Magistral：Mistral 从零搭一套纯 RL 推理训练栈

选对 reward 对 RL 算法能否有效工作至关重要。训练期间，模型的 generation 会沿四个轴被评估：格式、正确性、长度、语言一致性，下面逐一说明。

2.2.1 格式

对数学题和代码题，我们都指示模型遵循一个特定格式，这方便抽取模型的答案：

1. 标签要求：（i）模型回复必须以 <think> 标签开头，并且必须包含对应的 </think> 标签。（ii）回复里这组标签必须恰好出现一次。
2. 数学回复：对数学类输出，回复必须在 </think> 标签之后的答案区里，把最终答案包在 \boxed{} 中。
3. 代码回复：对代码类输出，回复必须在答案区里至少包含一个 markdown 代码块，用三个反引号加编程语言标识来标记。

任何一条不满足，reward 就是 0，回复也不再往下评分。否则回复拿到 0.1 的 reward 并进入评分环节。

2.2.2 正确性

如果生成的答案符合格式要求，我们就抽出模型的解答，用 verifier 判定其正确性。

数学正确性。最终答案从解答里最后一个 \boxed{} 内部抽出，用一个基于规则的 verifier 与参考答案比对。它会把 ground-truth 和生成的答案都做归一化，以便正确地给那些语义相同、写法不同的回复打分。我们组合使用多个不同的 parser 和 SymPy¹¹ 来评估输出、与原始 ground truth 比对。答案正确会额外给 0.9 的 reward，总 reward 变成 1.0。

代码正确性。代码从答案区的第一个 markdown 代码块里抽出。如果代码是 C++ 写的，就按 C++20 标准编译，超时设为 10 秒。我们预编译了 bits/stdc++.h 这个竞赛编程里常用的标准库头文件，以加快编译过程。我们从可用测试用例里随机选 20 个测试，并确保同一个回复组内用的是同一批测试。然后代码在这些测试上执行，每个测试超时 4 秒、内存上限 300 MB。代码成功通过全部测试会额外给 0.9 的 reward。

2.2.3 长度惩罚

参照 Yu 等人⁷，我们用软长度惩罚来向模型示意：最大 completion 长度的硬截断已经不远了。我们固定两个长度 $l_{\text{max}}$ 和 $l_{\text{cache}}$，把长度惩罚算作

2.2.4 语言一致性 reward

Magistral 的一条核心设计原则是：用与用户相同的语言推理。在数学和代码题上做强化学习，如果不做任何处理，模型回复经常混语言。在没有语言约束的初步实验里，我们频繁观察到英语、中文和俄语词混在一起的输出。这些输出虽然是连贯的，但从用户角度看并不理想。

为了防止语言切换，我们把 10% 的英文题目翻译成以下语言：法语、西班牙语、意大利语、德语、中文、俄语。在计算一段对话的 reward 时——一段对话是（题目、思考、答案）三元组——我们先把三个部分各自归一化，去掉 LaTeX 内容和代码块，然后对每一部分跑一个 fastText 分类器¹²。如果分类器判定三个部分用的是同一种语言，我们就额外给 $0.1$ 的 reward。

这些简单的改动就足以让模型紧跟用户的语言、几乎不做 code-switching，同时保住推理任务上的表现。虽然我们只把原始英文题目翻译成了少数几种语言，但我们观察到模型能成功地用任意语言生成 chain-of-thought。

System prompt。我们在 system prompt 里指定格式和语言要求，它见 Figure 2。我们发现 RL 训练对所用的 system prompt 相当敏感。举个例子，system prompt 里 Be as casual and as long as you want 这一段会提高模型的熵，从而改善模型的探索。

Figure 2：Magistral 的 system prompt。这段 system prompt 把格式和语言的规范给模型讲清楚。数学题和代码题用的是同一段 system prompt。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

A user will ask you to solve a task. You should first draft your thinking process (inner monologue) until you have derived the final answer. Afterwards, write a self-contained summary of your thoughts (i.e. your summary should be succinct but contain all the critical steps you needed to reach the conclusion). You should use Markdown and Latex to format your response. Write both your thoughts and summary in the same language as the task posed by the user.

Your thinking process must follow the template below:

<think>

Your thoughts or/and draft, like working through an exercise on scratch paper. Be as casual and as long as you want until you are confident to generate a correct answer.

</think>

Here, provide a concise summary that reflects your reasoning and presents a clear final answer to the user.

Problem:

{problem}

3 基础设施

Figure 3：online 训练流水线。1）generator 持续为来自输入数据源的 prompt 产出 completion。2）每当一条 completion 完成，它就被送到对应的 verifier。3）每条序列按一个预设的置换被送往不同的 data parallel group，直到每个 data parallel group 都攒够序列组成一个 batch。4）执行一次梯度步，trainer 和 generator 都被更新。在 generator 里，权重是在生成中途被替换掉的，这意味着还在飞行中的 generation 会带着一份稍微过期的 key-value cache 继续跑，因为我们不刷新这份 cache。由于 trainer 和 generator 两边的模型都驻留在 GPU 上，权重通过 NCCL 传输以获得最佳性能。模型权重会被动态地重新聚合，以适配 trainer 和 generator 之间不同的 sharding 拓扑。

本节我们呈现用于 online 训练的基础设施。我们采用了一套与若干前人工作^1314151617 相似的分布式 RL 训练系统，它协调三类 worker：

