AgentX 行业影响 · 传输引擎
Mooncake
Mooncake 承载着 Moonshot 的 Kimi 生产流量以及多家实验室的生产流量，同时也是 disaggregated vLLM 与 SGLang 配置底层的传输引擎。直到最近，它在 AMD 上的支持既缺少 RDMA 注册，也缺少可直接安装的软件包。
- ROCm 上的 GPU-direct RDMA 路径
- HIP dmabuf
- 同一个架构无关 wheel 覆盖的目标
- gfx942 + gfx950
- 按 tag 触发的发布矩阵
- Python 3.10–3.13
ROCm 上的 GPU-direct RDMA 注册
在 NVIDIA 上，为 RDMA 注册 GPU 显存要么使用 nvidia-peermem 内核模块，要么导出 dmabuf 文件描述符。AMD 没有 nvidia-peermem 的对应物，因此 GPU-direct RDMA 完全没有可走的路径，部署只能退回到通过主机 DRAM 中转 KV。
一个 HIP dmabuf 注册分支补上了与现有 CUDA dmabuf 路径对应的实现：改用 ROCm 导出，而不是调用 CUDA 的 handle 接口，并且会先解析出真实的分配基址，因为带缓存的分配器会把张量打包在一块更大分配内部的某个偏移处。主机内存仍然直接注册。
上游 PR
装不上的支持不算支持
Mooncake 发布了 CUDA 与 MUSA 的 wheel，却没有 ROCm 包，因此 AMD 用户只能在每个镜像里从源码构建引擎。ROCm wheel、CI 与发版流程把 mooncake-transfer-engine-rocm 一并发布到 PyPI。这条工作线来自 AMD 工程师 Andy Luo，他在用 AgentX 自测（dogfooding）智能体负载时注意到：在 ROCm 上从源码构建 Mooncake 并不是一流的使用体验。
该传输引擎没有设备端内核，也不依赖 torch，因此一个架构无关的 wheel 即可覆盖 gfx942 与 gfx950；ROCm 运行时在加载时绑定而非随包分发，这意味着同一个 wheel 在上游 vLLM ROCm 镜像与 SGLang ROCm 镜像中都可直接使用。验证覆盖了完整的交叉组合：MI300X 与 MI355X，各自在 vllm/vllm-openai-rocm 与 lmsysorg/sglang 下运行 master 二进制及带数据校验的 HIP buffer 传输测试。该 PR 还增加了按 tag 触发、覆盖 Python 3.10 到 3.13 的发布流程。
一个仍为 open 的后续改动增加了自托管的双节点 MI350X 外部 prefill 与 decode 环境，让 ROCm 的 disaggregated 路径在真实硬件上被实际执行，而不只是通过编译。综合这些工作，AMD 上的 AgentX 运行现在可以直接从已发布产物把传输引擎与 KV cache 层装进标准上游镜像，并在 GPU 显存与网络之间直接搬运 KV。
其他项目
推理引擎
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。
查看优化详情 →