CANN hixl零拷贝通信在Prefill/Decode分离推理中的实战

前言

PD分离架构下，Prefill节点与Decode节点之间存在频繁的KV Cache传输。每次自回归迭代，Decode节点都需要从Prefill节点获取当前层的Key和Value张量，然后用Attention机制计算上下文向量。如果走标准TCP Socket，流程是：发送端从NPU内存拷贝数据到CPU内存，经内核协议栈处理，再经网络传输，接收端再从CPU内存拷贝到NPU内存。这一趟下来，内存拷贝次数多、网络吞吐受CPU处理能力制约、延迟抖动大。对于一个需要传输几百MB KV Cache数据、每秒几十次迭代的推理服务来说，这种开销根本无法接受。

hixl的核心设计思路是把这条数据通路简化成"发送端写、接收端读"，绕过操作系统的参与，用硬件直接搬数据。零拷贝的含义不是真的不需要搬运，而是省去了中间缓存层的内存拷贝——数据从NPU内存出发，直接到达目标进程的NPU内存，中途不需要经过CPU内存中转。对比传统Socket的"两拷贝+内核处理"路径，hixl实现了真正的单边路径，数据流动的路径短了，延迟自然就低了。

在Ascend 910上，NPU之间通过NVLink或PCIe互联，hixl利用这些高速链路绕过Linux网络协议栈，直接管理硬件通信通道。对多卡场景，hixl还支持同一POD内的跨卡零拷贝，以及跨服务器的RDMA传输。这套机制对PD分离推理特别友好，因为KV Cache的传输特征本身就是"从Prefill端单向流出、Decode端单向接收"，单向传输场景最适合单边通信发挥优势。

一、hixl的通信模型与零拷贝原理

理解hixl，先要理解传统双边的痛点在哪里。假设Prefill节点调用send(sockfd, buf, len)发送KV Cache数据，glibc会先把用户态buffer内容拷贝到内核Socket Buffer（一次拷贝），然后内核协议栈处理完后，再由网卡DMA把数据从Socket Buffer搬到网络上。接收端反过来，网卡DMA把数据收到内核Socket Buffer（又一次拷贝），然后应用层调用recv()再从内核态拷贝到用户态。这是典型的双边通信模型，CPU深度介入每次数据搬运。

hixl的单边模型把这种不对称性打破了。它借鉴了RDMA的verb语义——发送端（Responder）注册一块内存区域到硬件，接收端（Requester）直接用硬件指令在那块内存上写/读数据。CPU只负责建立连接和同步，具体的搬数据动作完全由硬件DMA完成。

hixl的具体实现依赖昇腾NPU的通信加速引擎。程序启动时调用hixl_init()初始化通信库，同时注册一块用于通信的共享内存。这块内存由昇腾通信引擎直接管理，应用程序不需要关心它的物理位置。连接建立后，发送端拿到一个"远端内存描述符"——本质上是一个句柄，告诉硬件目标在哪。调用hixl_send()时，数据从本地注册的内存区域出发，通过硬件DMA直接写到接收端注册的内存区域，中途不经过任何CPU内存拷贝，也不经过Linux网络协议栈。

为什么叫"零拷贝"？这里有个细节需要说明。严格来说，数据最终还是从一处物理内存搬到另一处物理内存——但这中间没有经过任何中间缓存，也没有CPU参与数据搬运。传统Socket有"内核缓冲区→用户缓冲区"的两次拷贝，hixl只有一次硬件层面的DMA搬运，这就是零拷贝的真正含义。

二、PD分离推理中的KV Cache传输场景

在Prefill/Decode分离的推理架构中，KV Cache的传输有明确的单向性。Prefill节点在处理完prompt后，会生成一组KV张量，每个transformer层都对应一组Key Cache和Value Cache。对于一个70B参数的模型，单层KV Cache的大小约为batch_size × seq_len × head_dim × num_heads × 2（Key和Value各一份），完整上下文可能达到数百MB甚至GB。这些数据需要在Prefill和Decode之间进行传递。

