NLP——DeepCoder

注：本文包含 AI 辅助创作

Paper Summary

  • 核心内容：
    • 论文推出了 14B 模型 Deepcoder-14B-Preview（DeepCoder 是一款完全开源达到 o3-mini 水平的编程模型）
      • 基于 Deepseek-R1-Distilled-Qwen-14B 并通过分布式强化学习微调而成的代码推理模型
      • 在 LiveCodeBench 中实现了与 o3-mini 模型相当的性能，Pass@1（单次尝试通过率）准确率达60.6%
    • 重点：构建了高质量、可验证的代码数据集，并引入了算法与系统层面的优化，以实现高效的 RL 训练
    • Deepcoder-14B-Preview 是该方向上的第二个重要里程碑，其研发建立在作者之前的首款模型DeepScaleR-1.5B-Preview（聚焦数学推理任务）奠定的基础之上
    • 论文完整共享数据集、代码及训练方案
  • 该模型在 LiveCodeBench 上取得了令人印象深刻的 60.6% Pass@1 准确率（+8% 提升），以仅 14B 参数的规模，性能匹敌 o3-mini-2025-01-031 (Low) 和 o1-2024-12-17
  • 作者已将数据集、代码、训练日志和系统优化全部开源，旨在推动基于强化学习的智能扩展与加速

DeepCoder-14B-Preview 性能概览

  • 整体性能概览表：
    模型 LiveCodeBench (Pass@1)
    (2024年8月1日 - 2025年2月1日)    		 Codeforces 评分 Codeforces 百分位
    DeepCoder-14B-Preview 60.6 1936 95.3
    DeepSeek-R1-Distill-Qwen-14B 53.0 1791 92.7
    O3-Mini-2025-1-31 (Low) 60.9 1918 94.9
    O1-2024-12-17 (Low) 59.5 1991 96.1
  • 图 1： DeepCoder 在训练过程中的 LiveCodeBench (LCB) 分数。在第 180 步时，上下文长度扩展至 32K。最佳的 32K 检查点用于推理时扩展至 64K，最终实现 60.6% 的 LCB 分数——性能与 o3-mini 相当
  • 近年来，我们见证了通过 RL 在数学领域（例如 DeepScaleR、AReaL、Light-R1、DAPO）显著提升了推理模型的扩展能力。然而，编程领域的进展相对滞后，主要原因是构建具有可靠、可验证奖励的高质量数据集存在挑战
  • 在这篇博客中，作者将公开训练一个小型模型成为强大竞争性编程选手的“配方”，使用强化学习技术使其达到与 o3-mini 相当的水平
    • 作者介绍了 DeepCoder-14B-Preview，该模型在 32 块 H100 GPU 上，利用 2.4 万个可验证的编程问题训练了 2.5 周，其表现达到甚至超越了 OpenAI 的 o3-mini 在多个编程基准测试上的成绩
    • 作者还开源了 verl-pipe，这是对 verl 后训练系统的扩展，包含多项系统优化，可将端到端训练速度提升 2 倍

数据集构建

  • 在数学领域，先前的研究表明，使用可验证奖励进行强化学习可以显著增强模型的推理能力。然而，与互联网上存在大量高质量、可验证数据的数学领域不同，编程领域面临此类数据相对稀缺的问题
  • 在早期实验中，作者评估了几个流行的编程数据集，包括 APPS、TACO、CodeContests、KodCode 和 LeetCode，作者发现：
    • 有些数据集对于论文的模型来说太简单（如 KodCode、LeetCode）
    • 另一些数据集则存在噪声或包含有缺陷或缺失测试用例的不可验证问题
    • 这些问题通常会产生无效或误导性的奖励信号，最终导致 RL 训练不稳定
  • 为克服这些限制，作者精心策划了一个高质量的训练集，包含：
    • TACO 验证过的问题
    • PrimeIntellect 的 SYNTHETIC-1 数据集中经过验证的问题
    • 2023 年 5 月 1 日至 2024 年 7 月 31 日期间提交的 LiveCodeBench 问题
  • 为了确保数据质量以实现有效的 RL 训练，作者实施了严格的过滤流程：
    • 1）程序化验证 ：每个问题都使用外部官方解决方案自动验证
      • 论文只保留那些官方解决方案能通过所有单元测试的问题
      • 此过程在 tests/rewards/test_code_batch.py 中自动化完成
    • 2）测试用例过滤 ：每个问题必须至少包含 5 个单元测试
      • 论文发现，测试用例较少的问题容易引发 “Reward Hacking” 行为 ，即模型学会通过识别常见测试用例来直接打印出记忆的答案
    • 3）去重 ：论文移除了跨数据集的重复问题，以避免污染
      • 论文对三个训练数据集（Taco Verified、PrimeIntellect SYNTHETIC-1 和 LCB (05/01/23-07/31/24)）进行了去重，并验证了测试数据集（LCB (08/01/24-02/01/25) 和 57 场 Codeforces 比赛）中没有污染
  • 经过过滤后，论文得到了 2.4 万个高质量的编程问题用于 RL 训练，其中包括：
    • 7500 个来自 TACO Verified 的问题
    • 1.6 万个来自 PrimeIntellect 的 SYNTHETIC-1 的问题
    • 600 个来自 LiveCodeBench 的问题

