超稀疏模型技术 ¶

以 Mixture-of-Experts（MoE）为代表的稀疏激活架构，承接的是第五章里“哪些变量会先改写通信模式”这条主线。DeepSeek-V3/R1（671B 总参数、37B 活跃参数）和 Qwen3-235B-A22B 等模型表明，通过稀疏激活可以在大幅扩展模型容量的同时控制单次推理的计算量，但代价是对互联拓扑、内存布局与调度系统提出了截然不同的要求。

因此，本节关注的不是参数量还能做多大，而是当通信从规则同步转向不规则路由后，第四章各类参考设计会如何被重新排序。面向超节点架构，超稀疏模型技术的影响可以从以下维度考察：

• All-to-All 通信与拓扑约束：MoE 的 Expert Parallelism 本质上是一个 All-to-All 通信问题——每个 token 需要被路由到分布在不同卡 / 节点上的专家。这对 Scale-Up 域的双向带宽与延迟提出了比传统 AllReduce 更苛刻的要求，尤其是当专家数量从 8 扩展到 256+ 时，通信模式从 " 少数对少数 " 变为 " 多数对多数 "，拓扑对称性与非阻塞特性成为关键。
• 负载不均衡与动态调度：稀疏路由天然导致专家间的负载不均衡（某些专家被频繁激活，其余处于空闲），这在硬件层面表现为部分卡的计算 / 通信满载而其余卡闲置。负载均衡策略（辅助损失、容量因子、动态路由）需要与硬件的 QoS 机制和调度器协同设计，否则理论上的稀疏计算优势无法转化为实际的 Goodput。
• 内存布局与缓存策略：每个专家的权重需要常驻或可快速加载到计算设备。当专家数量很大（如 256 个）且模型总参数远超单卡 HBM 容量时，专家权重的放置策略（全部常驻 vs 按需换入 / 缓存）直接影响推理延迟和吞吐。这与内存池化、分层存储以及 KV Cache 管理之间存在资源竞争，需要统一的内存管理框架。

接下来最需要补上的，是 MoE 模型在不同并行策略下的通信量与拓扑适配分析、负载不均衡对实际 GPU 利用率的影响量化，以及专家缓存与权重管理的工程实践。

对参考设计的影响 ¶

超稀疏模型技术对第四章参考设计的影响最直接，因为它会把通信模式从 AllReduce 主导改写为更频繁的 All-to-All 与动态负载均衡问题：

• 标准构型 若缺乏足够的带宽弹性与调度能力，在专家路由压力上更容易提前触顶。
• Dragonfly + OCS / Torus + OCS 这类探索构型，会因为更强的拓扑弹性和更短的路径潜力，在大规模专家并行场景下获得更高战略价值。
• 所有方案 都会被迫重新评估 " 互联带宽够不够 " 之外的另一层问题：尾延迟、负载不均衡与专家缓存是否能被系统软件稳定控制。

MoE 属于已验证趋势，但其对参考设计优先级的影响强度，仍需要产业界实测来校准。最需要补充的证据，包括领先模型在真实部署中的专家路由分布、不同并行策略的通信热图、负载不均衡对 GPU 利用率和 Goodput 的影响，以及专家权重缓存 / 换入的实际代价。

MoE 的战略意义，不只是“用更少计算承载更多参数”，而是把超节点最敏感的互联问题从规则同步，改写为不规则路由、动态负载和尾延迟控制。它会让一部分今天仍然成立的参考设计，在未来 2–3 年里因为通信模式变化而重新排序。它在第五章中的位置，也因此不是单纯的模型技巧，而是会改写系统边界的未来变量。