2026 LLM Serving Stack 選型指南：從推論引擎到 AI Gateway 的架構視角

2026 年如果要部署 LLM，大部分人最後都會碰到同一個問題：到底該選什麼推論引擎是 vLLM、SGLang 還是 TensorRT-LLM？

在實際部署 OCR、VLM、Agent 與多模型服務之後，我發現真正困難的不是「哪個引擎最快」，而是當模型數量增加、需求改變、團隊需要維護時，這套 Serving Stack 是否能穩定運作。真正的 Production AI 早就不是「單一推論引擎」的選擇，而是一整個 Serving Stack——從底層的推論引擎，到分散式編排，再到最上面的 AI Gateway，每一層都會影響最終的效能、成本與可維運性。

這篇先把整個 Stack 的骨架跟選型方法論建起來——KV Cache 管理、Benchmark 細節、Orchestration 深入比較不會在這篇展開，這篇先彙整需要的骨架跟判斷順序。

TL;DR(Too Long; Didn’t Read)：懶人包
#

先給結論，層級怎麼分下面會有：

情境	選項
CPU／Apple Silicon／邊緣	llama.cpp
快速驗證、Demo、個人使用	Ollama
通用高併發 Production 服務	vLLM
Agent／高 Prefix 重複率	SGLang
固定模型、極致 NVIDIA 效能	TensorRT-LLM
多節點編排、Autoscaling 需求	Dynamo／Ray Serve
多供應商路由、金鑰治理	LiteLLM／Kong

這張表能先縮小範圍，但實際要不要選它，建議還是要經過邏輯判斷與測試。

Serving Stack 四個核心層級
#

正式 Serving 路徑上有四個核心層級，由下往上：硬體（GPU／Accelerator）→ 推論引擎（把單一模型跑得快、跑得省）→ 分散式編排（叢集級的擴展與調度）→ AI Gateway（統一入口與治理）。Ollama、LM Studio 這類工具在旁邊，是開發階段快速驗證用的，不在正式 Serving 路徑上。

企業真實環境的問題，很少是「我該用哪個 Engine」，更多是「我該怎麼管理 20 個模型、5 個團隊、3 個供應商」——那是上面兩層的事。這篇會由下往上，一層一層講。

推論引擎選型：vLLM／SGLang／TensorRT-LLM
#

評估推論引擎時，不應只看 Tokens/s。下圖先拆解一個請求的完整生命週期，再說明 Raw Throughput 跟 Goodput 為什麼會給出不同結論：

圖裡把「送出請求」到「拿到第一個字」拆成四段：送出 → 排隊（Queueing）→ 斷詞（Tokenize）→ Prefill。TTFT 量的是這整段時間，不是只有 Prefill。所以看到 TTFT 變高，別急著怪 Prefill Kernel 算得慢——很可能是請求卡在排隊，伺服器同時有太多請求在等，你的請求根本還沒開始算。先拆開看卡在哪一段，才知道問題出在哪。

拿到第一個字之後，後面逐字往外吐（Decode），字跟字之間的間隔就是 ITL。這跟 TTFT 量的不是同一個階段——TTFT 是「等第一個字多久」，ITL 是「字跟字之間隔多久」。

Goodput 則是另一件事。假設你定了一個規則：TTFT 要低於 2 秒才算一個「有效」的請求。系統 A 每秒能吐 2,000 個字，但只有 60% 的請求 TTFT 在 2 秒內；系統 B 每秒只能吐 1,700 個字，卻有 95% 的請求符合門檻。單看「每秒吐幾個字」，A 贏；但如果在意的是「有多少使用者真正得到好體驗」，B 贏——因為 B 有 95% 的請求是有效的，A 只有 60%。Goodput 就是只算這些「有效請求」的吞吐量，不是全部吞吐量。Production 場景該看 Goodput，因為它反映的是「真正服務了多少人」，不是機器空轉跑出來的漂亮數字。

再加上 KV Cache 管理方式（直接決定可容納的併發數）跟 Model Compatibility（模型「能啟動」不代表走在最佳化路徑上，可能退回 Transformers Backend），這五項才是評估的完整拼圖——單看其中一項都不夠。

