vLLM 为 Kimi K3.1 Pro 提供 Day-0 支持，覆盖 GPU、TPU 与 PPU

Kimi K3.1 Pro 是 Moonshot AI 能力最强的开放权重模型：一个 2.8T 参数（激活 104B）的多模态 MoE，上下文长度达 1M token，在编程、智能体和知识类基准测试上可与最强的闭源模型比肩。

主要变化在注意力机制：K3.1 Pro 为全部 24 个全注意力层加入了稀疏注意力（DSA）以提升效率。vLLM 在发布当天即提供支持，覆盖 NVIDIA GPU、AMD GPU、Google TPU 和阿里巴巴平头哥 PPU。

TL;DR

• 混合模型上的稀疏注意力：K3.1 Pro 保留 K3 的 KDA + MLA 混合结构，并在全部 24 个 MLA 层上加入 DSA 索引器。在长上下文下，一次解码步骤每层读取的字节数约为稠密 MLA 的四分之一。
• 一份 KV 缓存承载三种状态：vLLM 把每个块的 MLA latent、索引器键和 KDA 状态打包在一起。这份打包缓存配合 FlashInfer 和 FlashMLA 稀疏内核运行，支持 FP8 或 NVFP4 KV，索引键可选 MXFP4，P/D 分离时可直接原样传输。
• Token 分片的预填充注意力：在 8× GB300 上处理 340K token 时，首 token 延迟（TTFT）比按头分片的预填充最多快 1.69×。
• 带稀疏索引器的解码上下文并行（DCP）：精确的 top-k 合并让通信量减少约 10×，使注意力模块在 DCP8 下快 1.3–1.5×。DCP 预填充注意力每层快 4.1–4.3×，DCP8 可容纳的 KV token 数是 TP8 的 7.2×。
• 融合的低延迟解码：Kimi K3 的专用 CuTe DSL 解码路径现已覆盖 DSA 层，在 8× GB300 上解码快 1.2–1.6×，在 DCP8 下快 1.9×。
• 智能体服务：在 NVIDIA GB300 上，延迟敏感端每用户最高 375.9 tok/s，吞吐端每 GPU 总计 37.8K tok/s；在 NVIDIA Rubin 上，SemiAnalysis AgentX 基准中每用户最高 815.6 tok/s，每 GPU 总计 68.7K tok/s。
• 发布当天即支持零误差 RL：首次实现发布当天支持零误差 RL：vLLM 与 Megatron 对基础模型和 LoRA 适配器产出的 log-prob 逐位一致，因此在 100 步全模型训练的每一步中，PPO KL 都精确为 0。

快速开始

在 NVIDIA GPU 上：

# See the Kimi K3.1 recipe for the Docker image and multi-node commands.
vllm serve moonshotai/Kimi-K3.1-Pro \
  --tensor-parallel-size 8 \
  --trust-remote-code \
  --load-format fastsafetensors \
  --enable-auto-tool-choice \
  --tool-call-parser kimi_k3 \
  --reasoning-parser kimi_k3 \
  --speculative-config '{"model":"Inferact/Kimi-K3.1-Pro-DSpark-preview","num_speculative_tokens":5,"method":"dspark","draft_sample_method":"probabilistic"}'

在 AMD GPU 上：

VLLM_ROCM_USE_AITER=1 SAFETENSORS_FAST_GPU=1 \
vllm serve moonshotai/Kimi-K3.1-Pro \
      --served-model-name kimi-k31-pro \
      --tensor-parallel-size 8 \
      --trust-remote-code \
      --load-format fastsafetensors \
      --max-num-seqs 16 \
      --gpu-memory-utilization 0.85 \
      --speculative-config '{"model":"Inferact/Kimi-K3.1-Pro-DSpark-preview","num_speculative_tokens":5,"method":"dspark","draft_sample_method":"probabilistic"}'

Kimi K3.1 Pro 的新变化

K3.1 Pro 中的稀疏注意力

