华为昇腾通信资料最容易制造一种错觉：DMA、HCCS、HCCL、SHMEM、Fabric Memory 和 AIV 直驱仿佛是一摞可以从上到下整齐堆叠的软件层。实际并非如此。这些词分别回答“谁组织通信、谁建立地址、谁提交任务、谁搬数据、数据走哪条物理链路、对端是否参与”中的不同问题。有些是库，有些是协议或硬件，有些只是数据路径属性；把它们画在同一层，关系一定会错。

本文把历史纵轴和技术横轴合并：先建立一张总地图，再逐个概念给出小白版与专业版解释，最后核对公开仓库的首次可见提交、立项目的、硬件范围、迁移和待废弃状态。研究截止日为 2026 年 8 月 26 日。

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

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

本文对齐 InferenceX 官网、公开 API、官方 InferenceX / InferenceX-app 仓库、AIPerf，以及 Ascend 与 vLLM-Ascend 一手资料，回答“哪些 NVIDIA 基线真实存在、AgentX 能否迁移到 A3/A5、需要多少机器、数据怎样采集和提交”。结论是：AgentX 客户端可以直接压测 Ascend 的 OpenAI-compatible 服务，但模型可运行不等于能够同配置复现；DeepSeek-R1 当前没有原生 vLLM 的 H100/H200/B200 对照数据，A3 也不支持与 NVIDIA FP4 等价的原生浮点格式。应先建立严格对照的离线长表，再推进官方 runner、PR 与自动入库。

我看到 Mooncake 为 Ascend 提供了三个编译开关：USE_ASCEND、USE_ASCEND_DIRECT 和 USE_UBSHMEM。最直接的问题是：它们是不是三套并列的通信 engine？特别是后两个名字里已经有 Direct 和 SHMEM，是否意味着数据传输已经由 AIV 直驱？

沿着合入 PR 和源码调用链看下去，答案逐渐清楚：这不是三套同层方案，而是 Mooncake 先后解决“能传”“通用地传”和“把远端内存映射后再传”三个问题留下的三条路径。更重要的是，按当前可见源码，三者都不能直接称为 AIV 直驱。

理解“AIV 直驱缩短了通信控制路径”之后，下一步不是立即抄一个 AllGather，而是先闭合一条最小链路：Host 建立资源并分配对称内存，启动一个 AIV Kernel；Kernel 把数据写到对端并发布 signal；接收端等待 signal，最后 Host 确认完成并按依赖顺序销毁资源。

本文基于 cann/shmem@382afa08efa801d7bca6c2645fd17e155111efcc 和 CANN 9.0.X / 9.0.0-beta.2 官方文档。代码是绑定该 revision 的教学归一化代码，不是承诺可在任意 CANN 版本直接编译的通用样例。

TileXR 的 README 提到：若 UDMA 不可用，通信会平稳降级为 IPC/MTE。这个说法容易让人误以为 UDMA、IPC 和 MTE 是三个可以直接互换的传输引擎，或者一次 UDMA 调用会在失败后自动改写成 MTE 调用。

更准确的理解是：IPC/MTE 是一条组合路径。IPC 负责让本进程看见其他 Rank 的 NPU 内存，MTE 负责真正搬运数据；UDMA 则是另一套带队列、远端内存注册和完成通知的数据搬运后端。TileXR 所谓“自动降级”主要发生在初始化与能力选择阶段，而不是单次传输内部。

TileXR 和 cann/shmem 都涉及昇腾设备间通信，但它们封装的不是同一层对象。TileXR 面向通信器、共享窗口和融合算子；cann/shmem 面向 PE、对称堆与单边通信原语。把二者简单画成一条“TileXR 调 SHMEM”的直线，会掩盖 TileXR 三个实际 MC2 算子的不同通信路径，也会忽略其固定 SHMEM fork 与 cann/shmem main 之间尚未闭合的 ABI。

本文只依据三个固定源码状态：TileXR 46c58f3d、它的 SHMEM gitlink b79bda38、cann/shmem main 382afa08。没有 Ascend 硬件与完整 CANN 构建验证，因此“源码存在”“设计意图”和“可编译运行”会严格分开。

PagedAttention 是 vLLM 高吞吐推理的核心内存管理机制。它没有改变 Attention 的数学公式，也没有消灭 KV Cache，而是把每条请求持续增长的 KV Cache 切成固定大小的 Block，通过 Block Table 将逻辑连续的 Token 映射到不连续的 GPU 物理块。

它解决的核心矛盾是：LLM 服务需要保留大量、长度未知且生命周期不同的 KV Cache，但 GPU 显存有限，传统连续分配容易产生预留浪费和碎片。 更高的显存利用率允许 vLLM 同时容纳更多请求，进而扩大 Batch、提高吞吐并降低高负载下的排队延迟。

MoE 的 All-to-All 不是一次整齐的等长集合通信，而是由路由结果决定长度的 pack、跨 rank 搬运、完成通知、expert 计算、反向搬运与 combine。固定源码表明：TileXR 主仓已经预留 sendCountMatrix、UDMA flag 与设备指针，却没有落地可追踪的 MoE dispatch/combine kernel；真正实现分别位于它固定的 SHMEM fork 和 cann/shmem。本文只描述源码能证明的部分，所有缺少完整实验条件的性能数字均标为未公开或不可归因。

Mooncake 接入 vLLM 并不是把一个传输库直接塞进 attention：vLLM KVConnector 管请求和生命周期，Mooncake Transfer Engine 或 Store 管数据，vllm-ascend 再补上 NPU 地址、事件与后端适配。本文从固定 revision 的真实调用点穿刺这条链路，并专门核验一个容易混淆的问题：支持 Ascend、HCCL/RDMA 或名为 UBSHMEM 的 transport，是否等于使用 AIV Kernel 直驱？公开源码给出的答案是：不能等同，且当前没有找到 Mooncake KV 传输由 AIV Kernel 直驱的证据。