有了這五項標準，接下來的問題是：那目前有哪些可以拿來評估？2026 年剛好經歷了一次明顯的洗牌——Hugging Face 已將 TGI 轉為 Maintenance Mode，建議優先評估 vLLM、SGLang，以及 llama.cpp、MLX。下表是常見選項的快速對照——它們不完全位於同一抽象層，不是嚴格的同層比較：

工具／引擎	核心定位	適合場景	主要注意事項
vLLM	通用型 Production Inference Engine	單模型高併發 API、長上下文、廣泛硬體支援	多個 Base Model 需要多 Instance 與外部路由
SGLang	高效能通用 Serving Engine	高併發服務，重複 Prefix、Agent、分支推理額外加分	RadixAttention 收益依 Prefix 重複率
TensorRT-LLM	NVIDIA GPU 深度最佳化，PyTorch 與編譯式 Engine 兩條路徑	固定模型、深度調校	編譯式 Engine 建置與版本管理成本較高
LMDeploy	TurboMind 與 PyTorch 雙引擎	NVIDIA GPU、LLM／VLM 效能實驗	不同模型在兩套引擎支援程度不同
Ollama	簡化本地模型管理	開發、Demo、快速驗證	Production 調度需額外設計
llama.cpp	輕量與跨硬體推論	CPU、Apple Silicon、邊緣、GGUF 模型	高併發 GPU Serving 非主要定位

補充些常見誤解：SGLang 不是只在重複 Prefix 場景才有用，它是一套完整的通用 Serving Engine。另一個更常見的誤解是把 PagedAttention 跟 RadixAttention 當成互斥技術，直接寫成「vLLM = PagedAttention、SGLang = RadixAttention」拿來 PK。這是錯的——KV Cache 管理是 2026 推論引擎競爭的核心之一，但這兩個技術解決的是完全不同層次的問題（KV Cache 的實體配置 vs. 已計算 Cache 的 Prefix 重用），而且兩邊框架其實都同時具備這兩層能力，不是二選一。

一套可執行的選型流程
#

前面是介紹，這裡是方法論——能參考使用比較重要。

Step 1：先排除不能用的方案。 這一步不是列清單，是每個維度都要問「為什麼它會刷掉選項」：

模型型態要查框架 Supported Models 清單時，找的是模型 config.json 裡的 architectures 欄位（例如 Qwen3VLForConditionalGeneration），這是模型精確的類別名稱，不是「Qwen3」這種泛稱系列名。如果沒有，代表要嘛直接不支援，要嘛會退到通用的 Transformers Backend 硬跑——表面上能用，但沒走到該有的最佳化路徑，速度會差一截。這種「能啟動但沒吃到優化」的狀況，是模型部署時最容易被忽略、卻最花時間排查的一種坑。

精度與量化格式最容易被忽略的是「格式支援但沒加速」：FP8 要真的跑得快，GPU 硬體本身要有對應的運算電路，通常得是 Hopper 架構以上（例如 H100）。舊卡（例如 Ampere 架構的 A100）即使框架讓你把 FP8 模型載入、跑起來也沒報錯，實際上背後可能是軟體模擬湊出結果，不是硬體真的加速——省了記憶體，但沒有換到速度。

容量是唯一能真的算出數字的一項，靠三條公式。先算可用預算，扣掉系統跟每個服務啟動的固定消耗，剩下才是真正能分配的空間：

1
可用預算 = 總記憶體 − OS 保留 − (服務數 × process 開銷)

再確認東西塞不塞得下：

1
模型權重 + KV Cache + Activation ≤ 可用預算

KV Cache 大小可以先用這個公式抓量級：

1
KV Cache 大小 = 2 × 層數 × KV heads 數 × head_dim × dtype 位元組數 × 上下文長度 × 併發數

這串公式在算的是「每個 Token 要存多少 Key/Value 資料，乘上同時要處理多少 Token、多少個並行請求」。

舉個例子：一張 80GB 的 GPU，跑三個服務，OS 保留 4GB、每個服務啟動開銷約 1GB：

1
可用預算 = 80 − 4 − (3 × 1) = 73GB

