vLLM已合併一條適用於NVIDIA Blackwell GPU、針對Kimi K3的選用解碼路徑。在其10月16日的說明中，專案報告每秒產生842個詞元，原版vLLM則為488個，提升1.73×。這項比較的適用範圍很窄：一次一個請求、在16張GB300 GPU間進行張量平行運算、DSpark推測式解碼使用七個草稿詞元、合成接受長度為六、輸入一個詞元、輸出1,000個詞元。該數字衡量的是預填充後的整體解碼吞吐量，不是使用者完整請求完成的速度。

對評估是否測試這條路徑的工程師來說，有用的進展在於相當可觀的解碼結果，以及對適用範圍相當明確的說明。已合併的實作須透過decode_backend: latency_specialized選擇啟用；預設的auto設定仍使用原版解碼。vLLM表示，這條專用路徑針對同一NVLink網域內有八張或16張GPU的GB300部署；預填充、混合批次與不支援的步驟則回退到標準模型前向運算路徑。

時間花在哪裡

根據其模型卡，Kimi K3是一個大型混合專家模型。在解碼期間，服務系統反覆執行注意力運算、選擇專家，並在GPU間交換資料，以產生後續詞元。vLLM團隊建立了一條CuTe DSL路徑，針對預期的張量形狀特化這些運算。其說明涵蓋小型與較大批次採用不同注意力投影核心、融合注意力輸出投影與跨GPU歸約及後續殘差運算、分片的路由器計算、共享專家與路由專家之間的重疊執行，以及通訊期間預先擷取權重。貼文中的逐層追蹤顯示，專用路徑使用13個核心、耗時69微秒，原版vLLM則使用23個核心、耗時130微秒。這是所展示設定的追蹤報告，並非應用程式延遲數字。

適用範圍與核心設計同樣重要。Pull request描述了GB300在TP8與TP16下的驗證、最大批次64的非推測式解碼、使用三至七個草稿詞元的DSpark驗證，以及可選用的解碼上下文平行運算。它指出，效能工作使用FP8 KV快取、FP32 SSM快取與模型供應者提供的權重。這條路徑不變更模型權重、排程、取樣或DSpark草稿模型。如此一來，服務團隊可在熟悉的周邊技術堆疊中比較更換後的解碼實作，但也意味著這項最佳化不會加速服務的每一部分。

分開閱讀兩張基準測試表

每秒842對488的結果採用16張GB300 GPU上的TP16、批次1、使用七個草稿詞元的DSpark、合成接受長度六，以及DL=7、ISL=1、OSL=1k。vLLM將指標稱為每秒整體解碼詞元數，不計預填充。合成接受設定固定了基準測試接受多少個提議詞元；它不是從使用者提示詞量測到的接受率。提示詞、接受行為、批次大小或輸入長度不同的部署，都需要自行量測。

貼文也提供一張非推測式解碼表。例如，在TP16下，批次1的結果為每秒256.4個詞元，批次64則為3,606.1個；相對於各自的原版設定，提升幅度分別為1.88×與1.62×。這些是不使用推測式解碼的TP群組整體結果，不能與DSpark數字拼在一起，宣稱批次64下每位使用者的體驗更快。

貼文中的另一個數字涉及AgentX，這項工作負載以合成內容重播程式碼代理程式的流量模式。vLLM報告，在並行度為一時，P90互動速度為每位使用者每秒403.2個詞元，對照值為223.7。最佳化結果使用16張GB300 GPU，較早的對照測試則使用八張。由於GPU數量與實作同時變更，這項1.8×比較無法單獨辨識解碼路徑改善的效果。AgentX也包含較長的上下文、對話回合、停頓與快取重用，因此其指標回答的問題與純解碼基準測試不同。

公開貼文與較早的Pull request效能表之間有一個小差異：後者列出TP16、批次1、DSpark DL7與合成接受長度六時，每秒838對489個詞元。本文1.73×的數字來自貼文中842對488的比較。較早的表格可作為類似執行的有用證據，但不應將兩組數字交叉拼接。vLLM已公開程式碼與自己的驗證；BIG CHANGE並未重現其中任何一次執行。

評估需要什麼

有意義的本地比較應從已合併的PR及其列出的設定開始：同樣的Kimi K3模型供應者權重、在單一NVLink網域內有16張GPU的GB300系統、TP16、快取格式，以及標題測試的確切DSpark設定。於相同工作負載下執行原版auto與選用的latency_specialized，再將解碼吞吐量與預填充、首詞元時間、輸出吞吐量、請求層級延遲分開記錄。工作站或較小的GPU資源池無法直接重現標題中的16張GB300結果。貼文並未確立這項設定的租用成本。

其PR的驗證說明報告了數值檢查與模型評測，包括AIME25、GPQA-Diamond及長上下文MRCR測試。它也描述開發期間發現的同步錯誤，以及長輸出測試的變異。這些檢查提供讀者比速度圖表更多可檢視的內容，但仍是實作者自己的證據。服務團隊要判斷的是，自身的實際硬體、批次處理、上下文長度與推測式接受行為，是否足夠接近支援設定，值得在自己的流量上量測這條選用路徑。

關鍵變化

vLLM已合併的Kimi K3路徑，提供一個專用、可選用的GPU解碼實作，並附有記錄完整的基準測試與驗證脈絡。公開資訊中最突出的數字是在16張GB300 GPU上使用TP16、批次1、DSpark七個草稿詞元及合成接受長度六時，整體解碼速度為每秒842對488個詞元，也就是1.73×。不計預填充。是否能改善特定服務，取決於該服務的硬體與完整請求工作負載。

資料來源與延伸閱讀