OpenAI o1/o3-mini級的推理模型，竟被搶先開源了？

剛剛，來自UC伯克利和Together AI的聯(lián)合團(tuán)隊，重磅推出了一款完全開源的代碼推理模型——DeepCoder-14B-Preview。

現(xiàn)在，只需要14B就可以擁有一個媲美o3-mini的本地模型，并且完全免費(fèi)！

DeepCoder-14B-Preview通過分布式RL從Deepseek-R1-Distilled-Qwen-14B微調(diào)得來。

在LiveCodeBench基準(zhǔn)測試中，它的單次通過率（Pass@1）達(dá)到了60.6%，提升幅度高達(dá)8%。

至此，又見證了強(qiáng)化學(xué)習(xí)的勝利。

DeepCoder在訓(xùn)練過程中的LiveCodeBench (LCB) 得分：訓(xùn)練到第180步的時候，上下文長度擴(kuò)展到了32K；用32K時最佳的檢查點來做推理，并且把上下文擴(kuò)展到64K，這時LCB得分能達(dá)到60.6%，和o3-mini性能相當(dāng)

同時，團(tuán)隊還開源了verl-pipe，這是verl后訓(xùn)練系統(tǒng)的擴(kuò)展，集成了多項系統(tǒng)優(yōu)化，能讓端到端的訓(xùn)練速度提高2倍。

對此網(wǎng)友們稱贊：這是完全開源的勝利，不僅僅是模型，數(shù)據(jù)集、代碼、訓(xùn)練日志也開放。

值得一提的是，DeepCoder-14B-Preview基于24K個可驗證的編程問題，在32個H100 GPU上訓(xùn)練了2.5周。

數(shù)據(jù)集構(gòu)建

數(shù)學(xué)領(lǐng)域的研究發(fā)現(xiàn)，強(qiáng)化學(xué)習(xí)要是有可驗證的獎勵機(jī)制，能顯著提升模型的推理能力。

在數(shù)學(xué)領(lǐng)域，網(wǎng)上能找到好多高質(zhì)量、可驗證的數(shù)據(jù)，編程則相對稀缺。

在早期實驗中，團(tuán)隊評估了幾個常見的代碼數(shù)據(jù)集，像APPS、TACO、CodeContests、KodCode和LeetCode。

結(jié)果發(fā)現(xiàn)，有些數(shù)據(jù)集對模型來說太簡單了，如KodCode和LeetCode；還有些數(shù)據(jù)集有噪聲，或者里面的測試用例有缺陷、不完整，不可驗證。這會給出錯誤的獎勵信號，讓RL訓(xùn)練無法穩(wěn)定進(jìn)行。

為解決這些問題，研究者整理出一個高質(zhì)量的訓(xùn)練集，包括：

• TACO里已驗證過的問題。
• PrimeIntellect的SYNTHETIC-1數(shù)據(jù)集中經(jīng)驗證的問題。
• 2023年5月1日到2024年7月31日提交的LiveCodeBench問題。

為保證數(shù)據(jù)質(zhì)量，讓RL訓(xùn)練能順利開展，有一套嚴(yán)格的過濾流程：

• 程序化驗證：每個問題都會用外部官方的解法自動檢查一遍，只保留官方解法能通過所有單元測試的問題，檢查過程在tests/rewards/test_code_batch.py腳本中自動完成。
• 測試過濾：每個問題至少包含5個單元測試。測試用例少的問題容易讓模型鉆空子，模型通過識別常見測試用例，學(xué)會簡單地輸出記憶的答案，即「獎勵黑客」。
• 去重：研究者會把數(shù)據(jù)集中重復(fù)的問題都去掉，防止互相干擾。他們對Taco Verified、PrimeIntellect SYNTHETIC-1和LCB（2023年5月1日-2024年7月31日）這三個訓(xùn)練數(shù)據(jù)集做了去重處理，還檢查了測試數(shù)據(jù)集LCB（2024年8月1日-2025年2月1日）和Codeforces的57個競賽數(shù)據(jù)集。

過濾后，得到24K個高質(zhì)量的編程問題，用于RL訓(xùn)練，其中7.5K個來自TACO Verified，16K個來自PrimeIntellect SYNTHETIC-1，600個來自LiveCodeBench。

代碼沙盒環(huán)境

為了計算代碼RL訓(xùn)練的獎勵，得在代碼沙盒里，對模型生成的代碼進(jìn)行單元測試。

