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 這張表能先縮小範圍，但實際要不要選它，建議還是要經過邏輯判斷與測試。