论文 DeepSeek-Coder-V2: Breaking the Barrier of Closed-Source Models in Code Intelligence 于 2024 年 6 月公开, 模型与使用说明见 deepseek-ai/DeepSeek-Coder-V2. V2 不再从零训练一组 Dense 代码模型, 而是从已经训练 4.2T token 的 DeepSeek-V2 中间 checkpoint 继续训练 6T token. Lite 版本有 16B 总参数, 每个 token 激活 2.4B; 大版本有 236B 总参数, 激活 21B. 编程语言由上一代约 87 种扩展到 338 种, 上下文扩到 128K.
1. 续训路线把代码能力接到通用 MoE 基座上
Coder-V2 把代码续训接到了通用 MoE 基座上, 模型路线也由专用稠密模型转向通用稀疏模型.
1.1. 60/10/30 配比同时保留三类能力
新增训练数据按 60% 代码, 10% 数学, 30% 自然语言混合. 自然语言从 DeepSeek-V2 语料中采样, 代码和数学数据重新构建. GitHub 数据截止到 2023 年 11 月以前, 使用与 DeepSeek-Coder 相近的行长, 字母比例和文件类型过滤, 再做近重复去重. 最终从 GitHub 获得 821B 源码 token 与 185B 代码相关文本 token.
Common Crawl 侧沿用 DeepSeekMath 的迭代召回. StackOverflow, PyTorch 文档, Math StackExchange 等高相关页面先作为种子训练 fastText 分类器, 分类器再从网页中发现新页面. 中文文本改用 DeepSeek-V2 的 BPE token 作为分类输入, 避免依赖空格分词. 首轮中代码或数学页面占比超过 10% 的域名会被标记, 后续再沿 URL 补充同域未收录页面. 三轮网页召回得到 70B 代码相关 token 和 221B 数学 token; GitHub 上再运行两轮分类流程, 补充 94B 高质量源码. 新代码语料合计约 1.17T token.
数学语料 221B token, 大约是 DeepSeekMath 所用 120B 的两倍. 代码与数学共同增加, 与后续 Table 3 和 Table 9 的生成结果相符. 30% 自然语言维持通用交互, 但 Table 10 显示知识问答会相对 DeepSeek-V2 Chat 回落. 配比因此体现明确取舍: 更多容量被分配给代码结构, 数学步骤与任务指令, 百科知识的保持并非无损.
1.2. 1B 消融把语料质量与模型规模分开
报告使用同一 1B 模型架构比较旧 DeepSeek-Coder 语料与新语料. 训练 1T token 后, HumanEval 从 30.5% 升到 36.0%, MBPP 从 44.6% 升到 49.0%. 新语料继续训练到 2T token 后, 两项分别达到 37.2% 与 54.0%. 因为模型规模保持不变, 这组消融比大模型横向排名更直接地支持新语料管线有效.
1T 与 2T 的比较同时混入训练 token 数量变化. 其中旧语料 1T 对新语料 1T 可以支持质量差异; 新语料 1T 对 2T 只能说明继续训练有收益. 引言概括的 HumanEval 增加 6.7 个百分点, MBPP 增加 9.4 个百分点, 对应旧语料 1T 与新语料 2T 的总差, 不能全部算作清洗算法贡献.
1.3. MoE 的总参数和激活参数承担不同含义
V2 直接沿用 DeepSeek-V2-Lite 与 DeepSeek-V2 的 MoE 架构超参数. Lite 为 16B 总参数, 激活 2.4B; 大版本为 236B 总参数, 激活 21B. 总参数描述专家容量, 激活参数更接近一次 token 前向计算实际经过的权重规模. 两个数字都不能单独等同于显存占用或吞吐, 因为专家权重仍需分布在设备上, 路由, 通信和 batch 形状也会影响成本.
代码语料并未改变 MoE 的基本路由结构. V2 的路线是利用通用基座已经形成的语言, 数学和世界知识, 再通过 6T 定向续训改变能力分布. 报告还记录训练中出现不稳定与梯度尖峰, 并将问题归因于 exponential normalization, 随后退回 conventional normalization. 文中没有给出尖峰频率和消融数值, 可以确定的是最终训练设置放弃了该归一化方案, 不能进一步量化它对最终成绩的影响.
2. 训练目标和长上下文按模型用途分流
2.1. Lite 保留 FIM, 大模型只做 next-token prediction
16B Lite 同时使用 next-token prediction 与 FIM, 236B 只使用 next-token prediction. Lite 的 FIM 采用 PSM, 把文档切为 , 与 后重排:
FIM 在文档级, packing 之前执行, 比例为 0.5. 生成中间片段时, 前缀与后缀都已经位于因果注意力的左侧. Lite 因而保留适合 IDE 的双侧补全能力. 大版本把训练容量集中在自然语言指令下的长代码生成, 数学和软件任务, 没有以 FIM 为目标训练. Table 6 主要报告 Lite-Base, 正好与两档模型的训练目标对应.
FIM 与 next-token prediction 共用模型参数, 但输入格式不同. 50% FIM 会减少自然顺序文档占比, 同时增加双侧条件样本. V2 沿用上一代经过消融选择的比例, 没有报告在新 MoE 架构上重新扫描不同 FIM 率. 因此 0.5 是继承并验证可用的配置, 不是 V2 报告重新证明的最优点.
2.2. 优化设置包含一次明确的稳定性回退
预训练使用 AdamW, , , weight decay 0.1. 学习率采用 cosine 调度, warm-up 2000 步, 末端降到初始学习率的 10%. Lite 与大版本分别继承 DeepSeek-V2-Lite 和 DeepSeek-V2 的主要超参数. 从中间 checkpoint 续训减少了重新获得通用能力的成本, 也意味着最终模型不能只按新增 6T token 理解; 总暴露量为 10.2T token.
归一化回退揭示了大规模续训的一项边界: 在小规模实验中有效的数值技巧, 放到长周期 MoE 训练可能放大梯度异常. 最终采用 conventional normalization 是训练稳定性选择. 报告没有公开回退前后的损失曲线和成本, 所以不能断言该变化提升了基准成绩, 只能确认它解决了团队观察到的不稳定与梯度尖峰.
2.3. YaRN 用两段训练把窗口推到 128K
长上下文扩展沿用 DeepSeek-V2 的 YaRN, scale 为 40, beta 参数为 1 与 32. 第一阶段把序列扩到 32K, batch size 1152, 训练 1000 步; 第二阶段扩到 128K, batch size 288, 再训练 1000 步. 序列变长时 batch 减小, 控制每步显存与 token 规模. 训练阶段还会上采样长上下文数据, 让扩展后的位置范围真正出现在样本中.
Figure 2 的 Needle In A Haystack(NIAH)测试显示模型在直至 128K 的窗口内能够找回插入信息. NIAH 主要检验检索, 不覆盖多文件依赖推理, patch 正确性或长上下文中的干扰鲁棒性. 128K 表示已经训练并通过该检索测试的窗口, 对真实仓库仍需结合 RepoBench, SWE-Bench 等任务结果判断.
3. 对齐阶段把可验证反馈转成训练信号
3.1. SFT 混合代码, 数学和通用指令
SFT 数据包括约 20k 代码指令, 30k 数学指令, 以及从 DeepSeek-V2 指令集中采样的通用数据, 总量约 300M token. 训练使用 cosine 调度, warm-up 100 步, 初始学习率 , batch 约 1M token, 模型总计接触约 1B token. 指令条数与训练 token 暴露量口径不同, 后者包含重复 epoch 或采样.
16B 在 SFT 阶段继续保留 FIM 数据, 避免自然语言指令微调完全覆盖中间补全格式. 这项安排使同一个 Lite-Instruct 模型既能回答代码问题, 又能使用前后缀补中间. 报告没有给出 SFT 前后 FIM 的单独消融, Table 6 展示的是 Lite-Base, 因而只能确认训练方案保留该目标, 不能量化对齐后 FIM 能力保留了多少.
3.2. 编译器 0/1 信号先用于训练奖励模型
数学任务可以用 ground-truth 判定答案. 代码任务也能用编译和测试给出 0/1 反馈, 但有限测试用例无法覆盖所有行为: 一个错误程序可能碰巧通过, 一个输出格式差异也可能被判失败. 直接把该二值结果作为强化学习奖励, 梯度信号离散且带有测试覆盖噪声.
团队先用编译器与测试产生的数据训练代码奖励模型, 再由奖励模型给强化学习提供连续信号. Figure 3 在内部 LeetCode 与 LeetCode-zh 测试上显示, 奖励模型信号优于原始编译器信号. 奖励模型可以从大量已标注样本中学习跨题型特征, 但它不会自动获得测试未覆盖的真实正确性. 其误差可能被策略模型利用, 所以结果支持信号更有效, 不表示奖励已经等价于程序验证.
3.3. GRPO 省去 critic, 仍依赖组内比较质量
强化学习阶段使用 Group Relative Policy Optimization(GRPO), 代码 prompt 过滤后约 40k, 每条配有测试用例. GRPO 对同一 prompt 采样一组回答, 通过组内奖励的相对关系构造优势, 无需像 PPO 那样额外维护 critic 模型. 对 236B 总参数的 MoE, 少一个 critic 能显著减少训练权重与前向计算负担.
省去 critic 不会消除奖励偏差. 如果同组样本整体质量都低, 或奖励模型在某类代码上系统误判, 相对优势仍会把策略推向错误方向. 报告用内部数据比较奖励信号, 但没有公开奖励模型结构, 训练集规模, 组大小与 KL 设置. 因此可以复述 GRPO 的成本优势和信号来源, 无法从报告完整复现 RL 配方.
4. 代码评测要按生成, 补全和修复分开读
函数级生成、代码补全和软件修复是三种不同能力, 不能用一个 HumanEval 分数代替.
4.1. 函数生成与竞赛题衡量不同难度
Table 3 在 greedy 解码下给出 236B/21B Instruct 的 Python HumanEval 90.2%, 多语言平均 75.3%, MBPP+ 76.2%. 表内 GPT-4o 的多语言平均为 76.4%, GPT-4-Turbo-0409 为 72.3%. Lite 的多语言平均为 65.6%, 高于上一代 DeepSeek-Coder-Instruct 33B 的 61.9%. 这些数字显示 MoE 续训在函数级生成上取得较高参数效率, 但 HumanEval 的短函数不能代替软件修复结果.
LiveCodeBench 只取 2023 年 12 月至 2024 年 6 月子集, 因为预训练代码截止在 2023 年 11 月以前. 236B 总分 43.4%, 与表内 GPT-4o 相同, 低于 GPT-4-Turbo-0409 的 45.7%. USACO 为 12.1%. LiveCodeBench 的持续新增题降低直接污染风险; USACO 的复杂算法题和高质量测试则显示标准函数生成成绩无法等比例转化为竞赛能力.
CRUXEval 包含 800 个 Python 函数及输入输出, I 任务由输入预测输出, O 任务由输出反推输入. 236B 的 I-COT 为 70.0%, O-COT 为 75.1%. 报告把与更大闭源模型的差距部分归因于仅激活 21B 参数, 这是作者解释, 不是控制变量实验. 架构, 训练数据与对齐方法也同时不同.
4.2. Lite 的补全成绩对应低激活成本场景
RepoBench v1.1 来自 2023 年 10 月 6 日至 12 月 31 日创建的 Python 与 Java 仓库. 为避开 11 月前的训练数据, 报告只使用 2023 年 12 月子集. Lite-Base 的 Python 平均为 38.9%, 接近上一代 33B Base 的 39.1%; Java 平均为 43.3%. 它每个 token 激活 2.4B 参数, 但部署速度仍取决于专家并行和硬件通信, 不能只按激活参数线性推算.
单行 FIM 的 Table 6 中, Lite-Base 在 Python 为 80.0%, Java 为 89.1%, JavaScript 为 87.2%, 均值 86.4%. 结果与 0.5 FIM 训练目标一致, 也说明大模型没有参与这条产品定位的竞争. Exact match 对格式敏感, 一行完全一致适合评价自动补全接受概率, 不能度量语义等价的多行修复.
4.3. 软件修复暴露长上下文之外的瓶颈
Table 7 同时报告 Defects4J, SWE-Bench 与 Aider. 236B Instruct 分别为 21.0%, 12.7%, 73.7%. SWE-Bench 要求根据 GitHub issue 修改真实仓库并通过测试, 它把问题理解, 文件定位, patch 生成与验证串在一起. 12.7% 是报告中首个超过 10% 的开源成绩, 但也意味着大多数问题仍未修复. Lite-Instruct 在 SWE-Bench 为 0.0%, 表明 128K 窗口本身不能弥补模型容量, 检索和复杂指令执行的不足.
Aider 的 73.7% 高于表内 GPT-4o 的 72.9%, Defects4J 21.0% 则低于 GPT-4o 的 26.1%, SWE-Bench 12.7% 也低于 26.7%. 三个基准的输入形式, patch 范围与评分程序不同, 不能取一个最高数字概括所有修复能力. 更稳妥的结论是 V2 已能在部分代码编辑协议中接近闭源模型, 对开放式真实 issue 仍有明显缺口.
5. 数学和通用能力显示了配比的收益与代价
5.1. 数学成绩受益于数据与可验证对齐
Table 9 使用 greedy 且不调用外部工具. 236B Instruct 在 GSM8K 为 94.9%, MATH 为 75.7%, 后者接近表内 GPT-4o 的 76.6%. AIME 2024 为 4/30, maj@64 为 5/30, Math Odyssey 为 53.7%. AIME 分母很小, 单题变化就会明显改变比例, 所以报告保留答对题数比换算百分比更合适.
数学提升同时来自 221B 数学预训练语料, 30k SFT 数学指令和 ground-truth 奖励, 报告没有逐项消融三者贡献. 可验证答案让强化学习信号比开放式文本稳定, 但 GSM8K 与 MATH 成绩不能直接归因于 GRPO. 1B 语料消融只报告 HumanEval 与 MBPP, 没有给出数学语料的对应小模型对照.
5.2. 通用能力没有因 30% 自然语言完全保真
Table 10 与 DeepSeek-V2 Chat 对比时, V2-Coder 在部分推理和指令指标上更高, 例如 BBH 为 83.9 对 79.7, Arena-Hard 为 65.0 对 41.6. 知识型任务出现回落: TriviaQA 为 82.3 对 86.7, NaturalQuestions 为 47.5 对 53.4. MT-Bench 与 AlignBench 也略低于 DeepSeek-V2 Chat.
这些变化符合定向续训的能力再分配. 60% 代码和 10% 数学增强结构化生成与推理, 30% 自然语言避免通用能力大幅丢失, 但无法保证所有知识指标不退. 报告在结论中也把 instruction-following 和复杂场景列为后续方向. V2 的进步集中在代码, 数学, 长上下文和参数激活效率; 真实仓库修复与稳定执行复杂要求仍是评测中最清楚的边界.
迭代召回的每一轮都会改变下一轮分类器的数据分布. 域名阈值先扩大覆盖, URL 标注再补同站遗漏页面, GitHub 两轮筛选则继续提高源码相关性. 这比只按扩展名抓取更容易得到教程, issue 与代码说明, 也会继承种子集合的领域和语言偏好. 报告没有公开误报率, 分类阈值曲线和 338 种语言各自占比, 无法判断长尾语言是否均衡.
1B 消融需要按对照拆开. 旧语料与新语料都训练 1T 时, HumanEval 和 MBPP 的差异可归于语料管线. 新语料从 1T 继续到 2T 后的提升同时包含更多训练量. 引言给出的总增幅跨越了语料与 token 数两个变量, 不能全算作过滤算法收益. 1B 的数据瓶颈也不必然等同于 236B MoE, 所以完整模型评测仍然必要.
MoE 的总参数和激活参数回答不同问题. 总参数描述专家库容量, 激活参数近似单个 token 经过的权重规模. 未激活专家仍需驻留或在设备间分布, 路由和 all-to-all 通信也会影响速度. 236B/21B 不表示部署只需容纳 21B 权重, Lite 16B/2.4B 也不能直接等同于 2.4B Dense 模型.
RepoBench 中 Lite 接近更大的上一代 Dense 模型, 支持其参数效率, 但报告没有同硬件吞吐曲线. 专家并行, batch 大小和内存带宽会改变真实延迟. 激活参数适合解释每 token 计算为什么较低, 不能据此线性推算 IDE 响应时间. Lite 的产品定位还依赖 FIM 目标, 并非只由参数量决定.
Lite 与 236B 的训练目标已经分流. IDE 补全通常输入光标前后代码, 输出短且要求低延迟, Lite 的 0.5 FIM 与 2.4B 激活适合此场景. 大版本只做 next-token prediction, 再通过 SFT 和 RL 加强长代码生成与复杂请求. 两档模型不是同一目标上的简单缩放, 因而不能拿缺少 FIM 训练的大版本替代 Lite 的 PSM 使用路径.
两阶段 YaRN 训练控制位置分布变化. 先用 32K, batch 1152 训练 1000 步, 再用 128K, batch 288 训练 1000 步. 序列长度扩大四倍时 batch 缩小四倍, 每步 token 规模保持相近. 上采样长文档同样关键: 位置编码允许远距离输入, 只有样本真正出现远端依赖, 参数才获得利用它的梯度.
NIAH 证明在 128K 内找回插入信息, 不证明能修复 128K 仓库. 软件修复还要定位相关文件, 理解 issue, 生成一致 patch 并通过环境测试. NIAH 表现良好而 SWE-Bench 只有 12.7%, 正好显示长距离检索只是任务的一环. 上下文窗口扩大不能自动提供搜索策略和执行反馈循环.
SFT 的约 300M 去重 token 与约 1B 训练暴露量是两个口径, 后者意味着重复采样或多轮遍历. 代码, 数学和通用指令共同维持交互面, 16B 还继续混入 FIM 以减少对齐遗忘. 报告没有给通用样本数, 类别采样比例和 FIM 混合率, 所以不能从公开数字还原完整 epoch 分布.
编译器 0/1 反馈混合了语法, 有限测试和测试覆盖三层信息. 奖励模型从这类标签学习后, 能给部分正确候选连续排序, 也可能把代码风格和常见模板误当成正确性. Figure 3 支持内部 LeetCode 上奖励模型信号更有效, 没有给出可抄成百分点的表格数值. 部署时仍需真实编译与测试.
GRPO 通过同一 prompt 的一组候选计算相对优势, 困难题不会仅因绝对奖励低而完全失去信号. 当组内奖励相同, 更新信息会变弱; 采样多样性和奖励分辨率直接影响训练. 连续奖励模型因此比稀疏 0/1 更适配组内比较. 组大小, KL 设置和奖励模型结构未公开, 公开报告不足以完整复现 RL 配方.
代码生成表的 greedy, 数学表的 maj@64 与修复表的 patch 成功率也不能混用. greedy 衡量一次确定性输出, maj@64 使用多次采样聚合, SWE-Bench 要求真实仓库测试通过. AIME 4/30 的分母很小, 单题就会明显改变比例. 对比模型时需要保持 prompt, 工具使用和采样预算一致.
RepoBench 和单行 FIM 分别测试跨文件条件与当前文件双侧条件. Lite 在单行 FIM 均值 86.4%, RepoBench Python 平均 38.9%, 难度与指标并不相同. 大版本没有 FIM 训练, 报告不提供对应 FIM 表项. 两档模型用途不同, 所以表格覆盖的任务也不同.
Defects4J, SWE-Bench 和 Aider 对修改范围及交互协议的要求不同. 236B 在 Aider 达到 73.7%, 在 SWE-Bench 只有 12.7%; 高 Aider 分数不能概括所有软件修复. Lite 在 SWE-Bench 为 0.0%, 也说明低激活补全模型无法仅靠 128K 上下文完成开放式修仓. 容量, 对齐, 检索和执行环境都会进入最终结果.
数学提升来自 221B 数学预训练数据, 约 30k SFT 数学指令和 ground-truth 奖励的共同作用. 报告没有逐项消融, 不能把 MATH 75.7% 全归给 GRPO. 数学最终答案易于核验, 代码测试则受覆盖率限制, 因而两类奖励采用不同构造. 可验证信号减少主观打分, 仍不保证推导过程或未测试行为正确.
Arena-Hard 上升而 TriviaQA, NaturalQuestions 回落, 说明定向续训改善部分复杂回答与推理, 同时损失一部分事实召回. 30% 自然语言的作用是维持可用通用接口, 不是完全保存 DeepSeek-V2 Chat 的能力曲线. 工程选型应按任务分档: Lite-Base 做仓库补全与 FIM, Lite-Instruct兼顾交互, 236B Instruct处理高难生成, 数学与软件编辑.
128K, 奖励模型与 GRPO 分别处理输入长度, 训练信号和优化成本, 三者没有替代关系. 长窗口承载证据, 奖励模型平滑有限测试产生的标签, GRPO 省去 critic. 完整的软件工程链路还要接入检索, 编译, 测试和失败回馈. Table 7 留下的差距表明, 这些外部环节仍是把模型能力转成稳定修复率的必要部分.
报告的开放材料也限定了复现深度. 数据召回给出种子类型, 迭代轮数与总 token, 没有发布全部 URL 和分类器; RL 给出 prompt 数量, 奖励来源与 GRPO 名称, 没有给组大小, KL 系数和奖励模型结构. 因而可以复现方法框架与公开评测, 无法得到逐样本相同的训练轨迹. 对结果的解释应停留在表格和已公开设置能支持的范围内.
从前后代演进看, DeepSeek-Coder-V2 同时改变了基座, 架构, 数据截止时间, token 数, 语言覆盖, 上下文和对齐方式. Lite 超过上一代 33B 的若干成绩不能只归因于 MoE, 新语料和通用基座同样是变量. 1B 语料消融, RepoBench 的激活参数对照和修复基准分别提供局部证据, 但报告没有覆盖所有变量的全因子实验.
V2 最有价值的工程判断是将任务分开配置. 补全依赖 FIM, 双侧上下文和低延迟; 复杂生成依赖更大激活容量与指令对齐; 软件修复还要加检索和执行验证; 数学可以利用 ground-truth 奖励. 单一模型接口可以承载这些请求, 训练数据和外部系统却必须针对各自误差来源设计. 这也是标准生成分数接近闭源后, SWE-Bench 仍保留明显差距的原因.
6. 与相邻路线的边界
第一代Coder. 第一代是从头训练Dense 1.3B/6.7B/33B, 2T、87%代码、16K和广泛FIM. V2来自DeepSeek-V2中间checkpoint, 使用MoE、6T继续训练、60/10/30和128K. 二者共享代码专门化目标, 权重谱系和架构均发生断裂. Lite的补全对照最接近第一代6.7B/33B, 大模型的复杂生成则引入更大基座与对齐. 分数差不能只归因于代际名称. 训练截止、benchmark版本和prompt也变了. CodeI/O. CodeI/O关注代码与执行输入输出之间的行为数据, 可用于训练程序推理或验证能力. Coder-V2预训练主线仍是token目标, 后训练加入编译/答案reward, 与CodeI/O相关但不等同. 后续数据不能倒灌为6T配方. 若模型根据I/O反推程序, 任务条件是行为样例; RepoBench条件是代码上下文; SWE-Bench条件是issue和仓库. 都属于代码智能, 监督与评测不同. 谱系应按论文分别记录. DSec.
DSec位于执行基础设施层. 它管理大规模agent训练所需沙箱、资源、镜像和生命周期, 可以承载代码运行与测试. Coder-V2是模型, 其后继应沿模型版本追踪. 两者在agent rollout系统中协作, 不构成模型代际关系. 沙箱吞吐提高能增加可执行轨迹数量, 奖励质量仍由任务、测试和隔离决定. 没有DSec也能在普通容器评测Coder-V2; 有DSec也不会自动获得代码能力. 这条边界避免把infra进展写成模型训练事实.
6.1. 结论坐标
Coder-V2的核心组合是「V2 MoE中间基座 + 6T代码数学语言续训 + 模型用途分流 + 128K + SFT/可验证反馈」. 16B Lite以2.4B active服务补全, 236B以21B active承担高难生成. total/active分别对应容量与单token主计算, 真实部署还支付权重、通信和cache. 数据结论限于公开配比、召回方法与消融. 60/10/30能同时提升代码数学并大体维持通用能力, 事实召回仍有回落. 338语言表示覆盖扩大, 不表示均匀质量. 6T nominal token也不等于6T独特知识. 128K扩大可见范围, MLA降低状态成本, 检索与执行仍决定软件任务. FIM只在Lite明确保留, 大模型的自然语言生成优势不能替代专门补洞协议. 标准代码题接近闭源模型, SWE-Bench差距证明真实仓库链路还有定位、工具与验证瓶颈.
继续预训练的优化动力学： 旧能力为什么会遗忘. 从继续优化新分布时, 更新方向为. 若某些通用样本在中权重下降, 维持它们的梯度约束随之变弱. 参数共享使代码更新可能移动事实召回所依赖的表示. 30%自然语言相当于replay, 用旧域样本持续提供约束, 只能覆盖被采样的子分布. 遗忘可用旧任务loss变化衡量:
表示该域变差. benchmark准确率还受prompt与对齐影响, Base checkpoint上的同分布loss更直接. Coder-V2报告主要给最终模型横向表, 没公布所有中间checkpoint的遗忘曲线. 重放比例并非越高越好. 自然语言增多会减少代码数学token, 专业化速度下降; 太少则通用能力退化. 60/10/30是经验选择. 可证伪实验应固定6T总量, 扫描自然语言比例并画代码—数学—通用Pareto frontier. 学习率回退与稳定性. 报告记录训练中将学习率回退到更小值, 这是大规模继续预训练的重要事实. MoE路由、数据域变化和大batch共同影响梯度. loss spike可能来自异常batch、路由失衡或数值问题, 降学习率减少单步参数位移
回退能恢复稳定, 也改变原计划训练轨迹. 只看最终token和峰值lr无法复现. 需要checkpoint、optimizer state、异常step和数据批次日志. 论文公开了稳定性处理, 没给完整故障诊断. 继续预训练的optimizer状态是否继承会改变过渡动态. 继承Adam二阶矩可平滑更新, 新数据梯度尺度变化时旧矩估计可能不匹配; 重置则带来新的warmup需求. 论文公开信息不足以确定全部状态处理, 因而这里只比较两种机制可能产生的差异. 六万亿token意味着什么. 训练步数取决于global batch token数:
没有batch就无法从6T推回step、GPU小时或学习率阶段. 长上下文阶段每token FLOPs高, token占比也不能直接等于成本占比. MoE active params进一步让参数总量与计算脱钩. nominal token包含重复采样. 若独特语料小于6T, 多轮采样会强化高质量模式也增加记忆. 数据manifest、去重率和采样epoch未完整公开. 因此6T适合描述优化消费量, 不适合描述独特知识总量. 中间checkpoint的审计价值. 沿训练进度保存checkpoint, 可以画代码、数学、通用loss和路由负载. 若代码先升后平台而事实召回持续降, 应提前停止或调mixture; 若数学在后期才增长, 说明需要更多token. 最终点无法展示这些权衡.
MoE还可追踪专家利用率、路由熵和领域条件分布. 路由熵突然下降可能预示专家坍缩; 某语言长期集中单专家可能形成专门化, 也可能造成热点. 只有统计相关, 不能把专家命名成确定领域模块.
MoE的容量、路由与训练信号： top-k路由梯度. 路由器分数经softmax得到, top-k截断让只有选中专家执行. 对选中集合归一化后
离散选择使未选专家难获任务梯度, 负载均衡项提供额外信号. token路由边界附近, 小logit变化可更换专家, 训练噪声与低精度都会影响分配. Coder-V2继承基座机制, 报告不以路由算法创新为中心. 共享专家的意义. 共享专家对所有token激活, 可承载通用模式, 减少路由专家重复学习共同知识. 若共享容量太大, 每token计算上升; 太小, 多个专家重复基础语法. 细粒度专家让同总激活量选择更多小单元, 组合更灵活, all-to-all元数据也更复杂. 代码、数学和自然语言共享符号、逻辑和英文标识符, 共享专家可能促进迁移. 这只是架构动机. 验证需要屏蔽或替换共享专家, 比较各域loss及路由, Coder-V2报告没有给这项专门消融. 参数效率的三种口径.
容量效率看固定active compute下loss; 训练效率看固定GPU小时下能力; 服务效率看固定延迟/成本下质量. 236B/21B active可能在容量效率占优, 大权重分片与通信使训练/服务效率取决于集群. 只报active params会漏系统代价, 只报total params会高估每token计算. 比较模型时可列向量
不同任务权重不同: 离线批处理重吞吐, IDE补全重尾延迟, 本地部署重显存. Lite与大模型的定位因此分开. 路由反例. 若某稀有语言token被路由到训练不足专家, MoE容量大也可能表现差. 若batch很小, 专家kernel矩阵尺寸不足, active FLOPs少却利用率低. 若跨节点网络拥塞, 通信覆盖计算. 这些反例限定「稀疏更经济」的成立条件. 可证伪比较需要真实tokens/s和p99延迟. Lite对Dense同active规模若更慢, 系统开销抵消; loss仍更低则容量优势保留. 两个结论可以同时成立, 不能用一个吞吐数字替代模型质量.
6.2. 长上下文代码任务的结构
128K里放什么. 代码上下文包括目标文件、依赖定义、测试、issue、日志和文档. 每类信息价值不同. 设候选片段长度, 相关价值, 预算, 选择近似背包问题:
检索器估计, 128K增大, 仍无法容纳所有仓库. 无关片段还会降低注意力集中度. 长窗口和更好检索应联合评测. 位置与依赖距离. 依赖距离按token计算, 同一文件结构经不同tokenizer会变化. 定义在100K前、当前调用在末尾, 模型要保持名称和类型. 同名符号、重载与分支版本形成干扰. Needle只测字符串召回, 执行正确还需组合语义. 测试可分单跳、双跳与多跳依赖. 单跳找到定义, 双跳沿类型再找实现, 多跳涉及配置和生成代码. 若128K只提高单跳, 位置容量成立, 仓库推理仍有限. 报告的软件修复差距与这种分层一致. 长输出与长输入.
128K通常指输入加输出总上下文上限, 不等于能稳定生成128K代码. 长输出误差累积、重复和结构漂移更严重. 软件patch通常输出短diff, 输入很长. 评测应分别报告long-context retrieval和long generation. MoE在长序列中还会看到更多token分布, 专家负载可能随文件区域变化. 大batch长序列有利于聚合路由, 单请求decode仍逐token. prefill与decode成本结构不同, 论文模型规格没有给生产服务结论. YaRN反例. 在128K能找到固定needle, 不代表短距代码不退化; 在自然文本长测有效, 不代表跨文件符号有效; 某个位置成功, 不代表所有位置均匀. 需要长度×位置×干扰的矩阵, 并与未扩展checkpoint对照. 如果检索后只需16K, 128K模型优势可能很小, 更长训练成本却已支付. 业务选择应测真实上下文分布. 最大窗口是能力上限, 不是默认输入目标.
代码、数学与通用三域的耦合： 代码促进数学的路径. 代码数据训练精确变量追踪、循环和条件结构, 数学问题可转成程序验证. 竞赛代码同时含组合、图论、数论. 正迁移可能来自共同潜在结构, 也可能只是数学数据本身增加. 配比消融才能分离. PAL或工具评测把计算交给执行器, 模型负责转写. 纯MATH评测要求自然语言推导. 两者同时提升才说明能力覆盖更广. 最终答案reward可能鼓励正确结果, 推理过程仍可能含错误但巧合得到答案. 数学促进代码的路径. 算法题需要复杂度、证明与边界推理. 数学语料可提高规划, 不一定改善API调用和仓库补全. 将代码benchmark按算法、库、前端、数据库分组, 若收益集中算法类, 数学迁移解释更可信.
反例是HumanEval常见题提升而LiveCodeBench新题不升, 可能来自污染或格式. 时间外、高难、隐藏测试更适合测推理迁移. 论文同时采用多项评测, 仍需按类别拆分. 通用语言保留. 30%自然语言帮助理解issue、文档和用户意图, 也维护百科与对话. 代码模型的通用分数接近V2, 某些QA回落. 「可用」和「完全保真」是不同标准. 对开发助手, 技术写作与需求理解可能比TriviaQA更重要; 对通用聊天则相反. 领域评价应按产品权重组合, 不宜把所有benchmark平均. 可以设
权重由场景决定. Lite补全与236B助手自然会有不同. 多语代码覆盖. 338语言支持扩大训练识别范围, 长尾数据量和评测不足. 共享语法带来迁移, 生态API和构建工具仍需要本域样本. supported language list属于覆盖声明, 不能解释为每种语言达到Python水平. 评测可宏平均避免头部语言淹没长尾, 同时报告按真实流量微平均. tokenizer fertility、编译通过和执行通过应分语言给出. 仅用翻译HumanEval测语法, 还缺生态任务.
后训练奖励的失效模式： 编译器奖励投机. 模型可能生成空壳、硬编码或跳过逻辑, 只要编译就得正奖励. 奖励模型若从文本预测编译, 可能把代码围栏、长度和常见模板当捷径. 构造编译均成功但语义一正一错的pair, 可以测试reward是否理解行为. 编译器版本也影响标签. 新语法、依赖缺失和警告即错误设置会改变0/1. 数据生成必须固定镜像与命令. 基础设施失败若被标成模型失败, reward含噪. ground-truth奖励稀疏. 只有最终答案正确给1, 复杂题大多样本全0, 组内GRPO无相对信号. 增大采样组提高碰到正确解概率, 成本上升. 部分分奖励可改善密度, 也可能引入错误捷径. 数学答案格式需规范化, 分数、等价表达和单位都可能造成误判. 代码测试覆盖也决定ground truth. 可验证不等于无噪声, 只是比主观judge更直接.
KL与能力漂移. 策略目标通常含
过小, 模型可能追逐reward损伤语言质量; 过大, 更新受限. 参考模型多为SFT checkpoint, 因而RL在其支持域内重排概率. 未公开系数限制复现深度. 从离线奖励到agent. 单回答奖励评估一个程序或答案. Agent任务包含多步命令、文件状态和测试反馈, credit assignment跨动作. Coder-V2报告的RL不能自动等同agentic RL. DSec可提供大规模执行环境, 训练算法和任务仍需另行定义. 软件修复的误差链可以拆成五个连续环节. 「Issue理解」 issue可能缺复现步骤、包含用户术语或指向错误模块. 模型要抽取期望行为和约束. 通用自然语言数据有帮助, benchmark中的结构化issue比真实报告干净. 错误理解后, 128K只会提供更多无关内容. 「定位」
从仓库选文件是检索问题. 文件名、符号、堆栈和测试失败各提供线索. SWE-Bench系统常配搜索工具, 纯模型上下文设置与agent设置不能混比. RepoBench给定上下文, 不测完整定位. 「编辑」 修改可能跨源码、测试、配置和迁移文件. FIM擅长单缺口, diff生成需要保持未改内容. patch应用失败、行号漂移和格式错误都属于接口问题. Aider等评测加入编辑协议, 分数受prompt/harness影响. 「验证」 测试可能耗时、flaky或依赖外部服务. 模型需读取失败再修复, 单轮pass@1不覆盖. 沙箱保证隔离和复现, DSec属于这一层基础设施. 验证链越稳定, reward噪声越低. 「为什么标准题强而修复弱」
标准题把定位、环境和测试准备好, 模型只生成函数. 修复任务把所有环节串联, 总成功率近似各环节条件概率乘积. 每环80%时五环仅约33%. 因而某个环节小幅改善可显著影响端到端, 模型分数不能直接外推.