第 10 章 — LLM 引擎層

《LLM Primer VI:擴展 AI 系統》章節走讀的第十篇。這一章替引擎與平台之間的界線命名,並走過 2026 年主宰那一層的五個引擎。

這一章為什麼存在

第 1 到 9 章走過了單一次前向傳遞會觸及的機械:自回歸迴圈、KV 快取、GPU 底層、把它縮小的量化、把它閒置時間藏起來的批次處理、以及打破它循序依賴的推測解碼。這些沒有任何一項是 pip install 就能忘掉的函式庫。有人把它們拼進一個單節點執行期裡,那個執行期包住一顆模型、擁有 KV 快取、把請求排進一個連續批次、對外提供推論 API。那個執行期就是引擎。第 10 章替引擎層的職責命名、把它跟平台層(第 11 章)區分開來,並走過在同一份工作上做出不同機械取捨的五個引擎 — vLLM、TensorRT-LLM、SGLang、TGI、Ollama。

10.1 vLLM 是 Python 原生的預設

大多數生產團隊第一個伸手該拿的引擎是 vLLM,因為在初學者不知道該怎麼想的每一個維度上,它都做出了對的預設決定,而且是用 Python 做的。PagedAttention 讓碎裂化從 60 到 80% 掉到個位數,大約在同一顆 GPU 上讓可達批次翻一倍。連續批次自然地疊上去,chunked prefill 把 prefill 與 decode 工作混在同一次迭代裡,兩者之間的界線不再是死時間。從 block table 的設計裡自然衍生出免費的 copy-on-write 前綴共享。介面真的是幾行程式碼就能做到離線批次或 OpenAI 相容的 HTTP,而且每個新的模型架構因為社群夠廣,都很快就會落地。當運維者沒有特別理由挑別的東西時,這就是可以拿來標準化的引擎。

10.2 TensorRT-LLM 用建置管線買吞吐量

TensorRT-LLM 的訴求很狹窄。如果機群清一色 NVIDIA、每個百分點的每美元吞吐量都算、而且團隊願意付一份工程稅去替每個硬體世代編譯模型專屬的 engine 檔案,TRT-LLM 在同一顆硬體上比 vLLM 多榨 15 到 35% 的吞吐量。機制在 kernel 層級:把 transformer 圖降到 NVIDIA 專用 IR、融合相鄰 kernel(把 layernorm + matmul + activation 融進一次啟動)、從一組預先調校過的 kernel 庫裡替每個形狀挑最佳、產生一份序列化 engine、在 Triton Inference Server 底下跑。融合很重要,因為 kernel 啟動開銷每次 5 到 10 μs,天真的 70B 前向傳遞每個 token 就會派出好幾千個。稅則是建置管線本身 — 每個模型、每個 GPU、每個批次區間都要編譯,大多數團隊低估了這個維運成本。SGLang 是另一種特化:RadixAttention 把引擎看過的每一段前綴 KV 存進 radix tree,所以兩個共用 k 個 token 前綴的請求會在跨批次與跨時間之間精確共用那 k 個 token 的 KV。在有長共用系統提示詞、短變體後綴的代理式工作量上,SGLang 比 vLLM 的吞吐量高 2 到 6 倍,而且它的結構化輸出 DSL 在 logit 層強制執行 JSON schema,輸出必然通過驗證。

10.3 決策樹走的是工作量形狀,不是頭條吞吐量

五個引擎在一棵小決策樹上分出去。開發者筆電或帶著混合加速器的邊緣 → Ollama。生產 GPU 機群、清一色 NVIDIA、高 QPS、吞吐量的 ROI 抵得住建置管線 → TensorRT-LLM。混合硬體或頻繁換模型,工作量以前綴為主的結構化樣式為多數(代理、工具呼叫、長共用提示詞)→ SGLang。混合硬體、一般聊天工作量、深度整合 Hugging Face → TGI。其他都是 → vLLM。這個決定不是永久的:引擎在 API 邊界上可以互換 — 都講 OpenAI 風格的 HTTP — 所以平台層的路由器可以隨著模型、工作量、或區域轉移流量,不用改客戶端程式碼。許多生產堆疊同時跑兩三個引擎。小心頭條跑分:「Llama-2-7B 在批次 1 的 tokens per second」回答的是任何生產工作量都不會問的問題。用你自己的模型、自己的提示詞分布、自己的並行輪廓來跑 — 花半天,省好幾個月。

第 10 章鋪陳出來的東西

這一章描述的每個引擎都停在同一條邊界上。它懂 kernel、KV 區塊、連續批次;它不懂副本、租戶、串接、認證。第 11 章走過處理這些關心的平台層 — Ray Serve、KServe、BentoML、Triton Inference Server — 並顯示這項選擇更多不是關於功能,而是關於哪一種維運模式對得上團隊既有的基礎設施與能力。

下一篇 — 第 11 章:平台與編排層。Ray Serve、KServe、BentoML、Triton — 站在引擎之上的四個平台,以維運文化契合度來挑。