Owist Modelfile Resources

Live VRAM/RAM and speed estimation for Ollama Modelfiles, right in the editor — see whether a model actually fits your hardware, and roughly how fast it'll run, before you wait through a multi-gigabyte ollama create to find out.

This is a companion to owist-modelfile-lint (the Python CLI/library it's built on) and deliberately narrow in scope: syntax highlighting, generic autocomplete, and Modelfile snippets are already well covered by other extensions in this space. This one focuses on the one thing nothing else offers — resource estimation.

Requirements

pip install "owist-modelfile-lint[resources]"

The [resources] extra is only strictly needed on Windows (for RAM detection) — Linux/macOS work with the base package alone. Make sure modelfile-lint is on your PATH, or set owistModelfile.cliPath in settings to its full path.

Features

Always-visible inline estimate (CodeLens)

The moment you open a Modelfile whose FROM points at a local .gguf file, you'll see:

✓ ~5.85 GB · 43-76 tok/s · Fits on RTX 4090

right above the FROM line — no hovering required. If it doesn't fit, you'll see a second line offering to fix it automatically:

✎ Set num_ctx to 3200 (largest that fits)

One-click "set the largest context that fits"

Answers a question every Ollama user eventually asks — solved directly with math (KV cache scales linearly with context length), not a guess — and edits your PARAMETER num_ctx line for you.

Real diagnostics

Every issue modelfile-lint finds (not just resource estimates) shows up as a genuine VS Code diagnostic — squiggly underlines, Problems panel entries, the works.

Hover for the full breakdown

Hovering the FROM line shows the actual arithmetic — weights + KV cache + overhead — and the confidence caveat on the speed range, not just a headline number.

Status bar hardware indicator

A persistent reminder of what device every estimate in this window is being calculated against. Click it for the full detected profile.

Honesty about confidence levels

This extension inherits the same standard the underlying Python package holds itself to:

• Memory estimates are a real calculation from the model's own GGUF metadata — not a guess.
• Decode speed (tokens/sec) is a physics-grounded range, not a fabricated precise number — derived from memory bandwidth ÷ model size, which is a real ceiling, but actual speed depends on kernel implementation, thermal state, and background load that no static tool can see.
• Time-to-first-token is the least certain number shown and is always labeled as such.

Known gaps (stated plainly)

• AMD GPUs aren't detected yet (rocm-smi support not implemented in the underlying package).
• Pull-by-name models (FROM llama3.2) aren't inspected — only local .gguf file paths, since there's nothing on disk yet to read metadata from.
• Partial GPU/CPU offload doesn't compute an exact speed for the split.

See the Python package's own CHANGELOG.md for the full, current list.

How the estimate is computed

This extension doesn't reimplement any of the math — it shells out to the installed modelfile-lint --json CLI, the same tested engine used from the command line and in CI. One source of truth, no risk of the editor and CLI silently disagreeing with each other.