一份被低估的 109 页研发手册，首次公开顶尖 AI 实验室的研发品味
MAI-Thinking-1 深度解读 · 第一篇（共三篇）
· [1] 训练大模型不是造火箭，是攀岩（本篇） · [2] 让模型思考不难，让它持续思考才难 · [3] vibe coding 之后：AI 编程的工业化
如果你在 2026 年 6 月打开一份来自 Microsoft AI 的技术报告，你的第一反应可能是：“哦，微软也做模型了。”
这不怪你。在 pre-training 这个圈子里，最响亮的名字属于 OpenAI、Anthropic、Google DeepMind、DeepSeek。微软更多以 OpenAI 的投资方和 Azure 的提供者为人所知，而不是以模型研发见长。所以一份 109 页的微软技术报告很容易被当成又一家大公司的公关动作——“我们也做了个模型，虽然没那么好。”
但如果你因为这个先入为主的印象跳过了这份报告，你会错过一件非常罕见的事。
这件事不是”微软做了个好模型”。（它确实做了一个不错的模型——35B 激活参数，在 AIME 2025 上拿了 97%，SWE-Bench Pro 上 52.8%，跟 Claude Sonnet 4.6 打得有来有回——但这篇文章不打算聊这个。）
这件事是：有人第一次把顶尖 AI 实验室内部公认、但鲜少对外言明的研发哲学，用 109 页的篇幅毫无保留地写了出来。
我说的不是某个具体的 trick 或一个聪明的训练技巧。我说的是那套让你能从零开始、持续造出更好模型的思维框架。那套框架，顶尖 lab 内部当然知道——不然他们不可能持续出东西。但对外界来说，它一直是一团迷雾。你看到的永远是结果（“某某模型又刷榜了”），你看不到的是”他们怎么知道这个改动是正确的？他们怎么判断一个想法值不值得追？他们怎么避免在错误的方向上浪费几千万美元？”
这份报告做的事情，就是把迷雾拨开。
所以这篇文章不是为 MAI 写广告。我想做的，是帮你通过这份报告，补上那些顶尖 lab 已经内化、但普通人没有渠道接触到的 “研发品味”——不是怎么训练模型，而是怎么做研发决策。
我们先建立一个所有人都能认同的共识：大模型的 pre-training 极其昂贵。
MAI 的 MAI-Base-1 用 8,192 块 GB200 GPU 训练了 30 万亿个 token。光是电费，按保守估计就是数百万美元。而他们的 full pre-training + mid-training 加起来超过 33.5 万亿 token，耗时以月计。
在这个成本量级上，你不可能靠”试一下看看”来做研发决策。每一个选择——用多少层、多少专家、什么激活函数、什么数据配比——都必须有依据。一旦方向选错，代价不是重新写代码，而是几千万美元打水漂。
那依据从哪里来？
从实验中来。但你不能在大模型上做实验，你只能在小模型上做实验。
这是一个全行业的共识：训练几十个几亿参数的小模型，成本可控；从中找到优胜方案，然后把这个方案放大到千亿参数。整个过程背后有一个默认假设——排名的顺序在尺度放大后保持不变。学术界管它叫”rank invariance hypothesis”。如果你用 5B 参数的模型证明了方案 A 优于方案 B，那么在 500B 参数下，方案 A 也应当优于方案 B。
如果这个假设成立，那研发就好办了：用小模型做海量实验，把胜出方案放大，结束。
问题是，它不成立。
MAI 在早期的数据配比研究中，设计了两套方案：一套偏向代码数据（code-heavy mix），另一套大幅增加了 STEM 数学科学数据的比例（stem-heavy mix）。
先用 5B 参数的模型分别训练，结果是 stem-heavy 在 STEM 测试上明显更好。这非常符合直觉——训练数据里 STEM 内容多，模型的 STEM 能力自然更强。
然后他们把两套方案都放大到 23B 参数，各自训练了 20 万亿 token。
STEM 性能曲线在中途交叉了。Code-heavy 最终反超了 stem-heavy。
这意味着一个不小的麻烦：你用小模型做的所有实验、选出的所有”最优方案”，放大后不一定成立。 你投入大量资源推进一个你以为经过验证的方向，结果发现验证本身并不可靠。
为什么会发生这个反转？他们的归因分析发现了一个出人意料的原因：stem-heavy 方案中有一批高质量的 STEM 数据源，内容极好但多样性不足——本质上是在反反复复地喂同类信息。小模型容量有限，这些”浓缩营养剂”极有帮助；但大模型学得更快，几遍就榨干了这些数据的价值，后续的重复训练变成了过拟合的隐患。而 code-heavy 方案里这些数据源占比极低，模型被迫从更多样化的数据中学习更泛化的 STEM 能力——这在初期看似”慢”，却最终带来了更强的上限。
这个发现不是 MAI “发明”了一个新方法。这个发现证实了一个顶尖 lab 早已心知肚明、但很少公开讨论的事实：小规模实验的结果不能直接作为大规模决策的依据。
那问题就变成了：如果不能靠小模型实验做判断，那你怎么做判断？
有了 stem-heavy 和 code-heavy 的教训，一个自然的想法出现了：别只看某一个规模上的表现，看趋势。
既然小模型实验的结果可能在放大后反转，那我们就把每一个候选方案都放在多个规模下测试——从 3 亿参数到 20 亿参数到 100 亿参数——画出它的性能随模型规模变化的曲线。如果这条曲线在整个 scale 范围内都在 baseline 之上，且斜率不衰减，那这个方案就是真材实料的；如果它只在某个 scale 上亮眼、到了更大的 scale 就开始掉队，那就是又一个 stem-heavy。
这个想法在直觉上完全正确，也是 MAI 方法论的核心。但”看趋势”如果真的只是一个模糊的定性判断，它其实有四个问题，不解决就没法真正在研发中落地。
问题一：不同维度的改进没法互相比较。 你同时做了三个方向的探索——架构微调、数据源替换、训练 recipe 调整。架构改动让 loss 降了 0.02，数据改动让 loss 降了 0.015，recipe 调整让 loss 降了 0.025。哪个更值得追？绝对值不可比，因为不同实验用的模型 size 和 tokens 可能不一样。你需要一个统一量纲。
问题二：loss 改善在不同 scale 上的”含金量”不一样。 在 3 亿参数的模型上把 loss 降 0.01，和在大模型上把 loss 降 0.01，对应的成本增量完全不在一个数量级。因为模型越大，loss 下降越困难——这就是 scaling law 的边际收益递减。光看曲线的绝对值，你会严重低估大 scale 上的改进难度。
问题三：你没法比较不同方案在 scaling 上的”后劲”。 方案 A 在 5B 的时候比 B 好 10%，到了 20B 只比 B 好 2%。方案 C 在 5B 的时候比 B 差 3%，到了 20B 比 B 好 8%。光靠肉眼盯着几条曲线，你很难精确说出 A 和 C 谁的 scaling 前景更好，尤其是在它们交叉的时候。
问题四：你分不清”算法本身不行”和”实现还没优化”。 一个方案在 10B 参数下表现一般，可能有两个原因——它本质上不适合 scale，或者它的 kernel 还没人优化过、实际训练效率吃亏。这两条曲线的区分非常重要，因为后一种情况是可以通过工程投入解决的，而前一种不值得追。
这四个问题的共同根源是：你需要把”趋势好不好”这个直觉，变成一个可以计算、可以比较、可以为决策提供明确依据的操作化指标。
MAI 的答案就是 Efficiency Gain（EG）。它的计算思路很简单：先给 baseline 方案拟合一条 scaling law 曲线——描述它的性能随训练成本的变化规律。然后，对于任何一个候选方案，看它在某个成本 C 上达到了什么性能 P，再回到 baseline 的 scaling law 曲线上，找到 baseline 需要花多少钱才能达到同样的 P。如果 baseline 需要多花 30%，那候选方案的 EG 就是 1.3。
这个定义一举解决了上面四个问题。所有改进都统一换算成”baseline 需要多花百分之多少的成本”——不管你是改了架构还是换了数据，EG = 1.3 就意味着同一个意思（问题一）。而因为它基于 scaling law 拟合，边际收益递减的信息被内置进去了——在更大 scale 上达到同样的 loss 改善，baseline 需要付出的成本更大，EG 自动把这个差异编码进来（问题二）。把每个 FLOPs 水平上的 EG 画成一条曲线，你就能看谁的 scaling 后劲更足——交叉、衰减、加速，一目了然（问题三）。最后，他们分别计算 EG_FLOPs（只看算力消耗）和 EG_Time（计入实际训练时间），把算法效率和硬件实现效率解耦——如果 EG_FLOPs > 1 但 EG_Time < 1，说明方向是对的、只是 kernel 还没跟上（问题四）。
然后，为了获得可靠的 EG 估算，他们建了那个”梯子”——一系列严格按照相同 token-per-parameter 比例训练的模型，从 L12 到 L78。每当你有一个新想法，你不在某一个规模上测试它，你在整个梯子的每一级上测试它，然后画出一条 EG-成本曲线。关键不是看 EG 在某一级上是不是大于 1；关键看它在更大的规模上是上升、持平还是下降。如果曲线在往上走，恭喜你找到了一个越 scale 越好的方向；如果曲线在往下掉，趁早放弃。
这才是研发品味的核心：不是找到”什么有用”，而是找到”什么在更大的尺度上依然有用”。
有了这套思维框架，你才能真正理解下面这张”心电图”。
MAI 报告里的 Figure 11 记录了他们从架构 v2 到 v5 的演化。它同时给出两条线索：训练效率（MFU）会在架构改动后先掉下去，再靠工程优化爬回来；模型质量（EG）则沿着版本迭代持续上升。
右下角那排粉色柱子符合你对”持续改进”的想象：v2 到 v3 在爬，v3 到 v4 在爬，v4 到 v5 也在爬。
但如果你只看 EG 那半张图，你就错过了真正重要的部分。
真正有信息量的是上半张图：MFU 每一次都在暴跌后爬回来。
v4 的时候他们做了一系列重大架构改动：把专家数量从 192 增到 512，把 routing 从 top-4 改成 top-8，引入 Latent MoE。改完之后，训练效率从 22% 直接跌到了 16%。
这不是他们做错了什么。一个全新的架构永远是低效的——没有现成的优化 kernel，没有成熟的 GPU 内存布局策略，没有针对性的通信优化。在你有机会”优化它”之前，你必须先”发明它”，而在你发明它的那一刻，它是笨拙的。
v4 的 16% 是怎么爬回 20% 的？他们把 FlashAttention 从 v2 升级到 v4，重写了 CPU launch 逻辑减少调度开销，提高了 batch 内的任务聚合并行度。二十多项优化之后，才稳住。
然后 v5 来了。参数规模从 23B active 扩到 35B，总参数从 600B 变成 1T。新一轮的暴跌，新一轮的优化——这次靠的是激活 offloading 和更精细的 sharding 策略。
攀岩的本质就在这里。每一步创新都会让效率先跌再涨，而你能接受这个波动，是因为你的梯子告诉你”EG 在往上走”。你有信心——不是因为现在的 MFU 好看，而是因为你知道你的方向是对的就值得爬。
读完这 109 页，我最大的感受跟模型好不好没有关系。
我的感受是：顶尖 AI 实验室之间的竞争，核心已经不在于谁有一个更好的架构 idea。核心在于，谁有一套更好的系统，能让好的 idea 被快速验证、让通过验证的 idea 被持续放大、让放大的过程可控可复盘。
他们给这套系统起了一个名字——hill-climbing machine，攀爬机器。攀爬机器不是某个算法也不是某块 GPU。它是从数据处理到 scaling 实验到训练框架到评估到安全到基础设施的一整套闭环。
这份报告没有藏任何”独家秘方”。你可以去看，109 页，从 attention 怎么初始化到 expert 怎么 load balance 到 RL reward 怎么设计，全写了。
但你读完可能会发现：知道了所有的细节，也不等于能做出同样的东西。 因为这不是一个配方——配方你可以照着做。这是一个有机生长的系统，它需要时间积累每一次摔跤和每一次爬起来的经验。就像你看完一个专业攀岩运动员的训练日志——你知道了他的每一个动作——但这不是你能立刻复制的东西。
不过对绝大多数人来说，你需要知道的不是”我怎么复制它”，而是”原来事情是这么做的”。
这就是这份报告真正的价值：它不是在炫耀一个模型，它是在记录一种思维方式。而这种思维方式——从第一性原理出发，面对昂贵的失败成本，设计出能保护自己不受欺骗的实验框架，接受”创新必先倒退”的代价——它不仅仅适用于 AI 研发。
好的系统不是设计出来一次就完了的。好的系统是能让自己被持续变好的系统。
下一次你看到一个新模型发布，别只问”它有多厉害”。问一句：它背后的攀爬机器长什么样？
这是 MAI-Thinking-1 深度解读的第一篇。第二篇讨论 MAI 的推理 RL 训练纪律——恒温器、断路器和自蒸馏如何保证几千步不崩。第三篇讨论训练基础设施——如何从 487 万开源 PR 中筛出 26.5 万道题，以及 GLM-5 如何把前端代码评审这道工序工业化。
本文基于微软 MAI 团队 2026 年 6 月发布的 MAI-Thinking-1 技术报告。