AIV Direct Drive

导言

“AIV 直驱”是昇腾通信优化语境中的常见简称。最稳妥的理解是：让运行在 AIV（Vector Core）上的 Kernel 直接编排和提交通信工作，避免由 Host CPU 或 AICPU 为每一次细粒度传输继续充当中间调度者。它优化的是通信控制路径；真正搬运字节的仍是 HCCS、RoCE、RDMA 或 URMA 等通信机制与硬件。

一句话先懂

把跨卡通信想成寄快递：数据是包裹，AIV 是整理包裹的仓库工人，AICPU 或 Host CPU 是调度员，通信硬件是车辆和道路。

传统路径需要多一次交接：

AIV 整理数据 → AICPU/Host 下发任务 → 通信硬件搬运 → AIV 继续处理

AIV 直驱把细粒度任务提交下沉到设备侧：

AIV 整理数据并提交任务 → 通信硬件搬运 → AIV 检查完成并继续处理

“直”是控制路径更直接，不是 AIV 亲自取代网卡。Host 通常仍负责初始化通信资源、建立连接和启动 AIV Kernel；进入 Kernel 后，AIV 才接管高频的提交、同步与后处理。

先认清 AIV

在昇腾 AI Core 的分离模式中，AIC 和 AIV 是一组不同职责的计算核。官方架构文档将 AIC 定义为 Cube Core，将 AIV 定义为 Vector Core；AIV 包含独立的 Scalar 调度单元、Vector 计算单元和搬运单元，因此能够加载并执行自己的代码段，而不只是一个被动的向量运算器。昇腾 AI Core 基本架构

部件	主要职责	在直驱中的位置
AIC / Cube Core	矩阵乘等 Cube 计算	通常是被通信流水喂数据的计算侧
AIV / Vector Core	向量处理、标量控制和数据整理	执行通信算法、准备描述符、提交与检查通信
AICPU / Host CPU	通用控制和任务编排	非直驱路径中的中间下发者；直驱后退出高频关键路径
HCCS / RoCE / RDMA / URMA	跨卡或跨机的数据传输	真正完成字节搬运的传输路径

不要把三个概念混在一起

AIV 是硬件计算核；AIV 通信引擎是一种通信执行方式；AIV 直驱 RDMA 是其中更具体的一条实现路径。内部交流可能把后两者都简称为“AIV 直驱”，讨论设计时应继续确认：直驱的是 HCCS、RoCE、RDMA 还是 URMA？旁路的是 Host，还是进一步旁路 AICPU？

“直驱”直在哪里

HCCL 的公开文档给出了较宽泛的 AIV 通信引擎路径：Host 先提交一个 AIV Kernel，调度器把 Kernel 发送到 Vector Core，随后通信步骤由 Vector Core 执行，并直接利用 HCCS 或 RoCE 完成数据搬运。HCCL 通信引擎

这里的“直接”是相对于两种更长的控制路径：

1. Host CPU + TS：Host 把内存拷贝、同步等操作逐项提交给 Device 侧 Task Scheduler。
2. AI CPU + TS：Host 先启动 AI CPU Kernel，再由 AICPU 提交通信任务，之后调度到执行器。
3. AIV 引擎：Host 启动一次 AIV Kernel，通信算法的高频步骤留在 Vector Core 内推进。

更窄的 AIV 直驱 RDMA 还会把 WQE 提交从 AICPU 下沉到 AIV。WQE（Work Queue Element）可以理解为提交给 RDMA 工作队列的一条描述项，包含源/目的地址、长度、对端和操作类型等信息。

非直驱：AIV 准备地址与长度 → AICPU 生成/提交 WQE → RDMA 传输
AIV直驱：AIV 准备地址与长度 → AIV 直接提交 WQE → RDMA 传输

昇腾公开的 MoE 案例指出，AICPU 驱动 RDMA 时 WQE 串行下发会阻碍深度流水；改为多个 AIV 核并行下发 WQE 后，可以减少提交时延，并把发送粒度从按目标 Rank 聚合进一步细化到 Token。CANN MoE 通算融合案例

对象与执行过程

下面采用一个教学化对象表。不同芯片、CANN 版本和通信协议的真实字段会变化；表中对象用于说明谁生产、谁消费以及何时结束生命周期，不冒充未公开源码。

