Dynamo TRT-LLM and AgentX

导言

希望在华为 A3/A5 上实现 InferenceX 中 DeepSeek-R1 在 B200、H100 上的效果，首先需要明确“效果”究竟指什么。它不是一个孤立的峰值吞吐数字，而是由推理引擎、集群调度、并发负载、单用户速度和服务成本共同构成的性能曲线。

本文先解释 Dynamo TRT-LLM 的分层，再辨析 Conc、Interactivity、TTFT 和 Throughput/Chip，最后说明 AgentX 为什么把测试单位从独立请求升级成持续演化的 Agent 会话树。

三个边界

1. 截图中的字段是 Conc（Concurrency，并发数），不是 Conv。
2. 结果表中的“列”不等于图表中的“横轴”。典型 Pareto 图以 Interactivity 为横轴，以 Throughput/Chip 或成本效率为纵轴，Conc 决定曲线上的采样点。
3. TensorRT-LLM 属于 NVIDIA/CUDA 技术栈。在昇腾平台上应对标其系统能力和性能曲线，而不是把 TensorRT-LLM 原样移植过去。

推理栈分工

可以把大模型推理服务理解成一家餐厅：TensorRT-LLM 是厨房，Dynamo 是调度整个餐厅的系统。

• TensorRT-LLM 负责真正执行模型计算，包括模型并行、量化、Batch、KV Cache 和推测解码等推理能力。
• Dynamo 位于推理引擎之上，负责服务接入、请求路由、负载均衡、Prefill/Decode 分离、KV 感知调度和多节点编排。
• Dynamo TRT-LLM 表示 TensorRT-LLM 引擎运行在 Dynamo 的分布式推理框架中，而不是二者合并成一个新的算子库。

用户请求
   ↓
Dynamo：接入、路由、P/D 分离、KV 感知调度
   ↓
TensorRT-LLM：Batch、模型并行、量化、推测解码、GPU Kernel
   ↓
NVIDIA GPU

如果 A3/A5 指昇腾平台，可以先建立如下概念映射：

NVIDIA 侧	昇腾侧对应理解
Dynamo 的调度与 P/D 分离	MindIE Motor/Service 的调度与 P/D 分离
TensorRT-LLM 推理引擎	MindIE LLM 与 CANN/算子实现
CUDA 侧通信和 KV 数据路径	CANN、HCCL、LLMDataDist 等数据路径
B200/H100	A3/A5 对应的昇腾硬件

这里的映射强调职责相似，不表示实现接口、算子能力或性能必然等价。

性能坐标

Conc 是负载旋钮

Conc 表示测试施加的并发负载。在固定长度测试里，它可以近似理解为系统中同时存在多少个尚未完成的请求。

• 并发较小：单请求分到的资源更多，用户侧速度通常较快，但芯片可能没有吃满。
• 并发较大：系统更容易组成大 Batch，提高总吞吐；与此同时，请求排队和资源竞争可能增加，单用户速度与尾延迟可能恶化。

因此，Conc 是实验者主动设置的控制变量。扫描不同 Conc，才能得到完整的吞吐—时延曲线。

Interactivity 是用户速度

Interactivity 表示模型开始输出后，单个用户每秒收到多少个 Token，单位为 tok/s/user。它近似是每输出 Token 时间 TPOT 的倒数：

[
\text{Interactivity} \approx \frac{1}{\text{TPOT}}
]

若 TPOT 为 20 ms/token，则：

[
\text{Interactivity} = \frac{1000}{20} = 50\ \text{tok/s/user}
]

Interactivity 不等于完整等待时间

Interactivity 主要描述开始生成以后的流式速度。用户提交请求后等待首个 Token 的时间由 TTFT 描述。两者必须同时观察。

为什么横轴常用 Interactivity

推理服务需要同时满足两个相互制约的目标：

1. 用户侧要快：Interactivity 越高，流式输出越顺畅。
2. 系统侧要省：Throughput/Chip 越高，每张卡服务的总工作量越大。

典型 Pareto 图因此采用：

横轴：Interactivity，单用户输出速度
纵轴：Throughput/Chip 或 Tokens/$，系统效率
每个点：某个 Conc 下得到的测试结果

理想点位于右上角。Conc 在这里不是第二个横轴，而是产生采样点的负载配置。相同 Conc 下的两个系统可能提供完全不同的用户体验，因此更合理的比较方式是：先固定 Interactivity 和 TTFT 的服务目标，再比较吞吐与成本。

下图是原始 InferenceX 结果表的字段。它只能说明每条结果同时记录了硬件、精度、并行和性能信息，不能单凭表头认定所有字段都是绘图坐标。

{ width=100% }

会话中提供的 InferenceX 页面截图：Conc、Interactivity 与 Throughput/Chip 是同一结果的不同字段。

8k/1k 的特殊性

8k/1k 表示大约 8k 输入 Token 和 1k 输出 Token。这是一个 Prefill 较重、Decode 相对较短的固定长度场景。

它可能出现“开始输出后很快，但第一个 Token 等得很久”的情况。因此，复现这一场景至少要同时核对：

• P99 TTFT：8k Prefill 的计算和排队延迟；
• Interactivity/TPOT：Decode 阶段的单用户速度；
• Throughput/Chip：每张芯片的整体产能；
• Conc：产生该性能点时的负载；
• Token 口径：区分输入、输出与总 Token 吞吐。