每个稀疏注意力层都在其 MLA 注意力旁配有一个小型索引器。索引器为每个 token 保留一个 FP8 键（含缩放因子共 132 字节），并用 32 个轻量头为每个查询给所有更早的 token 打分，然后保留得分最高的 2,048 个 token。MLA 注意力随后精确计算，但只在这 2,048 个 token 上进行。DSA 最早由 DeepSeek-V3.2 提出；我们的DeepSeek-V3.2 文章对索引器有更详细的介绍。

收益在长上下文解码中最明显，因为这一环节受内存带宽限制。稠密 MLA 每层要为每个上下文 token 读取 576 字节的 FP8 latent。DSA 仍会扫描整个上下文，但只读取 132 字节的索引键，然后仅为 2,048 个 token 读取完整 latent。在长上下文下，这约为稠密 MLA 每层读取字节数的 23%。

图 1：Kimi K3.1 Pro 中的稀疏注意力（DSA）。索引器为每个历史 token 打分，保留前 2,048 个，每个查询头只在这些 token 的 latent 上精确计算注意力。可逐步查看。

KV cache 占用

索引键是 MLA latent 之外的第二份逐 token 缓存。在张量并行（TP）下，两者都会复制到每块 GPU 上；KDA 状态则按请求划分，与 K3 相同。

latent 和索引键可以独立量化。仅把 latent 换成 NVFP4，K3.1 Pro 就已经低于 K3 的 FP8 水平。再选用 MXFP4 索引键，还能多容纳 11% 的 token，并让索引器在长上下文下快 10–20%。两者叠加后，八块 GB300 GPU 能容纳的 token 数是 FP8 的 1.7 倍，而 DCP8 再将其乘以七：约可同时容纳 36 个完整的 100 万 token 上下文，相比之下 TP8 配 FP8 只有 3 个。

图 2：在 8× GB300 上实测的 KV cache 容量。可切换 latent 与索引键格式、并行方式或上下文长度，查看能容纳多少个完整上下文。

一个 KV cache，三种状态

每个 DSA 层都存有两份宽度不同的逐 token 缓存：MLA latent（FP8 下 576 字节，NVFP4 下 352 字节）和索引键（FP8 下 132 字节，MXFP4 下 68 字节）。两种宽度互不成倍数。69 个 KDA 层各自还要为每个请求额外保存一份循环状态，其大小远超单层一页 token。如果让每一层都使用同样大小的页，小页就得补齐到最大页的尺寸。

vLLM 按块而非按层打包缓存。缓存中的一个块是一条连续的行，存放该块在全部 24 个 DSA 层上的 MLA 页和索引键页，以及与该块共享的 KDA 状态。一行内的页大小可以不同，唯一约束是这一行要容纳 KDA 状态。块大小取 2 的幂，因此以不同 TP 规模运行的 prefill 与 decode 实例的块可以整除对齐，配对进行 KV 传输。

注意力 kernel 看到的仍是它们预期的小尺寸固定页。vLLM 在每一步之前把块表和缓存槽转换为 kernel 页地址，因此 FlashInfer 和 FlashMLA 的稀疏 MLA kernel 以及 DeepGEMM 的索引器 kernel 无需改动就能读取打包后的缓存。

这种布局让栈中其余部分得以运转：

• 任意稀疏 MLA kernel 与 KV 格式。在 Blackwell 上，默认使用 FlashInfer 的稀疏 MLA 配 FP8 latent。FlashInfer 新的 PrimsTS kernel 也支持 NVFP4 latent。
• 分离式服务。每个块都是一段连续内存，因此 P/D 传输只需一次大 RDMA 读取就能搬走，而不用做几十次按层的小读取。
• 共享基础设施。同一套打包规划器也服务于 GLM-5.3-Flash 和 DeepSeek-V4，它们的缓存同样面临页大小混杂的问题（见 DeepSeek V4 文章）。

图 3：TP8 下打包缓存的布局。注意力组和三个 KDA 组共享一个块行池；选择一个 token、一个 DSA 层和一个 KDA 层，即可看到各自落在哪个块和哪一页。

Prefill：按 token 而非按头切分注意力

在 TP8 下，每块 GPU 负责 K3.1 Pro 的 96 个注意力头中的 12 个。这对稀疏 MLA prefill 来说并不合适，原因与我们 GLM-5.3 文章中所述相同：

