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

资料范围：近两年公开资料；同一模型家族优先最新一版，最多看上一版，更老版本只在有不可替代证据时保留 目标读者：有 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、Qwen2.5-1M 等报告并不总使用这个词，而是称为 pre-training、continued pre-training、context extension 或 long-context pre-training。本文只在工程意义上把这些阶段归入 mid-train-like 范畴，不能等同于原报告术语。

资料选择上，本文不做模型历史复盘。每个模型家族优先读最新一版公开技术报告；只有当上一版披露了当前版本没有替代的信息，例如 1M context、显式 mid-training 命名、annealing 或 synthetic data 细节时，才保留上一版或必要例外。执行项目时，应先用目标模型家族的最新报告替换本文中的历史样本。

实践上，新团队不应先追大规模训练，而应先做小模型 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 之前。Qwen3、DeepSeek-V3、GLM-4.5 是主读样本；Qwen2.5-1M、OLMo 2、Phi-4、Llama 3 分别作为上一版专项、必要例外或降级参考。其中 GLM-4.5 和 OLMo 2 显式使用 mid-training 术语，GLM-4.5 进一步把 mid-training 拆成 code / reasoning / long-context 三个子阶段，是目前公开报告中子阶段拆分最细的样本。

第二，在 Qwen3、OLMo 2、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 来源。案例只用于回答“哪些公开事实能转成内部检查项”，并遵循版本筛选规则：同一模型家族优先最新一版，最多上一版；更早样本必须写明保留理由。

这张表的使用方式很简单：先读主读样本；只有当前模型报告没有覆盖某个关键问题，才读上一版或必要例外。若目标团队做的是某个特定模型家族，例如 Qwen、DeepSeek、Llama 或自研模型，内部资料包应优先替换成该家族最新报告，再保留最多一份上一版作为对照。

旧版本案例只保留三种情况：第一，它提供当前版本没有的术语或治理结构，例如 OLMo 2 的 mid-training 分层；第二，它提供专项能力的关键工程拆解，例如 Qwen2.5-1M 对 1M context 的训练/外推/部署拆分；第三，它提供一个仍未被新报告替代的受控变量，例如 Llama 3 的 annealing 或 Phi-4 的 synthetic data 边界。除此之外，旧模型不要进入主读清单。

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。最小字段如下：

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

[!CAUTION] - 没有 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。

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

事故先按六类登记：

[!CAUTION] 硬规则：任何能力结论或训练效果结论必须先完成四层隔离：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 只回答一个问题：

[!CAUTION] 只要某个 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（详见 1.2、1.4）。Mid-train 数据可以包含 QA、CoT、代码任务，但其目标不是让模型学会产品回答格式，而是改变能力分布。自检：如果数据 mix 大部分是指令-回答对，大概率在做提前的 SFT，而不是能力塑形。

第二，不要让 RL 背所有锅（详见 2.4 第四点、6.6）。如果 base model 没有足够的数学、代码、长上下文和自我纠错 substrate，RL 很可能只学到表面搜索或冗长推理。自检：如果目标任务的 zero-shot pass@100 为零，说明能力不在 base 的可达边界内，RL 大概率无法稳定探索到正确解。

第三，不要只追榜（详见 6.4、7.2 eval 事故、8.0）。Mid-train 的真实收益要在私有任务、真实产品任务和 post-train 接力中同时成立。自检：如果某个 eval 收益超过 5 个百分点但私有 holdout 不动，先假设是污染或格式适配。

第四，不要一开始就追 1M context（详见 4.5）。对多数团队，先把 32K/128K 做到可靠，比展示极长 context 更实际。自检：如果短任务（<4K）性能在拉长后明显下降，说明 context extension 的成本还没控制住。

第五，不要忽视数据工程（详见 4.2、4.2.1、9.1）。Mid-train 项目中，训练代码常常不是瓶颈，数据 lineage、污染控制、分桶 eval 和实验纪律才是。自检：如果团队无法在 30 秒内说出当前训练使用的 data manifest hash 和污染检查版本，数据治理还没到位。

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

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

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

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

主训练前必须有 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. 资料地图

本章不是文献综述的尾注，而是读者复核本文结论的路线图。使用原则是：同一模型家族先读最新一版公开技术报告；最多补读上一版；更早材料只在提供不可替代证据时保留，并在内部资料包中标为“必要例外”。

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

不要把这张表理解成“必读清单”。如果团队已经有目标模型家族的最新报告，应先替换主读样本；若新报告没有披露 mid-train 相关细节，再保留上一版或必要例外作为工程类比。

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

12.3 Claim / source matrix

12.4 推荐阅读顺序

1. 先读目标模型家族最新报告；没有目标家族时，先读 Qwen3 和 DeepSeek-V3。
2. 只在做 1M/超长上下文时补读 Qwen2.5-1M。
3. 只在需要明确 mid-training 治理范式时补读 OLMo 2。
4. 只在合成数据是主变量时补读 Phi-4。
5. 只在需要 late-stage/annealing 公开细节时补读 Llama 3。
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 产生前就已经能回答：目标是什么、不能牺牲什么、证据在哪里、谁来判定继续或停止。

附录：使用边界与更新原则

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