vLLM 首日支持 Thinking Machines 的 Inkling 2 Small

vLLM 支持 Thinking Machines 的Inkling 2 Small在发布当天（day 0）。它是一个多模态（文本和视觉）MoE 模型，总参数 594B、激活参数 17B，上下文长度最高 1M tokens。该模型还自带原生 DSpark 推测器。vLLM 以优化后的性能支持它（在 TP4 下最高 630 TPS/user，接受长度 3.5），并且也支持 LoRA。

TL;DR

• 总参数 594B，激活参数 17B，上下文 1M。一个 48 层 MoE，384 个专家（top-8），接收图像和文本并输出文本。
• 相对 Inkling 的架构升级。块注意力残差、注意力汇（attention sink）、门控注意力，以及 ViT 图像编码器。
• 混合精度 MoE。该 MoE 使用 NVFP4（第 0–39 层）和 MXFP8（第 40–47 层），因此模型可以单节点部署。
• 原生 DSpark 推测器。带 RNN 头的 DSpark 每步起草 7 个 token。
• 大量优化。内核融合、PDL、高度调优的 Gluon 注意力内核，以及序列并行，在 GB200 上以 TP4 达到最高 630 TPS/user，接受长度 3.5。
• RL 和 LoRA 支持。vLLM 为该模型支持 RL（通过 SkyRL）和 LoRA。

你可以用以下方式部署该模型：

vllmservethinkingmachines/Inkling-2-Small\
--tensor-parallel-size8\
--reasoning-parserinkling--tool-call-parserinkling--enable-auto-tool-choice\
--speculative-config'{"method":"dspark","num_speculative_tokens":7,"draft_sample_method":"probabilistic"}'

模型架构

图 1. Inkling 2 Small 架构。金色标记表示相对 Inkling 新增或变更的部分。

Inkling 主干 + 最新进展。Inkling 2 Small 保留了 Inkling 的主干：滑动窗口注意力与全注意力 5:1 的混合比例、用学习到的相对偏置代替 RoPE 的 GQA、每层四个短卷积，以及 sigmoid 路由的 MoE。在此基础上，它加入了最新进展。块注意力残差替换残差流，因此在每个子层之前，一个学习到的 query 会混合此前 6 层块的输出。门控注意力在每个头的输出上加入一个 sigmoid 门，同时配合一个逐 token 的注意力汇。它用 23 层 ViT 替换了 hMLP 图像编码器。

混合精度 MoE，采用 Four-Over-Six NVFP4。在 Inkling 2 Small 的 48 层中，前 40 层的专家使用 NVFP4，后 8 层的专家使用 MXFP8。NVFP4 激活使用逐 token 全局缩放加双候选块缩放（Four Over Six）：对于每个 16 元素块，量化器尝试将块最大值缩放到 6 和 4，并保留重建误差（MAE）更低的那一个。

带 RNN 头的 DSpark 投机器。该检查点还附带一个 DSpark 草稿模型，用来替代 Inkling 的 8 个链式 MTP 头。该投机器有 5 层，每步草拟 7 个 token。其头是 RNN 变体，DeepSeek 的 DSpark 论文中描述的那种。

vLLM 集成与优化

图 2. 一个解码器层中的内核，分别用于解码和大规模预填充。

内核融合与 PDL。vLLM 积极地将子层之间的集合通信和内存受限算子融合进单个内核。有了注意力残差，每个边界都需要一次 all-reduce、一个短卷积、一次残差更新、注意力残差混合以及一个 RMSNorm：在同一份隐藏状态上的五个内存受限步骤。融合后的内核，allreduce_conv_mix（图 2 中的金色部分），通过 NVLink 多播执行 all-reduce，并将其后的所有内容保留在寄存器中。GEMM、注意力、路由和激活内核以程序化依赖启动（PDL）方式启动，因此每个内核的前导部分会与上一个内核的尾部重叠，这在小批量大小下很重要，因为此时一个解码步骤是一长串短内核。

带融合激活量化的 MoE。vLLM 在产生专家激活的 kernel 内部对其进行量化（NVFP4 或 MXFP8，与每一层匹配），因此没有单独的量化流程会触及隐藏状态：路由 kernel 在 gate/up 投影之前对 token 进行量化，而带 softcap 的 SwiGLU 在 down 投影之前对其输出进行量化。专家 GEMM 运行在 TensorRT-LLM 的 batched-GEMM kernel 上，随 FlashInfer 一同发布。

用于 prefill 的序列并行。在普通的张量并行下，每块 GPU 在每次 all-reduce 之后都要对所有 token 运行短卷积、注意力残差混合和 RMSNorm：同样的工作在每个 rank 上重复一遍。这在 decode 阶段开销不大，但在 prefill 阶段代价高昂。vLLM 用序列并行消除了这种冗余（图 2 中的紫色和金色部分）。每块 GPU 先做 reduce-scatter，然后在一个融合conv_mixkernel 中只对自己负责的那部分 token 运行短卷积、残差更新、注意力残差混合和 RMSNorm，再对结果做 all-gather 供下一个 GEMM 使用。这在 TP4 下将 8K token 的 prefill 步骤缩短了 22%，在 TP8 下缩短了 26%，并为每块 GPU 释放出 1.3–1.9 GiB 用于 KV cache。

为 decode 优化的 Gluon 相对注意力 kernel。Inkling 的 FlashAttention-4 decode 路径对 Inkling 2 Small 来说很慢：6:1 的 GQA 比例会静默地禁用 GQA packing。为解决这个问题，我们为 decode 和 verify 编写了一个 warp 专用的 Gluon kernel，把 6 个头打包进一个 64 行的 tile，并且只读取一次 KV：一个 TMA warp 流式读取 KV，一个 tcgen05 warp 执行 MMA，四个 softmax warp 施加相对偏置。在 100K 上下文下，batch-1 的 decode 步骤从 15.1 ms 降至 4.8 ms。Prefill 仍沿用 Inkling 的 sheared-bias FlashAttention-4 路径。

性能

我们在 TP8（两个 4-GPU 节点）下，使用 DSpark（概率性起草）和前缀缓存，对 Inkling 2 Small 在一个智能体工作负载上进行了基准测试。每个会话保持长上下文，并且在每一轮都追加先前的回答和约 2K token 的工具输出，因此每轮只有约 3K token 是新的；随后每轮在开启推理、温度 1.0 下生成 1,024 个 token。表格给出了在每个用户获得 100 tokens/s 的并发度下，每块 GPU 的输出吞吐量。

在 TP4 配置下，单用户解码速度约为 630 tok/s，接受长度为 3.5。

准确率评估

vLLM 保持了参考实现的数值特性：每一步使用相同的数据类型，FP32 注意力输出和路由器，以及相同的 NVFP4/MXFP8 激活量化，仅归约顺序和 all-reduce 的 BF16 部分不同。端到端，我们在 NIAH 上验证了最高 1M token 的准确率，以及 MMMU-Pro 和 HLE 的准确率，使用inkling-verify，并启用了 DSpark；得分与我们在未使用投机解码时的运行结果一致。

致谢

我们感谢 Thinking Machines 团队在将 Inkling 2 Small 集成并优化到 vLLM 中的密切合作。这项工作由 Aurick Qiao（Thinking Machines）和 Woosuk Kwon（Inferact）主导。