算力架构的真正战场:不是更快,而是谁掌握路由权

Kevin Di

Hatched by Kevin Di

Jun 22, 2026

1 min read

87%

0

当“专家”越多,系统为什么反而越像一场权力分配

很多人第一次看到 MoE,会以为它的核心问题是“怎么把更多参数塞进去,还不把推理拖慢”。这当然没错,但真正有意思的地方不在参数规模,而在路由权。谁来决定每个 token 去见哪位专家,谁就决定了模型的计算路径、资源分配、训练稳定性,甚至决定了系统最后是像一个高效组织,还是像一群互相抢活的部门。

这件事和数据中心硬件世界惊人地相似。PCIe、NVLink、CXL、GPU Direct、P2P、Host memory,看上去是在争带宽、协议和拓扑,实质上争的也是一件事:数据和算力到底围绕谁组织。是围绕 CPU 这个中心协调者,还是允许设备形成自己的自治网络?MoE 的门控网络和数据中心互联协议,其实都在回答同一个更深的问题:系统究竟要不要一个绝对中心

真正的性能瓶颈,往往不是“算得不够快”,而是“谁有资格决定路径”。


MoE 不是“更多专家”,而是“更复杂的组织形式”

从表面看,MoE 只是把一个大 FFNN 拆成多个专家,让路由器按 token 选择其中几个参与计算。稀疏 MoE 选择少数专家,密集 MoE 则让所有专家都参与,只是权重不同。可一旦你把它想成组织结构,就会发现它并不是“模型结构的小改良”,而是把单一流水线变成分工协作网络

Dense 模式像是一个委员会,所有专家都参与讨论,只是发言权不同。Sparse 模式更像是一个值班调度系统,只有少数部门会被叫起来处理当前任务。前者的优势是协调容易,后者的优势是成本更低,代价则是更容易出现拥塞、偏置和训练不稳定。于是门控网络就变成了整个系统的治理核心,它不是简单的“筛选器”,而是分配稀缺计算资源的仲裁者

这也解释了为什么负载平衡损失如此关键。若不额外约束,某些专家会被频繁选中,另一些专家长期闲置。表面上看,这是“模型没有学会分工”,本质上却是一个典型的组织失衡问题:最容易被调用的部门越来越忙,最有潜力的部门没有机会成长。所以辅助损失并不是一个小技巧,它是在强行给组织结构加上反垄断机制。

尤其值得注意的是,很多人会把专家可视化理解成“把一个隐藏层切成几块”,但现实里专家往往本身就是完整的 FFNN。这意味着 MoE 不是简单的切分,而是复制了多个完整的处理单元,再由路由器来调度。换句话说,MoE 的核心不是“拆分计算”,而是在复制出的计算能力之间建立选择制度


数据中心里的同一场戏:中心化控制与局部自治的拉扯

如果把 MoE 的门控网络放大到硬件层,你会发现数据中心一直在演同一个故事。PCIe 的演进、GPU 的独立内存、NVLink 的私有互联、GPU Direct 的绕过 CPU、CXL 对 host 中心的坚持,本质上都是围绕“谁来做总调度”展开的权力斗争。

传统 PCIe 体系的设计,天然让 CPU 成为中心。设备可以挂在总线上,但真正的路径控制、地址管理、内存协调,还是要经过 host。GPU 的崛起打破了这种秩序。CUDA 让 GPU 拥有私有内存,要求 CPU pin 住 host DDR,还把大量原本属于 CPU 的调度和内存分配工作搬进 GPU 自己内部。结果就是,GPU 不再只是一个外设,而像一个在 CPU 旁边建立起来的独立王国

这时,带宽不只是带宽,协议不只是协议,它们直接决定了这个王国能否扩张。PCIe 若迟迟不提速,GPU 的能力就被束缚,NVIDIA 只能转向 NVLink,建立自己的高速互联体系。但 NVLink 又要求额外板级支持,难以普及,所以又催生了在 PCIe 上继续挖潜的 GPU Direct,试图绕过 CPU,直接让 GPU、SSD、RDMA 设备彼此通信。

这就像 MoE 里的稀疏路由。你可以把中间协调层拿掉,让参与者直接连接,但一旦这么做,就必须为新的局部自治付出代价:拓扑更复杂,失衡更容易出现,调试更难,稳定性更脆弱。于是另一股力量出现了,CXL。它看上去温和、简单、兼容,但本质上是一次对中心秩序的重申:所有设备交互都尽量经由 host memory,直通和旁路被有意压缩

看似在谈互联协议,实际上是在决定系统的政治结构。

CXL 的聪明之处,不在于它最激进,而在于它最可部署。它让现有 PCIe 设备和交换芯片只需有限改动就能进入新秩序,同时重新巩固 host CPU 作为一致性中心的地位。它不是简单地增加自由度,而是用一种更精致的方式恢复可治理性。这与 MoE 中的辅助损失极其相似:真正有用的机制,往往不是最大化局部自由,而是让自由发生在可控框架内


一个更深的统一视角:MoE 和互联协议都在解决“协调成本”

