推論引擎比較
引擎是把權重變成 token 的程式：它載入檔案、跑 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 出的不只是伺服器——還有量化與轉換工具、基準測試框架、以及十幾種語言的綁定。
深入補充
vLLM 誕生自分頁注意力的洞見（見 並行處理）：像 OS 對待 RAM 那樣對待 GPU 記憶體，就能塞進多更多的請求。它是「我有一台 GPU 伺服器與真實流量」的預設答案。
SGLang 跨請求快取前綴（RadixAttention）：如果 40 個智慧代理共享同樣兩頁的系統提示詞，那份提示詞只處理一次，不是 40 次。它也以快速受限解碼聞名——見 結構化輸出。
exllamav2 是專為一個利基磨的利刃：單人、單張 NVIDIA GPU、想要每量化位元最多 tok/s。伺服器故事與硬體涵蓋都很薄；但利基是真的。
MLX 是 Apple 的機器學習框架，為統一記憶體而生。截至目前，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% 以內——常常因為它們共享後端。真正讓你的體感速度以倍數而非百分比移動的是：
- 模型是否已經載入——冷載入要花數秒到一分鐘。
- 每輪是否重送整個對話——上下文成本，見 token 與分詞器。
- 請求是否在彼此後面排隊——見 並行處理。
- 層是否都在 GPU 上——見 引擎參數。
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 匯入本機路徑）。伺服器端 vLLM 與 SGLang 之間的 safetensors 也一樣。實際後果：沒有檔案層級的廠商鎖定，選錯引擎的代價是幾分鐘。
這就是這一頁不斷把工作流程擺在基準分數之前的原因：當需求改變，你已經下載的模型會跟著你走。
何時從 Ollama 畢業
Ollama 的預設值很優秀，直到不再優秀。在以下情況換到服務引擎：
- 你需要超過個位數串流的持續並行（見 並行處理）。
- 你想要跨多個共享系統提示詞的智慧代理做前綴快取（SGLang）。
- 你必須直接從 HF 生態服務 AWQ/GPTQ safetensors 量化。
- 你要在出貨前對產品功能做負載測試。
- 你需要多 GPU 張量平行把一個大模型塞進多張卡。
在上述任一成真之前，便利性比吞吐量更值錢。