• Trainer 保有模型权重的主拷贝，执行梯度更新。
• Generator 执行 rollout，用最新策略从训练 prompt 返回 completion 及其 log 概率。
• Verifier 评估 generator 产出的 completion 并返回一个 reward（细节见 §2.2）。

分布式 RL 的挑战。generator 占总算力的很大一块，也是 online RL 独有的那一块。它们的负载高度不均匀且难以预测，因为序列长度的分布高度偏斜，而且在训练过程中还会变化：最长的 completion 可能比最短的多花 5 倍时间。这套系统的一条主要约束是不能在序列长度上引入偏置：即便短的 completion 更早跑完，completion 长度的分布也必须严格等于训练数据的分布。另一个与之竞争的目标是尽早更新 generator 的权重。我们希望 generation 尽可能 on-policy，但同时也希望 generator 运转起来不必彼此等待、也不必等 trainer。

异步 generation。要做到训练时不带任何近似，我们本可以按 batch 顺序处理：让 generator 在一个 batch 上开跑，等所有序列完成，同时更新 trainer 和 generator 的模型权重，然后重复。然而这条路会因为完成时间不均匀而导致 generator 空转、流水线效率低。我们转而优先考虑效率，让 generator 以最大吞吐持续运转，从不等待 trainer。我们不断从 generator 那里收集组，验证它们，然后更新 trainer。这些更新之后，trainer 通过 NCCL 把新权重发给 generator，同时不丢弃当前正在生成的飞行中序列。把权重从 GPU 广播到 GPU 是关键，它把单次更新所需的时间压到 5 秒以下，即便模型很大、world size 很大也是如此。这个过程见 Figure 3。

一条解答在为单个 prompt 生成的过程中，可能经历多次模型权重更新，每次都反映 trainer 那边最新的改进。等到它被完整处理并送回 trainer 时，模型权重可能已经更新了好几次，但最新的那些 token 总是 on-policy 生成的。更新模型权重时，此前存在 key-value cache 里的 hidden state 会稍微过期，因为它们是由此前版本的模型算出来的。出于性能考虑，我们发现重算 key-value cache 并非必要，可能是因为 loss 函数本身自带 off-policy 修正⁶。

Trainer 优化。我们把一个 batch 定义为固定条数的 completion，而不是固定的 token 数。generator 按一个预设的置换，把每条完成的 completion 发给一个随机的 trainer rank。当每个 data parallel rank 都收到足够多的 completion 能凑成一个 batch 时，就执行一次梯度更新。如果 trainer 成了瓶颈——训练早期 generation 还很短时就是这种情况——我们就把涌入的 generation 攒进一个有固定大小上限的阻塞队列，用这个上限控制 off-policy 的程度。一个 batch 可以再切成若干 minibatch 以执行多次优化步（见 §6.3）。每个 minibatch 有固定条数的 completion，但 token 数是变的，所以它会被进一步切成固定 token 尺寸的 microbatch。由于我们是在多个 microbatch 上累积梯度，样本的顺序无关紧要。我们利用这个性质实现了一套贪心装箱（greedy collation）算法：把序列按尺寸降序排列，逐条尝试塞进某个还有空位的 microbatch，没有就新开一个。这保证了每个 minibatch 在各训练 worker 上的负载是均匀的，把 padding 减少了 19%。

4 数据筛选

我们把范围限制在有可验证解的问题上；我们用的数学题的解是一个数值答案或表达式，代码题则带有配套的测试。我们做了大量筛选，下面描述。

4.1 数学

格式筛选。我们从一个规模很大但很嘈杂的题库出发，大约 70 万条样本。我们首先对数据做全面的预处理和筛选，以确保所有题目都是完整的、最终答案是准确的且能被一套基于规则的系统验证。特别地，我们过滤掉证明题和多问题——这类题的正确性很难验证。此外，我们把选择题改写成陈述式题目，以获得更稳健的验证和更高的难度。

难度筛选。我们实现了一条两阶段筛选流水线，来筛出一批处于「goldilocks（金发姑娘）」难度的题目——对模型来说不太容易也不太难，恰好能学到东西。第一步，我们用 Mistral Large 2¹⁸ 做初始难度评估，为每道题采样 $16$ 个解答，把从来没解出来的和以很高成功率解出来的都剔掉。这批经过初筛的题目随后被用来通过我们的 online RL 流水线训练一个 24B 模型，得到一个小而能力不错的 checkpoint，我们只把它用来评判难度。

第二阶段，这个更强的、经过 RL 训练的模型被用来重新评判整个原始数据集。我们再次为每道题采样 16 条回复，把最容易的和仍然解不出来的过滤掉。接着我们进一步过滤掉可能标错的题目——那些多数样本给出同一个最终答案、但与「ground-truth」答案不一致的题。这是因为当模型持续达成一个与参考解相矛盾的共识时，更可能是题目本身的 ground-truth 答案就是错的。

这套两阶段方法是关键，因为只用最初那个更弱的 Mistral Large 2 模型跑一遍是不够的。它的推理能力很可能会让它把许多真正的难题错误地判成不可解、从而丢掉。通过用一个更强的、RL 训练过的模型做第二遍，我们确保这些有价值的、有挑战性的训练样本被准确评估并保留下来。

Table 1：不同筛选阶段之后的数学训练样本数。

4.2 代码

