Mid-train 技术综述与落地手册：面向有 post-train 经验的基模团队

作者流程：作者初稿 -> 技术专家挑刺 -> 编辑挑刺 -> 作者修订
时间范围：近两年公开资料，重点覆盖 2024-06-29 至 2026-06-29
目标读者：有 post-train 经验、准备承担 mid-train 的基模团队；也适合 Model / Data / Training / Eval / Post-train DRI 协作使用 结论性质：技术研究与工程参考，不构成任何商业或投资建议

使用导航 / 主线地图

这篇文章不是必须从头读的文献综述，而是一套 gate-driven 启动手册。若今天要开 mid-train 启动会，先读 0.2、0.3、8、9；若要设计数据和实验，读 4.2-4.6、6、11；若训练已经出事故，直接读 7；若要核查公开资料和引用边界，读 2、3、12。

主线只有一条：先证明目标值得 mid-train，再证明数据和评估可信，再证明短程训练有效，最后证明 post-train 后收益仍保留。

0. 摘要

Mid-train 不是 post-train 的放大版，也不是简单把 pretrain 再跑一段。本文采用一个保守的工程定义：

Mid-train 是 base pretrain 后、SFT/RL 等 post-train 前的一段受控继续训练，用来改变模型的能力分布、上下文适应能力，以及后续 SFT/RL 可利用的可训练性。

公开资料中，OLMo 2 明确把 base pretraining 之后、post-training 之前的阶段称为 mid-training；Qwen3、DeepSeek-V3、Llama 3、Qwen2.5-1M 等报告并不总使用这个词，而是称为 pre-training、continued pre-training、context extension 或 long-context pre-training。本文只在工程意义上把这些阶段归入 mid-train-like 范畴，不能等同于原报告术语。

实践上，新团队不应先追大规模训练，而应先做小模型 ablation、数据桶验证、污染检查、base 回归评估，再用主模型短程训练验证方向，并用固定 post-train recipe 检验收益是否保留。Mid-train 的成功标准不是某个 base benchmark 上涨，而是能力增强、遗忘可控、post-train 后收益仍存在。

边界上，本文不把所有 continued pretraining 都等同于 mid-train，也不把 DCA、YaRN、sparse attention、chunked prefill 等推理或架构技巧简单归为训练配方。公开案例只能作为设计参考，不能照搬为 recipe。

文中的数据比例、token budget、90 天路线图、质量门和事故 runbook 均为面向新团队的工程起步建议，不是公开论文直接给出的通用结论。

对一个有 post-train 经验、准备承担 mid-train 的基模团队，最重要的不是立刻上大规模训练，而是先建立四件事：

1. 明确目标能力和不可牺牲能力：例如数学提升不能以通用对话、事实知识、多语能力大幅退化为代价。
2. 做小模型和短程 ablation：先验证数据桶、学习率、序列长度、污染控制和遗忘风险。
3. 建立 mid-train 专用评估：不能只看 pretrain loss，也不能只看 post-train 后的榜单。
4. 让 Post-train DRI 接力验证：mid-train 的成功标准之一，是 SFT/RL 后收益仍能保留、训练更可控，而不只是 base checkpoint 某几个 zero-shot 分数更好。

0.1 读者决策树：你到底该做哪类 mid-train

这个决策树是执行入口，不是排他分类。一个成熟项目最后可能同时包含 capability shaping、long-context adaptation 和 post-train readiness，但第一轮最好只验证一个主假设。

0.2 第一天怎么启动

如果今天就要启动 mid-train 项目，不要先开训练。第一天只做 7 件事：

1. 拉齐 Model、Data、Training Infra、Eval、Post-train、Safety/Compliance、Product/Domain 的 DRI。
2. 写一页 Mid-train charter：目标能力、不可牺牲能力、为什么必须在 mid-train 做、预算边界。
3. 冻结 eval registry 的 v0 owner 和 schema；训练前再冻结 v1 eval registry，包括 base eval、专项 eval、长上下文 eval、私有 holdout、人工样例审查。没有 v1，不进入 Gate 1。
4. 让 Post-train DRI 冻结 paired protocol 的 v0 owner 和 schema；训练前再冻结 v1 paired protocol，包括 SFT/RL 数据版本、训练预算、seed、harness、评估集和失败判定。
5. 创建实验台账 schema，规定没有台账的实验不进入结论。
6. 定义 Gate 0-5 的通过条件、阻断条件和签字人。
7. 明确第一周不允许做什么：不边看私有 holdout 边调参，不在同一个实验 ID 下改 mix/过滤器/eval 版本，不把 proxy 成功当成主模型必然成功。

0.3 如何使用本文：按角色和任务跳读

这篇文章可以从头读，也可以当内部手册查。第一次启动 mid-train 项目时，建议按角色分工阅读：

如果只开一次 90 分钟启动会，会议不要讨论“大概要训多少 token”，而是按下面顺序收敛：

1. 术语边界：什么是 mid-train

1.1 一个实用定义

本文采用工程定义，而不是术语洁癖式定义：

Mid-train 是 base pretrain 后、post-train 前的继续训练阶段。它仍主要使用语言建模目标或其变体，但数据、学习率、序列长度和能力目标已经从“最大覆盖世界文本”转向“高质量能力塑形”。

这一定义覆盖几类公开实践：

• late-stage pretraining / annealing：在较低学习率下，用高质量数据继续训练，追求更低损失和更强下游能力。
• domain / capability continued pretraining：围绕代码、数学、STEM、医学、法律、金融、多语等能力继续训练。
• long-context extension：在原 base context 上扩展到 32K、128K、256K 等，配套位置编码、attention 优化和长文档数据；若目标是 1M 级上下文，应单独验证训练长度、位置/attention 外推、chunked prefill、KV cache 和 serving 成本，不能写成单纯继续训练或数据配方。
• reasoning-oriented mid-train：用数学、代码、合成推理、教材式数据、QA/CoT 等让 base model 更适合后续 RL 或 RLVR。

Mid-train 和 continued pretraining 有重叠，但强调点不同：continued pretraining 描述“训练从哪里接着跑”；mid-train 更强调“为什么跑、用什么数据塑形、如何服务 post-train”。

1.2 它和 post-train 的分工

Post-train 团队容易把 mid-train 想成“更多 SFT 数据”或“更早一点的 SFT”。这是危险的，因为两者优化对象不同。

Mid-train 关注：

• 模型内部是否有解决问题所需的知识、算法模式和表征能力。
• 长上下文中位置编码、attention、检索和跨段归纳是否可用。
• 代码、数学、工具轨迹、复杂指令的基础分布是否进入模型参数。
• 后续 SFT/RL 是否更容易把能力激发出来。

Post-train 关注：

• 指令遵循、回答风格、安全拒答、偏好排序。
• 多轮对话和用户意图对齐。
• 推理过程是否外显、是否符合产品策略。
• RL/RLHF/RLAIF/RLVR 中的 reward 可优化行为。

粗略说，mid-train 更偏向改变能力可达性和参数内分布，post-train 更偏向改变任务接口、行为策略和产品呈现；但在 reasoning、tool use、agent 和长上下文任务上，两者会交叠，必须用 paired protocol 判断收益来自哪里。

1.3 不宜把所有训练都叫 mid-train

本文不把以下情况简单归为 mid-train：

• 从零开始的大规模通用预训练。
• 单纯为了对齐、安全或格式的 SFT。
• 只在 post-train 数据上继续跑语言建模，但没有能力目标、数据控制和回归评估。
• RAG、外部工具、推理时 search 等不改变模型参数的系统工程。

边界要清楚，否则团队会用 post-train 的评估和组织方式管理 mid-train，最后很难判断收益来自哪里。

1.4 给有 post-train 经验的基模团队的 10 条差异认知

1. Mid-train 的对象是能力分布，不是回答风格。
2. Mid-train 的主损失通常仍接近语言建模目标，不是偏好优化。
3. Mid-train 数据可以包含 QA/CoT/FIM，但不要把 SFT 数据整体前移。
4. Mid-train 的好 checkpoint 不一定是 loss 最低 checkpoint，而是能力提升和遗忘之间的 Pareto 点。
5. Mid-train 的收益必须在 base eval 和 post-train readiness 中同时观察。
6. 数据污染在 mid-train 中比 SFT 更危险，因为它会进入 base 能力判断。
7. 合成数据要先被验证和分层，不应因为“便宜”而提高比例。
8. 长上下文能力要区分训练长度、推理外推长度和线上可服务长度。
9. RL 的收益通常依赖 base 已有可达能力区间，不能把所有 reasoning 问题推给 RL。
10. 放大训练前必须有停止条件；mid-train 不是“预算还没花完就继续跑”。

2. 公开证据强弱分层

