Open R1 项目进展第一期

发布日期：2025-03-31 21:04:06 浏览次数： 2298

作者：Hugging Face

微信搜一搜，关注“Hugging Face”

DeepSeek R1 发布已经两周 (注: 原文发布于 2 月 2 日) 了，而我们启动 open-r1 项目——试图补齐它缺失的训练流程和合成数据——也才过了一周。这篇文章简单聊聊:

Open-R1 在模仿 DeepSeek-R1 流程和数据方面的进展
我们对 DeepSeek-R1 的认识和相关讨论
DeepSeek-R1 发布后社区搞出来的有趣项目

这既是项目的最新动态，也是一些关于 DeepSeek-R1 的有趣资料合集。

一周后的进展

先来看看 Open-R1 这周干了啥。我们一周前才开始这个项目，经过团队和社区的小伙伴们一起努力，已经有点成果可以分享了。

评估

要模仿人家，第一步得确认我们能不能复现 DeepSeek 的成绩。我们在 MATH-500 基准测试上试了试，果然能跟 DeepSeek 公布的数据对上号:

模型	MATH-500 (我们测的)	MATH-500 (DeepSeek 公布的)
DeepSeek-R1-Distill-Qwen-1.5B	81.6	83.9
DeepSeek-R1-Distill-Qwen-7B	91.8	92.8
DeepSeek-R1-Distill-Qwen-14B	94.2	93.9
DeepSeek-R1-Distill-Qwen-32B	95.0	94.3
DeepSeek-R1-Distill-Llama-8B	85.8	89.1
DeepSeek-R1-Distill-Llama-70B	93.4	94.5

想知道怎么测的？去看说明吧。

我们还发现，DeepSeek 模型生成的回答特别长，评估起来都费劲。在 OpenThoughts 数据集里，DeepSeek-R1 的回答平均有 6000 个 token，有些甚至超过 20000 个 token。啥概念呢？一页书大概 500 个单词，一个单词可能由 1 个及以上的 token 组成，所以很多回答能写满 10 多页！(来源:)

回答这么长，给后面用 GPRO 训练带来了很大的挑战。想要生成超长内容，需要很多的 GPU 显存来存储梯度和激活值。

为了让大家都能看到进展，我们搞了个 open-r1 评估排行榜，社区可以在这里随时关注我们的复现情况:

训练流程

Open R1 发布后，GRPO (分组相对策略优化) 被集成到了最新版 TRL () 中。有了这个，任何模型都能用一个或多个奖励函数来训练。GRPO 还能跟 DeepSpeed ZeRO 1/2/3 配合，实现多 GPU 并行训练，还用 vLLM 加速生成——毕竟在线训练最大的瓶颈就是生成速度。

from datasets import load_dataset
from trl import GRPOConfig, GRPOTrainer

dataset = load_dataset("trl-lib/tldr", split="train")

# 简单奖励: 回答接近 20 个字符的给高分
def reward_len(completions, **kwargs):
    return [-abs(20 - len(completion)) for completion in completions]

training_args = GRPOConfig(output_dir="Qwen2-0.5B-GRPO", logging_steps=10)
trainer = GRPOTrainer(
    model="Qwen/Qwen2-0.5B-Instruct",
    reward_funcs=reward_len,
    args=training_args,
    train_dataset=dataset,
)
trainer.train()

不过现在内存用量还是有点高，我们正在想办法优化。

合成数据生成

R1 报告里最让人兴奋的是，主模型能生成合成推理过程，小模型用这些数据微调后效果也能跟主模型差不多。所以我们也想能够复现这个合成推理数据集，让大家都能拿去调模型。

R1 这种大模型，难点在于怎么高效快速地生成数据。我们试了一周，调了各种配置。

一开始用两个 8xH100 节点跑模型，用 vLLM 当推理服务器。但效果不好，吞吐量低，只能同时处理 8 个请求，GPU 的 KV 缓存很快就满了。缓存一满，请求就被打断，如果设置了 PreemptionMode.RECOMPUTE ，就得等显存空出来再重跑。

后来我们换成 4 个 8xH100 节点，总共 32 个 GPU。这样显存够用，能同时跑 32 个请求，几乎不会因为缓存满而重新排队。

一开始我们批量发请求给 vLLM，但发现批量里慢的会拖后腿，GPU 利用率忽高忽低。新一批次得等上一批全跑完才开始。后来改成流式处理，GPU 利用率稳定多了:

改代码也不难。原来的批量推理代码是:

# 每批 500 个请求
for batch in batch_generator(dataset, bs=500):
    active_tasks = []
    for row in batch:
        task = asyncio.create_task(send_requests(row))
        active_tasks.add(task)
    if active_tasks:
        await asyncio.gather(*active_tasks)

现在流式处理的代码是:

active_tasks = []
for row in dataset:
    # 活跃请求控制在 500 个以下
    while len(active_tasks) >= 500:
        done, active_tasks = await asyncio.wait(
            active_tasks,
            return_when=asyncio.FIRST_COMPLETED
        )

    task = asyncio.create_task(send_requests(row))
    active_tasks.add(task)

# 等所有任务跑完
if active_tasks:
    await asyncio.gather(*active_tasks)