我们从各种来源收集了编程竞赛数据。每个数据点包含一段题面，以及在有的情况下的正确解答和相关测试。为了训练，我们希望拿到题面，以及每道题尽可能多的正确测试。为此我们首先去掉所有没有解答、以及测试数量不够的题目。然后把每份解答在所有可用测试上执行一遍，丢掉那些一致性不足的测试。对于一致性足够但没有任何解答能通过的测试，我们假定这个测试本身是错的，就把它更新成各解答输出里最常见的那个结果。对于缺测试的代码题，我们额外生成测试，并让它们经过同样的评估流程。

最后，在适用的场合，题面会被复制一份，分别要求用 Python 或 C++ 作答——这是竞赛编程里两种常用的语言。这个流程最终得到一个 3.5 万道代码题的数据集。

5 实验与结果

Figure 4：本文讨论的筛选、训练与 RL 阶段总览。我们在 Mistral Medium 3 之上做 RL 得到 Magistral Medium。我们用这个模型为一大批多样的 prompt 生成答案。我们用这些生成的轨迹去微调 Mistral Small 3，然后做 RL 得到 Magistral Small。

本节我们呈现 Magistral 模型。我们的目标是回答两个问题：（i）在一个大 base 模型上纯做强化学习能走多远？（ii）给定一个很强的教师模型，怎样才能拿到最强的轻量级模型？为此我们训练了 Magistral Medium——在 Mistral Medium 3¹⁹ 之上用纯 RL；以及 Magistral Small——它从源自 Magistral Medium 的 SFT 轨迹起步。

5.1 评测 benchmark 与 baseline

我们报告在数学、代码和 STEM 领域评估能力的 benchmark 上的结果。数学方面我们给出 American Invitational Mathematics Examination 系列 benchmark（AIME'24、AIME'25）以及 MATH 数据集²⁰ 上的结果。代码方面我们纳入 LiveCodeBench（v5 和 v6 两个版本）²¹ 和 Aider Polyglot²²。STEM 方面我们报告基于 GPQA 数据集²³ 的结果。此外我们还报告在 Humanity’s Last Exam²⁴ 纯文本题上的结果，该 benchmark 包含横跨数十个学科的 2,500 道题，涵盖数学、人文与自然科学。所有评测任务的 temperature 都设为 0.7，数学评测和 GPQA 的 top-p 用 1.0，代码任务用 0.95。最大 token 长度 AIME 和 LiveCodeBench 设为 40k，其余全部评测设为 32k。

baseline 方面我们纳入 DeepSeek-AI 等人³ 的结果，他们报告了大规模 RL 训练的可比数据点，既有在推理模型轨迹上做过 SFT 的，也有没做过的。

5.2 Magistral Medium —— 从零做推理 RL

这里我们的目标是评估我们 RL 栈的质量，做法是训练一个完全没有「cold start」（即不通过蒸馏推理轨迹来预热推理能力）的模型。这次 run 我们用 Mistral Medium 3 Instruct¹⁹ 作为起始 checkpoint。训练分多个阶段进行，各阶段超参不同。特别地，这些阶段的设计是为了确保下面几条判据始终成立：

1. 数据集不能太容易。随着模型表现提升，我们提高数据的难度。更难的数据切片是这样构造的：把更复杂的数据（早先阶段被过滤掉的那些）放进来，或者把已经被完全解决的题目从数据里移除。
2. 生成长度不能停止增长。为防止生成长度停滞，我们同时提高最大允许 completion 长度，以及不受长度惩罚的最大 completion 长度 $l_{\text{max}}-l_{\text{cache}}$（参见 §2.2.3）。我们把 $l_{\text{max}}-l_{\text{cache}}$ 提高了两次：$16\text{k}\to 24\text{k}$ 和 $24\text{k}\to 32\text{k}$。
3. KV cache 的内存负担不能太大。随着生成长度增加，KV cache 相关的内存占用也在增加。为应对这一点，我们下调并发运行的请求总数 $n_{\text{async}}$、batch size $n_{\text{batch}}$ 以及 minibatch size $n_{\text{minibatch}}$。batch size 的影响在 §6.3 讨论。训练期间我们把 batch size 下调了两次：$8\text{k}\to 4\text{k}$ 和 $4\text{k}\to 2\text{k}$。

Table 2 展示了用纯 RL 训练的 Magistral Medium 的结果，并与 DeepSeek-AI 等人³ 的对应实验作比较。我们发现仅靠我们的 RL 流水线，就在 AIME ‘24（pass@1）上带来接近 50% 的准确率提升，在 LiveCodeBench（v5）上带来 30% 的提升。

Table 2：仅用 RL 训练的 Magistral Medium 的结果。为降低方差，AIME 我们取 64 次 run 的平均（写成 pass@1/maj@64），LiveCodeBench 取 16 次 run 的平均。Humanity’s Last Exam 只评测纯文本子集。

5.3 Magistral Small —— 在推理 SFT bootstrap 之上做 RL

有了 Magistral Medium 这个很强的「教师」模型，我们接下来探索怎样训出最强的学生模型。为此我们训练 Magistral Small，它用来自 Magistral Medium 的 SFT 轨迹做「cold start」。

