--- layout: post.njk source: https://yage.ai/share/mai-thinking-1-hill-climbing-20260603.html speaker: yage.ai title: |- Microsoft AI 发布 MAI-Thinking-1 技术报告：训练大模型不是造火箭，是攀岩 date: '2026-06-03' summary: 本文深度解读了Microsoft AI的MAI-Thinking-1技术报告，指出顶尖实验室的研发优势在于构建了一套基于第一性原理的“攀爬机器”思维框架。该框架强调通过小规模模型到大规模模型的缩放趋势分析（Efficiency Gain指标）来辅助研发决策，接受架构创新初期的训练效率波动，并强调系统性的实验设计与工程优化的闭环能力，而非仅依赖单一的训练技巧。 area: tech-engineering category: ai-ml tags: - ai-development - pre-training - scaling-laws - 研发品味 - efficiency-gain people: [] companies_orgs: - microsoft-ai - openai - anthropic - google-deepmind - deepseek products_models: - mai-thinking-1 - mai-base-1 media_books: [] draft: true status: evergreen --- > 一份被低估的 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 太贵了 我们先建立一个所有人都能认同的共识：大模型的 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）则沿着版本迭代持续上升。 Figure 11: MAI pre-training configurations show MFU recovering after optimization while EG rises across versions. 右下角那排粉色柱子符合你对”持续改进”的想象：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 技术报告。