第 12 章 — 解耦式服務與 Kubernetes

發佈於: 2026-05-04 最後更新於: 2026-07-08 版本: 1
第 12 章 — 解耦式服務與 Kubernetes

第 12 章 — 解耦式服務與 Kubernetes

LLM Primer VI:擴展 AI 系統》章節走讀的第十二篇。這一章終於把 prefill 與 decode 拆到不同的 GPU 池,並展示能把 pod 留在互連正確一側的 Kubernetes 原語。


這一章為什麼存在

第 11 章在引擎與平台之間畫了一條乾淨的線 — 直到引擎自己指出 prefill 與 decode 是相反的工作量。Prefill 受制於運算;decode 受制於記憶體頻寬。讓它們在同一顆 GPU 上跑,等於強迫一顆硬體同時把兩件相反的事情做好,結果是它兩件事都做得平庸。解耦式服務把它們拆到不同的 GPU 池,把 KV 快取在池與池之間搬運,並讓每個池為自己的工作量做調校。代價是維運複雜度,以 Kubernetes 原語、pod 拓樸、以及承載 KV 流量的網路架構來付。第 12 章走過那個複雜度的形狀 — 元件、傳輸路徑,以及表達它的 CRD(LeaderWorkerSet、Grove 的 PodCliqueSet、KAI Scheduler)。

一句話總結:解耦把一個平庸的 GPU 池變成兩個各自調校得好的池,代價是要在嚴格的 TTFT 預算內、透過 NVLink 或 InfiniBand 把 KV 快取(通常每個序列幾個 GB)搬過去。

12.1 Prefill 與 decode 要的是不同時脈下的不同晶片

在同一顆 H100 上,一段長的 prefill 可以真的跑到峰值 FLOPs 的 60 到 80%,而一步 decode 只用 5 到 15% 的 FLOPs,卻飽和 70 到 90% 的 HBM 頻寬。在連續批次下把它們交錯是可行的折衷,但會在兩個地方漏水。Prefill 的運算傳遞會撞到 decode 在排隊等著串流的 HBM 匯流排,token 間時間會膨脹。這張卡也只跑在一個運作點:調成偏 prefill 就 decode 頻寬受限,調成偏 decode 就 prefill 運算受限。隨著 RAG 與代理在生產流量佔比上升,提示詞從幾百個 token 變到幾千個,交錯的成本也跟著長。解耦讓每個階段有自己的池。Prefill worker 可以跑在裸 FLOPs 卡(H100 SXM、B200)。Decode worker 可以跑在容量與頻寬卡(H200、MI300X)。每個池按自己的工作量調大小 — 長上下文、短輸出的流量需要更多 prefill;聊天流量需要更多 decode。

12.2 形狀是四個元件加上一條 KV 傳輸路徑

一份可運作的解耦式部署有四個元件。Prefill worker 接受請求、計算 prefill、吐出第一個 token,並把 KV 快取準備好等傳輸。Decode worker 接收送進來的 KV 快取與它的 metadata、把它裝進自己的分頁式注意力池、並對在飛的生成跑連續批次。KV cache router — 控制平面 — 維護一份對每個 decode worker 剩餘 KV 容量、批次飽和度、網路地緣性的視圖,並指派每筆 prefill 的輸出,以最小化傳輸成本、平衡負載。前端 gateway 終止使用者的 HTTP 連線、從 prefill worker 串流第一個 token,再透明地切換到從 decode worker 串流其餘。關鍵限制是 KV 傳輸:一個 70B GQA 序列在 4,096 個 token 是 1.5 到 2 GB,而它得在使用者盯著的同一份 50 到 100 ms TTFT 預算內從 prefill 節點搬到 decode 節點。節點內的 NVLink 是 900 GB/s、節點間的 InfiniBand 是 400 Gb/s,可以撐得起這些數字 — 前提是pod 落在架構正確的那一側。

12.3 LeaderWorkerSet、Grove、KAI 表達拓樸

Kubernetes 原本沒有原語能表達「這兩個型別不同的 pod 是同一個邏輯副本」。LeaderWorkerSet 在 2024 年進到上游,能表達一個多 pod 的副本,其中有一個 leader(比方說 prefill)與若干 worker(比方說 decode);controller 會把整組維持成一個排程單位。NVIDIA Grove 的 PodCliqueSet(2025,是 NVIDIA AI Enterprise 的一部分)進一步一般化:有型別的 clique(prefill、decode、router),每一個都有自己的樣板與大小,再加上描述 clique 之間關係的 clique-topology。Grove 把整組跟 clique 內與 clique 間的地緣性限制一起送給排程器。這兩個 CRD 各自都不夠用;它們都需要一個懂叢集實體拓樸的排程器,而 Kubernetes 預設排程器不懂。KAI Scheduler — 2024 年從 Run:ai 開源出來的 — 消化由 nvidia-smi topo --matrix 與 InfiniBand subnet manager 產出的拓樸圖,並拿候選放置去對它打分。當一個 Grove clique 要求 nvlinkDomain: required 時,KAI 會把放置限制在單一 NVLink 相干域(HGX 底盤上、一個 NVSwitch 底下的八顆 GPU)。當 clique 間拓樸寫 sameInfiniBandIsland 時,KAI 會把那些 clique 留在同一個 leaf switch 群組裡,讓 KV 往返時間留在 100 μs 以內。

值得記住:沒有拓樸感知排程的解耦,比不解耦還糟。如果 KV 傳輸穿過錯的交換器,TTFT 預算就會消失在網路抖動裡,運維者只把切分的複雜度扛下、卻沒抓到它的吞吐量。

第 12 章鋪陳出來的東西

第 12 章給部署一張靜態的圖:任何時刻,有固定數量的 clique 在跑並服務流量。真實流量不是靜態的 — 聊天助理一天內尖峰對比谷底可以差 30 倍、開發者工具週末歸零、消費性產品追著太陽跑。第 13 章走自動擴縮的故事:為什麼標準的 HPA 對 LLM 服務是錯的擴縮器、KEDA 拿什麼訊號來擴、Knative 如何表達 scale-to-zero,以及要把 60 到 180 秒的冷啟動壓成使用者取向應用能吸收的長度需要什麼。


下一篇 — 第 13 章:自動擴縮與冷啟動緩解KEDA、Knative、CRIU、CUDA graph 快取、NVMe — 讓 scale-to-zero 跟真實使用者共存的堆疊。

想看完整的全貌?書中章節包含完整 Llama-70B 解耦部署的 LeaderWorkerSet 與 Grove YAML、KAI 的拓樸設定區塊、Python router 決策函式、跨四個元件的端到端請求追蹤,以及多模型、多租戶 clique 的說明。在 Amazon 查看 LLM Primer VI →

下田 昌平
下田 昌平
RECEIPTROLLER 的 CTO 與創辦人。專注於數據、驅動創新、始終保持好奇心。