与纯 RL 训练形成对照——纯 RL 受益于一小批极其干净且困难的训练点（§4）——我们发现对推理 cold-start 来说，prompt 的多样性很重要。我们首先从 Magistral Medium 的 RL 训练里抽取答案正确的轨迹，排除早期步骤里那些 CoT 很短的。我们还通过限制每道题的 generation 条数来维持题目难度的混合分布，避免收集到的轨迹偏向容易的题，同时对通过率较低的题做上采样。

我们在此基础上扩充 SFT cold-start 数据：用我们的 Magistral Medium 在一大批多样的 prompt 上生成回复，这些 prompt 来自 OpenThoughts²⁵ 以及 OpenR1²⁶²⁷ 的代码子集。我们在这之上再做一轮筛选，保留 prompt 的一个子集。这样我们得到一个难度混合的推理数据集。我们还加入 10% 的通用 instruction tuning 数据点，以保住非推理能力。我们把 Mistral Small 3 Instruct（一个 240 亿参数的模型）微调了 4 个 epoch，并按 AIME'24 挑出最好的 checkpoint 作为后续 RL 阶段的初始 checkpoint。

然后我们用 RL 训练这个 SFT checkpoint，batch size 为 2048 条序列，不受惩罚的最大 completion 长度 $l_{\text{max}}-l_{\text{cache}}$ 为 32k。generation 的采样 temperature 我们用 1.0，因为它在「温度更低时多样性不足」和「温度更高时输出不连贯」之间取得了最好的平衡。我们用 0.3 的 $\varepsilon_{\text{high}}$ 来鼓励探索，因为 cold-start 过的模型产出的回复熵要低得多。

Table 3 展示了在三种不同范式下训练出的 24B 模型的表现：只做 SFT；只做 RL；以及在 cold-start checkpoint 之上做 RL。这里与 DeepSeek-AI 等人³ 的发现相反，我们发现即便在更小的 base 模型上，RL 也能带来可观的提升，而且是在从更大的教师做蒸馏之上再加的提升。这凸显了本工作引入的这套 RL 栈的强度。

Table 3：Magistral Small 与不同训练配置在各 benchmark 上的表现对比。我们报告三个不同的 24B 模型的表现：在来自 Magistral Medium 的推理轨迹上微调过的 Mistral Small 24B（SFT）、从零用 RL 训练的 Mistral Small 24B（RL only），以及在 Magistral Medium 轨迹上微调后再用 RL 强化的 Mistral Small 24B（SFT + RL），后者就是最终的 Magistral Small。我们观察到「在推理轨迹上微调」加「RL」的组合带来最好的表现。Humanity’s Last Exam 的评测只考虑纯文本子集。

5.4 多语言 benchmark

为评估 Magistral 的多语言能力，我们用多种语言与 Magistral Medium 交互，检查它是否能用用户的语言推理和作答。我们还在 AIME 2024 benchmark 的多语言版本（法语、西班牙语、德语、意大利语、俄语、中文）上测试了 Magistral Medium。这些多语言版本是把题目从英文翻译成各语言得到的。结果见 Table 4。我们看到模型在多语言版本上比英文低 4.3–9.9%，换算到真实的 AIME 考试上相当于 1–3 道题，可能是因为我们约束了推理所用的语言。这个退化幅度和 base 模型的退化大致相当。注意在多语言 benchmark 上，所有推理和最终回复都是用输入语言进行的（也就是说，不是英文）。

Table 4：Magistral Medium 在 AIME 2024 benchmark 多语言版本上的 pass@1 表现。

6 消融实验

本节我们调整训练过程的参数，考察只在一种模态上做 RL 会发生什么，把 RL 与蒸馏 SFT 这条 baseline 作比较，并说明我们不得不面对的两个训练选择：batch 与 minibatch 大小，以及 advantage 归一化。

6.1 跨领域泛化

我们通过「在一个领域上训练、在另一个领域上评测」来考察模型的跨领域泛化能力。具体来说，我们在 24B 模型上做两个实验：一个只在数学数据上训练，然后在数学和代码上都评测；另一个只在代码上训练，评测方式相同。如 Table 5 所示，模型在域外任务上表现很强，展示了 RL 的泛化能力。

Table 5：24B 模型在只做数学 RL 和只做代码 RL 时的跨领域泛化

6.2 小模型：蒸馏 vs RL

先前工作³ 观察到，只依靠 RL 的小模型可能达不到从更大推理模型蒸馏出来的水平。然而我们的发现与这个观察相矛盾：即便在 Mistral Small 3 之上纯做 RL，我们也拿到了很强的结果。如 Figure 5 所示，我们的 Mistral Small 3 纯做 RL 在 AIME'24 上取得与蒸馏版本相近的表现。它在 MATH 和 GPQA 上甚至超过蒸馏版本，只在 LiveCodeBench 这类代码 benchmark 上略低一些。这些结果说明 RL 的好处并非大 base 模型独享，在小模型上同样成立。此外，我们的发现表明在蒸馏过的 checkpoint 之上再做 RL 能带来更好的表现，在各个 benchmark 上带来 5 分以上的增益。

Figure 5：Magistral Small 与不同训练配置在各 benchmark 上的表现。我们报告三个不同的 24B 模型的表现：从零用 RL 训练的 Mistral Small 24B（RL only）、在来自 Magistral Medium 的推理轨迹上微调过的 Mistral Small 24B，以及在 Magistral Medium 轨迹上微调后再用 RL 强化的 Mistral Small 24B，后者就是最终的 Magistral Small。我们观察到「在推理轨迹上微调」加「RL」的组合带来最好的表现。