公开材料不完全一致，最容易出错的地方是把“报告明确写出的训练阶段”“研究者的归纳”和“访谈里的行业经验”混为一谈。本文按证据强弱分三层使用资料。

2.0 本文的证据标签

为避免把公开事实和工程推断混在一起，后文默认使用四类证据标签：

读者在使用本文时，应把“报告事实”当作事实底座，把“论文归纳”和“工程归纳”当作实验设计输入，把“待验证假设”当作 backlog。任何会消耗大规模训练预算的决策，都应回到团队自己的 data manifest、eval registry 和 post-train paired protocol。

2.1 强证据：技术报告明确披露的阶段设计

强证据指模型团队在技术报告中直接披露的训练阶段、token 规模、上下文长度或数据策略。

这些报告能支撑“阶段设计”的存在，但通常不能支撑“照搬数据比例或学习率”。未公开的 tokenizer、数据清洗、采样策略、基础 checkpoint 状态、优化器状态和系统实现，都会显著影响结果。

2.2 中证据：综述和受控实验的归纳

Mid-training survey、PRISM 以及 pre-training / mid-training / RL interplay 这类研究能帮助团队理解变量关系：数据保留与能力迁移、能力是否位于模型可达边界、RL 是否能从 mid-trained checkpoint 获益等。

这些研究的价值是提出机制假设和实验维度，而不是给出可直接外推的产业配方。尤其是受控 synthetic task 或小规模模型上的结论，不能直接升级成“所有大模型训练定律”。

2.3 弱证据：访谈、博客和行业口径

访谈和博客通常能提供两类信息：术语如何被从业者使用，以及团队如何描述训练阶段的组织逻辑。但这类资料常常省略失败实验、数据细节和工程约束，所以只能作为趋势背景，不能作为硬事实。

如果访谈声称某个阶段“非常重要”，本文会把它当作待验证假设；只有技术报告、可复现实验或团队内部 ablation 支持后，才进入训练决策。

2.4 从公开资料抽出的保守共识

第一，mid-train-like 阶段通常发生在 base 能力形成之后、post-training 之前。OLMo 2 是狭义样本；Qwen3、DeepSeek-V3、Qwen2.5-1M、Llama 3 是工程上相近但术语不同的样本。

第二，在 OLMo 2、Qwen3、Phi-4、Llama 3 等案例中，late-stage / continued pre-training 往往伴随更强的数据筛选、能力定向采样或高质量数据上调；但 DeepSeek-V3 这类 context extension 案例主要支持阶段化长度扩展，不直接支持数据配比结论。更稳妥的说法是：晚期 token 的边际价值更依赖质量、配比和训练目标，而不是简单追加 web tokens。

第三，长上下文不是只改 RoPE scaling。真实长上下文能力需要训练数据、长度 curriculum、位置/注意力机制、推理框架和评估任务共同成立。DCA、YaRN、sparse attention、chunked prefill 等技术要区分其作用位置：有些影响训练可行性，有些主要服务推理外推和部署成本。

第四，reasoning mid-train 更适合作为“提高 RL 可用 substrate”的强工程假设，而不是已被证明的普遍定律。较保守的说法是：如果 base/mid-trained checkpoint 对目标任务完全没有可解性，RL 通常很难稳定地产生能力；但 RL 是否带来真实能力增益，还取决于 pretraining 暴露、任务是否位于模型能力边界、reward 设计和探索预算。

第五，合成数据有价值，但不是免费午餐。Phi-4 说明 synthetic data 可以显著影响 reasoning 表现，也提醒团队仍需要有机数据来补世界知识、表达多样性和真实分布。

第六，透明的实验台账比单点榜单更重要。OLMo 2 这类报告的最大价值之一，是把 pretraining、mid-training、post-training 和数据构成分开描述，帮助后来团队建立自己的 lineage、分桶 loss 和回归评估。

第七，公开报告能证明“某些成熟团队采用了阶段化 late-stage training”，但很少能证明“某个数据比例、学习率或 token budget 是通用最优”。本文后续所有 recipe 表都应读作搜索空间和质量门，而不是从某个模型报告复刻出的配方。

3. 公开案例能证明什么，不能证明什么

本章不是模型报告复述，也不是 recipe 来源。它只回答一个问题：公开案例能给新团队的 mid-train 项目提供哪些证据，哪些不能外推。先看案例证据总表；只有要核查事实边界时，再读逐案例说明。

本章案例只回答“公开材料能证明什么、能启发哪些内部实验变量”，不提供可复刻训练配方。凡涉及 token 数、context 长度、数据类型或阶段顺序的内容，均先按报告事实记录；只有经过团队自己的 data manifest、eval registry、proxy ablation 和 post-train paired protocol 验证后，才可进入训练决策。

3.1 OLMo 2：最清楚的 mid-training 公开范式

OLMo 2 明确把第二阶段称为 mid-training：第一阶段是大规模预训练，第二阶段使用 Dolmino Mix 等高质量数据混合进行训练，然后再做 instruction tuning 和 preference tuning。报告还披露了 50B/100B/300B 等 mid-training token 样本、micro-annealing 和 checkpoint averaging 等细节。它最适合作为公开透明的参考样本，而不是所有团队的默认组织模板。

可转化为内部假设/检查项：

• 将 mid-train 独立成一个有输入输出、有 eval gate 的阶段。
• 不把所有数据混在一起，而是明确区分 Dolma、DCLM、StarCoder、OpenWebMath 等来源。
• 在 post-train 前保留 base checkpoint 的独立评估。
• 使用 micro-annealing 等小规模后期训练实验，帮助判断是否值得把配方放大。

不能外推的部分：

• OLMo 2 的公开配方不等于所有团队的最优配方。它的价值是透明和可学习，不是可直接复制。
• 其数据结构偏开源英文生态，中文、多语、工具使用、agentic coding 等目标需要重做数据桶。

3.2 Qwen3：General -> Reasoning -> Long Context

Qwen3 技术报告把相关阶段称为 Pre-training Stage，而不是 mid-training。报告披露的三阶段路线是：

• General Stage：总预训练约 36T tokens，其中 S1 超过 30T tokens，覆盖通用语言知识。
• Reasoning Stage：约 5T 高质量 STEM、代码、推理和合成数据，增强任务相关能力。
• Long Context Stage：数千亿长上下文 tokens，把训练长度扩展到 32K。

这说明一个成熟团队会把 late-stage training 设计成多个能力目标，而不是一个单一“继续训练”阶段。

可转化为内部假设/检查项：

• 把能力型 mid-train 和长上下文 mid-train 分开设计。
• 第二阶段更像 capability shaping，第三阶段更像 context adaptation。
• 区分训练长度和推理支持长度：Qwen3 报告中的训练阶段扩到 32K；ABF 是 RoPE base frequency 调整，YaRN 和 DCA 用于进一步支持更长推理长度。
• 评估也应分开：STEM/代码/推理看专项 benchmark 和真实任务；长上下文看长文档、长代码和多证据任务。

不能外推的部分：

• Qwen3 的完整数据配比没有完全公开，不能把其宏观阶段当成可复制 recipe。
• “优先做能力增强还是长上下文”取决于产品目标。若产品目标不是长上下文优先，且已有 context 能满足主要任务，再优先做 capability shaping。

3.3 DeepSeek-V3：大规模 base 后的 context extension 和工程约束

DeepSeek-V3 报告给出了两个对 mid-train 很重要的信号：

• 14.8T 高质量、多样 token 对应 base pre-training 阶段。
• 在 base pre-training 后，使用 YaRN 做两段 long-context extension，每段 1000 steps，先从 4K 扩到 32K，再从 32K 扩到 128K。

此外，DeepSeek-V3 的训练还包含 MLA、DeepSeekMoE、auxiliary-loss-free load balancing、MTP 等架构和训练设计。对 mid-train 团队来说，这提醒我们：如果 base 架构、位置编码、MoE 路由、attention memory 和推理框架不支持，后期数据再好也可能达不到目标。

可转化为内部假设/检查项：

• 长上下文扩展应分阶段，不宜一步拉到目标长度。
• Context extension 前要确认推理框架和 attention kernel 可承载训练后的部署形态。
• 多目标训练时要监控 MoE load balance、训练稳定性和各数据桶 loss。

不能外推的部分：

• DeepSeek-V3 是从架构到训练都深度协同的大系统，不能把长上下文阶段孤立出来照搬。
• 其报告中很多关键效率来自系统和架构，数据/训练阶段只是整体的一部分。
• 128K 能力展示包含 NIAH 等测试，不能单独证明真实长文档、长代码和线上 serving 的全部能力。

3.4 Phi-4：synthetic-heavy training strategy，而不是干净的 reasoning mid-train

