AgentX 行业影响
面向智能体负载的优化
AgentX 上线头几个月最有价值的产出并不是开源数据集，而是 AgentX 合作伙伴以 AgentX 为北极星，为真实智能体负载提交的 50 多个上游 PR。
- 上游 PR
- 50+
- 上游项目
- 8
- 涉及的栈层级
- 5
- 作为北极星的 trace
- AgentX
AgentX 回放的是真实智能体流量，因此它衡量的远不止 prefill 与 decode 内核本身，而是端到端的完整链路：KV cache 生命周期、混合注意力（hybrid attention）cache 正确性、CPU KV offload、传输进度、路由亲和性、增量 tokenization、请求序列化以及调度器记账。这些开销每一项都是生产环境智能体部署已经在付的成本，而单轮 8k/1k 场景一项也测不出来。
SemiAnalysis 与 AMD 软件团队多年协作、推动其软件开发方式现代化，下面的许多工作正是这一协作的成果，它们让 AMD 开源栈在智能体负载上更接近一流水平。
按项目查看优化
下面每个页面汇总一个项目中由 AgentX 驱动的工作，并按其所处的栈层级归类。文中标注为 open 的改动只是已提出、尚未合入，不代表上游当前行为。
推理引擎
vLLM
混合注意力 prefix 保留、面向 hybrid 模型的 CPU KV offload，以及收窄后的 store 与 load 路径。
查看优化详情 →推理引擎
SGLang
Sliding-window 分配、HiCache 混合 offload、以 runtime scalar 传入上下文长度，以及 cache 感知的 DP 路由。
查看优化详情 →推理引擎
TensorRT-LLM
边界感知的增量 tokenization、disaggregated KV 的 descriptor 合并，以及调度器生命周期修复。
查看优化详情 →推理引擎
AMD ATOM
稀疏 checkpoint 保留、recurrent 状态 checkpoint、CPU offload 归属管理，以及长 prefill 并行。
查看优化详情 →内核
ROCm AITER
Context-parallel 进程组、面向大 cache 池的 64 位寻址，以及常驻式 MLA decode 内核。
查看优化详情 →Router 与编排
NVIDIA Dynamo
批量化 KV 匹配、以 request lease 表示归属、更廉价的 router 状态，以及更精简的请求平面。
查看优化详情 →KV cache 层
LMCache
分块的外部 cache 加载、hybrid group 存储优化、AMD Instinct 支持，以及 DCP 感知的 offload。
查看优化详情 →传输引擎
Mooncake
通过 HIP dmabuf 在 ROCm 上实现 GPU-direct RDMA，并提供已发布的 ROCm wheel 与发版流程。
查看优化详情 →分布式推理生态简介
智能体推理是系统级问题，而不是单纯的芯片或内核问题。当分布式系统需要处理数十万个智能体请求时，请求调度与 KV cache 管理就不再只是记账工作，而会实实在在地影响性能。例如 subagent 会产生突发式的 KV cache 访问模式，若不加优化，就会把主 agent 的 cache 挤掉。
在栈的最上层，router（有时也称 frontend）把请求分发给各个 worker。当服务端启用数据并行注意力（data-parallel attention）时，每个 DP rank 都有独立的 KV cache，因此请求会按 consistent hashing 等策略路由：同一会话或同一 subagent 的请求按其唯一 ID 落到同一个 rank，而不是把所有 cache 都搅乱。
大多数路由策略在不同实现之间差别不大。有些 router 是独立组件，例如 vLLM router 和 llm-d router；有些则集成在引擎内部，例如 SGLang model gateway 和 ATOM Mesh。
完成路由后，请求进入 vLLM、SGLang 等推理引擎的调度器。引擎负责执行推理并通过 API 返回结果，同时提供接口把引擎内部的 KV cache 接到外部 KV cache 管理器上——这正是该生态可插拔的原因：一个 cache 管理器可以对接多种引擎。
当前 AgentX 结果所用的简单部署方式，是让 Mooncake 与 vLLM 运行在同一节点上。每个 vLLM worker 内嵌一个 Mooncake Store 客户端，并贡献一部分主机 DRAM 给外部 KV cache 池。vLLM 通过 MooncakeStoreConnector 接口访问这个池：把可复用的 KV block 载入 GPU 显存，并把新计算出的 block 写回主机内存。Mooncake Store 负责放置与淘汰策略，Mooncake Transfer Engine 负责在 GPU 与 CPU 内存之间实际搬运数据。
不同的 KV cache 管理器会使用不同的传输引擎，在内存层级之间或机器之间（例如 prefill 与 decode worker 之间）搬运字节。一套部署可以用 Mooncake Store 把可复用的 KV block offload 到主机 DRAM，同时用 NIXL 把请求专属的 KV 直接从 prefill GPU 传给 decode GPU；在支持的环境下 NIXL 会走 UCX 与 GPUDirect RDMA。多条 KV 管理与传输路径可以在同一个推理引擎中共存。
整个生态由许多独立组件构成：推理引擎、router、KV cache 管理器、数据传输库以及集群控制器。NVIDIA Dynamo、llm-d、AMD Infera 等平台把其中若干组合打包成完整发行版，提供彼此兼容的容器镜像、connector、部署清单和编排逻辑。最终交付的通常是一组协同工作的容器，而不是单一的巨型服务。
其他优化：day-zero 支持与正确性
各项目页面汇总的工作主要针对长上下文开销：prefix 必须活下来、hybrid cache 必须保持正确、传输必须跟得上。这一节的改动性质不同，它们属于 day-zero 支持与正确性缺陷——它们让一个请求彻底失败的程度，和百万 token 会话遇到的问题一样严重。
MiniMax-M3 检验了这些 ROCm 工作能否累积成 day-zero 就绪能力，Advancing AI 一文直接给出了对比：AMD 首个公开的 disaggregated 配方 MI355X FP4 在 1 月才登陆 InferenceX，比 NVIDIA 晚了数月；而 M3 FP4 disaggregation 在 day zero 就已就位。相比 DeepSeek-R1 时期需要数月才追平，这是明显进步。day-zero 路径上有三个 vLLM 修复，且都属于正确性问题而非性能问题。
首先被卡住的是 disaggregation。NixlConnector 的握手逻辑假设 SPLIT 区域的 block_len 会随 prefill 与 decode 的 TP 比例缩放，但 block_len 实际取决于每个 rank 的 KV head 数量。M3 只有 4 个 KV head，因此 TP4 prefill 搭配 TP8 decode 时，两侧都被 GQA 限制为每 rank 一个 head，两个长度相等，而断言却要求相差两倍。握手因此被拒绝，KV 完全没有传输，decode 只能从零重新生成，gsm8k 得分为 0。改为按真实 head 比例校验后问题解决。
另外两个问题源于平台差异。M3 的稀疏注意力后端在所有 E4M3 配置下都把按字节存储的 FP8 cache 读作 float8_e4m3fn，但 gfx942 的平台 dtype 是 e4m3fnuz；两种编码并不相同，因此 K 和 V 在进入内核前就已被改变，而且 prefill 与 decode 的 wrapper 也漏掉了 FP8 检查中的 FNUZ 类型。改为按平台 dtype 解释 cache 视图后，两处一并修复。此外，M3 的 NVIDIA 与 AMD 模型实现位于不同文件，只有 NVIDIA 版实现了 EAGLE3 接口，导致 ROCm 上的 speculative decoding 在引擎初始化时就以 model-does-not-support 报错退出。把 AMD 版补齐到同等能力后恢复正常，MI355X 的 gsm8k 与未启用 EAGLE3 的 MI355X 运行以及 B200 结果一致。
TensorRT-LLM 页面覆盖了 M3 中与长上下文直接相关的工作：disaggregated KV 传输中的 descriptor 爆炸、context graph 捕获、稀疏 block stride、autotuner 候选集，以及必须从候选池中移除的错误 split-K MoE tactic。
AgentX 测试矩阵激活了什么
本地 AgentX 矩阵同时包含会话感知或 KV 感知路由、长度多变的长对话历史、MTP、hybrid attention、聚合式与 disaggregated 部署，以及跨越 HBM 容量悬崖的并发扫描；既有全部驻留 GPU 的对比，也有通过 vLLM SimpleCPU、Mooncake、LMCache 和 SGLang HiCache 进行的 CPU DRAM offload。正是这种组合激活了上面这些上游工作。
旧的固定序列矩阵通常只创建一个 prompt、执行一次 prefill、解码固定长度的续写，然后丢弃请求。因此它无法衡量 cache 跨轮次的存活、重复 tokenization、会话亲和性、cache 事件流量、offload 抖动、调度器停顿期间的传输进度，以及长生命周期的归属记账。
允许的优化策略把 CPU KV offload 视为可选项。厂商可以使用 vLLM connector、LMCache、SGLang HiCache、Mooncake、Dynamo KVBM 或其他 CPU DRAM connector；如果关闭 offload 能得到更好的延迟与吞吐量组合，也可以关闭。NVMe offload 暂缓。CPU DRAM 必须按所用 GPU 比例缩放，其中非标准化 DRAM 系统上限为 3 TB；标准化 DRAM 系统没有硬性上限，但同样遵守比例规则。本地生成器目前对所有 runner 一律套用 3 TB 上限，因此尚未实现标准化 DRAM 的例外条款。
新增的优化面并不只是"更长的注意力"，而是不断增长的会话状态在保存、搬运、路由、重建和反复处理过程中的全部开销。AgentX 把这些成本放大到足以推动 vLLM、SGLang、TensorRT-LLM、ATOM、AITER、Dynamo 和 LMCache 做出通用的上游改动。对 NIXL 与 Mooncake 的直接检索没有发现此处之外带 AgentX 标记的运行时 PR，因此它们的影响仍通过上述引擎 connector 改动体现。