MoK揭秘：NVL72上大规模MoE训练工程方案深度解读-北京尧图网络

这篇论文出来之后我第一时间翻完了全文。标题里的“Mixture-of-Kittens”确实会让人多看两眼但真正让我停下来的反而是后半句——“NVL72 上的 MoE 训练巨核 MoK”。翻译一下就是在一个 72 卡规模的 NVLink 域里做大规模 MoE 模型的训练然后他们把这一整套设计叫作 MoK。 MoE 本身不是什么新鲜话题稀疏专家模型这些年已经成了超大模型的主流解法。但真正在工业级集群上把 MoE 训练跑稳、跑满、跑出性价比依然是让人头疼的事。尤其是你要在单一 NVLink 域里塞下巨大的专家表让 token 路由不乱、让矩阵乘法吃满算力、让通信不成为瓶颈任何一个环节掉链子整周的训练任务就得重来。这篇论文的价值就在于它给出的不是花哨的数学创新而是一套可以在真实硬件上执行的工程方案。这篇解读适合两类人一类是正在做大模型训练、对 MoE 架构感兴趣但还没上过大规模集群的算法工程师另一类是已经跑过 MoE、但被负载不均衡、通信瓶颈、kernel 开销折磨过的训练系统工程师。我会把论文里的核心设计拆开结合我自己的训练经验讲清楚它的动机、做法、参数选择和容易踩的坑。1. MoK 到底在解决什么问题1.1 MoE 训练的三个老大难先对齐一下基础。MoE 模型的核心是把 Transformer 里的 FFN 层换成多个并行的专家网络每个 token 进来之后由一个门控网络router挑选最合适的若干专家来计算。这样一来理论上可以在不增加太多计算量的情况下把参数量做得非常大。但这个机制放到真实训练里问题立刻暴露。第一是通信开销。token 被路由到不同专家所在的设备上就要把 token 的激活信息从原设备搬到目标设备。这就是经典的 all-to-all 通信。专家数量越多、模型越大通信就越重。很多 MoE 训练在扩展专家数时算力利用率不升反降原因就在这里。第二是负载不均衡。router 很容易产生“热门专家”和“冷门专家”。热门专家显存不够用冷门专家闲着没事干。如果不去管它训练曲线会变得非常不稳定。第三是 kernel 效率。MoE 的专家数量一多每个专家分到的 token 数量就显得稀疏。单个 token 量少了矩阵乘法的尺寸就小GPU 上的计算单元填不满效率极低。这个问题在论文里有个专门的词叫“kernel 开销”也是 MoK 这个名字里“巨核”两个字要解决的核心目标。1.2 NVL72 平台的特殊性NVL72 指的不是一块显卡而是一个典型的 72 卡 NVLink 域集群节点。这个规模的硬件有几个特点值得先说清楚。其一72 张卡在物理上可以通过 NVLink 组成一个高带宽、低延迟的互联域卡与卡之间的通信带宽比传统以太网或者普通 InfiniBand 高出很多。这意味着很多在传统集群上不敢做的细粒度通信在 NVL72 上是可以考虑的。其二虽然 NVLink 带宽很高但 72 张卡共享的通信域并非无限资源。当 token 路由到专家时跨卡传输依然有上限。而且如果所有卡同时发起 all-to-all通信模式会瞬间打满互联带宽算力还是会被迫停下来等数据。其三这种规模的单域集群非常适合做“模型并行专家并行”的混合并行训练。但怎么把并行策略安排得让算力不闲置恰恰是论文里花大量篇幅讨论的事情。MoK 的设计背景就是这样不是要在学术小规模任务上刷点而是要在这种工业级硬件上把 MoE 模型训练吞吐榨出来。1.3 “Kitten”这个名字背后的直觉“Mixture of Kittens”这个命名确实带点恶趣味但也不是纯搞怪。论文里的“kitten”指的是那些规模很小、数量很多的专家单元。小、多、灵活、成群结队出现确实有点像一窝小猫。作者团队想表达的是与其搞几个巨大的专家不如用大量轻量级的小专家配合专门设计的调度和计算方案让它们像猫群一样灵活地响应不同 token 的请求。“巨核 MoK”中的“巨核”则是指把大量小专家对应的稀疏计算重新整理成大型矩阵乘法GEMM来处理。一个小专家算一个小矩阵这是“小核”把一群小专家的小矩阵合并成一个大 GEMM这就是“巨核”。所以 MoK 的核心思路可以压缩成一句话用大量小专家提高模型容量和路由灵活性再通过“巨核化”把稀疏计算变回密集计算最后在 NVL72 的高带宽环境下把通信藏进计算里。思路本身不复杂复杂的是每个环节怎么落地。2. MoK 方法拆解从路由到巨核2.1 专家分组litter 与 kittenMoK 对专家的管理方式是我觉得最有工程味道的部分。它没有把所有专家放在一个平面集合里而是引入了“分组”的概念。一组同类的小专家被称作一个 litter可以理解为“一窝小猫”。每一窝里的多个 kitten 专家共享某些计算资源在物理上也尽量放置在相近的 GPU 上。这样做的好处是toke 在做路由选择时不是先精确到具体某个专家而是先选择一个 litter再在 litter 内部选具体的 kitten。看起来多此一举但实际训练中这能大幅缩小路由决策的搜索范围也能让通信模式更加局部化。如果你做过 MoE 训练就会知道最烦的不是 router 算不对而是路由结果导致 token 在所有 GPU 之间混乱地乱跳。MoK 的分组策略本质上相当于给通信做了个约束先在大方向内聚再在内部流动。用大白话说就是让 token 尽量在“邻居家”之间串门不要动不动就跨整个集群跑一趟。2.2 巨核 GEMM把小 token 合成大矩阵这是 MoK 最值得细看的工程点。传统 MoE 在计算专家 FFN 时是按专家来做的每个专家收集自己的 token然后做一次小 GEMM。专家一多每个小 GEMM 都很小GPU 利用率非常糟糕。MoK 的做法不一样。它把同一 litter 内的多个 kitten 专家要处理的数据在内存中重新排布把所有小 GEMM 横向拼接成一个大的批量 GEMM 来执行。这个操作听起来简单实际上需要非常精细的 kernel 设计。它要求矩阵的布局既能被不同专家独立使用又能在底层并行执行时不互相干扰。我自己的经验是这类“拼接 GEMM”最大的坑在于显存布局的切换。因为 token 是动态路由的每个 step 各专家分到的 token 数量都在变。如果每次都要重新排列数据额外的内存拷贝开销可能直接吃掉合并带来的收益。论文里提到他们用预先分配好的显存池来降低这个开销这一点在复现时非常关键。巨核 GEMM 的意义不只是在单次计算上更高效更重要的是它让 GPU 的 Tensor Core 能够被充分喂饱。你可以这么理解Tensor Core 就像一个高档餐厅的小厨房你给它一盘精致的开胃菜它确实能做但大量的时间都浪费在准备工作上你一次性给它一整车食材它反而能高速运转起来。巨核化做的就是这件事。2.3 负载均衡与辅助损失的设计MoE 的负载均衡问题在 MoK 里没有回避而是通过组合拳来解决。第一层是概率均衡也就是常见的 auxiliary loss。router 在输出选择概率时会附带一个惩罚项鼓励 token 在选择专家时尽量均匀分布。MoK 对这个损失的实现做了一点调整它加了一个针对 litter 级别的均衡项再加一个针对 kitten 级别的均衡项。这样既不会让某一窝猫忙死也不会让窝里的某只猫饿死。第二层是容量因子capacity factor。MoK 设定一个动态容量因子根据各 litter 的实际负载情况在训练过程中缓慢调节每个 kitten 最多能接收的 token 数量。这个设计的精妙之处在于它不需要全局同步而是每个设备根据局部信息就可以做出调整减少了因负载均衡带来的额外通信。第三层是有损丢弃策略。如果某个 kitten 实在装不下更多 token 了MoK 不会硬撑而是把溢出的 token 直接跳过该专家。这在训练早期听起来有点浪费但它可以防止某个专家单点过载拖慢整个 step。实际跑下来这种“放弃一部分 token”的策略在吞吐上的收益通常远大于损失的那一点点信息。2.4 训练动态从稀疏到巨核的过渡论文里还有一个让我印象很深的细节就是他们提到了“从稀疏到巨核”的训练动态。具体来说模型并不是从一开始就启用全部 kitten 的。训练初期小专家还在“适应期”直接全部打开容易导致路由剧烈震荡。所以 MoK 设计了一个递增策略训练开始阶段只启用一小部分 kitten随着 loss 逐渐平稳再逐步解锁更多的专家。这种做法我理解是受到了课程学习curriculum learning思路的启发。它在两个维度上有效果。第一个维度是训练稳定性渐进式解锁专家给了 router 足够的适应时间避免一上来因为随机初始化导致路由崩溃。第二个维度是算力效率初期用小规模专家做热身等于给 GPU 空出了一些余量来做实际收益更高的计算。不过我得说这个递增策略的调度频率需要非常小心的实验。解锁太快等于没解锁解锁太慢又会造成训练时间浪费。论文里给出的一组参考值是每隔一定训练步数解锁一个比例但实测下来这个比例跟数据分布和模型规模都有关系换到自己的场景后必须重新调。3. NVL72 上的实用配置与实验效果3.1 并行策略EP TP FSDP 的分配在 NVL72 这样的平台上训练 MoK光有好的模型设计还不够必须解决并行策略的问题。MoK 给出的方案是三层组合。第一层是专家并行EP。litter 内部的所有 kitten 被打散放置在不同的 GPU 上token 根据路由结果在卡间进行局部通信。第二层是张量并行TP在每个计算节点内部对巨核 GEMM 的矩阵乘法做切分让单个大矩阵乘法也能被多卡协同计算。第三层是 FSDP 风格的分片优化器状态把优化器状态分散到各卡降低显存压力。这个组合的关键在于“内存规划”。72 张卡看起来显存很多但当专家数量达到几万级、序列长度再拉满时显存依然非常紧张。MoK 的做法是给不同类型的张量分配不同的并行维度权重按 EP 维度切片优化器状态按 FSDP 维度切片中间激活则尽量在 TP 维度内消化。我特别想说一下他们对于资源配置的一个观点在 NVL72 上真正稀缺的资源不是算力而是显存带宽和互联带宽。因此并行方案的目标不是让某一块计算最大化而是让通信不发生拥塞。实测下来EP 和 TP 的配比影响着 all-to-all 的模式找错配比会让整机算力利用率直接掉二十个百分点。3.2 关键超参备忘单论文里没有把全部超参都列出来但根据我读下来的感受以下这几个参数对复现结果影响最大。路由 top-k 的选择很重要。MoK 默认使用 top-2 路由。有人会想既然 kitten 那么多top-4 会不会效果更好实测来看top-2 在大多数场景下已经能拿到足够好的效果top-4 还会成倍增加通信量。litter 大小直接影响通信模式。一般建议每个 litter 内的 kitten 数量不超过 8 个。超过这个值巨核 GEMM 的收益就开始被通信延迟抵消。如果想增大专家总数优先增加 litter 的数量而不是单个 litter 的规模。容量因子方面MoK 给出的参考范围是在 1.0 到 1.25 之间动态调整。太高会让 token 大量溢出到丢弃逻辑太低则让有些专家空转。你可以在训练日志里盯着每个 litter 的平均利用率如果长期低于一半就说明容量因子设置太大了。另外巨核 GEMM 的拼接粒度也有讲究。太小的拼接块会让 kernel 启动开销明显太大的拼接块又可能造成显存峰值。建议以 512 个 token 为一块来做分组拼接这是 GPU 端 GEMM 相对舒服的粒度。3.3 实验结论怎么读论文报告的收益主要体现在三个维度。吞吐量方面MoK 相比 baseline MoE 在 NVL72 上实现了显著的算力利用率提升尤其当专家数量超过一万以后提升更明显。核心原因是巨核 GEMM 让 Tensor Core 的利用率大幅提高不再被小矩阵乘法拖累。收敛效果方面MoK 在相近的训练预算下下游任务平均分优于 baseline。这意味着它不是靠牺牲效果换吞吐而是实打实地训练出了更好的模型。渐进式解锁专家的设计对此也有贡献它让训练过程更平滑。扩展性方面论文特别强调了一点当模型规模再往上翻一倍时baseline MoE 几乎无法维持有效利用率但 MoK 依然能保持住训练吞吐。这正好说明MoK 的“巨核化”思路是为更大规模准备的不是小打小闹的优化。我自己读实验部分的时候最关心的其实是他们掉的“坑”。论文里提到一个现象训练初期如果不加 litter 级别的负载均衡loss 下降速度看起来很快但到中后期会突然出现梯度的异常尖峰。我推测这是因为热门 litter 在持续过载梯度质量不断恶化最终集中爆发。这个经验比那些“多了几个点”的数据更值得带进自己的项目。4. 复现要点与实战避坑记录4.1 路由崩溃的排查MoE 训练里最大的梦魇是路由崩溃。所谓 routing collapse就是 router 反复输出 one-hot 分布每次都只选同一个专家其他专家完全不参与。早期 designer 很容易忽视它因为 loss 在降看着一切正常。MoK 通过多个机制压制这个问题但你在复现时还是不能掉以轻心。我建议在训练日志里同时记录三个指标路由熵、litter 维度熵和 expert 利用率方差。路由熵低于理论最大值的 60% 时就要警惕了。如果发现某个 kitten 的利用率连续几千步都接近零多半是出现了死锁式的 collapse这时候需要回退到早一点的 checkpoint并调大 auxiliary loss 的系数。实际过程中我一般会把辅助损失的权重先设为千分之一如果 collapse 立刻调高到千分之三以上。但要记得训练稳定后把这个权重降回去否则会损害模型的效果。4.2 巨核 GEMM 显存峰值怎么处理巨核 GEMM 的问题之一是显存峰值。拼接大矩阵虽然提升了计算效率但一次性加载的数据量也变大了很容易踩到显存天花板。我的处理办法是分两步走。第一步在训练脚本里显式控制拼接缓冲区的最大上限而不是让框架自动扩展。比如设定单个缓冲区最多容纳 4096 个 token 的激活超出部分拆成两份计算。第二步用计算和通信重叠的思路把上一个矩阵乘法和下一个 all-to-all 通信在 CUDA stream 上并行执行。这一步做得好显存峰值可以下降约两成同时吞吐不会明显下降。这里有个容易被忽略的细节显存峰值不只是由矩阵本身决定的还要看通信缓冲区是否和计算缓冲区共用同一块显存池。我踩过一次坑通信库在初始化时悄悄申请了大块显存导致后面巨核 GEMM 反而因为显存不足被换到更保守的模式性能直接打回原形。解决方案是在启动前设置显存分配预留比例保证通信缓冲区的空间稳定。4.3 小专家容量设多少合适MoK 里的 kitten 数量很多单个 kitten 的尺寸又不大所以“容量因子”成为关键参数。容量因子直接决定每个 kitten 每次训练 step 最多处理多少 token。设太小大量 token 被丢弃信息损失偏大设太大路由机制形同虚设每个专家都忙得不可开交。我的经验是容量因子需要结合数据集的 token 重复度来看。如果数据本身重复度高容量可以设小一点反正相同的信息还会出现。如果数据集非常“碎”每个样本都有大量独特信息容量因子就要适当放大减少溢出丢弃。一个比较稳健的调参方式是先把容量因子固定在 1.1连续跑一万步观察溢出率也就是被丢弃 token 占全部路由 token 的比例。如果溢出率超过 5%说明容量不够往上加如果低于 0.5%说明路由分摊得太稀了整体效率偏低往下减。4.4 长期稳定训练的两个容易被忽略的点第一个问题是长时间训练中浮点累加误差会被逐步放大。MoK 里大量矩阵拼接再拆分每个 token 的梯度路径都不一样时间长了各专家之间的梯度尺度会漂移。这个漂移在几百步内看不出来但只要跑过几十万步就会在某个专家权重里悄悄长出异常范数。因此我会在训练脚本里增加一个梯度全范数监控并且定期对异常大的 expert 层做一次权重裁剪。别心疼这几分钟的操作它能避免你最后白跑一个月。第二个问题是checkpoint 的保存策略要针对 MoE 结构专门设计。MoK 的专家数量巨大如果每个 step 都保存完整模型磁盘开销会失控。建议把通用层和专家层分开存储通用层用较高频率保存专家层只保存当前最优版本和最新版本。同时定期做一次汇总 checkpoint 用于后续继续训练其他时间保存增量 checkpoint 即可。4.5 复现时对硬件环境的调校最后说一个很多论文解读不会提但实战又很有用的点NVL72 这种平台上的软件环境配置会对 MoK 的表现产生巨大影响。首先是通信库版本。MoK 的巨核 GEMM 极度依赖高效集合通信。老版本通信库在 NVLink 高带宽场景下经常出现“带宽利用率低”的问题换了新版本后同样的代码能快出一截。其次是算力库的配置要为这种大规模拼接 GEMM 场景调整 batch size 的对齐方式尽量让矩阵维度是硬件加速器最舒服的 8 倍数或 16 倍数。还有一个很多人忽视的地方是电源与散热策略。72 卡满负荷训练时的功耗非常惊人如果散热策略降级GPU 会自动降频。MoK 的巨核 GEMM 对频率非常敏感因为它的计算密集度太高降频带来的损失比稀疏场景更大。所以如果你发现训练吞吐在不该下降的时候下降了先别急着调模型去检查一下机房温度。5. 我的总体感受与扩展方向Mixture-of-Kittens 这篇论文给我的最大感受是真正的算法创新在落地时往往是非常朴素的。它没有重构 MoE 的数学框架而是把注意力放在通信模式、显存布局和 kernel 效率这些工程细节上。这正是现在大规模模型训练里最值钱的经验。MoK 这个名字看起来在卖萌背后的目标是实打实的“用工程手段榨干硬件的价值”。如果你试过跑大规模 MoE应该能体会那有多么不容易。多一倍的专家不代表多一倍的能力而往往是多一倍的调度烦恼。从扩展角度来看我认为 MoK 的思路至少可以在两个方向上继续延伸。一个是把 MoK 和更细粒度的 token 剪枝策略结合起来让那些容易被忽略的 token 在早期就被识别出来节省整个系统的无效计算。另一个方向是探索更激进的路由预测机制通过提前预判未来的 token 分布让巨核 GEMM 的输入拼接更有序进一步降低通信切换开销。这篇文章我读了两遍第一遍是顺着它的思路走第二遍是带着“我要在类似规模集群上复现它”的心态去挑毛病。结果发现它可能不是最华丽的方法但绝对是最值得工程团队拿来参考的 MoE 训练方案之一。最后再分享一个我个人的小习惯遇到这类论文不要光盯实验结果那几张图表。把实验配置部分放大看他们用了多长的训练步数、什么样的学习率调度、有没有做梯度裁剪这些才是决定成败的细节。算力越来越贵能提前多避开一个坑都是实打实的省钱。