AgentX 任务

传统 8k/1k 测试把一次独立请求作为基本单位。AgentX 则模拟 Coding Agent 读取仓库、调用工具、积累上下文、再次请求模型并展开子 Agent 的请求形状。

但 AgentX 不让模型真的修复一个 Bug，也不评价代码是否正确。公开回放会删除原始 Prompt、源代码、工具参数和工具结果，再用确定性合成 Token 替代内容，只保留：

• 每次请求的输入、输出长度；
• 多轮之间共享的长前缀；
• 工具调用造成的等待时间；
• 主 Agent 与子 Agent 的依赖关系；
• 并行分支、汇合点和辅助请求。

因此，AgentX 测的是推理基础设施能否服务真实形状的 Agent 流量，不是模型或 Agent 的任务质量。

下面的图把两种负载单位放在一起。固定长度测试从并发请求得到一个性能点；AgentX 则回放包含工具等待、上下文增长和子 Agent 分支的有向无环图。

{ width=96% }

根据会话内容整理的自绘示意图：8k/1k 以独立请求为单位，AgentX 以持续演化的 Agent 会话树为单位。

AgentX 的 Conc

AgentX 采用闭环回放：只有依赖的上一轮完成后，客户端才发出下一条可执行请求。更快的推理系统会让会话更快推进，也会更早制造后续请求。

所以 AgentX 中的 Conc = 50 表示 50 个活跃 Agent 客户端或会话树，不是最多 50 个 HTTP 请求。某个会话展开多个子 Agent 时，瞬时在途请求数可以超过 50；分支结束后又会下降。

AgentX 数据形状

AgentX v1.0 使用经过脱敏的 Coding Agent 会话形状。会话中已经关注的几个数据点包括：

• 393 个 Claude Code 会话；
• 单请求输入长度中位数约 142k Token；
• 单请求输出长度中位数约 444 Token；
• 44% 的会话包含子 Agent；
• 同时提供最高 1M 上下文版本和 256k 截断版本。

这些数字说明，AgentX 与固定 8k/1k 的主要区别不只是“输入更长”，而是请求长度、到达时间、前缀复用和并行分支都随会话进展动态变化。

维度	固定 8k/1k	AgentX
基本单位	单个独立请求	完整 Agent 会话树
输入与输出	约 8k/1k，固定	每轮变化并持续增长
请求关系	相互独立	有先后依赖和并行分支
Prefix Cache	不是主要负载特征	核心性能因素
工具等待	无	保留不均匀的间隔
并发含义	活跃请求	活跃 Agent 客户端
主要结果	固定请求性能	会话容量、响应性、缓存和成本

A3/A5 对标

如果目标只是复现 8k/1k 的曲线，主要工作集中在：

• Prefill/Decode 的算力与资源配比；
• P/D 分离及 KV 传输；
• Batch、TP、EP 和 MTP 配置；
• TTFT、Interactivity 和单卡吞吐之间的平衡。

如果目标进一步扩展到 AgentX，就会变成完整的推理系统工程：

1. 长生命周期 KV Cache：上百 K 上下文持续存在，不能每轮从头 Prefill。
2. Prefix 感知路由：后续请求应尽量路由到已有相应 KV Cache 的实例。
3. 分层缓存：大量长会话无法全部常驻 NPU HBM，需要在 HBM、Host 内存和更低层级之间管理。
4. 调度公平性：一个会话展开多个子 Agent 时，不能长期挤占其他会话。
5. 长上下文算子：142k、256k 乃至 1M 上下文与 8k Prefill 的瓶颈不同。
6. 前端与路由器：Prefix 匹配、流式返回和会话状态管理也可能成为系统瓶颈。

目标定义

“实现 B200/H100 的效果”应被改写成可验证目标：在相同模型、精度、输入输出分布和服务 SLO 下，复现可比较的 Interactivity—Throughput/Chip Pareto 曲线。如果对标 AgentX，还必须固定数据集版本、上下文上限和并发会话扫描范围。

总结

理解 InferenceX 可以抓住三层关系：

1. Dynamo TRT-LLM 是系统栈。 Dynamo 负责分布式调度，TensorRT-LLM 负责 NVIDIA GPU 上的推理执行。
2. Conc 是负载，Interactivity 是用户体验，Throughput/Chip 是系统效率。 Conc 产生采样点，Interactivity—Throughput 曲线用于在相同服务质量下比较方案。
3. AgentX 改变了测试单位。 它不再测试独立的固定长度请求，而是回放多轮、长上下文、工具等待和子 Agent 分支组成的会话树。

因此，8k/1k 更像测试“推理发动机”，AgentX 则开始测试“整套 Coding Agent 交通系统”。对 A3/A5 的真正挑战，也会从单个算子或引擎性能扩展到 KV Cache、路由、调度、存储与网络的协同设计。

参考资料

• InferenceX：DeepSeek-R1 B200 与 H100 的 8k/1k 对比
• Dynamo TensorRT-LLM 官方说明
• InferenceX 指标说明
• AgentX 方法与数据集
• Agentic Benchmark 方法说明
• MindIE Prefill-Decode 分离
• MindIE LLM 架构