当 GPU 之间的通信占了 70% 的时间，算力翻倍还有用吗？

DeepSeek-V3 在 32 张 GPU 上跑 MoE 推理时，70.4% 的时间花在 GPU 之间传数据。不是算得慢，是算得快不起来——一半的带宽被同一条数据反复传输浪费掉了。

一篇刚刚被 ISCA 2026 录用的上海交大论文，盯上了这个被忽略了很久的痛点。他们提出了一种叫 DySHARP 的方案，把计算塞进 NVSwitch 交换机里，直接消除冗余传输，最高实现了 1.79 倍的加速。

这不是一个简单的性能优化。它指向了一个更大的问题：当 MoE 成为大模型标配架构，GPU 之间的通信瓶颈，正在变成 AI 算力基础设施中最关键的制约因素之一。

问题出在哪

MoE（Mixture of Experts，混合专家）架构的核心思路是：把前馈网络层拆成多个"专家"，每个 token 只激活其中一小部分。DeepSeek-V3、GPT-4、Llama 3、Qwen 等主流大模型都采用了这个架构。

训练和推理时，专家被分布到不同 GPU 上（专家并行，EP）。但问题来了：一个 token 激活的专家可能分布在远程 GPU 上，所以需要频繁地在 GPU 之间传数据。

传数据本身不是问题。问题是——传了很多不该传的。

有两类冗余：

第一，Dispatch 阶段。一个 token 需要发到 3 张 GPU，同样的数据从源 GPU 到 NVSwitch 交换机要传 3 次。交换机拿到这份数据后，再分别转发给 3 张目标 GPU。

第二，Combine 阶段。3 张 GPU 上专家的输出需要聚合回源 GPU。这些输出是累加关系，但现在是 3 份单独传回去，在源 GPU 上再做加法。

上海交大的团队在模拟 GH200 NVL32 系统上跑 DeepSeek-V3，测出来通信冗余占总流量的近 50%。激活的专家越多，冗余越大。

NVIDIA 不是没看到这个问题

NVIDIA 从 Hopper 架构开始在 NVSwitch 里集成了一个叫 NVLink SHARP（NVLS）的功能。简单说，就是在交换机里做计算——交换机不是只管转发，还能做数据聚合（reduce）和多播（multicast）。

这理论上正好能解决上面说的冗余。Dispatch 阶段，GPU 传一份数据给交换机，交换机多播给所有目标 GPU。Combine 阶段，交换机直接在内部做加法，只把最终结果传回去。

但现实是，NVLS 不支持 MoE。

因为 NVLS 是静态的——它要求通信模式固定、目标集已知、地址对称。而 MoE 的通信是动态的：每个 token 激活哪些专家是运行时决定的，目标集随时变化，每个 GPU 的数据要发到不同的地址。

用软件方案把 MoE 通信"伪装"成静态集合通信，结果更糟——会制造出 340% 的无用流量，直接把交换机内计算带来的好处吃光。

DySHARP 怎么做的

DySHARP 的核心思路是：既然 NVLS 是静态的，那就把它扩展成动态的。

第一项技术：动态多内存寻址（Dynamic multimem addressing）

这是 ISA、架构和运行时的协同设计。数据包里只携带一个多内存地址，加上一个轻量级的目标列表。每个 GPU 本地管理自己的内存，不需要全局对称寻址。交换机根据目标列表，把数据动态路由到正确的 GPU 地址。

这一项技术本身就能消除近一半的总流量。

但问题来了。

第二项技术：Token 级核心融合（Token-centric kernel fusion）

流量消除了，加速比却没跟上来。原因很微妙：Dispatch 和 Combine 的流量减少是不对称的。一个方向的带宽省了，另一个方向没省，整体带宽利用率反而不均衡。

DySHARP 的做法是把 Dispatch、计算、Combine 整个链路用 token 级的数据依赖串起来，形成一个流水线。不同 token 的通信模式是互补的——一个 token 在 Dispatch 方向省带宽，另一个 token 在 Combine 方向省带宽——合并在一起，整体带宽利用率就上去了。

两项技术缺一不可。光有动态寻址，加速不明显；光有核心融合，冗余还在。两者配合，才实现了最高 1.79 倍的加速。

为什么通信瓶颈越来越致命

这篇论文提到了一个很容易被忽略的趋势：NVIDIA Blackwell 和 Rubin 架构中，计算能力的增长速度远远快于通信带宽的增长速度。

换句话说，GPU 越算越快，但 GPU 之间的通道没跟上。MoE 的通信开销在总体执行时间中的占比，只会越来越大，不会越来越小。

这跟系统架构里的经典"Amdahl 定律"是一个道理。当一个系统的某一部分被持续优化得越来越快，瓶颈就会转移到没被优化的部分。在 AI 训练集群里，那个没被充分优化的部分，就是 GPU 之间的通信。

更具体地说，MoE 让计算变得稀疏（每个 token 只激活少量专家），但稀疏计算的代价是通信变得密集。你用 MoE 省下的算力，被通信开销吃掉了一大块。当通信占 70% 以上的时间时，你再把算力翻一倍，整体速度也只快了不到 30%。

