32B IOI奧賽擊敗DeepSeek-R1！Open R1開源復(fù)刻第三彈，下一步R1-Zero

作者：新智元 2025-03-12 13:55:05

Hugging Face的Open R1重磅升級，7B擊敗Claude 3.7 Sonnet等一眾前沿模型。憑借CodeForces-CoTs數(shù)據(jù)集的10萬高質(zhì)量樣本、IOI難題的嚴(yán)苛測試，以及模擬真實(shí)競賽的提交策略優(yōu)化，這款模型展現(xiàn)了驚艷的性能。

Hugging Face的Open R1再度升級！

Hugging Face的Open R1是一個社區(qū)驅(qū)動的項(xiàng)目，目標(biāo)是創(chuàng)建一個完全開源的DeepSeek-R1版本。目前，已有模型如OlympicCoder-32B和數(shù)據(jù)集如codeforces發(fā)布，顯示了項(xiàng)目的進(jìn)展。

最新發(fā)布的7B和32B OlympicCoder，在IOI挑戰(zhàn)上超越了一眾前沿模型，比Claude 3.7 Sonnet還猛。

OlympicCoder已經(jīng)成了代碼推理界的「肌肉猛男」，有些模型規(guī)模比它大100倍，結(jié)果還是被它按在地上摩擦……

模型在2024年國際信息學(xué)奧林匹克競賽（IOI）50次提交中的表現(xiàn)

而這一切，得感謝Open R1的一系列騷操作：

CodeForces-CoTs數(shù)據(jù)集：近10萬個高質(zhì)量樣本，提煉自DeepSeek-R1，專門訓(xùn)練C++和Python代碼生成。
IOI基準(zhǔn)測試：拿2024年國際信息學(xué)奧林匹克競賽（IOI）的難題來虐AI，看看誰是真正的「代碼戰(zhàn)神」。
提交策略優(yōu)化：模擬OpenAI的策略，讓模型最大化得分，像真正的選手一樣參加比賽。

我們來扒一扒它是怎么煉成的，以及Hugging Face團(tuán)隊(duì)踩過的那些坑。

（小心，可能會讓你懷疑人生：AI連刷題都比你強(qiáng)了……）

CodeForces-CoTs數(shù)據(jù)集

CodeForces作為編程競賽的熱門平臺，其中的算法優(yōu)化問題極具挑戰(zhàn)性。

這使其成為一個有趣的數(shù)據(jù)集，用于提升和測試模型的代碼推理能力。

此次發(fā)布的open-r1/codeforces包含了超過1萬個問題，時間跨度從最初的競賽一直到2025年，其中約3000個問題是DeepMind和CodeContests中沒有的。

對于約60%的問題，數(shù)據(jù)集提供了競賽組織者撰寫的解題思路，這對理解原理至關(guān)重要。

同時，每個問題都從官方網(wǎng)站提取了3個正確解決方案。

open-r1/codeforces-cots數(shù)據(jù)集更是一大亮點(diǎn)，其中包含了DeepSeek-R1針對這些問題生成的近10萬個思維鏈（CoT）樣本，用C++和Python兩種語言呈現(xiàn)。

研究團(tuán)隊(duì)在這個數(shù)據(jù)集上對Qwen2.5 Coder Instruct 7B和32B進(jìn)行微調(diào)，得到了OlympicCoder-7B和OlympicCoder-32B模型。

代碼可驗(yàn)證性危機(jī)

雖然DeepMind和其他競賽數(shù)據(jù)集都包含測試用例，并聲稱是可驗(yàn)證的，但這些通常只是競賽網(wǎng)站上全套測試用例的一小部分。

特別是CodeForces，顯示的測試用例上限約為500個字符，這意味著這些數(shù)據(jù)集只包含符合此限制的較短、較簡單的測試用例。

例如，研究者選取了7個問題，R1生成的解決方案通過了全部公開測試用例，并將它們提交到CodeForces平臺：

盡管這些方案通過了較短的測試，但均未通過完整測試集。這凸顯了對新的可驗(yàn)證的編程競賽數(shù)據(jù)集的需求。