• MLA 的 latent KV 由所有头共享，因此每块 GPU 都要读取完整缓存，却只服务 12 个头，而稀疏 kernel 还会把这 12 个头补齐到最小 tile。
• 索引器完全不按头切分：每块 GPU 都要为每个 token 打分，于是其平方级开销被重复了八次。

对于较大的预填充步骤，vLLM 改为按 token 对注意力进行分片。一次 all-to-all 通信把每块 GPU 的 query 从“全部 token、12 个头”变成“1/8 的 token、全部 96 个头”。每块 GPU 只对自己负责的 token 运行 indexer 和稀疏 MLA，第二次 all-to-all 再把输出还原成按头排布。KV cache 在 TP 下本来就是复制的，所以其他部分不用改。MoE、序列并行和 cache 布局都保持原样。为了平衡因果注意力，每个请求被切成 16 份，GPU r 负责第 r 份和第 15 − r 份，与预填充上下文并行采用同样的均衡切分。两次 all-to-all 都直接写入对端的对称内存。

图 4：四块 GPU 上按 token 分片的预填充，改造前后对比。按头切分时，每块 GPU 都要重复运行 indexer，并给自己的头分块补齐；经过一次 all-to-all 后，每块 GPU 只用全部头对均衡分到的那部分 token 打分。可逐步查看。

在 8× GB300、TP8、真实权重、每次只处理一个请求的条件下，结果如下：

在很长的缓存前缀上追加少量内容（智能体多轮对话中很常见）同样受益。在 150K token 的缓存前缀上追加 2K token 时，indexer 和稀疏 MLA 内核每块 GPU 约耗时 15 ms，而不是 56 ms（8× GB300，FlashInfer 稀疏 MLA）。代价是交换缓冲区，每块 GPU 约 0.8 GiB 的 KV cache。

长上下文：带稀疏 indexer 的解码上下文并行

TP 会在每块 GPU 上复制 MLA latent，所以增加 GPU 并不会增加 KV 容量。解码上下文并行（DCP）改为按 token 分片缓存：W 块 GPU 中的第 r 块存储每第 W 个 token。对于稠密 MLA，每块 GPU 只在自己的分片上做注意力，部分输出再按 log-sum-exp（LSE）合并。

DSA 多了一步：每块 GPU 只能对自己那 1/W 的 token 排序，所以每一层都要在注意力开始前跨 GPU 合并出全局 top-2048。

流量减少 10 倍的精确 top-k 合并

通用合并方式会把每块 GPU 完整的本地 top-2048（FP32 分数与 token id 对）发给其他所有 GPU。在 8× GB300 上以 DCP8 运行、64 个类似 AgentX 的请求（每个 5 个 query token）时，这一步要花 258 µs，而整个注意力模块耗时 671 µs。

vLLM 发送的数据少得多。每块 GPU 直接从 BF16 分数中挑出最好的 1.5 × 2048 / W 个候选，把每个候选和它的分数打包进 32 位，字节数约减少 10 倍。然后每块 GPU 从收集到的候选中用基数选择挑出相同的全局 top-2048。合并仍然是精确的：如果某块 GPU 实际持有的 top-2048 数量多于它发送的数量，选择过程会发现，并让该 GPU 重新发送该行的完整本地 top-k。

图 5：8× GB300 上 DCP8、每个请求 5 个 query token 时的一个 DSA 注意力模块。精确的单轮合并比通用合并快 1.27–1.51 倍。将鼠标悬停在柱上可查看数值。

从 batch 32 起，在 128K 上下文下，K3.1 Pro 在 DCP8 下的稀疏注意力已经比 K3 的稠密 MLA 更快。

随后，各部分注意力输出会在对称内存上通过两个 CuTe DSL 内核交换并按 LSE 合并：比现有 CUDA 实现快最多 3.7 倍（8× GB300 上的 320 个 BF16 形状），且输出逐位一致。这对 DCP 下的所有 MLA 模型都有帮助。

无需合并的 DCP 预填充

