前言

在大模型推理服务中，用户最敏感的体验指标莫过于首 Token 延迟（Time to First Token, TTFT）。当你在对话框中输入问题，等待模型开始吐出第一个字的那几秒，往往决定了用户对整个服务的评价。这个延迟从何而来？传统推理架构将完整的推理流程放在同一组 GPU/NPU 上，Prefill 阶段（处理完整输入 prompt）和 Decode 阶段（逐 token 生成）共享计算资源。当输入较长时，Prefill 阶段会占用大量计算时间和显存带宽，导致 Decode 阶段被迫等待——用户看到的就是漫长的空白。

Prefill-Decode 分离架构（PD 分离）正是为解决这个问题而生。其核心思想是将 Prefill 和 Decode 两个阶段拆分到不同的计算节点上并行执行：Prefill 节点专注于快速处理输入 prompt 并生成 KV Cache，Decode 节点则专注于高效的 token 生成。当 Prefill 节点完成计算后，需要将 KV Cache 传输给 Decode 节点继续推理。这个过程必须足够快，否则 PD 分离的性能增益会被传输开销吞噬。

这就是 hixl 登场的时刻。作为昇腾异构计算架构（CANN）生态中的点对点通信库，hixl 提供了高效的跨节点数据传输能力，特别针对大模型 PD 分离和 RL 后训练场景优化。它让数据能够"直达目的地"，成为大模型分布式推理的秘密武器。

hixl 的定位：点对点通信专家

在分布式计算领域，通信库可以分为两大类：集合通信和点对点通信。集合通信关注多节点间的协同操作，如 AllReduce、AllGather、Broadcast 等，典型代表是 hccl（Huawei Collective Communication Library）。这些操作需要所有参与节点同步执行，适合模型并行训练中的梯度同步、参数分发等场景。

点对点通信则聚焦于两个节点之间的数据传输，如 Send、Recv、Put、Get 等操作。这类通信不需要全局同步，发送方和接收方可以独立执行，更加灵活。在大模型推理的 PD 分离场景中，Prefill 节点完成计算后，需要将 KV Cache 发送给特定的 Decode 节点——这是一对一的定向传输，正是点对点通信的典型用例。

hixl 的定位非常明确：专注于点对点通信，与 hccl 形成互补。hccl 处理集合通信，hixl 处理点对点通信，两者共同构成昇腾分布式计算的通信基础设施。这种分工让开发者可以根据实际场景选择最合适的通信方式，而不是用一把锤子砸所有钉子。

从架构角度看，hixl 提供了三层能力：

• 传输层：基于 RDMA（远程直接内存访问）技术，支持跨节点零拷贝传输
• 编排层：管理通信连接、内存注册、数据序列化等
• 应用层：提供易用的 API 接口，支持 Send/Recv、Put/Get 等语义

核心能力：零拷贝与 MTE 直驱

零拷贝：让数据少走弯路

传统跨节点数据传输的流程是这样的：发送方先将数据从设备内存（NPU 显存）拷贝到主机内存（CPU 内存），通过网络协议栈发送给接收方，接收方再将数据从主机内存拷贝到设备内存。这个过程涉及两次设备与主机之间的拷贝，以及多次内存拷贝操作，延迟可达毫秒级别。

零拷贝技术的核心思想是让数据尽可能不经过中间环节。hixl 利用 RDMA 技术，允许发送方直接将设备内存中的数据写入接收方的设备内存，中间不经过任何主机内存。具体流程如下：

# 传统方式：多次拷贝
# 1. NPU -> CPU (发送方)
# 2. CPU -> 网络 (发送方)
# 3. 网络 -> CPU (接收方)
# 4. CPU -> NPU (接收方)
# 总延迟：~1000μs

# hixl 零拷贝方式
# 1. NPU -> NPU (直达)
# 总延迟：~10μs

这个性能差异在大模型推理中尤为关键。以一个 70B 参数的模型为例，其 KV Cache 大小可能达到数 GB 级别。如果每次传输都要经过 CPU 中转，延迟将累积到无法接受的程度。零拷贝让这个传输过程缩短到微秒级别，真正释放 PD 分离的性能潜力。

