LM Studio

A GUI where Ollama is a command

Ollama removes the setup from running open weights and leaves you at a terminal. LM Studio removes the same setup and gives you a desktop application.

That sounds cosmetic and changes who can use it. A search box over Hugging Face, a download button, and a chat window is a different adoption curve from ollama pull. For trying five models against a task before committing, the GUI is faster to think in.

Underneath, both end up in the same place: an OpenAI-compatible endpoint on your own machine.

Finding and pulling models

Search and download run through Hugging Face from inside the app, so the catalogue is the Hub's rather than a curated list.

That means the discipline in models on Hugging Face applies here too. A search result is a repository, and telling a base model from a fine-tune, reading the licence, and checking the quantization are still yours to do. A friendly download button does not change what you are downloading.

The practical benefit is comparison. Pull three candidates, run the same prompts through each in the chat window, and you have the beginnings of the evaluation choosing the right model argues for, before any code exists.

The server is the part your code talks to

LM Studio serves models on OpenAI-like endpoints, locally and on the network.

So existing code points at it by changing a base URL, the same move OpenAI-compatible APIs describes, with the same caveat: compatible means the common path works, and provider-specific parameters may be silently ignored rather than rejected.

"And on the network" is worth noticing. A model served from a desktop machine to other machines is convenient for a team trying something, and it is a desktop application rather than a production server. The line Ollama draws between a laptop and serving applies unchanged.

There is a CLI as well

The lms command handles chat, downloads, daemon management and server control.

That matters for the awkward middle case: you like the GUI for exploration but need the model running without someone logged in and clicking. lms is how a laptop workflow becomes something scriptable, and it is easy to miss if you only meet the app through its window.

Acceleration, and why the Mac case is different

Two backends. llama.cpp across Mac, Windows and Linux, and MLX on Apple Silicon specifically.

MLX is the reason LM Studio comes up so often among Mac users. It targets Apple Silicon directly rather than treating it as a generic CPU or GPU, and on unified memory that is a real difference in what will run and how fast.

If you are on Apple Silicon and comparing local runners, benchmark both backends on the same model rather than assuming. If you are on Windows or Linux, this particular advantage does not apply and the choice comes down to whether you want a window or a prompt.

Where it fits

Reach for LM Studio when you are evaluating local models and want to move quickly, when the people doing that evaluation do not live in a terminal, or when you are on Apple Silicon and want MLX without assembling it.

Reach for Ollama when the workflow is scripted from the start, and for self-hosted models when the question stops being "does this run on my laptop" and becomes "what does it cost to serve this to users". Those are different problems, and a desktop app answers only the first.

Further reading

• LM Studio, Documentation: the app, the lms CLI, the local server and the acceleration backends.
• Ollama: the same job from a terminal.
• Models on Hugging Face: reading what you are about to download.
• Self-hosted models: where a laptop stops.