传统的解决方案有几条路：

一是用Redis或Memcached等外部存储系统。Prefill算完后写进去，Decode从里面读。这种方案引入了一个外部依赖，增加了系统的复杂度和延迟。Redis本身还是走TCP/IP协议，同样面临协议栈开销的问题。

二是用gRPC或者自定义的二进制协议走TCP直连。数据流和前面提到的Socket模型一样，需要经过内核协议栈。在高并发场景下，CPU处理协议栈的开销会成为瓶颈，尤其当传输的是GB级别的KV Cache时。

三就是用hixl。对PD分离这种单向传输场景，hixl的优势体现在几个方面：传输路径短，硬件直搬，没有协议栈开销；内存零拷贝，不触发垃圾回收，延迟稳定；支持多卡场景下的跨卡直接访问，无需绕回CPU。

具体到代码层面，Prefill节点初始化hixl时需要注册用于存放KV Cache的内存区域：

import ascend_hixl # 初始化hixl通信库，指定本端角色为Responder（发送方） hixl_ctx = ascend_hixl.init( role="responder", # Prefill节点作为KV Cache的发送端 dev_id=0, # 使用的昇腾NPU设备编号 # 注册一块大页内存，专门用于存放跨节点传输的KV Cache数据 # 这块内存后续会被硬件DMA直接访问，所以必须用支持设备间共享的页 buffer_size=2 * 1024 * 1024 * 1024, # 预分配2GB缓冲区，应对长序列场景 buffer_type="hbm" # 声明使用HBM而非CPU DDR，降低访问延迟 ) # 建立到Decode节点的连接 # hixl_connect内部会完成RDMA QP建立和内存区域注册 conn = hixl_ctx.connect( peer_ip="10.0.1.25", # Decode节点的IP port=9999, timeout_ms=5000 )

Prefill阶段完成计算后，KV Cache数据已经在之前注册的HBM缓冲区里。接下来只需要把元数据（当前层索引、序列位置、数据长度）告诉Decode节点，数据本身不需要再拷贝。发送端通过hixl_send触发硬件DMA，数据直接被推到Decode节点对应的内存区域：

# Prefill阶段计算完成后，调用send发送KV Cache # 这一步不会触发任何CPU参与的内存拷贝，数据直接从HBM出发 hixl_ctx.send( conn=conn, # 本地内存区域已经在init时注册，这里传句柄 local_buf=kv_cache_handle, offset=layer_index * layer_size, # 根据当前transformer层定位偏移 size=kv_slice_size, # flag设置同步模式，等接收端确认数据已就位再返回 flags=hixl.FLAG_SYNC )

Decode节点侧的接收逻辑类似，初始化时注册一块接收缓冲区，然后等待Prefill发来的数据。由于hixl支持零拷贝，接收到的数据直接在NPU HBM里，不需要再经过CPU内存。

# Decode节点作为Requester，初始化时注册接收缓冲区 recv_ctx = ascend_hixl.init( role="requester", dev_id=0, buffer_size=2 * 1024 * 1024 * 1024, buffer_type="hbm" ) # 监听来自Prefill节点的连接 listener = recv_ctx.listen(port=9999) # 进入推理主循环：等待KV Cache到达，执行Decode计算 while running: # hixl_recv是轮询接口，硬件层会等待数据就绪再返回 # 不返回时CPU可以去跑其他任务，不浪费资源 data = recv_ctx.recv(listener, timeout_ms=100) # data此刻直接是HBM里的数据指针，可以直接交给下层算子使用 # 不需要做任何内存拷贝 attn_output = attention_layer.forward(kv_data=data, query=current_query) decode_step()

从这段代码可以看到，Decode端的recv调用返回后，data已经是一个可以直接使用的HBM内存地址，不需要做任何拷贝就可以交给后续的Attention算子。这种设计让PD节点间的数据传输开销从"毫秒级"降到"微秒级"。