Phi-4 更适合作为 synthetic-heavy training strategy 的案例，而不是一个干净的“reasoning mid-train”配方。报告确实强调 synthetic data for pretraining and midtraining；同时，显式 midtraining stage 主要承担长上下文扩展，把 context 从 4K 扩到 16K，并训练约 250B tokens。本文对 reasoning 增益的表述是工程归纳：公开报告能支持合成数据、课程设计、数据混合和 post-training 都很重要，但不能精确归因各部分贡献。

可转化为内部假设/检查项：

• 数学、代码、逻辑推理、教材式解释非常适合引入可验证或半可验证合成数据。
• 合成数据最好有生成、过滤、验证、去重、难度分层和风格多样化流程。
• 小模型上先看合成数据占比、题型难度、解答长度、正确性过滤对最终能力的影响。

不能外推的部分：

• 合成数据会放大 teacher model 的偏见和错误。
• 如果生成模板单一，模型会学到“看起来像推理”的表面格式。
• 对开放域知识、真实用户 query 和多语言表达，仍需混入高质量有机数据。

3.5 Qwen2.5-1M：训练扩展、推理外推和部署优化要分开

Qwen2.5-1M 报告展示了长上下文能力如何由训练、post-training、推理外推和部署系统共同构成。需要特别避免一个误读：1M context 不是简单通过 mid-train 数据直接训出来的，但也不能说训练不重要。

更准确的拆法是：

• Long-context pre-training：采用 progressive pre-training，大致按 4K -> 32K -> 64K -> 128K -> 256K 的长度路线推进，并使用自然长文档、合成长上下文任务和长度分布 curriculum。
• Post-training：用长指令数据和多阶段 post-training 让模型更会在长上下文中完成用户任务。
• Inference / deployment：1M 支持来自 256K long-context training 与 DCA/YaRN 外推的组合；稀疏注意力、chunked prefill、vLLM/BladeLLM 适配主要服务部署成本，而不是普通意义上的 mid-train 数据配方。

可转化为内部假设/检查项：

• 长上下文是模型、数据、训练、推理框架四件事共同定义的能力。
• 从 4K 直接到 1M 风险极高，建议先按 8K/16K/32K/128K/256K 逐步验证训练与推理的一致性。
• 评估要避免单一 needle 指标，应包含复杂长文档 QA、长代码、表格、跨段推理和鲁棒性测试。

需要注意：

• 1M context 的成本和部署复杂度非常高，不一定适合所有产品。
• 对多数团队，32K/128K 高质量可用性可能比 1M 展示能力更有商业价值。

3.6 Llama 3：initial pre-training + long-context + annealing 的保守样本

Llama 3 系列报告没有把相关阶段称为 mid-training，但它给了一个有价值的保守样本。以 405B 模型为例，报告披露 initial pre-training 使用 8K context、约 15.6T tokens；随后 long-context pre-training 约 800B tokens，从 8K 分六段扩展到 128K；最后 40M tokens 做学习率 annealing 到 0，并保持 128K context、上调部分高质量数据。

可转化为内部假设/检查项：

• late-stage training 可以同时承担长上下文适应和质量收敛，但必须持续做通用能力回归。
• annealing 不是“再训一点”的口号，而是和数据质量、学习率、checkpoint 选择绑定的阶段。
• 如果团队保守，Llama 3 的启示不是追求复杂花活，而是把继续训练、长上下文和末期收敛拆成可观测步骤。

不能外推的部分：

• Llama 3 报告里的具体 token 数和数据配方依赖其大规模基础训练，不宜迁移成小团队默认预算。
• 其长上下文和后续指令模型能力也受到 post-training 和系统实现影响。

3.7 PRISM 与 pre/mid/RL 研究：把机制假设当假设

PRISM 和 pre-training / mid-training / RL interplay 这类论文的价值，是把几个长期靠经验讨论的问题变成可实验的问题：mid-training 如何影响 retention，哪些能力在继续训练中相互促进或相互干扰，RL 是否依赖 pre/mid 阶段已经暴露过的能力边界。

可转化为内部假设/检查项：

• 把“保留旧能力”和“注入新能力”拆成两个指标，不要只看目标能力增长。
• 把任务是否位于模型 edge-of-competence 作为 RL 前置检查。
• 把 controlled experiment 的结论作为 ablation 设计参考，而不是直接作为主训练结论。

需要注意：

• 这类论文通常规模、任务和数据分布都受控，外推到产业模型时必须重新验证。
• 对 reasoning 的判断尤其要保守：RL 可能放大已有能力，也可能放大奖励漏洞和格式偏差。

4. Mid-train 的设计框架

本章先按第一轮最小闭环来读：Gate 0 冻结目标能力、不可牺牲能力、eval registry 和 post-train paired protocol；Gate 1 冻结 data manifest；Gate 2 用 control mix + 3-5 个单变量变体在 proxy scale 排除坏方向；Gate 3 用 target model 短程训练寻找能力/遗忘 Pareto checkpoint；Gate 4 用同一套 frozen post-train paired protocol 验证收益是否保留。4.1-4.6 分别解释这个闭环中的目标、数据、训练旋钮、ablation、curriculum 和组织质量门。

一个可执行的 mid-train 项目，最终应回答五个问题：目标能力是什么，哪些能力不能退化，能力由哪些数据桶驱动，训练长度/学习率/context curriculum 如何设置，以及如何证明它对 post-train 有帮助。

4.0 第一轮最小闭环

第一次做 mid-train 时，不要先设计完整训练系统。这里的“最小闭环”不是最小训练配方，而是最小证据链：用尽可能小的实验代价验证数据、训练、评估和 post-train 接力是否能形成可解释结论。先跑通一个目标、一个主假设、一组数据桶、一套 eval registry、一个短程训练窗口、一个 frozen post-train paired protocol。

第 11 章给出的是这个闭环的一组示例搜索网格，不是默认配方。第 4 章先讲设计对象，第 6-8 章讲如何判断证据，第 11 章才给可执行起步样例。

4.1 能力目标分层

建议把目标分成四层：

第一层：通用 base 保真

• 通用语言建模 loss 不异常上升。
• 常识、事实、多语、基础指令理解不明显退化。
• 多轮对话虽然不是 mid-train 主目标，但基本可读性不能崩。

第二层：核心能力增强

• 数学：GSM8K、MATH、AIME 类，以及内部可验证题库。
• 代码：HumanEval、MBPP、EvalPlus、repo-level completion、FIM、多文件定位等；SWE-bench 更适合在固定 harness、轻量 instruction wrapping 或 post-train readiness 阶段使用。
• STEM：GPQA、MMLU-Pro、领域题库。
• 推理：BBH、ARC、逻辑推理、复杂 QA。

第三层：结构能力

• 长上下文检索、综合、冲突消解。
• FIM、代码补全、多文件编辑。
• 表格、日志、长 PDF、长会议纪要理解。

第四层：post-train readiness

• SFT 后是否更容易学会目标格式。
• RL/RLVR 后是否更稳定提升。
• reward hacking 是否减少。
• 推理轨迹是否更可控。

4.2 数据桶设计

建议至少建立以下数据桶：

不要只做一个全局 mix。每个桶要有：

• 数据来源和 license 记录。
• 去重策略。
• 质量打分。
• contamination 检查。
• 采样比例。
• 单独 loss。
• 对应 eval。

4.2.1 数据桶准入卡

每个数据桶进入训练前，都应先进入 data manifest，而不是直接进入 mix。最小字段如下：

数据桶准入门建议写成硬规则：

• 没有 manifest/hash，不进入训练。
• 没有对应 eval，不提高采样权重。
• 污染命中未处理，不进入 primary 实验。
• 合成数据没有正确性过滤和风格多样性检查，不超过低比例探索。
• 领域数据没有通用回归保护，不进入主模型短程。
• 长上下文数据只有拼接文本、没有真实长任务，不进入 long-context primary mix。
• 任何改过滤器、质量模型、dedup 阈值、采样权重、合成生成 prompt 或数据顺序的动作，都必须生成新的 data_manifest_hash 和 experiment_id。

4.2.2 合成数据使用边界

合成数据需要单独治理，因为它最容易在短期指标上“看起来很有效”：

合成数据的合理用法是“可验证能力放大器”，不是低成本 token 替代品。数学、代码、结构化推理适合多用可验证合成；开放域知识、语言风格、多语表达仍需要高质量有机数据兜底。

不同合成数据类型的边界也不同：

Synthetic bucket 还必须记录 teacher model/version、生成 prompt、采样参数、verifier 版本、过滤规则、被拒样本比例、模板重复率、答案可验证率、人工抽检错误率，以及生成器是否读过 eval/benchmark。合成 CoT/QA 要额外检查 style entropy、template n-gram 和 response length distribution，避免把 post-train 行为格式提前固化。