如果直接做 DCP 预填充，每个提示词 token 都要付出合并与 LSE 组合的代价，而且每块 GPU 上都会重复做一遍注意力计算。当 DCP 组就是 TP 组时，vLLM 改为把这一步的上下文（包括 MLA latent 和 index key）从所有 GPU 汇集到一块对称内存工作区（FP8 下每 GPU 每 1M token 约 0.7 GB），再在上面跑上一节介绍的按 token 分片的预填充。这样既不需要合并也不需要组合，输出与不带 DCP 的按 token 分片预填充逐位一致。

端到端来看，单个请求在 DCP8 下的预填充速度与 TP8 相当：27K、108K、340K token 时分别为 1.10、4.40、14.61 s，而 TP8 为 1.10、4.39、14.50 s（8× GB300，FP8 KV）。

何时使用 DCP

DCP 用单步延迟换 KV 容量：DCP8 把每 GPU 的 MLA 缓存和 index-key 缓存都缩小到八分之一，而 KDA 状态本来就按 head 拆分。上下文放得下时，低并发下普通 TP 解码更快；当 KV 成为瓶颈时 DCP 才划算，比如超长上下文或大量长生命周期的智能体会话。在 8× GB300 上，DCP8 能容纳 21.8M token 的 FP8 KV，TP8 只有 3.04M（latent 用 NVFP4 时分别为 32.1M 和 4.49M）。并发为 1 时，32K 上下文下 TP8 的 TPOT 为 9.35 ms，DCP8 为 11.48 ms（128K 时为 9.45 对 11.58 ms）；融合解码路径把 DCP8 降到 5.96 和 6.04 ms。

TP8 的八块 GPU 也能服务完整的 1M token 请求：8× GB300 配 FP8 KV 时缓存可容纳 3.04M token，即 2.9 个并发的 1M token 请求。

低延迟解码：融合的 DSA 解码路径

针对 Kimi K3，vLLM 提供了一条可选的解码路径，几乎用为小批量调优的 CuTe DSL kernel 替换了所有算子。它把通信融合进计算，重做了 MoE 调度，并把权重预取到 L2（见 Hyper Optimizing Kimi K3 in vLLM）。对于 K3.1 Pro，这条路径现在覆盖了 DSA 层。一个 DSA 层的执行流程是：

• 把 query、KV latent、输出门以及 indexer 的 key 和 head 权重打包成一次输入投影；
• 融合的 indexer 前端：query norm、indexer 的 query 投影、折入 head 权重的 FP8 或 MXFP4 量化，以及新 token 的 index key，全部在一个 kernel 里完成；
• MLA query（上投影和吸收后的 key 投影，把新 token 的 latent 写入 KV 缓存），与 indexer 重叠执行，而不是先于它运行；
• 融合的 indexer：key 均衡的打分器和精确 top-k 选择分两个 kernel 完成，输出注意力要读取的物理 KV 行；
• 稀疏注意力：FlashInfer 稀疏 MLA（trtllm-gen 或 PrimsTS，按批量大小选择）或 FlashMLA 稀疏；在 DCP 下批量 1–8 时，使用为该形状构建的 CuTe DSL kernel（批量 1 时每层 11.9 µs 对 21.4 µs）；
• value 投影和 sigmoid 门在一个 kernel 里完成，随后是 K3 的输出投影及其融合 all-reduce。

在 DCP 下，query 会发布到每块 GPU，各 GPU 的 top-k 候选被精确交换和合并，部分输出通过 LSE 组合，全部经由 kernel 内的 NVLink mailbox 完成，路径上没有任何 NCCL 集合通信。

图 6：8× GB300、TP8、1K token 输入下每个输出 token 的耗时。融合解码路径在批量 1 时快 1.63×，批量 64 时仍有 1.18×。将鼠标悬停在柱上可查看数值。

在 DSpark 投机解码（7 个草稿 token）下，融合路径把并发 1 时的单 token 耗时从 2.86 ms 降到 2.14 ms，GSM8K 准确率保持不变。在 DCP8 下，融合路径把并发 1 时的 TPOT 在 32K 上下文下从 11.48 ms 降到 5.96 ms，在 128K 下从 11.58 ms 降到 6.04 ms。

基于 DSpark 的投机解码