代码沙箱环境

  • 为了计算代码 RL 训练的奖励，我们必须在代码沙箱中运行模型生成代码的单元测试
  • 在每次 RL 迭代中，论文的训练批次需要在 1024 个问题上进行评估，每个问题都包含多个单元测试（大于等于 5 个）
  • 这种繁重的工作负载要求并行扩展 100 多个代码沙箱，以确保在合理时间内准确验证大语言模型生成的代码
  • 目前，论文使用两种沙箱，下面分别进行介绍

Together Code Interpreter

  • 这是一个快速、高效的环境，与论文的 RL 训练直接兼容，每个问题的成本仅为 3 美分
  • 论文一直在努力将 Together Code Interpreter 可靠地扩展到 100 多个并发沙箱和每分钟 1000 多次沙箱执行
  • 这些沙箱暴露了 stdout、stdin 和代码输出的最后一行，同时安全地限制执行并将代码与主机系统隔离
  • Together Code Interpreter 目前处于测试阶段；详细信息请参阅 Together Code Interpreter 文档，集成示例代码可在论文的代码仓库中找到

Local Code Sandbox

  • 启动一个独立的、有防护的 Python 子进程作为本地沙箱，通过 stdin 接收测试用例输入，并将答案打印到 stdout
  • 论文的本地沙箱遵循官方 LiveCodeBench 仓库的相同评估代码，确保论文的结果与现有排行榜一致

奖励函数

  • 论文的奖励函数采用稀疏的结果奖励模型（ORM）
  • 论文避免分配部分奖励，例如思维链惩罚，或如果 K/N 个测试通过则分配 K/N 的奖励，因为这可能导致 “Reward Hacking” 行为，即大语言模型学会直接打印出公共测试的答案，或错误地收敛于通过简单的边缘情况
  • 1 ：生成的代码必须通过所有采样的单元测试
    • 由于一些问题包含数百个测试，使得完全验证不切实际，论文为每个问题采样 15 个最具挑战性的测试，这些测试由其输入字符串的长度确定
  • 0 ：如果大语言模型的代码至少在一个测试用例上失败，或者答案格式不正确（即缺少 python [CODE]），则不给予奖励
    • 每个测试用例的超时时间为 6-12 秒

训练配方

GRPO+：GRPO 的稳定版本

  • 图 2： GRPO+ 和 GRPO 在 16K 运行中的平均训练奖励。GRPO 的奖励曲线最终崩溃。由于 Clip High，GRPO+ 的曲线保持稳定
  • 图 3： 由于长序列过滤，GRPO+ 的响应长度随时间稳步增长
  • 图 4： Clip High 和无熵损失确保了 GRPO+ 的 token 级熵不会崩溃，并鼓励足够的探索
  • 论文通过整合 DAPO 的见解，增强了原始的 GRPO 算法，以实现更稳定的训练：
    • 无熵损失 ：论文观察到包含熵损失项常常导致不稳定，熵会呈指数级增长并最终导致训练崩溃。为缓解此问题，论文完全消除了熵损失
    • 无 KL 损失 (来自 DAPO) ：消除 KL 损失可以防止大语言模型被约束在原始 SFT 模型的信任区域内。这一移除也免去了计算参考策略的对数概率的需要，从而加速了训练
    • 长序列过滤 (来自 DAPO) ：为了保留长上下文推理能力，论文对截断的序列屏蔽损失。这项技术使 DeepCoder 能够推广到 64K 上下文的推理，尽管它是在 32K 上下文下训练的。如图 3 所示，这种方法允许响应长度自然增长而不受截断惩罚
    • Clip High (来自 DAPO) ：通过增加 GRPO/PPO 代理损失的上限，论文鼓励更多探索并稳定熵。图 4 表明，这种调整带来了更稳定的训练和改进的模型性能