4.3 学习率和 token budget

公开报告通常不会完整给出所有细节，但工程上有几条稳健原则。

第一，mid-train 通常不应使用接近 pretrain 初期的高学习率。模型已经形成大量通用能力，过高学习率会导致遗忘、风格漂移和 loss spike。

第二，学习率策略要和目标匹配：

• 短程能力增强：低学习率继续训练，观察专项能力和通用回归。
• late-stage annealing：进一步降低学习率，用高质量数据收敛。
• context extension：学习率更保守，并配合长度 curriculum。
• domain adaptation：更要限制 token budget 和数据比例，避免模型变窄。

第三，token budget 不是越大越好。下面三档只是启动实验的保守刻度，不按模型规模线性通用，也不能替代 scaling ablation：

• 1B-10B tokens：用于 pipeline、数据质量、LR、污染检查和 proxy ablation。
• 10B-100B tokens：作为可观察能力增强和中小模型 recipe 验证的示例区间，实际预算要由模型规模、数据质量和 gate 结果决定。
• 100B-1T+ tokens：才适合主模型较完整的 capability shaping 或 long-context extension。

以上不是行业定律，而是工程上较保守的起步刻度。真正 token budget 应由模型规模、数据质量、目标能力和预算共同决定。

4.3.1 配方旋钮与不可同时改变原则

训练变量也要像数据和 eval 一样冻结版本。每次 run 至少记录：

Scale-up 也要保守。Proxy 成功只能说明某个方向值得继续，不说明目标规模必然成功。进入更大训练前至少满足四个条件：

1. 两个 scale 或 target 短程 run 的方向一致。
2. 分桶 loss、目标 eval、base regression 的变化能被同一个数据/训练假设解释。
3. 相同 mix 下不同 seed 不反转，训练吞吐、checkpoint resume 和监控已经验证。
4. 成本上可接受：如果放大 10 倍 token 后只可能换来边际小幅收益，就应先改善数据或 eval，而不是加预算。

一次实验不要同时改太多旋钮。建议把常见旋钮拆开看：

4.4 第一轮 ablation 设计表

第一轮不要追求“最好配方”，而要快速排除错误方向。下表中的比例只是搜索变量示例，用来暴露灵敏度和坏方向，不能作为主训练默认 mix。

这些实验的产出不是最终模型，而是决策：哪个数据桶有效，哪个比例危险，哪个学习率区间安全，是否值得进入更长主训练。

4.4.1 如何读 ablation

Ablation 的产出是排除坏方向和形成候选 Pareto，不是证明最终配方。建议按五条规则判读：

1. Proxy 成功不等于 target 成功；进入主模型前需要两个 scale 方向一致，或 target 短程 run 复核。
2. 单一公开榜上涨不等于能力增强；必须和 private holdout、失败样例簇、人工审查一起看。
3. Target 能力提升必须和 guardrail 一起看；数学/代码涨而多语、事实、自然生成明显跌，不算干净收益。
4. 接近阈值的结果要重复 run 或相邻 checkpoint 复核；不要用一次 seed 的小幅收益做放大决策。
5. 任何中途改 mix、filter、LR、长度 curriculum 或 eval 版本的实验，都必须重开 experiment_id。

4.5 Curriculum：先能力，后长度，还是并行？

建议新团队不要一开始把所有目标混在一起。

更稳的顺序是：

1. Base 保真检查：确认 checkpoint、tokenizer、optimizer state、数据 pipeline、评估体系可用。
2. 能力型 mid-train：数学/代码/STEM/高质量合成数据，短程 ablation。
3. 长上下文适应：从较短 context 逐步拉长，单独监控长上下文 loss 和真实任务。
4. 小规模 post-train 接力：用固定 SFT/RL recipe 比较 mid-train 前后 checkpoint。
5. 决定是否合并为主训练配方。

为什么建议先能力后长度？因为长上下文训练成本高、debug 难，而且容易把架构和数据问题混在一起。如果模型基础 reasoning/代码能力没有改善，长上下文只是放大输入窗口，不一定放大任务能力。

也有例外：如果产品目标就是法律/金融长文档 QA 或代码库 agent，长上下文可以前置，但仍建议先在小模型上验证。

长上下文 curriculum 要记录长度分布，而不是只记录最大长度。每个阶段至少记录：

• 4K/16K/32K/64K/128K 样本比例。
• packing 策略、padding 浪费、短样本是否被过度上采样。
• 长样本来源：自然长文档、长代码、合成长任务、跨文档集合。
• 任务结构：证据密度、不可回答样本、冲突证据、多跳证据、证据位置、输出长度。
• 训练 kernel 与推理 kernel 是否一致。

否则“扩到 128K”只是一个最大长度声明，不能解释模型到底学到了长上下文理解、长距离检索，还是只学会在更长输入里保持 loss 不崩。

4.6 组织运行机制：角色、台账和质量门

Mid-train 项目不是训练团队单独完成的模型续训，而是 data、training、eval、post-train 四方共用同一张实验台账、同一组质量门的能力塑形项目。每个组织概念都必须绑定工程对象：checkpoint、data manifest、eval version、gate、owner 和 decision。

第一，设定 DRI，而不是泛泛“多团队参与”。

第二，实验台账要有固定 schema。没有台账的实验不进入结论；任何中途改 mix、改过滤器、改 eval 版本，都必须新建 experiment_id。

第三，质量门的唯一权威看板放在第 8.0 节；本节只定义角色、台账字段和签字责任。本文不能替团队设阈值，但 gate memo 至少要定义：目标能力最低提升、通用能力最大回撤、私有 eval 通过率、污染命中率上限、loss spike 处理规则、风格漂移判定、post-train 后收益保留比例。任何 gate 状态、证据路径、版本 hash 和过期时间，都以第 8.0 节 dashboard 为准。

第四，会议节奏要服务决策，不服务汇报：

• Daily training review：loss、吞吐、NaN/loss spike、checkpoint、resume、事故处理。
• Twice-weekly eval review：目标能力、通用回归、私有 holdout、人工样例审查。
• Weekly decision review：kill、retry、extend、promote，只基于台账和 gate memo 决策。
• Post-train handoff review：paired protocol 是否有效，收益是否保留，安全和风格是否退化。

这套机制的底线是：日历不能替代质量门。90 天只是参考节奏，是否进入下一阶段由数据就绪度、训练稳定性、eval 稳定性和 post-train 接力验证决定。

5. 训练工程检查点

5.1 启动前检查

启动 mid-train 前，应完成：

• Base checkpoint 的完整 eval 快照。
• Optimizer state 是否接续的决策。
• Tokenizer 和 special tokens 冻结。
• 数据去重和 benchmark contamination 检查。
• 每个数据桶的样例审查。
• 小规模 dry run，确认 loss、吞吐、显存、checkpoint、resume 正常。
• Post-train DRI 确认后续 SFT/RL 的 paired protocol。

如果没有 post-train 接力验证，mid-train 很容易优化错目标。

5.2 训练中监控

至少需要监控：

• 全局 training loss / validation loss。
• 按数据桶分解的 validation loss。
• 通用能力 benchmark 的回归。
• 目标能力 benchmark 的增益。
• 长上下文不同长度段的 loss。
• 生成样例的风格漂移。
• MoE 模型的专家负载、路由熵和 token drop。
• 梯度范数、loss spike、checkpoint 间差异。

不要等训练结束才做 eval。Mid-train 的失败常常在早期就有信号：通用 eval 大跌、输出风格模板化、某个数据桶 loss 异常、长上下文短任务退化。

5.3 Checkpoint 策略

建议保留：

• pre-mid checkpoint。
• 每个阶段的 early/mid/final checkpoint。
• 学习率变化前后的 checkpoint。
• context length curriculum 每个长度阶段的 checkpoint。
• 用于 post-train 接力的候选 checkpoint。

不要只保留最后一个。Mid-train 的最佳 checkpoint 可能不是 loss 最低的 checkpoint，而是目标能力和遗忘之间的 Pareto 最优点。

5.4 容易低估的工程风险

第一，mixed-length batching 和 context parallelism 会带来负载不均。长上下文 batch 的吞吐、显存碎片、padding 浪费和通信模式都和短上下文不同，训练监控必须按长度段拆开，否则全局吞吐会掩盖局部不稳定。

第二，optimizer state 接续或重置都可能出问题。接续 optimizer state 更像原训练轨迹延长，但可能继承旧阶段动量；重置 optimizer state 更干净，但需要重新设计 warmup，否则容易出现 loss spike 或过慢收敛。两种方案都应先在 proxy scale 测。

第三，训练 attention kernel 和部署 attention kernel 不一致会制造假阳性。离线 eval 通过，不代表线上 128K/1M 服务可用；长上下文训练、推理外推、kv cache、chunked prefill、sparse attention 和 serving 框架必须联合验证。