每個RL迭代過程，用1024個問題來評估訓(xùn)練效果，每個問題至少有5個單元測試。

這么多測試任務(wù)，就得靠100多個代碼沙盒一起并行運(yùn)行，才能在合理的時間內(nèi)，準(zhǔn)確驗證模型生成的代碼。

目前，研究者用了兩種沙盒：Together代碼解釋器和本地代碼沙盒。

Together代碼解釋器

這個環(huán)境速度快、效率高，能直接用在RL訓(xùn)練上，每個問題的成本僅3美分。

Together代碼解釋器已支持100多個沙盒同時運(yùn)行，每分鐘能執(zhí)行1000多次沙盒操作。

這些沙盒能訪問標(biāo)準(zhǔn)輸出（stdout）、標(biāo)準(zhǔn)輸入（stdin），還能評估代碼最后一行輸出的結(jié)果。

同時，它能把代碼運(yùn)行的環(huán)境和主機(jī)系統(tǒng)隔離開，保證安全。

本地代碼沙盒

本地代碼沙盒是通過啟動一個獨立的、有防護(hù)的Python子進(jìn)程來運(yùn)行的。它從標(biāo)準(zhǔn)輸入（stdin）接收測試用例的輸入，然后把答案輸出到標(biāo)準(zhǔn)輸入（stdout）。

本地沙盒用的是LiveCodeBench官方代碼庫里的評估代碼，確保測試結(jié)果和現(xiàn)有排行榜一致。

獎勵函數(shù)

有些獎勵方式容易讓模型作弊，比如給思維鏈（CoT）懲罰，或者N個測試中有K個通過就給K/N獎勵。

獎勵函數(shù)采用稀疏結(jié)果獎勵模型（ORM），具體獎勵規(guī)則是這樣的：

• 獎勵為「1」：生成的代碼必須通過所有抽選的單元測試。有些問題有幾百個測試用例，全部驗證不太現(xiàn)實，所以會根據(jù)輸入字符串的長度，每個問題挑出15個最難的測試（根據(jù)輸入字符串的長度來判斷）。
• 獎勵為「0」：要是模型生成的代碼有一個測試用例沒通過，或者答案格式不對（比如缺少python[CODE]標(biāo)記），就沒有獎勵。每個測試用例都有6-12秒的時間限制。

訓(xùn)練方法

GRPO+

研究者參考了DAPO的關(guān)鍵思路，改進(jìn)了GRPO算法，讓訓(xùn)練過程更穩(wěn)定：

GRPO+和GRPO在16K上下文訓(xùn)練中的平均訓(xùn)練獎勵：GRPO的獎勵曲線最后會崩潰，GRPO+因為有Clip High機(jī)制，獎勵曲線保持穩(wěn)定

• 無熵損失：加上熵?fù)p失項，很容易讓訓(xùn)練不穩(wěn)定，熵值指數(shù)級增長，導(dǎo)致訓(xùn)練崩潰。因此移除了熵?fù)p失項。
• 無KL損失（源自DAPO）：去掉KL散度損失，LLM就不會被限制在原來監(jiān)督微調(diào)（SFT）模型的置信區(qū)域內(nèi)。還能省掉為參考策略計算對數(shù)概率，訓(xùn)練速度也就更快了。
• 超長過濾（源自DAPO）：為保留長上下文推理能力，對超出長度而被截斷的序列做了特殊處理。這項技術(shù)使DeepCoder即使在32K上下文環(huán)境中訓(xùn)練，在64K上下文下也能推理。這種過濾方法允許響應(yīng)長度自然增長，而不會因截斷而受到懲罰。

由于采用超長過濾機(jī)制，GRPO+的響應(yīng)長度隨訓(xùn)練時間穩(wěn)步增長

• Clip High（源自DAPO）：通過提高GRPO/PPO代理損失的上限，鼓勵模型嘗試更多不同的可能，熵值也更穩(wěn)定。這樣調(diào)整后，訓(xùn)練更穩(wěn)定，模型性能也有提升。

Clip High機(jī)制和沒有熵?fù)p失，能保證GRPO+的token級熵不會崩潰，鼓勵模型充分探索

迭代式上下文擴(kuò)展

在DeepScaleR的介紹中，提到過迭代式上下文擴(kuò)展技術(shù)。它能讓模型先在短一點的上下文里學(xué)會有效思考，然后再應(yīng)用到更長的上下文。