6.3 batch 与 minibatch 大小

PPO 或 GRPO 这类强化学习（RL）算法引入了两种不同的 batch 尺度。batch size，记作 $n_{\text{batch}}$，指的是更新 generator 权重之前收集的序列条数。minibatch size $n_{\text{minibatch}}$ 指的是用来计算梯度、执行一次优化步的序列条数。要注意 $n_{\text{minibatch}}$ 必须整除 $n_{\text{batch}}$。此外，在 异步 RL 流水线里还引入了第三个尺度：并发序列数 $n_{\text{async}}$，它表示并行生成中的序列条数。如果并发生成的序列数 $n_{\text{async}}$ 远大于 batch size $n_{\text{batch}}$，那么一条典型的序列是用 $n_{\text{async}}/n_{\text{batch}}$ 个不同的策略生成出来的，可能过于 off-policy。当我们每个 batch 做多于一次 minibatch 更新时，这个效应会更严重。

为检验这个假设，我们从 Ministral 3B 出发用 SFT 准备了一个很强的 3B 模型，然后用 GRPO 在纯数学数据上训练它，学习率恒定，$n_{\text{async}}=4096$ 固定，$n_{\text{batch}}$ 和 $n_{\text{minibatch}}$ 取 $\{1024,2048,4096,8192\}$ 中的不同值。

Figure 6：batch 与 minibatch 大小对 RL 训练 reward 的影响。(a) 3B 模型在数学数据上做 RL 训练时不同 batch size 下的 reward，此时 minibatch size 保持等于 batch size。并发生成的序列数恒为 4096。(b) 同一配置下，固定 batch size 为 8192 条序列、不同 minibatch size 时的 reward。我们观察到表现对 batch size 并不敏感，但当一个 batch 里有超过 2 个 minibatch 时会退化。

我们观察到，只要保持 $n_{\text{batch}}=n_{\text{minibatch}}$ 并且 $n_{\text{batch}}$ 足够大，把曲线按处理过的 prompt 数来画时表现非常相近，见 Figure 6(a)。另一方面，在 $n_{\text{batch}}$ 不变的前提下减小 $n_{\text{minibatch}}$，表现会突然退化，甚至比把 $n_{\text{batch}}$ 直接降到同样的 $n_{\text{minibatch}}$ 还要差，如 Figure 6(b) 所突出的。当 $n_{\text{batch}}\leq 1024$ 时训练变得不太稳定，所以我们在最终训练和后续消融里选择保持 $n_{\text{async}}/n_{\text{batch}}\leq 2$ 且 $n_{\text{batch}}=n_{\text{minibatch}}$。

6.4 advantage 归一化

我们试了下面几种 advantage 归一化方法：

• Minibatch —— 在一个 minibatch 内归一化 advantage
• 组内归一化 —— 在单个 prompt 对应的一个组内归一化 advantage
• 不归一化 —— 不对 advantage 做归一化

先前工作⁸¹⁰ 指出，在给定问题的一组 generation 上做归一化会导致一种偏置：容易的题或很难的题因为标准差更小而被加权放大。然而我们没有观察到对评测表现或长度增长有任何显著影响，如 Figure 7 所示。因此我们决定在所有实验里都用 minibatch 归一化。

Figure 7：GRPO 里不同 advantage 归一化方式的训练结果。我们观察到不同归一化方法既没有在评测表现上、也没有在训练期间的长度增长上带来显著差异。

7 分析

本节我们考察 RL 训练的动力学，并给出证据说明「拉长 completion」是提升模型表现的主要资源。这些动力学对此前的能力没有破坏性，推理能力甚至能泛化出去：多模态推理白白变好了，function calling 和 instruction following 保持不变甚至略有提升。此外我们讨论两个对我们不奏效的想法——基于测试通过率给代码任务更细粒度的 reward，以及通过 loss 里的 entropy bonus 项来控制熵。

7.1 强化学习在低维空间里移动权重

为了更好理解 Magistral 在 RL 训练期间的动力学，我们遵循 Li 等人²⁸ 的方法，分析 Magistral Small RL-only 这次 run，并把最终 checkpoint 附近的 loss landscape 可视化出来。

首先，我们把所有中间 checkpoint 的权重堆成一个矩阵 $X \in \mathbb{R}^{T\times W}$，其中 $T$ 是 checkpoint 数、$W$ 是权重数。然后我们减去这 $T$ 个 checkpoint 的均值权重，做 PCA 分析，在权重空间里找出矩阵 $X$ 的两个主成分。由于权重空间维度极高，我们用迭代式的 Lanczos-Arnoldi 算法²⁹ 求 $X^TX$ 的 top-2 特征向量。这样我们得到两个成分 $c_1$ 和 $c_2$，再把它们做 L2 归一化成单位范数。

其次，我们通过加上这两个成分来扰动最终 checkpoint 的权重 $w^* \in \mathbb{R}^{W}$：

我们在固定的 512 条 prompt 上评估每个被扰动的 checkpoint，每条 prompt 生成 16 条 completion，reward 设置与 Magistral Small RL-only 那次 run 相同。最后我们为每个 checkpoint 算出平均 reward 和平均输出长度，并画在 $(\alpha_1, \alpha_2)$ 坐标里。

