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