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