vLLM 首日支持 TML Inkling：1T 多模态模型的长上下文推理被推到台前

导语

vLLM 在官方博客中宣布，已在 TML Inkling 发布首日提供支持。这一消息的重点不只是适配了一个新模型，而是围绕一个 1T 参数、多模态、长上下文模型，完成了从架构兼容到推理性能优化的一整套工程落地。

TML Inkling 由 Thinking Machines Lab 训练，支持文本、图像和音频输入，并输出文本。模型原生上下文长度最高可达 1M tokens。vLLM 表示，其同时支持 thinkingmachines/Inkling-NVFP4 和 BF16 版本，并在 NVIDIA Blackwell 与 Hopper GPU 上运行；更广泛的硬件支持仍在推进中。

核心要点

• 多模态与长上下文并存：Inkling 可接收文本、图像、音频输入，采用 decoder-only Transformer 主干，并通过大量滑动窗口注意力来支撑 1M 级上下文。
• 架构并不“常规”：模型没有使用 RoPE，而是采用相对注意力；每层还大量使用窗口大小为 4 的 short convolution，用于 key、value、attention output 和 MoE output。
• MoE 设计有新变化：每层包含 256 个路由专家、top-6 激活，以及 2 个共享专家。共享专家参与路由分数计算，但不进入 top-6 候选，这被称为 expert sink。
• MTP 推测解码是性能关键：Inkling 带有 8 个 MTP heads，理论上每次前向最多生成 9 个 token。vLLM 在拒绝采样后会重新运行 MTP heads，以处理 draft token 被拒导致的 KV cache 失效问题。
• 工程优化围绕缓存与通信展开：vLLM 将 short convolution cache 作为虚拟滑动窗口注意力层的 KV cache 管理，使 prefix caching 能与其协同；同时引入 sconv-aware TP sharding，减少跨 GPU 重复计算和缓存复制。

性能与验证

根据 vLLM 的测试，在 4 块 GB200 GPU 上，使用来自 SPEED-Bench 的 8K 输入提示、每个请求生成 1K 输出时，开启 MTP8 的吞吐可达最高 380 tokens/s/user，平均接受长度为 4.5；未开启 MTP 时为 140 tokens/s/user。

vLLM 还提到，适配工作经过了多类基准验证，包括音频 MMAU、视觉 MMMU-Pro、工具调用 BFCL、推理 HLE，以及长上下文 NIAH。长上下文方面，vLLM 表示在 221K tokens 内与参考实现完全一致，在 513K 内保持约 1 个百分点以内差距；更极端长度下，NIAH 结果存在更高的运行间波动。

意义与影响

这次集成反映出大模型推理框架的竞争重点正在变化：仅支持模型加载已不够，长上下文、多模态、MoE、量化、推测解码和分布式并行需要被同时纳入优化目标。

对开发者而言，vLLM 的价值在于把复杂模型架构背后的缓存管理、并行切分和通信融合尽量封装起来，让超大模型服务更接近可部署状态。对基础模型团队而言，Day-0 支持也意味着模型发布和推理生态之间的协同正在变得更紧密。

来源：vLLM Blog