vLLM 发布 Kimi K3 Day-0 支持：2.8 万亿参数 MoE 从单机到 370 token/秒的部署实操指南

一句话结论

vLLM 宣布对 Kimi K3 的 Day-0 高效支持正式上线。Kimi K3 是已发布的最强开源权重模型之一：

2.8 万亿参数混合专家（MoE）模型，每 token 激活 896 个专家中的 16 个，基于 Kimi 增量注意力（KDA）与注意力残差（AttnRes）构建，100 万 token 上下文窗口加原生视觉。这篇文章就是一份可落地的部署实操指南。

K3 的四个架构要点

K3 在四个方面偏离了标准 Transformer，每一项都改变了服务引擎要做的事。

**Kimi 增量注意力（KDA）：混合循环+全注意力栈。

** K3 大部分层是 KDA——一种线性注意力机制，保持固定大小的循环状态而非不断增长的 KV 缓存，与周期性全注意力层交错，后者保留精确的全局回忆。正是这一点让 100 万 token 上下文变得可负担。

一个统一的混合 KV 缓存管理器在同一个调度器下持有两种内存：全注意力层的分页 KV 块，与 KDA 层的紧凑循环状态块。

最难的部分是循环状态上的前缀缓存：KDA 层没有可哈希的逐 token KV，vLLM 把物理状态块大小与前缀匹配粒度分离，在块边界复用状态快照，让长共享提示仍能命中缓存。

注意力残差（AttnRes）：把此前各层的输出与 softmax 注意力混合，让每个 token 的表示随内容在网络深度上自适应。

vLLM 实现了融合 CUDA 算子，单次启动完成 logits 计算、跨层 softmax 与聚合，把残差加法和输出 RMSNorm 折进同一算子。

Stable LatentMoE：每个 token 路由到 896 个专家中的 16 个。

专家用专家并行分片；vLLM 提供两个针对不同拓扑调优的 MoE 后端：张量并行（TP>1）用的 TRT-LLM-Gen，分离/专家并行（DEP）用的 MegaMoE，外加可选的专家并行负载均衡（EPLB）。

MXFP4 权重与原生视觉：K3 的权重经量化感知训练为 4 位 MXFP4，低精度是原生属性而非事后转换。

服务语义：K3 不带 Jinja 聊天模板，其 tokenizer 通过一个 Python 程序渲染消息。vLLM 在 Python 与 Rust 两个前端实现了同一渲染程序，工具调用、推理输出与结构化输出在两端行为一致。

为生产而生：快、省、粘

服务好一个 2.8 万亿混合 MoE，意味着对单个用户快、对数千用户省、对智能体粘。vLLM 在三点上全部就绪。

超低延迟：在 2.8 万亿模型上不损精度达到超低延迟，投机解码是自然选择。

vLLM 因此从 Day 0 支持 DSpark，团队还训练并发布了自己的 K3 DSpark 投机器。DSpark 用块扩散骨干一次并行 pass 生成多个投机 token，让起草成本随块加深保持平稳。

草稿模型做成 MLA 原生，镜像 K3 自己的注意力，让草稿与目标共享相似 KV 布局。

同一构建、提示与方法下实测：单用户 118 → 370 token/秒，3.14 倍提升（16 卡 NVIDIA GB300 NVL72；TP8 上 111 → 331）。

增益取决于输出可预测性——编程等低熵任务 DSpark 每步接受约 4.73 个 token；创意写作等高熵任务约 2.61 个。所以这个加速比是标准设置下的实测值，不是普适常数。

草稿模型与推理支持均随本次发布开源。

大规模服务（预填/解码分离）：对高吞吐集群，vLLM 以跨节点专家+数据并行服务 K3，配合预填/解码（PD）分离——预填密集与解码密集的工作跑在不同副本上，各自按自身瓶颈定容。

已验证拓扑为 TEP8 预填 → DEP16 解码，阶段间通过 NIXL 搬运 KV/状态。

智能体服务：智能体负载（长多轮会话、工具循环、大型共享系统提示）需要精细的 KV 复用。

