你選的其實不是推理引擎。你選的是硬體策略、工作負載形狀和服務模型。引擎只是隨之而來的結果。
這才是思考 LLM 推理引擎最有用的方式。
系列說明：這是我「自托管 LLM / 本地 AI」教學系列的第三部分。
那兩篇文章解釋了硬體容量和頻寬的計算方式。
這篇文章則說明將硬體轉化為可用推理的軟體層。
引擎
這些工具服務於不同的目的 / 處於不同的層級
- 本地可攜性
- 消費級 CUDA
- Apple 統一記憶體工作流程
- 量化推理
- 生產環境服務
- 分散式編排
- 供應商優化的資料中心執行
一個有用的心智模型：
推理引擎不是「模型」。它是交通指揮、記憶體管理器、核心調度器、排程器、快取記帳員、平行化規劃者、API 介面，有時甚至是部署框架。
最好的引擎會匹配你的記憶體層級、互連架構、量化格式、延遲與吞吐量目標、模型架構，以及營運成熟度。
一頁決策指南
- 筆電 / 邊緣裝置 / 特殊硬體 → llama.cpp
- Mac 優先的工作流程 → MLX / MLX-LM
- 單張 RTX 的本地推理 → ExLlamaV2
- 2-4+ 張 NVIDIA / CUDA GPU → ExLlamaV3
- 一般生產環境服務 → vLLM
- 長上下文 / MoE / 路由 → SGLang
- NVIDIA 最大效能 → TensorRT-LLM
- 叢集編排 → NVIDIA Dynamo
本指南的其餘部分會解釋原因。
推理引擎實際在做什麼
推理引擎會載入權重、將輸入標記化、執行前向傳播、取樣 token、維護 KV 快取，並串流輸出結果。嚴謹的引擎還會處理批次處理、排程、前綴快取、量化、平行執行、API 服務、指標監控，以及分散式執行。
工作負載有兩個階段：
Prefill（預填充）讀取提示詞並建立初始 KV 快取。它是計算密集型的。
Decode（解碼）一次生成一個 token，反覆讀取權重和 KV 快取。它受記憶體頻寬限制。解碼速度更取決於記憶體頻寬而非峰值計算量。
這個區別解釋了幾乎所有事情：
- 短提示詞、長回答：解碼主導 → 記憶體頻寬和批次處理很重要。
- 長提示詞、短回答：預填充主導 → 注意力核和分塊預填充很重要。
- 多名使用者：排程器品質很重要 → 連續批次處理、快取分頁、公平性。
- 長上下文：KV 快取主導 → 分頁注意力、KV 量化、卸載。
- MoE：專家路由主導 → 專家平行化、互連、分組 GEMM。
- 多節點：互連主導 → NVLink、RDMA、流水線平行化、分離式架構。
PagedAttention 解決了 KV 快取碎片化問題。FlashAttention 使用 IO 感知的平鋪技術來減少 HBM（高頻寬記憶體）流量。開放式解碼先草擬便宜的 token，再平行驗證它們。反覆出現的主題是：推理效能就是記憶體搬移加上排程。
真正的瓶頸
- 記憶體頻寬，而不只是 VRAM 大小。VRAM 決定能否容納模型。頻寬決定解碼速度。Apple 的 M3 Ultra 提供高達 819 GB/s 的統一記憶體頻寬。NVIDIA 的 H100 SXM 則有 3.35 TB/s 的 GPU 記憶體頻寬。統一記憶體讓你可以運行在消費級 VRAM 中無法容納的模型。HBM 則讓你能在模型容納得下時更快地提供服務。能容納不代表速度快。容量不代表頻寬。
- KV 快取的增長。KV 快取會隨著批次大小和上下文長度而增長。長上下文的工作負載即使在權重能容納的情況下，也可能耗盡記憶體。PagedAttention 將 KV 快取分割成區塊，提高了利用率並支援更大的批次。
- 互連架構。一旦模型跨越 GPU 邊界（多 GPU），你就得付出通訊成本。張量平行化需要頻繁的全歸納集合。流水線平行化在階段邊界進行通訊。專家平行化則需要 MoE 的全對全流量。vLLM 的文件指出，如果沒有 NVLink，流水線平行化的表現可能優於張量平行化。
- 排程器品質。一個好的排程器能決定哪些請求進入批次、預填充和解碼如何共用加速器、長提示詞是否會阻塞短解碼、以及如何避免資源饑餓。支援批次處理並不等同於像一個生產就緒的排程器那樣運作。
- 執行時期開銷。CUDA graphs、核融合、取樣開銷、標記器開銷、HTTP 開銷、LoRA 切換，以及結構化解碼，這些都很重要。在大規模場景下，那些惱人的 2% 開銷會聯合起來，需要你特別關注。
引擎家族
主要有四大類別：
可攜式本地運行時：llama.cpp、 MLC LLM、 ONNX Runtime GenAI、 OpenVINO、 Ollama 風格工具。它們關心的是「讓它在這裡跑起來」。
Apple / 統一記憶體運行時：MLX 和 MLX-LM。它們關心的是「善用大共享記憶體和 Apple 的軟體堆疊」。
消費級 CUDA 量化引擎：ExLlamaV2 和 ExLlamaV3。它們關心的是「讓我的 3090/4090/5090 主機用低位元權重發揮極致效能」。
生產環境服務引擎：vLLM、 SGLang、 TensorRT-LLM、 TGI、 LMDeploy。它們關心的是並發使用者、KV 快取、批次處理、平行化、可觀測性，以及每個 token 的成本。
此外，還有像 Dynamo 這樣的編排層，它位於引擎之上，負責協調叢集、分離式預填充/解碼、路由和自動擴展。
llama.cpp：可攜性之王
當硬體是特規的、資源受限的、離線的、CPU 密集的、邊緣運算的，或者不是整潔的 NVIDIA 資料中心節點時，llama.cpp 就是答案。
它透過 ARM NEON、Accelerate 和 Metal 支援 Apple Silicon；透過 AVX/AVX2/AVX512/AMX 支援 x86；支援 RISC-V、低位元量化、CUDA、透過 HIP 支援 AMD、MUSA、Vulkan、SYCL，以及 CPU+GPU 混合卸載。這就是為什麼 llama.cpp 在「讓它跑起來」這個領域獨占鰲頭。
它的 HTTP 伺服器不僅僅是一個「玩具級本地執行器」。llama-server 提供了與 OpenAI 相容的路由、Anthropic Messages API 相容性、重新排序、連續批次處理、多模態支援、JSON Schema 約束、函數呼叫、開放式解碼，以及一個 Web 介面。
一個關鍵的限制是：llama.cpp 不適用於嚴肅的多節點生產環境服務。它的 RPC 後端被明確標記為概念驗證、脆弱且不安全。
結論：當可攜性、離線操作、GGUF 或混合卸載比大規模叢集服務更重要時，請使用 llama.cpp。
不要在多 GPU 設定中使用。
MLX 和 MLX-LM：Apple Silicon 的利器
MLX 是 Apple 為 Apple Silicon 打造的陣列框架，而 MLX-LM 是建構於其上的 LLM 套件。它是一個 Mac 優先的 ML 軟體堆疊。
關鍵的硬體事實是統一記憶體。Apple Silicon 讓 CPU 和 GPU 直接存取相同的記憶體池。MLX 陣列存在於統一記憶體中，你可以在執行運算時選擇裝置，而不需要在不同的記憶體空間之間搬移陣列。
這改變了本地推理的權衡取捨。在獨立 GPU 系統上，問題是「它能放進 VRAM 嗎？」在擁有大量統一記憶體的 M 系列 Mac 上，問題變成了「它能放進記憶體嗎？記憶體系統餵給 GPU 的速度夠快嗎？」大型量化模型可以裝進那些在 24 GB 消費級 GPU 上無法運行的機器。
不過，它的速度也比較慢。
MLX-LM 新增了 Hugging Face Hub 整合、量化、LoRA 和完整微調、分散式推理，以及一個龐大的 MLX Community 模型生態系統。MLX 現在已不限於 Mac：它為 Linux 提供了 CUDA 和純 CPU 套件。分散式通訊支援 MPI、基於 TCP 的 Ring、用於 Thunderbolt RDMA 的 JACCL，以及用於 CUDA 的 NCCL。
MLX-LM 的伺服器本身也警告不建議用於生產環境，因為它僅實作了基本的安全檢查。
結論：在 Mac 優先的 ML 和 LLM 工作流程中使用 MLX。對於高並發的公開服務，請從真正的服務堆疊開始。
ExLlamaV2 和 V3：消費級 CUDA，經過調校且快速
ExLlamaV2 是給那些想讓消費級 NVIDIA GPU 發揮超水準表現的人使用的本地 CUDA 量化引擎。它支援分頁注意力、動態批次處理、提示詞快取、KV 快取去重、批次生成、串流和開放式解碼。要記住的關鍵詞是「本地」。它能讓量化模型在現代 CUDA GPU（尤其是消費級顯卡）上快速運行。
最適合：單張 RTX 3090/4090/5090 主機、本地編碼助手、本地聊天、EXL2 量化模型，以及專業消費者工作站使用。
ExLlamaV3 將這個理念延伸到多 GPU 和 MoE 本地推理。它新增了基於 QTIP 的 EXL3 量化格式、針對消費級硬體的靈活張量平行化和專家平行化推理、透過 TabbyAPI 提供與 OpenAI 相容的伺服器、連續動態批次處理，以及多模態支援。
當你擁有 2-4+ 張消費級 NVIDIA GPU，或者想要本地 MoE 時，V3 就很有吸引力。但需要注意一些警告：有些模型在 ExLlamaV3 中不支援張量或專家平行化。
結論：ExLlamaV2 是發燒友的本地 CUDA 引擎。ExLlamaV3 則是多 GPU（2-4 張）本地系統的前沿選擇。要獲得更好的能力，就得接受它比較粗糙的邊緣。
vLLM：預設的開源生產環境伺服器
vLLM 是大多數團隊在評估嚴肅的開源 LLM 服務時，應該首先考慮的引擎。
它提供了基於 PagedAttention 的 KV 記憶體管理、連續批次處理、分塊預填充、前綴快取、CUDA/HIP graphs、廣泛的量化支援（FP8、MXFP8/MXFP4、NVFP4、INT8、INT4、GPTQ、AWQ、GGUF）、最佳化的注意力與 GEMM/MoE 核、開放式解碼、torch.compile，以及分離式預填充/解碼/編碼。
它也很靈活：支援張量/流水線/資料/專家/上下文平行化、串流、結構化輸出、工具呼叫、與 OpenAI 相容和 Anthropic Messages API、gRPC、多 LoRA，以及對 NVIDIA、AMD、x86/ARM/PowerPC CPU 的支援，此外還有 TPU、Gaudi、Ascend、Apple Silicon 等外掛程式。
vLLM 的文件指出，多節點部署通常使用 Ray，如果沒有 NVLink，流水線平行化可能優於張量平行化。一個常見的陷阱是假設 vLLM 就不需要系統思維了。你仍然需要調整批次處理、上下文長度、GPU 記憶體利用率、平行化佈局和路由。vLLM 給了你一個非常好的引擎，但它仍然需要良好的系統設計。
結論：如果有人說「我們需要在生產環境中服務開源模型」，vLLM 就是預設的起點。
SGLang：vLLM 那個懂系統思維的表親
當服務工作負載變得很棘手時：結構化輸出、長上下文、MoE、分離式架構和路由，你就會找上 SGLang。
它提供了 RadixAttention 前綴快取、預填充-解碼分離、開放式解碼、連續批次處理、分頁注意力、張量/流水線/專家/資料平行化、結構化輸出、分塊預填充，以及多 LoRA 批次處理。它支援 NVIDIA、AMD、Intel Xeon、Google TPU、Ascend NPU 等。
SGLang 的區別在於其服務架構。它的預填充-解碼分離技術將計算密集的預填充和記憶體密集的解碼分配到專門的實例上，並在它們之間傳輸 KV 快取。這可以防止長時間的預填充批次中斷解碼並導致 token 延遲飆升。
結論：SGLang 適合那些瓶頸不再是「我們能跑這個模型嗎？」而是「我們能在高壓流量下運行它，同時不讓延遲、記憶體和成本爆炸嗎？」的團隊。
TensorRT-LLM：NVIDIA 的最大效能
TensorRT-LLM 是 NVIDIA 的效能最大化解決方案。它經過最佳化、專有化、功能強大，而且不假裝自己可以移植。
它提供了 Python API 來建置帶有最先進最佳化的 TensorRT 引擎，以及 Python 和 C++ 運行時。它包含用於注意力、GEMM 和 MoE 的自訂核；預填充-解碼分離、廣義專家平行化、開放式解碼；以及一個與 NVIDIA Dynamo 和 Triton Inference Server 整合的高階 Python API。
B200 GPU 可以使用最佳化的核心來載入 FP4 權重。H100 及後續型號支援 FP8 量化，與 16 位元相比，效能可提升一倍，記憶體消耗可減少一半，且精度損失極小。
它的優勢領域：H100/H200/B200/GB200/GB300 等級的叢集、純 NVIDIA 資料中心、FP8/FP4 部署、多節點服務，以及大規模 MoE。它的劣勢領域：對 AMD、Apple 或 Intel 的可攜性；快速變化的實驗性模型；小型本地設定；以及需要「什麼都能跑」的團隊。
結論：如果你專注於 NVIDIA，並且在意絕對效能，那麼 TensorRT-LLM 值得納入評測。你將用可攜性換取效能。它是經過調校的專化解決方案，但功能較少。
其他引擎
TGI 是 Hugging Face 的生產伺服器，包含追蹤、指標、張量平行化和連續批次處理。當 HF 整合和簡單性很重要時，可以考慮使用它。
MLC LLM 是編譯器優先的通用部署引擎，透過 REST、Python、JavaScript、iOS 和 Android 提供與 OpenAI 相容的 API。最適合「將 LLM 部署到任何地方」，尤其是瀏覽器、行動裝置和原生應用程式。
ONNX Runtime GenAI 在 ONNX Runtime 上實作了完整的生成循環，並驅動 Foundry Local、Windows ML 和 VS Code AI Toolkit。它支援 CPU、CUDA、DirectML、TensorRT-RTX、OpenVINO、QNN、WebGPU 和 AMD GPU。最適合應用程式部署和 ONNX 工作流程。
OpenVINO GenAI 是針對 Intel Xeon CPU、Arc GPU、Core Ultra 和 NPU 的 Intel 最佳化解決方案。它提供與 OpenAI 相容的服務，並具有連續批次處理和分頁注意力。最適合 Intel 硬體。
LMDeploy 是一個 CUDA 為中心的工具包，使用 TurboMind 追求效能，使用 PyTorch 追求易用性。對於想要 vLLM/SGLang/TensorRT-LLM 替代方案的 CUDA 使用者來說，它最有趣。
NVIDIA Dynamo 是一個位於 vLLM、SGLang、TensorRT-LLM 等引擎之上的分散式編排層，支援分離式架構、智慧路由和多層級 KV 快取。當單引擎服務不再足夠時，可以考慮使用它。
注意：不要使用 Ollama。
硬體策略配方
純 CPU 伺服器：首先是 llama.cpp。Intel Xeon 則用 OpenVINO。應用程式/ONNX 部署則用 ONNX Runtime GenAI。
MacBook / Mac Studio：Mac 原生工作流程用 MLX / MLX-LM。GGUF 可攜性則用 llama.cpp。
單張 RTX 3090 / 4090 / 5090：EXL2 本地推理用 ExLlamaV2。GGUF 或可攜性則用 llama.cpp。如果要服務多名使用者，則用 vLLM。
雙卡或四卡消費級 RTX 主機：多 GPU 量化推理或 MoE 用 ExLlamaV3。如果服務行為很重要的話，用 vLLM。如果要測試路由或長上下文模式，用 SGLang。
8×H100 / H200 節點：從 vLLM 或 SGLang 開始。如果是純 NVIDIA 環境且效能值得調校，則對 TensorRT-LLM 進行基準測試。當需要多節點編排時，使用 Dynamo。
B200 / GB200 / GB300 等級基礎設施：對 TensorRT-LLM、SGLang 和 vLLM 進行基準測試。新增 Dynamo 用於叢集級編排、KV 感知路由和自動擴展。
AMD MI300 / MI325 / MI350 / MI355：在 ROCm 上從 vLLM 或 SGLang 開始。避免假設 NVIDIA 的基準測試結果可以直接套用。
Intel Xeon / Core Ultra / Arc：OpenVINO GenAI 或 OpenVINO Model Server。如果需要嵌入應用程式，則用 ONNX Runtime GenAI。
瀏覽器、行動裝置、應用程式原生：MLC LLM / WebLLM 或 ONNX Runtime GenAI。
基準測試：要測量什麼
糟糕的基準測試：「我得到了 180 tok/s。」
好的基準測試包含：
模型：確切模型、架構、參數數量、活躍 MoE 參數。
權重：資料類型、量化格式、分組大小、校準方式。
引擎：版本、提交號碼、後端、標誌。
硬體：GPU SKU、記憶體容量、頻寬、互連架構、CPU、RAM。
工作負載：輸入/輸出長度分佈、並發數、串流、共享前綴、結構化輸出。
指標：TTFT、TPOT、端到端延遲、p50/p95/p99、每秒 token 數、每秒請求數、GPU 記憶體使用量、KV 快取命中率、預填充吞吐量、解碼吞吐量、每 1M token 的成本。
基準測試規則：
- 永遠不要只使用單一使用者的每秒 token 數來比較引擎。
- 測試你實際的提示詞和輸出分佈。
- 使用實際的並發數進行測試。
- 將預填充和解碼分開。
- 追蹤 p95 和 p99，而不只是平均值。
- 在目標上下文長度下測量記憶體餘量。
- 如果你的應用程式有重複的前綴，請測試快取重用。
- 單獨對結構化輸出進行基準測試；語法約束會增加開銷。
- 單獨對 LoRA 和多 LoRA 進行基準測試。
- 在驅動程式、CUDA、ROCm、模型或引擎升級後重新測試。
常見錯誤
僅憑 VRAM 容量做選擇。VRAM 決定能否容納。頻寬和排程器決定速度。一台大統一記憶體的機器可以容納巨大的模型，但當模型容納得下時，H100 因為擁有高得多的 HBM 頻寬，解碼速度更快。
在弱互連上使用張量平行化。如果沒有 NVLink 或 NVSwitch，請測試流水線平行化。vLLM 的文件針對 L40S 這類設定指出了這一點。
忽略 KV 快取。長上下文和並發性可能使 KV 快取成為限制因素。在大規模場景下，PagedAttention、前綴快取、KV 量化和分離式架構都不是可選項。
將本地引擎當作生產伺服器對待。llama.cpp 伺服器功能強大。MLX-LM 伺服器很方便。Ollama 用起來很愉快，但不應該使用。
然而，生產環境意味著安全性、可觀測性、背壓、路由、自動擴展和 SLA 行為。MLX-LM 本身也警告其伺服器不建議用於生產環境。
假設每種量化格式都可以移植。GGUF、EXL2、EXL3、AWQ、GPTQ、FP8、FP4、MLX 格式和 ONNX 並不能互換。正確的格式是你的引擎具有最佳化核心的那一種。
忽略模型架構。密集模型、MoE、混合注意力、多模態模型和長上下文變體會對引擎的不同部分造成壓力。廣泛的支援並不意味著每種最佳化都能同樣有效。
相信沒有附帶工作負載形狀的基準測試圖表。一個針對 Llama 3.1 8B 在 1K 輸入 / 128 輸出下的圖表，幾乎無法說明一個使用 Qwen 3.6 27B / Gemma 4 26B-A4B、處理 80K 上下文的編碼 Agent，或是一個有 500 個並發使用者的 RAG 服務的情況。
最終主觀建議地圖
本地 AI 使用者：為了方便，使用 LM Studio 或 Harbor。為了控制性，使用 llama.cpp。Mac 上用 MLX。追求 CUDA 本地效能則用 ExLlamaV2/V3。
建構本地 Agent：任何引擎應該都可以，但考量到大多數人的用法；可攜性選 llama.cpp。如果使用者在 Apple Silicon 上，選 MLX。如果要在本地模擬生產環境服務，選 vLLM。
為內部團隊提供服務：從 vLLM 開始。如果結構化輸出、長上下文、多 LoRA、MoE 或路由很重要的話，使用 SGLang。
為客戶提供大規模服務：對 vLLM、SGLang 和 TensorRT-LLM 進行基準測試。如果路由和分離式架構很重要，SGLang 和 Dynamo 值得關注。
NVIDIA 資料中心：追求最大效能用 TensorRT-LLM。追求靈活性用 vLLM。處理複雜服務用 SGLang。叢集編排用 Dynamo。
Apple Silicon：原生開發用 MLX。GGUF 則用 llama.cpp。統一記憶體是一個容量上的超級強項，但附帶了頻寬上的權衡，它並非 HBM。
邊緣運算、應用程式、瀏覽器或 Windows 原生：根據你的技術堆疊，選擇 llama.cpp、MLC LLM、ONNX Runtime GenAI 或 OpenVINO。
最終原則
推理引擎的選擇會帶來後果。
在回答了以下問題後再選擇引擎：
- 我實際上有什麼硬體？
- 模型能放進快速記憶體，還是只能放進系統/統一記憶體？
- 瓶頸是解碼還是預填充？
- 需要考慮什麼樣的上下文長度和並發數？
- 提示詞是否有足夠的共享性，能夠使用前綴快取？
- 模型是密集的、MoE、多模態的，還是混合的？
- 我需要本地便利性、生產環境服務，還是叢集編排？
- 在目標引擎上，哪種量化格式有最佳化的核心？
- 我的互連架構是 PCIe、NVLink、NVSwitch、Ethernet、RDMA 還是 Thunderbolt？
- 我正在最佳化延遲、吞吐量、成本、隱私、可攜性，還是開發速度？
引擎會跟隨答案而決定。
下次再見。
- Ahmad
