：custom_all_reduce 单机/跨节点原理（IPC、Fabric、HSA）)
目录1 为什么有custom_all_reduce2 节点内的Custom AllReduce2.1 节点内的Custom AllReduce大体原理2.2 IPCHIP IPC3 跨节点的Custom AllReduce3.1 跨节点的Custom AllReduce大体原理3.2 FabricHSA RPC Fabric4 那么IPC和跨机的Fabric通信区别在哪里4.1 共同流程IPC 和 Fabric 都一样4.2 区别4.3 IPC 模式其实就是用了HIP API实现了共享显存的原理1. 分配显存2. 导出句柄64 字节3. 交换句柄控制面4. 对端打开句柄5. 限制4.4 Fabric 模式其实就是用了hsa的api实现了共享显存1. 分配显存2. 导出句柄256 字节3. 交换句柄控制面4. 对端 attach 句柄5. 能力4.5 区别对比表格4.6 IPC 那套 API 属于谁4.7 Fabric 那套 API 属于谁5 什么是HSAHSA 是什么HSA Runtime 是什么和 HIP 是什么关系abstract:heterogeneous 英/ ˌhetərəˈdʒiːniəs / 有很多种类组成的化不均一的多相的数不纯一的参差的, 这里是异构的意思fabric 英/ ˈfæbrɪk / 布料织物构造结构汽车的车身飞机的机身 这里是Fabric 在此指超节点 GPU 互联结构跨节点 CAR 通过 HSA RPC Fabric API 完成显存导出与映射而不是普通以太网/IB 发包。一句话概括Custom AllReduce 的快路径都是通过共享/映射 GPU 显存完成通信——节点内靠 HIP或 CUDAIPC 句柄跨节点超节点靠 HSA Fabric 句柄差别主要在用什么 API 导出和打开显存句柄。HSA Heterogeneous System Architecture异构系统架构1 为什么有custom_all_reduceCustom AllReduce 是 vLLM 为 Tensor Parallel 场景实现的一条专用 AllReduce 快路径。在满足条件时它不经过 PyNccl/RCCL 这类通用集体通信而是通过 vLLM 自研的 GPU 核函数vllm._custom_ops配合 GPU 显存 IPC/P2P 直连来完成求和条件不满足时会自动回退到 NCCL/RCCL。具体代码路径在 vllm/distributed/device_communicators/custom_all_reduce.py2 节点内的Custom AllReduce2.1 节点内的Custom AllReduce大体原理控制面用torch.distributednon-NCCL 的cpu_group一般是 Gloo交换 IPC handle数据面用 vLLM 自研 C 扩展vllm._custom_ops通过 CUDA IPC / HIP IPC 让同机 GPU 直接访问彼此显存计算自定义 all-reduce kernel 在 GPU 上直接做 reduce关键代码def create_shared_buffer(...): pointer, handle ops.allocate_shared_buffer_and_handle(size_in_bytes) ... dist.all_gather_object(handles, handle, groupgroup) # 控制面交换 handle ... pointers.append(ops.open_mem_handle(h)) # 数据面打开对端显存以及真正执行 reduceops.all_reduce(self._ptr, inp, out, 0, 0) # 自定义 kernel不是 torch2.2 IPCHIP IPC你的 GPU 显存 ──transport── 别的 GPU 能直接读到这块显存 ── kernel 做 reduce项目说明全称Inter-Process CommunicationGPU 显存句柄共享范围同一台物理机同一 OS、同一 shared-memory namespace原理本机 GPU A 导出显存 handle64 字节GPU B 用open_mem_handle打开直接访问 A 的显存谁在用vLLM 原版、aiter 同节点模式限制跨物理机不行——两台服务器之间没法用 IPCIPC 确实是「进程间通信」你没理解错。IPC Inter-Process Communication进程间通信。在 CAR 这里它特指的是 GPU 显存的 IPCHIP IPC / CUDA IPC不是泛指 socket、MPI 那种通用进程通信进程 AGPU0 导出显存 handle↓进程 BGPU1 打开 handle直接访问 GPU0 的显存所以名字上是进程间通信实现上是 GPU 显存句柄共享 直连访问范围上同一台物理机同一 OS、同一 shared-memory namespace3 跨节点的Custom AllReduce3.1 跨节点的Custom AllReduce大体原理aiter 在同样思路上做了超节点扩展数据面多了一条 Fabric 路径transport数据面适用场景ipcHIP IPC和 vLLM 类似同节点fabricHSA RPC / Fabric 显存共享跨节点超节点auto同节点 IPC跨节点 Fabric自动选择aiter 初始化时会选 transportif self.requested_transport ipc: if not same_node: return # 跨节点不能用 IPC self.transport ipc elif self.requested_transport auto: self.transport ipc if same_node else fabric else: self.transport fabric # 强制超节点 Fabric3.2 FabricHSA RPC Fabric项目说明范围跨物理机超节点多台服务器通过专用互联原理用hsa_ext_rpc_memory_create/attach/detach做跨节点显存导出和映射handle 大小256 字节IPC 是 64 字节谁在用aiter 超节点模式前提编译时AITER_ENABLE_SUPERNODE_AR1运行时AITER_AR_TRANSPORTfabricFabric 也是「共享显存」思路只是跨了物理机可以这么理解Fabric 把「导出显存 → 对端 attach → 直接访问」这套模型从单机扩展到了跨节点。aiter 文档里写得很直白层次做什么跨节点内存导出/映射hsa_ext_rpc_memory_create/attach/detach实际 AllReducekernel 直接访问 Fabric 映射后的地址4 那么IPC和跨机的Fabric通信区别在哪里4.1 共同流程IPC 和 Fabric 都一样1. 每个 rank 在本机 GPU 上分配一块显存2. 每个 rank 把这块显存「导出」成一个 handle句柄3. 通过控制面把 handle 发给所有 rankTCPStore / torch.distributed4. 每个 rank 用对端 handle「打开/attach」得到本进程里可访问的指针5. kernel 直接通过这些指针 读/写 远端显存完成 all-reduce4.2 区别其实本质区别就在于怎么把本机 GPU 显存「导出」成句柄以及别的 rank 怎么「打开/attach」这个句柄拿到可访问的地址。其实往下看就能知道它们两者相当于用了不同的api去实现了共享显存4.3 IPC 模式其实就是用了HIP API实现了共享显存的原理1. 分配显存hipMalloc / hipExtMallocWithFlags(...) // 本机 GPU 显存2. 导出句柄64 字节hipIpcGetMemHandle(handle, gpu_ptr)得到hipIpcMemHandle_t64 字节描述「这块本机 GPU 显存」。vLLM 里对应custom_all_reduce.cuLines 167-174// Create IPC memhandle for the allocated buffer.cudaIpcGetMemHandle((cudaIpcMemHandle_t*)handle.data_ptr(), buffer);3. 交换句柄控制面dist.all_gather_object(handles, handle, groupgroup) # vLLM# 或 aiter 用 TCPStore pickle 交换4. 对端打开句柄hipIpcOpenMemHandle(mapped_ptr, peer_handle, hipIpcMemLazyEnablePeerAccess)在本进程地址空间里映射到同一台机器上另一块 GPU 的显存。5. 限制必须同一物理机同一 OS、同一 shared-memory namespace依赖 GPU P2P / XGMI跨物理机时hipIpcOpenMemHandle无效4.4 Fabric 模式其实就是用了hsa的api实现了共享显存1. 分配显存hipExtMallocWithFlags(..., hipDeviceMallocUncached) // 或 finegrained要求这块显存可被 Fabric 导出。2. 导出句柄256 字节hsa_ext_rpc_memory_create(gpu_ptr, size, fabric_handle)得到hsa_ext_rpc_memory_t256 字节不是 HIP IPC handle。aiter 源码custom_all_reduce.cu Lines 404-425void get_meta_buffer_handle(..., transport) { if (transport IPC) hipIpcGetMemHandle(...); // 64 字节 else hsa_ext_rpc_memory_create(...); // 256 字节 }3. 交换句柄控制面和 IPC 同一套机制aiter 的_gather_ipc_meta走 TCPStore只是 handle 更大、内容不同。4. 对端 attach 句柄hsa_ext_rpc_memory_attach(fabric_handle, 1, fabric_agent, mapped_ptr)通过 HSA RPC Fabric agent把远端物理机 GPU 显存映射到本机可访问地址。aiter C 里custom_all_reduce.cuh Lines 2623-2646char* open_peer_handle(const void* handle) { if (transport IPC) return open_ipc_handle(handle); // hipIpcOpenMemHandle // Fabric: hsa_ext_rpc_memory_attach(fabric_handle, 1, fabric_agent_, mapped_ptr); return mapped_ptr; }5. 能力可跨物理机超节点专用互联需要编译AITER_ENABLE_SUPERNODE_AR1需要链libhsa-runtime644.5 区别对比表格步骤IPCFabric分配显存hipMalloc/ uncacheduncached / finegrained导出 APIhipIpcGetMemHandlehsa_ext_rpc_memory_create句柄类型hipIpcMemHandle_t64Bhsa_ext_rpc_memory_t256B句柄交换TCPStore / all_gather一样打开 APIhipIpcOpenMemHandlehsa_ext_rpc_memory_attach映射结果同机另一 GPU 显存地址跨机远端 GPU 显存地址范围单机多机超节点4.6 IPC 那套 API 属于谁属于 HIPROCm 运行时不是 aiter 自己的 API。API所属库hipMalloc/hipExtMallocWithFlagsHIP Runtimelibamdhip64hipIpcGetMemHandleHIP IPC API仍在 HIP/ROCm 里hipIpcOpenMemHandleHIP IPC API在 NVIDIA 上vLLM 用的是同一思路的 CUDA Runtime APIcudaMalloccudaIpcGetMemHandlecudaIpcOpenMemHandle4.7 Fabric 那套 API 属于谁不属于 aiter属于 HSA Runtimelibhsa-runtime64 的超节点扩展 API。API所属库hsa_ext_rpc_memory_createHSA RPC Fabric 扩展hsa_ext_rpc_memory_attachHSA RPC Fabric 扩展hsa_ext_rpc_memory_detachHSA RPC Fabric 扩展hsa_iterate_agents等标准 HSA Runtimeaiter 文档写得很清楚跨节点内存导出/映射用的是hsa_ext_rpc_memory_create/attach/detach并且.so会链接libhsa-runtime64。所以 Fabric API 是 AMD超节点平台HSA Fabric 互联 提供的不是 aiter 发明的。5 什么是HSAHSA 是什么HSA Heterogeneous System Architecture异构系统架构最初由 AMD 等推动的一套规范目标是让 CPU 和 GPU以及其它加速器在同一套系统模型下协同工作包括统一的「设备/agent」抽象统一的内存与访问模型设备发现、队列、同步等运行时能力可以把它看成比 HIP 更底层的一整套「异构计算平台规范 运行时基础设施」。HSA Runtime 是什么HSA Runtime 是 HSA 规范的具体实现库在 Linux 上通常是libhsa-runtime64.so它提供的是运行时 API例如能力典型 API发现设备hsa_iterate_agents枚举 CPU、GPU 等 agent内存管理各类 HSA 内存分配/映射 API队列与同步提交任务、信号量等超节点扩展hsa_ext_rpc_memory_create/attach/detachFabric 跨节点显存你们 aiter Fabric 模式里用的hsa_ext_rpc_memory_*就是 HSA Runtime 提供的扩展 API不是 aiter 自己定义的。和 HIP 是什么关系在 AMD/海光 ROCm 生态里可以粗略看成两层你写 kernel、跑算子↓HIP ← 类似 CUDA日常开发主要用这个↓HSA Runtime ← 更底层管 agent、部分内存/互联能力↓驱动 / 硬件HIPHSA Runtime角色GPU 编程接口写 kernel、malloc 显存异构系统运行时设备模型、底层互联类比CUDA比 CUDA Driver 更「系统级」的一层开发者经常直接写多数时候不直接写库/驱动会调在你们场景IPC 用hipIpcGetMemHandleFabric 用hsa_ext_rpc_memory_*所以IPC走 HIP 自己的同机显存句柄机制Fabric跨机时 HIP IPC 不够要借助 HSA Runtime 的 Fabric/RPC 内存扩展
目录1 为什么有custom_all_reduce2 节点内的Custom AllReduce2.1 节点内的Custom AllReduce大体原理2.2 IPCHIP IPC3 跨节点的Custom AllReduce3.1 跨节点的Custom AllReduce大体原理3.2 FabricHSA RPC Fabric4 那么IPC和跨机的Fabric通信区别在哪里4.1 共同流程IPC 和 Fabric 都一样4.2 区别4.3 IPC 模式其实就是用了HIP API实现了共享显存的原理1. 分配显存2. 导出句柄64 字节3. 交换句柄控制面4. 对端打开句柄5. 限制4.4 Fabric 模式其实就是用了hsa的api实现了共享显存1. 分配显存2. 导出句柄256 字节3. 交换句柄控制面4. 对端 attach 句柄5. 能力4.5 区别对比表格4.6 IPC 那套 API 属于谁4.7 Fabric 那套 API 属于谁5 什么是HSAHSA 是什么HSA Runtime 是什么和 HIP 是什么关系abstract:heterogeneous 英/ ˌhetərəˈdʒiːniəs / 有很多种类组成的化不均一的多相的数不纯一的参差的, 这里是异构的意思fabric 英/ ˈfæbrɪk / 布料织物构造结构汽车的车身飞机的机身 这里是Fabric 在此指超节点 GPU 互联结构跨节点 CAR 通过 HSA RPC Fabric API 完成显存导出与映射而不是普通以太网/IB 发包。一句话概括Custom AllReduce 的快路径都是通过共享/映射 GPU 显存完成通信——节点内靠 HIP或 CUDAIPC 句柄跨节点超节点靠 HSA Fabric 句柄差别主要在用什么 API 导出和打开显存句柄。HSA Heterogeneous System Architecture异构系统架构1 为什么有custom_all_reduceCustom AllReduce 是 vLLM 为 Tensor Parallel 场景实现的一条专用 AllReduce 快路径。在满足条件时它不经过 PyNccl/RCCL 这类通用集体通信而是通过 vLLM 自研的 GPU 核函数vllm._custom_ops配合 GPU 显存 IPC/P2P 直连来完成求和条件不满足时会自动回退到 NCCL/RCCL。具体代码路径在 vllm/distributed/device_communicators/custom_all_reduce.py2 节点内的Custom AllReduce2.1 节点内的Custom AllReduce大体原理控制面用torch.distributednon-NCCL 的cpu_group一般是 Gloo交换 IPC handle数据面用 vLLM 自研 C 扩展vllm._custom_ops通过 CUDA IPC / HIP IPC 让同机 GPU 直接访问彼此显存计算自定义 all-reduce kernel 在 GPU 上直接做 reduce关键代码def create_shared_buffer(...): pointer, handle ops.allocate_shared_buffer_and_handle(size_in_bytes) ... dist.all_gather_object(handles, handle, groupgroup) # 控制面交换 handle ... pointers.append(ops.open_mem_handle(h)) # 数据面打开对端显存以及真正执行 reduceops.all_reduce(self._ptr, inp, out, 0, 0) # 自定义 kernel不是 torch2.2 IPCHIP IPC你的 GPU 显存 ──transport── 别的 GPU 能直接读到这块显存 ── kernel 做 reduce项目说明全称Inter-Process CommunicationGPU 显存句柄共享范围同一台物理机同一 OS、同一 shared-memory namespace原理本机 GPU A 导出显存 handle64 字节GPU B 用open_mem_handle打开直接访问 A 的显存谁在用vLLM 原版、aiter 同节点模式限制跨物理机不行——两台服务器之间没法用 IPCIPC 确实是「进程间通信」你没理解错。IPC Inter-Process Communication进程间通信。在 CAR 这里它特指的是 GPU 显存的 IPCHIP IPC / CUDA IPC不是泛指 socket、MPI 那种通用进程通信进程 AGPU0 导出显存 handle↓进程 BGPU1 打开 handle直接访问 GPU0 的显存所以名字上是进程间通信实现上是 GPU 显存句柄共享 直连访问范围上同一台物理机同一 OS、同一 shared-memory namespace3 跨节点的Custom AllReduce3.1 跨节点的Custom AllReduce大体原理aiter 在同样思路上做了超节点扩展数据面多了一条 Fabric 路径transport数据面适用场景ipcHIP IPC和 vLLM 类似同节点fabricHSA RPC / Fabric 显存共享跨节点超节点auto同节点 IPC跨节点 Fabric自动选择aiter 初始化时会选 transportif self.requested_transport ipc: if not same_node: return # 跨节点不能用 IPC self.transport ipc elif self.requested_transport auto: self.transport ipc if same_node else fabric else: self.transport fabric # 强制超节点 Fabric3.2 FabricHSA RPC Fabric项目说明范围跨物理机超节点多台服务器通过专用互联原理用hsa_ext_rpc_memory_create/attach/detach做跨节点显存导出和映射handle 大小256 字节IPC 是 64 字节谁在用aiter 超节点模式前提编译时AITER_ENABLE_SUPERNODE_AR1运行时AITER_AR_TRANSPORTfabricFabric 也是「共享显存」思路只是跨了物理机可以这么理解Fabric 把「导出显存 → 对端 attach → 直接访问」这套模型从单机扩展到了跨节点。aiter 文档里写得很直白层次做什么跨节点内存导出/映射hsa_ext_rpc_memory_create/attach/detach实际 AllReducekernel 直接访问 Fabric 映射后的地址4 那么IPC和跨机的Fabric通信区别在哪里4.1 共同流程IPC 和 Fabric 都一样1. 每个 rank 在本机 GPU 上分配一块显存2. 每个 rank 把这块显存「导出」成一个 handle句柄3. 通过控制面把 handle 发给所有 rankTCPStore / torch.distributed4. 每个 rank 用对端 handle「打开/attach」得到本进程里可访问的指针5. kernel 直接通过这些指针 读/写 远端显存完成 all-reduce4.2 区别其实本质区别就在于怎么把本机 GPU 显存「导出」成句柄以及别的 rank 怎么「打开/attach」这个句柄拿到可访问的地址。其实往下看就能知道它们两者相当于用了不同的api去实现了共享显存4.3 IPC 模式其实就是用了HIP API实现了共享显存的原理1. 分配显存hipMalloc / hipExtMallocWithFlags(...) // 本机 GPU 显存2. 导出句柄64 字节hipIpcGetMemHandle(handle, gpu_ptr)得到hipIpcMemHandle_t64 字节描述「这块本机 GPU 显存」。vLLM 里对应custom_all_reduce.cuLines 167-174// Create IPC memhandle for the allocated buffer.cudaIpcGetMemHandle((cudaIpcMemHandle_t*)handle.data_ptr(), buffer);3. 交换句柄控制面dist.all_gather_object(handles, handle, groupgroup) # vLLM# 或 aiter 用 TCPStore pickle 交换4. 对端打开句柄hipIpcOpenMemHandle(mapped_ptr, peer_handle, hipIpcMemLazyEnablePeerAccess)在本进程地址空间里映射到同一台机器上另一块 GPU 的显存。5. 限制必须同一物理机同一 OS、同一 shared-memory namespace依赖 GPU P2P / XGMI跨物理机时hipIpcOpenMemHandle无效4.4 Fabric 模式其实就是用了hsa的api实现了共享显存1. 分配显存hipExtMallocWithFlags(..., hipDeviceMallocUncached) // 或 finegrained要求这块显存可被 Fabric 导出。2. 导出句柄256 字节hsa_ext_rpc_memory_create(gpu_ptr, size, fabric_handle)得到hsa_ext_rpc_memory_t256 字节不是 HIP IPC handle。aiter 源码custom_all_reduce.cu Lines 404-425void get_meta_buffer_handle(..., transport) { if (transport IPC) hipIpcGetMemHandle(...); // 64 字节 else hsa_ext_rpc_memory_create(...); // 256 字节 }3. 交换句柄控制面和 IPC 同一套机制aiter 的_gather_ipc_meta走 TCPStore只是 handle 更大、内容不同。4. 对端 attach 句柄hsa_ext_rpc_memory_attach(fabric_handle, 1, fabric_agent, mapped_ptr)通过 HSA RPC Fabric agent把远端物理机 GPU 显存映射到本机可访问地址。aiter C 里custom_all_reduce.cuh Lines 2623-2646char* open_peer_handle(const void* handle) { if (transport IPC) return open_ipc_handle(handle); // hipIpcOpenMemHandle // Fabric: hsa_ext_rpc_memory_attach(fabric_handle, 1, fabric_agent_, mapped_ptr); return mapped_ptr; }5. 能力可跨物理机超节点专用互联需要编译AITER_ENABLE_SUPERNODE_AR1需要链libhsa-runtime644.5 区别对比表格步骤IPCFabric分配显存hipMalloc/ uncacheduncached / finegrained导出 APIhipIpcGetMemHandlehsa_ext_rpc_memory_create句柄类型hipIpcMemHandle_t64Bhsa_ext_rpc_memory_t256B句柄交换TCPStore / all_gather一样打开 APIhipIpcOpenMemHandlehsa_ext_rpc_memory_attach映射结果同机另一 GPU 显存地址跨机远端 GPU 显存地址范围单机多机超节点4.6 IPC 那套 API 属于谁属于 HIPROCm 运行时不是 aiter 自己的 API。API所属库hipMalloc/hipExtMallocWithFlagsHIP Runtimelibamdhip64hipIpcGetMemHandleHIP IPC API仍在 HIP/ROCm 里hipIpcOpenMemHandleHIP IPC API在 NVIDIA 上vLLM 用的是同一思路的 CUDA Runtime APIcudaMalloccudaIpcGetMemHandlecudaIpcOpenMemHandle4.7 Fabric 那套 API 属于谁不属于 aiter属于 HSA Runtimelibhsa-runtime64 的超节点扩展 API。API所属库hsa_ext_rpc_memory_createHSA RPC Fabric 扩展hsa_ext_rpc_memory_attachHSA RPC Fabric 扩展hsa_ext_rpc_memory_detachHSA RPC Fabric 扩展hsa_iterate_agents等标准 HSA Runtimeaiter 文档写得很清楚跨节点内存导出/映射用的是hsa_ext_rpc_memory_create/attach/detach并且.so会链接libhsa-runtime64。所以 Fabric API 是 AMD超节点平台HSA Fabric 互联 提供的不是 aiter 发明的。5 什么是HSAHSA 是什么HSA Heterogeneous System Architecture异构系统架构最初由 AMD 等推动的一套规范目标是让 CPU 和 GPU以及其它加速器在同一套系统模型下协同工作包括统一的「设备/agent」抽象统一的内存与访问模型设备发现、队列、同步等运行时能力可以把它看成比 HIP 更底层的一整套「异构计算平台规范 运行时基础设施」。HSA Runtime 是什么HSA Runtime 是 HSA 规范的具体实现库在 Linux 上通常是libhsa-runtime64.so它提供的是运行时 API例如能力典型 API发现设备hsa_iterate_agents枚举 CPU、GPU 等 agent内存管理各类 HSA 内存分配/映射 API队列与同步提交任务、信号量等超节点扩展hsa_ext_rpc_memory_create/attach/detachFabric 跨节点显存你们 aiter Fabric 模式里用的hsa_ext_rpc_memory_*就是 HSA Runtime 提供的扩展 API不是 aiter 自己定义的。和 HIP 是什么关系在 AMD/海光 ROCm 生态里可以粗略看成两层你写 kernel、跑算子↓HIP ← 类似 CUDA日常开发主要用这个↓HSA Runtime ← 更底层管 agent、部分内存/互联能力↓驱动 / 硬件HIPHSA Runtime角色GPU 编程接口写 kernel、malloc 显存异构系统运行时设备模型、底层互联类比CUDA比 CUDA Driver 更「系统级」的一层开发者经常直接写多数时候不直接写库/驱动会调在你们场景IPC 用hipIpcGetMemHandleFabric 用hsa_ext_rpc_memory_*所以IPC走 HIP 自己的同机显存句柄机制Fabric跨机时 HIP IPC 不够要借助 HSA Runtime 的 Fabric/RPC 内存扩展
