跪拜 Guibai
← Back to the summary

Ollama vs LM Studio on a 24GB M6 Mac: MLX, Memory, and Locked Model Files Decide It

Ollama or LM Studio: On a 24GB M6 Mac, I Uninstalled Ollama

2026-10-29 | Environment: Mac mini M6 / 24GB unified memory / macOS 27.0.1 Keywords: Ollama, LM Studio, MLX, Apple Silicon, local LLM, memory management

Conclusion first

My three-month setup was "Ollama + command-line llama.cpp"; I finally switched to "LM Studio + command-line llama.cpp" and removed Ollama. Not because it's bad, but because it was exactly weak on the thing I care about most.

1. Clarifying lineage: these are not the same kind of product

Many people compare Ollama and LM Studio as two competing engines, but they sit at different layers.

What Ollama is: The underlying engine is llama.cpp, with a proprietary model repository (ollama pull), model format management, a set of CLI commands, and a resident local API service (default 11434). It is essentially a wrapper product of "llama.cpp + repository + service."

What LM Studio is: A closed-source, free GUI runner. Since 2025 it bundles a dual engine—llama.cpp (for GGUF) and MLX (for Apple Silicon native formats). Models are downloaded via a direct HuggingFace search from the interface.

So really four things are worth comparing: where models come from, which engine runs them, who manages memory, and who the interface is for. The table below follows this framework.

2. Ten-point comparison

Dimension Ollama LM Studio
Essence llama.cpp wrapper + own model repo + CLI service GUI runner with dual llama.cpp and MLX engines
Interaction command line ollama run, menu-bar icon GUI with model marketplace, chat window, parameter panel
Model source only ollama pull from its repository direct HuggingFace search, GGUF / MLX both, local import
File format proprietary blob repo, one tensor per file (black box) normal files, models/publisher/model/ structure (white box)
MLX support none yes, fastest path on M-series chips
Quantization levels mainly preset levels from repo any level freely chosen (Q4_K_M, UD-Q4_K_XL, 4bit/6bit/8bit MLX)
Memory control keep_alive adjustable (set to 0 to unload after use), but mmap behavior opaque JIT loading + idle auto-unload (duration configurable) + partial GPU offload
Multimodal supported, depends on repo drag image into chat window directly, vision models plug-and-test
Local API OpenAI-compatible, localhost:11434 OpenAI-compatible, localhost:1234
Resident overhead background service ~100-200MB Electron shell, 200-400MB minimum
Server deployment strong point, one curl install, pure CLI desktop app, not for servers
Third-party client compatibility best ecosystem, many plugins default to 11434 any OpenAI-protocol tool works, but fewer "one-click" recognitions

3. Three decisive differences

3.1 Are model files a black box or white box

This is the one that hurt me most in real deployment. The new Ollama stores models as "one tensor per file"—my downloaded qwen3.5:9b was split into 789 shards, totaling 7.1GB.

The consequence: these shards cannot be read directly by LM Studio, llama.cpp, or any other tool. There is no shortcut to copy a gguf out of blobs and rename it; manually reassembling 789 shards is unrealistic. In other words, models downloaded in Ollama only work with Ollama.

On the LM Studio side, it's just ordinary files: ~/.lmstudio/models/lmstudio-community/Qwen3.5-9B-MLX-4bit/, 5.6GB, copyable, backupable, putable on a NAS, and du-able for size.

A model is an asset you paid for in bandwidth and time; being locked inside a container has a cost in itself.

3.2 Whether there is an MLX engine

Ollama has only llama.cpp—it uses Metal as a GPU, workable but not using all of Apple Silicon's features.

LM Studio's MLX engine wraps Apple's official framework. The M6's GPU has a neural network accelerator per core; new features are followed by MLX most quickly. The industry-wide observation is that for pure text generation MLX is 10-30% faster than llama.cpp. I agree with that range, but the exact multiple strongly depends on model and quantization, so it should not be taken as a constant.

For "adapting to new chips", this one is decisive: llama.cpp can do it, but MLX is home turf.

3.3 Memory strategy: one is a resident service, one is on-demand loading

Ollama's design assumption is "treat it as a background service," so models and processes tend to stay resident. keep_alive can be tuned (including set to 0 to unload after use), but its mmap behavior is opaque; it's hard to know exactly how much physical memory a loaded model occupies.

LM Studio takes the opposite approach: JIT loading, load the model when a request comes, auto-unload after idle timeout. It also has a "partial GPU offload" slider to keep some layers on the CPU when memory is tight.

For a 24GB machine that also runs a browser and IDE, the second strategy is friendlier.

4. My choices for "frugal residence"

Do the math first, then choose the tool. The 24GB budget roughly breaks down like this:

Item Usage
macOS system + daily apps (browser, IDE, terminal) 8-10GB
Qwen3.5-9B (MLX 4bit weights) 5.6GB
KV cache (context compressed to 8K-16K) 1-2GB
Headroom 4-6GB

The conclusion is clear: 24GB is only enough to keep a 9B-class model resident, and context must be kept under 16K. Any 27B dense model (4bit ~16-18GB) would push memory to the edge of swapping, running at 5-8 tokens/s, breaking the experience.

So my division is:

A side note: LM Studio has a separate product called Bionic (released July 2026), an agent application built on top of LM Studio that can edit code, process documents, and do local speech-to-text, free locally without an account. Its features overlap with Claude Code; I didn't install it. But its underlying inference reuses LM Studio, so the two can coexist.

5. When would I reinstall Ollama

Not a total rejection. In three scenarios I'd immediately curl | sh again:

  1. Need to connect third-party tools that only recognize port 11434. Some Obsidian plugins, browser AI plugins, and many tutorials assume Ollama is on the machine; changing the port costs more than installing Ollama.
  2. Running inference service on a Linux server. Ollama installs with one command, is systemd-managed, and ollama run works remotely. LM Studio is a desktop app; that path doesn't work.
  3. Onboarding newcomers. ollama run qwen3 gets someone who's never touched local models running in one line; that learning curve has no rival.

The cost? The same model will be downloaded twice (each 5-6GB), an extra resident process, and those 5-6GB are locked in the blob repository. So install it only when you actually need it.

6. My final configuration

Purpose Tool Port / method
Daily experiments, multimodal image recognition LM Studio (MLX engine) GUI, 1234
API for scripts / pipelines LM Studio Local Server http://localhost:1234/v1
Long-resident, strict memory control llama-server (llama.cpp) 8080, KV cache quantization
Heavy tasks, long context Cloud API pay per use
Server-side inference Ollama only then 11434

The actual uninstall of Ollama is only two lines (first confirm there are no other models):

# Confirm only the model you want to delete
find ~/.ollama/models/manifests -type f

# Delete models (app itself can stay or go)
rm -rf ~/.ollama/models

This freed 7.1GB, and since the models were unusable by other tools anyway, there was no loss.

Final words

Tool choice shouldn't become a camp. Ollama solves "making a local model run simply enough"; LM Studio solves "making a local model run fast enough, transparently enough, and manageably enough." These goals don't conflict; it's just that on my 24GB M6 Mac, the latter weighs more.

The judgment criteria always are your constraints: how much memory you have, whether you need multimodal, whether models are resident or unloadable, and whether any third-party tool binds to a port. Write those four down and the answer largely appears; no need to look at any leaderboard.

All sizes, memory, and port data in this article come from local measurements; vendor-reported benchmarks are separately noted. Model versions and inference framework features change quickly; refer to official latest docs when deploying.