前言为什么从CPU往GPU传数据要用memcpy而从你自己电脑往同事电脑传文件却不需要知道对方内存地址这两个看似不相关的问题其实指向了同一个技术困境异构计算中的国界线。在CANN软件栈的体系里CPU和昇腾NPU就像两个主权国家各自管理着自己的内存领地数据跨越边界需要经过海关检查——显式的内存拷贝。这种设计在单机时代问题不大但当大模型推理需要把数百GB的KV Cache在不同节点间来回搬运时拷贝开销就成了性能瓶颈。hixl这个仓库名字里的Xi代表Transfer它要做的事情就是在这个异构世界里修一条高速公路让数据能像在同一个国家内部一样自由流动而不需要每次都过海关。异构内存访问的痛点从跨国物流说起理解hixl之前需要先弄清楚为什么异构计算的内存访问是个问题。把CPU和NPU想象成两个国家每个国家有自己的货币内存地址空间、自己的海关内存控制器、自己的运输公司DMA引擎。传统模式下如果CPU上的程序想要把数据发给NPU处理流程大致是这样的CPU先把数据打包序列化交给海关内存控制器海关检查货物地址转换接下来装车运输DMA传输到达对面海关后再拆包反序列化收尾阶段才能入库写入NPU内存。这个过程有几个明显的效率损耗一是每次跨境都要经过海关地址转换和数据校验消耗时间二是货物要装卸两次海关两边都要存储缓冲区三是运输公司不一定满载小批量货物往往要凑整车才能发车。在实际的大模型推理场景中这个痛点被放大了数倍。以KV Cache为例当推理请求从Prefill阶段进入Decode阶段时可能需要把上百GB的KV Cache从一台机器的显存搬运到另一台机器。如果走传统的RoCE网络带宽上限约20GB/s传输耗时超过5秒而同期NPU的计算能力可能已经闲置等待了。更糟糕的是这些数据在传输过程中要经过多次拷贝从NPU显存到Host内存D2H再从Host内存通过网络发出去对端接收后从Host内存拷贝到NPU显存H2D。每一级拷贝都消耗内存带宽和容量而内存带宽恰恰是AI芯片最稀缺的资源之一。hixl的设计思路把海关变成超市面对这些痛点hixl的选择不是优化海关流程而是直接让两个国家变成一个统一市场。这个思路的核心叫作统一虚拟地址空间Unified Virtual AddressUVA。它的基本设想是能不能让CPU和NPU使用同一套地址编码让一个地址指针既能被CPU解引用也能被NPU直接访问如果地址空间统一了数据就不需要拷贝了就像你在北京买的东西拿到上海还能用不需要兑换货币。hixl的架构可以分成三层来理解。最上层是应用接口层提供TransferSync、TransferAsync等传输API以及RegisterMem、Connect等生命周期管理接口。中间层是传输引擎负责把用户请求翻译成底层硬件能理解的指令并管理传输链路的状态。最底层是硬件抽象层屏蔽HCCS、RDMA等不同物理链路的差异让上层代码不用关心传输介质是什么。#includehixl/hixl.hhixl::Hixl engine;hixl::Status statusengine.Initialize(192.168.1.100:5678,{});if(status!hixl::SUCCESS){// 初始化失败处理return-1;}// 注册本地内存可以是Host内存或Device内存hixl::MemDesc mem_desc;mem_desc.addrreinterpret_castuintptr_t(buffer_ptr);mem_desc.lenbuffer_size;hixl::MemHandle mem_handle;statusengine.RegisterMem(mem_desc,hixl::MEM_DEVICE,mem_handle);// 连接远端引擎statusengine.Connect(192.168.1.101:5678,5000);// 发起传输hixl::TransferOpDesc op_desc;op_desc.local_addrmem_desc.addr;op_desc.remote_addrremote_buffer_addr;// 远端注册内存的地址op_desc.lentransfer_size;statusengine.TransferSync(192.168.1.101:5678,hixl::WRITE,{op_desc},3000);// 清理engine.DeregisterMem(mem_handle);engine.Finalize();这段代码展示了hixl的基本使用流程初始化引擎、注册内存、连接远端、发起传输、清理资源。代码中的每个接口都对应一个具体的生命周期阶段。为什么要显式RegisterMem而不是直接传地址因为底层硬件特别是RDMA网卡需要把虚拟地址锁定并映射到物理地址这个过程叫内存注册或内存固定。如果不显式注册每次传输都要做地址转换开销更大。把注册操作暴露给用户让用户决定哪些内存需要频繁传输可以避免不必要的注册开销。三种访问模式的适用场景没有万能钥匙hixl的设计者并没有试图创造一个万能的传输模式而是提供了三种各有优劣的访问路径让用户根据数据特征选择。模式一NPU直接访问CPU内存。这种模式适合数据量小、生命周期短的场景。典型例子是推理请求的输入token几十KB的数据用完即弃。如果为了这点数据专门分配NPU显存再拷贝开销比收益还大。hixl允许NPU通过PCIe直接读取Host内存虽然带宽不如HBM但省去了拷贝延迟。模式二CPU预取NPU数据。这种模式适合数据可以提前准备、且有明确使用时机的场景。典型例子是模型权重加载。推理服务启动时CPU把权重从磁盘加载到内存接下来预取到NPU显存。hixl提供异步接口让预取操作可以和计算重叠。模式三双向异步访问。这种模式适合数据双向流动、且时序不确定的场景。典型例子是分布式训练中的梯度同步。前向传播时NPU往Host写激活值反向传播时Host往NPU读梯度。hixl的TransferAsync接口支持这种全双工通信并通过GetTransferStatus接口查询传输完成状态。// 模式一NPU直接读Host内存小数据量场景void*host_buffermalloc(1024*1024);// 1MB数据hixl::MemDesc host_mem;host_mem.addrreinterpret_castuintptr_t(host_buffer);host_mem.len1024*1024;hixl::MemHandle host_handle;engine.RegisterMem(host_mem,hixl::MEM_HOST,host_handle);// NPU侧直接通过DMA读取这块Host内存hixl::TransferOpDesc read_desc;read_desc.local_addrdevice_buffer_addr;// NPU显存地址read_desc.remote_addrhost_mem.addr;// Host内存地址远端视角read_desc.len1024*1024;engine.TransferSync(remote_engine_id,hixl::READ,{read_desc});// 模式三双向异步传输分布式训练场景std::vectorhixl::TransferOpDescforward_ops;// ... 构建前向传播的数据传输描述hixl::TransferReq forward_req;engine.TransferAsync(remote_id,hixl::WRITE,forward_ops,{},forward_req);// 在等待传输完成的同时可以执行其他计算ComputeGradientOnDevice();// 查询传输状态hixl::TransferStatus status;engine.GetTransferStatus(forward_req,status);if(statushixl::TransferStatus::COMPLETED){// 传输完成继续后续逻辑}engine.DeregisterMem(host_handle);这段代码展示了小数据量场景和双向异步场景的典型用法。RegisterMem的第二个参数MEM_HOST和MEM_DEVICE区分了内存类型。为什么不统一用一种模式因为硬件约束不同。MEM_HOST类型走PCIe总线延迟高但容量大MEM_DEVICE类型走HCCS链路带宽大但容量有限。如果所有数据都走HCCS显存很快就会不够用如果所有数据都走PCIe带宽瓶颈又无法突破。三种模式本质上是让用户在延迟、带宽、容量三个维度上做权衡。FabricMem模式超节点内的内存池化hixl在2026年3月发布了一个重要特性——FabricMem模式。这个特性主要解决超节点Supernode场景下的内存访问效率问题。Atlas 800T A3超节点是一台特殊的机器机箱内部有多张计算卡每张卡有自己的DRAM内存但这些内存通过HCCS高速链路互联物理上形成了一个共享内存池。FabricMem模式利用这个特性把超节点内所有节点的DRAM统一编址让每个NPU都能直接访问其他节点的内存而不需要经过TCP/IP协议栈。具体实现上FabricMem依赖CANN的Virtual Memory Manager机制。每个进程先通过aclrtMallocPhysical申请物理内存再通过aclrtReserveMemAddress申请虚拟地址收尾阶段通过aclrtMapMem把物理内存映射到虚拟地址空间。映射完成后物理地址就可以在进程间交换其他进程把这个物理地址映射到自己的页表里就能通过SDMA指令直接读写。// 启用FabricMem模式std::maphixl::AscendString,hixl::AscendStringoptions;options[hixl::OPTION_ENABLE_USE_FABRIC_MEM]1;// 可选配置Fabric内存池参数options[hixl::OPTION_GLOBAL_RESOURCE_CONFIG]R({ fabric_memory: { pool_size_gb: 512, start_addr: 0x200000000000, max_stream_per_task: 8 } });hixl::Hixl engine;engine.Initialize(192.168.1.100:5678,options);// 在Atlas 800T A3超节点内带宽可达百GB/s级别hixl::MemDesc fabric_mem;fabric_mem.addrAllocateFabricMemory(128*1024*1024);// 128MBfabric_mem.len128*1024*1024;hixl::MemHandle fabric_handle;engine.RegisterMem(fabric_mem,hixl::MEM_HOST,fabric_handle);// 传输时底层走HCCS链路而非RoCEhixl::TransferOpDesc op;op.local_addrlocal_buffer_addr;op.remote_addrremote_fabric_addr;op.len128*1024*1024;// 实测带宽可达100GB/s以上基于A3超节点HCCS带宽参数估算engine.TransferSync(192.168.1.101:5678,hixl::WRITE,{op},5000);这段代码展示了FabricMem的启用方式通过在Initialize的options中设置OPTION_ENABLE_USE_FABRIC_MEM为1来开启。为什么FabricMem能达到百GB/s级带宽因为数据走的是HCCS链路而不是以太网。HCCS是昇腾芯片间的私有高速互联协议物理层是SerDes差分信号不需要经过TCP/IP协议栈的封装解封装。RoCE虽然也绕过了TCP/IP但受限于以太网物理带宽约25Gb/s每通道而HCCS链路的单通道带宽远超这个数字。LLM-DataDist为KV Cache量身定制的接口hixl的传输引擎是通用的可以搬运任意数据。但大模型推理场景有特定的数据语义——KV Cache。为了降低使用门槛hixl在传输引擎之上封装了一层LLM-DataDist接口。LLM-DataDist的核心概念是KV Cache Block。一个Block包含多层的Key和Value张量以及与之关联的序列号Sequence ID。用户不需要关心Block的物理地址只需要通过Sequence ID来标识和引用数据块。LLM-DataDist内部维护了一个地址映射表把Sequence ID翻译成物理地址后再调用底层的传输引擎。这个设计带来的好处是用户代码可以保持语义级的简洁不需要处理地址分配、对齐、碎片整理等底层细节。同时LLM-DataDist还提供了和vLLM、SGLang等推理引擎的对接接口让用户可以直接把KV Cache传输嵌入到现有的推理流程中。#includellm_datadist/llm_datadist.hllm_datadist::LLMDataDist data_dist;data_dist.Initialize(192.168.1.100:8888,{});// 注册本地KV Cache Blockllm_datadist::KVCacheBlock block;block.sequence_idreq_12345;block.layer_count32;block.num_tokens2048;data_dist.RegisterKVBlock(block);// 发起跨节点传输底层自动处理地址映射data_dist.TransferKVCache(192.168.1.101:8888,// 目标节点req_12345,// 序列号llm_datadist::WRITE,// 写入远端5000// 超时5秒);// 查询传输状态boolcompleteddata_dist.IsTransferCompleted(req_12345);// 清理data_dist.DeregisterKVBlock(req_12345);data_dist.Finalize();这段代码展示了LLM-DataDist的简化接口用户只需要操作Sequence ID不需要处理底层地址细节。为什么要封装一层语义接口因为直接暴露地址给应用层会带来维护负担。KV Cache的生命周期和推理请求强绑定如果应用层需要手动管理地址一旦请求被取消或超时地址泄漏的问题很难排查。封装一层语义接口让库来管理地址生命周期既降低了使用门槛又避免了资源泄漏。异构内存访问的效率对比传统memcpy方案和hixl零拷贝方案在效率上存在显著差异这种差异源于对内存带宽和传输延迟的不同处理方式。维度传统memcpy方案hixl零拷贝方案差异来源D2H拷贝延迟约1-2ms128MB数据0ms无拷贝避免PCIe总线往返网络传输带宽约20GB/sRoCE约100GB/sHCCSFabricMem物理链路差异H2D拷贝延迟约1-2ms128MB数据0ms无拷贝避免PCIe总线往返内存带宽占用三次全量读写D2H网络H2D单次远程读取减少内存控制器争用Host内存峰值约256MB发送接收缓冲区约128MB仅原始数据避免缓冲区分配上表中的数据基于以下参数估算128MB数据量PCIe Gen4 x16带宽约32GB/sRoCE v2网络带宽约20GB/sHCCS链路带宽约119GB/sAtlas A3芯片规格。传统方案需要D2H显存到Host内存、网络传输、H2DHost内存到显存三步每步都涉及内存读写。hixl方案通过统一地址空间和零拷贝技术将数据读写次数从三次降到一次。在多节点分布式训练场景下这种差异会更加明显。如果采用AllReduce算法同步梯度每个节点都要从其他节点读取数据。传统方案下每轮迭代的通信开销可能占总时间的30%-40%。而采用hixl的零拷贝方案特别是配合FabricMem的百GB/s级带宽通信开销占比可以降到15%以下让NPU的计算能力得到更充分的利用。API设计哲学极简背后的权衡hixl的API数量控制在十几个这在底层系统库中算是相当精简。设计者在多个地方做了显式vs隐式的权衡。连接管理是显式的。用户必须调用Connect建立连接调用Disconnect断开连接不能指望库自动建立和销毁。这种设计虽然增加了代码量但让连接的生命周期可追溯。在分布式系统中网络抖动是常态显式管理可以让用户决定重试策略和超时时间。内存注册是显式的。用户必须调用RegisterMem注册内存调用DeregisterMem解注册。虽然可以设计成传输时自动注册但那会带来两个问题一是每次传输都要注册开销更大二是注册失败时传输失败用户无法提前感知。显式注册让用户在初始化阶段就确定资源是否充足。传输是半显式的。TransferSync是阻塞调用TransferAsync是非阻塞调用但传输完成状态需要轮询查询。为什么不用回调函数因为回调函数会引入线程切换开销在高并发场景下反而降低性能。轮询看起来低效但在确定性时延场景下轮询的尾部延迟比回调更可控。// 异步传输配合轮询的典型模式hixl::TransferReq req;std::vectorhixl::TransferOpDescopsBuildTransferOps();engine.TransferAsync(remote_id,hixl::WRITE,ops,{},req);// 轮询等待不阻塞线程hixl::TransferStatus status;do{engine.GetTransferStatus(req,status);if(statushixl::TransferStatus::FAILED){// 处理失败可能需要重试break;}// 可以在这里穿插其他计算任务ProcessPendingWork();}while(statushixl::TransferStatus::WAITING);// 或者批量查询多个请求的状态hixl::GetTransferStatusArgs args;args.max_query_count100;args.skip_waitingtrue;// 只返回已完成/失败的请求std::vectorhixl::TransferResultresults;engine.GetTransferStatus(args,results);for(constautoresult:results){if(result.statushixl::TransferStatus::COMPLETED){// 处理完成的请求}}这段代码展示了异步传输配合轮询的使用模式以及批量查询状态的接口用法。为什么用轮询而不是回调因为在AI推理场景下尾部延迟比平均延迟更重要。回调函数引入的线程切换、锁竞争、队列排队都可能增加尾部延迟。轮询虽然看起来忙等但让用户完全控制时序可以精确预测完成时间。在实时推理服务中可预测性比吞吐量更关键。单边通信的本质hixl的全称是Huawei Xfer LibraryXfer暗示了它的设计理念——数据搬运而不是消息传递。传统通信库如MPI采用双边通信模式发送方调用Send接收方调用Recv双方必须配对才能完成传输。这种模式在并行计算中很自然但在异构场景下有问题接收方可能正忙着计算没空调用Recv。hixl采用的是单边通信模式发起方调用Transfer不需要接收方配合数据直接写入远端内存。这就像你可以直接把文件放到同事的网盘里不需要同事点击接收。单边通信的好处是解耦了通信和计算发送方可以在接收方计算的时候提前传输数据实现真正的通信计算重叠。当然单边通信也有代价接收方不知道数据什么时候到达需要额外的同步机制。hixl提供了Notify接口让发送方在数据写入完成后发送一个通知接收方通过轮询Notify队列来获知数据就绪。这种设计把同步时机交给了用户用户可以根据业务需求决定何时检查通知。从底层看设计动机回顾hixl的几个核心设计统一虚拟地址空间解决了地址不统一的问题零拷贝传输解决了数据搬运太多的问题FabricMem模式解决了带宽不够快的问题单边通信解决了对方没空接收的问题。这些设计背后有一个共同的主题减少异构世界的摩擦。在CPU-GPU异构计算时代这种摩擦已经存在了十几年。程序员习惯了memcpy、习惯了数据分片、习惯了等待DMA完成。hixl的设计者选择了一条不同的路如果硬件支持为什么不让程序员像操作本地内存一样操作远端内存这条路的技术门槛更高需要操作系统、驱动、运行时的配合但一旦打通上层应用就能获得数量级的性能提升。结尾hixl作为CANN软件栈中的异构通信库其核心价值在于提供了一条绕过传统内存拷贝的数据传输路径。统一虚拟地址空间、零拷贝传输、FabricMem模式、单边通信接口这些特性共同构成了一个面向异构场景的通信基础设施。在百GB级KV Cache跨节点传输、分布式训练梯度同步等场景中hixl能够降低内存带宽占用、减少传输延迟、提升端到端性能。当然这些收益的前提是用户理解hixl的设计原理并根据数据特征选择合适的访问模式。仓库地址https://atomgit.com/cann/hixl