MoK揭秘：NVL72上大规模MoE训练工程方案深度解读

相关推荐

Python深度学习股票量化系统：从数据到回测的工程化实战

C语言指针进阶：复杂声明、函数指针与二级指针的工程实战解析

硬盘接口原理与性能瓶颈全解析：从SATA到PCIe直连

更多资讯

Codeforces 946G Almost Increasing Array：删除位置与树状数组优化解析

odbcji32.dll丢失修复指南：从SFC扫描到官方数据库驱动完整方案

【一人公司】2026 独立开发新范式：从 v0 到 Cursor，用 TaoToken 统一 Key 打通全链路 AI 提效

一天连开七个仓库对标 Adobe：本周 GitHub 上最猛的个人开发者是他

Zotero Better BibTeX 导入偏好配置指南：花括号大小写保护、AUX 扫描回填与句例化处理

WAMP环境下的网络考试系统设计与实现：从数据库到PHP的完整指南

今日更新

再见，SSE！你好，Streamable HTTP！轻松开发 Streamable HTTP MCP Server 并接入 TaoToken

工业软件标准化路线图：国产替代的落地施工图

VCMI安卓版实操指南：原生运行英雄无敌3的3步技术落地

本周精选

CMOS设计三大物理效应：体效应、沟道长度调制与亚阈值导电

微信小程序在线阅读毕设全解析：Java后端+MySQL+避坑实战

Android音频问题五层分析法：从App到Codec的系统化诊断

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？