打破AI大模型时代的GPU通信“竖井”

随着人工智能(AI)大模型在技术深度与应用广度上的持续突破，GPU 集群的通信效率已成为制约算力充分释放的核心瓶颈，其重要性随模型规模扩张愈发凸显。当前的通信库生态呈现出“竖井”式的困局：厂商生态碎片化、新硬件适配成本高昂、上层应用重复造轮。为解决上述问题，ODCC联合中国信通院、腾讯、快手、美团、百度、京东、博通、AMD、海思网络、燧原科技、壁仞、海光信息、沐曦、云豹在2025ODCC开放数据中心大会共同启动“OpenUCL”社区。

在 2025ODCC 网络组分论坛上，腾讯基础网络中心副总监文权首次深度揭秘了 OpenUCL 的核心内容。本文将结合该分享详细解读 OpenUCL 的设计理念、核心架构与未来规划。OpenUCL旨在打造一个统一、高效、开放的 GPU 通信库，将 GPU 通信从“专属”变为“共享”，加速AI模型的创新与落地。

文权

腾讯基础网络中心副总监

困局与挑战—当前 GPU 通信库为何艰难险阻

1.1

模型发展日新月异，通信行为持续演化

AI 模型的发展深刻地改变了底层的通信模式，单一的通信库已无法满足多样化的需求。

1） 传统集合通信库：主要为传统科学计算和早期深度学习模型的并行训练设计，聚焦于All-Reduce、All-Gather 和 Broadcast 等标准集合通信操作。

2）面向MoE的通信需求：以 Mixture-of-Experts (MoE) 为代表的新型模型，其通信模式以高频次和细粒度的 All-to-All 通信为主，这对通信库的调度和执行能力提出了全新挑战。为此，业界出现了如 DeepEP 这样的专用通信方案，专注于大规模专家并行(Expert Parallelism)场景。

3） 面向推理的通信需求：在推理场景中，Prefill (P) 与 Decode (D) 阶段的分离已成常态，以追求极致延迟优化。这两个阶段频繁交互的核心在于 KV Cache 的动态传输：Prefill 阶段需高效加载初始 KV Cache(批量传输)，而 Decode 阶段则需持续同步更新后的 KV Cache(高频小包传输)。正是这种 KV Cache 在 P/D 间的高频、差异化传输需求，亟需像 NIXL 这样的通信库进行针对性优化。

通信需求的多样化导致了通信方案的碎片化，开发者需为不同模型维护不同的通信栈。

1.2

新增 XPU 卡“即插不即用”，生态适配成本高昂

理想情况下，新增一款 XPU(通用计算处理单元，泛指 GPU 等加速卡)应能无缝接入现有系统，但现实却面临多重挑战。一是 厂商库并非“开箱即用”。无论是 NVIDIA 的 NCCL、AMD 的 RCCL 还是其他厂商的通信库，都需要经过长时间的适配、移植和功能增强，才能真正满足复杂业务场景的需求。二是“竖井”式的技术栈。XPU 卡、底层驱动(如 CUDA/CANN/ROCm)和上层集合通信库由各厂商牢牢掌控。基于 A 厂商硬件的深度优化和适配经验，几乎无法复用到 B 厂商的硬件上，每次引入新硬件都意味着一次从零开始的移植和漫长的性能调优过程。三是管理维护成本高。在拥有多种硬件和多种应用的复杂环境中，通信库的数量呈爆炸式增长(应用数量 × 厂商数量)，导致管理和维护成本居高不下。四是能力参差不齐。各厂商通信库的性能、功能和运营支撑能力(如监控、调试)差异巨大，无法为上层业务提供统一、稳定的服务体验。

1.3

“竖井”困局：重复造轮与高昂的定制代价

当前 GPU 通信库生态正深陷 “竖井式困局”。不同厂商、不同类型的 XPU 服务器，其硬件架构与互联协议各成体系，直接造成通信库的实现千差万别，既无统一标准可循，也缺乏通用抽象层支撑。

这种局面带来的现实困境尤为突出：若业务场景需要一项定制化通信优化 —— 比如新增一个专用通信算子，技术团队就不得不针对每一款硬件平台、每一种通信库，从零开始单独开发、反复适配。如此一来，不仅开发成本与维护代价高到难以承受，更像一道无形的枷锁，严重桎梏着技术创新的脚步。

2.