我们为 K3.1 Pro 训练了一个 DSpark 投机器，并发布了预览版检查点：Inferact/Kimi-K3.1-Pro-DSpark-preview。在真实采样设置下（temperature 1.0、top-p 0.95），该预览版在 GSM8K 上使用 7 个草稿 token 时，平均接受长度已达到 4.597。在 8× GB300 上以 TP8、batch size 1 运行时，解码速度提升 3.0×。在长上下文 BEAM 基准上测得，该投机器在 K3.1 Pro 最长 1M token 的完整上下文窗口内仍能保持准确率。

该检查点仅为预览版。我们正在训练一个更准确、更高效的投机器，很快就会发布。

智能体服务：AgentX

vLLM 在智能体服务负载上表现出色。我们在 NVIDIA GB300 和 NVIDIA Rubin 上，用 SemiAnalysis AgentX 基准测试了我们的 day-0 镜像。

NVIDIA GB300

在前沿的延迟敏感端，Kimi K3.1 Pro 每用户可达 375.9 tokens/s。沿前沿继续推进，它能在每 GPU 每秒处理 19.2K token 的同时，让每个用户仍保持 100 tokens/s 以上。在吞吐端，它达到每 GPU 37.8K tokens/s，约为最具交互性那一点的 26 倍，而每个用户仍能看到约 54 tokens/s。

图 7：Kimi K3.1 Pro 在 NVIDIA GB300 上的 AgentX 帕累托前沿，使用 4 个投机 token，合成接受长度为 3.36 个 token。将鼠标悬停在某个点上可查看其配置和指标。

NVIDIA Rubin

在 NVIDIA Rubin 上，Kimi K3.1 Pro 在前沿的延迟敏感端每用户可达 815.6 tokens/s。沿前沿继续推进，它能在每 GPU 每秒处理 46.0K token 的同时，让每个用户仍保持 100 tokens/s 以上。在吞吐端，它达到每 GPU 68.7K tokens/s，约为最具交互性那一点的 51 倍，而每个用户仍能看到约 75 tokens/s。

图 8：Kimi K3.1 Pro 在 NVIDIA Rubin 上的 AgentX 帕累托前沿。并发不超过 64 的点使用 7 个投机 token，合成接受长度为 3.84 个 token；更高并发使用 3 个投机 token，接受长度为 3.0。将鼠标悬停在某个点上可查看其配置和指标。

day-0 零偏差强化学习

vLLM 的 day-0 支持首次实现了零偏差的强化学习：使用 verl 进行 LoRA RL，vLLM 作为 rollout 引擎，Megatron 作为训练器，训练器的 log-probs 与 rollout 逐位相等。vLLM 没有用重要性采样或路由重放来限制差距，而是在内核层面消除了它：训练器的前向传播逐位复现 rollout，把 RL 训练的稳定性提升到新水平：

• 全模型 LoRA RL。 Rank-32 LoRA 覆盖所有注意力投影和全部 896 个专家，基础模型和适配器在 vLLM 与 Megatron 之间都逐位一致。
• 原生批不变内核。 借助 VLLM_BATCH_INVARIANT=1，一个 token 的 log-prob 不依赖其所在批次，而且 vLLM 越来越多的高性能内核在设计上就是批不变的，例如 DeepSelect top-k。

图 9：相同的 token、相同的内核、相同的 log-probs。切换到默认 rollout 即可对比。

在完整模型上跑 100 步，每一步的 rollout/trainer KL 都恰好是 0.0，而 AIME mean@8 从 0.451 升到 0.664（图 10）。

图 10：在完整模型上进行的 100 步 LoRA RL 训练。

batch-invariant 路径的性能优化仍在进行中。源代码位于 Inferact/zero-mismatch-rl。

AMD

在 AMD Instinct MI355X 上，vLLM 将 MXFP4 索引、稀疏注意力和解码上下文并行结合起来。这些优化降低了长上下文的内存需求，并提升了 prefill 与 decode 的效率。

量化：原生 MXFP4 索引器

索引器先扫描上下文，再选出 2,048 个 token 参与注意力计算。MXFP4 把每个索引键从 FP8 下的 132 字节（含 scale）降到 68 字节，索引缓存存储因此减少 48.5%。打分使用原生 FP4 矩阵指令，配合 FP32 累加和跨注意力头的加权归约。在投机验证阶段，键会在不同查询行之间复用，以减少重复读取。

