Kimi K3 vLLM 最佳化：NVIDIA 解碼速度提升 1.68×

NVIDIA 已將專為 Kimi K3 設計的解碼實作貢獻至 vLLM，再次展現軟體如何在既有硬體上提升推論速度。IT Home 報導指出，SemiAnalysis 於 10 月 18 日發布的貼文顯示，這款 2.8 兆參數模型每位使用者可達 每秒 423 個 token，並在相同 GB300 NVL72 硬體上達到 1.68× 加速。

首先必須釐清的是所採用的指標。附帶圖表的橫軸標示為 P90 互動性（tok/s/user）。這代表每位使用者的串流效能指標，不是機櫃的 token 總輸出量，不代表每個請求都能達到此效能，也不表示服務流程中的每個環節都提升了 68%。

報告中的結果與基準測試背景

SemiAnalysis 的圖片比較了標示為 Dynamo vLLM 的 GB300 NVL72 組態，日期分別為 10 月 18 日和 9 月 15 日。圖中將每位使用者的互動性指標，與估算總擁有成本下每美元可產生的 token 總量進行對照。

IT Home 轉載的 SemiAnalysis 結果與圖表。

本文檢視的 InferenceX 即時儀表板，選取的是 Kimi K3 2.8T、Agentic、FP4，執行日期為 10 月 18 日。表格顯示，GB300 NVL72 的最高 P90 互動性數值為 424 tok/s/user。這是之後查閱時的即時顯示數值，不能據此悄悄更改原始貼文中的 423 數值。

儀表板也另行呈現每顆晶片的吞吐量。這些欄位不可合併或互相替代：針對單一串流速度最佳化的組態，可能會犧牲整體吞吐量；而高吞吐量組態則可能降低每位使用者的串流速度。

在檢視的資料中，原始貼文所標示數據點的確切並行請求數，以及提示詞／輸出長度均未獲確認。尤其是，儀表板初始靜態 HTML 顯示的是通用的 8K/1K 選取項目，但頁面完整載入後則選取了 Agentic。不可將靜態預設值當成報告結果的工作負載規格。

使用 CuTeDSL 的專用解碼路徑

SemiAnalysis 貼文將這項工作歸功於 NVIDIA CentML 工程師 Benjamin；他運用 CuTe DSL，投入約 12,000 行程式碼開發 megakernel。上游實作可直接追溯至 vLLM 第 61867 號提取請求，標題為 Kimi K3 Specialized Decode: CuTeDSL Optimized GB300 (1.5–2x)。

該提取請求說明，這是 NVIDIA 為 GB300 開發的實作，並於 10 月 16 日合併。它新增了針對特定模型的專用執行階段，而非修改 Kimi K3 的權重。NVIDIA 的 CUTLASS 專案將 CuTe DSL 描述為一種以 Python 為本、低階的 GPU 核心撰寫方式，運用 CuTe 的配置、張量和硬體抽象。

其工程構想是針對特定模型與硬體組合，最佳化解碼時的運算作業與執行模式。這比起在所有加速器上加速模型的每個階段，適用範圍更狹窄。提取請求支援的路徑包括張量平行度 8 或 16，以及特定的推測式與非推測式解碼組態。

上游測試實際呈現的結果

相較於簡短的新聞報導，提取請求提供了更明確的測試條件。其中一項非推測式測試使用 GB300 上的 TP16、輸入序列長度為 1、輸出長度為 1,024，並採用貪婪解碼，搭配 FP8 KV 快取、FP32 SSM 快取，以及模型提供者的權重。

其解碼步驟耗時採用中位數 token 間延遲，不包含預填充；測量時執行中的請求數恰好等於表列數量。作者表示，每個批次設定使用四個提示詞執行三次測試，並與圖形重播計時交叉比對。

這些是另外進行的開發者測試，不是對儀表板上確切 423 tok/s/user 數據點的重現或說明。其價值在於，測試明確列出並行數、序列長度，以及測量的階段。

提取請求也包含推測式解碼測試。部分效能測量使用合成或強制設定的草稿接受長度，不應誤認為每種工作負載都能自然達到該接受程度。在一項輸入長度為 32K、使用 DSpark DL7、合成接受長度為 3.78，並啟用解碼情境平行的測試中，報告的純解碼效益高於納入其他請求預填充工作的輸出吞吐量效益。作者指出，在該項比較中，首次 token 時間相同。

