推論基礎設施
NVIDIA Dynamo 為 Kimi K3 提供多節點部署配方，百萬 token 推論至少需 16 顆 GB200／GB300
Dynamo 的實驗版本加入 Kimi K3 多模態、推理與工具呼叫解析，並公開聚合及 prefill／decode 分離的 Kubernetes 配方。配方把 2.8T MoE 的部署門檻量化到機架拓撲，但目前未經正式 QA，且已知 GB200 設定仍有啟動錯誤。
Kimi K3 權重公開後，部署問題從「能否下載」轉為「如何在多節點上實際服務」。NVIDIA 於 7 月 27 日釋出 Dynamo `v1.4.0-kimi-k3-dev.1` 預覽版，把 Kimi K3 接入 vLLM 後端，補上文字與圖片前處理、reasoning parser、tool-call parser，以及 GB200、GB300 的 Kubernetes 範本。這是先前模型釋出的後續部署里程碑，而非新的模型版本。
四種配方涵蓋聚合式推論與 prefill／decode 分離。GB200 聚合配置使用 16 顆 GPU、跨四個節點做 TP16；分離配置需要 16 顆 prefill 加 16 顆 decode GPU。GB300 聚合配置以 16 顆 GPU 建立兩個 TP8 replica，分離配置則使用 8 顆 prefill 與 16 顆 decode。兩者透過 Kubernetes ComputeDomain 保持 NVLink 拓撲；分離式部署由 NIXL 搬運 KV cache，GB300 走 NVLink，GB200 則走 RDMA InfiniBand。
權重中的 routed experts 採 MXFP4、dense 部分維持 BF16，KV cache 使用 FP8；配方同時開啟 prefix caching、KV-aware routing 與多模態 encoder 的資料平行切分，標示可服務 1,048,576 token 上下文。這些選擇反映超大型 MoE 的系統瓶頸：記憶體格式、KV 搬運、網路拓撲與請求路由，往往比單一核心的 token 速度更決定成本。
不過，這仍是 branch-specific snapshot，並非 QA-gated 穩定版，也沒有公布端到端吞吐、首 token 延遲或不同上下文長度的成本曲線。官方還列出 GB200 分離式 frontend 的 `MODEL_PATH` 未設定問題，可能令容器以字面字串啟動。評估團隊應先套用修正、驗證 storage class 與模型快取，再以自身 agent 流量測量 KV 命中率和 prefill／decode 比例；現有硬體表格只能證明配方存在，不能證明經濟性。