破局之道——OpenUCL 的统一架构与设计理念

为了打破“竖井”，我们设计并推出了 OpenUCL，一个旨在统一和解耦的全新架构。

2.1

OpenUCL 的形态与展望

OpenUCL 的解决思路：

1）统一 CCL/CL 接口层：通过定义统一的 CCL(Collective Communication Library)/CL(Communication Library)接口，让业务侧获得无差别算子服务。

2）解耦核心逻辑（服务层）：将通信算法与硬件传输实现解耦，打造可复用的核心服务层，实现算法与传输层的深度复用。

3） 统一抽象层与接入规范：定义标准化的异构抽象层接口(UCLAI - Unified Communication Library Abstraction Interface)，让厂商专注硬件和驱动优化，降低适配门槛。

预期收益与重大意义：

1）效率提升：新通信算子的开发周期将实现突破性缩短，从原本的数月大幅压缩至数周乃至数天。

2） 开箱即用：拉齐 XPU 的通信能力，实现接近“开箱即用”的体验。

3） 支持异构：原生支持异构卡(不同厂商)的混合训练与混合推理通信。

4）开放生态：为通信库开发者打造开放协作的家园，使其无需深陷各厂商的技术细节，能够聚焦核心创新，共同参与生态的贡献与发展。

OpenUCL 的重大意义在于：借助统一接口与抽象设计，彻底消除生态碎片化的障碍，让 GPU 通信从 “专属壁垒” 转变为 “共享资源”，进而全面加速整个 AI 领域的技术创新与产业落地进程。

2.2

核心架构：OpenUCL 接口抽象层（UCLAL）定义

UCLAL (OpenUCL Abstraction Layer) 是 OpenUCL 的基石，它定义了三类标准接口：

1） 通信统一接口：提供标准化通信原语接口(如 Send、Recv、All-Reduce 等)，上层服务与应用可直接调用，无需关注底层硬件差异。

2）通信资源统一接口：实现对通信资源(包括通信器、流、事件等)的统一管理，为上层提供细粒度控制能力，支撑复杂场景下的调度策略与性能优化。

3）运维统一接口：内置通信原生的性能监控与遥测功能，可实时暴露关键性能指标与状态信息，为高效故障定位和深度性能分析提供支撑。

2.3

核心架构：核心服务层举例

在 UCLAL 中，OpenUCL 构建了功能丰富的服务层，这些服务可被上层应用复用。

1） Bootstrap 服务：负责在分布式任务启动时，帮助所有参与节点建立一个全连接的管理网络。它提供基础的通信原语，支撑初始化过程中的信息同步和流程对齐，是构建任何大规模通信任务的第一步。

2）拓扑发现服务：具备自动探测与建模能力，可精准识别系统中的硬件单元(GPU、交换机、网卡等)及其物理连接，并构建一个带权重的拓扑图。这个拓扑图精确描述了系统的连接关系和通信能力(带宽、延迟)，上层应用可以基于此图选择全局最优的通信路径和算法，实现通信性能的极致优化。

3）连接管理服务：采用分层设计，针对机内、机间不同通信场景提供专属解决方案，精准匹配性能需求。其中机内连接模块 (P2PConnector)聚焦节点内部 GPU 间通信资源构建，通过 NVLink、PCIe 等硬件优化路径建立点对点连接，实现机内通信的 “高带宽、低延迟” 突破。机间连接模块(NetConnector)专注集群节点间通信资源管理，通过网络连接优化、资源动态调度等能力，有效支撑大规模集群的线性扩展，保障跨节点通信的稳定性与效率。

3.

未来之路——OpenUCL 的关键路标与社区共建

OpenUCL 项目并非停留在概念阶段，已经完成了详细的可行性分析，并已正式启动实施。为确保项目有序推进，制定了清晰明确的发展路线图。未来将按计划逐步发布关键版本，并基于社区反馈持续迭代优化，不断完善技术体系与功能体验。

我们深知，一个开放标准的成功离不开整个社区的共同努力。在此，我们诚挚地邀请广大 AI 开发者、系统工程师、硬件厂商以及研究机构加入我们，共同建设 OpenUCL 生态。

联系方式：

王老师，13701380040 wangshaopeng@caict.ac.cn

孙老师，15732071244 suncong@caict.ac.cn

ODCC秘书处联系人

刘老师 13488889649(微信同号) 邮箱：liupengyun@caict.ac.cn