國際信息學(xué)奧林匹克競賽（IOI）

國際信息學(xué)奧林匹克競賽（IOI）是全球頂尖的編程競賽。

完整測試集遵循寬松的（CC-BY）許可發(fā)布，使其成為測試代碼推理能力的理想數(shù)據(jù)集。

如果你熟悉美國數(shù)學(xué)邀請賽（AIME），IOI就相當(dāng)于數(shù)學(xué)奧林匹克競賽（IMO）的編程版，參加AIME的最優(yōu)秀學(xué)生才有資格受邀參加IMO。

IOI的問題設(shè)計(jì)獨(dú)特，每個問題細(xì)分為多個子任務(wù)，各子任務(wù)輸入約束不同。

參賽者要解決子任務(wù)，提交的方案須在嚴(yán)格時限內(nèi)通過所有測試用例。

最后子任務(wù)通常是完整復(fù)雜問題，而前面子任務(wù)相對簡單、約束更多，參賽者常針對特定子任務(wù)拿部分分?jǐn)?shù)，競賽中得滿分十分罕見。

團(tuán)隊(duì)整理了2020-2024年的IOI問題，將它們拆分為子任務(wù)，使每個提示都能解決一個特定的子任務(wù)，便于有針對性地訓(xùn)練和評估。

他們還在open-r1/ioi和open-r1/ioi-test-cases中發(fā)布了處理后的問題陳述、評分檢查文件及測試用例，同時創(chuàng)建了自定義代碼，用于運(yùn)行解決方案并按IOI規(guī)則評分，代碼可在https://github.com/huggingface/ioi上獲取。

研究者對2024年IOI上40多個領(lǐng)先的推理模型進(jìn)行了全面評估。

每個問題的提交次數(shù)限制為50次，采用與OpenAI類似的選擇策略模擬得分。

評估結(jié)果顯示，OlympicCoder模型表現(xiàn)出色。

OlympicCoder-32B在50次提交限制下，超越了o1-mini、DeepSeek-R1、Claude-3.7-Sonnet-thinking等模型。

模型在2024年國際信息學(xué)奧林匹克競賽（IOI）50次提交中的表現(xiàn)

提交策略

這種提交策略可能不利于非推理模型，像OlympicCoder-32B-Instruct和Qwen-2.5-Coder-32B-Instruct。

為模擬真實(shí)競賽，團(tuán)隊(duì)采用類似OpenAI用于o1-ioi的循環(huán)提交策略。

首先提交針對最后一個子任務(wù)的解決方案，然后是倒數(shù)第二個子任務(wù)的方案，以此類推，只有選定提交時才評估解決方案。

若子任務(wù)已被之前選定的提交解決，就跳過針對該子任務(wù)的提交。

在每個目標(biāo)子任務(wù)里，傾向于選擇更長的生成內(nèi)容，這對推理模型合理，對其他模型不太適用。

如果取消50次提交限制，并評估生成的所有提交，會得到以下結(jié)果：

國際信息學(xué)奧林匹克競賽（2024年）無提交限制時模型的表現(xiàn)

基于R1軌跡訓(xùn)練的經(jīng)驗(yàn)教訓(xùn)

在創(chuàng)建OlympicCoder模型時，研究者進(jìn)行了大量SFT實(shí)驗(yàn)，以了解用于CodeForces數(shù)據(jù)集的各種篩選條件的作用。

發(fā)現(xiàn)open-r1/codeforces-cots的以下子集表現(xiàn)最佳：

solutions：R1根據(jù)問題陳述生成的方案。
solutions_w_editorials：R1根據(jù)問題陳述和解釋正確解決方案的說明生成的方案。

請注意，這里只關(guān)注了C++解決方案，融入Python解決方案可能進(jìn)一步提高性能。

用LiveCodeBench作為模型的測試平臺，然后將表現(xiàn)最佳的checkpoints用于更具挑戰(zhàn)性的IOI基準(zhǔn)測試。

研究者測試了各種超參數(shù)配置來訓(xùn)練模型，最終確定如下：