vLLM 的 Mooncake 集成让 K3 跨轮次与跨请求卸载并复用 KV，重复出现的代码库、文档或智能体草稿区不必每轮付全额预填。配合 K3 循环状态上的前缀缓存，长智能体会话随上下文累积仍保持响应。

基准成绩

以下全部通过服务的 OpenAI 兼容端点与发布版解析器测得：

• GSM8K：0.976
• GPQA-Diamond：0.939
• OCRBench：0.889
• MMMU Pro Vision：0.818

在推理与知识上，vLLM 紧贴 Kimi 官方报告的质量，说明算子、解析器与缓存端到端保住了模型质量。

一条实战笔记：K3 答题前会先大量推理。分数偏低时，先检查答案是否被截断再断定答错，并考虑大幅调高 max_tokens 预算。

部署：从快启命令到参数清单

快速启动（2.8 万亿 MoE 至少需要一台 8× B300 节点才能跑起来）：

vllm serve moonshotai/Kimi-K3 \
  --tensor-parallel-size 8 \
  --trust-remote-code \
  --load-format fastsafetensors \
  --enable-prefix-caching \
  --max-num-seqs 512 --max-model-len 32768 \
  --enable-auto-tool-choice --tool-call-parser kimi_k3 \
  --reasoning-parser kimi_k3

开启 DSpark 投机解码：

--speculative-config '{"model":"Inferact/Kimi-K3-DSpark","method":"dspark","num_speculative_tokens":7,"attention_backend":"FLASHINFER_MLA","draft_sample_method":"probabilistic","rejection_sample_method":"block"}'

每条都来自真实事故的部署笔记：

• --enable-prefix-caching 打开前缀缓存，K3 默认不开。
• 工具调用：在自己的流量上验证；生产智能体应在 tool_calls 返回为空时重试或回退，并考虑严格/结构化工具调用。
• --moe-backend：任何 DEP 环境用 deep_gemm_mega_moe，TP>1 用 flashinfer_trtllm。
• --all2all-backend：NVLink 用 flashinfer_nvlink_one_sided，RDMA 用 deepep_v2。

常见问题：

• 需要多少 GPU？至少一台 8× B300（或 GB300）节点才能跑起来；多数生产部署用多节点专家+数据并行，走 RDMA 或 NVLink。
• K3 支持前缀缓存吗？默认开吗？支持全注意力 KV 与循环 KDA 状态上的前缀缓存，但默认不开——传 --enable-prefix-caching。
• vLLM 在 AMD GPU 上支持 K3 吗？支持。ROCm 支持随发布上线，更广的调优在路线图上。

完整配方、算子与完整博文：模型在 huggingface.co/moonshotai/Kimi-K3，DSpark 草稿模型在 huggingface.co/Inferact/Kimi-K3-DSpark，配方与 Docker 镜像在 recipes.vllm.ai/moonshotai/Kimi-K3，完整博文在 vllm.ai/blog/2026-07-27-k3。

为 K3 建造的这些基础设施，现在属于之后到来的每一个模型。

部署操作参考

给准备上手 K3 服务部署的工程团队三条可核对的操作依据：

1. 硬件检查：部署前先确认至少一台 8× B300（或 GB300）节点可用——这是 2.8 万亿参数 MoE 模型跑起来的最低配置；单机方案可先用 --max-model-len 32768 控制上下文长度试跑推理任务。
2. 功能配置：部署命令里显式加 --enable-prefix-caching（K3 默认不开前缀缓存），需要工具调用时配 --tool-call-parser kimi_k3，生产环境的智能体要对 tool_calls 返回为空做重试与回退处理。
3. 速度评估：延迟敏感的推理场景开启 DSpark 投机解码后，用真实流量测量每用户 token 生成速度——编程类低熵任务加速明显（约 4.73 token/步），创意写作类高熵任务增益有限（约 2.61 token/步）。

原文信息

• 作者：vLLM 项目（@vllm_project），开源大模型推理引擎官方团队
• 发布时间：2026-07-27
• 模型地址：huggingface.co/moonshotai/Kimi-K3

原文地址：