MAI-Thinking-1：微软造了一台爬坡机
这篇文章回答的问题： 微软 AI 从零训练了一个 35B 活跃参数 / 1T 总参数的 MoE 推理模型，在没有蒸馏第三方 CoT 的前提下达到了接近 Claude Sonnet 4.6 的水平——他们是怎么做到的？整个工程链路是什么样的？
这篇文章应该回答但没回答的问题： 在 AIME 2025 拿到 97.0% 的同时，这个模型在日常对话、创意写作、低资源语言上的表现如何？一个 1T 参数的 MoE 模型在推理成本和延迟上意味着什么？30T token 的预训练数据中，微软自有的数据到底占比多少？
一、核心定位：这不是一篇模型报告，是一篇「造模型工厂」的报告
这份技术报告的真正主角不是 MAI-Thinking-1 这个模型本身，而是微软 AI 构建 「爬坡机」（Hill-Climbing Machine） 的完整工程体系。所谓爬坡机，就是一套从数据管道、训练基础设施、RL 环境、评估套件到安全测试的闭环系统，能持续迭代地把模型性能往上推。
报告的三大设计原则开宗明义：
- 能力是学出来的，不是继承的（Capabilities are learned, not inherited）——不从第三方模型蒸馏，完全靠自己从数据中学习
- 简洁是可持续的（Simplicity is sustainable）——用 GRPO 而非更复杂的 RL 算法，用简单的 ReAct agent loop
- 科学严谨（Scientific rigor）——每个设计决策都有消融实验支撑，不是拍脑袋
“We climb from scratch, without distilling on any third-party chain-of-thoughts. This gives us a clean vantage point for studying how CoTs evolve as the model strengthens.”
我们从零开始爬坡，没有蒸馏任何第三方的思维链。这给了我们一个干净的视角来观察 CoT 如何随着模型的增强而演化。
二、架构拆解：78 层 Transformer，MoE + Dense 交织
2.1 模型规格总览
| 维度 | 规格 |
|---|---|
| 总参数量 | ~1T |
| 活跃参数量 | 35B |
| 层数 | 78 |
| 架构 | Decoder-only Transformer |
| MoE 配置 | Top-8 / 512 experts，LatentMoE 压缩 |
| 注意力机制 | GQA，8 KV heads，周期性 local/global（5:1） |
| 上下文长度 | 256K（渐进扩展：16K → 64K → 256K） |
| 词表大小 | 128K（o200k_base） |
| 训练 token 数 | 30T |
| 训练 GPU | 8K GB200 |
2.2 三个最不寻常的架构决策
决策一：MoE + Dense FFN 交织（Interleaved MoE）
不是每层都是 MoE。微软采用了 MoE 层和普通 Dense FFN 层交替排列的设计。这背后的工程逻辑是：纯 MoE 模型在 expert 负载均衡和训练稳定性上一直是难题，交替 Dense 层相当于给模型留了一条"保底通道"——即使 MoE 路由崩了，Dense 层仍然能保证基本的信息流动。
直觉类比：想象一个公司里，有的部门用项目制（MoE，动态组队），有的部门用固定编制（Dense，稳定产出）。两者交织确保了既灵活又不会全盘崩溃。
决策二：LatentMoE —— 在压缩空间做路由
传统 MoE 的瓶颈在于 all-to-all 通信：每个 token 要把激活值发送给 8 个 expert，在 512 个 expert 中选。通信量巨大。微软的做法是：先过一个共享的 down-projection（把维度压低），然后在压缩后的 latent space 里做路由决策和 expert 计算，最后再 up-projection 回来。
这意味着 all-to-all 通信的数据量大幅减少。工程上的代价是：多了一个 down-projection 的计算，但这个计算是矩阵乘法，GPU 上非常高效；换回的是 all-to-all 通信量的显著下降，在 8K GPU 的规模下这个 tradeoff 是值得的。
决策三：Zero-init Attention + 0.15 Dropout
两个看似矛盾的决策放在一起：
- 注意力输出的 RMSNorm gain 初始化为零 → 模型在训练初期等价于一堆纯前馈层的堆叠，MoE 路由不会因为注意力机制的随机初始化而产生不均衡
- 每层输出到残差连接前加 0.15 的 dropout → 这个 dropout 率在 LLM 训练中是相当高的
这是一个「稳定起步 + 正则化防过拟合」的组合拳。Zero-init 让模型从简单的前馈网络开始，慢慢学会用注意力；高 dropout 确保在这个学习过程中不会过拟合训练数据的噪声。
2.3 周期性 Local/Global Attention（5:1）
每 5 层 local attention 之后跟 1 层 global attention。Local attention 使用 RoPE 滑动窗口（窗口大小 512），global attention 不使用位置编码（no-PE）。这个设计的工程直觉是：
- 大部分信息只需要局部上下文（local attention，RoPE 提供相对位置）
- 少量信息需要全局视野（global attention，不带位置编码，相当于在全局 token 中做信息聚合）
- 5:1 的比例是根据消融实验确定的——更多的 global attention 会增加计算量但收益递减
三、预训练：30T Token 的数据工程
3.1 数据配比（最反直觉的发现）
| 数据类型 | 占比 |
|---|---|
| 代码 | 54.6% |
| STEM | 15.8% |
| 数学 | 5.4% |
| Web 文本 | 14.9% |
| 书籍 | 3.1% |
| 4.7% | |
| 多语言 | 1.6% |
代码占了一半以上。 这不是传统 LLM 的做法。通常预训练数据以自然语言为主，代码作为辅助。微软的选择是刻意为之——代码是最结构化、最逻辑严密的人类语言，对推理能力的培养有独特的价值。
但更有趣的发现是 Rank Non-Invariance（排序非不变性）：
在小规模模型（L12）上，STEM-heavy 配比表现更好；但到了 23B 规模，Code-heavy 配比反超了。
这意味着你不能在小模型上做数据配比实验然后把结论直接放大到目标规模。这是一个非常有价值的工程洞察——数据配比的最优解是模型规模的函数。
3.2 数据管道：从 1.2T 页面到可用语料
Web 数据的处理流程：
1.2T 原始页面
→ 政策合规过滤 + 成人内容过滤 + 黑名单域名 → 794B
→ 精确去重（MD5） → 423B
→ 模糊去重（LSH） → 73.4B 英文 + 116.5B 非英文
→ 质量评分（属性模型 + Gopher 式启发式过滤） → 4.6B 英文
从 1.2T 到 4.6B，过滤掉了 99.6% 的原始数据。这个过滤率是相当激进的。
STEM 数据的处理有专门的管道：
- 7 个二分类器（数学、物理、统计、化学、生物、工程、CS）
- 教育价值分类器
- 教育水平分类器（高中/本科/研究生）
- 定制的 HTML→Markdown 转换（Trafilatura 对公式和代码处理不好）
- LLM 辅助的段落级筛选（保留/移除决策，不允许生成内容）
代码数据来自 GitHub，分三个数据集：
- Files: 1.26T tokens（最新版本的文件，按仓库结构 DFS 排列）
- Commits: 4.5T tokens（最近 10K commits，commit patch 作为训练目标）
- PRs: 1.19T tokens（PR 标题 + 描述 + 评审评论 + 补丁，已去污染 SWE-bench）
3.3 Scaling Ladder：用小模型指导大模型
微软发明了一个方法论叫 Scaling Ladder：训练一系列从小到大的模型（L12 到 L78），用它们来测量架构决策的 效率增益（Efficiency Gain, EG）。
EG 有两个度量：
- EG_FLOPs：基于计算量的效率增益
- EG_Time：基于挂钟时间的效率增益（更实用）
这个方法论的巧妙之处在于：你不需要训完整的目标模型就能判断一个架构变更是否值得。在小规模上测量 EG 趋势，然后外推到目标规模——前提是你要验证这个外推是可靠的。
四、RL 爬坡：从「啥也不会」到「竞赛级选手」
4.1 三个专科模型，一次整合
微软的 RL 爬坡分三条路线，各自独立训练后再合并：
| 专科 | 训练数据 | 核心能力 |
|---|---|---|
| STEM | 数学竞赛题 + 科学推理 | AIME/HMMT 级别的推理 |
| Agentic (SWE) | 265K 真实 SWE 环境 | 代码 bug 修复 + 工具使用 |
| Helpfulness + Safety | 多轮对话 + 安全红队 | 指令遵循 + 安全对齐 |
整合过程：先把三个专科的 rollout 数据收集起来做 SFT（Self-distillation），然后再做一轮最终 RL。这个 “Self-distillation → Final RL” 的流程是关键——它确保了不同专科之间不会互相干扰。
4.2 GRPO 的两个修改
基础算法是 GRPO（Group Relative Policy Optimization），但微软做了两个关键修改：
修改一：自适应熵控制（Adaptive Entropy Control）
用一个积分控制器动态调整熵系数。直觉是：训练初期需要高熵（鼓励探索），训练后期需要低熵（利用已学到的策略）。但手动调这个系数很难，所以用一个反馈控制器自动调节——如果当前熵低于目标熵，就增大熵系数；反之减小。
修改二：Outer Ratio Clip
标准的 GRPO 中，ratio clip 在 per-token 级别操作。微软加了一个 trajectory-level 的 ratio clip，防止整个 trajectory 的概率比偏离太远。这解决了一个实际问题：长 trajectory 中，即使每个 token 的 ratio 都在合理范围内，乘积效应也可能导致整个 trajectory 的概率比爆炸或消失。
4.3 Self-Distillation：长 RL 攀爬的关键技术
这是报告中最有价值的工程洞察之一：
RL 训练时间一长，模型会"遗忘"早期学到的好策略。解决方案是：在 RL 过程中持续收集 rollout traces，然后用这些 traces 对模型做 SFT。
关键发现：
- O(1M) 条 traces 就够了（不需要特别多）
- 后期阶段产出的 traces 比早期的更有价值（因为模型已经更强了）
- Self-distillation 是让 RL 攀爬能持续数周而不崩溃的关键
直觉类比：RL 就像爬山，过程中你会找到好的路径。Self-distillation 相当于每走一段就把好路径记下来复习，确保不会走着走着把之前的技巧忘了。
4.4 SWE 环境构建：从 102M PR 到 265K 可用环境
这是整篇报告中工程量最大的部分：
102M GitHub PRs
→ 过滤（Python + 热门仓库 + 有测试） → 4.87M
→ 构建（Docker 环境搭建） → 2.08M
→ 评分（单元测试通过率） → 745K
→ 验证（多轮人工/自动验证） → 265K（覆盖 94K 仓库）
构建基础设施：
- 30,000 CPU cores 的双池 Ray 集群
- Builder pool 和 main pool 分离（安全隔离 + 故障隔离）
- 每个 builder pod 含两个容器：BuildKit（构建）+ podman（运行评分）
- BuildKit layer cache 复用同仓库的基础层
- 吞吐瓶颈不是 CPU/磁盘，而是 LLM token 消耗（12M tokens/min）
- 最终产出：~20 个/分钟的通过评分的环境
4.5 Rocket：异步分布式 RL 框架
Rocket 是微软自研的大规模异步分布式 RL 框架：
- Learner：使用 YOLO 框架（自研 PyTorch 训练框架）
- Inference：使用 SGLang（高性能推理框架）
- 架构：Controller + Problem Worker + Rollout Worker
- 推理与学习 GPU 比例：最高可达 5:1
5:1 的推理/学习比例意味着 RL 的计算量主要在推理侧（rollout generation），而不是参数更新侧。这是一个重要的工程约束——你需要在大量 GPU 上同时跑推理来生成训练数据。
五、结果：与 Sonnet 4.6 持平，离 Opus 4.6 有距离
5.1 STEM 基准
| 基准 | MAI-Thinking-1 | Sonnet 4.6 | Opus 4.6 | GPT-5.4 |
|---|---|---|---|---|
| AIME 2025 | 97.0 | 95.6 | 99.8 | — |
| AIME 2026 | 94.5 | — | — | — |
| HMMT Feb 2026 | 84.9 | — | — | — |
| GPQA Diamond | 84.2 | — | 96.4 | 92.7 |
| LiveCodeBench v6 | 87.7 | 93.1 | — | — |
AIME 2025 的 97.0% 非常亮眼，但注意 Opus 4.6 拿了 99.8%。GPQA Diamond 上与 Opus 的差距更大（84.2 vs 96.4）。
5.2 Agentic Coding
| 基准 | MAI-Thinking-1 | Sonnet 4.6 | Opus 4.6 |
|---|---|---|---|
| SWE-Bench Verified | 53.4 | 72.7 | 72.0 |
| SWE-Bench Pro | 52.8 | — | — |
| Terminal-Bench 2.0 | 36.0 | — | — |
SWE-Bench Verified 上差距明显（53.4 vs 72.7），说明在 agentic coding 上，微软还有很长的路要走。
5.3 人类评估
| 对比 | MAI-Thinking-1 胜率 | 对手胜率 | 平局 |
|---|---|---|---|
| vs Sonnet 4.6 | 49% | 45% | 6% |
| vs Opus 4.6 | 43% | 52% | 5% |
人类评估中略优于 Sonnet 4.6，但低于 Opus 4.6。这是一个相对诚实的定位——模型在数学推理上非常强，但在 agentic coding 和通用能力上还有差距。
六、工程级对比：自己手搓 vs 微软官方方案
| 环节 | 手搓版（DIY） | MAI-Thinking-1 官方方案 |
|---|---|---|
| 架构 | 标准 Transformer + 纯 MoE | 交织 MoE+Dense + LatentMoE 压缩 |
| 数据配比 | 经验法则（web 为主） | Scaling Ladder 实验确定，代码占 54.6% |
| 数据去重 | MinHash + 精确去重 | 同上 + 语义去重（embedding cosine similarity） |
| RL 算法 | 标准 GRPO/PPO | GRPO + 自适应熵控制 + outer ratio clip |
| 长 RL 稳定性 | 经常崩溃/遗忘 | Self-distillation（O(1M) traces） |
| SWE 环境 | 手动标注几十到几百个 | 102M PR → 自动构建 → 265K 验证环境 |
| 长上下文 | 直接训 256K | 渐进扩展（16K→64K→256K），95% 的 NLL 改善在前 1-10% 的步数内完成 |
| 训练框架 | Megatron/DeepSpeed | 自研 YOLO + Rocket |
| MoE 通信 | 标准 all-to-all | LatentMoE（压缩空间路由）+ dropless variable-size all-to-all |
| 基础设施 | 公有云按需 | 自有 GB200 集群 + 拓扑感知调度 + 节点生命周期管理 |
七、选型决策框架：什么时候该关注这个工作？
| 场景 | 是否关注 | 理由 |
|---|---|---|
| 你在做推理模型训练 | ✅ 必须关注 | Self-distillation + GRPO 修改是最实用的工程经验 |
| 你在做 MoE 架构 | ✅ 必须关注 | LatentMoE + 交织 Dense 是值得尝试的设计 |
| 你在做 SWE Agent | ✅ 值得关注 | 265K 环境的构建流程是业内最大规模 |
| 你需要选一个模型来用 | ⚠️ 等一等 | 模型尚未开源/开放 API，agentic coding 能力偏弱 |
| 你在研究 RL for LLM | ✅ 必须关注 | Rank non-invariance + 自适应熵是关键洞察 |
| 你在做预训练数据工程 | ✅ 值得关注 | 数据配比随规模变化的发现挑战了传统直觉 |
八、诚实限制
- Agentic Coding 是短板：SWE-Bench Verified 只有 53.4%，远低于 Sonnet/Opus 的 72%
- GPQA 差距大：84.2% vs Opus 的 96.4%，在高级科学推理上还有明显差距
- MRCR 暴露了问题：在长上下文计数/复制任务上表现差（60% vs SOTA 95%），暗示可能存在长上下文的细粒度操作短板
- 训练成本不透明：没有公开训练的总 GPU 小时数或碳足迹
- 数据来源不透明：“proprietary crawl"和"direct agreements with publishers"的具体内容未披露
- 模型未开放：截至报告发布，模型尚未开放 API 或权重
九、推理轨迹的演化：弱模型猜测，强模型验证
报告的附录 C 提供了一个极其珍贵的视角——从零训练的模型，其推理策略是如何演化的。因为微软没有蒸馏第三方的 CoT，所以可以清楚地看到模型从"瞎猜"到"严谨推理"的完整过程。
模式一：弱模型猜答案，强模型推导答案
同一道 AIME 2024 题目：
- 弱模型：看到题目中的数字 18, 72, 98，就猜 minimizer 可能和这些数字有关，算出了 40, 152, 512 三个值——但只有最后一个碰对了
- 强模型：先推导出四个代数候选 k ∈ {8, 32, 200, 512}，然后逐一检查定义域条件 x > 0，排除了 512，最终得到正确答案 240
模式二：弱模型暴力枚举，强模型找不变量
- 弱模型：假设 cubing 是 units 上的双射（错了），把三次条件简化成线性条件
- 强模型：识别出关键不变量——对于 3 的幂次，unit cubes 形成一个 index-3 的子群，由 ≡ ±1 (mod 9) 刻画
模式三：弱模型做表面检查，强模型挖源代码
在 SWE 任务中：
- 弱模型：改完代码后，列一个 checklist 说"我改了这些文件，满足需求”
- 强模型：改完代码后，跑单元测试来验证
模式四：弱模型关注编辑操作，强模型做"证据考古"
- 弱模型：花大量时间在精确的文本编辑操作上（tab vs space、行号对齐）
- 强模型：先充分探索仓库，收集大量证据（reverted commit、payload、测试），然后再动手改
十、基础设施：8K GPU 的 Goodput 达到 90%
在 8K GB200 GPU 的规模下，训练的 Goodput（有效吞吐率）达到 90%。这个数字在业界是非常高的。
关键设计：
- 节点认证制：新节点必须通过分级测试（单节点→机架级→跨机架）才能被调度
- 拓扑感知调度：Kubernetes + Kueue 保持大作业在紧凑的拓扑区域内
- 可观测性作为控制环的一部分：硬件遥测不只是仪表盘，直接决定节点是否被调度、排干或修复
- Rack 碎片管理：软机架预留 + 借用回收机制
MAIA-200 部署：推理场景下，每瓦吞吐量比 GB200 高 40%。
苏格拉底对话：理解 MAI-Thinking-1 的核心洞察
学生（尾巴）：微软说他们从零训练，不用任何第三方蒸馏，这有什么意义？不是用 DeepSeek 的数据效率更高吗？
老师：好问题。用蒸馏当然可以更快达到一个还不错的水平，但你永远不知道那个「还不错」的天花板在哪里。从零训练给了微软一个独特的能力——他们可以观察到模型的推理策略是如何从无到有地演化出来的。报告中那些弱模型 vs 强模型的 CoT 对比，只有在没有蒸馏污染的条件下才能做。
学生：但代价不是很大吗？30T token，8K GPU 训练……
老师：代价确实大。但微软投资的不只是这个模型，而是整台「爬坡机」。模型会过时，但数据管道、RL 框架、评估体系、基础设施——这些是可以持续复用的。报告的标题叫 “Building a Hill-Climbing Machine”，不是 “A Hill-Climbed Model”。这是关键区别。
学生：代码占预训练数据 54.6%——这也太多了吧？自然语言理解能力不会受影响吗？
老师：这就是 Rank Non-Invariance 的发现为什么重要。在小规模上，STEM-heavy 配比确实更好；但到了 23B 规模，Code-heavy 反超了。这意味着代码作为预训练数据的价值被系统性地低估了。代码有独特的性质：逻辑严密、有明确的正确/错误标准、结构化程度高、包含丰富的推理模式。但 MMLU-Pro 上微软确实只有 74.8%，低于 Sonnet 的 80.2%——自然语言知识能力确实有代价。
学生：Self-distillation 听起来像是在用自己的输出训练自己，不会导致退化吗？
老师：关键区别在于——他们不是在用模型的"所有输出"做 SFT，而是从 RL 过程中 筛选 出成功的 rollout traces。而且后期的 traces（模型更强时产出的）比前期的更有价值。这不是"自己教自己"的循环论证，而是"把自己偶然发现的好策略固化下来"。RL 的不稳定性很大程度来自 catastrophic forgetting——你学了新东西就把旧的忘了。Self-distillation 解决的是这个问题。
学生：那 SWE-Bench 只有 53.4%，远低于 Claude，这是为什么？
老师：这可能反映了 RL 爬坡的一个根本限制——你的训练数据决定了你的天花板。微软的 SWE 环境虽然有 265K 个，但构建过程是高度自动化的（从 GitHub PR 自动构建 Docker 环境），质量和多样性可能不如手动标注的数据。而 Claude 在 SWE-bench 上的优势，可能部分来自于更精细的训练数据设计。报告中也坦诚了这个短板。
学生：最后一个问题——LatentMoE 在压缩空间做路由，会不会丢失信息？
老师：理论上会，但工程上这是一个非常聪明的权衡。MoE 的 all-to-all 通信在 8K GPU 规模下是主要瓶颈。LatentMoE 用一个共享的 down-projection 把激活维度压低，然后在低维空间做路由和 expert 计算。损失的信息量由 down-projection 的压缩比控制，而通信量的下降是直接的。在 8K GPU 的规模下，通信 » 计算，所以这个 tradeoff 几乎总是值得的。微软的消融实验也证实了这一点。
个性化洞察
洞察 1：Self-Distillation 是长 RL 训练的必备技术
为什么跟你有关：你关注 AI 前沿技术和推理模型训练。Self-distillation 的 O(1M) traces 就够了，后期 traces 更有价值——这些是直接可用的工程参数。
你可以怎么做：如果你在做任何形式的 RL 训练（包括 fine-tuning），考虑在训练过程中收集成功的 rollout traces，定期用 SFT 固化。不需要太多数据，关键是用 RL 后期（模型更强时）的 traces。
洞察 2：数据配比是模型规模的函数——小模型上的结论不能直接放大
为什么跟你有关：你做技术选型和方案评估时，经常需要判断"这个在论文里看起来好的方案，在我的场景下是否还好"。Rank Non-Invariance 告诉我们，甚至连数据配比这种基本决策都是规模相关的。
你可以怎么做：在做小规模实验验证方案时，明确标注"这个结论的适用规模"。不要把小模型上的消融结论直接用于大模型的决策。
洞察 3：代码占 54.6% 的预训练数据——推理能力的燃料
为什么跟你有关：你在做全栈开发和系统架构。这个发现意味着：如果你想训练一个擅长推理的模型，代码数据比 STEM 文本更重要。这与直觉相反——我们通常认为数学训练推理能力，但代码可能更有效，因为代码有明确的执行反馈和结构化的逻辑模式。
你可以怎么做：如果你在做代码相关的 AI 产品（Copilot、代码审查、自动修复），关注那些在预训练阶段就大量使用代码数据的模型，它们可能在推理能力上有结构性优势。
洞察 4：渐进式长上下文扩展——不需要全程用长序列训练
为什么跟你有关：长上下文是当前 AI 应用的热点。微软的发现是：16K 预训练 → 64K 中期训练 → 256K 短期扩展，效果和全程 128K 训练一样好，而 95% 的 NLL 改善在前 1-10% 的步数内完成。
你可以怎么做：如果你需要让模型支持长上下文，不需要在整个训练过程中使用长序列。用一个短期的扩展阶段就够了——这大幅降低了训练成本。
洞察 5：SWE Agent 的"证据考古" vs “编辑操作”——工程实践的直接启示
为什么跟你有关：你日常使用 Claude Code 做 coding agent。报告中弱模型（关注编辑操作）和强模型（先做证据考古）的对比，直接反映了 coding agent 的质量差异。
你可以怎么做：在使用 coding agent 时，给模型足够的探索空间——让它先充分理解代码库再动手改，而不是直接让它"改这个文件"。报告的发现是：强模型会主动寻找源数据（reverted commit、测试、日志），而弱模型只关注怎么改代码。
来源：MAI-Thinking-1: Building a Hill-Climbing Machine — Microsoft AI, 2026-06-02
分析完成时间：2026-06-03 23:30:00