LMSYS 團隊公開了一組 DeepSeek-V4-Pro 的服務端最佳化數據，測試平台是 H20，對照組是輝達（Nvidia）的旗艦晶片 B300。作者為 Tianyu Zhang、Yusong Gao 與 Yun Zhang，所有工作皆跑在開源框架 SGLang 上。
先看兩項主要數據。預填階段，PP2-CP8-TP8 組態在 4K 上下文下達到每秒 16900 個 token；換成 PP4-CP8-TP8 跑 512K 長上下文，輸送量反而升到每秒 25860 個 token，處理 100 萬 token 耗時 43.7 秒。解碼階段的低延遲情境下，單批次在 H20 上每秒輸出 271 個 token，B300 則是 383.7 個，兩者比值為 1.42 倍。
高輸送量情境另有一套組態。DP32-EP32 在 4K 上下文、32 路並行下做到每張卡每秒 703.15 個 token，DP16-EP16 更高一些，達 759.73。上下文拉到 100 萬 token 時，每張卡每秒仍有 66 到 67 個 token。
1.42 倍是什麼概念
H20 是輝達為中國市場推出的合規版本，紙面運算能力與 B300 之間相差的遠不止一個等級。把單批解碼的差距壓到 1.42 倍，說明卡關的並非峰值運算能力，而是記憶體頻寬、通訊開銷與排程空轉。
這也解釋了最佳化清單的組成。收益最大的幾項都不在運算精度上：量化熱路徑融合把 SwiGLU 激活函數與量化一併處理、去除中間緩衝區，單項輸送量提升 44.0%；把詞表權重的內積運算換成轉置 GEMM，減少高並行下的重複讀取，輸送量再增 22.8%；依實測的專家（expert）偏好重新配置負載，又拿到 13.5%。
預填端的手法同理。把 7 個運算子融合成 3 個執行群組，首 token 延遲降低 3.5%；從正式環境的實際路由直方圖裡擷取高頻樣態，分別對兩組專家權重做針對性最佳化，首 token 延遲再降 11.35%。最後這一項尤其務實，它沒有假設請求分佈均勻，而是照著線上流量本就偏斜的樣子去調整。
還有一處結構性替換：預填階段改用張量並行取代專家並行來切分 MoE 層。理由是專家負載不均會拖出長尾，寧可多付一點通訊成本也要把尾巴剪掉。
記憶體容量是換來的
比速度更硬的限制是容量。這組工作裡有兩項直接針對記憶體：Humming MXFP4AFP8 用 MXFP4 儲存專家權重、搭配線上 FP8 激活，相對基準拿到 1.71 到 4.47 倍的容量；線上 C128 KV 壓縮維護精簡的聚合狀態而非逐索引狀態，貢獻 2.268 倍。兩者疊加，區間來到 3.88 到 10.14 倍。
對部署方而言，這一項的帳最好算。同樣一台 8 卡機器，能容納的並行數或上下文長度翻了好幾倍，單位 token 成本就按同樣比例往下降。當晶片數量拿不到增量時，容量倍數就是唯一還能自己掌握的變數。
DSpark 的貢獻另外列了一筆：跨管線階段協調目標執行與驗證步驟後，每 token 輸出時間改善 74.8% 到 78.0%。
把這幾項換算成成本會更直觀。假設一台 8 卡 H20 機器的月度持有成本固定，容量倍數提升 4 倍，同一張帳單能服務的並行數就是原來的 4 倍，單位 token 的機器成本降到約四分之一（這是粗估，忽略了長上下文帶來的額外運算量與路由抖動）。對按 token 計價、毛利本就被價格戰壓薄的服務方來說，這層騰挪空間往往比等新一代晶片來得實在，何況晶片也未必換得到。
給出的是一張組態表
這篇工作最後端出的並非單一最佳解，而是一張按情境分檔的組態表：預填在 32K 以內用 PP2、128K 以上換 PP4；解碼追求低延遲走 PP2-TP8，追求輸送量走 DP32-EP32，DP16-EP16 則留作效率參照。
這種寫法本身就是一種訊號。排行榜要的是一個數字，正式環境要的是知道自己的流量長什麼樣、該落在哪一檔。對手上只有 H20、卻仍得把 1.6 兆參數模型服務起來的團隊來說，這張表比任何一項峰值紀錄都更能直接派上用場。
參考來源：LMSYS 技術部落格、CocoLoop、SGLang 專案文件；輸送量、延遲與容量倍數均取自該部落格給出的實測組態表，B300 對照資料同源。