AgentX 行业影响 · 推理引擎

TensorRT-LLM

TensorRT-LLM 的 AgentX 工作从前端开始——那里有一项只因负载是多轮才存在的开销——随后沿着请求路径深入到传输粒度、内核选择与调度器生命周期。

每轮 tokenization 平均耗时: 185.1 ms → 11.3 ms
并发 5 时请求关键路径 KV 的 p99: 26.74 s → 125 ms
context graph 带来的单用户输出吞吐量提升: +12.58%

边界感知的增量 tokenization

对话每一轮都会把完整历史再加一点新内容重新发送一遍，而朴素实现会把这些内容整体重新 tokenize。按千字节计算 tokenization 很便宜，但当同样的 100,000 个 token 每轮都被重新处理一次时，代价就变得难以承受。

看上去显而易见的修法——只 tokenize 新增的后缀——却错在一个容易被忽视的地方：BPE 并非与位置无关。token 可能跨接缝合并，因此在边界处切分文本再把两段 token 序列拼接，可能得到与整体 tokenize 不同的序列，从而悄悄偏离 prefix cache 所依据的序列。

TensorRT-LLM 实现了边界感知的增量 tokenization：先找到渲染文本的公共前缀，回退一个完整 token 以便重新计算任何跨接缝的合并，再从该处只对变化的后缀做 tokenize。在 Qwen3.5 的 AgentX trace 上，它在全部 1,087 次转换中都与完整 tokenize 结果一致——正确性是被验证的，而不是被假设的——平均处理时间从 185.1 ms 降到 11.3 ms。固定的 8k/1k 请求没有上一轮渲染结果可复用，因此完全体现不出这一点。

相关地，chat template 渲染被移入输入处理线程池，长模板不再让主请求循环排在它后面串行等待。

上游 PR

Disaggregated KV 搬运与 descriptor 粒度

MiniMax-M3 的工作聚焦于 disaggregated KV 搬运，那里的问题出在粒度上。当 prefill 与 decode 对 head 布局理解不一致时，一个逻辑请求的 KV 就不再是少数几块大的连续区域，而变成数千个带 stride 的小片段，每一片都会生成自己的传输 descriptor。搬运的字节数没变，爆炸的是每个 descriptor 的开销，而且恰恰在最需要关注的长 prompt 上最严重。

修正后的多池映射与分块 NIXL bounce 路径把这些碎片通过一块有界可复用的 arena 合并起来，以一次额外的 staging 拷贝换取数量级更少的 descriptor。AgentX 诊断显示：并发 5 时请求关键路径 KV 的 p99 从 26.74 秒降到 125 ms，并发 40 时从 10.15 秒降到 288 ms。

非阻塞的 context 传输轮询保护同一条路径：即使调度停顿，也能及时回收已完成的传输，打破"已完成的 KV block 仍被钉住、导致无法接纳新请求"的反馈回路。另有一个 draft cache 传输提案已关闭且未合入，不应算作 TensorRT-LLM 已交付的行为。

上游 PR

面向不规则长上下文的执行路径

TensorRT-LLM 还把不规则的长上下文工作迁移到更高效的执行路径上。面向 MiniMax-M3 的 context graph producer 捕获稳定的稀疏 producer，同时让依赖请求的注意力保持 eager 执行，在其 AgentX 测试中单用户输出吞吐量提升 12.58%。另有一个仍为 open 的原生 KV 事件生成改动，减少了 KV 感知路由路径上的内存分配与格式转换开销。

上游 PR

内核选择与调度器生命周期

AgentX 还暴露出只有在规模和持续时间上去之后才会出现的内核选择与调度器生命周期问题。其中两个关乎"选中了哪个内核"。MiniMax-M3 为 MXFP8 autotuning 增加了 CuTeDSL 候选，扩大候选集后，在低并发聚合点上每 GPU 输出吞吐量提升约 7% 到 10%。反方向的例子是：TensorRT-LLM 在错误的 split-K MoE tactic 导致七次 AgentX 运行中有五次崩溃后禁用了它们，之后七次对照运行无一崩溃。一个又快又错的 tactic 比单纯慢的更糟，而 autotuner 只要不把它从候选池中剔除，就会兴高采烈地选中它。

另外两个属于生命周期缺陷，这类问题是长时间运行（而非大规模运行）的典型失败模式。序列槽位余量与一致的按槽位索引的 buffer 尺寸，处理的是"一个请求即将完成、另一个刚被接纳、两者同时需要槽位"的短暂重叠——持续的到达与离开会不断撞上这个窗口，而固定批次永远撞不到。后续的 attention 数据并行 dummy request 修复，让九个 Qwen3.5 disaggregated 单元保持存活，而此前多数单元几分钟内就会失败：这正是"能跑完基准测试的配置"与"能撑过一次会话的配置"之间的差别。

上游 PR

面向超长 prompt 的流水线 KV 传输

两个仍为 open 的传输改动针对超长的 disaggregated prompt，它们放在一起还说明了一个修复如何制造出下一个瓶颈。在默认安排下，decode worker 必须等整段 prompt 完成 prefill 并传输完毕才能开始，于是两个昂贵阶段前后串行，尽管第一个阶段本可以增量产出。流水线 KV 传输会在每个 prefill 分块完成时就开始发送，让传输与 prefill 计算重叠，只有最后一个分块留在关键路径上。

该改动使分块处理变得频繁，从而暴露出原本只做一次的工作。其后续改动改为只取当前分块所属的 block ID，而不是每次都取整段 prompt 的 block 列表。对于切成 1,024 token 分块的 128,000 token prompt，这就是"构建一次 4,096 条目的列表"与"为每个层组重建 128 次"的差别——一项随 prompt 总长增长的按分块开销，正好会吃掉流水线刚刚换来的收益。