模型：Qwen2.5 Coder Instruct 7B和32B
輪數(shù)：10
有效批大小：128
學(xué)習(xí)率：4e-5
調(diào)度器：余弦衰減至峰值學(xué)習(xí)率的10%
上下文長度：7B為32,768個token，32B為22,528個token

樣本打包會損害推理性能

樣本打包是一種在訓(xùn)練中常用的加速方法，它將訓(xùn)練樣本連接成大小相等的塊，無需填充token。

打包后，樣本可能會跨塊邊界重疊。不過，要是大部分樣本比塊小很多，這種重疊影響不大。

然而，對于從R1提取的推理軌跡，這可能會帶來負(fù)面影響。

因?yàn)楹芏嘬壽E長，答案被截?cái)嗟目赡苄愿摺＿@就導(dǎo)致訓(xùn)練時，它很難關(guān)注長上下文信息，尤其是問題和答案被分到不同塊的時候。

如下圖所示，打包會嚴(yán)重?fù)p害模型的性能。用打包時，模型幾乎解不出LiveCodebench里的題；不用打包，性能在幾個訓(xùn)練周期后趨于平穩(wěn)。

這種差異可能是由于訓(xùn)練集僅包含C++解決方案，而LiveCodeBench僅評估Python的性能。

盡管如此，在所有分析過的數(shù)據(jù)集里，打包的效果都更差。

用較大的學(xué)習(xí)率獲得最佳表現(xiàn)

在用Qwen進(jìn)行的大多數(shù)SFT實(shí)驗(yàn)中，2e-5的學(xué)習(xí)率通常足以獲得強(qiáng)大的性能。

但是，當(dāng)將帶有推理數(shù)據(jù)的SFT用于現(xiàn)有指令模型時，將學(xué)習(xí)率大幅提高到4e-5，性能會顯著提升。

如下圖所示，學(xué)習(xí)率每提高一倍，在LiveCodeBench上的得分就會提高近10分！

納入解題思路無助于提升性能

在創(chuàng)建open-r1/codeforces-cots數(shù)據(jù)集中的solutions_w_editorials子集時，原以為給R1輸入問題及解答，能獲得更好的推理軌跡。

但出人意料的是，結(jié)果并非如此。訓(xùn)練時，直接從問題描述采樣，反倒讓性能有了一定的持續(xù)提升。

用<think>預(yù)填充以持續(xù)生成長CoT

在測試模型時，發(fā)現(xiàn)個奇怪現(xiàn)象：拿領(lǐng)域內(nèi)問題（比如競技編程）提問，模型會在<think>和</think>標(biāo)簽里，輸出長長的CoT，然后給出答案。

可要是問領(lǐng)域外的問題，像「瑞士首都是哪」，模型就變回原來指令模型的回答方式了。

舉個例子，簡單問題「1+1等于幾」，模型正常回答是這樣：

用戶：1+1等于多少？

模型回答：2。這是最基礎(chǔ)的數(shù)學(xué)加法題，1+1就是 2。這題常出現(xiàn)在面試或者在線測試?yán)铮脕砜疾齑痤}人能不能快速解決問題。雖說答案大家都知道，但雇主能通過這題，看看答題人有沒有批判性思維和解決問題的能力。而且，這也是數(shù)學(xué)里復(fù)雜運(yùn)算的基礎(chǔ)。下次再有人問，你就放心答2就行！

這段代碼里，定義了add_numbers函數(shù)，輸入兩個數(shù)返回它們的和。接著用1和1調(diào)用函數(shù)，把結(jié)果存進(jìn)result，再打印出來。

但要是預(yù)先在模型回答里加上<think>，情況就不一樣了：

用戶：1+1等于多少？

模型回答：<think>好的，我要回答「1+1等于多少」這個問題。1+1等于2。不過，會不會有別的考法？或者不同進(jìn)制？十進(jìn)制里是2，二進(jìn)制就是10了。但這問題問得直接，用戶估計(jì)就想要個簡單答案，那就是2。直接說出來？</think>對，1+1等于2，你還有別的想了解的嗎？

這說明，將推理軌跡融入現(xiàn)有預(yù)訓(xùn)練模型時，得在最終模型的對話模板里，默認(rèn)強(qiáng)制加上預(yù)填充。DeepSeek處理提煉模型用的也是這招，這可能就是原因所在。