三、性能对比：hixl vs TCP Socket vs Redis

实际部署中，不同传输方案的性能差距是显著的。以下数据基于Ascend 910集群环境测试，仅供参考，实际性能受网络配置、序列长度、batch size等因素影响。

从数据来看，hixl的延迟只有TCP Socket的约十分之一，吞吐量是后者的7倍左右。这个差距在PD分离推理中会直接体现在首token延迟和端到端推理吞吐量上。延迟每降低1ms，Decode阶段每个token的生成时间就能减少约0.5ms，对一个1000 token的回复序列，总延迟能省下500ms左右。

CPU开销的差异在高并发场景下更为关键。假设一个推理服务同时处理32路并发请求，TCP Socket模式下协议栈的CPU消耗可能达到20%~30%，而hixl的硬件DMA几乎不消耗CPU，相同的CPU预算可以全部用来跑推理计算，间接提升系统的并发处理能力。

不过需要注意的是，hixl的优势建立在一定的硬件条件上。跨节点通信需要网络设备支持RDMA（通常是RoCEv2或者InfiniBand）。在没有RDMA支持的环境下，hixl会自动回退到TCP模式，优势会大打折扣。另外，两端的内存注册需要预先规划好地址空间，如果内存不足或者地址冲突，初始化会失败。

四、踩坑实录：hixl在PD分离场景的常见问题

问题一：内存区域注册失败

在实际部署中，最常见的问题就是hixl_init阶段报错"memory registration failed"。通常有两个原因：

一是HBM空间不够。PD分离推理本身会消耗大量HBM来存放模型权重和中间激活，注册通信用的缓冲区时，系统已经没有足够的连续空间。这时候需要调整模型切分策略，给通信池预留一定比例的HBM，或者把通信缓冲区改到CPU DDR（延迟会稍高，但容量大很多）。

二是NUMA亲和性问题。在多路服务器的NUMA架构上，注册HBM时如果没指定正确的本地NUMA节点，硬件访问这块内存会产生跨NUMA的访问延迟。初始化时建议显式指定numa_node=0或者通过nproc确认当前进程绑定的NUMA节点，然后注册同节点上的HBM。

# 踩坑修复：指定NUMA节点注册HBM缓冲区 import numa node_id = numa.node_of_cpu(numa.cpu_to_node(0)) hixl_ctx = ascend_hixl.init( role="responder", dev_id=0, buffer_size=2 * 1024 * 1024 * 1024, buffer_type="hbm", # 显式指定NUMA节点，避免跨节点访问 numa_node=node_id, # 允许内存溢出到DDR（牺牲部分延迟换取容量） allow_paging_to_ddr=True )

问题二：跨节点连接超时

生产环境中Prefill节点和Decode节点往往不在同一台物理机上，需要跨交换机通信。如果网络配置有问题（比如没有配置正确的路由或者防火墙阻断了端口），connect调用会在超时后失败。

排查这个问题时，先用ibstat或roce_info确认网卡是否支持RDMA且状态正常。然后检查两端IP是否互通（注意不要混用IPv4和IPv6地址）。最后确认端口没有被防火墙拦截。

# 排查网络连通性基础步骤 # 1. 确认网卡状态 ibstat # 2. 测试端到端连通性（不经过协议栈） hixl_diag --ping 10.0.1.25 --count 10 # 3. 如果ping不通，检查路由表 route -n # 如果需要，手动添加路由 ip route add 10.0.1.0/24 via <gateway_ip>

问题三：多路并发下的资源竞争

PD分离推理系统通常部署多路Prefill和Decode节点，形成M×N的通信拓扑。当Prefill节点同时给多个Decode节点发送数据时，如果通信库没有做并发管理，可能会出现资源竞争。

hixl通过连接池（Connection Pool）来解决这个问题。每个Peer维护独立的连接实例，不同的并发流走不同的物理通道。初始化时建议提前建立好到所有Decode节点的连接，避免在推理主循环里动态创建连接（创建连接的开销不低）。