6. 评估体系

6.0 从 benchmark list 到 eval registry

Mid-train 的评估系统不是榜单集合，而是一组带版本、污染状态、运行 harness、阈值和原始输出存档的 eval object；没有进入 registry 的评估结果，只能作为观察，不能作为 go/no-go 依据。

每个项目最多设置 3-5 个 primary 指标，另设若干 guardrail 和 diagnostic。Primary 太多会诱导 cherry-pick，diagnostic 太少会让团队不知道为什么涨跌。

6.1 Eval registry 的最小 schema

Eval DRI 应在 Gate 0 冻结 v0 owner 和 schema，并在进入 Gate 1 前冻结 v1 eval registry。最小字段如下：

Eval 版本变更规则要写死：改样本、改 prompt、改答案抽取器、改 metric、改 harness、改阈值，都必须生成新 eval_suite_version，旧结果不能横向混比。

私有 holdout 建议分三层：

• dev-private：调 pipeline、校准 harness，不进入最终 gate。
• sealed-private：阶段门使用，禁止针对它调数据 mix 或 prompt。
• final-blind：只在 Gate 5 或发布前使用，避免被反复优化成“另一套训练目标”。

6.2 Eval suite matrix

目标能力 eval 回答“能力是否真的变强”；base regression eval 回答“有没有伤到别的能力”；post-train readiness eval 回答“这个 base 变化是否能穿过 SFT/RL 仍然有价值”。

6.3 Base regression eval

Base regression 的重点不是证明模型更强，而是保护不可牺牲能力。它应覆盖：

• 通用知识：MMLU、MMLU-Pro、内部知识题。
• 推理：BBH、ARC、GPQA、逻辑题。
• 数学：GSM8K、MATH、AIME 风格内部题。
• 代码：HumanEval、MBPP、EvalPlus、repo-level completion、FIM、多文件定位。
• 多语：中文、英文和目标市场语言。
• 生成质量：长回答、摘要、解释、翻译、自然对话。

Base model 未必稳定遵循复杂格式，所以要区分“能力不足”和“格式不服从”。每个 base eval 应记录 minimal prompting、few-shot policy、答案抽取器版本和人工复核规则。SWE-bench、agent 任务、tool-use eval 混入了指令遵循、工具协议、环境稳定性和 scaffold 质量，更适合作为 readiness/diagnostic，而不是裸 base 主指标。

Base regression scorecard 至少报告：

• 不可牺牲能力最大回撤，而不只是平均分。
• 低分桶和长尾语言变化。
• 输出风格、拒答、冗长程度和幻觉样例。
• 固定人工审查样本篮子的结论。

6.4 Target capability eval

Target capability eval 要和 base regression 分开。它不只是问“公开榜有没有涨”，而是问“目标能力是否在真实任务和私有任务上变强”。

如果目标能力只在 public benchmark 上升，而 private holdout、失败样例簇和人工审查不支持，应先视为污染、格式适配或窄分布优化。

6.5 Long-context eval

长上下文评估要分三层：

• 机械检索：Needle-in-a-haystack、多 needle、不同位置和不同噪声密度。它只能作为 diagnostic，不应进入主 gate。
• 真实理解：长文档 QA、多章节摘要、多证据综合、冲突信息判断、长表格/日志分析。
• 任务完成：长代码库修改、多文件 bug 定位、法律/财报/论文综合分析、agent 轨迹复盘和下一步决策。

长上下文 eval registry 必须按轴展开：

长上下文的 hard gate 不应只看“最长长度能跑通”。更合理的门槛是：短上下文能力不明显退化，中长上下文真实任务有收益，推理系统在目标长度下成本和延迟可接受。

6.6 Post-train readiness eval

Post-train readiness 要用 paired protocol：

• pre-mid checkpoint 和 mid checkpoint 使用同一套 frozen post-train paired protocol。
• 固定数据顺序、seed、预算、checkpoint selection policy、reward/verifier、harness、decoding 和失败判定。
• 关键结论接近阈值时，跑多 seed 或重复 run，并报告方差或 bootstrapped CI。
• 不用“最佳 post-train checkpoint”做事后比较；要比较固定预算、固定选择规则下的结果，或报告训练曲线 AUC。

这里冻结的 SFT/RL recipe 是诊断仪器，用于比较 pre-mid 与 mid checkpoint，不代表最终生产 post-train 配方。若为追求更好结果而调整 recipe，应重新登记 experiment_id，原 mid-train 结论不得直接沿用。

四格判读：

6.7 Scorecard：如何读评估结果

每个候选 checkpoint 都应生成一页 scorecard。它是 Eval DRI 给 gate 的输入，不替代 4.6 的最终 go/no-go 决策。

如果某个指标收益异常高，而私有任务、人工审查和相邻 eval 不支持，应先假设污染、格式适配或过拟合，而不是先宣布能力突破。

Gate meeting 里先看一行红黄绿摘要，再看完整 scorecard：

7. 风险与事故处理 Runbook

第 7 章不是失败模式科普，而是训练中的事故处理 runbook：任何异常都必须能落到一个症状、一个实验 ID、一个受影响 checkpoint、一组证据路径和一个继续/回滚/kill 决策。

7.0 如何使用本章

正常监控、eval registry 和 gate 机制分别放在第 4-6 章；本章只处理异常。触发异常后，值班 DRI 先冻结现场，再做 30 分钟首轮诊断，最后给出临时决策。没有完成归因前，不要在同一个 run 里改数据、改学习率、改 eval harness 或改 post-train recipe。

事故出现后先做三步，不要先改配置：

事故先按六类登记：

硬规则：任何能力结论或训练效果结论必须先完成四层隔离：system replay、data manifest diff、eval harness diff、model checkpoint diff；若某一层与事故无关，应标记为 N/A 并写明理由。证据不齐时，只能登记为未归因事故，不能写入能力结论。

7.1 事故分级：观察、警报、阻断

处理原则：

7.2 训练中事故 triage 表

7.3 数据事故 runbook

数据事故的第一原则是隔离版本，不是现场修补。任何过滤器、生成器、去重、采样权重、tokenizer 或 packing 变化，都必须产生新的 data_version 和 manifest hash。

如果污染、license 或隐私边界无法解释清楚，应直接 kill 该数据版本。对 mid-train 来说，“可能污染但分数好”不是可接受状态。

7.4 训练事故 runbook

训练事故优先保护可恢复性。发现 numerical 或 resume 类问题后，不要先调学习率碰运气；先确认 checkpoint、optimizer、RNG、data cursor 和代码版本是否能 replay。

训练继续的最低条件是：数值稳定、系统 replay 成功、数据 manifest 未漂移、eval harness 未漂移。缺任一项，只能 retry 或 rollback，不能 promote。

7.5 评估事故 runbook

评估事故最常见的错误，是把工具变化当成能力变化。只要 prompt、wrapper、judge、答案抽取器、decoding、样本集或 metric 任一项变化，旧分数和新分数都不能直接横比。

只有当“旧 harness 下新 checkpoint 变好”和“新 harness 下旧 checkpoint 没有同等变好”同时成立，才可以把收益初步归因给模型。若 private holdout 被反复查看或调参，应降级为 dev-private，并重新建立 sealed-private 或 final-blind。

7.6 Post-train 接力事故

Mid-train 的收益如果在 post-train 后消失，先不要简单判定 mid-train 无效。需要同时排查四件事：

如果 post-train 接力连续两轮在 paired protocol 下失败，且 base 端收益只存在于 public benchmark 或单个 seed，应 kill 该 mid-train 方向；如果 base 端收益稳定但被 SFT/RL 覆盖，则把结论写成“post-train handoff 未打通”，不要写成“mid-train 无收益”。为排查覆盖问题而调整 SFT/RL 数据、reward、verifier、预算或 seed 时，旧 paired protocol 的结论不能继续作为 mid-train 收益证据，只能作为诊断线索。

7.7 事故复盘模板

每个警报或阻断级事故都要有一条复盘记录。复盘不是追责文档，而是让下一次训练能少踩同一个坑。

incident_id:
experiment_id:
incident_type: numerical | data | eval | infra | capability | post-train handoff
severity: observation | alert | blocker
first_detected_at:
affected_checkpoint:
symptom:
root_cause: confirmed | suspected | unresolved
changed_variables:
rollback_point:
evidence_paths:
four_layer_isolation:
  system_replay:
  data_manifest_diff:
  eval_harness_diff:
  model_checkpoint_diff:
decision: kill | retry | rollback | extend | promote | unresolved
prevention_rule:
owner:
reviewed_by:

如果 root_cause 仍是 unresolved，事故可以关闭训练动作，但不能关闭认知结论：文档中只能写“未归因事故，已隔离”，不能写“模型能力退化”或“某数据桶有效”。

8. 给新团队的 90 天路线图

这张路线图是参考节奏，不是日历承诺。进入下一阶段应由 Gate 0-5 决定，而不是由第几天决定。

8.0 Gate dashboard：每一阶段只回答一个决策问题

90 天路线图的用途不是排期，而是把项目从“想训练”推进到“证据足够再训练”。每个 gate 只回答一个问题：

只要某个 gate 的证据不完整，就不要用“再训一点看看”绕过去。Mid-train 的项目成本高，真正的节奏控制来自 gate，而不是日历。

每个 gate 的 dashboard 记录还必须包含 status、owner、evidence_path、version_hash、stale_after 和 next_action。没有证据路径的绿色状态，应视为黄色。

第 0-14 天：定义目标和评估

对应 Gate 0，主责为 Model Lead、Eval DRI 和 Post-train DRI；本阶段的决策会议只回答一个问题：这个目标是否真的需要 mid-train。

交付物：

• Mid-train charter：目标能力、不可牺牲能力、目标 checkpoint、预算。
• Eval matrix：base eval、能力 eval、长上下文 eval、post-train readiness。
• 数据桶设计文档。
• 风险清单和 go/no-go gate。
• Frozen post-train recipe：SFT/RL 数据版本、训练预算、seed、harness、评估集和失败判定。

Go/no-go：

• 如果 eval registry、私有 holdout 和 post-train 接力 recipe 没有冻结，不进入训练。
• 如果私有 holdout 创建时间晚于训练数据混合，或允许针对私有 holdout 调参，不进入训练。

第 15-35 天：数据和小模型 ablation

对应 Gate 1-2，主责为 Data DRI 和 Eval DRI；所有实验必须登记到 4.6 的实验台账。

交付物：

• 例如 1B/3B/7B proxy model 上的数据 mix 实验；具体 scale 由团队现有模型谱系和预算决定。
• 学习率和 token budget sweep。
• 合成数据正确性和多样性报告。
• 每个数据桶的 loss 和能力关联分析。
• Data manifest/hash、near-duplicate 检测报告、污染检查报告、人工抽检样本。

Go/no-go：

• 至少一个 mix 在目标能力上提升，且通用能力回撤可接受。
• 合成数据没有明显污染和风格坍缩。
• Proxy 成功只说明坏方向被排除，不能证明 target scale 一定成立；进入主模型短程前，至少需要两个 scale 方向一致，或 target model 短程 run 验证关键信号。

第 36-60 天：主模型短程 mid-train

对应 Gate 3，主责为 Training Infra DRI、Eval DRI 和 Model Lead；本阶段必须先定义 kill switch，再启动训练。

交付物：

• 主模型短程训练，例如 10B-100B token 级窗口；具体 token budget 由 Gate 2 证据和训练成本决定。
• 每日 checkpoint eval。
• 能力/遗忘 Pareto 曲线。
• 候选 checkpoint 选择。
• 训练 runbook、checkpoint lineage、resume 记录、训练代码 commit、事故记录。

Go/no-go：

• 目标能力提升不是单一 benchmark 驱动。
• 通用能力下降低于事先定义阈值。
• 生成样例没有明显风格漂移。
• 出现 NaN、不可恢复 loss spike、梯度异常、吞吐异常、某数据桶 loss 反常、checkpoint resume 不连续，或长上下文训练伤害短任务时，触发停止或回滚。

第 61-75 天：post-train 接力验证

对应 Gate 4，主责为 Post-train DRI 和 Eval DRI；如果 post-train recipe 在本阶段改变，mid-train 结论应视为无效或重新标记实验 ID。

交付物：

• 固定 SFT recipe 对比。
• 如适用，固定 RL/RLVR recipe 对比。
• post-train 后真实任务评估。
• reward hacking / safety / style 回归报告。
• Post-train readiness report：recipe 版本、seed、预算、harness、失败判定和收益保留比例。

Go/no-go：

• Mid-trained checkpoint 在 post-train 后仍保留收益。
• 对齐难度没有显著增加。

第 76-90 天：放大或收缩决策

对应 Gate 5，主责为 Decision owner、Model Lead 和 Release owner；本阶段不是自动放大，而是决定继续、收缩、重做数据或停止。

交付物：

• 放大候选 recipe 或下一阶段收缩重做 recipe。
• 是否进入 100B-1T+ token 训练的决策。
• 数据和评估自动化改进清单。
• 长上下文或第二能力目标的下一阶段计划。
• Model registry：checkpoint lineage、data manifest、eval raw outputs、训练日志、权限、保留周期和可回滚 checkpoint。

Go/no-go：

• 如果收益主要来自污染、窄评估或 post-train 偶然性，不放大。
• 如果收益稳定、可解释、可在 post-train 后保留，进入主训练。

9. 可执行 checklist

9.0 最小交付包与交付物索引

如果团队不想一开始就维护完整文档体系，至少要有下面 8 个交付物。缺任意一个，mid-train 结论都很难复盘。

Checklist 的作用是验收这些交付物，不是制造流程负担。对新团队来说，先把最小交付包跑通，比追求完美平台更重要。

每个 checklist 项都不应只打勾，还要绑定最小审计字段：

owner:
evidence_path:
version_hash:
stale_after:
gate_role: primary | guardrail | diagnostic
status: green | yellow | red

如果一项检查没有 evidence_path 或 version_hash，它最多只能算 yellow，不能作为 gate 通过证据。

9.1 数据 checklist

• [ ] 每个数据版本都有 data manifest/hash，记录 source snapshot、processing commit、tokenizer、dedup、contamination、sampling weight、shuffle seed。
• [ ] 每个数据源有 license / 合规记录。
• [ ] 每个数据桶有质量打分和人工样例审查。
• [ ] 每个数据桶绑定 linked_eval_id，未绑定 eval 的桶不提高采样权重。
• [ ] benchmark contamination 检查完成。
• [ ] 训练集、验证集、私有 holdout 分离。
• [ ] 合成数据记录 teacher/version、prompt、采样参数、verifier、过滤规则、拒样比例、模板重复率、人工错误率。
• [ ] 合成数据有正确性过滤、多样性、模板化和 style entropy 检查。
• [ ] 长上下文数据包含真实长任务，不只是拼接文本。
• [ ] 通用数据保留比例有 ablation 支持。

9.2 训练 checklist

• [ ] Base checkpoint eval 完成。
• [ ] Tokenizer / special tokens 冻结或变更有充分理由。
• [ ] Optimizer state 接续策略明确。
• [ ] LR schedule、warmup、peak/min LR、decay shape、gradient clipping、precision 记录清楚。
• [ ] global batch、microbatch、packing/masking、data order、shuffle seed 记录清楚。
• [ ] checkpoint selection policy 在训练前冻结。
• [ ] 每个阶段有 checkpoint 保存策略。
• [ ] 分桶 validation loss 可观测。
• [ ] MoE/attention/long-context 系统指标可观测。
• [ ] 训练可 resume，checkpoint 可复现。

9.3 评估 checklist

• [ ] Eval registry 已冻结，包含 eval_id、eval_family、data_hash、harness_commit、prompt_or_wrapper_version、metric、decision_role、threshold_or_guardrail、raw_output_path。
• [ ] Base eval、能力 eval、长上下文 eval 分开。
• [ ] 每个 eval 标明 primary、guardrail 或 diagnostic，primary 指标不超过 3-5 个。
• [ ] 指标包含真实任务和人工审查。
• [ ] 不只看平均分，也看能力回撤。
• [ ] 每个候选 checkpoint 生成 scorecard，包含目标能力 delta、最大回撤、污染状态、失败样例和建议动作。
• [ ] 每个候选 checkpoint 做同一套 eval。
• [ ] 私有 holdout 分为 dev-private、sealed-private、final-blind，创建时间早于训练数据 mix 冻结，且不得针对 sealed/final 调参。
• [ ] 长上下文 eval 覆盖长度、位置、信息密度、任务类型和部署一致性。
• [ ] Post-train 接力 recipe 固定，并记录数据顺序、seed、harness、预算、checkpoint selection policy 和失败判定。
• [ ] Post-train 后收益可复现。

9.4 组织 checklist