這個方法曾讓1.5B參數(shù)模型的下游任務(wù)性能穩(wěn)步提升，隨著上下文窗口從8K擴(kuò)大到16K，再到24K的過程中，在AIME測試?yán)锏臏?zhǔn)確率從33%提高到38%，最后到了43%，最終達(dá)到了o1-preview的水平。

不過，將這個技術(shù)用在14B參數(shù)模型的時候，遇到了新問題：

• 14B參數(shù)模型本身推理能力就很強(qiáng)，想要再提升，就得解決更難的問題。
• 這些更難的問題往往需要比8K更長的上下文窗口，而8K是之前小模型訓(xùn)練的起始上下文長度。

如果一開始用短上下文訓(xùn)練，模型輸出超出這個長度就懲罰它，這樣做效果不好。模型的初始性能會下降，輸出的內(nèi)容也會變短，長上下文的推理能力也會變?nèi)酢?/span>

為了在保證訓(xùn)練效率的同時，讓模型能處理長上下文推理，研究者引入了DAPO的超長過濾技術(shù)。在訓(xùn)練的時候，會忽略那些因為太長被截斷的序列，這樣模型就算生成的內(nèi)容長一點，也不會被懲罰。

因此，模型即使在較短的上下文中訓(xùn)練，也能「想得長遠(yuǎn)」。

研究者把迭代上下文擴(kuò)展用在DeepCoder-14B-Preview上，把訓(xùn)練的上下文窗口從16K擴(kuò)大到32K，LiveCodeBench基準(zhǔn)測試中，模型表現(xiàn)如下：

• 在16K和32K上下文長度下，準(zhǔn)確率從54%提升至58%。
• 在64K上下文長度評估時，達(dá)到了60.6%。

這說明模型的泛化能力很強(qiáng)，超出了訓(xùn)練時的上下文范圍也能表現(xiàn)得很好。

和DeepSeek-R1-Distill-Qwen-14B這種基礎(chǔ)蒸餾模型比起來，DeepCoder-14B-Preview的泛化能力就更突出了。

基礎(chǔ)蒸餾模型一旦超出訓(xùn)練時的上下文長度，性能就很難提升了。

雖然DeepCoder因為平均響應(yīng)長度較長，在16K上下文長度下的原始性能低一些，會因為截斷和格式問題扣分，但它在長上下文的推理能力很強(qiáng)，最終在64K上下文長度的評估中超越了其他模型。

DeepCoder在訓(xùn)練過程中的平均響應(yīng)長度和訓(xùn)練獎勵：平均響應(yīng)長度從8K增長到17.5K

DeepCoder的成功，正是把迭代上下文擴(kuò)展和超長過濾技術(shù)結(jié)合起來了。

從圖中可以看到，在訓(xùn)練過程中，模型的平均響應(yīng)長度從8K增長到17.5K，平均獎勵也從0.6提高到 0.7。說明隨著時間推移，模型學(xué)會了更厲害、更有條理的思考方式。

關(guān)鍵技術(shù)改進(jìn)

在多種編程基準(zhǔn)上對 Deepcoder-14B-Preview 進(jìn)行了評估，包括LiveCodeBench (LCB)、Codeforces、HumanEval+以及AIME2024數(shù)學(xué)競賽。

憑借14B的參數(shù)量，模型在所有編程基準(zhǔn)上均展現(xiàn)出強(qiáng)勁性能：在LiveCodeBench上實現(xiàn)了60.6%的Pass@1準(zhǔn)確率，在Codeforces上獲得了1936的評分，其表現(xiàn)可與o3-mini (low) 和o1模型相媲美。

訓(xùn)練耗時太長？系統(tǒng)優(yōu)化來幫忙

使用長上下文對LLM進(jìn)行強(qiáng)化學(xué)習(xí)（RL）訓(xùn)練非常耗時，需要在長上下文環(huán)境中反復(fù)進(jìn)行采樣和訓(xùn)練。

若無系統(tǒng)層面的優(yōu)化，完整的訓(xùn)練流程可能耗費(fèi)數(shù)周乃至數(shù)月。14B參數(shù)編程模型訓(xùn)練，每一步就得花1200至2500秒，總訓(xùn)練時長達(dá)到2.5周！

團(tuán)隊引入并開源了verl-pipeline。它是開源RLHF庫verl的一個優(yōu)化版本，用了多項系統(tǒng)級改進(jìn)措施，旨在加速端到端的RL訓(xùn)練過程。

相較于基準(zhǔn)的verl實現(xiàn)，verl-pipeline實現(xiàn)了高達(dá)2.5倍的速度提升。