把這些經(jīng)驗(yàn)都用上，團(tuán)隊(duì)做出了OlympicCoder-7B，性能和DeepSeek的提煉模型差不多，比基礎(chǔ)的Qwen2.5-Coder強(qiáng)多了。

巧用8位優(yōu)化器，拓展長上下文大模型

訓(xùn)練OlympicCoder-7B時，研究者發(fā)現(xiàn)DeepSpeed ZeRO-3在配有8個H100的單節(jié)點(diǎn)上，訓(xùn)練32k上下文長度的模型沒問題。

可一旦把訓(xùn)練方案用于32B模型，就遇到了一系列內(nèi)存問題。尤其是上下文長度超過20k token時，哪怕用16個節(jié)點(diǎn)，也會因內(nèi)存不足而崩潰。

這可不妙，CodeForces-CoTs里20%的軌跡長度都超過20k token，意味著它們會在訓(xùn)練期間被截?cái)唷?/span>

問題的根源在于transformers和trl尚不支持上下文并行。

團(tuán)隊(duì)嘗試了各種節(jié)省內(nèi)存的辦法，發(fā)現(xiàn)將FSDP與paged_adamw_8bit優(yōu)化器結(jié)合起來，可以將上下文擴(kuò)展到 22,528個token，但仍有9%的數(shù)據(jù)被截?cái)唷?/span>

更新

最近，團(tuán)隊(duì)在改進(jìn)TRL中GRPO的實(shí)現(xiàn)方面取得了進(jìn)展，帶來了一些提升，進(jìn)一步提高了效率、可擴(kuò)展性和資源利用率。

以下是這次更新最重要的變化概要：

生成重復(fù)使用

GRPO的主要瓶頸與其他在線方法相同：生成過程需要時間。

提高GRPO樣本效率的一個關(guān)鍵方法是在優(yōu)化過程中多次重用生成的樣本，而不是在單次使用后丟棄。這一技術(shù)實(shí)際上早在PPO中就已經(jīng)引入。

對于GRPO，樣本重用的次數(shù)用μ表示。

現(xiàn)在，可以多次重用生成的樣本，從而顯著加快處理速度。

from trl import GRPOConfig

training_args = GRPOConfig(..., num_iteratinotallow=...)

不過需要注意的是，如果μ過大，可能會對學(xué)習(xí)產(chǎn)生負(fù)面影響。根據(jù)他們的經(jīng)驗(yàn)，2到4之間的值是一個較好的平衡點(diǎn)。

獎勵加權(quán)

在訓(xùn)練模型時，并非所有獎勵都同等重要。例如，可能希望模型優(yōu)先關(guān)注正確性而非格式，而不是平等對待兩者。

為了解決這個問題，現(xiàn)在可以為不同的獎勵分配不同的權(quán)重，從而更精細(xì)地控制優(yōu)化過程。通過調(diào)整這些權(quán)重，我們可以引導(dǎo)模型更加關(guān)注特定任務(wù)中最重要的方面。

下面代碼配置了一個GRPO訓(xùn)練器，通過GRPOConfig設(shè)置訓(xùn)練參數(shù)，并為兩個獎勵函數(shù)（very_important_reward 和 less_important_reward）分配了不同的權(quán)重（0.9和0.1），以控制優(yōu)化過程中不同獎勵的重要性。

from trl import GRPOConfig, GRPOTrainer

def very_important_reward(completions, **kwargs):
    ...

def less_important_reward(completions, **kwargs):
    ...

training_args = GRPOConfig(
    ...,
    reward_weights=[0.9, 0.1],
)
trainer = GRPOTrainer(
    ...,
    reward_funcs=[very_important_reward, less_important_reward],
    args=training_args,
)

其他改進(jìn)

GRPO還進(jìn)行了一些較小但影響深遠(yuǎn)的改進(jìn)：