MTE 直驱：绕过协议栈

MTE（Memory Transfer Engine）是昇腾处理器内部的专用数据搬运引擎，可以在无需 CPU 参与的情况下完成大块数据的传输。hixl 通过 MTE 直驱技术，让数据传输完全绕过操作系统的网络协议栈，进一步降低延迟。

传统的网络传输路径是：应用程序 → 系统调用 → 协议栈 → 网卡驱动 → 网卡硬件。每一层都会引入额外的开销和延迟。MTE 直驱的路径是：应用程序 → MTE 硬件 → 网卡硬件。中间环节被大幅压缩，CPU 几乎不参与传输过程。

这种架构设计带来几个关键优势：

• 延迟确定性：传输延迟可预测，不受操作系统调度影响
• CPU 卸载：CPU 资源可以用于其他计算任务
• 带宽利用高：充分发挥网络硬件性能

单边通信：接收方无感知

单边通信（One-sided Communication）是 hixl 的杀手锏特性。传统的点对点通信需要发送方和接收方配合：发送方调用 Send，接收方调用 Recv，双方同步完成数据传输。这种方式要求接收方主动参与，如果接收方正在执行其他任务，传输就会被延迟。

单边通信允许发送方直接操作接收方的内存，无需接收方主动参与。具体来说，发送方可以调用 Put 操作，将数据写入接收方预先注册的内存区域；或者调用 Get 操作，从接收方内存读取数据。整个过程接收方不需要执行任何通信相关代码，可以专注于计算任务。

在大模型 PD 分离场景中，这个特性尤为宝贵。Decode 节点可能正在处理上一个请求的 token 生成，无法主动参与 KV Cache 的接收。使用单边通信，Prefill 节点可以直接将 KV Cache 写入 Decode 节点的预留内存区域，Decode 节点在适当时候直接使用即可。这种"异步直达"模式让通信和计算真正并行。

在 PD 分离中的应用：KV Cache 直达

PD 分离架构的典型部署方式是：多个 Prefill 节点负责处理输入 prompt，生成 KV Cache；多个 Decode 节点负责持续生成 token。当用户请求到达时，负载均衡器将其路由到一个 Prefill 节点，Prefill 节点完成计算后，将 KV Cache 传输给一个 Decode 节点继续推理。

传统实现中，这个传输过程通常使用 TCP 或 gRPC 等通用协议。以一个 70B 模型、2048 token 输入为例，KV Cache 大小约为 2GB。使用 TCP 传输，即使网络带宽达到 100Gbps，传输时间也需要 160ms 以上。这个延迟加上序列化/反序列化开销，使得 PD 分离的性能增益大打折扣。

使用 hixl 的零拷贝单边通信，情况完全不同。Prefill 节点可以在 KV Cache 生成完成后，立即通过 hixl 的 Put 操作将其写入 Decode 节点的内存。由于采用零拷贝和 MTE 直驱，传输延迟可以控制在毫秒级别。更重要的是，这个过程可以与 Decode 节点的其他工作并行——Decode 节点可能正在生成前一个请求的 token，而新的 KV Cache 已经在后台到达。

以下是简化的代码示例：

// Prefill 节点：生成 KV Cache 后发送
void send_kv_cache(hixl::Context& ctx, 
                   hixl::RemoteMemory& remote_mem,
                   void* kv_cache_ptr, 
                   size_t kv_cache_size) {
    // 1. 注册本地内存
    hixl::Memory local_mem = ctx.register_memory(
        kv_cache_ptr, kv_cache_size);
    
    // 2. 单边 Put：直接写入接收方内存
    hixl::Request req = ctx.put(
        local_mem,    // 本地源地址
        remote_mem,   // 远程目标地址
        kv_cache_size // 传输大小
    );
    
    // 3. 等待传输完成（非阻塞）
    req.wait();
}

// Decode 节点：预留内存，无需主动接收
void prepare_memory(hixl::Context& ctx,
                   void* buffer_ptr,
                   size_t buffer_size) {
    // 1. 注册内存并发布给发送方
    hixl::Memory remote_mem = ctx.register_memory(
        buffer_ptr, buffer_size);
    ctx.expose(remote_mem, "kv_cache_buffer");
    
    // 2. 继续执行其他计算，KV Cache 会自动到达
    // 无需主动调用 recv
}

