📚 plmblog

Appearance

Mistral 系列

📅 发表于 2026/09/23
🔄 更新于 2026/09/23
👁️ — 次访问
📝 4345 字
⏳ 13 分钟
mainllm
#基模
#Pretrain
#SFT
#RL

变化点 ​

2025

2025.12 · Devstral 2

  • 提供 123B 与 24B 两个 Dense 模型，扩展 256K 仓库上下文与跨文件修改。
  • 结合 Mistral Vibe CLI 完成代码任务，延续 Devstral 的 Agent 路线。

2025.06 · Magistral

  • 以可验证奖励训练长推理，改进 GRPO 的优势与损失计算，稳定在线 RL。
  • 从 Medium 生成推理数据蒸馏到 Small，兼顾开放模型的多语言推理与推理效率。

2025.05 · Devstral

  • 以环境探索与单元测试筛选成功轨迹，再用多阶段 SFT 和 RL 训练 24B 模型。
  • 使用 OpenHands 与 SWE-Gym，强化多步骤仓库任务与迭代验证。
2024 及以前

2024.05 · Codestral-22B

  • 面向代码生成与 FIM 补全，覆盖多种编程语言，支持 32K 上下文。

2024.01 · Mixtral 8x7B

  • 每个 Token 从 8 个 FFN 专家中选择 2 个，以稀疏计算扩大参数容量。
  • 在 32K 上下文预训练基础上进行 SFT 与 DPO，形成开放 MoE 指令模型。

(2512) Devstral 2 (123B / 24B、256K) ​

Devstral 2

核心内容

  • 提供 123B 与 24B 两个 Dense 模型，扩展 256K 仓库上下文与跨文件修改。
  • 结合 Mistral Vibe CLI 完成代码任务，延续 Devstral 的 Agent 路线。

详细笔记

(2506) Magistral (纯 RL 推理、异步 GRPO) ​

🌺 论文摘要

Magistral 论文摘要

参考链接

问题背景

  • 长推理 RL 需要同时解决可验证数据质量、探索能力与异步生成效率；小模型还需要比较直接 RL 和蒸馏后的 RL。

核心方法

  • 数据与分支训练：数学题经格式、难度筛选从 699K 缩至 38K，代码题清洗测试后保留 35K；Medium 直接 RL，Small 24B 用 Medium 轨迹 SFT 后 RL。
  • 修改 GRPO：去除 KL、按组内总 Token 数归一化损失，优势只减组均值后在 Minibatch 内标准化；提高上侧裁剪阈值并过滤零优势组。
  • 验证奖励：格式 0.1、完全正确 0.9，叠加柔性长度惩罚与语言一致性奖励。
  • 异步训练：生成与训练持续并行，权重更新不中断正在生成的序列，保留旧 KV Cache，并控制并发量相对 Batch 的比例。

模型效果(Mistral Medium 3 Instruct + RL)

  • AIME 2024 pass@1：26.8 → 73.6；LiveCodeBench v5：29.1 → 59.4；Aider Polyglot：28.9 → 47.1。
  • Magistral Small 24B 的 SFT → SFT+RL：AIME 2025 55.6 → 62.8，LiveCodeBench v5 52.2 → 55.8。

重要结论

  • 24B 的直接 RL 也有效：AIME 2024 上，RL-only 65.8 与蒸馏 SFT 65.4 接近；SFT+RL 达到 70.7。
  • 密集奖励未必更好：按测试通过比例奖励减少了约三分之二的数据丢弃，但最终 LiveCodeBench 低约 2pt。
  • 异步条件限制多次更新：固定生成并发量时，一个 Batch 拆成过多 Minibatch 会加重策略滞后，降低训练效果。

关键贡献

  • 给出可扩展的推理 RL 配方和负结果，开放 Magistral Small 24B 权重。

未来方向

  • 继续研究损失与优化算法、自生成推理轨迹的迭代训练、更大计算规模，以及工具、多模态与 Agent RL。

问题背景 ​

