清华唐杰团队把 GLM 练成 MoE 后

PromptCube 专家 3小时前 758 浏览 15 点赞 约 2 分钟

前两天把 Z.ai 那场内部分享的录屏刷完,最大的感受不是模型多大、参数多少,而是他们把「怎么把 Scaling Law 落到每张 H100 上」这事儿想得有多透。唐杰老师全程没秀过一张 Loss 曲线,全在讲通信重叠、专家并行切分粒度、以及怎么让 3000 卡集群不跑偏。

最扎心的一段是讲 MoE 专家并行。业界通用的做法是 EP(Expert Parallel)切一刀,每张卡拿几个专家,All-to-All 一通猛换。GLM 这边直接把 EP 维度再拆细:把专家内部的 FFN 权重按输出维度再切一刀,配合 TP(Tensor Parallel)把单专家的矩阵买再拆开。结果是单张卡显存占用再降 18%,All-to-All 通信量直接砍半。工程组把 NCCL 的调度策略改了三版,最后把通信计算重叠率从 60% 逼到 92%,这才是真正的「把 Scaling Law 算进硬件里」。

另一个细节是数据混合策略。别人家都是按比例采样、甚至训练中间动态调权重,GLM 直接把数据分成 12 个质量梯度桶,预训练前三分之二只喂高质量桶,后三分之一再把长尾桶按课程学习的节奏慢慢喂进去。唐杰说得很直白:「Scaling Law 告诉你要喂多少 token,但不告诉你喂哪些 token、什么顺序喂;这中间的工程红利,比堆卡更值钱。」

推理侧更狠。他们把 MoE 的路由器做成了两阶段:第一阶段在 CPU 上跑轻量级 Top-K,只算专家亲和度;第二阶段才在 GPU 上做真正的专家前向。配合动态批次调度,单卡吞吐直接跑满 BF16 算力上限的 85%。现场有人问「为啥不搞 DeepSeek 那种 MLA」,回答干脆:「MLA 省 KV Cache,但我们 MoE 稀疏激活本身就只算 1/8 参数,省下来的显存够再跑 4 倍批次,吞吐换延迟,划算。」

看完录屏回头看自家集群,才发现以前总盯着「买多少卡、跑多大模型」,根本没把「每张卡每秒钟干了多少有效 FLOPs」当指标。唐杰团队把 Scaling Law 从数学公式变成了 NCCL 参数、内核调度、数据管线、甚至机房布线的拓扑感知——这才是大模型工程化该有的样子。

如果你手头有几百张卡、想把 MoE 练稳、推得动,强烈建议去啃啃 GLM-4 的技术报告附录,里面藏的工程细节比正文正经多了。别光盯着 Benchmark 榜单,真正的护城河在集群利用率里。

GLMMoEZ.ai唐杰清华大学

全部回复 (3)

极客阿强 中级 3小时前
EP 切完还得调 capacity factor,不然 hot expert 直接把显存撑爆,我们线上加了个动态 token drop 才稳住
0 回复
折腾党小雨 中级 3小时前
我们集群跑 MoE 最头疼的是路由抖动,加了个 auxiliary loss 才不跑偏
0 回复
T
Tom 中级 3小时前
EP 这边通信重叠怎么搞的?All-to-All 那块没把计算挤死?
0 回复

发表回复

支持 Markdown 格式