推理引擎对比
引擎是把权重变成词元的程序：加载文件、跑 transformer 前向传播、通常还在上面说 HTTP。好消息是几乎每个引擎在同一硬件上以大致相同的速度跑同一个模型——引擎选择关乎工作流、格式支持和并发，而非原始 tok/s。坏消息也一样：在它们之间逛基准测试基本是浪费力气。
全场
| 引擎 | 它是什么 | 格式 | 硬件触达 | 为谁而生 |
|---|---|---|---|---|
| llama.cpp | 带内置服务器的 C/C++ 推理核心 | GGUF | CPU、CUDA、ROCm、Metal、Vulkan——最广触达 | 地基；几乎到处跑 |
| Ollama | llama.cpp 加模型库、CLI 和 REST 的包装 | GGUF | llama.cpp 能跑的都行 | 零摩擦桌面使用 |
| LM Studio | 精致 GUI 加 OpenAI 兼容服务器 | GGUF（Mac 上还有 MLX） | Windows/macOS/Linux GUI | 要按钮不要标志的人 |
| vLLM | Python 服务引擎：页注意力、连续批处理 | safetensors | CUDA（加一些 ROCm/TPU 支持） | 数据中心级并发服务 |
| SGLang | 带 RadixAttention 前缀缓存的服务引擎 | safetensors | CUDA | 快速结构化输出；共享前缀的智能体 |
| exllamav2 | 为解码速度调优的仅 GPU 加载器 | EXL2、GPTQ | 仅 CUDA | 单张消费级 NVIDIA GPU 上的最大单用户 tok/s |
| MLX | Apple 的数组框架；mlx-lm 在其上跑模型 |
MLX | Apple silicon | 近期 Mac 上的快速实用路线 |
| transformers (HF) | 一切移植所自的参考实现 | safetensors | CPU、CUDA | 正确性核对、实验、训练管道 |
一条血统注：Ollama 和 LM Studio 都在引擎盖下跑 llama.cpp。把它们与 llama.cpp 相比是在比包装、不是比推理。
也值得知道：llama.cpp 发布的不止服务器——量化和转换工具、基准测试 harness、和一打语言的绑定。
深挖
vLLM 诞生自页注意力洞见（见 并发）：像 OS 对待内存那样对待 GPU 内存，就能装下远多得多的请求。它是“我有一台 GPU 服务器和真实流量”的默认答案。
SGLang 跨请求缓存前缀（RadixAttention）：如果 40 个智能体共享同一个两页系统提示词、提示词只处理一次、不是 40 次。它也以快速约束解码著称——见 结构化输出。
exllamav2 是恰好一个生态位的锋利边缘：单张 NVIDIA GPU 上的单用户、要每比特量化最多的 tok/s。服务器故事和硬件广度都薄；生态位是真的。
MLX 是 Apple 的 ML 框架、为统一内存而造。截至本文写作 mlx-lm 常在更大模型上胜过 llama.cpp 的 Metal 路径——接近到在 Mac 上值得两个都试（更多在 Apple Silicon）。
transformers 是缓慢、忠实的参考：当量化引擎行为怪异时、把同一模型穿过它跑一遍回答“是引擎还是模型”。它也是微调工具底下的管道（见 微调）。
按需选择
| 你是…… | 从……开始 |
|---|---|
| 在自己桌前聊天 | Ollama 或 LM Studio |
| 从 shell 写脚本（管道、cron、小工具） | Ollama 的 REST API、或 llama-server |
| 搭建轻流量应用后端 | llama-server——一个进程、零运维 |
| 服务许多并发用户 | vLLM 或 SGLang |
| 跑共享长系统提示词的智能体机群 | SGLang 或 vLLM；见 智能体 |
| 全 Mac 家庭 | 先 Ollama/LM Studio；要更快就 MLX |
表格两条注：
- “从……开始”不是“止步于此”——每个桌面引擎读同一个 GGUF，试第二个花五分钟、不是一次迁移。
- 真要比较时，保持一切恒定：同模型、同量化、同提示词、模型已热。
格式分界镜像桌面/服务器分界
GGUF 对 safetensors（见 模型格式）不只是容器偏好——它决定你的引擎。GGUF 是单文件、预量化、到处跑的格式，整个桌面生态（llama.cpp、Ollama、LM Studio）建立在它上面。safetensors 是 Hugging Face 生态的分片张量格式；高吞吐服务器引擎（vLLM、SGLang、transformers）消费它、通常即时量化（AWQ/GPTQ 变体）而非预打包。
所以真实的决策树很短：桌面和单用户 → GGUF 引擎；服务器和并发 → safetensors 引擎。其余是细节。
当什么东西“跑不起来”时，先查格式——“引擎 X 跑不了模型 Y”的一半是 GGUF/safetensors 错配、不是能力差距。
开销不是故事
在相同硬件、相同量化下，引擎们的单流解码落在彼此大约 10–20% 之内——常常因为它们共享后端。真正以倍数（不是百分比）移动你体验速度的是：
Same GPU, same 8B Q4_K_M, single stream (illustrative, not specs):
llama.cpp / Ollama / LM Studio ~130–145 tok/s (same engine underneath)
exllamav2 EXL2 ~4bpw ~160–180 tok/s (loader tuned for decode)
Same GPU, 8 concurrent chat streams:
llama-server serial queue each stream waits; total throughput flat
vLLM all streams near single-stream speed
选匹配你工作流的引擎，然后把精力花在 I/O 模式而不是引擎基准上。
一个文件、多个引擎
你为 Ollama 下载的 GGUF 也能直接在 llama.cpp 和 LM Studio 里跑——引擎不转换、不重新下载；你把它们指向同一个文件（Ollama 能用一行 Modelfile 导入本地路径）。服务端 safetensors 在 vLLM 和 SGLang 之间同样成立。实际后果：没有文件级厂商锁定、选错引擎只花你几分钟。
这就是本页不断把工作流推到基准之前的原因：需求变化时、你已经下载的模型跟着你走。
何时从 Ollama 毕业
Ollama 的默认值极佳、直到不再极佳。以下时候转向服务引擎：
- 你需要超过寥寥几条流的持续并发（见 并发）。
- 你想要跨共享系统提示词的许多智能体的前缀缓存（SGLang）。
- 你必须直接服务 HF 生态的 AWQ/GPTQ safetensors 量化。
- 你在发布产品功能前做负载测试。
- 你需要多 GPU 张量并行把一个大模型装进多卡。
那些有一条成真之前，便利比吞吐更值钱。