在开源力量的推动下，大模型创业公司和互联网大厂的关系，不再是非此即彼，而是相互协作的关系。
近日，DeepSeek工程师在GitHub上高亮了来自腾讯的代码贡献，并用“huge speedup”介绍了大模型网络提速技术方案详情。在鹅厂的帮助下，DeepSeek开源的网络通信神器DeepEP性能再上新台阶。
DeepSeek公开致谢，经腾讯技术团队优化的DeepEP，实现了多种网络环境下的性能提升。经测试，优化后的通信框架性能在 RoCE 网络环境提升 100%，IB 网络环境提升 30%，可以为企业开展 AI 大模型训练提供更高效的解决方案。
DeepEP通信框架背后的性能瓶颈
那么，腾讯到底贡献出一项什么技术，让AI圈如此兴奋？说来话长，此事还要从今年2月份开始追溯！
众所周知，DeepSeek从今年年初爆火。那个时候，DeepSeek开源了包括
DeepEP在内的五大代码库，揭秘了他们如何用1/5硬件资源实现传统万卡集群效能的核心技术。其中，
DeepEP作为突破NCCL性能瓶颈的
通信框架，通过300%的通信效率提升，成功让众多MoE架构的大模型摆脱了对英伟达NCCL的依赖。但这项技术有一个痛点，那就是在成本较高的InfiniBand（IB）专用网络中如鱼得水，却难以适配更普适的RoCE网络环境。有一个形象的比喻是，DeepEP当时的境遇就像一个超级酷的跑车，但只能在专业赛道驰骋，开上普通公路就性能缩水，这让大多数使用普通网络的企业机构面对DeepEP往往看得着、用不上。
之后，DeepEP在Github主页上非常坦诚地介绍了其应用的难点，也出现了关于RoCE网络环境中性能表现不佳的讨论，但相关问题一直没有找到理想的解法。但腾讯在RoCE网络领域可以说是“老司机”，基于多年调教数据中心和GPU通信沉淀下来的TRMT技术，可以提供更卓越的优化方案。
RoCE网络实现性能翻倍
鹅厂的出手，就像华佗的“妙手回春”之术，通过“望闻问切”四步法实现了“对症下药”。腾讯技术团队迅速找到两个关键突破点：1）车道利用率低下；2）CPU控制瓶颈。
进一步的理解是，在通路问题上，RoCE网卡普遍采用双端口架构，但既有系统无法智能分配流量，常出现单车道拥堵、双车道闲置的窘境，就像快递公司面对双向八车道却只使用一侧车道。 而在CPU控制上，虽然DeepEP通过RDMA技术实现了GPU直连通信，但在控制面交互层面仍依赖CPU中转，存在时延和能耗优化空间。
如何解决？腾讯技术团队分三步法逐一攻破：1）让双车道充分利用，构建拓扑感知的多QP建链；2）进一步绕过CPU，基于 IBGDA 的多 Channel 负载均衡数据传输；3）排好队不出错，实现原子化信令协同。
具体做法是，在 AI 模型启动时，多个 GPU 之间会建立通信组。每个 GPU 组内，GPU 之间都要建立通信链接，并且每个 GPU 对需要建立多组 QP（队列对）。而通过动态分配起始匝道口（UDP源端口），可以确保双车道物理通道（网卡端口）的车流均衡，从根本上避免了多车队汇入同条车道引发的堵塞，让双端口网卡带宽利用率达到理论峰值。针对CPU瓶颈，腾讯基于IBGDA（InfiniBand GPU Direct Accelerator）技术，让控制面场景的CPU也绕过了，控制时延降低至硬件极限。同时，腾讯还让每个 GPU 都能同时用多个“通道”来发送数据，而且这些通道会自动分配数据，不会让某个通道太忙而其他通道闲着。另外，在GPU直接通信时还存在一个关键难题：当A GPU直接把数据写入B GPU内存时（类似隔空投送），B GPU并不知道数据何时到达。如果多个数据传输任务同时进行，可能会发“先发的包后到”的混乱情况。腾讯工程师提出了一种叫做“QP内时序锁”机制，类似一种智能快递签收机制：每次传输数据时，通过网卡硬件自动生成数字指纹（类似快递单号加密），收件方必须按正确顺序“签收”。现在，就算同时处理1000多个数据传输任务，系统也能自动理顺先后顺序。
▲腾讯工程师在不同节点服务器上的测试数据
一系列操作下来，让DeepEP性能直接“捅破天花板”。不仅在
RoCE网络上实现性能翻倍，当DeepSeek将这套方案反哺到IB网络时，原本已经很优秀的
通信效率竟然又提升了30%。目前该技术已全面开源，并成功应用于腾讯混元大模型等项目的训练推理，在腾讯星脉与H20服务器构建的高性能环境中，这套方案同样展现出卓越的通用性。
结语：
DeepSeek和鹅厂的合作，引起技术圈的广泛讨论。有人夸赞鹅厂的格局大，技术实力强，有人认为是AI平权让高质量AI不再是互联网巨头的专利……无论哪种说法，其实都在说明同一个事实，那就是开源的潜力无限。在开源生态助力下，无论是大厂，还是创业公司；无论是国内，还是世界级企业，都在向同一个方向努力，那就是让AI变得更加普惠，所有企业都希望抓住这波发展机会，实现弯道超车的目标。