迭代式上下文延长：开箱即用的泛化能力

  • 在论文最初的 DeepScaleR 博客文章 中，论文介绍了迭代式上下文延长，这是一种训练技术，使语言模型能够先在较短的上下文长度下学习有效思考，然后推广到更长的上下文
  • 这种方法帮助论文的 1.5B 参数模型在将其上下文窗口从 8K -> 16K -> 24K 扩展时，下游性能稳步提升，在 AIME 上的准确率从 33% -> 38% -> 43%，最终达到 O1-preview 的性能
  • 然而，在将此技术应用于论文的 14B 参数模型时，论文遇到了新的挑战：
    • 14B 参数模型已经比 1.5B 参数模型拥有显著更强的推理能力，这意味着进一步的改进需要解决更难的问题
    • 这些更难的问题自然需要比小模型使用的 8K 起始点更长的上下文窗口
    • 从短上下文开始并惩罚模型超出该窗口的行为产生了负面影响——导致初始性能下降、响应变短以及模型在长上下文上推理能力的退化
  • 为了在实现高效训练的同时保留长上下文推理能力，论文采用了来自 DAPO 的长序列过滤技术
    • 该技术在训练期间屏蔽截断的序列，因此模型不会因生成超出当前上下文限制的深思熟虑但冗长的输出而受到惩罚
    • 结果是，模型在较短的上下文中训练时仍然可以“长思考”
  • 论文将迭代式上下文延长应用于论文的 DeepCoder-14B-Preview，将上下文窗口从 16K 扩展到 32K。在 LiveCodeBench 上，该模型实现了：
    • 16K 和 32K 上的准确率分别为 54% -> 58%，
    • 在 64K 上下文评估时达到 60.6%，展示了超越其训练上下文的强大泛化能力
  • 这种泛化能力与像 DeepSeek-R1-Distill-Qwen-14B 这样的基础蒸馏模型形成鲜明对比，后者在其训练上下文长度之外会达到性能瓶颈：
    模型 16K 32K 64K
    DeepCoder-14B-Preview 45.6 57.9 60.6
    DeepSeek-R1-Distill-Qwen-14B 50.2 53.0 53.0
  • 虽然由于其更长的平均响应长度导致截断和分数惩罚，DeepCoder 在 16K 的原始性能较低，但它最终在 64K 上凭借其在更长上下文中推理的能力超越了其他模型
  • 图 5： DeepCoder 在训练过程中的平均响应长度和训练奖励。平均响应长度从 8K 增加到 17.5K 上下文长度 > Baby, there ain't no mountain high enough. Ain't no context long enough. — Inspired by Marvin Gaye & Tammi Terrell
  • DeepCoder 的成功直接源于将迭代式上下文延长与长序列过滤相结合。如图 5 所示，在整个训练过程中，模型的平均响应长度从 8K 稳步增长到 17.5K，同时平均奖励从 0.6 提升到 0.7——这清晰地表明，模型正在逐步学习更具可扩展性和连贯性的思考模式

评估

  • 论文在多个编程基准上评估了Deepcoder-14B-Preview，包括 LiveCodeBench (LCB)、Codeforces 和 HumanEval+ 以及AIME2024
  • 拥有 14B 参数的模型在整个编程基准测试中展示了强大的性能，LiveCodeBench 达到了 60.6%，Codeforces 评分为 1936 分，与o3-mini（低配置版）和o1的表现相当
  • 此外，尽管该模型没有专门针对数学任务进行训练，但其从编程任务中获得的推理能力很好地推广到了数学领域
    • 这在其 AIME2024 得分 73.8% 上体现出来，比基础模型提高了 4.1%
    • 总体而言，论文的模型在编程和数学领域都表现出色
  • 评估结果如下：
    Model LCB (8/1/24-2/1/25) Codeforces Rating* Codeforces Percentile* HumanEval+Pass@1 AIME 2024
    DeepCoder-14B-Preview (ours) 60.6 1936 95.3 92.6 73.8
    DeepSeek-R1-Distill-Qwen-14B 53.0 1791 92.7 92.0 69.7
    O1-2024-12-17 (Low) 59.5 1991 96.1 90.8 74.4
    O3-Mini-2025-1-31 (Low) 60.9 1918 94.9 92.6 60.0
    O1-Preview 42.7 1658 88.5 89 40.0
    Deepseek-R1 62.8 1948 95.4 92.6 79.8
    Llama-4-Behemoth** 49.4 - - -
    • * 表示由于 DeepSeek 和 OpenAI 对 Codeforces 的评估为内部流程，有关 Codeforces 评估的更多细节，可参考附录A
    • ** 表示非推理型模型
  • 图6：LiveCodeBench Pass@1准确率与模型规模对比。DeepCoder仅需14B 参数，性能便已与前沿推理模型o1和o3-mini（低配置版）持平