運(yùn)用這些新的系統(tǒng)優(yōu)化來訓(xùn)練DeepCoder-1.5B-Preview模型，該模型在LiveCodeBench上的準(zhǔn)確率達(dá)到了25%，相比Deepseek-R1-Distill-Qwen-1.5B提升了8%。

采樣器是瓶頸

在后訓(xùn)練中，采樣往往是拖慢整體進(jìn)度的關(guān)鍵因素。這是因為用vLLM和SGLang這類推理引擎生成32K token的長序列時，會產(chǎn)生延遲。

Verl的PPO/GRPO訓(xùn)練流程：每次RL迭代都包含采樣、獎勵函數(shù)計算和訓(xùn)練這三個階段；其中，采樣是整個訓(xùn)練流程的瓶頸，訓(xùn)練速度受限于那些生成較長序列的掉隊采樣器（straggler samplers）

RL訓(xùn)練系統(tǒng)通常受限于采樣時間——上圖展示了Verl的PPO/GRPO流水線，其中響應(yīng)長度的不一致性導(dǎo)致部分采樣器成為掉隊者。

這些掉隊者會拖慢訓(xùn)練進(jìn)度，而先完成任務(wù)的采樣器則處于空閑狀態(tài)，從而導(dǎo)致GPU利用率低下。

樸素解決方案：小批流水線化

為了減少RL訓(xùn)練過程中的空閑時間，研究者將采樣和訓(xùn)練過程流水線化（Minibatch Pipelining）。

如此一來，訓(xùn)練器在采樣器繼續(xù)生成后續(xù)數(shù)據(jù)批次的同時，就會開始利用較早到達(dá)的小批數(shù)據(jù)進(jìn)行模型更新。這種重疊執(zhí)行有助于減少采樣帶來的延遲。

小批流水線：采樣器和訓(xùn)練器分別在不同的工作機(jī)組中運(yùn)行；當(dāng)完成采樣并釋放小批量數(shù)據(jù)（用于PPO/GRPO訓(xùn)練）后，訓(xùn)練器會異步處理這些數(shù)據(jù)；在一次迭代結(jié)束時，訓(xùn)練器會將更新后的權(quán)重給采樣器

然而，這種方法存在三個關(guān)鍵的局限性：

1. 小批數(shù)據(jù)的平均序列長度往往隨訓(xùn)練進(jìn)展而增長，這增加了處理后續(xù)小批的訓(xùn)練時間。結(jié)果就是，最后幾個小批數(shù)據(jù)常常在采樣階段結(jié)束后才能處理完畢，從而限制了流水線化帶來的實際效益。
2. 流水線化需要在采樣器和訓(xùn)練器之間靜態(tài)劃分GPU資源，這減少了可用采樣器的數(shù)量。不同于Verl可以在同一個GPU池中動態(tài)地切換采樣器和訓(xùn)練器角色，這種靜態(tài)劃分因采樣器數(shù)量減少，可能反而會延長端到端的總采樣時間。
3. 獎勵函數(shù)的計算可能耗時很長，特別是對于編程類任務(wù)，每個RL迭代都需要運(yùn)行數(shù)千個單元測試。在Verl的默認(rèn)設(shè)置中，獎勵計算是在所有采樣任務(wù)完成后，在頭節(jié)點（head node）上集中進(jìn)行的。

盡管存在這些約束，團(tuán)隊在代碼庫的ray_trainer_pipeline.py文件中實現(xiàn)了小批流水線化，并且需要指出的是，這種流水線技術(shù)可以通過引入微批處理（microbatching）來進(jìn)一步優(yōu)化。

DeepCoder的解決方案：一次性流水線化

為實現(xiàn)訓(xùn)練、獎勵計算和采樣的完全流水線化，研究者引入了一次性流水線化（One-Off Pipelining）。

一次性流水線：采樣器會提前一個迭代周期生成一批數(shù)據(jù)，而訓(xùn)練器則使用上一次迭代的數(shù)據(jù)來更新梯度；此外，獎勵函數(shù)的計算與采樣過程是交錯進(jìn)行的；這種方法不會為GRPO/PPO的策略算法引入異步離策略樣本

其思路非常簡單：犧牲第一個RL迭代，僅執(zhí)行采樣任務(wù)，然后利用這個采樣得到的數(shù)據(jù)批次在下一個迭代中進(jìn)行訓(xùn)練。

