vLLM 对 Kimi K3.1 Pro 的 Day-0 支持：稀疏注意力、DCP 与零失配强化学习
摘要
vLLM 为 Moonshot AI 的 Kimi K3.1 Pro 提供了 Day-0 支持，该模型是一个拥有 2.8T 参数（104B 激活）的开源权重多模态 MoE，支持 1M token 上下文，可在 NVIDIA GPU、AMD GPU、Google TPU 和阿里巴巴 T-HEAD 真武 PPU 上运行。此次发布意义重大，因为 K3.1 Pro 在原本混合 KDA + MLA 模型的所有 24 个全注意力层上增加了稀疏注意力（DSA），而 vLLM 必须重新设计 KV 缓存、预填充分片、解码并行和低延迟解码路径，以高效服务这种混合稀疏架构。
Kimi K3.1 Pro 的变化
Kimi K3.1 Pro 保持了 Kimi K3 的架构，但在每个全注意力层上增加了稀疏注意力索引器。该模型仍然是 93 层混合架构，包含 69 个 KDA 层和 24 个全注意力层，896 个 MoE 专家（16 个激活），MXFP4 MoE 权重，以及 1M token 上下文窗口。
| Kimi K3 | Kimi K3.1 Pro | |
|---|---|---|
| 层数 | 93：69 KDA + 24 全注意力 | 93：69 KDA + 24 全注意力 |
| 全注意力层 | 密集 MLA | MLA + DSA 索引器（top-2048），NoPE |
| 索引器 | 无 | 32 头 × 128 维，FP8 键 |
| MoE | 896 专家，16 激活，MXFP4 | 不变 |
| 上下文窗口 | 1M | 1M |
| 总参数 | 2.8T | 2.8T |
核心的技术变化在于注意力机制。每个稀疏层在 MLA 注意力旁边保留一个小型索引器。索引器为每个 token 存储一个 FP8 键，包括其缩放因子共 132 字节，并使用 32 个轻量级头为每个查询对所有先前 token 进行评分。然后保留前 2,048 个 token，MLA 注意力仅在这 2,048 个 token 上运行。vLLM 指出 DSA 是在 DeepSeek-V3.2 中引入的，并指向其早期的 DeepSeek-V3.2 文章以获取详细的索引器说明。
稀疏注意力降低长上下文解码带宽
DSA 的最大收益体现在长上下文解码中，这受限于内存带宽。密集 MLA 每层每个上下文 token 读取 576 字节的 FP8 潜在表示。DSA 仍然扫描整个上下文，但在扫描期间仅读取 132 字节的索引键，然后仅对 2,048 个 token 读取完整的潜在表示。在长上下文下，这大约是密集 MLA 每层读取字节数的 23%。
这是 K3.1 Pro 的核心服务论点：模型保持 1M token 上下文，但将长上下文解码步骤的每层内存流量减少到密集 MLA 流量的约四分之一。
三种状态的紧凑 KV 缓存
vLLM 将每个缓存块的 MLA 潜在表示、索引器键和 KDA 状态打包在一起，而不是为每层提供相同大小的页面。每个 DSA 层存储两种不同宽度的每 token 缓存：MLA 潜在表示（FP8 为 576 字节，NVFP4 为 352 字节）和索引键（FP8 为 132 字节，MXFP4 为 68 字节）。两种宽度都不是彼此的倍数，并且 69 个 KDA 层每个请求添加一个循环状态，该状态远大于一层的 token 页面。传统的每层相同大小缓存必须将小页面填充到最大页面。
vLLM 改为将缓存的一个块作为单个连续行，包含该块的所有 24 个 DSA 层的 MLA 页面和索引键页面，以及共享该块的 KDA 状态。行内的页面可以具有不同大小；唯一约束是行包含 KDA 状态。块大小是 2 的幂，因此预填充和解码实例在不同 TP 大小下运行的块可以均匀划分，并可以配对进行 KV 传输。
注意力内核仍然看到它们期望的小型固定大小页面。vLLM 在每一步之前将块表和缓存槽转换为内核页面地址，因此 FlashInfer 和 FlashMLA 的稀疏 MLA 内核以及 DeepGEMM 的索引器内核无需更改即可读取紧凑缓存。
这种布局实现了三件事：
- 任意稀疏 MLA 内核和 KV 格式。 在 Blackwell 上，默认是 FlashInfer 的稀疏 MLA，使用 FP8 潜在表示。FlashInfer 的 PrimsTS 内核也支持 NVFP4 潜在表示。
- 分离式服务。 每个块是内存中的一个连续范围，因此预填充/解码传输可以通过一次大型 RDMA 读取移动它，而不是数十次小的逐层读取。
- 共享基础设施。 相同的紧凑规划器服务于 GLM-5.3-Flash 和 DeepSeek-V4，它们的缓存具有相同的混合页面大小问题。
每个 token 的 KV 缓存占用
在张量并行下，MLA 潜在表示和索引键在每个 GPU 上复制；KDA 状态按请求存储，如 K3 中。
| 每个 GPU 每个 token 的 KV 缓存（24 个全注意力层） | 字节 |
|---|---|
| Kimi K3，FP8 MLA 潜在表示 | 13,824 |
| Kimi K3.1 Pro，FP8 潜在表示 + FP8 索引键 | 16,992 |
| Kimi K3.1 Pro，NVFP4 潜在表示 + MXFP4 索引键 | 10,080 |
潜在表示和索引键可以独立量化。仅 NVFP4 潜在表示就已经使 K3.1 Pro 低于 FP8 的 K3。可选的 MXFP4 索引键额外容纳 11% 的 token，并使索引器在长上下文下快 10-20%。两者结合，八块 GB300 GPU 可容纳的 token 数量是 FP8 的 1.7 倍，而 DCP8 将其乘以七：同时约 36 个完整的 1M token 上下文，而 TP8 使用 FP8 时为 3 个。
按 token 分片的预填充改善首 token 时间
对于大型预填充步骤，vLLM 按 token 而不是按头对注意力进行分片。在 TP8 下，每个 GPU 拥有 K3.1 Pro 的 96 个注意力头中的 12 个，这对于稀疏 MLA 预填充来说并不理想：MLA 的潜在 KV 由所有头共享，因此每个 GPU 读取完整缓存仅为 12 个头服务，并且稀疏内核将这些 12 个头填充到其最小 tile。索引器根本不按头拆分，因此每个 GPU 对所有 token 进行评分，其二次成本重复八次。
vLLM 改为使用 all-to-all 将每个 GPU 的查询从“所有 token，12 个头”移动到“1/8 的 token，所有 96 个头”。每个 GPU 为其自己的 token 运行索引器和稀疏 MLA，第二次 all-to-all 将输出返回到头布局。KV 缓存已在 TP 下复制，因此其他不变；MoE、序列并行和缓存布局保持不变。为了平衡因果注意力，每个请求被切成 16 块，GPU r 取块 r 和 15 - r，与预填充上下文并行中使用的平衡拆分相同。两个 all-to-all 直接写入对等方的对称内存。
在 8× GB300 上使用 TP8、真实权重和一次一个请求：
| 提示 token | TTFT，按头分片 | TTFT，按 token 分片 | 加速比 |
|---|---|---|---|
| 27K | 0.82 秒 | 0.71 秒 | 1.16× |
| 108K | 3.72 秒 | 2.89 秒 | 1.29× |
| 340K | 15.89 秒 | 9.42 秒 | 1.69× |
长缓存前缀上的短追加（在代理式轮次中常见）也受益。对于 150K token 缓存前缀上的 2K token 追加，索引器和稀疏 MLA 内核在 8× GB300 上使用 FlashInfer 稀疏 MLA 时每个 GPU 约需 15 毫秒，而不是 56 毫秒。代价是交换缓冲区，每个 GPU 约 0.8 GiB 的 KV 缓存。
带稀疏索引器的解码上下文并行
张量并行在每个 GPU 上复制 MLA 潜在表示，因此添加 GPU 不会增加 KV 容量。解码上下文并行（DCP）改为按 token 对缓存进行分片：W 个 GPU 中的 GPU r 存储每第 W 个 token。对于密集 MLA，每个 GPU 在其分片上执行注意力，部分输出通过其 log-sum-exp（LSE）组合。DSA 增加了一步：每个 GPU 只能对其自己的 1/W 的 token 进行排名，因此全局 top-2048 必须在每层注意力开始之前跨 GPU 合并。
精确 top-k 合并，流量减少约 10 倍
通用合并将每个 GPU 的完整本地 top-2048（作为 FP32 分数和 token ID 对）发送到所有其他 GPU。在 DCP8 下，8× GB300 上，64 个类似 AgentX 的请求，每个 5 个查询 token，需要 258 微秒，而注意力模块总时间为 671 微秒。
vLLM 发送的数据少得多。每个 GPU 仅从其 BF16 分数中挑选最佳 1.5 × 2048 / W 个候选，并将每个候选及其分数打包为 32 位，大约减少 10 倍的字节。然后每个 GPU 从收集的候选中基数选择相同的全局 top-2048。合并保持精确：如果 GPU 持有的 top-2048 多于其发送的，选择会检测到，该 GPU 会重新发送该行的完整本地 top-k。
精确的一轮合并比通用合并快 1.27-1.51 倍。从批次 32 开始，在 128K 上下文下，K3.1 Pro 在 DCP8 下的稀疏注意力比 K3 的密集 MLA 更快。
然后部分注意力输出通过两个 CuTe DSL 内核在对称内存上交换并通过 LSE 组合：在 8× GB300 上跨 320 个 BF16 形状，比现有 CUDA 实现快高达 3.7 倍，输出逐位相同。vLLM 指出这对 DCP 下的每个 MLA 模型都有帮助。
无合并的 DCP 预填充
普通的 DCP 预填充将为每个提示 token 支付合并和 LSE 组合的成本，并在每个 GPU 上重复注意力工作。当 DCP 组是 TP 组时，vLLM 改为从所有 GPU 收集步骤的上下文（包括 MLA 潜在表示和索引键）到对称内存工作区（FP8 下每 GPU 每 1M token 约 0.7 GB）。然后在其上运行上述按 token 分片的预填充。不再有合并或组合，输出与无 DCP 的按 token 分片预填充逐位匹配。
| 一个 DSA 层，DCP8 在 8× GB300 上，AgentX 混合 16K token 步骤 | DCP 预填充 | 收集上下文预填充 |
|---|---|---|
| FP8，FlashInfer trtllm-gen | 24.8 毫秒 | 5.8 毫秒（4.3×） |
| FP8，FlashInfer PrimsTS | 24.8 毫秒 | 5.7 毫秒（4.3×） |
| NVFP4，FlashInfer PrimsTS | 25.7 毫秒 | 6.2 毫秒（4.1×） |
端到端，单个请求在 DCP8 下的预填充速度与 TP8 下相同：在 27K、108K 和 340K token 下分别为 1.10、4.40 和 14.61 秒，而 8× GB300 上使用 FP8 KV 时为 1.10、4.39 和 14.50 秒。
何时使用 DCP
DCP 以每步延迟换取 KV 容量。DCP8 将每个 GPU 的 MLA 和索引键缓存减少八倍，而 KDA 状态已按头拆分。当上下文适合时，普通 TP 在低并发下解码更快；当 KV 成为限制时，DCP 才有价值，例如非常长的上下文或许多长期存在的代理会话。在 8× GB300 上，DCP8 可容纳 21.8M token 的 FP8 KV，而 TP8 为 3.04M，或使用 NVFP4 潜在表示时为 32.1M 对 4.49M。在并发 1 时，TPOT 在 32K 上下文下 TP8 为 9.35 毫秒，DCP8 为 11.48 毫秒，在 128K 下为 9.45 对 11.58 毫秒；融合解码路径将 DCP8 降至 5.96 和 6.04 毫秒。
八块 GPU 在 TP8 下也可以服务完整的 1M token 请求：在 8× GB300 上使用 FP8 KV，缓存可容纳 3.04M token，即 2.9 个并发的 1M token 请求。
针对 DSA 层的融合低延迟解码
对于 Kimi K3，vLLM 提供了一条可选的解码路径，用针对小批量调优的 CuTe DSL 内核替换几乎所有算子。它将通信融合到计算中，重新设计 MoE 调度，并将权重预取到 L2。对于 K3.1 Pro，此路径现在覆盖 DSA 层。DSA 层运行如下：
- 一个打包的输入投影，用于查询、KV 潜在表示、输出门以及索引器的键和头权重；
- 一个融合的索引器前端：查询归一化、索引器的查询投影、其 FP8 或 MXFP4 量化（头权重已折叠）以及新 token 的索引键，在一个内核中；
- MLA 查询，包括上投影和吸收的键投影，并将新 token 的潜在表示写入 KV 缓存，与索引器重叠而不是在其之前运行；
- 一个融合的索引器：一个键平衡的评分器和一个精确的 top-k 选择，在两个内核中发出注意力读取的物理 KV 行；
- 稀疏注意力：FlashInfer 稀疏 MLA（trtllm-gen 或 PrimsTS，按批量大小选择）或 FlashMLA 稀疏；在 DCP 下，批次 1-8 时，使用为形状构建的 CuTe DSL 内核，批次 1 时每层 11.9 微秒对 21.4 微秒；
- 值投影和 sigmoid 门在一个内核中，然后是 K3 的输出投影及其融合的 all-reduce。
在 DCP 下，查询发布到每个 GPU，每个 GPU 的 top-k 候选被交换并精确合并，部分输出通过 LSE 组合，全部通过内核内的 NVLink 邮箱完成，路径上没有 NCCL 集合。
融合解码路径在批次 1 时快 1.63 倍，在批次 64 时仍快 1.18 倍（8× GB300，TP8，1K token 输入）。使用 DSpark 推测解码和 7 个草稿 token，融合路径将并发 1 时的每 token 时间从 2.86 毫秒降至 2.14 毫秒，GSM8K 准确率不变。在 DCP8 下，融合路径将并发 1 时的 TPOT 从 32K 上下文下的 11.48 毫秒降至 5.96 毫秒，从 128K 下的 11.58 毫秒降至 6.04 毫秒。
使用 DSpark 进行推测解码
vLLM 为 K3.1 Pro 训练了一个 DSpark 推测器，并发布了预览检查点 Inferact/Kimi-K3.1-Pro-DSpark-preview。在温度 1.0 和 top-p 0.95 的现实采样下，预览在 GSM8K 上使用 7 个草稿 token 达到平均接受长度 4.597。在 8× GB300 上使用 TP8 的批次大小 1 时，解码加速 3.0 倍。推测器还在 K3.1 Pro 的完整上下文窗口（最多 1M token）上保持准确率，在长上下文 BEAM 基准上测量。
vLLM 将此检查点描述为仅预览，并表示正在训练更准确、更高效的推测器，即将发布。
在 NVIDIA GB300 和 Rubin 上的代理式服务
vLLM 使用 SemiAnalysis AgentX 基准在 NVIDIA GB300 和 NVIDIA Rubin 上对其 Day-0 镜像进行了基准测试。
NVIDIA GB300
在前沿的延迟敏感端，Kimi K3.1 Pro 保持每位用户每秒 375.9 个 token。进一步沿前沿，它保持每位用户每秒超过 100 个 token，同时每 GPU 每秒服务 19.2K 总 token。在吞吐量端，它达到每 GPU 每秒 37.8K token，约为最具交互性点的 26 倍，而每位用户仍看到约每秒 54 个 token。GB300 扫描使用 4 个推测 token 和 3.36 个 token 的合成接受长度。
NVIDIA Rubin
在 NVIDIA Rubin 上，Kimi K3.1 Pro 在前沿的延迟敏感端保持每位用户每秒 815.6 个 token。进一步沿前沿，它保持每位用户每秒超过 100 个 token，同时每 GPU 每秒服务 46.0K 总 token。在吞吐量端，它达到每 GPU 每秒 68.7K token，约为最具交互性点的 51 倍，而每位用户仍看到约每秒 75 个 token。并发高达 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。
- 整个模型上的 LoRA RL。 Rank-32 LoRA 覆盖所有注意力投影和所有 896 个专家，基础模型和适配器在 vLLM 和 Megatron 之间逐位相同。
- 批量不变内核，原生支持。 使用
VLLM_BATCH_INVARIANT=1，token 的 log-prob 不依赖于其批次，并且更多 vLLM 的高性能内核在设计上是批量不变的，例如 DeepSelect top-k。
在完整模型上超过 100 步，rollout/训练器 KL 在每一步都恰好为 0.0，而 AIME mean@8 从 0.451 上升到 0.664。vLLM 表示批量不变路径的性能优化正在进行中，源代码位于 Inferact/zero-mismatch-rl。
AMD Instinct MI355X 支持
在 AMD Instinct MI355X 上，vLLM 结合了 MXFP4 索引、稀疏注意力和解码上下文并行。这些优化减少了对长上下文的内存需求，并提高了预填充和解码效率。
原生 MXFP4 索引器
索引器在选择 2,048 个 token 进行注意力之前扫描上下文。MXFP4 将每个索引键从 FP8 的 132 字节减少到包括缩放因子的 68 字节，将索引缓存存储减少 48.5%。评分使用原生 FP4 矩阵指令，具有 FP32 累加和跨头的加权归约。在推测验证期间，键在查询行之间重用，以减少重复读取。在 AgentX 扫描中，MXFP4 索引器配置在并发 48 时总工作负载吞吐量提高了 5.3%。
上下文并行稀疏注意力预填充
在预填充期间，GPU 收集索引键并在它们之间划分查询行。每个 GPU 对其分配的行针对完整上下文进行评分，并直接选择全局 top-k，避免合并每个排名的候选。当减少通信并适合工作区预算时，主注意力可以单独收集 KV，然后处理本地头的所有查询行。
| 输入/输出 token | 总吞吐量（token/秒） | 输出吞吐量（token/秒） | 中位 TTFT（秒） | 中位 TPOT（毫秒） |
|---|---|---|---|---|
| 8K / 1K | 5,357.8 → 6,015.4（+12%） | 595.3 → 668.4 | 2.462 → 1.875 | 24.571 → 22.063 |
| 128K / 100 | 6,950 → 17,678（+154%） | 5.30 → 13.48 | 268.7 → 105.5 | 331.5 → 129.6 |
设置：MI355X，TP8/DCP8，并发 16，64 个提示，禁用前缀缓存。
FlyDSL 稀疏 MLA 直接从 FP8 KV 缓存读取选定的 token。每个工作组处理一个查询行及其本地注意力头，在预填充步骤中提供跨多个查询行的并行性。较小的批次保留 Triton 路径，它在每行内提供额外的并行性。
| 实现 | 基准持续时间（秒） | 中位 TTFT（秒） | 输出吞吐量（token/秒） |
|---|---|---|---|
| Triton | 432.8 | 96.2 | 14.79 |
| FlyDSL | 404.4 | 89.8 | 15.83 |
| 改进 | 降低 6.6% | 降低 6.6% | 提高 7.0% |
设置：MI355X，TP8/DCP8，并发 16，64 个提示，ISL/OSL 128K/100。
融合低延迟解码
对于小型推测验证批次，DSA 索引和稀疏注意力分别运行，然后是一个持久化单内核，将注意力输出投影、AttnRes 和完整的潜在 MoE 计算（包括张量并行 all-reduce）融合到一次启动中。这减少了内核启动开销，并将 MoE 权重加载与前面的归约和残差处理重叠。专用路径支持每步最多 8 个验证 token，包括一个具有 7 个草稿 token 的请求。平均 TPOT 从 6.02 毫秒提高到 4.40 毫秒，降低 27.0%，在 TP8/DCP1 上使用 FP8 索引器，8K/1K，并发 1，7 个草稿 token，合成接受长度 3.84。
跨 GPU 通信
在解码期间，每个 GPU 交换候选分数，同时保持 token ID 本地。共享阈值和一致的平局处理确定选择哪些本地候选。对于 2,048 个候选，仅交换分数将候选负载从每个查询每 GPU 16 KiB 减半到 8 KiB。AITER 通过专用 GPU 内核加速 DCP all-gather，该内核通过 HIP IPC 读取对等缓冲区并直接写入所需的输出布局，结合数据收集和布局转换。在八块 MI355X GPU 的独立微基准测试中，对于测试的查询和候选张量形状，AITER 路径将 all-gather 延迟比 RCCL 降低了 53-61%。
Google TPU 支持
vLLM 在 Day-0 通过 vllm-torchtpu 在 TPU 上支持 Kimi K3.1 Pro，已在 TPU v7x 的 16 芯片切片上验证。布局为 TP32，MoE 使用 EP32，DCP 按 token 分片 MLA 潜在表示和索引键以支持长上下文。DSA 的工作在 TPU 的两种计算单元之间分配：TensorCore 对 FP8 索引键进行评分，然后 SparseCore 选择前 2,048 个 token 并将其潜在表示收集到密集缓冲区中，供 TensorCore 的 MXU 运行注意力。与 GPU 一样，DSA 和 KDA 状态共享一个块索引 KV 池，这使前缀缓存在混合缓存中正常工作。
阿里巴巴 T-HEAD 真武 PPU 支持
阿里巴巴 T-HEAD 团队通过 vllm-sail 插件增加了在阿里巴巴 T-HEAD 真武 PPU（M890 和 810E）上运行 Kimi K3.1 Pro 的支持。已验证的配置是：
- 810E：两个节点，TP32 / EP32，使用 W4A16 MoE 后端。
- M890：四个节点，TP8 / DP4 / EP32，使用 DeepEP。
vLLM 表示这是真武 PPU 首次为主流开源大模型提供 Day-0 支持，持续支持即将推出。
快速开始
在 NVIDIA GPU 上，vLLM 提供 vllm serve 命令，使用张量并行 8、fastsafetensors 加载、Kimi K3 工具调用和推理解析器，以及具有 5 个推测 token 的 DSpark 推测配置：
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 上，命令启用 AITER 和快速 GPU safetensors 加载，设置张量并行 8，限制序列为 16，设置 GPU 内存利用率为 0.85，并使用相同的 DSpark 推测配置：
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 是一个混合模型，具有三种不同的每 token 或每请求状态：MLA 潜在表示、DSA 索引键和 KDA 循环状态。vLLM 的 Day-0 支持表明，高效服务此类模型需要跨 KV 缓存布局、预填充分片、解码并行和低延迟内核融合的协调更改，而不是单个注意力内核。
紧凑块缓存是启用的抽象：它允许注意力内核保持其固定大小页面，而服务堆栈连续存储混合宽度状态，以便 RDMA 传输和前缀缓存。按 token 分片的预填充解决了 MLA 在张量并行下的头复制问题，而具有精确 top-k 合并的 DCP 解决了 TP 在长上下文下的 KV 容量限制。融合解码路径和 DSpark 推测解码针对代理工作负载所依赖的小批量延迟。
零失配 RL 结果与推理性能分开，但对训练基础设施意义重大：vLLM 报告 vLLM rollout 和 Megatron 训练之间的 log-probs 逐位相同，适用于基础模型和覆盖所有注意力投影和所有 896 个专家的 rank-32 LoRA 适配器，KL 在 100 步中恰好为 0.0。这消除了 RL 不稳定的一个来源，而不是通过重要性采样或路由重放来限制它。
平台覆盖
Day-0 支持涵盖四个硬件系列：NVIDIA GPU、AMD GPU、Google TPU 和阿里巴巴 T-HEAD 真武 PPU。NVIDIA 路径包括 GB300 和 Rubin 上的 SemiAnalysis AgentX 基准。AMD 路径包括 MI355X 优化，用于 MXFP4 索引、上下文并行稀疏预填充、融合低延迟解码和 AITER all-gather。TPU 路径通过 vllm-torchtpu 在 TPU v7x 的 16 芯片切片上运行，使用 TP32/EP32 和 DCP。T-HEAD 路径通过 vllm-sail 插件在 810E 和 M890 配置上运行。
vLLM 感谢 Moonshot 开源 Kimi K3.1 Pro，并感谢 Inferact、AMD 和阿里巴巴 T-HEAD 提供 Day-0 支持，以及 NVIDIA 的帮助。