交换机内计算的战略意义

DySHARP 最有价值的洞察不是技术方案本身，而是它点明了一个方向：加速 AI 基础设施，不一定只在 GPU 芯片上做文章。

过去几年的主流叙事是"更大的 GPU、更多的 HBM、更快的 NVLink"。但 DySHARP 的思路是：交换机不只是交换机，它可以成为计算的一部分。

这个思路其实有先例。SmartNIC、DPU、IPU 都在试图把计算从主机 CPU 移到网络侧。但 DySHARP 的不同之处在于，它瞄准的是 AI 训练/推理最核心的数据流——MoE 的 token 分发和结果聚合——而不是网络管理或安全卸载。

如果 NVSwitch 真的能原生支持 MoE 的动态通信模式，那意味着 NVIDIA 在交换机侧又多了一层护城河。其他 GPU 厂商要追赶，不仅需要做出对标的 GPU，还需要做出对标的交换机。

国内芯片公司的机会窗口

DySHARP 基于 NVIDIA 的 NVLink/NVSwitch 架构。但"交换机内计算"这个思路本身并不绑定特定硬件。

国内做 AI 加速芯片的公司，如果在互联架构设计时就考虑把计算能力嵌入交换机/互联层，而不是事后补救，可能会在 MoE 训练/推理场景中获得差异化优势。尤其是当 NVIDIA 的 NVLS 还停留在静态集合通信阶段时，动态版本的交换机内计算如果能先在国产互联方案中落地，就是一个不错的技术叙事。

当然，实现难度不小。这需要芯片架构、互联协议、编译器、运行时调度等多个层面的协同设计，不是单点优化能搞定的。但至少方向是明确的。

这也正是IC Agent Hub这类 AI 工具平台在芯片设计流程中可以发挥作用的地方——从架构探索到互联协议验证，工程师需要高效的工具链来加速方案迭代。关注回复「合作」，可以深入交流。

MoE 训练的成本压力

MoE 架构的卖点是"用更少的算力达到同样的效果"。但通信瓶颈让这个卖点打了折扣。

对于一个训练集群来说，如果通信占 70% 的执行时间，那意味着你买的大部分 GPU 算力在空转。DySHARP 的 1.79 倍加速，如果能在实际集群中复现，直接等同于训练成本砍半——这比任何算法优化都来得实在。

推理场景的价值可能更大

论文主要关注训练场景。但推理侧的 MoE 通信问题同样严重——甚至更值得关注，因为推理的延迟敏感性比训练高得多。

如果一个 MoE 推理请求的 token 需要在多张 GPU 之间反复传输，那 P99 延迟会被通信开销严重拖累。交换机内计算如果能在推理路径上消除这些冗余传输，对推理延迟的改善可能比训练场景更明显。

对 EDA 工具链的启示

DySHARP 是 ISA、架构和运行时的协同设计。这意味着芯片设计流程中，互联架构和通信原语的验证复杂度会进一步上升。

传统的 EDA 工具在验证计算核心时已经够复杂了。当交换机也成为计算单元，验证范围就从"芯片内部"扩展到了"芯片间互联"。这对形式验证、性能仿真、通信覆盖率分析都提出了新的要求。

交换机内计算会成为标配吗

NVIDIA 在 Hopper 中引入 NVLS，在 Blackwell 中继续增强，再加上这篇论文指出的方向，趋势已经比较清晰：未来的 AI 集群互联架构，交换机一定不只是交换机。

但 NVLS 目前还是静态的。要让它支持 MoE 这种高度动态的通信模式，NVIDIA 需要在架构层面做更大的改动。DySHARP 提供了一个可行的技术路径，但 NVIDIA 是否会采纳、何时采纳，是另一个问题。

这篇论文的价值不在于 1.79 倍的加速数字——虽然这个数字本身已经足够亮眼。

它更大的价值在于提醒了一件事：当所有人都盯着 GPU 芯片本身的算力时，GPU 之间的那根线，可能才是下一个真正的瓶颈。

而解决这个瓶颈的方法，不一定是把线加粗，而是让线上的交换机也能算。

如果你对 AI+芯片设计工具链感兴趣，或者正在探索芯片研发流程自动化，关注回复「合作」，可以深入交流。IC Agent Hub支持 SaaS 体验与私有化部署双模式，欢迎来聊。

作者：麒芯

参考来源：arXiv:2605.05607 (ISCA 2026)、DeepSeek-V3 论文

本文基于公开论文整理分析，不构成任何投资建议。

加入 IC Agent 技术交流群

群里聚集了芯片设计工程师、IT/CAD 负责人和 AI+EDA 从业者，聊技术、聊工具、聊行业趋势。

关注回复「加群」，拉你进群一起聊

关注回复「合作」，如果你在做 AI+ 芯片/EDA 相关，欢迎来聊

后续会持续更新这个系列，关注不迷路。