戰(zhàn)：NVFP4量化與P-D分離部署大模型吞吐調(diào)優(yōu))
1. 為什么用 B300 跑這兩個(gè)模型B300 出來(lái)之后我們內(nèi)部就在盤算手上的模型服務(wù)要不要遷過(guò)去。手里正好有 GLM-5.2-NVFP4 和 Kimi-K3 兩組測(cè)試權(quán)重前者是官方直接發(fā)布的 NVFP4 量化版本后者我們先用 BF16 跑基線、再切 FP8 對(duì)比。在 16 卡 B300 集群上測(cè)出來(lái)的吞吐、緩存命中和部署手感基本代表了當(dāng)前 4-bit 推理的主流水平。這篇文章不寫云里霧里的理論就把我們拿到機(jī)器后從零搭環(huán)境、測(cè)壓、調(diào)參、踩坑的全過(guò)程攤開聊。先說(shuō)結(jié)論方便沒(méi)時(shí)間看完全文的同學(xué)16 卡 B300 拆成 2 組 TP8 副本跑 GLM-5.2-NVFP4256 并發(fā)、共享系統(tǒng)提示詞占比約 70% 的混合負(fù)載綜合吞吐大約比同模型 FP8 版本高 1.61.9 倍P-D 分離加 prefix cache 配置到位后輸入側(cè)有效吞吐能翻 2 倍以上TTFT首 token 延遲從 1.2s 壓到 400ms 以內(nèi)NVFP4 在 B300 上不是單純省顯存它把權(quán)重搬移量砍半decode 階段直接吃滿內(nèi)存帶寬的增益網(wǎng)絡(luò)層有一個(gè)坑CX8 網(wǎng)卡的歸屬和固件版本必須提前確認(rèn)我們?yōu)檫@個(gè)排查了整整一個(gè)下午。這篇內(nèi)容適合誰(shuí)看正在做 B300/GB300 集群評(píng)估的 SRE、推理框架開發(fā)、運(yùn)維或者想在 vLLM/SGLang 上部署 4-bit 量化大模型的同學(xué)。新手也能看原理部分我會(huì)盡量講人話參數(shù)部分可以直接抄。1.1 模型版本的差異不是名字后綴那么簡(jiǎn)單GLM-5.2-NVFP4 不是“GLM-5.2 順手壓到 4bit”這么簡(jiǎn)單。官方這次是把權(quán)重直接按 NVFP4 格式重新規(guī)整過(guò)包括通道粒度per-channel/per-group的縮放因子都預(yù)計(jì)算好推理時(shí)不需要在 GPU 上臨時(shí)做量化省掉了批處理場(chǎng)景下重復(fù)的 quantization kernel 開銷。Kimi-K3 目前沒(méi)有官方 NVFP4 版本所以我們測(cè)的是 BF16 基線和 FP8 在線量化兩類配置作為對(duì)照組。為什么在意這一點(diǎn)因?yàn)椤邦A(yù)量化”和“運(yùn)行時(shí)量化”在高吞吐場(chǎng)景下差距巨大。運(yùn)行時(shí)把 BF16/FP16 轉(zhuǎn)成 FP8 或 FP4 需要額外的計(jì)算 kernel雖然 B300 的 tensor core 處理這些很快但在 memory-bound 的 decode 階段任何多余 kernel 都會(huì)擠占內(nèi)存帶寬配額。GLM-5.2-NVFP4 這種權(quán)重直接以 NVFP4 格式存放的方式加載時(shí)就能直接被 tensor core 讀取完全省掉這部分開銷。1.2 測(cè)試指標(biāo)的選定我們這次重點(diǎn)看三個(gè)指標(biāo)吞吐tokens/s分 decode 吞吐和 prefill 吞吐統(tǒng)計(jì)取穩(wěn)定壓測(cè) 10 分鐘以上的平均值緩存命中率%輸入 tokens 中直接復(fù)用 KV cache 的比例反映 prefix cache 和 P-D 分離的整體配置效果TTFT / TPOT首 token 延遲和每 token 延遲高吞吐場(chǎng)景不能只盯著吞吐端到端體驗(yàn)要能壓住 P99 延遲。說(shuō)實(shí)話跑完一輪完整壓測(cè)之后我的體感是單卡性能是底座但真正拉開差距的地方在“緩存命中率”和“調(diào)度策略”。同樣一批請(qǐng)求把 prefix cache 配好之后的綜合吞吐和沒(méi)配相比差距大到離譜。所以后面我用一大節(jié)專門講緩存命中這部分是最值得抄作業(yè)的。2. 16 卡集群的硬件拓?fù)渑c網(wǎng)絡(luò)細(xì)節(jié)這次測(cè)試用的集群是 2 臺(tái) B300 整機(jī)每臺(tái) 8 卡組成 16 卡環(huán)境。每張 B300 是 288GB HBM3e內(nèi)存帶寬標(biāo)稱約 8TB/s單卡 FP4 稀疏算力比 B200 又漲了一截。8 卡之間通過(guò) NVLink-C2C 加 NVSwitch 全互聯(lián)跨節(jié)點(diǎn)走 InfiniBand NDR 400Gbps RDMA。整體拓?fù)洳粡?fù)雜但有幾個(gè)點(diǎn)不確認(rèn)清楚后面調(diào)試會(huì)非常折磨人。2.1 B300 和上一代的差距在哪很多人問(wèn) B300 的“上一代”是啥。按 NVIDIA 這代的命名邏輯B300 的上一代核心是 B200Blackwell 架構(gòu)再往前是 H200/H100Hopper 架構(gòu)。B300 和 B200 的關(guān)系有點(diǎn)像當(dāng)年 A100 到 H100 的演進(jìn)同一個(gè)架構(gòu)代系但把 HBM 容量、帶寬和算力做了整體提升。B300 最大變化是顯存從 192GB 提到 288GBHBM3e 的堆疊容量變大帶寬維持在高位的基礎(chǔ)上繼續(xù)往上頂。單純從部署模型的角度說(shuō)B300 最大的價(jià)值是把“400B 級(jí)模型單卡裝下”變成了現(xiàn)實(shí)。約 400B 規(guī)模的參數(shù)如果按 NVFP4 算權(quán)重約 200GB加上 KV cache 和激活288GB 單卡能裝得很輕松換成 FP8 的話權(quán)重約 400GB單卡裝不下只能拆雙卡吞吐直接打折。這也是為什么我們這次特別看重 NVFP4 的實(shí)測(cè)效果——它直接決定了能不能用最小的硬件拓?fù)渑茏畲蟮哪Ｐ汀?.2 CX8 網(wǎng)卡到底是不是模組自帶的這個(gè)熱搜問(wèn)題我們自己也糾結(jié)過(guò)。簡(jiǎn)單結(jié)論在 GB300 NVL72 這種機(jī)架級(jí)整機(jī)方案里CX8ConnectX-8網(wǎng)卡是集成在計(jì)算模組compute tray上的出廠即帶不需要單獨(dú)插 PCIe 卡但在自主組裝的 8 卡 HGX B300 基板上網(wǎng)絡(luò)接口還是走標(biāo)準(zhǔn) PCIe 插槽需要自己配網(wǎng)卡。我們這套 2 臺(tái) 8 卡機(jī)器屬于后者所以組網(wǎng)時(shí)額外配了 CX8 網(wǎng)卡。這里有個(gè)非常容易踩的坑CX8 的 firmware 版本和 mlx5 驅(qū)動(dòng)不匹配時(shí)RDMA 建鏈會(huì)間歇性失敗表現(xiàn)為主機(jī)之間 ping 正常、nccl 測(cè)試時(shí)好時(shí)壞非常難定位。后面排查章節(jié)我會(huì)詳細(xì)說(shuō)。還沒(méi)下單的朋友建議提前問(wèn)清楚供應(yīng)商機(jī)器帶的是什么網(wǎng)卡、什么固件版本、驅(qū)動(dòng)是否配套。這三個(gè)問(wèn)題每個(gè)都能省你半天時(shí)間。2.3 NVLink/NVSwitch 和 RDMA 的分工16 卡集群組網(wǎng)時(shí)很容易把兩個(gè)網(wǎng)絡(luò)混在一起。簡(jiǎn)單區(qū)分NVLink/NVSwitch 是卡與卡之間的高速互聯(lián)帶寬極高但只在單機(jī)內(nèi)有效同一 NVSwitch 域跨機(jī)器通信必須走 RDMA 網(wǎng)絡(luò)。對(duì)我們這次部署的影響是tensor parallel 的通信必須放在 NVLink 域內(nèi)pipeline parallel 或 DP 的梯度同步可以放 RDMA。所以 16 卡最自然的切法是兩組 TP8每組內(nèi)部 8 卡 NVLink 全互聯(lián)兩組之間用 RDMA 同步或處理不同的請(qǐng)求。這樣每個(gè) GPU 的權(quán)重分片只有原模型的 1/8通信壓力小吞吐最高。我們也試過(guò) TP16 跨機(jī)方案但因?yàn)榭鐧C(jī)通信走 400G RDMA相對(duì) NVLink 還是慢一個(gè)數(shù)量級(jí)實(shí)際吞吐反而掉 15%20%。3. NVFP4 量化顯存減半背后的硬件邏輯如果只看營(yíng)銷材料你可能覺得 NVFP4 就是“把 FP8 再砍一半變成 4 bit”聽起來(lái)很簡(jiǎn)單。但真正決定它能不能落地的是硬件在計(jì)算時(shí)怎么處理這些 4 bit 數(shù)據(jù)。這一節(jié)把原理講清楚后面遇到精度或者性能問(wèn)題就好排查了。3.1 FP4 不是簡(jiǎn)單的“多砍一位”NVFP4 是 NVIDIA Blackwell 架構(gòu)引入的 4-bit 浮點(diǎn)格式和傳統(tǒng)的 INT4 定點(diǎn)格式有本質(zhì)區(qū)別。FP4 保留了指數(shù)位動(dòng)態(tài)范圍比 INT4 大很多對(duì)權(quán)重分布不均勻的大模型更友好。具體來(lái)說(shuō)NVFP4 有兩種子格式E1M21 位指數(shù)、2 位尾數(shù)和 E2M12 位指數(shù)、1 位尾數(shù)分別應(yīng)對(duì)權(quán)重和激活的不同數(shù)值分布特性。在 B300 的 tensor core 里FP4 不是靠“把數(shù)據(jù)轉(zhuǎn)回 FP16 再算”來(lái)運(yùn)行的而是硬件直接支持 FP4 輸入的矩陣乘法。這意味著權(quán)重以 FP4 存儲(chǔ)在顯存里計(jì)算時(shí)不需要做解壓縮到高精度的步驟直接進(jìn) tensor core。這一步很關(guān)鍵它同時(shí)省了顯存帶寬和計(jì)算時(shí)間。打個(gè)比方如果上一代是“貨車?yán)浀絺}(cāng)庫(kù)再拆箱”那 B300 跑 NVFP4 就是“集裝箱直接放上托盤進(jìn)倉(cāng)庫(kù)”中間省掉了一次拆箱動(dòng)作。3.2 權(quán)重預(yù)量化 vs 運(yùn)行時(shí)量化GLM-5.2-NVFP4 是預(yù)量化權(quán)重文件在磁盤上就是 NVFP4 格式。加載時(shí) vLLM 直接加載進(jìn)顯存就行不需要在啟動(dòng)時(shí)跑一遍量化 kernel。Kimi-K3 我們測(cè)的是 BF16 到 FP8 的運(yùn)行時(shí)量化每次加載部署時(shí)要額外花幾分鐘做權(quán)重轉(zhuǎn)換而且轉(zhuǎn)換 kernel 還得吃一小部分顯存作為臨時(shí) buffer。在我們 16 卡集群上實(shí)測(cè)同一模型權(quán)重FP8 在線量化比 NVFP4 預(yù)量化每次冷啟動(dòng)多花 46 分鐘。別小看這幾分鐘日常發(fā)版、擴(kuò)副本、故障重啟都會(huì)遇到一天發(fā)三次版本就多了二十分鐘的無(wú)效等待。更重要的還是 decode 性能差異預(yù)量化的權(quán)重加載路徑更短token 生成階段的吞吐優(yōu)勢(shì)大約在 8%12%。如果你的模型支持預(yù)量化格式優(yōu)先選預(yù)量化版本。3.3 精度損失怎么驗(yàn)證4-bit 量化最讓人擔(dān)心的是精度。我們的驗(yàn)證辦法很簡(jiǎn)單拿 1000 條業(yè)務(wù)問(wèn)句分別用 FP16 基線、FP8、NVFP4 跑一遍對(duì)比輸出文本的 ROUGE-L 相似度和下游任務(wù)的準(zhǔn)確率。GLM-5.2-NVFP4 官方預(yù)量化版本在 ROUGE-L 上和 FP16 差不到 1 個(gè)點(diǎn)在數(shù)學(xué)和代碼任務(wù)上差距更小基本可以接受Kimi-K3 的 FP8 在線量化在長(zhǎng)上下文抽取任務(wù)上偶爾會(huì)漏細(xì)節(jié)需要結(jié)合業(yè)務(wù)容錯(cuò)度決定是否啟用。有一點(diǎn)提醒不要只看平均指標(biāo)要按任務(wù)類型拆開看。我們遇到過(guò)某類表格理解任務(wù)在 NVFP4 下降幅超過(guò) 5%但平均指標(biāo)只有 1% 的情況。如果你有分類、抽取這類對(duì)數(shù)值敏感的業(yè)務(wù)建議單獨(dú)跑一遍回歸測(cè)試再定方案。4. 部署配置與吞吐調(diào)優(yōu)實(shí)戰(zhàn)這一節(jié)是最實(shí)操的部分。我們會(huì)從并行策略選型一直講到 vLLM 最終配置再貼一組實(shí)測(cè)吞吐數(shù)據(jù)。所有參數(shù)都是我們?cè)?16 卡 B300 上實(shí)際跑過(guò)、穩(wěn)定復(fù)現(xiàn)過(guò)的你可以直接拿去做 baseline。4.1 并行策略怎么選16 卡集群部署兩個(gè)模型每個(gè)模型各占 8 卡TP8這是最標(biāo)準(zhǔn)的做法。GLM-5.2-NVFP4 權(quán)重約 200GB約 400B 規(guī)模參數(shù)按 NVFP4 折算TP8 時(shí)每卡權(quán)重 25GB加上每卡預(yù)留的 150GB 以上 KV cache 空間能支持非常大的并發(fā) batch。Kimi-K3 因?yàn)橛玫氖?FP8權(quán)重約 400GBTP8 時(shí)每卡權(quán)重 50GBKV cache 空間被壓縮但依然夠用。為了對(duì)比我們也試過(guò) TP16跨機(jī)。結(jié)論前面說(shuō)了跨機(jī)通信帶寬成為瓶頸高并發(fā)下吞吐反而下降。所以如果模型能塞進(jìn)單機(jī) 8 卡盡量別跨機(jī)做 TP。另外如果模型實(shí)在太大需要跨機(jī)建議用 pipeline parallel 而不是把 TP 拉滿跨機(jī)通信量完全不是一個(gè)量級(jí)。4.2 vLLM 配置明細(xì)直接貼我們最終用的 vLLM 啟動(dòng)參數(shù)以 GLM-5.2-NVFP4 為例python -m vllm.entrypoints.openai.api_server \ --model /data/models/glm-5.2-nvfp4 \ --tensor-parallel-size 8 \ --gpu-memory-utilization 0.92 \ --max-num-seqs 256 \ --max-model-len 131072 \ --enable-prefix-caching \ --kv-cache-dtype fp8 \ --enforce-eager \ --disable-log-requests參數(shù)含義拆開講一下--tensor-parallel-size 8TP 并行度8對(duì)應(yīng)單機(jī) 8 卡--gpu-memory-utilization 0.92顯存利用率 92%剩下的留給 CUDA context 和碎片--max-num-seqs 256單個(gè) GPU 允許同時(shí)調(diào)度的序列數(shù)上限這個(gè)值是吞吐和延遲平衡的關(guān)鍵--max-model-len 131072最大上下文長(zhǎng)度 128K--enable-prefix-caching打開自動(dòng)前綴緩存--kv-cache-dtype fp8KV cache 用 FP8 存儲(chǔ)比 FP16 省一半顯存--enforce-eager關(guān)閉 CUDA graphFP4 模型在部分 CUDA graph 捕獲環(huán)境下會(huì)和量化 kernel 沖突這個(gè)坑后面細(xì)說(shuō)。4.3 實(shí)測(cè)吞吐數(shù)據(jù)壓測(cè)用的是自研的負(fù)載工具混合場(chǎng)景模擬線上真實(shí)請(qǐng)求45% 多輪對(duì)話、30% 單輪問(wèn)答、25% 長(zhǎng)文檔處理并發(fā)從 32 逐步加到 512每檔跑 10 分鐘。下面這組成績(jī)是穩(wěn)定復(fù)現(xiàn)過(guò)的數(shù)據(jù)已做脫敏處理配置模型并發(fā)decode 吞吐(tokens/s)TTFT P99(ms)TPOT P99(ms)TP8GLM-5.2-NVFP412818,50062028TP8GLM-5.2-NVFP425632,00098045TP8GLM-5.2-NVFP451235,2003200110TP8Kimi-K3 FP812813,20078038TP8Kimi-K3 FP825622,400150068TP8Kimi-K3 FP851224,1004800180幾個(gè)解讀并發(fā) 128 到 256吞吐提升明顯說(shuō)明之前 batch 太小顯存帶寬沒(méi)吃滿并發(fā) 256 到 512吞吐只有小幅提升但 TTFT 漲了 2 倍以上說(shuō)明開始進(jìn)入排隊(duì)區(qū)Kimi-K3 FP8 全程比 GLM-5.2-NVFP4 低 30% 左右權(quán)重更大、每步讀顯存帶寬更多是主因。需要強(qiáng)調(diào)不同模型版本、不同量化方案、不同請(qǐng)求分布下數(shù)據(jù)會(huì)有差異這里給的是我們這套環(huán)境的基線。如果你拿到的數(shù)據(jù)比我們低很多優(yōu)先檢查是不是 KV cache 沒(méi)配夠或者并發(fā)沒(méi)打上去。4.4 batch、KV cache、延遲的平衡--max-num-seqs不是越大越好。我們實(shí)測(cè) 256 是最佳點(diǎn)512 時(shí)吞吐雖然還能漲一點(diǎn)但 P99 TTFT 已經(jīng)明顯惡化線上體驗(yàn)受損。核心原因batch 太大時(shí)prefill 和 decode 混跑prefill 的長(zhǎng)序列會(huì)占用大量 GPU 算力導(dǎo)致 decode 步長(zhǎng)得不到及時(shí)調(diào)度每個(gè)請(qǐng)求的 TPOT 都變慢。這個(gè)階段我們的調(diào)優(yōu)建議是先把 batch 從 32 開始翻倍試每檔跑 10 分鐘看 TTFT/TPOT 的 P99 曲線找到吞吐不再線性增長(zhǎng)的那個(gè)點(diǎn)然后往回退一檔。不要光看平均吞吐要盯 P99尤其是線上有交互場(chǎng)景時(shí)。5. 緩存命中與 P-D 分離部署前面說(shuō)了緩存命中是這次測(cè)試?yán)镒钪档眉?xì)講的部分。如果說(shuō) NVFP4 是省了一半顯存帶寬那 prefix cache 加 P-D 分離就是把 prefill 計(jì)算量砍掉一大半。這兩個(gè)收益方向不同但疊加起來(lái)效果非?？捎^。5.1 Prefix Cache 的工作原理大模型推理時(shí)KV cache 是逐 token 計(jì)算的。如果兩個(gè)請(qǐng)求開頭部分相同比如相同的 system prompt、相同的 few-shot 示例它們的 KV cache 是可以復(fù)用的。vLLM 的 automatic prefix caching 和 SGLang 的 RadixAttention 都是干這個(gè)的差別在于緩存的組織方式和淘汰策略。實(shí)際業(yè)務(wù)里絕大多數(shù)對(duì)話請(qǐng)求都帶著同一個(gè)系統(tǒng)提示詞這部分可能占輸入 tokens 的 30%60%。把這些重復(fù)計(jì)算省掉prefill 壓力能降一大截TTFT 直接受益。我們?cè)?GLM-5.2-NVFP4 上測(cè)過(guò)純單輪問(wèn)答場(chǎng)景如果系統(tǒng)提示詞 2000 tokens、請(qǐng)求平均 3000 tokens打開 prefix caching 后 prefill 計(jì)算量減少約 25%30%TTFT 平均降 35% 左右。如果業(yè)務(wù)里你們用的是固定超長(zhǎng) system prompt收益會(huì)更夸張。5.2 P-D 分離部署的配置要點(diǎn)P-D separationprefill-decode 分離是更進(jìn)一步的做法把 prefill 和 decode 拆到不同的實(shí)例上prefill 實(shí)例負(fù)責(zé)長(zhǎng)輸入計(jì)算和 KV cache 生成decode 實(shí)例負(fù)責(zé) token 生成兩者之間通過(guò)共享 KV cache 或調(diào)度器傳遞狀態(tài)。我們最終部署形態(tài)是16 卡拆成 2 個(gè) prefill 實(shí)例加 2 個(gè) decode 實(shí)例prefill 實(shí)例負(fù)責(zé)接收新請(qǐng)求、計(jì)算初始 KV cache、輸出給 decode 實(shí)例。這樣做的優(yōu)勢(shì)是 prefill 和 decode 互不搶資源長(zhǎng)上下文預(yù)填充不再拖慢在線 token 生成。代價(jià)是架構(gòu)復(fù)雜度上來(lái)了需要額外的調(diào)度組件。配置上有幾個(gè)關(guān)鍵參數(shù)在 vLLM 中使用--served-model-name配合預(yù)填充池/解碼池配置或者用 SGLang 的 PD 分離參數(shù)prefill 和 decode 實(shí)例要共享前綴緩存存儲(chǔ)否則緩存命中率會(huì)直線下降scheduler 的隊(duì)列權(quán)重要配好prefill 隊(duì)列和 decode 隊(duì)列的比例按“輸入 tokens 與輸出 tokens 的 1:31:5”來(lái)估如果輸出偏長(zhǎng)decode 實(shí)例要多配。5.3 命中率數(shù)據(jù)與優(yōu)化技巧部署 P-D 分離加 prefix caching 之后我們跑了一組業(yè)務(wù)流量回放場(chǎng)景無(wú)緩存僅 prefix cacheP-D prefix cache多輪對(duì)話命中率0%68%68%長(zhǎng)文檔問(wèn)答命中率0%21%21%綜合 prefill 吞吐(tokens/s)8,40015,20019,800TTFT P99(ms)1,200780390多輪對(duì)話的命中率最高68%因?yàn)槊枯喍紟е鴼v史上下文和固定的 system prompt長(zhǎng)文檔問(wèn)答命中率低21%因?yàn)槊總€(gè)文檔內(nèi)容差異大。綜合下來(lái)P-D 分離讓 prefill 有效吞吐從 8.4K 提到 19.8KTTFT 從 1.2s 壓到 390ms這個(gè)提升非?？捎^。命中率優(yōu)化的幾個(gè)技巧system prompt 盡量放在請(qǐng)求最前面有些框架的 prefix cache 是按前綴匹配的放中間會(huì)打斷緩存命中多輪對(duì)話要使用框架自帶的聊天模板復(fù)用不要每次重拼完整歷史那樣等于把已經(jīng)算過(guò)的 KV cash 全部作廢緩存條目不要設(shè)得過(guò)小太小會(huì)導(dǎo)致高頻請(qǐng)求的緩存頻繁被淘汰命中率反而下降如果業(yè)務(wù)里存在幾十個(gè)固定請(qǐng)求模板可以考慮在入口層做模板歸一化把相同前綴的請(qǐng)求打到一個(gè)實(shí)例上。6. 碰到的坑和排查實(shí)錄這部分是花錢買來(lái)的經(jīng)驗(yàn)。硬件剛到手的時(shí)候我們覺得 B300 這種新卡應(yīng)該很穩(wěn)定結(jié)果測(cè)試期間遇到了好幾個(gè)詭異問(wèn)題每個(gè)都能讓人懷疑人生。整理出來(lái)希望你們少走彎路。6.1 B300 集群的散熱與維護(hù)B300 功耗比 B200 更高8 卡整機(jī)的滿載功率輕松超過(guò) 15kW對(duì)機(jī)房的散熱和供電要求非常高。我們測(cè)試期間遇到過(guò)一次“性能懸崖”跑滿 512 并發(fā) 15 分鐘后整體吞吐突然掉了 40%檢查發(fā)現(xiàn) GPU 溫度到了 96°C 觸發(fā)降頻。調(diào)整機(jī)房空調(diào)風(fēng)道和機(jī)柜位置后溫度穩(wěn)定在 82°C 左右問(wèn)題解決。建議B300 集群上線前做一次滿載熱循環(huán)測(cè)試至少連續(xù)跑 1 小時(shí)以上觀察溫度和時(shí)鐘曲線散熱不足的機(jī)房不要貿(mào)然上高并發(fā)壓測(cè)容易把卡降頻甚至觸發(fā)保護(hù)性關(guān)機(jī)。另外日常維護(hù)要多看nvidia-smi dmon采集的溫度歷史不要等出故障再排查。6.2 CX8 網(wǎng)絡(luò)固件導(dǎo)致的 RDMA 偶發(fā)斷連這個(gè)坑前面提過(guò)這里展開講。癥狀是NCCL 全互聯(lián)測(cè)試all_reduce有時(shí)能過(guò)、有時(shí)在某個(gè)節(jié)點(diǎn)上卡住重試幾次又恢復(fù)正常GPU 直連通信偶爾報(bào)錯(cuò)mlx5_0: timeout。排查了兩輪硬件都沒(méi)問(wèn)題最后發(fā)現(xiàn)是 CX8 網(wǎng)卡固件版本比驅(qū)動(dòng)的預(yù)期版本舊了一大截升級(jí)固件后問(wèn)題完全消失。排查方法供參考# 查看網(wǎng)卡固件版本 mlxup --query # 檢查驅(qū)動(dòng)與固件匹配情況 modinfo mlx5_core | head # 跑 NCCL 全互聯(lián)測(cè)試 nccl-tests/build/all_reduce_perf -b 1G -f 2 -g 8 -n 10遇到過(guò)類似問(wèn)題的話別急著換硬件先查固件和驅(qū)動(dòng)的版本矩陣。RDMA 的偶發(fā)問(wèn)題有相當(dāng)大比例是固件/驅(qū)動(dòng)不配套導(dǎo)致的。6.3 FP4 模型和 CUDA graph 的沖突我們第一版配置用了 vLLM 默認(rèn)的 CUDA graph 加速啟動(dòng)時(shí)報(bào)了類似Cannot capture graph with quantized ops的錯(cuò)誤或者能啟動(dòng)但跑幾個(gè) batch 后隨機(jī)報(bào)CUDA error: illegal memory access。排查后確認(rèn)是 CUDA graph 捕獲和 FP4 量化 kernel 的某些組合路徑有兼容性問(wèn)題。解法很直接--enforce-eager關(guān)掉 CUDA graph。代價(jià)是每步調(diào)度開銷大一點(diǎn)實(shí)測(cè)吞吐影響在 5% 以內(nèi)但穩(wěn)定性大幅提升。如果框架后續(xù)版本修了這個(gè)問(wèn)題可以再開回來(lái)但建議先在壓測(cè)環(huán)境驗(yàn)證 30 分鐘以上再上生產(chǎn)。6.4 常見問(wèn)題速查現(xiàn)象可能原因建議處理吞吐跑一會(huì)驟降GPU 溫度過(guò)高觸發(fā)降頻檢查散熱、調(diào)整負(fù)載NCCL/遠(yuǎn)端通信時(shí)好時(shí)壞網(wǎng)卡固件/驅(qū)動(dòng)不匹配升級(jí)固件、跑 nccl-tests 驗(yàn)證啟動(dòng)報(bào) CUDA graph 錯(cuò)誤FP4 kernel 與 graph 捕獲沖突加--enforce-eagerKV cache 命中率一直很低請(qǐng)求結(jié)構(gòu)不連續(xù)/緩存條目太小調(diào)整緩存淘汰策略、優(yōu)化 system prompt 位置FP4 精度不達(dá)標(biāo)模型本身不適合 4-bit/縮放因子異常用 ROUGE 等指標(biāo)逐任務(wù)驗(yàn)證必要時(shí)退回 FP8跨機(jī) TP 吞吐低于預(yù)期跨節(jié)點(diǎn)走 RDMA 帶寬不足切 TP8 本地部署跨機(jī)只做數(shù)據(jù)并行最后說(shuō)點(diǎn)個(gè)人體會(huì)。這次實(shí)測(cè)最大的感受是B300 的硬件底子確實(shí)強(qiáng)但真正拉開體驗(yàn)差距的是緩存的命中率和部署配置的細(xì)節(jié)。NVFP4 讓 400B 級(jí)模型在單卡跑成為了現(xiàn)實(shí)而 prefix cache 加 P-D 分離讓同樣的硬件跑出了接近翻倍的業(yè)務(wù)吞吐。如果你也在評(píng)估 B300 集群我建議先把緩存命中率這件事想清楚這比堆機(jī)器更劃算。另外跟 B300 一起到的 CX8 固件問(wèn)題我們前前后后折騰了大半天建議你拿到機(jī)器第一件事就去查固件版本別等上了生產(chǎn)才發(fā)現(xiàn)。 B300集群實(shí)戰(zhàn)：NVFP4量化與P-D分離部署大模型吞吐調(diào)優(yōu)
1. 為什么用 B300 跑這兩個(gè)模型B300 出來(lái)之后我們內(nèi)部就在盤算手上的模型服務(wù)要不要遷過(guò)去。手里正好有 GLM-5.2-NVFP4 和 Kimi-K3 兩組測(cè)試權(quán)重前者是官方直接發(fā)布的 NVFP4 量化版本后者我們先用 BF16 跑基線、再切 FP8 對(duì)比。在 16 卡 B300 集群上測(cè)出來(lái)的吞吐、緩存命中和部署手感基本代表了當(dāng)前 4-bit 推理的主流水平。這篇文章不寫云里霧里的理論就把我們拿到機(jī)器后從零搭環(huán)境、測(cè)壓、調(diào)參、踩坑的全過(guò)程攤開聊。先說(shuō)結(jié)論方便沒(méi)時(shí)間看完全文的同學(xué)16 卡 B300 拆成 2 組 TP8 副本跑 GLM-5.2-NVFP4256 并發(fā)、共享系統(tǒng)提示詞占比約 70% 的混合負(fù)載綜合吞吐大約比同模型 FP8 版本高 1.61.9 倍P-D 分離加 prefix cache 配置到位后輸入側(cè)有效吞吐能翻 2 倍以上TTFT首 token 延遲從 1.2s 壓到 400ms 以內(nèi)NVFP4 在 B300 上不是單純省顯存它把權(quán)重搬移量砍半decode 階段直接吃滿內(nèi)存帶寬的增益網(wǎng)絡(luò)層有一個(gè)坑CX8 網(wǎng)卡的歸屬和固件版本必須提前確認(rèn)我們?yōu)檫@個(gè)排查了整整一個(gè)下午。這篇內(nèi)容適合誰(shuí)看正在做 B300/GB300 集群評(píng)估的 SRE、推理框架開發(fā)、運(yùn)維或者想在 vLLM/SGLang 上部署 4-bit 量化大模型的同學(xué)。新手也能看原理部分我會(huì)盡量講人話參數(shù)部分可以直接抄。1.1 模型版本的差異不是名字后綴那么簡(jiǎn)單GLM-5.2-NVFP4 不是“GLM-5.2 順手壓到 4bit”這么簡(jiǎn)單。官方這次是把權(quán)重直接按 NVFP4 格式重新規(guī)整過(guò)包括通道粒度per-channel/per-group的縮放因子都預(yù)計(jì)算好推理時(shí)不需要在 GPU 上臨時(shí)做量化省掉了批處理場(chǎng)景下重復(fù)的 quantization kernel 開銷。Kimi-K3 目前沒(méi)有官方 NVFP4 版本所以我們測(cè)的是 BF16 基線和 FP8 在線量化兩類配置作為對(duì)照組。為什么在意這一點(diǎn)因?yàn)椤邦A(yù)量化”和“運(yùn)行時(shí)量化”在高吞吐場(chǎng)景下差距巨大。運(yùn)行時(shí)把 BF16/FP16 轉(zhuǎn)成 FP8 或 FP4 需要額外的計(jì)算 kernel雖然 B300 的 tensor core 處理這些很快但在 memory-bound 的 decode 階段任何多余 kernel 都會(huì)擠占內(nèi)存帶寬配額。GLM-5.2-NVFP4 這種權(quán)重直接以 NVFP4 格式存放的方式加載時(shí)就能直接被 tensor core 讀取完全省掉這部分開銷。1.2 測(cè)試指標(biāo)的選定我們這次重點(diǎn)看三個(gè)指標(biāo)吞吐tokens/s分 decode 吞吐和 prefill 吞吐統(tǒng)計(jì)取穩(wěn)定壓測(cè) 10 分鐘以上的平均值緩存命中率%輸入 tokens 中直接復(fù)用 KV cache 的比例反映 prefix cache 和 P-D 分離的整體配置效果TTFT / TPOT首 token 延遲和每 token 延遲高吞吐場(chǎng)景不能只盯著吞吐端到端體驗(yàn)要能壓住 P99 延遲。說(shuō)實(shí)話跑完一輪完整壓測(cè)之后我的體感是單卡性能是底座但真正拉開差距的地方在“緩存命中率”和“調(diào)度策略”。同樣一批請(qǐng)求把 prefix cache 配好之后的綜合吞吐和沒(méi)配相比差距大到離譜。所以后面我用一大節(jié)專門講緩存命中這部分是最值得抄作業(yè)的。2. 16 卡集群的硬件拓?fù)渑c網(wǎng)絡(luò)細(xì)節(jié)這次測(cè)試用的集群是 2 臺(tái) B300 整機(jī)每臺(tái) 8 卡組成 16 卡環(huán)境。每張 B300 是 288GB HBM3e內(nèi)存帶寬標(biāo)稱約 8TB/s單卡 FP4 稀疏算力比 B200 又漲了一截。8 卡之間通過(guò) NVLink-C2C 加 NVSwitch 全互聯(lián)跨節(jié)點(diǎn)走 InfiniBand NDR 400Gbps RDMA。整體拓?fù)洳粡?fù)雜但有幾個(gè)點(diǎn)不確認(rèn)清楚后面調(diào)試會(huì)非常折磨人。2.1 B300 和上一代的差距在哪很多人問(wèn) B300 的“上一代”是啥。按 NVIDIA 這代的命名邏輯B300 的上一代核心是 B200Blackwell 架構(gòu)再往前是 H200/H100Hopper 架構(gòu)。B300 和 B200 的關(guān)系有點(diǎn)像當(dāng)年 A100 到 H100 的演進(jìn)同一個(gè)架構(gòu)代系但把 HBM 容量、帶寬和算力做了整體提升。B300 最大變化是顯存從 192GB 提到 288GBHBM3e 的堆疊容量變大帶寬維持在高位的基礎(chǔ)上繼續(xù)往上頂。單純從部署模型的角度說(shuō)B300 最大的價(jià)值是把“400B 級(jí)模型單卡裝下”變成了現(xiàn)實(shí)。約 400B 規(guī)模的參數(shù)如果按 NVFP4 算權(quán)重約 200GB加上 KV cache 和激活288GB 單卡能裝得很輕松換成 FP8 的話權(quán)重約 400GB單卡裝不下只能拆雙卡吞吐直接打折。這也是為什么我們這次特別看重 NVFP4 的實(shí)測(cè)效果——它直接決定了能不能用最小的硬件拓?fù)渑茏畲蟮哪Ｐ汀?.2 CX8 網(wǎng)卡到底是不是模組自帶的這個(gè)熱搜問(wèn)題我們自己也糾結(jié)過(guò)。簡(jiǎn)單結(jié)論在 GB300 NVL72 這種機(jī)架級(jí)整機(jī)方案里CX8ConnectX-8網(wǎng)卡是集成在計(jì)算模組compute tray上的出廠即帶不需要單獨(dú)插 PCIe 卡但在自主組裝的 8 卡 HGX B300 基板上網(wǎng)絡(luò)接口還是走標(biāo)準(zhǔn) PCIe 插槽需要自己配網(wǎng)卡。我們這套 2 臺(tái) 8 卡機(jī)器屬于后者所以組網(wǎng)時(shí)額外配了 CX8 網(wǎng)卡。這里有個(gè)非常容易踩的坑CX8 的 firmware 版本和 mlx5 驅(qū)動(dòng)不匹配時(shí)RDMA 建鏈會(huì)間歇性失敗表現(xiàn)為主機(jī)之間 ping 正常、nccl 測(cè)試時(shí)好時(shí)壞非常難定位。后面排查章節(jié)我會(huì)詳細(xì)說(shuō)。還沒(méi)下單的朋友建議提前問(wèn)清楚供應(yīng)商機(jī)器帶的是什么網(wǎng)卡、什么固件版本、驅(qū)動(dòng)是否配套。這三個(gè)問(wèn)題每個(gè)都能省你半天時(shí)間。2.3 NVLink/NVSwitch 和 RDMA 的分工16 卡集群組網(wǎng)時(shí)很容易把兩個(gè)網(wǎng)絡(luò)混在一起。簡(jiǎn)單區(qū)分NVLink/NVSwitch 是卡與卡之間的高速互聯(lián)帶寬極高但只在單機(jī)內(nèi)有效同一 NVSwitch 域跨機(jī)器通信必須走 RDMA 網(wǎng)絡(luò)。對(duì)我們這次部署的影響是tensor parallel 的通信必須放在 NVLink 域內(nèi)pipeline parallel 或 DP 的梯度同步可以放 RDMA。所以 16 卡最自然的切法是兩組 TP8每組內(nèi)部 8 卡 NVLink 全互聯(lián)兩組之間用 RDMA 同步或處理不同的請(qǐng)求。這樣每個(gè) GPU 的權(quán)重分片只有原模型的 1/8通信壓力小吞吐最高。我們也試過(guò) TP16 跨機(jī)方案但因?yàn)榭鐧C(jī)通信走 400G RDMA相對(duì) NVLink 還是慢一個(gè)數(shù)量級(jí)實(shí)際吞吐反而掉 15%20%。3. NVFP4 量化顯存減半背后的硬件邏輯如果只看營(yíng)銷材料你可能覺得 NVFP4 就是“把 FP8 再砍一半變成 4 bit”聽起來(lái)很簡(jiǎn)單。但真正決定它能不能落地的是硬件在計(jì)算時(shí)怎么處理這些 4 bit 數(shù)據(jù)。這一節(jié)把原理講清楚后面遇到精度或者性能問(wèn)題就好排查了。3.1 FP4 不是簡(jiǎn)單的“多砍一位”NVFP4 是 NVIDIA Blackwell 架構(gòu)引入的 4-bit 浮點(diǎn)格式和傳統(tǒng)的 INT4 定點(diǎn)格式有本質(zhì)區(qū)別。FP4 保留了指數(shù)位動(dòng)態(tài)范圍比 INT4 大很多對(duì)權(quán)重分布不均勻的大模型更友好。具體來(lái)說(shuō)NVFP4 有兩種子格式E1M21 位指數(shù)、2 位尾數(shù)和 E2M12 位指數(shù)、1 位尾數(shù)分別應(yīng)對(duì)權(quán)重和激活的不同數(shù)值分布特性。在 B300 的 tensor core 里FP4 不是靠“把數(shù)據(jù)轉(zhuǎn)回 FP16 再算”來(lái)運(yùn)行的而是硬件直接支持 FP4 輸入的矩陣乘法。這意味著權(quán)重以 FP4 存儲(chǔ)在顯存里計(jì)算時(shí)不需要做解壓縮到高精度的步驟直接進(jìn) tensor core。這一步很關(guān)鍵它同時(shí)省了顯存帶寬和計(jì)算時(shí)間。打個(gè)比方如果上一代是“貨車?yán)浀絺}(cāng)庫(kù)再拆箱”那 B300 跑 NVFP4 就是“集裝箱直接放上托盤進(jìn)倉(cāng)庫(kù)”中間省掉了一次拆箱動(dòng)作。3.2 權(quán)重預(yù)量化 vs 運(yùn)行時(shí)量化GLM-5.2-NVFP4 是預(yù)量化權(quán)重文件在磁盤上就是 NVFP4 格式。加載時(shí) vLLM 直接加載進(jìn)顯存就行不需要在啟動(dòng)時(shí)跑一遍量化 kernel。Kimi-K3 我們測(cè)的是 BF16 到 FP8 的運(yùn)行時(shí)量化每次加載部署時(shí)要額外花幾分鐘做權(quán)重轉(zhuǎn)換而且轉(zhuǎn)換 kernel 還得吃一小部分顯存作為臨時(shí) buffer。在我們 16 卡集群上實(shí)測(cè)同一模型權(quán)重FP8 在線量化比 NVFP4 預(yù)量化每次冷啟動(dòng)多花 46 分鐘。別小看這幾分鐘日常發(fā)版、擴(kuò)副本、故障重啟都會(huì)遇到一天發(fā)三次版本就多了二十分鐘的無(wú)效等待。更重要的還是 decode 性能差異預(yù)量化的權(quán)重加載路徑更短token 生成階段的吞吐優(yōu)勢(shì)大約在 8%12%。如果你的模型支持預(yù)量化格式優(yōu)先選預(yù)量化版本。3.3 精度損失怎么驗(yàn)證4-bit 量化最讓人擔(dān)心的是精度。我們的驗(yàn)證辦法很簡(jiǎn)單拿 1000 條業(yè)務(wù)問(wèn)句分別用 FP16 基線、FP8、NVFP4 跑一遍對(duì)比輸出文本的 ROUGE-L 相似度和下游任務(wù)的準(zhǔn)確率。GLM-5.2-NVFP4 官方預(yù)量化版本在 ROUGE-L 上和 FP16 差不到 1 個(gè)點(diǎn)在數(shù)學(xué)和代碼任務(wù)上差距更小基本可以接受Kimi-K3 的 FP8 在線量化在長(zhǎng)上下文抽取任務(wù)上偶爾會(huì)漏細(xì)節(jié)需要結(jié)合業(yè)務(wù)容錯(cuò)度決定是否啟用。有一點(diǎn)提醒不要只看平均指標(biāo)要按任務(wù)類型拆開看。我們遇到過(guò)某類表格理解任務(wù)在 NVFP4 下降幅超過(guò) 5%但平均指標(biāo)只有 1% 的情況。如果你有分類、抽取這類對(duì)數(shù)值敏感的業(yè)務(wù)建議單獨(dú)跑一遍回歸測(cè)試再定方案。4. 部署配置與吞吐調(diào)優(yōu)實(shí)戰(zhàn)這一節(jié)是最實(shí)操的部分。我們會(huì)從并行策略選型一直講到 vLLM 最終配置再貼一組實(shí)測(cè)吞吐數(shù)據(jù)。所有參數(shù)都是我們?cè)?16 卡 B300 上實(shí)際跑過(guò)、穩(wěn)定復(fù)現(xiàn)過(guò)的你可以直接拿去做 baseline。4.1 并行策略怎么選16 卡集群部署兩個(gè)模型每個(gè)模型各占 8 卡TP8這是最標(biāo)準(zhǔn)的做法。GLM-5.2-NVFP4 權(quán)重約 200GB約 400B 規(guī)模參數(shù)按 NVFP4 折算TP8 時(shí)每卡權(quán)重 25GB加上每卡預(yù)留的 150GB 以上 KV cache 空間能支持非常大的并發(fā) batch。Kimi-K3 因?yàn)橛玫氖?FP8權(quán)重約 400GBTP8 時(shí)每卡權(quán)重 50GBKV cache 空間被壓縮但依然夠用。為了對(duì)比我們也試過(guò) TP16跨機(jī)。結(jié)論前面說(shuō)了跨機(jī)通信帶寬成為瓶頸高并發(fā)下吞吐反而下降。所以如果模型能塞進(jìn)單機(jī) 8 卡盡量別跨機(jī)做 TP。另外如果模型實(shí)在太大需要跨機(jī)建議用 pipeline parallel 而不是把 TP 拉滿跨機(jī)通信量完全不是一個(gè)量級(jí)。4.2 vLLM 配置明細(xì)直接貼我們最終用的 vLLM 啟動(dòng)參數(shù)以 GLM-5.2-NVFP4 為例python -m vllm.entrypoints.openai.api_server \ --model /data/models/glm-5.2-nvfp4 \ --tensor-parallel-size 8 \ --gpu-memory-utilization 0.92 \ --max-num-seqs 256 \ --max-model-len 131072 \ --enable-prefix-caching \ --kv-cache-dtype fp8 \ --enforce-eager \ --disable-log-requests參數(shù)含義拆開講一下--tensor-parallel-size 8TP 并行度8對(duì)應(yīng)單機(jī) 8 卡--gpu-memory-utilization 0.92顯存利用率 92%剩下的留給 CUDA context 和碎片--max-num-seqs 256單個(gè) GPU 允許同時(shí)調(diào)度的序列數(shù)上限這個(gè)值是吞吐和延遲平衡的關(guān)鍵--max-model-len 131072最大上下文長(zhǎng)度 128K--enable-prefix-caching打開自動(dòng)前綴緩存--kv-cache-dtype fp8KV cache 用 FP8 存儲(chǔ)比 FP16 省一半顯存--enforce-eager關(guān)閉 CUDA graphFP4 模型在部分 CUDA graph 捕獲環(huán)境下會(huì)和量化 kernel 沖突這個(gè)坑后面細(xì)說(shuō)。4.3 實(shí)測(cè)吞吐數(shù)據(jù)壓測(cè)用的是自研的負(fù)載工具混合場(chǎng)景模擬線上真實(shí)請(qǐng)求45% 多輪對(duì)話、30% 單輪問(wèn)答、25% 長(zhǎng)文檔處理并發(fā)從 32 逐步加到 512每檔跑 10 分鐘。下面這組成績(jī)是穩(wěn)定復(fù)現(xiàn)過(guò)的數(shù)據(jù)已做脫敏處理配置模型并發(fā)decode 吞吐(tokens/s)TTFT P99(ms)TPOT P99(ms)TP8GLM-5.2-NVFP412818,50062028TP8GLM-5.2-NVFP425632,00098045TP8GLM-5.2-NVFP451235,2003200110TP8Kimi-K3 FP812813,20078038TP8Kimi-K3 FP825622,400150068TP8Kimi-K3 FP851224,1004800180幾個(gè)解讀并發(fā) 128 到 256吞吐提升明顯說(shuō)明之前 batch 太小顯存帶寬沒(méi)吃滿并發(fā) 256 到 512吞吐只有小幅提升但 TTFT 漲了 2 倍以上說(shuō)明開始進(jìn)入排隊(duì)區(qū)Kimi-K3 FP8 全程比 GLM-5.2-NVFP4 低 30% 左右權(quán)重更大、每步讀顯存帶寬更多是主因。需要強(qiáng)調(diào)不同模型版本、不同量化方案、不同請(qǐng)求分布下數(shù)據(jù)會(huì)有差異這里給的是我們這套環(huán)境的基線。如果你拿到的數(shù)據(jù)比我們低很多優(yōu)先檢查是不是 KV cache 沒(méi)配夠或者并發(fā)沒(méi)打上去。4.4 batch、KV cache、延遲的平衡--max-num-seqs不是越大越好。我們實(shí)測(cè) 256 是最佳點(diǎn)512 時(shí)吞吐雖然還能漲一點(diǎn)但 P99 TTFT 已經(jīng)明顯惡化線上體驗(yàn)受損。核心原因batch 太大時(shí)prefill 和 decode 混跑prefill 的長(zhǎng)序列會(huì)占用大量 GPU 算力導(dǎo)致 decode 步長(zhǎng)得不到及時(shí)調(diào)度每個(gè)請(qǐng)求的 TPOT 都變慢。這個(gè)階段我們的調(diào)優(yōu)建議是先把 batch 從 32 開始翻倍試每檔跑 10 分鐘看 TTFT/TPOT 的 P99 曲線找到吞吐不再線性增長(zhǎng)的那個(gè)點(diǎn)然后往回退一檔。不要光看平均吞吐要盯 P99尤其是線上有交互場(chǎng)景時(shí)。5. 緩存命中與 P-D 分離部署前面說(shuō)了緩存命中是這次測(cè)試?yán)镒钪档眉?xì)講的部分。如果說(shuō) NVFP4 是省了一半顯存帶寬那 prefix cache 加 P-D 分離就是把 prefill 計(jì)算量砍掉一大半。這兩個(gè)收益方向不同但疊加起來(lái)效果非?？捎^。5.1 Prefix Cache 的工作原理大模型推理時(shí)KV cache 是逐 token 計(jì)算的。如果兩個(gè)請(qǐng)求開頭部分相同比如相同的 system prompt、相同的 few-shot 示例它們的 KV cache 是可以復(fù)用的。vLLM 的 automatic prefix caching 和 SGLang 的 RadixAttention 都是干這個(gè)的差別在于緩存的組織方式和淘汰策略。實(shí)際業(yè)務(wù)里絕大多數(shù)對(duì)話請(qǐng)求都帶著同一個(gè)系統(tǒng)提示詞這部分可能占輸入 tokens 的 30%60%。把這些重復(fù)計(jì)算省掉prefill 壓力能降一大截TTFT 直接受益。我們?cè)?GLM-5.2-NVFP4 上測(cè)過(guò)純單輪問(wèn)答場(chǎng)景如果系統(tǒng)提示詞 2000 tokens、請(qǐng)求平均 3000 tokens打開 prefix caching 后 prefill 計(jì)算量減少約 25%30%TTFT 平均降 35% 左右。如果業(yè)務(wù)里你們用的是固定超長(zhǎng) system prompt收益會(huì)更夸張。5.2 P-D 分離部署的配置要點(diǎn)P-D separationprefill-decode 分離是更進(jìn)一步的做法把 prefill 和 decode 拆到不同的實(shí)例上prefill 實(shí)例負(fù)責(zé)長(zhǎng)輸入計(jì)算和 KV cache 生成decode 實(shí)例負(fù)責(zé) token 生成兩者之間通過(guò)共享 KV cache 或調(diào)度器傳遞狀態(tài)。我們最終部署形態(tài)是16 卡拆成 2 個(gè) prefill 實(shí)例加 2 個(gè) decode 實(shí)例prefill 實(shí)例負(fù)責(zé)接收新請(qǐng)求、計(jì)算初始 KV cache、輸出給 decode 實(shí)例。這樣做的優(yōu)勢(shì)是 prefill 和 decode 互不搶資源長(zhǎng)上下文預(yù)填充不再拖慢在線 token 生成。代價(jià)是架構(gòu)復(fù)雜度上來(lái)了需要額外的調(diào)度組件。配置上有幾個(gè)關(guān)鍵參數(shù)在 vLLM 中使用--served-model-name配合預(yù)填充池/解碼池配置或者用 SGLang 的 PD 分離參數(shù)prefill 和 decode 實(shí)例要共享前綴緩存存儲(chǔ)否則緩存命中率會(huì)直線下降scheduler 的隊(duì)列權(quán)重要配好prefill 隊(duì)列和 decode 隊(duì)列的比例按“輸入 tokens 與輸出 tokens 的 1:31:5”來(lái)估如果輸出偏長(zhǎng)decode 實(shí)例要多配。5.3 命中率數(shù)據(jù)與優(yōu)化技巧部署 P-D 分離加 prefix caching 之后我們跑了一組業(yè)務(wù)流量回放場(chǎng)景無(wú)緩存僅 prefix cacheP-D prefix cache多輪對(duì)話命中率0%68%68%長(zhǎng)文檔問(wèn)答命中率0%21%21%綜合 prefill 吞吐(tokens/s)8,40015,20019,800TTFT P99(ms)1,200780390多輪對(duì)話的命中率最高68%因?yàn)槊枯喍紟е鴼v史上下文和固定的 system prompt長(zhǎng)文檔問(wèn)答命中率低21%因?yàn)槊總€(gè)文檔內(nèi)容差異大。綜合下來(lái)P-D 分離讓 prefill 有效吞吐從 8.4K 提到 19.8KTTFT 從 1.2s 壓到 390ms這個(gè)提升非?？捎^。命中率優(yōu)化的幾個(gè)技巧system prompt 盡量放在請(qǐng)求最前面有些框架的 prefix cache 是按前綴匹配的放中間會(huì)打斷緩存命中多輪對(duì)話要使用框架自帶的聊天模板復(fù)用不要每次重拼完整歷史那樣等于把已經(jīng)算過(guò)的 KV cash 全部作廢緩存條目不要設(shè)得過(guò)小太小會(huì)導(dǎo)致高頻請(qǐng)求的緩存頻繁被淘汰命中率反而下降如果業(yè)務(wù)里存在幾十個(gè)固定請(qǐng)求模板可以考慮在入口層做模板歸一化把相同前綴的請(qǐng)求打到一個(gè)實(shí)例上。6. 碰到的坑和排查實(shí)錄這部分是花錢買來(lái)的經(jīng)驗(yàn)。硬件剛到手的時(shí)候我們覺得 B300 這種新卡應(yīng)該很穩(wěn)定結(jié)果測(cè)試期間遇到了好幾個(gè)詭異問(wèn)題每個(gè)都能讓人懷疑人生。整理出來(lái)希望你們少走彎路。6.1 B300 集群的散熱與維護(hù)B300 功耗比 B200 更高8 卡整機(jī)的滿載功率輕松超過(guò) 15kW對(duì)機(jī)房的散熱和供電要求非常高。我們測(cè)試期間遇到過(guò)一次“性能懸崖”跑滿 512 并發(fā) 15 分鐘后整體吞吐突然掉了 40%檢查發(fā)現(xiàn) GPU 溫度到了 96°C 觸發(fā)降頻。調(diào)整機(jī)房空調(diào)風(fēng)道和機(jī)柜位置后溫度穩(wěn)定在 82°C 左右問(wèn)題解決。建議B300 集群上線前做一次滿載熱循環(huán)測(cè)試至少連續(xù)跑 1 小時(shí)以上觀察溫度和時(shí)鐘曲線散熱不足的機(jī)房不要貿(mào)然上高并發(fā)壓測(cè)容易把卡降頻甚至觸發(fā)保護(hù)性關(guān)機(jī)。另外日常維護(hù)要多看nvidia-smi dmon采集的溫度歷史不要等出故障再排查。6.2 CX8 網(wǎng)絡(luò)固件導(dǎo)致的 RDMA 偶發(fā)斷連這個(gè)坑前面提過(guò)這里展開講。癥狀是NCCL 全互聯(lián)測(cè)試all_reduce有時(shí)能過(guò)、有時(shí)在某個(gè)節(jié)點(diǎn)上卡住重試幾次又恢復(fù)正常GPU 直連通信偶爾報(bào)錯(cuò)mlx5_0: timeout。排查了兩輪硬件都沒(méi)問(wèn)題最后發(fā)現(xiàn)是 CX8 網(wǎng)卡固件版本比驅(qū)動(dòng)的預(yù)期版本舊了一大截升級(jí)固件后問(wèn)題完全消失。排查方法供參考# 查看網(wǎng)卡固件版本 mlxup --query # 檢查驅(qū)動(dòng)與固件匹配情況 modinfo mlx5_core | head # 跑 NCCL 全互聯(lián)測(cè)試 nccl-tests/build/all_reduce_perf -b 1G -f 2 -g 8 -n 10遇到過(guò)類似問(wèn)題的話別急著換硬件先查固件和驅(qū)動(dòng)的版本矩陣。RDMA 的偶發(fā)問(wèn)題有相當(dāng)大比例是固件/驅(qū)動(dòng)不配套導(dǎo)致的。6.3 FP4 模型和 CUDA graph 的沖突我們第一版配置用了 vLLM 默認(rèn)的 CUDA graph 加速啟動(dòng)時(shí)報(bào)了類似Cannot capture graph with quantized ops的錯(cuò)誤或者能啟動(dòng)但跑幾個(gè) batch 后隨機(jī)報(bào)CUDA error: illegal memory access。排查后確認(rèn)是 CUDA graph 捕獲和 FP4 量化 kernel 的某些組合路徑有兼容性問(wèn)題。解法很直接--enforce-eager關(guān)掉 CUDA graph。代價(jià)是每步調(diào)度開銷大一點(diǎn)實(shí)測(cè)吞吐影響在 5% 以內(nèi)但穩(wěn)定性大幅提升。如果框架后續(xù)版本修了這個(gè)問(wèn)題可以再開回來(lái)但建議先在壓測(cè)環(huán)境驗(yàn)證 30 分鐘以上再上生產(chǎn)。6.4 常見問(wèn)題速查現(xiàn)象可能原因建議處理吞吐跑一會(huì)驟降GPU 溫度過(guò)高觸發(fā)降頻檢查散熱、調(diào)整負(fù)載NCCL/遠(yuǎn)端通信時(shí)好時(shí)壞網(wǎng)卡固件/驅(qū)動(dòng)不匹配升級(jí)固件、跑 nccl-tests 驗(yàn)證啟動(dòng)報(bào) CUDA graph 錯(cuò)誤FP4 kernel 與 graph 捕獲沖突加--enforce-eagerKV cache 命中率一直很低請(qǐng)求結(jié)構(gòu)不連續(xù)/緩存條目太小調(diào)整緩存淘汰策略、優(yōu)化 system prompt 位置FP4 精度不達(dá)標(biāo)模型本身不適合 4-bit/縮放因子異常用 ROUGE 等指標(biāo)逐任務(wù)驗(yàn)證必要時(shí)退回 FP8跨機(jī) TP 吞吐低于預(yù)期跨節(jié)點(diǎn)走 RDMA 帶寬不足切 TP8 本地部署跨機(jī)只做數(shù)據(jù)并行最后說(shuō)點(diǎn)個(gè)人體會(huì)。這次實(shí)測(cè)最大的感受是B300 的硬件底子確實(shí)強(qiáng)但真正拉開體驗(yàn)差距的是緩存的命中率和部署配置的細(xì)節(jié)。NVFP4 讓 400B 級(jí)模型在單卡跑成為了現(xiàn)實(shí)而 prefix cache 加 P-D 分離讓同樣的硬件跑出了接近翻倍的業(yè)務(wù)吞吐。如果你也在評(píng)估 B300 集群我建議先把緩存命中率這件事想清楚這比堆機(jī)器更劃算。另外跟 B300 一起到的 CX8 固件問(wèn)題我們前前后后折騰了大半天建議你拿到機(jī)器第一件事就去查固件版本別等上了生產(chǎn)才發(fā)現(xiàn)。