Figure 8：reward 与长度在 $w(\alpha_1, \alpha_2)$ 超平面上的演化。黑色箭头轨迹是 Magistral Small RL-only 那次 run 的中间 checkpoint 在这个超平面上的投影。黑点是用上面那个公式算出的被扰动的 checkpoint。中间的值用三角网格上的线性插值算出。

我们清楚地观察到存在一个「长度」方向——当模型在 Figure 8 里从右往左移动时，平均 reward 和输出长度都在增长，直到长度开始撞上长度惩罚和最大允许 completion 长度那一点为止。我们还额外画出了不含长度惩罚的原始 reward 对输出长度的依赖，在 Figure 9 里观察到一种普遍存在的 log 型 scaling。

Figure 9：reward 随输出长度的 scaling。每个点对应一个用上面那个公式算出的被扰动的 checkpoint。我们用该 checkpoint 生成 8192 条 completion，评估平均输出长度和原始 reward（不含长度惩罚的 reward）。我们对平均输出长度在 1500 到 8000 之间的 checkpoint 做线性回归，观察到 reward 随输出长度呈对数增长。

Figure 10：多模态 benchmark 上的表现。

7.2 白吃的多模态午餐

用于 RL 训练的初始 checkpoint，Mistral Small 3 和 Mistral Medium 3，都是多模态模型，自带视觉 encoder。在 RL 训练阶段，由于模型是在纯文本数据上训练的，人们可能预期多模态表现会退化。然而恰恰相反，我们发现模型不仅保住了多模态能力，还意外地长出了更强的多模态推理能力。得到的模型在多模态 benchmark 上也展现出更好的表现。

我们报告在几个为评估推理能力设计的多模态 benchmark 上的结果，具体是 MathVista³⁰、MMMU³¹ 和 MMMU-Pro³²。我们在 Figure 10 里的结果显示，在大多数 benchmark 上都没有性能回退，并且在 MMMU（+5%，达到 70%）、MMMU-Pro-Standard（+4.4%，达到 57.9%）和 MMMU-Pro-Vision（+12%，达到 52.1%）上有明显提升。虽然最显著的提升出现在需要文本推理的科学类问题上，我们观察到模型把它拉长的思考过程迁移到了所有类型的问题上（定性示例见附录的 Figure 14、15、16）。

7.3 RL 对其他能力的影响

与 §7.2 提到的多模态能力类似，我们的 RL checkpoint 维持甚至改善了它的 tool calling 和 instruction following³³ 能力（Table 6）。这让我们可以把模型开箱即用地接进现有的工具里。

Table 6：强化学习前后的 benchmark。Internal bench 是 Mistral 内部的 function calling benchmark。我们用的是修正了公开版一些问题的内部版 IFEval。这些分数与其他公开分享的分数不可比。

7.4 没成功的尝试

本节我们呈现那些我们试过但最终没有采用的方法，因为它们没有带来任何性能提升。

7.4.1 代码数据的部分 reward

竞赛编程在正确性和复杂度约束上的严苛要求，导致 reward 很稀疏，经常有很多代码 generation 因为 reward 多样性不足而被丢弃。

为解决这一点，我们试了一种比例式 reward：基于通过的测试比例，而不是 §2.2.2 讨论的二值 reward。在一个 24B 模型跑 250 步的消融里，我们发现用比例式 reward 训练更快，被丢弃的数据少了三倍。然而这条路导致 benchmark 上的最终表现略低一些，LiveCodeBench 下降 2%（Figure 11a），生成长度的增长也更慢（Figure 11b）。

我们原本的期望是，基于通过测试比例的 reward 应该比简单的通过/失败给 RL 训练提供更丰富的信号。但潜在的问题是，部分 reward 也可能给错误的解答提供虚假信号，并且对不同实现之间的细微不一致更敏感，从而可能导致训练 batch 的意义变弱。

Figure 11：代码题的二值 reward vs 比例式 reward。(a) 用二值 reward 和比例式 reward 训练 250 步之后在 AIME 和 LiveCodeBench 上的准确率。用比例式 reward 时 LiveCodeBench 上的表现低 2%。(b) 训练全程的长度演化。用二值 reward 时长度涨得更多。

7.4.2 熵目标控制

为了鼓励探索、防止 RL 训练期间的熵坍缩，文献里⁶ 一个常见策略是加一个 entropy bonus loss 项。然而我们发现这个策略不稳定，因为 entropy bonus 的效果随数据集变化很大。对纯数学数据集，加了 entropy bonus 熵反而下降，而更高的 $\varepsilon_{\text{high}}$ 能维持住熵、增强探索（Figure 12a）。在数学加代码的数据集上，加了 entropy bonus 熵会过度上涨（即便系数和纯数学那次 run 一样），而更高的 $\varepsilon_{\text{high}}$ 允许熵下降，改善了利用（Figure 12b）。

Figure 12：$\varepsilon_{\text{high}}$ 对训练全程熵分布的影响。(a) 3B 模型在纯数学数据集上训练全程的熵演化。加 entropy bonus 时熵下降，而更高的 $\varepsilon_{\text{high}}$ 维持住了熵，允许更好的探索。(b) 3B 模型在数学加代码数据集上训练全程的熵演化。加 entropy bonus 时熵爆掉了，即便系数和纯数学版本一样。更高的 $\varepsilon_{\text{high}}$ 表现更好，让熵能够下降。

