LM Studio vs Ollama in November 2026: license, engines, API, server use and speed

LM Studio and Ollama run the same engines underneath (llama.cpp on every platform, MLX on Apple silicon), so on the same model and engine version their speed is within a few percent; the reported gaps, from 10% up to 2.3 times, come from older bundled runtimes or from MLX against llama.cpp on a Mac. The real differences are elsewhere: Ollama is MIT-licensed open source, while LM Studio is a free but closed app whose terms bar offering it as a service to third parties. LM Studio has the better desktop app, Ollama the simpler Linux service. Versions on 7 November 2026: LM Studio 0.4.28 (31 October 2026) and Ollama v0.40.15 (3 November 2026).

From the LM Studio changelog, 0.4.0 release post, terms and privacy policy, and Ollama's GitHub repository, releases page and FAQ, all read 7 November 2026.

What is the difference in licensing?

Ollama's code is MIT-licensed on GitHub (186k stars on 7 November 2026), so you can modify it, ship it inside a product or run it as a paid service. LM Studio's desktop app is closed source. Until July 2025 companies needed a separate commercial license; on 8 July 2025 LM Studio announced it is free to use at home and at work with no form to fill in.

"Free for work" has limits that matter for some readers. The current app terms (version of 23 August 2026) license the software for your "personal and / or internal business purposes" and prohibit sublicensing, distributing or offering it as a service to third parties. If you are an employee, your employer is the customer bound by the terms. Running LM Studio on your laptop to help write code is fine. Wrapping llmster into a hosted product for your clients is the case the terms exclude, and Ollama's license does not. The terms also say certain features may carry fees; the privacy policy names cloud models and web search as the paid Cloud Services, and local inference is not among them.

Which engines and model formats does each use?

Both are wrappers around the same open engines, and the version each one bundles is what you are really choosing. LM Studio ships its llama.cpp engine as a runtime that updates separately from the app: the 0.4.26 changelog (13 October 2026) names runtime 2.50.0, built from upstream build b11337, and the Bionic changelog of 5 November already lists runtime 2.67.0. Upstream llama.cpp was at b12189 on 7 November 2026. Update it with lms runtime update llama.cpp (or lms runtime update mlx on a Mac), and judge an install by its runtime version, not the app version. On macOS it also runs MLX models, and from 0.4.25 a third engine it calls Splash on M3 or newer Macs with macOS 26.4 or later.

Ollama runs GGUF models through its llama.cpp-based engine and, from v0.40.0 (25 September 2026), runs model architectures that MLX supports on MLX by default on Apple silicon. Its library publishes both kinds of builds side by side, for example qwen3.6:27b-q4_K_M (17 GB) and qwen3.6:27b-nvfp4 for MLX (19 GB).

Format support follows from that. Both load GGUF files from Hugging Face. LM Studio loads MLX safetensors on a Mac directly from its model search. Ollama imports GGUF or safetensors through a Modelfile but does not quantize GGUF files on import. If you are choosing a machine mainly for MLX, the DGX Spark vs Mac Studio page compares unified-memory hardware. If you want the newest llama.cpp features on day one (a new architecture, a new speculative decoding method), plain llama.cpp gets them first; the llama.cpp build guide covers building it on a GB10.

Is LM Studio faster than Ollama?

Only when the two are not running the same engine or the same engine version. The published comparisons:

Reported by third parties, not GPUwerk measurements. asiai does not state the app versions; InventiveHQ does not state versions either and measured wall-clock speed over a 12-prompt suite. Both asiai runs predate Ollama v0.40.0, which made MLX its default on Apple silicon. Read 7 November 2026.

Read the table by engine, not by brand. The large Mac gaps in the asiai test are MLX against llama.cpp, and Ollama's own MLX launch post showed the same effect inside one product: Qwen3.5-35B-A3B went from 58 tok/s on its llama.cpp path to 112 tok/s on MLX. Since v0.40.0 both apps use MLX for that model on a Mac, so the March numbers no longer describe the current Ollama. On the RTX 5060 Ti, LM Studio matched plain llama.cpp within 0.3%, while Ollama paid about 10%, which InventiveHQ puts down to its daemon, scheduler and bundled runtime. On the M3 Max the order flipped and LM Studio was slowest, blamed on its bundled runtime lagging upstream. Version lag can be worse than that: ComputingForGeeks found Ollama's bundled runtime at 20.0 tok/s on an L40S where upstream llama.cpp with the same flags gave 39.1.

The memory column in the asiai test is more instructive than the speed one. LM Studio's process used 21.4 GB and Ollama's 41.6 GB, and asiai attributes the difference to Ollama reserving KV cache for the full 262k-token context. That matches Ollama's context-length rule: on 48 GiB of GPU memory or more, the default context is 256k. By my calculation from the model's config.json (48 layers, 4 KV heads, head dimension 128):

• KV per token at f16: 2 × 48 × 4 × 128 × 2 bytes = 98,304 bytes, or 96 KiB.
• At 262,144 tokens: 262,144 × 96 KiB = 24 GiB of KV cache before you type anything.

That is the 20 GB gap in the test, near enough. On a 64 GB Mac it costs nothing until you load a second model; on a 24 GB GPU Ollama would have picked a 32k default instead. Set OLLAMA_CONTEXT_LENGTH to what you actually use.