這樣一來，采樣和訓(xùn)練就能并行處理，徹底消除了采樣完成后訓(xùn)練器的等待空閑時間。

其次，獎勵計算被嵌入到采樣流程中，與之交錯執(zhí)行。

一旦某個采樣請求完成，其對應(yīng)的獎勵會立即被計算出來——這有效減少了獎勵評估環(huán)節(jié)的開銷，特別是對于計算密集型任務(wù)（例如編程任務(wù)中的測試用例執(zhí)行）而言效果顯著。

團(tuán)隊在代碼庫verl分支（fork）中的ray_trainer_async.py文件里實現(xiàn)了一次性流水線化。

端到端性能

一次性流水線完全掩蓋了訓(xùn)練器和獎勵計算的時間，數(shù)學(xué)任務(wù)訓(xùn)練時間縮短1.4倍，編程任務(wù)縮短2倍

上圖展示了對verl、小批流水線化和一次性流水線化在兩種工作負(fù)載（數(shù)學(xué)和編程）下的評估結(jié)果。

為確保公平性，所有基準(zhǔn)方法都利用Python線程池并行計算獎勵；而verl官方實現(xiàn)是串行計算每個樣本的獎勵，這種方式對于編程任務(wù)來說耗時過長，難以實際應(yīng)用。

在8塊A100 GPU上對Deepcoder-1.5B-Preview進(jìn)行了評估，并細(xì)致調(diào)整了采樣器與訓(xùn)練器的資源配比，旨在更好地平衡兩者所需的時間開銷。

• 對于數(shù)學(xué)任務(wù)：一次性流水線化將每次RL迭代所需時間縮短了1.4倍。值得注意的是，數(shù)學(xué)任務(wù)的獎勵計算時間幾乎為零，因為它僅涉及基礎(chǔ)的Sympy檢查。特別之處在于，一次性流水線化能夠完全掩蓋（mask away）訓(xùn)練器所需的時間，這與小批流水線化中最后一個小批會「溢出」（spill over）導(dǎo)致延遲的情況形成了對比。
• 對于編程任務(wù)：計算獎勵需要在每次RL迭代中運(yùn)行數(shù)千個單元測試，這是一個非常耗時的過程。一次性流水線化能夠同時掩蓋訓(xùn)練器時間和獎勵計算時間，從而將端到端的訓(xùn)練總時長縮短了2倍。

最關(guān)鍵的是，一次性流水線化不僅切實有效，而且能成功擴(kuò)展應(yīng)用于復(fù)雜的編程任務(wù)。

DeepCoder使用ray_trainer_async.py（采用一次性流水線化）訓(xùn)練了DeepCoder-1.5B-Preview，其在 LiveCodeBench (LCB) 上的得分相較于基礎(chǔ)的蒸餾模型提升了8%。

作者介紹

Sijun Tan（譚嗣俊）

譚嗣俊是UC伯克利計算機(jī)科學(xué)專業(yè)的三年級博士生，導(dǎo)師是Raluca Ada Popa。隸屬于伯克利的Sky Computing Lab。

此前，他在弗吉尼亞大學(xué)獲得計算機(jī)科學(xué)和數(shù)學(xué)雙學(xué)士學(xué)位，導(dǎo)師是David Wu和Yuan Tian。

他曾在Facebook AI Research（FAIR）實習(xí)過一段時間，并在螞蟻集團(tuán)擔(dān)任過高級算法工程師。

他的研究領(lǐng)域涵蓋機(jī)器學(xué)習(xí)、計算機(jī)安全和應(yīng)用密碼學(xué)。目前，其研究重點是增強(qiáng)通用型AI智能體的能力和魯棒性。

Michael Luo

Michael Luo目前是UC伯克利電氣工程與計算機(jī)科學(xué)系（EECS）的博士生，導(dǎo)師是Ion Stoica教授。

在此之前，他獲得了UC伯克利電氣工程與計算機(jī)科學(xué)碩士和工商管理雙學(xué)士學(xué)位。

他的研究興趣主要在人工智能和系統(tǒng)領(lǐng)域。目前，其研究主要是為機(jī)器學(xué)習(xí)從業(yè)者構(gòu)建可擴(kuò)展的系統(tǒng)，以實現(xiàn)Sky Computing的愿景。

Roy Huang

Roy Huang目前是UC伯克利計算機(jī)科學(xué)專業(yè)的大四學(xué)生，對CV和NLP領(lǐng)域的研究感興趣。