要放一個 14B 模型（FP8 量化後權重約 14GB），Activation 抓 2GB，上下文長度 8192、要撐 16 個併發請求，40 層、8 個 KV heads、head_dim 128、FP16 儲存（2 bytes）：

1
KV Cache 大小 = 2 × 40 × 8 × 128 × 2 × 8192 × 16 ≈ 20GB

三項加起來：14 + 2 + 20 = 36GB，遠低於 73GB 的可用預算，還有餘裕。如果這個數字算出來已經超過可用預算，代表這個模型／量化組合在這張卡上放不下，直接淘汰，不用等到實際部署才發現。

這五項的共同點：每一項都有明確可查、可算的判準，不是憑感覺篩，做完這一步通常已經刪掉一半以上的選項。

Step 2：建立 Workload Profile。 固定 Input／Output 長度分布、Prefix 重複率、多模態比例、模型數量，以及負載模型（Closed-loop 固定併發，或 Open-loop 固定到達率——兩者的 Queueing 行為差很多）。沒有這份 Profile，後面的 Benchmark 數字都沒意義。

Step 3：先定服務品質門檻，再設容量目標。 例如 P95 TTFT < 2 秒、End-to-End Error Rate < 0.1%，符合這些條件下再要求 Goodput 達標。先定義「怎樣算一個有效請求」，才能判斷有效容量夠不夠。

Step 4：同條件 Benchmark。 相同模型、量化、Dataset、上下文、硬體、Warm-up、併發設定，至少重複三次。條件不一致的 Benchmark 不能比。

Step 5：計算營運成本。 除了速度，也比每百萬 Token 成本、GPU 使用率、模型升級時間、監控完整度，以及團隊維運能力。跑得快但沒人維護得動的方案，長期不會留下來。

如果只想快速縮小範圍，這張圖是簡化版判斷邏輯：先看跑在哪裡、要不要高併發、Prefix 重複率、要不要跨節點治理。但先測誰不等於最後選誰——圖只是把候選名單從十個縮到兩個，Benchmark 才是從兩個選一個。

往上一層：Orchestration 與 AI Gateway
#

前面的選型流程都停在推論引擎這一層。往上還有兩層，這裡只建立概念，不深入展開：

Engine ＝跑模型。 推論引擎負責把單一模型跑得快、跑得省——vLLM、SGLang、TensorRT-LLM 都在這層。
Orchestration ＝管理模型服務。 如果把 vLLM 視為 AI Runtime，Dynamo、Ray Serve 解決的是 Runtime 之上的服務治理：Replica 管理、跨模型的 Routing、Autoscaling、故障恢復。
Gateway ＝治理模型入口。 不只是 API Proxy，而是企業 AI 的控制平面，負責身份、成本、路由與跨供應商治理——LiteLLM、Kong、Portkey、Cloudflare AI Gateway 都在這層。這一層也是企業導入時最容易忽略安全模型的地方，選型不能只看功能。

我越來越少只測試「誰最快」
#

我越來越少著重「誰最快」，而越來越常探討「誰能留下來」。一個推論引擎如果只有 Benchmark 漂亮，卻無法處理模型升級、容量規劃、權限治理與團隊交接，那它解決的只是今天的問題。Production 系統真正的成本，往往不是發生在選型當下，而是部署完成之後——這些都不會出現在任何一張跑分表上，卻是系統能不能活過一年的關鍵。

Benchmark 選不出 Production 系統。真正決定系統壽命的，往往是模型升級、容量治理與團隊接手之後的那六個月。所以這整篇沒有辦法給出「最強框架」，因為那個問題本身就問錯了——真正該問的是：在我的硬體、我的 Workload、我的 SLO、我的團隊維運能力下，哪一套組合能穩定跑到明年，而且換人接手還能理解。Build to last, not to demo，講的就是這件事。

TL;DR(Too Long; Didn’t Read)：懶人包#

Serving Stack 四個核心層級#

推論引擎選型：vLLM／SGLang／TensorRT-LLM#

一套可執行的選型流程#

往上一層：Orchestration 與 AI Gateway#

我越來越少只測試「誰最快」#

參考資料#