你要给一群厨师安排晚宴。只按“总共切了多少菜”来排班，可能会选出一份纸面上很漂亮的方案：厨师分工极细，每个人只处理一道工序。但真开工后，食材在工位之间来回传递，大家不断等待，晚宴反而更迟。
训练混合专家模型也有类似问题。混合专家模型（Mixture-of-Experts，MoE）在模型里放入许多“专家”子网络，每次处理一个词元——也就是模型读写文本时使用的基本单位——只调用其中少数几个。它像医院分诊：科室很多，但一位患者不必看遍所有科室。这样可以扩大模型的总容量，同时压低每次实际执行的运算量。
问题在于，专家通常分散在多块加速器上。模型越稀疏，也就是每次闲置的参数比例越高，纸面计算可能越省；数据搬运、跨设备通信和相互等待却可能越严重。论文《Compute-Optimal Is Not Cluster-Optimal》提出 MOSAIC，把预测模型效果的规模定律与真实集群的性能模型接在一起。作者想回答的不是“给定运算量，数学上该选多大的模型”，而是“给定一套集群和训练时间，哪种模型真能训练得最好”。下文的数字和效果判断均来自 Soumajyoti Sarkar、Yuxin Tang 与 Sheng Zha 的这篇论文，尚无第二个独立信源交叉验证。
旧账本漏掉了什么？
规模定律是一类经验公式，用来估计模型、训练数据和计算量增加后，训练损失会怎样变化。训练损失可以粗略理解为模型预测得有多不准，通常越低越好。团队拿到固定计算预算后，常先用规模定律决定模型大小和训练数据量，再单独调整并行方式，让它适配硬件。
这相当于先设计菜谱，再问厨房能不能做。两步各自合理，接缝处却可能出问题。
传统账本常用 model FLOPs，也就是模型按数学定义需要完成的浮点运算量。对 MoE 来说，它主要跟每个词元实际激活的参数有关。然而，两种 model FLOPs 相同的架构，上机后的速度可能相差很大。专家数量、每次调用几个专家、单个专家多宽，不只影响训练损失，也会改变显存占用和通信方式。
论文特别关注模型 FLOPs 利用率（Model FLOPs Utilization，MFU）：芯片实际用于完成模型运算的速度，占理论峰值的比例。MFU 低，说明机器可能在传数据、等内存或等其他设备，而不是持续做有效计算。模型在纸面上省下来的运算，不一定会变成墙上时钟里的时间。
MOSAIC把两本账合成一本
MOSAIC 联合选择三件事：具体的 MoE 架构、训练词元数量，以及分布式执行方案。执行方案决定模型怎样切到多块设备上，包括张量、专家、流水线和数据等并行布局；也包括微批次大小与是否用激活检查点——用额外重算换取显存空间的技术。
它由两部分组成。第一部分是四维 MoE 规模定律，用模型总参数、训练数据、稀疏度和 expert split factor 预测损失。expert split factor 指一个原本完整的前馈网络被切成多细的专家；切得越细，专家越小、数量可以越多。
第二部分是性能模型。它从算子层面估计一次前向与反向训练的耗时，并预测 MFU、通信成本、内存占用以及最佳并行布局。模型还使用目标硬件上的微基准测试数据，例如矩阵乘法、MoE 专家计算和集合通信的实测效率。作者强调，性能模型在测量范围内插值，不静默外推到没有测试过的区域。
最后，MOSAIC不再把可用计算量视为与架构无关的固定数字。它计算“可交付的 model FLOPs”：一套集群在给定训练窗口内，扣除利用率损失后，真正能完成多少有效模型运算。于是，一个通信太重、显存放不下或并行布局低效的架构，会直接在规模选择阶段付出代价。
越稀疏，为何不再总是越好？
作者用于拟合规模定律的模型覆盖 1.04 亿至 27 亿活跃参数，总参数量最高达到 790 亿。活跃参数是每个词元实际调用的部分；总参数还包括当次没有参与计算、但仍需存储的专家。
在作者校准过的稀疏度范围内，如果预算只计算 model FLOPs，拟合损失会随着模型变稀疏而单调下降。换句话说，这本账找不到一个位于测试范围内部的最佳稀疏度，所谓最优点一直被推到数据支持范围的上边界。
这不是“模型越稀疏越好”的普遍定律。恰恰相反，最优点撞上数据边界，说明原来的预算没有给某些成本标价，也不能据此继续向更高稀疏度外推。
把集群约束加入后，情形改变了。更多专家可以增加模型容量，但也会抬高内存压力；更细的专家可能有利于损失，却会形成许多较小的计算任务，降低硬件利用率；专家路由还需要跨设备发送和汇合数据。收益与代价开始真正相交，于是出现一个位于范围内部、针对具体集群的最优稀疏度。
论文给出的一个实例使用 4 个 p6-B200 节点、训练 5 天。在这套硬件条件下，按原方案继续增加稀疏度会变得不可行；重新优化得到的集群最优配置，其预测损失比 model FLOPs 最优的边界配置低 0.031 nats。nats 是用自然对数计量损失的单位。这个数字来自作者的模型与基础设施，不应直接搬到其他集群。
为什么这件事值得关注？
MOSAIC最重要的提醒很朴素：训练预算不能只写“总共做多少运算”，还要写这些运算由哪套机器、以什么效率、在多长时间里完成。
这对 MoE 尤其关键。稀疏激活把“模型拥有多少参数”和“每次使用多少参数”拆开了，也让通信、内存与并行策略进入架构选择。论文甚至观察到，在固定 GPU 小时预算下，损失最低的配置并不是输出 model FLOPs 最多的配置。多做纸面运算，不等于把硬件预算花得更有效。
因此，作者主张把架构设计和训练系统协同优化。它不是训练完成后的性能调优，而是在决定模型长什么样时，就把厨房的门宽、灶台数量和传菜速度算进去。
局限与未知
- 所有结论目前都来自同一篇论文。材料未给出完整实验表格、全部误差范围、训练词元数、基线对比或外部复现，不能判断 MOSAIC 相对传统流程的普遍收益幅度。
- “系统约束下存在最优稀疏度”依赖具体硬件、网络拓扑、并行策略和性能模型校准。不同集群不会共享一个固定答案。
- 规模定律只在作者覆盖的数据范围内得到校准。边界上的趋势不能证明更高稀疏度仍会带来更低损失；论文也把测试时的硬件成本留作未来工作。