训练后阶段的系统优化

  • 采用长上下文强化学习训练大型语言模型十分耗时，需要在长上下文环境中反复进行采样和训练
  • 若缺乏系统级优化，完整的训练流程可能需要数周甚至数月，论文针对 14B 参数模型的编程任务训练，每一步便需 1200-2500 秒，总训练时长更是长达2.5周
  • 为此，论文开发并开源了 verl-pipeline ，这是基于开源强化学习人类反馈（RLHF）库 verl 的优化扩展版本
    • 该扩展通过多项系统级改进，实现了端到端强化学习训练的加速，较基础版 verl 实现最高可提升2.5倍训练速度
    • 论文将这些全新的系统优化方案应用于 DeepCoder-1.5B-Preview 模型的训练，使其在 LCB 测试集上的通过率达到 25%，较Deepseek-R1-Distill-Qwen-1.5B模型提升了 8%
  • 作者诚邀整个社区（包括verl开发团队及其他新兴项目团队）采用这些优化方案，并在此基础上进一步开发创新

采样器是性能瓶颈

  • 图7：Verl的PPO/GRPO训练流程。每个强化学习迭代周期均包含采样、奖励函数计算和训练三个环节。其中，采样是性能瓶颈；训练速度受限于生成长序列的“滞后采样器”（straggler samplers）
  • 在训练后阶段的系统中，采样时间往往是主要瓶颈，使用 vLLM、SGLang 等推理引擎生成超长序列（最长可达32K tokens）会产生较高延迟
  • 如图7所示的 Verl PPO/GRPO 流程中，响应长度的不一致会导致部分采样器成为“滞后采样器”
    • 这些滞后采样器会拖延训练进度，而已完成任务的采样器则处于闲置状态，最终导致 GPU 利用率低下

基础解决方案：Minibatch Pipelining

  • 图8：小批量流水线流程。采样器与训练器分属不同的工作组。当采样器完成小批量（用于PPO/GRPO）生成并输出后，训练器工作组会异步处理这些数据。在一个迭代周期结束时，训练器会将权重广播至采样器
  • 为减少训练后阶段的设备闲置时间，作者将采样与训练流程进行流水线处理，允许训练器在采样器继续生成下一批数据的同时，提前对已生成的小批量数据进行更新。这种并行重叠操作有助于掩盖采样过程中的延迟
  • 然而，该方案存在三个关键局限性：
    • 1）首先，小批量数据的平均序列长度会随时间推移而增加，这会延长后续小批量数据的训练时间。最终，最后几批数据的训练往往会在采样完成后才结束，从而限制了流水线方案的收益
    • 2）其次，流水线方案需要在采样器和训练器之间分配GPU资源，这会减少可用于采样的设备数量。与Verl不同（Verl可在同一GPU资源池内动态切换采样器和训练器角色），这种静态资源分配方式会因采样器数量减少，导致端到端采样时间延长
    • 3）最后，奖励函数计算可能需要较长时间（尤其对于编程类任务而言，每个强化学习迭代周期可能需要运行数千次单元测试）。在默认的Verl流程中，奖励计算需在采样完成后，由主节点（head node）统一执行
  • 尽管存在上述限制，我们仍在代码库的 ray_trainer_pipeline.py 文件中实现了小批量流水线方案，并发现通过微批量（microbatching）技术可进一步改进流水线性能

论文的解决方案：One-Off Pipelining

  • 图9：一次性流水线流程。采样器提前一个迭代周期生成数据批次，而训练器则使用上一个迭代周期的数据更新梯度。其次，奖励函数计算与采样过程交叉进行。该方案不会为GRPO/PPO的在策略（on-policy）算法引入异步离策略（off-policy）样本
  • 为实现训练、奖励计算与采样的完整流水线化，我们提出了 一次性流水线（One-Off Pipelining） 方案。其核心思路十分简洁：
    • 牺牲第一个强化学习迭代周期，仅用于采样；
    • 在下一个迭代周期中，再使用上一周期采样得到的数据进行训练
    • 这种设计能让采样与训练并行进行，彻底消除采样完成后训练器的闲置时间
  • 其次，作者将奖励计算与采样过程交叉结合，一旦某个请求处理完成，便立即对其进行奖励计算
    • 这一改进减少了奖励评估的额外开销，尤其适用于编程类等计算密集型任务（如测试用例执行）
  • 作者在 verl 分支的 ray_trainer_async.py 文件中实现了一次性流水线方案

