世界從未停止變化。RSS
BIG CHANGE.

Markdown 版本

AI-translated from English; not yet reviewed by a fluent editor.

# vLLM的Kimi K3解碼路徑在特定GB300測試中達到每秒842個詞元

> vLLM報告，在特定DSpark設定下，Kimi K3於16張GB300 GPU上的整體解碼速度為每秒842個詞元，對照值為488；不計預填充。

By BIG CHANGE Editorial

Published: 2026-10-18T20:03:34.885Z
Updated: 2026-10-18T20:03:34.885Z
Canonical: https://bigchange.ai/blog/kimi-k3-vllm-gpu-inference-benchmark

![Conceptual charcoal illustration of the rear of a generic compute cabinet with rack units and secured cables in a data-center aisle.](https://bigchange.ai/api/media/file/kimi-k3-decode-cabinet-concept-v1.png)
AI-generated conceptual illustration by BIG CHANGE; no actual GB300 chassis, vLLM installation or measured result is depicted.

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

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

## 時間花在哪裡

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

適用範圍與核心設計同樣重要。[Pull request](https://github.com/vllm-project/vllm/pull/61867)描述了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將指標稱為每秒整體解碼詞元數，不計預填充。合成接受設定固定了基準測試接受多少個提議詞元；它不是從使用者提示詞量測到的接受率。提示詞、接受行為、批次大小或輸入長度不同的部署，都需要自行量測。

貼文也提供一張[非推測式解碼表](https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel#decode-performance-without-speculation)。例如，在TP16下，批次1的結果為每秒256.4個詞元，批次64則為3,606.1個；相對於各自的原版設定，提升幅度分別為1.88×與1.62×。這些是不使用推測式解碼的TP群組整體結果，不能與DSpark數字拼在一起，宣稱批次64下每位使用者的體驗更快。

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

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

## 評估需要什麼

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

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

## 關鍵變化

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

## 資料來源與延伸閱讀

- [vLLM於10月16日發布的技術文章](https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel)說明了解碼變更，並提供842/488的設定、非推測式解碼表與AgentX比較。結果由專案及NVIDIA貢獻者Benjamin Chislett報告。
- [已合併的vLLM pull request #61867](https://github.com/vllm-project/vllm/pull/61867)記錄了選用設定、支援組態、實作界線、驗證，以及較早的838/489 DSpark表格。這是程式碼與結果的紀錄，並非獨立重現。
- [Moonshot AI的Kimi K3模型卡](https://huggingface.co/moonshotai/Kimi-K3)指明實作引用的模型與權重。
- [AgentX方法說明](https://inferencex.semianalysis.com/agentx)描述了另一項互動速度比較所用的流量重播工作負載。

## Sources

- [vLLM，〈在vLLM中深度最佳化Kimi K3：快速且負責任地前進〉（2026-10-16）](https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel) — 第一手技術說明，也是842/488、1.73×結果的來源。它明列16張GB300 GPU上的TP16、批次1、DSpark DL7、合成AL6、ISL1、OSL1k，以及不計預填充的整體解碼TPS。另提供不同的非推測式解碼與AgentX結果。
- [vLLM pull request #61867，Kimi K3專用解碼](https://github.com/vllm-project/vllm/pull/61867) — 已合併的實作與作者執行的驗證紀錄。記錄最終選用設定、支援組態與回退機制。其較早的DSpark表格列出TP16 B1、合成AL6下為838/489，因此不能將這些數字與部落格中的一組混用。
- [Moonshot AI，Kimi K3模型卡](https://huggingface.co/moonshotai/Kimi-K3) — 指明模型與模型供應者提供的權重；不會獨立確立vLLM的效能。
- [InferenceX，AgentX方法與資料集](https://inferencex.semianalysis.com/agentx) — 描述另行報告的互動速度比較所用的流量重播工作負載。vLLM的比較也變更了GPU數量。