• [ ] 数据团队、训练团队、Post-train DRI 共用同一张实验台账。
• [ ] 每次实验记录数据 mix、LR、token budget、context length、eval 版本。
• [ ] Research、Data、Training、Eval、Post-train、Release owner 均已明确。
• [ ] Model Lead、Data DRI、Training Infra DRI、Eval DRI、Post-train DRI、Safety/Compliance DRI、Product/Domain DRI、Decision owner 均已明确。
• [ ] Mid-train charter、data manifest/hash、eval registry、runbook、checkpoint ledger、post-train readiness report、go/no-go memo 均有 owner。
• [ ] 项目开始前冻结“不可牺牲能力”和各阶段回滚条件。
• [ ] 每个 gate 的阈值、阻断条件和签字人已在实验前写入 gate memo。
• [ ] 任何中途改 mix、改过滤器、改 eval 版本的行为都会新建 experiment_id。
• [ ] 训练中有停止条件。
• [ ] 放大训练前必须过 go/no-go gate。
• [ ] 发布前保留 pre-mid、mid、post 三类 checkpoint 的完整报告和 model registry。

10. 对有 post-train 经验的基模团队的特别提醒

第一，不要用 SFT 的心智做 mid-train。Mid-train 数据可以包含 QA、CoT、代码任务，但其目标不是让模型学会产品回答格式，而是改变能力分布。

第二，不要让 RL 背所有锅。如果 base model 没有足够的数学、代码、长上下文和自我纠错 substrate，RL 很可能只学到表面搜索或冗长推理。

第三，不要只追榜。Mid-train 的真实收益要在私有任务、真实产品任务和 post-train 接力中同时成立。

第四，不要一开始就追 1M context。对多数团队，先把 32K/128K 做到可靠，比展示极长 context 更实际。

第五，不要忽视数据工程。Mid-train 项目中，训练代码常常不是瓶颈，数据 lineage、污染控制、分桶 eval 和实验纪律才是。

11. 第一轮搜索空间：示例搜索网格，不可直接作为默认 mix

这一章是工作样例，不是配方。它的用途是帮助第一次做 mid-train 的团队把数据、训练、评估和 post-train 接力串成一个最小证据链。

如果团队已有一个可用 base model 和稳定 post-train pipeline，建议第一轮不要做大而全，先做一个“能力型 mid-train + post-train 接力”的最小闭环。以下比例不是推荐 recipe，而是用于启动 ablation 的搜索空间；不同模型规模、预训练历史、目标语言和产品任务会显著改变最优 mix，主训练前必须通过 proxy scale 和短程主模型验证。

这里的“最小闭环”不是最小训练配方，而是用尽可能小的实验代价验证数据、训练、评估和 post-train 接力是否能形成可解释结论。下列比例和 token 区间只用于设计 ablation 变量，不得作为默认 mix、默认 LR 或默认预算。

只有在 base checkpoint、目标能力、不可牺牲能力、eval registry、data manifest 和 post-train paired protocol 已冻结后，下面的区间才可作为 ablation 变量；否则不应进入训练配置。

目标：

• 提高数学、代码、STEM 和复杂 QA。
• 不显著伤害通用、多语、事实和自然生成。
• 验证 SFT/RL 后是否仍有收益。

数据 mix 搜索空间（bucket sensitivity sweep 轴）：

• 高质量通用文本：用低/中/高几个点测试保真底线，例如 30/50/70%，不是固定占比建议。
• 代码与 FIM：用低/中/高几个点测试代码能力和普通生成漂移，例如 10/20/30%。
• 数学/STEM：用低/中/高几个点测试推理注入收益、饱和点和通用回撤。
• 合成教材/可验证推理：用上限 sweep 测试 verifier 质量、模板化和 teacher 错误放大。
• QA/CoT/短答任务形态：用单独开关或低比例混入测试格式漂移，避免把 post-train 行为格式提前固化。

这些 bucket 轴只用于第一轮单变量或少变量搜索，不是要同时满足的归一化比例表。实际 mix 必须通过小模型和短程主模型实验决定。

这个起点不是 OLMo 2、Qwen3、Llama 3 或 Phi-4 的复刻配方，也不是从公开报告反推出的最优比例。它只是一组便于新团队暴露数据冲突、遗忘风险和合成数据边界的搜索网格。

主训练前必须有 mix sensitivity curve，而不是只选择一个看起来最好的点。至少回答：

• 通用数据比例下降时，哪些不可牺牲能力最先回撤？
• 数学/STEM 或代码比例提高时，收益是否线性、饱和还是反转？
• Synthetic ratio 增加时，私有任务、风格审查和模板重复率是否同步恶化？
• 同一 mix 在不同 seed 或相邻 checkpoint 上方向是否一致？
• 目标能力收益是否足以补偿通用回撤和训练成本？

第一轮不要只跑一个 mix。更好的做法是保留一个 control mix，再围绕单一变量做小矩阵：

每个变体只能改 1-2 个主变量。边训边改 mix、过滤器、LR 或 eval 版本，会让实验无法解释。

通过 Gate 2 后的主模型短程验证起点：

• 低学习率继续训练。
• 先用原 context length 或小幅扩展。
• 10B-50B tokens 级短程主模型验证上限示例；实际预算必须由 proxy 结果、target model 短程信号、遗忘阈值和成本共同决定。
• 每 10%-20% token 保存 checkpoint 并 eval。

评估起点：

• Base eval：MMLU/MMLU-Pro、BBH、GPQA、GSM8K/MATH、HumanEval/MBPP、多语集。
• 私有 eval：内部数学、代码、复杂 QA、真实用户任务。
• Post-train readiness：固定 SFT recipe，对比 pre-mid 和 mid checkpoint。

如果这轮闭环没有稳定收益，不要急着扩大 token budget。先回到数据和学习率。

12. 资料地图

本章不是文献综述的尾注，而是读者复核本文结论的路线图。建议团队把资料分成三类读：先读一手报告确认事实边界，再读综述建立 taxonomy，最后读受控实验形成内部 ablation 假设。

12.1 一手技术报告：事实底座

12.2 综述和受控实证研究：假设来源

12.3 Claim / source matrix

12.4 推荐阅读顺序

1. 先读 OLMo 2：理解 mid-training 作为独立阶段时，文档、数据、checkpoint 和 post-training 如何分层。
2. 再读 Qwen3：理解“通用 -> 能力增强 -> 长上下文”的阶段设计，同时注意原报告用的是 pre-training stages。
3. 再读 DeepSeek-V3 和 Qwen2.5-1M：理解长上下文扩展不能脱离架构、推理外推和 serving 系统。
4. 再读 Phi-4：理解合成数据的价值与边界，尤其不要把 synthetic-heavy strategy 简化成单一 reasoning mid-train。
5. 再读 Llama 3：理解 continued pre-training、long-context pre-training 和 annealing 的保守路线。
6. 最后读 survey、PRISM 和 pre/mid/RL 论文：把机制假设转成团队自己的 ablation，而不是把论文结论直接写进训练决策。

13. Go/no-go memo 最小模板

具体启动动作见 0.2，交付物索引见 9.0。正文最后只保留一个决策模板：每一次 go/no-go 都必须能追到证据路径、版本和 owner。

decision_id:
gate:
status: green | yellow | red
decision: go | no-go | retry | rollback | kill
target_capability:
non_regression_guardrails:
evidence_paths:
version_hash:
stale_after:
data_manifest_hash:
eval_registry_version:
post_train_protocol_version:
checkpoint_or_run_id:
known_risks:
owner:
signoff:
reviewed_by:
next_action:

一个成熟的 mid-train 项目不是“训练跑起来”才开始，而是在第一个 checkpoint 产生前就已经能回答：目标是什么、不能牺牲什么、证据在哪里、谁来判定继续或停止。

附录 A：审稿意见吸收记录

技术专家挑刺后，作者已做以下修订：

• 在摘要和术语边界中加入限定：OLMo 2 是狭义 mid-training 样本，Qwen3、DeepSeek-V3、Llama 3、Qwen2.5-1M 等仅在工程意义上归为 mid-train-like。
• 修正 Qwen2.5-1M：区分 long-context pre-training、post-training 和 inference/deployment；明确 1M 支持主要来自 DCA/YaRN 等外推和推理系统，不把稀疏注意力写成普通 mid-train 数据配方。
• 修正 Phi-4：改为 synthetic-heavy training strategy 案例，不再写成干净的 reasoning mid-train 配方。
• 降低 reasoning/RL 表述强度：改成强工程假设，并强调 edge-of-competence、reward 设计和探索预算。
• 将数据比例和 token budget 从“推荐配方”改为“第一轮搜索空间”。
• 调整 SWE-bench 定位：更适合 fixed harness、轻量 instruction wrapping 或 post-train readiness。

编辑挑刺后，作者已做以下修订：

• 在摘要后新增读者决策树，让团队先判断自己该做 capability mid-train、context extension、domain adaptation 还是 reasoning substrate。
• 把“近两年共识”改成“公开证据强弱分层”，区分技术报告、综述/受控实验和访谈/博客。
• 增加第一轮 ablation 设计表，把文章从综述推进到可执行项目计划。
• 补充有 post-train 经验的基模团队的 10 条差异认知。
• 将资料地图拆成一手技术报告、综述和受控实证研究。

