第 11 章 — 平台與編排層

《LLM Primer VI:擴展 AI 系統》章節走讀的第十一篇。這一章主張平台的選擇不是關於功能,而是關於哪一種維運模式對得上團隊既有的維運文化。

這一章為什麼存在

引擎把一顆模型包在一顆 GPU 上並產出 token。這就是它完整的工作描述。當生產環境需要在負載平衡器後面放兩個副本、或需要在一個端點下面放兩個不同引擎、或需要一條把 embed→retrieve→rerank→generate 當作單一邏輯呼叫的管線、或需要一個防止某租戶餓死另一租戶的配額系統、或需要一個隨佇列深度上升而增加副本的自動擴縮器 — 引擎就用完答案了。第 11 章走過 2026 年主宰那份工作的四個平台 — Ray Serve、KServe、BentoML、Triton Inference Server — 並主張它們之間的選擇是關於團隊維運文化契合度的問題,不是關於功能的問題。

11.1 Ray Serve 是 Python 優先;KServe 是 Kubernetes 優先

Ray Serve 是這樣一個平台:當出發問題是「如果我永遠不用離開 Python 就能組合、擴展、部署一條模型管線,那服務框架會長什麼樣?」時,浮現出來的答案。答案是被標成 actor 的 Python 類別,用 Python 函式呼叫串在一起,由 Ray runtime 負責複製、放置、自動擴縮。Deployment 之間靠互相呼叫方法組成管線;管線是 Python、可觀測性是 Python、維運故事也是 Python。當同一個叢集已經在跑 Ray 做訓練時,它就是自然的選擇。KServe 從相反的出發點浮現:Kubernetes 優先、廠商中立、宣告式。一個 KServe InferenceService 是一個 CRD,捕捉權重放哪裡、由哪個 runtime 提供服務、自動擴縮該怎麼運作。平台透過 Knative 完成 scale-to-zero、透過 Istio 完成流量路由,並對外提供一個穩定的 HTTP 端點。取捨是表達力 — 在 KServe 裡組管線比 Ray Serve 更靠 YAML — 換來可攜性與標準化。

11.2 BentoML 做打包;Triton 對異質模型做批次

BentoML 站在第三個立場:平台的第一份工作是把模型 + 程式碼 + 依賴包成一份連貫的產物 — 一個 Bento — 並讓把那份產物部署到任何地方(Kubernetes、Lambda、Cloud Run、裸機 VM)成為一鍵操作。它之於模型服務層,就像 Docker 映像檔之於一般應用程式。撰寫體驗是 FastAPI 形狀的 Python;部署故事是「先做產物」的動作。最佳契合是小型維運足跡、以及想要從「Python 類別」到「能在任何地方跑的部署端點」最短路徑的團隊。Triton Inference Server 是企業級的動態批次器,歷史上主宰了與 NVIDIA 對齊的服務。它同時 host TensorFlow、PyTorch、ONNX、TensorRT、TensorRT-LLM、以及 Python backend,對非 LLM 工作量(推薦、分類、embedding)套用動態批次,對 LLM 則在它的 TensorRT-LLM backend 底下用連續批次排程。最佳契合是異質工作量,或是已經深度使用 NVIDIA 堆疊的團隊。

11.3 四項選擇按維運文化契合度分區

四個平台切得很清楚。Python 與 Ray 是重心 → Ray Serve。Kubernetes、宣告式 manifest、多雲可攜、多租戶隔離 → KServe。小型維運足跡、從類別到端點最短路徑 → BentoML。異質工作量或 NVIDIA 優先的公司 → Triton。它們不是組織層面上互斥的:大型組織裡常見的樣式是,最高流量的生產 LLM 用 Triton、組多模型呼叫的 RAG 與代理管線用 Ray Serve、KServe 當作強制多租戶的傘、開發者環境裡則放 BentoML。挑的時候有一個實用的做法:列出團隊絕對需要的三個維運性質、以及絕對可以放棄的三個,再拿平台去對這份清單排名。抗拒那個「什麼都支援」的平台 — 每個平台都把它的核心做得好、把周邊做得差,而核心跟必需項重疊的那個,才是團隊會覺得好用的。

第 11 章鋪陳出來的東西

當副本的單位是「一個 pod 在一個 GPU 節點上擁有一顆模型」時,引擎/平台的界線很乾淨。當我們尊重第 1 章那個「prefill 與 decode 是相反工作量」的事實時,它就不再乾淨。第 12 章把它們拆到不同的 GPU 池,把 KV 快取透過網路架構在池與池之間搬運,並以 Kubernetes 原語表達那個切分 — LeaderWorkerSet、Grove 的 PodCliqueSet、KAI Scheduler 的拓樸感知。平台層是讓那個切分變得可維運的東西;平台層是讓那個切分變得可表達的原因。

下一篇 — 第 12 章:解耦式服務與 Kubernetes。把 prefill 與 decode 拆到不同的 pod,以及表達那個切分的 Kubernetes 原語。