对象	生产者	消费者	形状或内容	生命周期
input_tokens	上游模型阶段	AIV 预处理	[T, H]，FP16/BF16 示例	形成发送切片前保持存活
route_rank	MoE Router	AIV 控制逻辑	[T, K]，目标专家或 Rank	完成 Dispatch 规划后释放
send_slice	AIV Gather/Reorder	通信硬件	[t, H]	对应传输完成前保持存活
channel_ctx	Host/HCCL 初始化	AIV Kernel	Channel、对端地址和传输句柄	跨多次传输持久存在
wqe	直驱路径中的 AIV	RDMA 工作队列	地址、长度、对端、操作	从提交到完成状态返回
notify_or_flag	对端或通信协议	AIV 等待逻辑	Notify、Flag 或完成状态	覆盖一次同步区间
remote_buffer	通信硬件写入	接收侧 AIV	[T_recv, H]	后处理和下游消费期间存活
output_tokens	接收侧 AIV	本地专家或下一层	[T_recv, H]	作为机制输出继续向下游传递

AIV 通信算子的公开资源模型也对应这张表：Vector Core 表达 Rank 内并发，Notify 提供核内或跨 Rank 的软件同步，Channel 提供跨 Rank 数据通道。AIV 通信资源

下面的伪代码表达完整教学路径，不对应某个公开 API：

def host_prepare(group, topology):
    channel_ctx = create_channels(group, topology)
    notify_set = allocate_notify_state(group)
    register_communication_memory(group)
    launch_aiv_kernel(channel_ctx, notify_set)
    return channel_ctx, notify_set


def aiv_direct_dispatch(input_tokens, route_rank, channel_ctx, notify_set):
    send_order = stable_sort_indices(route_rank)
    packed_tokens = gather_rows(input_tokens, send_order)
    peer_ranges = build_peer_ranges(route_rank, send_order, channel_ctx.peers)
    inflight = []

    for peer in channel_ctx.peers:
        begin, end = peer_ranges[peer]
        if begin == end:
            continue

        send_slice = slice_rows(packed_tokens, begin, end)
        remote_address = channel_ctx.remote_address(peer, begin, end)
        wqe = build_write_descriptor(
            source_address=address_of(send_slice),
            destination_address=remote_address,
            byte_length=nbytes(send_slice),
            peer=peer,
            operation="WRITE",
        )
        request_id = post_from_aiv(channel_ctx.queue(peer), wqe)
        inflight.append((request_id, send_slice))

    for request_id, send_slice in inflight:
        wait_for_completion(request_id, notify_set)
        release_send_slice(send_slice)

    remote_buffer = wait_for_all_peer_payloads(notify_set)
    receive_order = build_receive_order(remote_buffer.metadata)
    output_tokens = gather_rows(remote_buffer.payload, receive_order)
    publish_ready_flag(output_tokens, notify_set)
    return output_tokens

{ width=100% }

自绘五视图技术图：A 展示旁路 AICPU 前后的物理路径；B 展示瓶颈、机制、效果与代价；C 展示一次运行过程；D 展示 Host、AIV、AICPU、传输引擎和对端 Buffer 的时序与对象生命周期；E 展示 Token 张量和控制对象的数据流。语义依据公开 CANN 9.0.0-beta.2/9.1.0-beta.3 文档与 MoE 技术文章，不是周期精确追踪，也不代表未公开源码。

读图时应特别注意：AICPU 被旁路的是每次 WQE 的高频提交，不是所有初始化工作；蓝色实线表示数据，橙色虚线表示控制；wqe 是控制描述符，不是 Token 张量。

MoE 中为何重要

MoE Dispatch 先根据 Router 结果，把每个 Token 发到对应专家所在的 Rank。此时通信通常具有三个特征：消息小、目标分散、每轮频繁发生。这恰好放大了固定下发时延，而不是只考验链路峰值带宽。

如果 WQE 主要由 AICPU 串行下发，为减少提交次数，实现往往倾向先把同一目标 Rank 的 Token 聚合成大块，再统一传输。这会引入等待：较早准备好的 Token 也要等同组数据聚齐。AIV 并行提交 WQE 后，可以让更多小块更早进入传输路径，并把机间接收、机内转发和接收后处理形成更深的流水。

{ width=92% }

原创认知插图：小黑代表 AIV，它不再把每张通信任务单交给远处的中转调度员，而是把 WQE 与数据块直接送入通信管道；管道代表传输机制，不代表 AIV 自己搬完所有字节。

公开案例报告 MoeDistributeDispatch 和 MoeDistributeCombine 在该实现与测试条件下，相比前一阶段的 AIV+AICPU 分层方案平均性能提升 **10%+**。这个数字只证明该案例中的相对结果；公开文章没有给出足以外推到其他模型、Shape、拓扑、硬件或 CANN 版本的完整原始数据，因此不能把它当作“AIV 直驱必然提升 10%”的通用结论。

收益与代价

把一次通信粗略拆为：

$$
T_{comm}=T_{launch}+T_{submit}+T_{transport}+T_{sync}+T_{post}
$$

