LM Studio, Ollama, or llama.cpp: what actually runs on your machine

Your runtime doesn’t decide what model you can run: your memory budget does. LM Studio, Ollama, and llama.cpp let you spin up a model that’s going to crawl. llmfit is a single terminal command that reads your actual RAM, CPU, and GPU and ranks all the models by what actually runs on your machine, across LM Studio, Ollama, llama.cpp, MLX, and Docker Model Runner at once. It’s written in Rust, has an MIT license, and sits at around 36,000 stars on GitHub.

The interesting part isn’t the ranking. It’s that the tool refuses to give you a number without telling you where that number came from.

Why choosing a runtime doesn’t answer the question?

Almost all advice on “what local model to run” starts in the wrong place: it asks which runtime you prefer. But LM Studio, Ollama, and llama.cpp load the same quantized weights into the same finite memory. What decides whether a 14B model is usable on your laptop is how much memory the weights plus the KV cache need at the context you actually want to use — and that math is identical no matter which runtime you spin up.

llmfit scores each model on four dimensions instead of one: memory fit, estimated speed, quality, and context. A model can pass the memory filter and still be the wrong choice, because it only fits with such a short context that you can’t feed it a file. Separating the axes is what makes the output worth reading: “it fits” and “it’s usable” are different statements.

Speed is the axis that normally gets waved away. Here the estimates come from a memory bandwidth model backed by runtime sampling and real community measurements, and — this is the part that matters — each estimate comes with its inputs. llmfit info "<model>" shows you the fit analysis, the basis of the estimate, and the commands to verify it yourself.

If you’re curious how far you can stretch a modest machine, yoDEV already covered how Colibri runs a 744B parameter model on a 32GB laptop without a GPU. llmfit is the tool that tells you upfront whether your case looks like that.

LM Studio or Ollama? What llmfit finds in each runtime

Here the runtime comparison stops being abstract. llmfit doesn’t ask which one you use: it finds out.

  • Ollama — queries GET /api/tags on startup to inventory what you already have installed and marks those models with a green check. Downloads go through POST /api/pull.
  • LM Studio — queries GET /v1/models at the default endpoint; downloads use POST /api/v1/models/download, with progress tracked by job ID.
  • llama.cpp — detected by finding llama-cli or llama-server in your PATH. Models map to GGUF repositories on Hugging Face, with local cache in ~/.cache/llmfit/models.
  • Docker Model Runner — queries GET /engines, with Ollama-style naming ai/<tag>.
  • MLX — Apple Silicon, against the mlx-community model cache.

When more than one runtime can serve the same model, press d in the TUI to choose between them. Version v1.1.10 (August 17, 2026) also added RamaLama discovery.

Runtimes running on another machine connect via environment variables:

OLLAMA_HOST="http://192.168.1.100:11434" llmfit
DOCKER_MODEL_RUNNER_HOST="http://192.168.1.100:12434" llmfit
LMSTUDIO_HOST="http://192.168.1.100:1234" llmfit

LM Studio API authentication uses LMSTUDIO_API_KEY.

How do you install llmfit?

Pick the line that matches your machine:

scoop install llmfit                                    # Windows
brew install llmfit                                     # macOS/Linux, homebrew-core
port install llmfit                                     # MacPorts
curl -fsSL https://llmfit.axjns.dev/install.sh | sh     # add -s -- --local to avoid sudo
uvx llmfit                                              # run without installing
docker run --rm -it ghcr.io/alexsjones/llmfit --tui

Run llmfit with no arguments to open the TUI: your hardware on top and all models ranked below. / searches, j/k navigate, d downloads, D opens the download manager, and r refreshes after you spin up a server.

Are the numbers estimated or measured?

All numbers start out as an estimate. You can replace them with a measurement.

Spin up a model in any detected runtime and press b in the TUI: llmfit runs three real inference passes against the server running and measures tokens per second and time to first token on your hardware. Results are saved locally first. If you enable sharing with Space or s, the tool forks the repository, commits your result, and opens a pull request via GitHub’s device flow — and merged contributions ship in later releases, replacing estimates with data measured by the community on similar hardware.

That cycle is why the speed column is worth something. Self-reported benchmark numbers are usually a manufacturer talking about their own product; here they’re other people’s machines, attributed, with the estimation model visible alongside.

How do you use llmfit from a script?

For anyone wanting to hook this into an agent or provisioning step, the CLI is the real interface:

llmfit fit --perfect -n 5                    # perfect fits only, top 5
llmfit recommend --json --use-case coding --limit 3
llmfit recommend --force-runtime llamacpp
llmfit plan "Qwen/Qwen3-4B-MLX-4bit" --context 8192 --target-tps 25 --json
llmfit doctor                                # hardware detection report

plan is the underrated subcommand: it answers “can I run this specific model with this specific context and hit this token rate?”, and its JSON includes the upgrade deltas — what you’d have to change to make it work.

You can also describe a machine you don’t have yet, making it as much a shopping tool as a diagnostic one:

llmfit --memory=24G --ram=64G --cpu-cores=8 fit

And there’s a REST API if you want it resident:

llmfit serve --host 0.0.0.0 --port 8787
curl "http://localhost:8787/api/v1/models/top?limit=5&min_fit=good&use_case=coding"

What doesn’t llmfit do?

It ranks models; it doesn’t run inference. You still need a runtime. The quality dimension is a criterion coded by the maintainers, not a benchmark you ran yourself, so treat it as an initial filter, not a verdict. And the list of providers grows release to release: at the time of writing this note it covers the five runtimes documented above plus RamaLama discovery, so check the repository if yours is missing.

The honest summary: the LM Studio versus Ollama discussion matters way less than people think, and llmfit is the fastest way to prove it on your own hardware, before you spend forty gigabytes finding out.