這幾天一直在消化 SOSP 2026 的論文Session 1A 這場(chǎng)的主題是 Model Serving at Scale也就是大規(guī)模模型服務(wù)。說句實(shí)話這個(gè)方向在系統(tǒng)領(lǐng)域不算新但最近兩年因?yàn)榇竽Ｐ桶淹评沓杀就频搅藥缀趺總€(gè)團(tuán)隊(duì)都頭疼的程度一下子變成了頂會(huì)里最擁擠的賽道之一。這一場(chǎng)的幾篇論文集中討論了一個(gè)共同問題當(dāng)模型服務(wù)的請(qǐng)求規(guī)模、模型規(guī)模、GPU 規(guī)模和集群規(guī)模同時(shí)漲上去之后傳統(tǒng) Serving 系統(tǒng)的設(shè)計(jì)邏輯還撐不撐得住撐不住的地方又該怎么改。你如果只是做應(yīng)用層開發(fā)可能對(duì)這些論文沒什么感覺但如果你是負(fù)責(zé)部署推理服務(wù)、調(diào)優(yōu) GPU 利用率、或者正在從單卡部署往多機(jī)集群遷移的工程師這一場(chǎng)的內(nèi)容基本就是為你準(zhǔn)備的。文章里很多設(shè)計(jì)并不是停留在紙面上的 idea而是直接可以影響你選型、配參數(shù)、設(shè)計(jì)服務(wù)架構(gòu)的決策。這篇文章我就按自己的理解把這一場(chǎng)里最有價(jià)值的幾個(gè)系統(tǒng)設(shè)計(jì)思路拆開講順便把我自己實(shí)操中踩過的坑和驗(yàn)證過的做法穿插進(jìn)去希望能給你一些可直接參考的東西。圍繞 Model Serving 的討論其實(shí)有一條很清晰的暗線單卡能跑通模型只是第一步真正難的是讓幾十張甚至幾百張 GPU 在持續(xù)變化的請(qǐng)求流下保持高吞吐、低延遲和低成本。這背后牽扯到調(diào)度策略、顯存管理、通信設(shè)計(jì)、甚至 kernel 層面的優(yōu)化不是單純把模型塞進(jìn)顯存就完事的。1. 這屆 Session 1A 到底在討論什么Model Serving 的核心矛盾1.1 從單機(jī)部署到集群化推理變化發(fā)生在哪前幾年我們部署推理服務(wù)思路其實(shí)很簡單模型加載進(jìn) GPU起一個(gè) HTTP Server請(qǐng)求來了就前向推理一次返回結(jié)果。那時(shí)候模型不大并發(fā)不高Serving 系統(tǒng)要解決的只是“別讓 GPU 閑著”而已。但到了大模型時(shí)代情況完全變了。單是這個(gè)“別讓 GPU 閑著”就已經(jīng)很難做到因?yàn)檎?qǐng)求之間不是獨(dú)立的。每個(gè)請(qǐng)求都有自己的 prompt、自己的上下文長度、自己已經(jīng)生成的歷史 token服務(wù)端要為每個(gè)請(qǐng)求動(dòng)態(tài)維護(hù)一份 KV Cache。這意味著 Serving 不能像傳統(tǒng) Web 服務(wù)那樣無狀態(tài)地橫向擴(kuò)展每個(gè)請(qǐng)求的內(nèi)存占用是動(dòng)態(tài)變化的GPU 顯存很容易在幾分鐘內(nèi)被打滿。這一場(chǎng)論文里反復(fù)出現(xiàn)的一個(gè)詞是“協(xié)調(diào)”。單卡推理的利用率再高放到集群層面也可能因?yàn)榕抨?duì)不均衡、數(shù)據(jù)傾斜、上下游帶寬不匹配而整體吞吐很差。協(xié)調(diào)的核心對(duì)象有三個(gè)算力、顯存、時(shí)間。算力決定你單位時(shí)間能跑多少個(gè) token顯存決定你能同時(shí)放多少個(gè)請(qǐng)求時(shí)間則決定了請(qǐng)求從進(jìn)入到返回的整個(gè)延遲。三個(gè)因素互相耦合操作任何一個(gè)都會(huì)影響另外兩個(gè)這就是規(guī)?；暮诵拿?。1.2 論文給出的三個(gè)關(guān)鍵約束我梳理了一下這一場(chǎng)的論文基本默認(rèn)了三個(gè)物理約束所有設(shè)計(jì)都圍繞它們展開GPU 顯存的增長速度跟不上模型參數(shù)的增長但更跟不上并發(fā)請(qǐng)求對(duì) KV Cache 的需求。于是論文普遍把 KV Cache 當(dāng)作一種可以池化、調(diào)度、換入換出的資源而不是綁定在某張卡上的固定內(nèi)存塊。單卡計(jì)算峰值很高但內(nèi)存帶寬遠(yuǎn)低于計(jì)算速度。也就是說decode 階段每生成一個(gè) token 都要把整個(gè)模型參數(shù)學(xué)一遍此時(shí)算力不是瓶頸顯存帶寬才是。這個(gè)約束直接決定了很多論文為什么在 decode 階段采用 batch 合并和特殊 kernel。請(qǐng)求的到達(dá)模式高度不均勻而且長請(qǐng)求和短請(qǐng)求混在一起。簡單 FCFS 會(huì)導(dǎo)致長尾延遲爆炸純優(yōu)先級(jí)調(diào)度又會(huì)餓死大批量短任務(wù)必須在“公平”和“效率”之間做文章。這三個(gè)約束單獨(dú)任何一個(gè)都容易理解難的是同時(shí)優(yōu)化。Session 1A 里好幾篇論文的設(shè)計(jì)差異恰恰體現(xiàn)在約束的取舍順序上有的優(yōu)先保證延時(shí)有的優(yōu)先保證吞吐有的優(yōu)先做成本歸一化但骨架都是圍繞算力、顯存、時(shí)間三者建模再?zèng)Q定調(diào)度和分配策略。這套取舍邏輯我認(rèn)為是最值得學(xué)的比具體的代碼實(shí)現(xiàn)更有普適性。1.3 評(píng)述視角這套方案解決了什么沒解決什么如果只看論文標(biāo)題Model Serving at Scale 聽起來是一個(gè)通用問題但細(xì)讀會(huì)發(fā)現(xiàn)作者們基本把目光鎖定在“單集群內(nèi)、多租戶、長文本交互”這個(gè)典型場(chǎng)景。優(yōu)點(diǎn)是問題定義非常清楚評(píng)測(cè)指標(biāo)統(tǒng)一關(guān)注 TTFT首 token 延遲、ITLtoken 間延遲、吞吐和 GPU 利用率結(jié)果可復(fù)現(xiàn)。缺點(diǎn)是這套設(shè)計(jì)對(duì)“跨數(shù)據(jù)中心”“超大模型分布式訓(xùn)練疊加推理”“邊緣設(shè)備服務(wù)”這些更極端的場(chǎng)景沒有太多討論。也就是說這一場(chǎng)的成果對(duì)絕大多數(shù)做線上推理服務(wù)的團(tuán)隊(duì)都有參考價(jià)值但如果你是想找一套能直接解決手機(jī)端或者多地域容災(zāi)的 Serving 方案可能還要結(jié)合其他方向的工作。不過這不影響我們從中提取可遷移的設(shè)計(jì)原則。我需要特別說明一下下面幾節(jié)我不會(huì)逐篇復(fù)述論文而是把這一場(chǎng)里反復(fù)出現(xiàn)的系統(tǒng)設(shè)計(jì)思路提煉出來結(jié)合我自己上線推理服務(wù)時(shí)用過的方案和踩過的坑給你一套能帶走的東西。2. 核心設(shè)計(jì)思路拆解以 request 為中心的調(diào)度2.1 Continuous batching 為什么成了默認(rèn)答案很多沒深入做過推理系統(tǒng)的人可能不理解為什么兩年前大家都在吹動(dòng)態(tài)批處理continuous batching現(xiàn)在它反而成了 Serving 引擎的默認(rèn)配置似乎沒什么好講的。但恰恰因?yàn)樗匾诉@一場(chǎng)論文里幾乎所有實(shí)驗(yàn)的 baseline 都建立在它的基礎(chǔ)上所以我先把它的原理說透。傳統(tǒng)的 static batching 做法是收集一批請(qǐng)求等數(shù)量滿了或者超時(shí)了一起做前向推理。問題在于這批請(qǐng)求里如果有幾個(gè)生成了 20 個(gè) token 就結(jié)束了另外幾個(gè)還在生成 200 個(gè) token那么 GPU 算力的利用率就會(huì)隨著請(qǐng)求不斷結(jié)束而下降。因?yàn)?batch 里空出來的位置沒法再填新請(qǐng)求必須等整批結(jié)束才能開啟下一批。Continuous batching 的做法是每個(gè)序列在 GPU 上的執(zhí)行不再是“整批綁定”而是以 iteration一次前向?yàn)榱６葎?dòng)態(tài)調(diào)度。某個(gè)序列結(jié)束了下一輪迭代立刻插入新請(qǐng)求某個(gè)序列的 KV Cache 不夠了系統(tǒng)會(huì)在迭代邊界給別的序列騰位置。這樣一來GPU 上同時(shí)運(yùn)轉(zhuǎn)的序列數(shù)始終接近顯存容量允許的上限吞吐自然就上來了。但代價(jià)也藏在里面。動(dòng)態(tài)調(diào)度意味著每一個(gè) iteration 都要重新決定 GPU kernel 要處理哪些序列調(diào)度開銷會(huì)隨序列數(shù)上升。這一場(chǎng)論文里凡是自稱高性能的 Serving 方案基本都在這個(gè)“動(dòng)態(tài)調(diào)度”層做了優(yōu)化要么把調(diào)度器放到獨(dú)立線程要么用流水線把調(diào)度的計(jì)算和 GPU 執(zhí)行重疊。我自己的經(jīng)驗(yàn)是當(dāng)單機(jī)并發(fā)請(qǐng)求數(shù)超過 200 且序列長度不均勻時(shí)沒有優(yōu)化過的動(dòng)態(tài)調(diào)度器反而會(huì)成為瓶頸CPU 占用沖到 100%GPU 利用率卻只有 60%。所以 “continuous batching”不等于免費(fèi)午餐它需要配合高效的調(diào)度實(shí)現(xiàn)。2.2 Prefill/Decode 分離帶來的調(diào)度革命這一場(chǎng)討論熱度最高的話題應(yīng)該是 prefill 階段和 decode 階段的分離調(diào)度。很多同學(xué)看到這個(gè)名詞以為只是把兩個(gè)階段放到不同 GPU 上執(zhí)行其實(shí)背后的動(dòng)機(jī)非常鮮明。Prefill 階段處理的是一個(gè)長 prompt計(jì)算量大但是并行度高因?yàn)榭梢砸淮涡詫?duì)所有輸入 token 做矩陣乘法。Decode 階段則是一個(gè) token 一個(gè) token 地生成每一步都依賴上一步的輸出串行特性很強(qiáng)。把這兩個(gè)階段混在同一批請(qǐng)求里會(huì)導(dǎo)致系統(tǒng)很難同時(shí)優(yōu)化二者prefill 想要大 batch、長序列、高計(jì)算強(qiáng)度decode 想要的卻是小 batch、高帶寬、低延遲。兩者對(duì)資源的需求幾乎是反的。所以現(xiàn)在很多 Serving 架構(gòu)會(huì)設(shè)置兩類實(shí)例一類專門做 prefill把請(qǐng)求的 KV Cache 計(jì)算好另一類專門做 decode只負(fù)責(zé)后續(xù) token 的生成。請(qǐng)求在 prefill 實(shí)例上完成后把 KV Cache 傳給 decode 實(shí)例繼續(xù)生成。論文里對(duì)這種“分離式架構(gòu)”的改進(jìn)主要集中在這幾點(diǎn)Prefill 和 decode 實(shí)例之間的比例不是固定的而是根據(jù)流量動(dòng)態(tài)調(diào)整避免某個(gè)階段排隊(duì)過長。KV Cache 的傳輸不需要通過 CPU 中轉(zhuǎn)而是通過 GPU 間的 NVLink 或者 RDMA 直接交換減少拷貝延遲。當(dāng) decode 實(shí)例空閑時(shí)它也可以反過來接受一些輕量 prefill 任務(wù)避免算力浪費(fèi)。這里我要多說一句PD 分離不是銀彈。如果你的線上流量是短文本、短回答比例偏向輕量請(qǐng)求那么 prefill 和 decode 混跑其實(shí)并不會(huì)差很多強(qiáng)行拆開反而增加數(shù)據(jù)傳輸開銷。所以論文里給出的在 8 卡到 32 卡場(chǎng)景下收益比較明顯小集群收益有限。這個(gè)結(jié)論跟我在自己環(huán)境里的測(cè)試是一致的。2.3 KV Cache 資源池化顯存不再是單卡約束傳統(tǒng)推理部署里KV Cache 是跟著請(qǐng)求走的。請(qǐng)求在哪個(gè) GPU 上KV Cache 就在哪個(gè) GPU 上分配。但請(qǐng)求長度變化太隨機(jī)了可能某張卡上的請(qǐng)求全是長文本把顯存吃滿另一張卡卻全是短請(qǐng)求留下大片空洞。Session 1A 多篇論文的解決思路是把 KV Cache 做成集群級(jí)資源池由中心調(diào)度器統(tǒng)一管理。每個(gè)請(qǐng)求在運(yùn)行前先“預(yù)留”一塊虛擬顯存配額實(shí)際物理分配則按需從池子中領(lǐng)取頁面。當(dāng)某張 GPU 顯存不夠了可以把部分請(qǐng)求的舊 KV Cache 頁面替換或換出再重新調(diào)度到有空間的 GPU 上繼續(xù)生成。這個(gè)思路聽著很像操作系統(tǒng)里的虛擬內(nèi)存但實(shí)現(xiàn)起來難點(diǎn)在粒度。如果按 token 一個(gè)個(gè)管理緩存頁調(diào)度開銷會(huì)大到你沒法接受如果按整個(gè)請(qǐng)求管理又沒法處理變長序列帶來的碎片。我比較欣賞的一種做法是分層管理請(qǐng)求級(jí)調(diào)度器負(fù)責(zé)把請(qǐng)求分配到 GPU 節(jié)點(diǎn)節(jié)點(diǎn)級(jí)運(yùn)行時(shí)負(fù)責(zé)把 KV Cache 按固定大小的塊比如 64 token 一組管理同一請(qǐng)求的多個(gè)塊可以分散在不同 GPU 上但盡量保證當(dāng)前正在生成的 token 所在的塊在本地避免頻繁跨卡讀取。用生活類比就是不要讓每個(gè)旅客請(qǐng)求必須住一整間房整塊顯存而是把房間拆成可組合的床位旅客可以靈活入住多名室友同時(shí)保證每個(gè)旅客常用的隨身物品最近的 KV就在手邊。這套機(jī)制讓顯存利用率從 60% 提升到 85% 以上直接帶來的效果就是同樣的 GPU 數(shù)量能承載更多的并發(fā)和更長的上下文。2.4 多級(jí)隊(duì)列與優(yōu)先級(jí)策略不要讓一個(gè)長任務(wù)毀了所有短任務(wù)最后一個(gè)在論文里反復(fù)出現(xiàn)、但容易被忽視的設(shè)計(jì)是調(diào)度隊(duì)列。很多人以為調(diào)度就是把請(qǐng)求按到達(dá)順序排好按先來后到執(zhí)行。但在多租戶場(chǎng)景下這種策略非常容易出事故。設(shè)想一下一個(gè)請(qǐng)求的 prompt 是 8000 token回復(fù)也要 8000 token另一個(gè)請(qǐng)求只有 30 token 的輸入輸出。如果它們混在一個(gè)隊(duì)列里長請(qǐng)求會(huì)占住 GPU 資源和 KV Cache短請(qǐng)求被迫等待最終短請(qǐng)求的 TTFT 會(huì)從幾十毫秒漲到幾秒前端直接超時(shí)。論文里給出的多級(jí)隊(duì)列方案大體是這樣的隊(duì)列級(jí)別服務(wù)對(duì)象策略典型場(chǎng)景L1 快速通道短請(qǐng)求、首 token 敏感請(qǐng)求搶占式可中斷長任務(wù)的空閑 slot在線對(duì)話、搜索摘要L2 普通通道中長請(qǐng)求、批處理任務(wù)保證最小吞吐內(nèi)容生成、批量翻譯L3 后臺(tái)通道離線任務(wù)、預(yù)填充只在 GPU 空閑運(yùn)行日志摘要、數(shù)據(jù)增強(qiáng)實(shí)際落地時(shí)調(diào)度器會(huì)在迭代邊界做“搶占”只要 L1 隊(duì)列有請(qǐng)求就優(yōu)先把它插進(jìn)下一輪 iteration哪怕這意味著要暫時(shí)打斷 L2 隊(duì)列里正在進(jìn)行的某條序列。這種設(shè)計(jì)需要代價(jià)被打斷的序列會(huì)多等一兩個(gè)迭代但在短請(qǐng)求 SLO 和長請(qǐng)求吞吐之間取得了更好的平衡。我在部署時(shí)也遇到過類似問題。一開始我們用簡單的 FCFS 隊(duì)列結(jié)果線上經(jīng)常出現(xiàn)一個(gè)用戶輸入超長文檔、其他用戶全部超時(shí)的投訴。后來借鑒了這種多級(jí)隊(duì)列的思路把在線推理請(qǐng)求和離線批處理請(qǐng)求分離效果立竿見影p99 延遲直接降了一個(gè)數(shù)量級(jí)。多級(jí)隊(duì)列的配置參數(shù)說穿了就是你在延遲、吞吐、成本之間的偏好沒有標(biāo)準(zhǔn)答案但方向是對(duì)的。3. 實(shí)操落地從論文到生產(chǎn)的三個(gè)可遷移動(dòng)作3.1 第一步測(cè)量自己的請(qǐng)求分布論文里的調(diào)度策略之所以有效很大程度上因?yàn)樽髡吣芫_測(cè)量請(qǐng)求長度、到達(dá)速率、token 分布等指標(biāo)。但很多生產(chǎn)團(tuán)隊(duì)的 Serving 配置都是拍腦袋定的這是我見到的最大的問題。你要做的第一件事不是調(diào)參而是把線上請(qǐng)求日志撈出來統(tǒng)計(jì)下面幾個(gè)指標(biāo)請(qǐng)求的 prompt 長度分布尤其關(guān)注 p50、p95、p99。生成的回復(fù) token 數(shù)分布這里通常跟模型類型強(qiáng)相關(guān)對(duì)話類模型和生成類模型的差異非常大。每秒到達(dá)的請(qǐng)求數(shù)RPS的峰值和低谷最好能畫出時(shí)間曲線。同一時(shí)刻并發(fā)請(qǐng)求的 token 總量這個(gè)決定了 KV Cache 的峰值需求量。拿到這些數(shù)據(jù)后你再回看論文里的設(shè)計(jì)會(huì)發(fā)現(xiàn)很多選擇都非常合理。比如你的流量如果是“少量長文檔 大量短對(duì)話”那 prefill/decode 分離幾乎是必須的如果是“絕大多數(shù)請(qǐng)求都很短”那么單卡混跑加 continuous batching 就夠了沒必要上集群級(jí)調(diào)度。我自己剛接手推理服務(wù)的時(shí)候第一件事就是寫了一個(gè)簡單的統(tǒng)計(jì)腳本把線上 7 天的請(qǐng)求日志做了分布統(tǒng)計(jì)結(jié)果發(fā)現(xiàn)接近一半的請(qǐng)求 prompt 長度不足 200 token但同時(shí)有 5% 的請(qǐng)求 prompt 超過 4000 token。不看這個(gè)數(shù)據(jù)我可能會(huì)花大量精力去優(yōu)化長文本的 KV Cache 池化但實(shí)際上短請(qǐng)求的調(diào)度優(yōu)化才是核心收益點(diǎn)。3.2 第二步合理切分 prefill/decode 實(shí)例如果你確定了要走 PD 分離這條路那就要考慮實(shí)例比例問題。比較樸素的做法是直接按流量占比來分配 GPU假設(shè) 30% 的時(shí)間在跑 prefill70% 的時(shí)間在跑 decode那就按 3:7 的比例分卡。但這忽略了 token 吞吐的差異prefill 階段雖然耗時(shí)短但計(jì)算量大decode 階段耗時(shí)雖長但每個(gè) token 的計(jì)算強(qiáng)度低所以不能只看時(shí)間占比。更合理的估算方式是按 token 吞吐量來算假設(shè)你的 GPU 做 prefill 時(shí)能達(dá)到每秒處理 X 萬 token 的輸入速度。decode 時(shí)能達(dá)到每秒生成 Y 千 token 的輸出速度。根據(jù)線上統(tǒng)計(jì)的輸入輸出比例算出單卡處理單位請(qǐng)求的時(shí)間占比。再根據(jù) RPS 和并發(fā)量反推需要多少張 prefill 卡、多少張 decode 卡。這個(gè)算法寫起來很簡單但真正常用的方案是讓 prefill 和 decode 實(shí)例的比例不是固定的而是支持動(dòng)態(tài)遷移。比如把一部分 GPU 標(biāo)記為“彈性角色”流量高峰時(shí)可以自動(dòng)從 decode 模式切換到 prefill 模式。論文里對(duì)這種彈性角色切換的設(shè)計(jì)做了很多優(yōu)化核心點(diǎn)在于切換時(shí) KV Cache 和模型權(quán)重如何快速重新布局避免傷害在線請(qǐng)求。我自己在生產(chǎn)環(huán)境里最開始就是靜態(tài)比例后來發(fā)現(xiàn)每天下午的流量形態(tài)跟上午差別很大最終改成白天 prefill:decode 2:8晚上 4:6靠定時(shí)任務(wù)切換雖然沒有論文里的動(dòng)態(tài)聯(lián)動(dòng)那么優(yōu)雅但已經(jīng)能省下不少成本。如果你條件允許可以嘗試讓調(diào)度器根據(jù)排隊(duì)長度自動(dòng)調(diào)整角色這是投入產(chǎn)出比很高的一件事。3.3 第三步用緩存、量化、投機(jī)解碼降本Session 1A 里不少篇幅在討論如何用更少 GPU 扛住同樣流量這也符合“at Scale”的現(xiàn)實(shí)訴求。除了調(diào)度之外有三個(gè)手段幾乎每篇論文都會(huì)作為模塊提到Prefix Cache把公共前綴的 KV Cache 緩存起來后續(xù)請(qǐng)求只要命中同一個(gè)系統(tǒng)提示詞或者文檔前綴就能跳過 prefill 直接進(jìn)入 decode。實(shí)測(cè)在 RAG 場(chǎng)景下命中率能到 40% 以上TTFT 下降非常明顯。量化感知 Serving模型權(quán)重從 FP16 降到 INT8 或 INT4能省一半顯存代價(jià)是精度略微下降。Serving 系統(tǒng)要做的是根據(jù)請(qǐng)求類型動(dòng)態(tài)切換量化版本比如對(duì)內(nèi)部測(cè)試流量用低精度對(duì)核心用戶保留高精度。投機(jī)解碼用小模型先生成若干個(gè)候選 token再用大模型一次驗(yàn)證。如果候選被接受那么一次前向可以產(chǎn)出多個(gè) tokendecode 吞吐直接翻倍甚至更高。但它對(duì)生成的接受率敏感不是所有場(chǎng)景都有效。我特別想強(qiáng)調(diào) Prefix Cache 的重要性。很多人以為 KV Cache 是跟隨請(qǐng)求動(dòng)態(tài)生成的沒有太多復(fù)用價(jià)值但實(shí)際上在一個(gè)固定場(chǎng)景里用戶輸入往往帶有一段很長的公共指令前綴。啟用 Prefix Cache 后新請(qǐng)求只需要計(jì)算差異部分的 KV大量復(fù)用已有結(jié)果。我這里給一個(gè)簡單的配置思路# 框架無關(guān)的偽配置示意 serving: cache: enabled: true max_prefix_tokens: 4096 min_match_length: 64 quantization: default: int8 fallback: fp16 speculative_decoding: draft_model: small_v2 verify_interval: 4這段配置的核心意義不是參數(shù)本身而是你要在 Serving 層把“緩存”“量化”“投機(jī)解碼”都當(dāng)成一等公民來設(shè)計(jì)而不是事后再補(bǔ)。等流量上漲再想加這些功能改動(dòng)成本要高得多。4. 常見問題與排查技巧實(shí)錄我從 Session 1A 延伸到實(shí)戰(zhàn)場(chǎng)4.1 顯存碎片化導(dǎo)致推理引擎 OOM我做過很多次性能優(yōu)化最崩潰的一類問題是明明 GPU 顯存還有幾個(gè) GB但啟動(dòng)新請(qǐng)求時(shí)直接報(bào) Out of Memory。原因就是 KV Cache 的分配和釋放不連續(xù)顯存被切割成很多小塊哪一塊都不夠塞進(jìn)一個(gè)長序列的 KV。Session 1A 里推薦的思路是引入“Cache Blk”抽象把所有顯存預(yù)先切成固定大小的 block請(qǐng)求需要的 KV 按 block 分配而不是按“整段連續(xù)內(nèi)存”分配。這樣即使顯存碎片很多只要總 free block 數(shù)夠請(qǐng)求就能成功分配。這個(gè)方法我實(shí)際操作之后基本上杜絕了“顯存剩余但 OOM”的怪現(xiàn)象。如果你想排查自己的服務(wù)是否存在碎片化最直接的方式是觀察顯存分配曲線如果分配總量看起來有空閑但并發(fā)請(qǐng)求的規(guī)模上不去那大概率是碎片問題?？梢钥紤]在代碼層引入類似 PyTorch caching allocator 的機(jī)制或者直接改用論文里推薦的 block-based KV Cache 實(shí)現(xiàn)。4.2 長尾延遲p99 總是不達(dá)標(biāo)這一場(chǎng)多次講到延遲的分布問題。稍微上一點(diǎn)規(guī)模后你會(huì)發(fā)現(xiàn)平均延遲看起來還行但 p99 或者 p999 總是異常高。原因往往不在模型本身而是在調(diào)度環(huán)節(jié)要么是某個(gè)長請(qǐng)求占住 GPU 時(shí)間太久要么是某個(gè) decode 實(shí)例負(fù)載過高導(dǎo)致所有排到它上面的請(qǐng)求都變慢。排查時(shí)我習(xí)慣分三層去看看隊(duì)列排隊(duì)時(shí)間如果一個(gè)請(qǐng)求從進(jìn)入到執(zhí)行的時(shí)間占了總延遲的 40% 以上說明調(diào)度策略有問題?？磫?iteration 耗時(shí)如果某個(gè)階段執(zhí)行時(shí)間突然從 30ms 漲到 100ms可能是 key-value cache 換頁或者跨卡訪問?？?GPU 帶寬如果 decode 階段大量跨卡取 KV帶寬會(huì)成為隱形瓶頸。對(duì)癥下藥的方式可能是調(diào)整 prefill/decode 比例也可能是給短請(qǐng)求提升優(yōu)先級(jí)。論文里給出的動(dòng)態(tài)隊(duì)列方案就是解決這個(gè)問題的但你需要先定位問題在哪個(gè)環(huán)節(jié)才能真正用對(duì)方向。我在實(shí)際調(diào)優(yōu)時(shí)發(fā)現(xiàn)很多團(tuán)隊(duì)的 p99 問題其實(shí)出在“跨卡 KV Cache 訪問”上改掉之后效果立竿見影。4.3 多模型共存時(shí)的資源干擾Session 1A 有一個(gè)容易被忽略的應(yīng)用場(chǎng)景是多模型同時(shí)服務(wù)比如一個(gè)模型中英文翻譯一個(gè)模型做摘要還有一個(gè)模型做向量化。很多人一開始把它們部署在同一臺(tái)機(jī)器上以為共享 GPU 能省錢結(jié)果發(fā)現(xiàn)兩個(gè)模型互相干擾各自的吞吐都下降了。這是因?yàn)椴煌Ｐ偷?kernel 執(zhí)行時(shí)間不同對(duì)顯存帶寬、SM 占用、緩存行利用都存在競(jìng)爭。論文里提到的一個(gè)方案是“資源池隔離 時(shí)間片輪轉(zhuǎn)”把 GPU 的 SM 劃分為不同 partition讓不同模型占用獨(dú)立 partition同時(shí)用時(shí)間片避免長任務(wù)獨(dú)占。但這類方案對(duì) kernel 的配合度要求高如果模型來自不同框架可能沒法精細(xì)隔離。從實(shí)操角度我的建議是在模型之間用“小型獨(dú)立實(shí)例 統(tǒng)一入口路由”來代替硬隔離。每個(gè)模型一組 GPU共享一個(gè)請(qǐng)求入口入口根據(jù)模型類型路由。雖然犧牲了一些共享收益但穩(wěn)定性和可維護(hù)性高很多。論文里的精細(xì)隔離方案更需要底層硬件的支持適合大廠或者專用集群小團(tuán)隊(duì)落地成本偏高。5. 寫在最后從論文評(píng)審到工程實(shí)現(xiàn)我更關(guān)注什么Session 1A 的論文讀下來我最深刻的體會(huì)是Model Serving 的工程難度已經(jīng)不再局限于模型本身了。過去我們常討論模型結(jié)構(gòu)、訓(xùn)練方法但線上系統(tǒng)設(shè)計(jì)的好壞直接決定了用戶等多久才能看到第一個(gè) token、你一個(gè)月要燒多少 GPU 費(fèi)用、以及流量十倍增長時(shí)服務(wù)會(huì)不會(huì)直接崩潰。這些論文雖然來自學(xué)術(shù)界但提出的很多模塊化設(shè)計(jì)已經(jīng)值得生產(chǎn)環(huán)境借鑒。不用貪多求全地一次性把所有論文里的機(jī)制都搬進(jìn)自己的系統(tǒng)。我的建議是從一個(gè)痛點(diǎn)開始如果你的問題是顯存利用率低就先去實(shí)現(xiàn) block-based KV Cache如果問題是長請(qǐng)求導(dǎo)致短請(qǐng)求超時(shí)就先去做多級(jí)隊(duì)列。系統(tǒng)設(shè)計(jì)的提升從來不是推倒重來而是把瓶頸點(diǎn)逐個(gè)擊破。最后還有一個(gè)小技巧想分享無論你采用的是哪個(gè)開源推理引擎都記得在壓測(cè)時(shí)加上 token 級(jí)的性能指標(biāo)采集而不是只看請(qǐng)求成功率。TTFT、ITL、生成吞吐這三個(gè)指標(biāo)分開追蹤你才能知道瓶頸是在 prefill 還是 decode是在網(wǎng)絡(luò)還是顯存。我在排查性能問題時(shí)這個(gè)習(xí)慣幫我省了大量時(shí)間。