索引缓存变小后，更多 GPU 显存可以留给缓存的上下文，有利于高并发下的长上下文服务。在 AgentX 的测试中，MXFP4 索引器配置在并发 48 时把总工作负载吞吐量提升了 5.3%。

Prefill：上下文并行稀疏注意力

在 prefill 阶段，各 GPU 收集索引键，并在彼此之间划分查询行。每块 GPU 对自己负责的行与完整上下文打分，直接选出全局 top-k，无需合并各 rank 的候选结果。当这样做能减少通信且不超出工作区预算时，主注意力可以单独收集 KV，然后处理本地注意力头对应的所有查询行。

这些 DCP prefill 优化在开发基准测试中同时提升了吞吐量和延迟表现。

配置：MI355X，TP8/DCP8，并发 16，64 条提示词，前缀缓存关闭。

FlyDSL 稀疏 MLA 直接从 FP8 KV 缓存读取选中的 token。每个工作组处理一个查询行在本地的各个注意力头，从而在 prefill 步骤的大量查询行之间实现并行。较小的批次仍走 Triton 路径，它能在每一行内部提供额外的并行度。

配置：MI355X，TP8/DCP8，并发 16，64 条提示词，ISL/OSL 128K/100

Decode：融合低延迟解码

对于较小的投机验证批次，DSA 索引和稀疏注意力分开执行，随后由一个常驻 monokernel 把注意力输出投影、AttnRes 以及完整的 latent MoE 计算（包括张量并行 all-reduce）融合进单次启动。这减少了内核启动开销，并让 MoE 权重加载与前序的归约和残差处理重叠。这条专用路径每步最多支持八个验证 token，包括单个请求携带七个草稿 token 的情况。

配置：TP8/DCP1，FP8 索引器，8K/1K，c1，草稿 token 7，合成 AL 3.84

通信：高效的跨 GPU 通信

在解码阶段，每块 GPU 交换候选分数，而 token ID 仍保留在本地。通过共享阈值和一致的平局处理规则，决定哪些本地候选被选中。对于 2,048 个候选，仅交换分数就能把每次查询、每块 GPU 的候选数据量从 16 KiB 减半到 8 KiB。

AITER 用一个专用 GPU 内核加速 DCP all-gather：该内核通过 HIP IPC 读取对端缓冲区，并直接写入所需的输出布局。这样就把数据收集和布局转换合二为一，省去了单独的重新排序拷贝。在八块 MI355X GPU 上的独立微基准测试中，对于所测试的查询和候选张量形状，AITER 路径相比 RCCL 将 all-gather 延迟降低了 53–61%

TPU

vLLM 通过 vllm-torchtpu 在 TPU 上实现了对 Kimi K3.1 Pro 的 Day-0 支持，并在 TPU v7x 的 16 芯片切片上完成验证。布局为 TP32，MoE 采用 EP32，DCP 按 token 对 MLA latent 和索引键进行分片，以支持长上下文。DSA 的工作被拆分到 TPU 的两类计算单元上：TensorCore 计算 FP8 索引键的分数，随后 SparseCore 选出前 2,048 个 token，并将其 latent 收集到稠密缓冲区，供 TensorCore 的 MXU 执行注意力计算。与 GPU 上一样，DSA 和 KDA 状态共用一个按块索引的 KV 池，使前缀缓存在这种混合缓存中依然有效。

阿里巴巴平头哥

阿里巴巴平头哥团队通过 vllm-sail 插件，新增了对在平头哥真武 PPU（M890 和 810E）上运行 Kimi K3.1 Pro 的支持。已验证的配置如下：

• 810E：两个节点，TP32 / EP32，使用 W4A16 MoE 后端
• M890：四个节点，TP8 / DP4 / EP32，使用 DeepEP

这是真武 PPU 首次对主流开源大模型提供 Day-0 支持，持续支持也即将到来。

致谢

我们衷心感谢 Moonshot 团队开源 Kimi K3.1 Pro。同时感谢 Inferact、AMD 和阿里巴巴平头哥在 vLLM 中为该模型提供 Day-0 支持，也感谢 NVIDIA 的帮助。