
第一次在本机跑 7B 模型,最耗时间的不是下载,是选工具。搜一圈会看到四个名字反复出现:Ollama、LM Studio、llama.cpp、vLLM,文章一律说”各有优劣”,然后你就关掉页面了。
问题在于,这四个东西压根不在同一个层级上竞争。把它们摆成一排比”谁更快”,就像拿螺丝刀、电钻、车床和一条生产线比谁拧螺丝快。
所以这篇不比优劣,只讲边界:每个工具在哪一步之后开始变难受。
1. 先把层级说清楚
llama.cpp 是推理引擎,用 C/C++ 写的,跑 GGUF 格式的量化模型,能在只有 CPU 的机器上跑。Ollama 是它的封装,负责下模型、管进程、给一个 HTTP 接口。LM Studio 是图形界面的封装,Mac 上还会用 MLX 后端。vLLM 是另一条路上的引擎,为 GPU 高并发设计。
Ollama 和 LM Studio 都是”让别人不用碰命令行”的产物,llama.cpp 和 vLLM 是”让你能碰到每一个参数”的产物。这四个词经常被并列,是因为它们都在解决”本地跑模型”,但解决的是不同人的不同麻烦。
2. 四个工具,四条天花板
Ollama:天花板是并发。 它用 OLLAMA_NUM_PARALLEL 控制并行请求数,本质还是同一份 KV cache 分片,两个人同时用就开始排队。它的价值在于 ollama run qwen3:8b 这一条命令——模型、量化、模板、接口全都替你定了。
LM Studio:天花板是自动化。 它的模型库、显存估算条、对话界面做得比同类都好,点几下就能试一个新模型。但它是个桌面应用,没有服务化、没有守护进程、没有开机自启的可靠办法,放进 CI 或者塞进服务器是错配。
llama.cpp:天花板是你自己的耐心。 -ngl 决定多少层放显卡,--ctx-size 决定上下文长度,--cache-type-k q8_0 能再把 KV cache 压一半。它的每一个参数都能省下或浪费几百兆显存,代价是你得自己算。
vLLM:天花板是显存和运维。 PagedAttention 让它能把显存切得很细,几十个并发下吞吐是前三个的数倍。但它启动时就要按 --gpu-memory-utilization 预占显存,模型格式要 AWQ、GPTQ 或 FP8,它不负责让你试模型,它负责让一件事稳定地被很多人同时用。
3. 多维对照
| 维度 | Ollama | LM Studio | llama.cpp | vLLM |
|---|---|---|---|---|
| 模型格式 | GGUF | GGUF / MLX | GGUF | Safetensors(AWQ/GPTQ/FP8) |
| 跑在 CPU 上 | 可以 | 可以 | 最擅长 | 不行 |
| 并发能力 | 个位数 | 基本为 1 | 低,靠 server 模式 | 几十到上百 |
| 显存控制粒度 | 粗 | 中 | 最细 | 按比例预留 |
| 上手成本 | 一条命令 | 点鼠标 | 要读文档 | 要懂部署 |
| 适合的负载 | 本机脚本、工具调用 | 试模型、单人对话 | 显存吃紧、异构硬件 | 团队共享 API |
这张表里最该看的是第三行。并发这一行决定的不只是性能,是”这工具能不能被第二个人用”。
4. 一个必须自己算的显存账本
选工具之前先算账,能省掉一半的试错。粗算公式:参数量 × 每参数字节数 + KV cache + 上下文开销。
Q4_K_M 量化大致是每参数 0.55 字节,Q8_0 约 1.06 字节,FP16 是 2 字节。所以 7B 的 Q4 模型文件约 4.1GB,32B 的 Q4 约 19GB,70B 的 Q4 约 40GB。这是权重,不含上下文。
| 模型规模 | Q4_K_M | Q8_0 | 8K 上下文额外占用 |
|---|---|---|---|
| 7B | 约 4.1GB | 约 7.5GB | 约 1GB |
| 14B | 约 8.5GB | 约 15GB | 约 2GB |
| 32B | 约 19GB | 约 34GB | 约 4GB |
| 70B | 约 40GB | 约 72GB | 约 8GB |
数字是估算,实际随模型结构和实现浮动 10% 到 20%。但量级足够判断一件事:你的显卡是”刚好装下”,还是”装下之后没有余量”。刚好装下的,上下文一长就会 OOM。
5. 三套能直接照抄的组合
- 试模型阶段:LM Studio 单独用。 一个下午试五六个模型,看哪个中文还行、哪个代码能跑通。这个阶段任何命令行都是浪费。
- 本机脚本与工具调用:Ollama + OpenAI 兼容接口。 起在
127.0.0.1:11434,用官方 SDK 把base_url指过去,代码不用改。写完脚本就固定用这一个模型。 - 给团队用:vLLM + 一层反向代理。 一张 24GB 卡跑 14B 的 AWQ,
--max-model-len 8192、--gpu-memory-utilization 0.85,前面挂一个带鉴权的网关。这时候你要管的不再是模型,是配额和超时。
还有一个不常被提到的组合:老显卡或纯 CPU 机器上,直接上 llama.cpp,把 -ngl 设成能塞进显存的层数,剩下的交给内存。它的速度不算好看,但它是唯一能在 8GB 卡上跑 32B 模型的路子。
6. 选错了的三个信号
信号一:你在给 Ollama 加负载均衡。 需要给一个单机封装加反向代理和队列,说明你要的其实是 vLLM。继续加固只是在给错误的选择做工程。
信号二:你在给 vLLM 写模型切换脚本。 每次换模型都要重启服务、重新预占显存、等两分钟加载,说明你在用一个生产引擎做实验。这个活该交给 LM Studio 或 Ollama。
信号三:你在用 LM Studio 的界面点”启动服务”,然后希望它一直活着。 桌面应用没有守护进程语义,窗口一关、系统一睡,服务就没了。把桌面工具当服务用,故障不会是”挂了”,而是”不知道为什么没响应”。
写在最后
这四个工具的分野,其实不是技术路线之争,是”谁承担复杂度”的问题。Ollama 和 LM Studio 把复杂度吞进去,换来的是你失去对显存的控制;llama.cpp 和 vLLM 把复杂度摊开,换来的是你必须自己算账。
大多数人会在两者之间来回跳一次:先用 GUI 试,觉得不够用,转命令行,发现要调的东西太多,又退回去。这个来回不是浪费时间,它是你搞清楚自己真实负载的唯一办法。
真正的分水岭只有一个问题:这台机器上的模型,是你一个人用,还是别人也在用。
你本机现在跑的是哪个模型、多大显存?有没有遇到过”刚好装下、一长就崩”的情况?

评论 (0)