第一次定时优化中，作者吸收技术评审和编辑评审后做了以下修订：

• 新增“第 0.2 节：第一天怎么启动”，把启动动作压缩成 DRI、charter、eval registry、post-train recipe、实验台账和 gate memo。
• 将第 4.6 节改成“组织运行机制：角色、台账和质量门”，补充 DRI 表、实验台账 schema、Gate 0-5 质量门和会议节奏。
• 将 90 天路线图改为阶段门驱动，强调日历只是参考，进入下一阶段由数据就绪度、训练稳定性、eval 稳定性和 post-train 接力验证决定。
• 补充 proxy ablation 的边界：proxy 只能排除坏方向，不能证明 target scale 一定成立。
• 升级组织 checklist，加入 gate memo、签字人、experiment_id 变更规则和 model registry。

第二次定时优化中，作者吸收技术评审和编辑评审后做了以下修订：

• 将第 6 章从 benchmark 清单改成 Eval Registry 使用说明，强调没有进入 registry 的结果不能作为 go/no-go 依据。
• 新增 eval registry schema，覆盖 eval_id、data_hash、harness_commit、prompt/wrapper、decoding、metric、threshold、raw output 等字段。
• 将私有 holdout 拆成 dev-private、sealed-private、final-blind，避免团队在“私有集”上反复调参。
• 拆分 base regression、target capability、long-context、post-train readiness 和 safety/style eval，明确各自用途和失败信号。
• 补充 paired post-train readiness protocol，要求冻结 seed、预算、checkpoint selection policy、reward/verifier、harness、decoding 和失败判定。
• 新增 checkpoint scorecard 模板，要求同时报告目标能力 delta、最大回撤、污染状态、失败样例和建议动作。

第三次定时优化中，作者吸收技术评审和编辑评审后做了以下修订：

• 在第 4.2 节补充数据桶准入卡，要求每个数据版本有 data manifest/hash、tokenizer、sampling weight、shuffle seed、linked_eval_id 等字段。
• 在第 4.2.2 节补充合成数据使用边界，要求记录 teacher/version、prompt、采样参数、verifier、过滤规则、模板重复率、人工错误率和是否读过 eval。
• 在第 4.3.1 节补充训练旋钮冻结项，包括 peak/min LR、decay shape、gradient clipping、precision、global batch、microbatch、data order 和 checkpoint selection policy。
• 在第 4.5 节补充长上下文 curriculum 的长度分布记录，避免只记录最大 context length。
• 将第 4.4 ablation 表降温为“搜索变量示例”，并在第 11 章加入 mix sensitivity curve 要求。
• 同步升级数据和训练 checklist，强调数据、过滤器、生成器、训练配方和 checkpoint 选择都必须可复现。

第四次定时优化中，作者吸收技术评审和编辑评审后做了以下修订：

• 将第 7 章改为“风险与事故处理 Runbook”，明确本章只处理训练异常，不重复正常 gate、监控和 eval registry。
• 新增事故类型和事故分级，覆盖 numerical、data、eval、infra、capability、post-train handoff 六类事故，以及观察、警报、阻断三级处理。
• 补充“四层隔离”硬规则：system replay、data manifest diff、eval harness diff、model checkpoint diff 证据不齐时，不能写入能力结论。
• 将训练事故 triage 表升级为现场症状、30 分钟首查、分层归因、立即决策和必须留档的 runbook。
• 新增数据事故、训练事故、评估事故和 post-train 接力事故的专项处理流程。
• 新增事故复盘模板，要求记录 incident_id、experiment_id、affected_checkpoint、changed_variables、evidence_paths、decision 和 prevention_rule。

第五次定时优化中，作者吸收技术评审和编辑评审后做了以下修订：

• 在第 2 章新增证据标签，区分报告事实、论文归纳、工程归纳和待验证假设。
• 将第 2.1 节表格从“可借鉴点”改为“公开报告直接支持”和“本文工程类比”，避免把原报告术语和作者归纳混在一起。
• 收窄“公开案例普遍提高高质量数据占比”的说法，明确 DeepSeek-V3 主要支持阶段化 context extension，不直接支持数据配比结论。
• 对 OLMo 2、Qwen3、DeepSeek-V3、Phi-4、Qwen2.5-1M、Llama 3 案例做一手事实校准，并补充原文术语、token/context/stage 限定和不可外推边界。
• 将第 12 章从参考书单升级为资料地图，新增一手报告用途表、综述/受控实验边界表和 claim / source matrix。
• 在摘要和第 11 章补充护栏，明确数据比例、token budget、90 天路线图和质量门是工程起步建议，不是公开论文直接给出的通用结论。

第六次定时优化中，作者吸收技术评审和编辑评审后做了以下修订：

• 在正文开头新增“使用导航”，把启动会、数据实验、训练事故和资料核查的阅读路径前置。
• 修正第 0.2 节的 Day-1 口径：第一天冻结 owner/schema，训练前冻结 v1 eval registry 和 post-train paired protocol。
• 调整 mid-train / post-train 分工表述，强调 reasoning、tool use、agent 和长上下文任务上两者会交叠，需要 paired protocol 判断收益来源。
• 在第 4.5 节新增 curriculum 分支表，按产品主目标区分先能力、先长度或并行验证，避免把“先能力后长度”写成硬规则。
• 将第 6.7 节补成 gate meeting 可用的红黄绿 scorecard 摘要。
• 在第 7.0 节补充事故处理三步：冻结现场、判定级别、分层隔离。
• 将第 8.0 节改为可执行 Gate dashboard，加入 owner、next action 和 evidence_path/version_hash/status 等审计字段。
• 将第 9.0 节升级为最小交付包与交付物索引，明确模板位置、冻结 Gate 和使用会议。
• 将第 11 章标题改为“示例搜索网格，不可直接作为默认 mix”，并把进入比例表前的硬条件写在同一屏。
• 新增正文收束入口，后续压缩为第 13 章 go/no-go memo 最小模板，减少与 0.2 和 9.0 的重复。

第七次定时优化中，作者吸收技术评审和编辑评审后做了以下修订：

• 将“使用导航”升级为“使用导航 / 主线地图”，收紧第一轮验证对应章节到 4.0、4.4 和 11。
• 在第 3 章新增案例证据总表，并按原报告术语、报告事实、证据标签、可安全归纳、不得推出和内部验证动作拆分。
• 将第 3 章各案例的“工程启发 / 可复用点”统一降级为“可转化为内部假设/检查项”，避免读者拼成公开团队共同 recipe。
• 将第 4 章开头改为第一轮最小闭环导读，并明确“最小闭环”是最小证据链，不是最小训练配方。
• 修正第 4.3.1 节两个细节：scale-up 条件从“三个”改为“四个”，并将长度变量从 global_batch / sequence_length_distribution 改为 sequence_length_distribution / length_bucket_ratio。
• 在第 6.6 节补充说明：冻结的 SFT/RL recipe 是诊断仪器，不代表生产 post-train 配方。
• 将第 11 章进一步降级为最小证据链样例，明确比例和 token 区间不得作为默认 mix、默认 LR 或默认预算。
• 将第 13 章压缩为 go/no-go memo 最小模板，减少与 0.2 和 9.0 的重复。

第八次定时优化中，作者吸收技术评审和编辑评审后做了以下修订：

• 统一标题、目标读者、第 1.4 节和第 10 章称谓为“有 post-train 经验、准备承担 mid-train 的基模团队”。
• 收窄 long-context extension 表述：32K/128K/256K 可作为训练长度扩展示例，1M 级上下文必须单独说明训练长度、位置/attention 外推、serving 和成本验证。
• 将第 8.0 节明确为唯一 Gate dashboard，第 4.6 节只保留角色、台账和签字责任，避免两套 gate 口径并存。
• 将第 11 章数据 mix 百分比改成 bucket sensitivity sweep 轴，明确它们不是要同时满足的归一化比例表。
• 调整事故硬规则：能力结论和训练效果结论必须做四层隔离；无关层可以写 N/A 和理由，避免机械套表。
• 明确 final-blind 在 Gate 5 或发布前应保持 unused/reserved，防止被阶段性调参消耗。
• 在 post-train handoff 处补充：一旦调整 SFT/RL 数据、reward、verifier、预算或 seed，必须新建 experiment_id 或 paired_protocol_version，旧 paired 结论不能作为 mid-train 收益证据。
• 补齐第 13 章 go/no-go memo 的 status、version_hash、stale_after、signoff、reviewed_by 等审计字段。

附录 B：最终质量说明

本文当前可作为基模团队启动 mid-train 项目的内部手册使用，但仍不是训练配方，也不是对公开模型的复刻说明。