这段代码展示了单边通信的核心特点：发送方主动 Push 数据，接收方只需提前暴露内存地址，无需阻塞等待。这种设计让 Decode 节点可以专注于 token 生成，通信开销被降到最低。

在 RL 后训练中的应用：Actor/Critic 梯度传输

强化学习（RL）后训练是提升大模型能力的重要手段，如 PPO、DPO 等算法需要在 Actor 模型和 Critic 模型之间频繁传输数据。在分布式训练场景中，Actor 和 Critic 可能部署在不同的节点上，中间的梯度传输成为性能瓶颈。

以 PPO 算法为例，训练流程涉及以下数据传输：

• Actor 生成动作样本，传输给 Critic
• Critic 计算价值估计，传输给 Actor
• Actor 计算 policy gradient，需要与 Critic 的梯度同步

传统实现使用 AllReduce 等集合通信，虽然可以实现梯度同步，但开销较大。AllReduce 需要所有节点同步，形成全局屏障，任何慢节点都会拖慢整体进度。

hixl 的点对点通信提供了一种更灵活的方案。Actor 和 Critic 之间可以直接使用 hixl 进行数据传输，无需全局同步。特别是对于稀疏梯度传输场景，点对点通信更加高效：

// Actor 节点：发送梯度给 Critic
void send_gradient_to_critic(hixl::Context& ctx,
                            int critic_rank,
                            float* grad_ptr,
                            size_t grad_size) {
    // 获取 Critic 节点的远程内存句柄
    hixl::RemoteMemory critic_mem = 
        ctx.get_remote_memory(critic_rank, "grad_buffer");
    
    // 单边 Put：直接写入 Critic 内存
    ctx.put(ctx.register_memory(grad_ptr, grad_size),
            critic_mem, 
            grad_size).wait();
}

// Critic 节点：接收梯度，无需主动参与
void prepare_grad_buffer(hixl::Context& ctx,
                        float* buffer,
                        size_t size) {
    hixl::Memory mem = ctx.register_memory(buffer, size);
    ctx.expose(mem, "grad_buffer");
    // 梯度会自动到达，继续其他计算
}

这种设计让 Actor 和 Critic 可以异步执行，减少等待时间。特别是在大规模集群中，节点间的性能差异不可避免，使用点对点通信可以让快的节点不必等待慢的节点，整体训练效率得到提升。

核心价值：让数据直达目的地

hixl 的设计哲学可以用一句话概括：让数据直达目的地。在大模型时代，数据传输已经成为计算流程中不可忽视的瓶颈。传统的通信方式——多次拷贝、协议栈开销、同步等待——在 PB 级数据流面前显得捉襟见肘。

hixl 通过三项核心技术解决这个问题：

• 零拷贝：数据从 NPU 直达 NPU，不绕弯路
• MTE 直驱：绕过协议栈，降低确定性延迟
• 单边通信：接收方无感知，通信与计算并行

这些技术的组合，让 hixl 成为大模型 PD 分离和 RL 后训练的关键基础设施。在 PD 分离场景中，KV Cache 的跨节点传输从百毫秒级降低到毫秒级，真正释放了分离架构的性能潜力。在 RL 后训练场景中，Actor 和 Critic 之间的高效通信让分布式训练更加灵活。

与 hccl 的互补定位，让昇腾生态形成了完整的通信能力矩阵：集合通信有 hccl，点对点通信有 hixl。开发者可以根据场景选择最合适的工具，而不是在不适配的工具上强行适配。

从更宏观的角度看，hixl 代表了分布式计算的一个趋势：让通信更加智能、更加高效、更加贴近硬件。随着大模型规模的持续增长，数据传输的重要性只会越来越高。hixl 提供了一个范例——如何通过架构创新，让数据流动的效率提升一个数量级。

这就是 hixl 的核心价值：不仅仅是通信库，更是大模型分布式推理和训练的效率引擎。当你在享受毫秒级首 Token 响应时，背后可能正是 hixl 在默默工作，让数据以最快的速度到达它该去的地方。