长推理 RL 的数据与系统约束
  • 奖励必须可信：缺题干、错误参考答案或不可靠测试会让 RL 优化错误目标。
  • 探索容易收缩：低概率但有价值的推理 Token 需要获得足够更新空间，长输出也不能过早被截断。
  • 生成长度差异大：不同回答长度可相差数倍，同步等待会浪费推理资源；过度异步又会扩大新旧策略差异。
  • 两种起点需要区分：Medium 从已有 Instruct 模型直接训练推理；Small 先学习自有 Medium 的推理轨迹，再继续 RL。

核心方法 ​

可验证数据与 Medium/Small 分支 ​

数学与代码数据筛选

数学：699K → 501K → 38K

  • 格式过滤去掉证明题、多部分问题和不可规则验证的答案，并把选择题改写成直接作答题。
  • 先由 Mistral Large 2 每题采样 16 次，过滤从未解出和过易题，用留下的数据训练一个用于筛选的 24B RL 模型。
  • 再由更强的 RL 模型重新检查原始题库，每题仍采样 16 次，保留适中难度问题，避免弱筛选器误删有价值的难题。
  • 若多个解答对最终答案形成一致意见，却与参考答案冲突，则去除可能标注错误的问题。

代码：35K 道题

  • 汇集竞赛题、参考程序与测试；运行多个参考程序检查测试一致性，删除低一致性测试。
  • 对参考程序输出形成一致意见、但测试预期错误的情况，按共识修正测试；缺少测试时合成并经过相同验证。
  • 按需要将题目分别改成 Python 或 C++ 作答，训练时同时覆盖两种语言。
两条模型训练路线
  • Magistral Medium：起点为 Mistral Medium 3 Instruct，直接进行推理 RL；随能力提升加入更难数据，未惩罚长度上限依次为 16K → 24K → 32K，Batch 从 8K → 4K → 2K 条序列递减。
  • Small 的 SFT：起点为 Mistral Small 3 Instruct 24B；收集 Medium RL 中答对且具有足够长推理的轨迹，限制每题重复量并上采样难题，再让 Medium 回答 OpenThoughts / OpenR1 Code 中筛选后的多样 Prompt。
  • Small 的混合与选点：加入 10% 通用指令数据，SFT 4 epochs，根据 AIME 2024 选择 RL 起点。
  • Small 的 RL：Batch 为 2048 条序列，未惩罚长度上限 32K，采样温度 1.0；因 SFT 起点熵较低，将 ε_high 设为 0.3。

GRPO 目标与探索控制 ​

去除偏置并保留有效梯度

损失与优势

  • 去除 KL：不保留参考模型的 KL 惩罚，允许推理策略偏离起始模型，并节省参考模型计算。
  • Token 归一化：先累加同组所有回答、所有 Token 的裁剪目标，再除以组内回答的总 Token 数，避免逐回答平均带来的长度偏置。
  • 优势估计：A_i = r_i − mean_group(r)，不除以组内奖励标准差；随后按 Minibatch 内各序列优势的均值与标准差归一化。
  • 零优势组过滤：整组全部答对或全部答错、奖励完全相同时，不进入训练 Batch。

探索控制

  • 使用非对称裁剪区间 [1−ε_low, 1+ε_high]，提高上界，让原本低概率的有效 Token 更容易增加概率。
  • Medium 训练期间将 ε_high 调节在 0.26～0.28，结合熵变化保持训练稳定。

格式、正确性、长度与语言奖励 ​

先检查格式，再执行验证

基础奖励

  • 输出必须以 <think> 开始，且只有一组 <think>...</think>；数学最终答案放在推理之后的 \boxed{} 中，代码放在带语言标记的 Markdown 代码块中。
  • 格式不合格直接得 0，停止后续验证；格式合格先得 0.1。
  • 数学取最后一个 Boxed 答案，做符号规范化并结合 SymPy 判断等价；正确再得 0.9。
  • 代码提取最终回答的第一个代码块，每题随机选 20 个测试，同组回答使用相同测试，全部通过再得 0.9。
  • C++ 按 C++20 编译，编译超时 10s；每个测试限时 4s、内存 300MB。

