SOSP 的 Session 1A 開場就是 Model Serving at Scale這個安排本身就很能說明問題。這幾年我和團隊一直在做 LLM 推理服務化眼看著這個方向從AI 實驗室里的小工具變成了真正意義上的系統(tǒng)軟件——調度、緩存、資源池化、故障恢復每一個話題都回到了操作系統(tǒng)研究的老本行。這個 Session 值得逐篇細看不只是因為論文本身而是因為它集中展示了整個行業(yè)在規(guī)?；渴鸫竽Ｐ屯评頃r的真實瓶頸和解決思路。這篇文章我按自己的理解把 Session 1A 的幾條主線拆開講包含對系統(tǒng)設計的分析、對工程落地的思考以及我自己在部署過程中踩過的坑。如果你也在做模型服務化或者正準備上手搭推理平臺這些內容應該能幫你省不少時間。1. 為什么 Model Serving at Scale 值得單獨開一場先把背景說清楚。SOSP 一直是以操作系統(tǒng)、存儲、分布式系統(tǒng)見長的頂會往年這類會議上的工作大多是文件系統(tǒng)、內存管理、一致性協(xié)議。現(xiàn)在 Model Serving 能占一個 Session說明學術界已經(jīng)達成了一個共識大模型推理瓶頸不再是模型精度而是系統(tǒng)效率。1.1 從跑通模型到規(guī)?；盏霓D折過去一年里行業(yè)里能穩(wěn)定對外提供大模型推理服務的團隊基本都遇到了相同的問題。單機單卡跑一個 7B 模型很容易但一旦要支持幾百路并發(fā)請求、上下文長度動輒幾十 k token、還有嚴格的響應時間要求問題立刻變成資源調度問題。GPU 顯存怎么分、請求怎么排隊、cache 怎么復用、負載怎么均衡這些都不是 PyTorch 或者 Transformer 庫能解決的。Session 1A 里的工作本質上就是在回答一個問題當模型推理變成基礎服務操作系統(tǒng)的那套方法論——調度、緩存、隔離、容錯——要怎么遷移到 GPU 上。1.2 這個 Session 的三條核心主線我把分場論文歸納成三個方向方便理解。調度與批處理解決怎么讓 GPU 一直有事干。連續(xù)批處理、chunked prefill、請求級優(yōu)先級這些都是圍繞吞吐和延遲的博弈。狀態(tài)管理解決KV Cache 放哪里、怎么復用。涉及顯存管理、跨請求復用、緩存淘汰策略。資源池化解決多 GPU、多節(jié)點如何協(xié)同。包括 prefill/decode 分離、異構調度、彈性伸縮。這三條線不是孤立的好的系統(tǒng)設計通常同時處理多個問題。后面我逐個展開。2. 全景拆解Session 1A 的四條技術主線這一節(jié)把分場的內容按主題做一個總覽。如果你只想要一個速覽結論今年的模型服務研究已經(jīng)從單卡優(yōu)化全面轉向集群協(xié)同所有論文都在試圖打破單機資源上限。2.1 主線一調度與批處理調度是模型服務系統(tǒng)的心臟。早期推理服務用靜態(tài)批處理請求來了先湊一批再一起算延遲高、利用率低。vLLM 提出的 PagedAttention 是一次突破但它解決的是顯存管理問題真正讓吞吐大幅提升的是連續(xù)批處理continuous batching——每個 step 動態(tài)決定哪些請求進入計算不用等整批結束。今年的論文在連續(xù)批處理基礎上又往前走了一步。請求級搶占、優(yōu)先級隊列、prefill 分塊調度這些都是為了讓調度器有更細的控制粒度。我的看法是未來的調度器會越來越像 CPU 調度器只是時間片換成了 token 計算步。2.2 主線二KV Cache 的狀態(tài)管理KV Cache 是模型服務里最系統(tǒng)的部分。一個 7B 模型生成長度為 4096 的響應KV Cache 占的顯存可能比模型權重還大。緩存怎么分配、怎么換出、怎么在請求之間復用直接決定了單卡能并行處理多少請求。這一方向的代表作就是 PagedAttention把 KV Cache 切成固定大小的塊用類似虛擬內存的方式管理。后續(xù)工作在此基礎上做了分層緩存、壓縮緩存、跨節(jié)點共享。本質上這就是把操作系統(tǒng)的頁面置換算法搬到了 GPU 顯存上。2.3 主線三Prefill/Decode 分離與池化這是今年最值得關注的方向。推理過程分兩個階段prefill計算密集和 decode訪存密集。兩個階段對 GPU 資源的需求完全不同混在一起會導致資源浪費。DistServe 提出的方案是把兩者拆到不同的 GPU 池各干各的Mooncake 更進一步把 KV Cache 當作一個可共享的存儲層prefill 池算完就把中間結果丟給 decode 池。分離架構的收益很明顯但工程復雜度也很高。請求怎么流轉、失敗怎么恢復、兩個池的容量怎么配比都是難題。2.4 主線四性能可觀測性與 SLO 治理規(guī)模化服務不能只靠感覺。TTFT首 token 延遲、TPOT每 token 生成時間、端到端延遲這些指標要能實時監(jiān)控并且要能根據(jù) SLO 自動伸縮。相關論文給出的思路是把 SLO 作為調度器的輸入?yún)?shù)而不是事后統(tǒng)計。3. 調度細節(jié)從連續(xù)批處理到請求級控制調度這塊看起來簡單但真做起來全是細節(jié)。我下面拆解幾個關鍵環(huán)節(jié)。3.1 為什么連續(xù)批處理成了標配傳統(tǒng)批處理的問題很好理解一批請求里最慢的那個決定了整批的結束時間。如果一批里有 8 個請求其中一個要生成 2000 token其他 7 個只要 50 token那這 7 個快的也得等慢的跑完。GPU 的算力大量浪費在等待上。連續(xù)批處理的思路是每個解碼步結束后完成的請求立刻離開 batch新請求立刻補進來。這樣 GPU 永遠在算密度最高的批次。實測下來同樣的硬件連續(xù)批處理能把吞吐提升 2-3 倍。代價是調度器的復雜度上來了每一步都要檢查有哪些請求完成、新請求是否要搶占、KV Cache 是否夠分。3.2 Chunked Prefill 與請求優(yōu)先級連續(xù)批處理引入了一個新問題prefill 階段計算量大一個長請求的 prefill 可能會阻塞后面一排短請求的 decode。于是大家開始做 chunked prefill——把 prefill 的一大段計算切成小塊穿插在 decode 步之間。這就像操作系統(tǒng)的搶占式調度長任務不再獨占 CPU而是分時執(zhí)行。實際調優(yōu)中chunk 大小的選擇很講究太大導致 decode 延遲飆升太小又增加調度開銷。我們團隊的經(jīng)驗是chunk 大小控制在 512-1024 token 之間比較穩(wěn)妥同時要給短延遲請求開快車道——可以搶占低優(yōu)先級請求的算力。提示chunked prefill 不是銀彈。如果你的業(yè)務首 token 延遲要求極高比如低于 200ms還是要把短請求湊成一個獨立優(yōu)先級隊列避免被長 prefill 拖累。3.3 調度器里最難調的參數(shù)調度器的核心其實是三個數(shù)字的博弈TTFT、TPOT、吞吐量。想提升吞吐就得多塞請求進 batch但每個請求的 TPOT 就會變慢想降低 TTFT 就得讓請求快速插隊但頻繁插隊會導致整體吞吐下降。我給團隊定的調優(yōu)策略是先定 SLO 紅線然后在這條線下最大化吞吐。具體做法是給請求分三類——交互型要求 TTFT 500ms、生成型要求 TPOT 穩(wěn)定、批處理型無所謂延遲。這三類請求分別走不同的隊列調度器按比例分配 GPU 時間片。4. KV Cache分層、復用與壓縮KV Cache 是模型服務的顯存大頭也是緩存系統(tǒng)的重點研究對象。這一節(jié)講我在讀論文和實操中理解到的核心問題。4.1 PagedAttention 之后的世界PagedAttention 的核心貢獻是把 KV Cache 切成固定大小的塊通過頁表映射管理從而消除顯存碎片、支持跨請求共享。這個思路對顯存利用率提升非常明顯。但它的粒度是塊一個塊通常是 16 個 token 的 KV這在長上下文場景下仍有浪費——最后一塊可能只用了幾個 token。后續(xù)的優(yōu)化方向是更小的塊粒度、動態(tài)塊大小、以及把 KV 數(shù)據(jù)壓縮到更低位寬。比如 FP8 甚至 INT4 存儲 KV Cache配合量化感知的注意力計算。代價是精度損失但實測中大多數(shù)場景的生成質量影響很小可以接受。4.2 跨請求共享與語義緩存不同用戶問什么是 KV Cache前面幾層網(wǎng)絡prompt 前綴是完全相同的。如果每次請求都重新算一遍 prefill浪費十分嚴重。RadixAttentionSGLang 的核心思想把 KV Cache 按公共前綴組織成樹結構新請求能直接復用已有緩存跳過重復計算。這在共享前綴命中率高的場景收益極大比如聊天機器人的 system prompt、RAG 的固定檢索頭。但要注意緩存容量管理——樹結構緩存需要配套的淘汰機制LRU 是最基礎的更高級的是按未來復用概率做加權淘汰。緩存策略適用場景命中率提升復雜度普通 LRU通用場景一般低Radix Tree 前綴復用固定 system prompt高中語義緩存相似問題聚類高高需要 embedding 匹配分層緩存多 GPU 集群較高高4.3 緩存淘汰的權衡緩存淘汰最大的坑是你沒法預知哪個 KV Cache 會被復用。有些請求只是偶爾重復一次占著大量顯存有些用戶的高頻請求卻因為容量不夠被換出下次又要重算 prefill。我的建議是淘汰策略不要只看訪問時間要結合請求頻率、前綴長度、是否來自高價值用戶來綜合打分。另外考慮把冷 KV Cache 下移到 CPU 內存或遠端存儲而不是直接丟棄。雖然從 CPU 拉回 GPU 有帶寬開銷但相比重算 prefill通常還是劃算的。5. Prefill/Decode 分離與資源池化的實戰(zhàn)思考分離式架構是今年討論熱度最高的話題也是實際操作中收益和坑并存的方向。5.1 為什么非拆不可一個 LLM 請求的 prefill 階段是計算密集的GPU 的算力能跑滿但顯存帶寬需求低decode 階段則反過來每個 token 只需要做一次小矩陣乘大量時間花在讀顯存上。把兩個階段混在同一批里GPU 一會兒算到冒煙一會兒又閑得等顯存調度效率很低。分離架構把 prefill 和 decode 交給不同的 GPU 池處理。prefill 池用高算力 GPUdecode 池用大顯存 GPU各得其所。請求先到 prefill 池算出 KV Cache然后 KV Cache 傳到 decode 池繼續(xù)生成。理論吞吐可以提升數(shù)倍。5.2 分離架構的工程代價聽起來很美但工程實現(xiàn)遠比想象復雜。KV Cache 傳輸帶寬是硬瓶頸。一個 32K 上下文的 KV Cache 大約有幾百 MB跨節(jié)點傳輸本身就是延遲大頭。請求分配策略難調。prefill 池和 decode 池的比例要根據(jù)業(yè)務特征動態(tài)調整今天聊天請求多明天長文生成請求多比例不對就會一邊忙死一邊閑著。故障恢復復雜。decode 池里的請求可能依賴 prefill 池傳過來的中間結果prefill 池故障意味著要追溯重算。我的建議是如果單集群規(guī)模不大比如少于 32 卡不要輕易上分離架構。先把連續(xù)批處理和緩存復用做到位通常就能解決 80% 的吞吐問題。分離架構是為了沖更高規(guī)模上限的手段不是起點。5.3 池化調度的核心指標一旦決定做資源池化就要盯著幾個關鍵指標看池間隊列深度如果 prefill 池的隊列深度長期高于 decode 池說明 prefill 能力不足要加卡。KV Cache 傳輸耗時占比這個占比超過 20%說明網(wǎng)絡帶寬是瓶頸考慮壓縮 KV 或走共享顯存。池內空閑率min(池 A 空閑, 池 B 空閑) 越低越好。如果經(jīng)常出現(xiàn)一邊空轉一邊排隊說明池比例沒調對。6. 落地實操讀完論文后的部署經(jīng)驗論文給的是思路落地全是細節(jié)。分享一些我在實踐中獲得的經(jīng)驗希望能幫你少走彎路。6.1 論文指標和生產指標不是一回事論文里通常報告吞吐量tokens/s、首 token 延遲等指標但它們大多數(shù)是在特定數(shù)據(jù)集上測的前綴緩存命中率可能很高batch 里的請求分布也和你的業(yè)務不一樣。生產環(huán)境要關心的是有效吞吐——滿足 SLO 的那些請求的吞吐而不是理論吞吐。我見過不少團隊被論文數(shù)字吸引上線后實測只有論文數(shù)據(jù)的 30%。原因幾乎都是兩類業(yè)務請求長度分布跟論文數(shù)據(jù)集差異大或者高峰期的并發(fā)波動把調度器打懵了。所以用你自己的真實流量做壓測建立基線指標再找優(yōu)化點。6.2 架構選型建議根據(jù)集群規(guī)模和業(yè)務場景我給一個簡單直接的建議表規(guī)模場景推薦架構理由單機 1-4 卡內部工具、小流量vLLM 連續(xù)批處理簡單可靠夠用單機 8 卡中等流量、RAG獨立 prefill/decode 分離利用多卡異構優(yōu)勢多機多卡高并發(fā)、多租戶池化 KV Cache 共享存儲彈性伸縮資源效率高混合云流量波動大Serverless 自動伸縮成本最優(yōu)但要解決冷啟動如果流量比較平穩(wěn)那不一定要上復雜的池化架構如果流量有早晚高峰那就要提前規(guī)劃彈性擴縮。調度器的自動伸縮觸發(fā)條件建議用排隊長度而不是 GPU 利用率因為 GPU 利用率往往有滯后。6.3 部署監(jiān)控的最小清單做推理服務下面這些指標缺一不可請求級TTFT、TPOT、尾延遲P99系統(tǒng)級GPU 利用率、顯存占用、KV Cache 命中率隊列級每類請求的排隊長度、平均等待耗時資源級CPU/內存/網(wǎng)絡帶寬尤其是跨節(jié)點 KV Cache 傳輸帶寬我習慣把 TTFT 和排隊長度放在同一張圖上。只要隊一長TTFT 必然跟著漲這時候靠加卡解決不了問題——得看是不是調度策略把長請求和短請求混在一起了。7. 高頻問題排查記錄把幾個我反復遇到、也最適合拿來說明系統(tǒng)原理的問題整理成速查表。現(xiàn)象可能原因排查思路解決建議TTFT 忽高忽低長請求 prefill 阻塞看調度日志檢查 chunk 大小拆 prefill 塊或啟用長請求單獨隊列GPU 利用率高但吞吐低decode 階段顯存帶寬受限看解碼步的平均耗時檢查 KV Cache 是否壓縮降低數(shù)據(jù)讀取量KV Cache 頻繁換出緩存容量不足看命中率曲線增加顯存份額或引入 CPU 分層緩存多節(jié)點時吞吐上不去KV 傳輸帶寬瓶頸看節(jié)點間網(wǎng)絡占用壓縮 KV、減少跨節(jié)點請求自動伸縮反復抖動伸縮閾值太敏感看隊列長度變化增大冷靜周期用加權移動平均7.1 典型場景一TTFT 突然從 300ms 飆到 2 秒排查思路分三步。第一步看有沒有大請求進來第二步看調度器是否啟用了連續(xù)批處理但 prefill 沒分塊第三步看請求是否都擠進了同一個邏輯隊列。我遇到過最隱蔽的問題是緩存命中率突然下降導致 prefill 計算量翻倍緩存沒失效但用戶請求的 prompt 模板變了前綴全部 miss。7.2 典型場景二加了卡吞吐沒變化這通常說明瓶頸不在算力而在別處?？赡苁?KV Cache 傳輸網(wǎng)絡帶寬打滿、也可能是調度器單點成了瓶頸。你應該做的第一件事是看吞吐曲線的增長坡度如果是線性走平就需要檢查各環(huán)節(jié)的隊列深度。7.3 典型場景三長上下文請求把緩存打爆長上下文的 KV Cache 動輒幾個 GB一個并發(fā)稍高就填滿顯存。解法有兩類一類是限制單請求最大上下文長度另一類是給長請求設獨立的池避免它們擠占普通請求的緩存空間。后一種更推薦因為一刀切限制長度會傷用戶體驗。8. 寫在最后一些個人觀察Session 1A 這一整場看下來我最大的感受是模型服務正在快速操作系統(tǒng)化。調度、緩存、隔離、池化、容錯——這些詞本來就是操作系統(tǒng)教材里的核心章節(jié)現(xiàn)在它們在大模型推理場景里重新煥發(fā)了生命力。我的第二個觀察是論文給出的系統(tǒng)設計越來越復雜但工業(yè)界實際部署時越簡單的系統(tǒng)越容易成功。你可以先從一個單機版的連續(xù)批處理做起把監(jiān)控和排障體系建好再逐步迭代到池化架構。系統(tǒng)復雜度和團隊維護能力要匹配否則論文里漂亮的設計會變成生產事故的來源。如果你正在搭建模型推理服務建議盯著兩個指標P99 TTFT 和有效吞吐。把這兩個指標排在所有優(yōu)化工作之前就不會跑偏。至于緩存復用、prefill 分塊這些技術細節(jié)都屬于怎么讓這兩個指標更好的工具箱按需取用就好。我個人在實操中還有一個習慣每篇相關論文讀完不急著改架構先畫一張當前系統(tǒng)瓶頸在哪的圖把論文方案和我們的瓶頸對照。很多論文確實優(yōu)秀但它解決的瓶頸你可能還沒遇到先確認自己真的卡在哪一層再決定要不要借鑒。這樣既能避免過度設計也能在真正遇到瓶頸時知道該從哪個方向找答案。