端到端性能

  • 在 图10 中，我们针对数学和编程两类任务负载，分别评估了 verl 基础版、微批量流水线方案和一次性流水线方案的性能
  • 为保证公平性，所有基准方案均通过 Python 线程池并行计算奖励；而 verl 官方版本对每个样本的奖励计算为串行执行，这对于编程任务而言耗时过长，不具备实际可行性
  • 作者在8台A100设备上对Deepcoder-1.5B-Preview模型进行评估，并调整采样器与训练器的比例，以更好地平衡两者的运行时间
  • 在数学任务中，一次性流水线方案将每个强化学习迭代周期的时间缩短了1.4倍。需说明的是，数学任务的奖励计算时间几乎为零，因为其仅涉及基础的sympy检查。具体而言，一次性流水线方案完全掩盖了训练器的运行时间，而微批量流水线方案中最后一批数据的训练仍会出现延迟
  • 在编程任务中，奖励计算需在每个强化学习迭代周期内运行数千次测试，是一个耗时过程。一次性流水线方案同时掩盖了训练器和奖励计算的时间，最终将端到端训练时间缩短了2倍
  • 图10：一次性流水线方案完全掩盖了训练器和奖励计算的时间，使数学任务的训练时间缩短1.4倍 ，编程任务的训练时间缩短2倍
  • 最重要的是，一次性流水线方案不仅有效，还能扩展应用于复杂的编程任务
    • 作者使用 ray_trainer_async.py 训练出 DeepCoder-1.5B-Preview 模型，其 LCB 得分较基础蒸馏模型提升了 8%
  • 具体数据为：
    Model LCB(8/1/24-2/1/25) Codeforces Rating Codeforces Percentile HumanEval+
    DeepCoder-1.5B-Preview 25.1 963 28.5 73.0
    Deepseek-R1-Distill-Qwen-1.5B 16.9 615 1.9 58.3

附录

附录 A. 训练基础设施与成本

  • DeepCoder-14B-Preview 的训练在 Together AI 提供的云平台上进行，使用了 32 块 NVIDIA H100 GPU
    • 整个训练过程持续了 2.5 周
  • 论文采用了高效的分布式训练框架和优化的通信策略，以最大化 GPU 利用率
    • 得益于 verl-pipe 系统中的多项优化（包括梯度检查点、混合精度训练和高效的批处理调度），端到端的强化学习训练速度相比基线提升了 2 倍
  • 单次完整训练的成本主要由 GPU 小时和沙箱验证费用构成：
    • GPU 计算成本 ：约 $45,000
    • Together Code Interpreter 沙箱成本 ：约 $720 （基于 3¢/problem 和总计 24,000 个问题计算）
    • 总估算成本 ：约 $45,720

附录 B. 可复现性指南

  • 为确保研究结果的可复现性，作者在 GitHub 仓库中提供了详细的文档和脚本：
    • 1）数据准备 ：scripts/download_and_filter_datasets.py 脚本自动化了从原始来源下载、验证和过滤数据集的全过程
    • 2）环境配置 ：environment.yml 文件定义了精确的 Python 依赖环境
    • 3）训练启动 ：launch_training.sh 脚本包含了启动 GRPO+ 训练的所有参数和配置
    • 4）评估流程 ：eval/ 目录下的脚本可用于在 LiveCodeBench、Codeforces 和 AIME2024 等基准上复现我们的评估结果
  • 强烈建议使用者参考 README.md 中的“快速开始”部分来部署和运行模型

附录 C. 局限性与未来工作

  • 尽管 DeepCoder-14B-Preview 取得了显著成果，但仍存在一些局限性：
    • 领域专注 ：模型在竞争性编程任务上表现出色，但在真实世界软件工程任务（如调试大型代码库、理解复杂 API）上的泛化能力有待验证
    • 语言覆盖 ：当前版本主要针对 Python 代码生成进行了优化，对其他编程语言的支持较弱
    • 推理延迟 ：由于其长上下文推理能力，在 64K 上下文下生成答案的延迟较高，可能不适用于对实时性要求极高的场景
  • 未来的工作将集中在解决这些局限性，并探索将此框架应用于更广泛的智能体任务，例如自主代理和复杂决策系统