附加项

  • 柔性长度惩罚：在 l_max−l_cache 前不惩罚，此后随长度线性降到 −0.1，超出最大长度时保持 −0.1。
  • 语言一致性：把 10% 英文题翻译为法、西、意、德、中、俄六种语言；去掉 LaTeX 和代码后，用 fastText 判断题目、推理、答案的语言，三者一致奖励 +0.1。

连续生成与异步权重更新 ​

Trainers、Generators、Verifiers 解耦
  • 持续 Rollout：Generator 完成回答后立刻送给 Verifier，验证后的序列按预定随机排列送到训练 Rank，收齐 Batch 后更新。
  • 生成中更新权重：通过 NCCL 将新权重同步到推理 GPU，传输耗时低于 5s；正在生成的回答继续运行，保留之前权重计算出的 KV Cache。
  • 限制策略滞后：若训练端变成瓶颈，用有长度上限的阻塞队列限制积压；记录生成时的概率，供策略比率计算使用。
  • 长度感知组批：每个 Minibatch 固定序列数、Token 数可变；按长度降序贪心装入固定 Token 预算的 Microbatch，Padding 减少 19%。
  • 最终调度规则：选择 n_async / n_batch ≤ 2，并让 n_batch = n_minibatch，减少同批数据上的重复更新与异步滞后叠加。

实验设置 ​

模型分支与生成口径
  • Medium 主实验：Mistral Medium 3 Instruct → 纯 RL；Small 主实验：同一个 24B 起点分别做 SFT、RL-only、SFT+RL。
  • 采样设置：温度 0.7；数学与 GPQA 的 Top-p 为 1.0，代码为 0.95。
  • 输出预算：AIME 与 LiveCodeBench 为 40K，其余任务 32K；AIME 平均 64 次采样估计 pass@1，并报告 maj@64，LiveCodeBench 平均 16 次。
  • 跨领域实验：24B 分别只做数学 RL 或代码 RL，检查未参与训练的另一领域。
  • 异步消融：从 Ministral 3B 经 SFT 得到的起点出发，在数学数据上固定并发 4096、固定学习率，改变 Batch / Minibatch。
  • 额外蒸馏实验：论文第 8 节另用约 1.3M 条开源 R1 轨迹训练 Medium 后再 RL；与主实验的纯 RL Medium 分开报告。

关键结果(Magistral Medium + RL；Small 24B + SFT/RL) ​

主模型：RL 与蒸馏可以互补

Mistral Medium 3 Instruct → Magistral Medium

  • AIME 2024 pass@1：26.8 → 73.6；maj@64：43.4 → 90.0。
  • AIME 2025 pass@1：21.2 → 64.9；GPQA：59.6 → 70.8。
  • LiveCodeBench v5：29.1 → 59.4；v6：30.0 → 50.3；Aider Polyglot：28.9 → 47.1。

Small 24B：SFT / RL-only / SFT+RL

  • AIME 2024 pass@1：65.4 / 65.8 / 70.7；AIME 2025：55.6 / 51.9 / 62.8。
  • LiveCodeBench v5：52.2 / 46.4 / 55.8；v6：44.6 / 42.4 / 47.4。
  • SFT+RL 的单样本表现最好，但 AIME 2024 maj@64 为 83.3，低于 SFT 的 90.0；不能把 pass@1 的提升等同为所有采样指标都提升。
消融与负结果
  • 跨领域迁移：24B 仅数学 RL，使未训练的 LiveCodeBench v5 从 22.7 → 38.3；仅代码 RL，使未训练的 AIME 2024 从 32.2 → 49.7。
  • Batch 与 Minibatch：3B 消融中，Batch 足够大且与 Minibatch 相同时，按已处理 Prompt 数比较的效果接近；固定 Batch 后拆成更多 Minibatch 会退化。
  • 优势标准化：Minibatch、组内或不标准化，实验未显示明显评测和长度差异；作者采用 Minibatch 标准化，未证明其显著优于另外两种。
  • 代码部分奖励：24B 的 250 steps 消融中，按测试通过比例奖励使丢弃数据降为约三分之一，但 LiveCodeBench 低约 2pt，输出长度增长也较慢。
  • 熵奖励不稳定：相同 Entropy Bonus 系数在仅数学与数学+代码数据上呈现不同趋势；调节 ε_high 更容易控制训练。