其中，$T_{launch}$ 是 Kernel 启动时间，$T_{submit}$ 是工作描述符准备与提交时间，$T_{transport}$ 是链路传输时间，$T_{sync}$ 是完成确认与同步时间，$T_{post}$ 是接收后处理时间。AIV 直驱主要降低或掩盖 $T_{submit}$，并通过流水重叠部分 $T_{transport}$、$T_{sync}$ 与 $T_{post}$；它不会自动提高物理链路带宽。

维度	直接收益	新代价或限制
控制路径	减少 Host/AICPU 中转	设备侧协议和错误处理更复杂
提交并行度	多个 AIV 核可并行提交	需要正确划分队列、Channel 和同步资源
通信粒度	小块或 Token 可以更早发送	WQE 数量、状态轮询与元数据开销增加
通算流水	预处理、传输、转发、后处理可重叠	依赖拓扑、资源和完成语义正确配合
Vector 资源	AIV 可直接推进协议	通信与激活、量化等 Vector 计算竞争核资源
带宽上限	更容易减少空洞、接近可用带宽	链路饱和后，继续缩短提交路径收益有限

HCCL 文档明确把 AIV 引擎定位为低时延方案，同时提醒它会占用 Vector Core，并可能与计算算子争用；算法选择章节进一步把它指向数据量较小、时延敏感的推理通信。AIV 算法选择

要报告数值收益，至少应在同一模型、Batch/Token 分布、精度、EP 拓扑、硬件、CANN 版本和测量窗口下，对比端到端算子时间、WQE 提交时间、链路利用率、AIV 占用率以及 P50/P99 时延。

边界与误解

AIV 直驱通常值得优先评估的场景包括：

• 小而频繁的推理通信，固定提交时延占比较高。
• MoE Dispatch/Combine 或 AllToAllV，目标不规则且需要细粒度流水。
• 通信与 Vector 后处理融合，AIV 可以立即消费完成状态和接收数据。
• Host/AICPU 下发成为瓶颈，Profiler 能观察到提交串行或任务间空洞。

以下情况则不能仅凭“直驱”二字判断更优：

• 大块传输已经受链路带宽限制，控制时延占比很小。
• AIV 正在执行繁重的激活、量化或数据变换，通信会争抢 Vector Core。
• 组网、通信域、算子、数据类型或产品版本不支持对应引擎。
• 业务依赖复杂错误恢复、多通信域并行或尚未验证的完成语义。

版本边界

AIV 直驱不是跨所有昇腾产品自动成立的统一能力。例如 CANN 9.1.0-beta.2 发布说明只对指定产品和接口写明 Ascend 950PR 的 HcclChannelAcquire 支持 AIV 直驱 RoCE 与 URMA。阅读设计文档时必须同时确认产品、CANN 版本、接口、协议和拓扑。CANN 9.1.0-beta.2 发布说明

从实现归属看，通信域、Channel、Notify、内存注册和传输能力属于 CANN/HCCL 与底层 Runtime；具体算子的 Tiling、数据重排、WQE 粒度、完成状态消费和异常处理属于算子实现。迁移到新芯片、协议或新 MoE 结构时，至少要重新适配资源申请、目标映射、队列并发、同步协议、错误恢复和性能阈值，不能只替换一个“直驱”开关。

最常见的四个误解是：

1. 把 AIV 当成 AIC。AIV 是 Vector Core，AIC 主要负责 Cube 矩阵计算。
2. 把直驱理解成 AIV 亲自传完数据。AIV 负责控制与编排，传输硬件负责数据面搬运。
3. 把直驱理解成完全没有 Host。Host 仍可能负责资源初始化、建链、内存注册和 Kernel 启动。
4. 把低时延理解成带宽凭空增加。直驱主要减少软件提交开销；链路上限不会因此消失。

总结

理解 AIV 直驱时记住三条规则即可：先问旁路了谁，再问驱动了什么，最后问数据究竟由谁搬。在公开 CANN 语境下，宽泛定义是 Vector Core 执行通信算法并直接使用通信通路；在 AIV 直驱 RDMA 的窄义场景中，则进一步表示 AIV 自己提交 WQE、旁路 AICPU 的逐次下发。它的价值来自更短的控制路径、更高的提交并行度和更深的通算流水，代价是 AIV 占用、同步复杂度与严格的版本适配边界。

参考资料

1. CANN 9.1.0-beta.3：AI Core 基本架构
2. CANN 9.0.0-beta.2：HCCL 通信引擎
3. CANN 9.0.0-beta.2：AIV 算法选择
4. CANN 9.1.0-beta.3：AIV 通信资源
5. 昇腾社区：CANN MoE 通算融合与 AIV 直驱 RDMA
6. CANN 9.1.0-beta.2 发布说明