我们转而发现依赖 $\varepsilon_{\text{high}}$ 更有效，文献⁷³⁴ 里也提到了这一点。这个方法避免了 entropy bonus 带来的不稳定问题。

另一个控制熵的做法是给 PPO loss 加一个 KL 项。然而由于 generation 分布预期会显著偏离原始模型，我们发现用 KL 惩罚主要是在阻碍训练，这与先前的发现⁷ 一致。我们尝试过用训练期间权重的指数移动平均作为 KL 的参考，但发现手动调 $\varepsilon_{\text{high}}$ 更简单。

8 在 OSS 推理轨迹微调出的模型上做 RL

作为一个实验，我们还试了先用开源推理数据集 OpenThoughts²⁵ 和 OpenR1²⁶²⁷ 的代码子集微调 Mistral Medium 3，其中同时包含这些数据集里的 prompt 和 generation，也就是 Deepseek R1 生成的轨迹。这总共包括约 130 万条 generation。然后我们用我们最难的那部分数据子集，在这个微调过的 checkpoint 之上跑 RL。如 Figure 13 所示，加上 RL 相比 SFT checkpoint 带来了可观的性能增益。值得注意的是，RL 模型在 AIME'25 上提升超过 10 分、在 LiveCodeBench 上提升 5 分，在代码和数学 benchmark 上达到与 Deepseek-R1 相当的最终水平。

Figure 13：在开源轨迹上微调的 Magistral Medium 的 benchmark 表现。所有结果都用 pass@1 报告。阴影区域突出的是在监督微调之上做 RL 带来的额外提升。我们发现虽然在开源轨迹上微调本身就能拿到很强的结果，但再施加 RL 会进一步显著提升表现。特别是 AIME'25 上的准确率提高了 12% 以上。请注意 GPQA Diamond 上的表现在 RL 之后从 72.9% 降到了 71.0%。

9 结论

Magistral 是我们用强化学习走向通用能力系统的第一步。我们期待着前方的下一批研究问题：什么样的 loss 和优化算法最合适，让模型在自己的推理轨迹上做 bootstrap 能解锁多少增益，以及如何扩展到下一个数量级的算力。展望未来，我们也很兴奋地想把 RL 的边界推向一整片应用领域，涉及 tool-use、集成的多模态和 agent。在探索这片前沿的过程中，我们仍然致力于以透明和乐观的方式为科学做贡献。

Core contributors

Abhinav Rastogi, Albert Q. Jiang, Andy Lo, Gabrielle Berrada, Guillaume Lample, Jason Rute, Joep Barmentlo, Karmesh Yadav, Kartik Khandelwal, Khyathi Raghavi Chandu, Léonard Blier, Lucile Saulnier, Matthieu Dinot, Maxime Darrin, Neha Gupta, Roman Soletskyi, Sagar Vaze, Teven Le Scao, Yihan Wang

Contributors

Adam Yang, Alexander H. Liu, Alexandre Sablayrolles, Amélie Héliou, Amélie Martin, Andy Ehrenberg, Anmol Agarwal, Antoine Roux, Arthur Darcet, Arthur Mensch, Baptiste Bout, Baptiste Rozière, Baudouin De Monicault, Chris Bamford, Christian Wallenwein, Christophe Renaudin, Clémence Lanfranchi, Darius Dabert, Devon Mizelle, Diego de las Casas, Elliot Chane-Sane, Emilien Fugier, Emma Bou Hanna, Gauthier Delerce, Gauthier Guinet, Georgii Novikov, Guillaume Martin, Himanshu Jaju, Jan Ludziejewski, Jean-Hadrien Chabran, Jean-Malo Delignon, Joachim Studnia, Jonas Amar, Josselin Somerville Roberts, Julien Denize, Karan Saxena, Kush Jain, Lingxiao Zhao, Louis Martin, Luyu Gao, Lélio Renard Lavaud, Marie Pellat, Mathilde Guillaumin, Mathis Felardos, Maximilian Augustin, Mickaël Seznec, Nikhil Raghuraman, Olivier Duchenne, Patricia Wang, Patrick von Platen, Patryk Saffer, Paul Jacob, Paul Wambergue, Paula Kurylowicz, Pavankumar Reddy Muddireddy, Philomène Chagniot, Pierre Stock, Pravesh Agrawal, Romain Sauvestre, Rémi Delacourt, Sanchit Gandhi, Sandeep Subramanian, Shashwat Dalal, Siddharth Gandhi, Soham Ghosh, Srijan Mishra, Sumukh Aithal, Szymon Antoniak, Thibault Schueller, Thibaut Lavril, Thomas Robert, Thomas Wang, Timothée Lacroix, Valeriia Nemychnikova, Victor Paltz, Virgile Richard, Wen-Ding Li, William Marshall, Xuanyu Zhang, Yunhao Tang

附录

Figure 14：一道物理多模态题目，以及 Magistral Medium 生成的解答。

题目：

一束光如图所示从介质 1 经介质 2 进入介质 3。关于光在每种介质中的速度可以得出什么结论？

A. $v_3 > v_1 > v_2$

B. $v_1 > v_2 > v_3$

C. $v_1 > v_3 < v_2$

D. $v_2 > v_3 > v_1$

模型生成：

<think> 首先，我需要理解光穿过不同介质时的行为。根据 Snell 定律，光进入折射率不同的介质时速度会改变。介质的折射率 $n$ 与该介质中的光速 $v$ 成反比，意味着折射率越大，光速越小。

