推論系統
vLLM 以 Mooncake 跨節點串流隱藏狀態，為 2.8T Kimi K3 訓練 DSpark 草稿模型
vLLM 與 Red Hat AI 公開 Kimi K3 的 50 億參數 DSpark 草稿模型，以及跨節點抽取、傳送隱藏狀態的完整配方。官方測試把單一使用者生成速度由約 110 提至 435 token/s，但結果依賴 GB300 叢集與特定推理負載。
vLLM 團隊為 2.8 兆參數 Kimi K3 訓練並釋出 DSpark speculative model，把大型模型難以集中於單機的問題，拆成彼此獨立擴展的推論與訓練平面。即使將 Kimi K3 權重量化至 4 bit，抽取隱藏狀態仍至少需要兩個 GB300 節點；團隊因此以兩個四 GPU 節點執行目標模型，另一個四 GPU 節點訓練草稿模型，再由 Mooncake 透過 RDMA 或 TCP 串流中間狀態與目標 logits。
公開的草稿模型有五層、約 50 億參數，每輪提出八個 token。DSpark 不像 EAGLE-3 逐 token 產生草稿，而是先平行預測整個區塊，再用低秩 Markov head 補回相鄰 token 的條件關係；另一個 confidence head 則估計各位置被目標模型接受的機率，讓排程器按負載縮短或延長驗證前綴。九類評測的平均接受長度為每輪 4.11 token，數學推理達 6.42，HumanEval 為 4.96。
在團隊公布的數學負載中，單流速度由約 110 增至 435 token/s；並行數從 1 提高至 16 時，總吞吐量由 177 增至 683 token/s，中位首 token 延遲只由 379 增至 479 毫秒。378K-token 的 LongBench-v2 個案則達每輪 5.31 個輸出 token，顯示長上下文不必然令草稿接受率崩落。
工程價值不只在單一 checkpoint：Apache 2.0 的 Speculators 已加入 DSpark、跨節點 hidden-state connector、訓練指令與可直接載入 vLLM 的 Hugging Face 格式。不過效能數字來自同一團隊、GB300 NVL72 與精心調整的軟體棧；不同提示分布、採樣設定、舊 GPU 或網路互連可能抵消草稿模型的額外計算。下一步應看第三方能否重現成本收益，以及 Mooncake 傳輸與五層草稿模型在多租戶服務下是否仍划算。