未来方向 ​

作者提出的后续问题
  • 比较更合适的 RL 损失与优化算法，研究使用模型自身推理轨迹迭代训练还能获得多少收益。
  • 将训练扩展到更大计算规模，并推进工具使用、多模态与 Agent 场景中的 RL。

(2505) Devstral (SWE 轨迹 SFT、RL) ​

Devstral

核心内容

  • 以环境探索与单元测试筛选成功轨迹，再用多阶段 SFT 和 RL 训练 24B 模型。
  • 使用 OpenHands 与 SWE-Gym，强化多步骤仓库任务与迭代验证。

详细笔记

(2405) Codestral-22B (FIM、32K) ​

Codestral-22B

核心内容

  • 面向代码生成与 FIM 补全，覆盖多种编程语言，支持 32K 上下文。

详细笔记

(2401) Mixtral 8x7B (Token 级 Top-2 MoE) ​

🌺 论文摘要

Mixtral 8x7B 论文摘要

参考链接

问题背景

  • Dense 模型增加参数时，每个 Token 的计算量随之增长；需要在控制激活计算量的同时扩大模型容量。

核心方法

  • 稀疏专家架构：32 层 Transformer 的 FFN 替换为 8 个 SwiGLU 专家，每 Token、每层动态激活 Top-2；Attention 与其他模块共享。
  • 多语言预训练与对齐：提高多语言数据采样比例，原生训练 32K 上下文；指令模型依次进行 SFT 与 DPO。
  • 稀疏计算与专家并行：公开推理栈在 vLLM 中集成块稀疏计算，并说明将 Token 分发到专家所在设备的并行方式。

模型效果(Mixtral 8x7B Base，论文统一评测)

  • 相比 Llama 2 70B，HumanEval 29.3 → 40.2、MBPP 49.8 → 60.7、MATH 13.8 → 28.4。
  • Mixtral 8x7B Instruct 经 SFT/DPO 后，MT-Bench 为 8.30，同表 GPT-3.5 Turbo 1106 为 8.32。

重要结论

  • 激活计算量与存储量不同：约 13B 活跃参数降低计算，但模型仍需存储约 47B 参数，部署收益取决于批量和设备条件。
  • 专家并未明显按语义领域分工：不同文本领域的路由分布相近；相邻 Token 与相同语法结构更常选择相同专家。

关键贡献

  • 开放 Base / Instruct 权重，展示小激活量的稀疏 MoE 在通用、代码与多语言任务上的有效性。

未来方向

  • 利用路由的局部性优化缓存，同时处理专家并行时局部集中带来的负载不均。

问题背景 ​

参数容量与逐 Token 计算量
  • Dense 扩容成本高：模型每一步都调用所有参数，增大模型会直接增加解码计算。
  • MoE 的目标：保留更多可学习参数，但每个 Token 只经过少数专家，使模型容量与活跃计算量部分解耦。
  • 系统成本仍存在：专家权重需要存储，路由需要通信；实际吞吐还取决于专家负载与批量大小。

核心方法 ​

Token 级 Top-2 稀疏专家 ​

共享 Attention，替换 FFN

网络配置

  • 32 层、隐藏维度 4096、FFN 中间维度 14336；32 个 Query Heads、8 个 KV Heads，Head Dimension 为 128。
  • 使用 GQA，词表 32000，完整 Attention 的上下文长度为 32768。
  • 每层包含 8 个独立 SwiGLU 专家；同一 Token 在不同层可以选择不同专家。

路由与计算

  • 对 Token 表示做线性投影，得到 8 个路由分数；仅保留 Top-2，其余设为负无穷，再做 Softmax。
  • 两个专家输出按路由概率加权求和；Attention 与其余模块不随专家复制。
  • 因此总参数约为 47B，每 Token 活跃参数约为 13B。