如果只看性能数字,我们很容易把这些技术看成不同领域的巧合。但把它们放在一起,会出现一个更统一的框架:计算系统的核心难题,从来不是单点算力,而是协调成本

可以把任何复杂系统想成三层:

  1. 生产层,谁真正干活,例如专家 FFNN,GPU 核心,SSD,RDMA 设备。
  2. 路由层,谁决定任务去哪,例如门控网络,PCIe 拓扑,NVLink 互联,CXL 一致性机制。
  3. 治理层,谁控制系统是否稳定,例如辅助损失,host CPU,负载均衡策略,内存一致性协议。

MoE 的难点,不是把专家堆起来,而是让路由层足够聪明,让治理层足够稳。硬件互联也是一样,不是把带宽堆高就结束了,而是要回答:设备之间如何交换,谁负责地址一致性,谁承担协调开销,谁拥有最终解释权。

这就是为什么“稀疏参数,密集加载,稀疏激活”这一特征如此重要。MoE 在训练和部署之间做了分裂:所有专家都要加载进显存,但推理时只激活一部分参数。表面上这是资源优化,深层上则是把“存在”和“参与”拆开了。很多现代系统其实都在这么做。GPU、CXL、NVLink、RDMA 也是在拆分“设备是否属于系统”和“设备是否参与本次事务”。

这类设计的本质,是把系统从“统一执行”改造成“按需协作”。统一执行容易理解,也容易治理,但扩展性差。按需协作更高效,却必须解决两个问题:谁来分配参与资格,谁来约束参与冲突。MoE 的门控网络和负载平衡损失,正是这一难题的机器学习版本。PCIe/CXL/NVLink 的互联体系,则是这一难题的硬件版本。


为什么“最优架构”通常不是最自由,而是最会限制自由

直觉上,我们总觉得性能来自更多自由度:更多专家、更多直通、更少中心、更少阻塞。但系统工程里常常相反。能长期工作的架构,往往是那些精确限制自由的架构

Switch Transformer 通过简化架构和训练过程提升稳定性,这一点很重要。它告诉我们,MoE 的真正挑战不在于是否能动态选择专家,而在于这种动态选择是否会失控。硬件世界也是一样。NVLink 带来更直接的设备自治,但它的部署成本更高。GPU Direct 绕开 CPU,提升性能,但系统复杂度也急剧上升。CXL 则通过坚持 host 中心,换来更强的一致性和更低的部署摩擦。

这可以形成一个很实用的判断标准:

  • 自由度越高,局部效率越可能提高
  • 自由度越高,协调成本也越可能指数级上升
  • 真正优秀的系统,不是把自由度开到最大,而是把自由度锁在正确的边界里

把这个判断放回 MoE,就能解释为什么路由器和负载平衡如此关键。一个好的 MoE,不是让每个 token 任意找专家,而是让 token 在足够灵活的同时,不把某些专家压垮,也不让另一些专家长期闲置。把它放回数据中心,也能解释为什么 host-centric 的一致性设计总有市场,因为很多真实系统宁愿少一点自治,也要换来更少的故障、更低的调试成本和更清晰的责任边界。

架构设计的成熟标志,不是“能不能让一切都去中心化”,而是“能不能只在该去中心化的地方去中心化”。


Key Takeaways

  1. 把 MoE 理解成组织治理,而不是参数拼装。 门控网络决定的不只是计算路径,更是资源分配与专家成长机会。

  2. 警惕“性能提升”背后的协调成本。 更高的自由度和更少的中心化,往往会带来更复杂的负载均衡、稳定性和调试问题。

  3. 用“三层模型”看系统:生产层、路由层、治理层。 任何复杂系统的瓶颈,通常出现在路由和治理,而不只是生产能力本身。

  4. 优先寻找“可控的自治”,而不是绝对自治。 无论是 MoE 还是硬件互联,最可持续的设计通常是在局部自治与全局一致性之间找到边界。

  5. 评估架构时,问“谁拥有路由权”。 这比单纯问“谁更快”更能揭示系统的真实性能上限。


结语:未来的竞争,不是谁更像神经元,而是谁更像制度

MoE 和数据中心互联看似分属两个世界,一个属于模型内部,一个属于系统基础设施。但它们共同指向一个越来越重要的现实:现代计算的决定性能力,不只是更强的单元,而是更好的协调制度

神经网络正在从单一路径的密集计算,走向多专家、多路径、多约束的治理型结构。数据中心也正在从单一中心总线,走向混合式互联、局部直通、以及重新定义一致性的复杂体系。未来真正拉开差距的,不会只是芯片更快、参数更多,而是谁能设计出更稳定的路由规则,更合理的负载分配,更聪明的边界控制。

所以,下次当你听到某个系统“更快了”,不妨追问一句:它只是算得更快,还是把路由权重新分配得更好了。很多时候,答案决定了它是一次性能优化,还是一次架构升级。

Sources

← Back to Library

Hatch New Ideas with Glasp AI 🐣

Glasp AI allows you to hatch new ideas based on your curated content. Let's curate and create with Glasp AI :)

Start Hatching 🐣