看图：

光束从介质 1 进入介质 2，向法线方向偏折。这说明介质 2 的折射率比介质 1 大，因为光在减速（进入更致密的介质）时会向法线偏折。

光束从介质 2 进入介质 3 时远离法线偏折。这说明介质 3 的折射率比介质 2 小，因为光在加速（进入较不致密的介质）时会远离法线偏折。

现在我们来分析光在每种介质里的速度：

在介质 1 里，光速是 $v_1$。

在介质 2 里，由于光从介质 1 进入时向法线偏折，介质 2 的折射率比介质 1 大。因此介质 2 里的光速 $v_2$ 小于介质 1 里的，所以 $v_1\,>\,v_2$。

在介质 3 里，由于光从介质 2 进入时远离法线偏折，介质 3 的折射率比介质 2 小。因此介质 3 里的光速 $v_3$ 大于介质 2 里的，所以 $v_3\,>\,v_2$。

现在我们需要比较 $v_1$、$v_2$、$v_3$ 的速度。由上面的分析，

$v_1\,>\,v_2$

$v_3\,>\,v_2$

但我们还需要确定 $v_1$ 和 $v_3$ 之间的关系。由于介质 3 的折射率比介质 1 小（因为光从介质 2 进入介质 3 时远离法线偏折，而我们已经知道介质 2 的折射率比介质 1 大），这意味着介质 3 比介质 1 更不致密。因此介质 3 里的光速会大于介质 1 里的。

所以总结起来：$v_3\,>\,v_1\,>\,v_2$

看给出的选项：A. $v_3\,>\,v_1\,>\,v_2$ B. $v_1\,>\,v_2\,>\,v_3$ C. $v_1\,>\,v_3\,<\,v_2$ D. $v_2\,>\,v_3\,>\,v_1$

与我们的结论相符的正确选项是 A。

</think>

最终答案：A

Figure 15：一道化学多模态题目，以及 Magistral Medium 生成的解答。

题目：

哪个箭头指向的是氢键？

模型生成：

<think> 好的，这张图展示了一个分子结构，上面有标为 a、b、c、d 的箭头。问题是问哪个箭头指向氢键。我们来拆解一下。

首先，我需要弄清楚什么是氢键。氢键是氢原子与氧、氮、氟这类电负性原子之间的一种吸引性相互作用。在这个例子里，由于我们看到的是水分子（H2O），氢键应该出现在不同水分子的氢原子与氧原子之间。

看这张图：

• 箭头 a 指向的是同一个水分子内部氢原子与氧原子之间的键。那是共价键，不是氢键。
• 箭头 b 指向的是另一个单个水分子内部的键，同样是共价键。
• 箭头 c 指向的是一个水分子的氢原子与另一个水分子的氧原子之间的键。这看起来像是氢键，因为它在不同的水分子之间。
• 箭头 d 指向的是单个水分子内部氢与氧之间的键，所以那是另一个共价键。

由此看来，箭头 c 指向的是一个水分子的氢与另一个水分子的氧之间的氢键。

不过为了保险，我应该再检查一遍。氢键通常出现在分子之间而不是同一个分子内部，并且涉及一个氢原子被氧这类高电负性原子吸引。箭头 c 展示的确实是一个分子的 H 与另一个分子的 O 之间的这种分子间相互作用。

</think>

图中有四个标为 a、b、c、d 的箭头。箭头 c 指向的是一个水分子里的氢原子与另一个水分子里的氧原子之间的键。这是氢键的特征——氢键出现在不同分子之间，而不是同一个分子内部。

最终答案：c

Figure 16：一道生物多模态题目，以及 Magistral Medium 生成的解答。

题目：

是什么导致这片叶子的叶脉起皱？

A. 细菌病原体

B. 我不知道，也不想猜

C. 真菌病原体

D. 卵菌（水霉）病原体

E. 生理性病症；不涉及病原体

模型生成：

<think> 这张图是一片叶子的特写，沿叶脉有一些起皱和褪色。要判断起皱的原因，我们需要考虑给出的几种可能。

首先，我们排除掉一些选项：

细菌病原体（选项 A）通常引起水浸状病斑、萎蔫和细菌溢出这类症状，而不是这里看到的起皱。

真菌病原体（选项 C）常引起叶片上的斑点、白粉或粉状物，与这里的外观不符。

卵菌（水霉）病原体（选项 D）常导致水浸状病斑和更普遍的疫病，而不是叶脉专属的起皱。

现在我们来考虑剩下的选项：

选项 B（「我不知道，也不想猜」）不是一个有效答案，因为我们的任务就是判断起皱的原因。

选项 E（生理性病症）有可能，因为它涉及营养缺乏或环境胁迫这类状况，这些都能在不涉及病原体的情况下导致起皱。

这片叶子的外观显示沿叶脉起皱并有一些褪色，这往往可以归因于生理性病症。可能包括营养缺乏、水分胁迫，或者其他不涉及病原体的环境因素。

综合视觉线索和不同原因通常对应的典型症状，这片叶子叶脉起皱最可能的原因是生理性病症而非病原体。

</think>

总结：图中是一片叶脉起皱并有一些褪色的叶子。在考虑了各种原因对应的典型症状之后，起皱最可能是由生理性病症导致的，而不是细菌、真菌或卵菌病原体。因此正确答案是：

最终答案：E