Which has the better API and headless server?

They are close; Ollama is easier to run as a plain Linux service, and LM Studio exposes more API styles. LM Studio's OpenAI-compatible server answers /v1/models, /v1/responses, /v1/chat/completions, /v1/embeddings and /v1/completions, its Anthropic-compatible /v1/messages works with Claude Code, and the native /api/v1/chat added in 0.4.0 is stateful (pass previous_response_id to continue a conversation) and returns speed and time-to-first-token stats with each response. Ollama has its native /api routes, OpenAI-compatible /v1 routes including a stateless /v1/responses, and /v1/messages.

For servers, LM Studio 0.4.0 (28 January 2026) introduced llmster, the app's core packaged as a daemon with no GUI:

curl -fsSL https://lmstudio.ai/install.sh | bash
lms daemon up
lms get <model>
lms server start

Ollama's Linux install script sets up a systemd service, and the Docker image is ollama/ollama:

curl -fsSL https://ollama.com/install.sh | sh
sudo systemctl status ollama
ollama pull qwen3.8:27b

Model loading differs in a way that bites shared machines. LM Studio's just-in-time loading lists every downloaded model at /v1/models and loads one on first request, then auto-unloads it after an idle period. Ollama keeps a model in memory for 5 minutes after the last request by default (keep_alive), and loads up to three models per GPU. On the security side, LM Studio's server has a Require Authentication setting that accepts a bearer token (per its Anthropic compatibility docs); the Ollama docs I read describe binding with OLLAMA_HOST but no API key for the local server, so put a reverse proxy or gateway such as LiteLLM in front before exposing it.

Can either one serve several users?

A few, yes; a team, not well. LM Studio 0.4.0 added continuous batching to its llama.cpp engine, with a "Max Concurrent Predictions" setting that defaults to 4 slots on a unified KV cache; the release post said MLX support for parallel requests was still in the works. Ollama processes one request per model at a time unless you raise OLLAMA_NUM_PARALLEL, and memory then scales with slots times context. Neither has user accounts, quotas or per-user keys; the team access guide covers what a shared box needs on top. For more than a handful of people I would put vLLM behind Open WebUI instead; the sibling article on Ollama vs vLLM has the concurrency numbers (936 against 74 tok/s at 32 requests on an RTX 5090).

What does each send over the network?

For local models, neither vendor says it collects your prompts; both phone home for updates and offer optional cloud models. LM Studio's privacy policy (last updated 19 October 2026) says that when you run models locally "none of your messages, chat histories, and documents are ever transmitted from your system", and that the app has no telemetry or user-specific tracking. Update checks send the app version and build, your OS and your IP address, and model searches go out as anonymized queries. The Ollama FAQ says "We don't see your prompts or data when you run locally"; the macOS and Windows apps download updates automatically, and signing in (ollama signin) connects your install to ollama.com for cloud models and pushing models.

Both now sell cloud inference inside the same app: LM Studio's cloud models and web search, and Ollama's cloud model tags such as gpt-oss:120b-cloud. Those requests do leave the machine. Ollama says it does not store or log that content, and LM Studio says it processes it transiently. If a model must never leave the box, check the model tag before you run it, and block outbound traffic at the firewall rather than relying on settings.

Which should you use on Windows, a Mac or a Linux server?

Both are fine for one person; pick by operating system and by whether a GUI matters.

If you want local tools, LM Studio has been an MCP host since 0.3.17, while Ollama needs a separate client; the setup for both is in MCP with local LLMs. For editor agents against either server, the coding agents guide shows the base URL and model name each tool needs. If you have not installed either yet, how to run an LLM locally walks through both. On a DGX Spark, LM Studio’s install and speed are covered in LM Studio on a DGX Spark.

FAQ

Sources

Every figure above is attributed to its source in the sentence or table where it appears. Pages were read on 7 November 2026 unless a date says otherwise.

• LM Studio changelog, LM Studio, 2026-10-31
• Bionic changelog, LM Studio, 2026-11-05
• Introducing LM Studio 0.4.0, LM Studio, 2026-01-28
• LM Studio is free for use at work, LM Studio, 2025-07-08
• LM Studio app terms, LM Studio, 2026-08-23
• LM Studio app privacy policy, LM Studio, 2026-10-19
• OpenAI compatibility endpoints, LM Studio docs
• Anthropic compatibility, LM Studio docs
• Headless mode, LM Studio docs
• System requirements, LM Studio docs
• ollama/ollama, GitHub
• Releases · ollama/ollama, GitHub, 2026-11-03
• FAQ, Ollama docs
• Context length, Ollama docs
• Importing a model, Ollama docs
• qwen3.6 tags, Ollama library
• Ollama vs LM Studio: Apple Silicon Benchmark, asiai, 2026-03-29
• Ollama vs LM Studio vs llama.cpp: Which Local LLM Runner Should You Use?, InventiveHQ, 2026-06-01
• Ollama vs vLLM vs llama.cpp: Speed Benchmarked, ComputingForGeeks, 2026-10-06
• Ollama is now powered by MLX on Apple Silicon in preview, Ollama blog, 2026-03-30
• Qwen/Qwen3-Coder-30B-A3B-Instruct config.json, Hugging Face