# 预建连接池，避免在推理循环中创建连接 class HixlPool: def __init__(self, peer_list): self.connections = {} self.ctx = ascend_hixl.init(role="responder", dev_id=0) # 批量预建连接 for peer_ip, peer_port in peer_list: conn = self.ctx.connect( peer_ip=peer_ip, peer_port=peer_port, timeout_ms=10000 ) self.connections[(peer_ip, peer_port)] = conn def send_to(self, peer_ip, peer_port, data): # 根据peer选择对应的连接实例，并发安全 conn = self.connections[(peer_ip, peer_port)] return self.ctx.send(conn=conn, local_buf=data, flags=hixl.FLAG_ASYNC)

五、替代方案与选型建议

虽然hixl在PD分离场景下优势明显，但并不是所有场景都必须用它。如果团队目前的基础设施还不支持RDMA，强行上hixl反而会增加运维复杂度。这种情况下建议先用gRPC方案做原型验证，等网络基础设施就绪后再迁移到hixl。

另一个值得关注的替代是ascend-boost-comm。这个仓库是算子公共平台（中间件），实现了M×N算子复用，和hixl的定位有所不同。如果你的场景是"Prefill和Decode之间的通信相对稳定且流量大"，hixl是更好的选择；如果需要在多个计算节点之间动态分配算子负载，ascend-boost-comm可能更合适。二者在设计目标上有交叉，但在通信路径上各有侧重，实际选型时需要结合具体的推理架构来做决策。

还有一种折中方案是混合模式：跨节点通信用hixl，单机多卡内部用ascend-boost-comm做负载均衡。这样既能保证跨节点的零拷贝优势，又能充分利用单机的算力聚合能力。这种混合部署模式在大规模推理集群中越来越常见。

六、验证与调优实践

部署完hixl通信层后，需要做系统性的验证来确认零拷贝是否真正生效。常见的验证方法是检查NPU内存的直接访问计数：如果数据真的从HBM直接DMA到远端，CPU侧不会有任何内存拷贝操作。

一个简单的验证脚本：

import ascend_hixl import ascend_rt # 创建两个hixl上下文，模拟Prefill->Decode通信 pref_ctx = ascend_hixl.init(role="responder", dev_id=0) dec_ctx = ascend_hixl.init(role="requester", dev_id=1) # 建立连接 conn = pref_ctx.connect(peer_ip="10.0.1.25", port=9999) # 创建一块测试数据，填充特定模式方便验证 test_buf = ascend_rt.allocate(shape=(1024, 1024), dtype="float16") ascend_rt.fill(test_buf, value=0.1234) # 发送数据 pref_ctx.send(conn=conn, local_buf=test_buf, size=test_buf.nbytes) # 接收端确认 recv_buf = dec_ctx.recv(timeout_ms=5000) # 校验数据一致性：验证是否发生了真正的零拷贝 assert ascend_rt.allclose(test_buf, recv_buf), "数据不一致！" print("零拷贝传输验证通过")

调优方面，有几个参数值得关注。buffer_size影响预分配内存的总量，需要根据KV Cache的最大尺寸来估算，建议预留30%以上的余量。FLAGS选择上，在推理主循环内建议用FLAG_ASYNC做异步发送，避免等待期间CPU空转；在关键同步点（比如Prefill算完后等待Decode就绪）用FLAG_SYNC保证数据可见性。timeout_ms设置需要结合网络环境，跨交换机场景建议5秒以上，避免误判网络抖动为故障。

结尾

hixl为零拷贝场景设计，在PD分离推理中表现出的低延迟和高吞吐，来自于硬件直搬的通信路径和对传统协议栈的绕过。接入这套通信库需要具备RDMA网络环境，但一旦跑通，KV Cache传输的开销从毫秒级降到微秒级，对端到端推理体验的改善是实打实的。

仓库链接：

https://gitee.com/ascend/cann/tree/master/hixl