PEFT+vLLM集成：現(xiàn)在可以將PEFT（參數(shù)高效微調(diào)）與vLLM結(jié)合使用，將高效微調(diào)與優(yōu)化的推理相結(jié)合，提升可擴(kuò)展性。
梯度檢查點(diǎn)：通過重新計(jì)算某些激活值而非存儲它們來減少訓(xùn)練過程中的內(nèi)存消耗，從而支持訓(xùn)練更大的模型。
優(yōu)化的選擇性Log Softmax計(jì)算：引入了一種新的Log Softmax計(jì)算方法，降低了訓(xùn)練期間的內(nèi)存峰值。

接下來的工作

團(tuán)隊(duì)當(dāng)前的重點(diǎn)集中在兩個關(guān)鍵領(lǐng)域：

提升生成速度：正在探索進(jìn)一步的優(yōu)化（如靜態(tài)緩存），以使生成過程更快。
將GRPO擴(kuò)展到多節(jié)點(diǎn)設(shè)置：正在努力使 GRPO 能夠在多節(jié)點(diǎn)上擴(kuò)展，從而支持訓(xùn)練更大的模型。

Open R1 Math-Dataset更新

研究團(tuán)隊(duì)還進(jìn)一步豐富了之前發(fā)布的OpenR1-Math-Raw數(shù)據(jù)集，添加了新的元數(shù)據(jù)，以在過濾和驗(yàn)證過程中支持更明智的決策。具體來說，新增了以下列：

reparsed_answers：注意到答案列中的許多條目要么LaTeX格式不正確，要么僅包含部分答案。此外，由于一些問題是多項(xiàng)選擇題，正確答案本身及其對應(yīng)的字母都應(yīng)視為有效響應(yīng)。

為此，他們使用Llama-3.3-70B-Instruct模型從解決方案列中重新提取了所有答案，確保reparsed_answers包含正確答案，并在多項(xiàng)選擇題中同時包含對應(yīng)的字母。

correctness：基于模型的答案驗(yàn)證可能需要大量資源。因此，團(tuán)隊(duì)使用Llama-3.3-70B-Instruct作為評判模型，并結(jié)合math_verify對答案列和reparsed_answers列進(jìn)行了評估。

訓(xùn)練與評估

在數(shù)據(jù)受限的過濾場景中，精確度和召回率都是重要的考慮因素。

因此，研究團(tuán)隊(duì)沒有為每個實(shí)驗(yàn)設(shè)定相同的token預(yù)算，而是對所有數(shù)據(jù)進(jìn)行了單個周期的訓(xùn)練。

他們選擇了Qwen7B-Instruct模型，并通過RoPE擴(kuò)展將其微調(diào)至32k的上下文長度，采用余弦調(diào)度。

為了跟蹤性能進(jìn)展，每隔40步在AIME-24、AIME-25和MATH-500數(shù)據(jù)集上使用lighteval評估模型。

下圖展示了在AIME-24、AIME-25和MATH-500數(shù)據(jù)集上，不同方法（包括無限制、LLaMA驗(yàn)證、math_verify等）對模型準(zhǔn)確率隨訓(xùn)練步數(shù)變化的影響。

結(jié)果顯示，驗(yàn)證顯著影響了早期性能。過濾在前40步尤為重要。

在MATH-500數(shù)據(jù)集上，較嚴(yán)格的驗(yàn)證方法在早期階段顯著提升了性能（例如，no_restrictions得分為 0.61，而LandMV 為0.72）。然而，隨著訓(xùn)練的進(jìn)行，這種性能差距逐漸縮小，擁有更多樣本（即使其中包含錯誤）變得更有利。

使用math_verify過濾的數(shù)據(jù)集始終表現(xiàn)出較低的訓(xùn)練損失。

研究團(tuán)隊(duì)推測math_verify能有效識別特定任務(wù)子集（主要是數(shù)值型任務(wù)），而基于Llama的驗(yàn)證或未過濾的數(shù)據(jù)集則保持了更廣泛的數(shù)據(jù)多樣性。

不僅如此，還有個意外發(fā)現(xiàn)，未過濾數(shù)據(jù)集并未嚴(yán)重退化。盡管包含錯誤樣本，no_restrictions數(shù)據(jù)集在長時間訓(xùn)練中仍保持了競爭力。