整合、準確性檢查與限制

提取請求透過選用參數 --additional-config '{"decode_backend": "latency_specialized"}' 啟用此路徑。這是該合併貢獻文件所述的組態；它不是完整的伺服器啟動命令，也不代表每個已發布的 vLLM 套件都已包含此功能。

專用執行階段可在預填充、混合批次和大型批次情況下，退回標準 vLLM 執行路徑。因此，使用者不應假設解碼專屬的速度提升，能原封不動地套用於長提示詞讀取、混合流量或所有並行層級。

開發者表示，已針對 AIME25、GPQA-Diamond、GSM8K 和 MRCR v2 等任務進行評估，並執行數值檢查。這些檢查有助於在已公布的條件下比較兩種實作，但無法證明每次取樣執行都會產生完全相同的文字，也無法證明所有應用程式的行為都維持不變。

原始報導也指出，NVIDIA 正在為 DeepSeek V4.1 和其他模型開發 vLLM 最佳化。這項說法應維持為對進行中工作的描述。Kimi K3 的結果不能證明其他模型也已獲得相同提升，或具有相同的部署需求。

常見問題

這份報告中的 423 tok/s/user 代表什麼？

附帶的 SemiAnalysis 圖表將此指標標示為每位使用者每秒 token 數的 P90 互動性。這是串流效能指標，與系統總吞吐量及首次 token 時間不同。

1.68× 的提升是來自硬體升級嗎？

報告中的比較使用相同的 GB300 NVL72 硬體。報告將效能提升歸因於軟體路徑，但這不代表該硬體上的每種工作負載都會獲得相同幅度的提升。

這項最佳化已經整合至上游 vLLM 嗎？

經檢視的第 61867 號提取請求已於 10 月 16 日合併。實際部署仍取決於使用的版本是否包含該變更，以及是否符合實作所支援的模型、硬體和組態要求。

這項最佳化也能加速預填充嗎？

這項貢獻是專用解碼實作。其說明指出，預填充、混合批次和大型批次可使用標準路徑，因此不應將解碼步驟的測量結果宣稱為整個流程的速度提升。

提取請求中的批次大小為一的數值，與 423 數值來自相同基準測試嗎？

目前未能確認兩者完全相同。提取請求公布的微基準測試明確列出序列長度與並行數，而本文無法確認 SemiAnalysis 所標示數據點的完整工作負載設定。

推測式解碼測試能保證實際使用時也有相同的速度提升嗎？

不能。草稿接受情況、情境長度、並行數和預填充流量都會影響結果；而且提取請求中的部分效能測試使用合成接受值。應依適用的測試流程進行測試，並先評估實際工作負載，再推估效能表現。

相關工具

• vLLM：提供推論與服務框架，並整合這項專用解碼實作。
• NVIDIA CuTe DSL：提供這項最佳化使用的 GPU 核心程式設計工具。
• InferenceX：呈現不同硬體與服務組態下的 Kimi K3 效能曲線。

相關連結

• 已合併的 Kimi K3 專用解碼提取請求：說明支援的組態、選用整合方式、基準測試及驗證限制。
• SemiAnalysis 原始貼文：呈現每秒 423 tok/s/user 與 1.68× 的報告結果。
• Kimi K3 InferenceX 儀表板：提供即時基準測試圖表，以及分開呈現的每位使用者和每顆晶片指標。
• InferenceX 基準測試儲存庫：介紹公開基準測試專案及其方法資源。
• NVIDIA CUTLASS 儲存庫：說明 CuTe DSL 程式設計模型及相關 GPU 核心基礎架構。
• CuTe DSL 快速入門：提供核心程式設計環境的官方入門指南。
• AI 推論詞彙表：定義互動性、並行數及相關基準測試術語。
• IT Home 原始報導：提供原始中文報導及檢視過的結果截圖。

摘要

NVIDIA 已合併的 CuTeDSL 貢獻，為 Kimi K3 在 GB300 上提供專用解碼路徑；開發者測試顯示，在條件明確的情況下，延遲有顯著改善。SemiAnalysis 另行報告指出，在相同硬體上效能提升 1.68×，並達到每位使用者每秒 423 tok/s。

解讀數值時，務必一併標明所屬階段與指標：每位使用者的解碼互動性，不等於系統總吞吐量，也不代表普遍適用的端對端速度提升。