Top-2 路由
g(x)=Softmax(Top2(xWg)),y=∑i=18gi(x)SwiGLUi(x)
  • 蓝色操作只保留两个最高分专家；其余专家权重为零。
  • 固定激活专家数时，增加总专家数主要扩大参数容量，不同比例增加逐 Token FFN 计算。

多语言预训练与 SFT/DPO ​

Base 与 Instruct 的训练分工

预训练

  • 沿用 Mistral 7B 的总体设计，增加多语言数据的采样比例，覆盖英语、法语、德语、西班牙语和意大利语。
  • 从训练阶段支持 32K 上下文，长文本能力通过 Passkey Retrieval 与 ProofPile 困惑度评估。

指令对齐

  • 首先在指令数据上进行 SFT，再用偏好成对数据进行 DPO，得到 Mixtral 8x7B Instruct。
  • DPO 提高偏好回答相对非偏好回答的概率，改善指令执行与对话质量。

稀疏计算与专家并行 ​

让不等量 Token 进入专家
  • 块稀疏计算：公开推理栈在 vLLM 中集成 MegaBlocks CUDA Kernels，用稀疏矩阵计算处理不同专家接收到不同数量 Token 的情况。
  • 专家并行：不同专家可分布在不同 GPU，先分发 Token，再回收专家输出完成加权合并。
  • 适用场景：较大的批量有利于提高专家矩阵运算的算术强度；单次低批量请求仍需要访问更多模型权重。
  • 负载约束：Top-2 路由会使 Token 集中到部分专家，部署与训练都需要关注专家利用率及通信。

实验设置 ​

分开比较 Base 与 Instruct
  • Base 对照：Mistral 7B、Llama 2 7B / 13B / 70B；表 2 中的 Llama 2 使用作者评测代码重新运行。
  • 代码：HumanEval 为 0-shot；MBPP 为 3-shot，使用人工核验的子集。
  • 知识与数学：MMLU 为 5-shot；表 2 的 GSM8K 为 8-shot / maj@8，MATH 为 4-shot / maj@4。
  • 指令模型：MT-Bench 与 Chatbot Arena；Arena 仅对应 2023-12-22 的榜单快照。
  • 长上下文：在不同位置、不同上下文长度插入 Passkey；另用 ProofPile 观察上下文增长时的困惑度。

关键结果(Mixtral 8x7B + 多语言预训练/SFT/DPO) ​

Base：较低活跃参数量下的代码与数学表现

Llama 2 70B → Mixtral 8x7B

  • MMLU：69.9 → 70.6。
  • HumanEval：29.3 → 40.2；MBPP：49.8 → 60.7。
  • MATH：13.8 → 28.4；GSM8K：69.6 → 74.4，均为表 2 的多数投票口径。
  • 多语言 MMLU：法语 64.3 → 70.9、德语 64.2 → 71.5、西班牙语 66.0 → 72.5、意大利语 65.1 → 70.9。

指令与长上下文

  • Instruct 的 MT-Bench 为 8.30，Llama 2 70B Chat 为 6.86。
  • Passkey 在 32K 范围内不同插入位置均达到 100%；ProofPile 困惑度随可用上下文增加而下降。
路由观察：语法结构与相邻 Token 更相关
  • 领域分工不明显：ArXiv、PubMed、PhilPapers 等数据的专家调用分布接近，不能把 8 个专家直接解释成 8 类知识领域。
  • 局部路由集中：Python 的 self、缩进和英语中的重复结构呈现相似专家选择。
  • GitHub 第 15 层：相邻 Token 的首选专家重复率为 28.1%，随机基线为 12.5%；两个专家集合有交集的比例为 66.9%，随机基线约 46%。
  • 工程含义：局部性有利于缓存，但在专家并行中也可能把连续 Token 集中到少数设备；这是论文提出的系统优化切入点。

未来方向 ​

作者提出的系统问题
  • 研究如何利用相邻 Token 的路由局部性，提高专家计算与缓存的效率。
  • 在专家并行中缓解局部路由集中造成的负载不均，改善训练和推理吞吐。
总访客数：— · 总访问量：—
PLM's Blog @ 2016 - 2026