這項由Meta AI基礎人工智慧研究部門（FAIR at Meta）和法國國家資訊與自動化研究所（Inria）以及巴黎多菲納大學聯合開展的研究，以預印本形式於2026年7月28日發布，論文編號為arXiv:2607.25970。有興趣深入了解的讀者可以通過這一編號在arXiv平台查閱完整論文。
**代碼能寫對，但能寫快嗎？**
一個AI能寫出能運行的程序，這本身已經讓很多人印象深刻。但現實世界裡，"能跑"和"跑得快"之間，往往有著天壤之別。一段處理百萬用戶請求的代碼，慢上十倍就意味著伺服器成本翻十倍，用戶體驗變成災難。然而，目前幾乎所有訓練AI寫代碼的方法，都只關心"寫對了沒有"，完全不在意速度快慢。
這就是這項研究要正面回答的問題：能不能通過強化學習，讓AI不只寫出正確的程序，還能寫出快速的程序？
這個問題聽起來直接，實際上卻暗藏重重陷阱。研究團隊在探索過程中發現，只要把"運行時間"塞進獎勵信號，整個訓練就會崩掉——生成的程序要麼沒有變快，要麼開始變得不正確。這套研究工作的核心貢獻，正是系統性地找出了為什麼會崩、每一個環節該怎麼修，並最終讓AI在代碼優化這件事上取得了真正顯著的進步。
---
一、為什麼"讓AI寫快代碼"這麼難
先用一個貼近生活的比喻來理解這件事的難度。設想你是一位廚師，老闆原本只要求你做出"能吃的菜"，現在他突然說："還得做得快。"你原來的考核方式是顧客吃完以後給個好評或負評，現在老闆要在這個基礎上再加一個"出菜速度"的評分。
問題立刻就來了：廚房裡有噪音——有時計時器不准，有時爐子火力不穩，同一道菜在不同時間量出來的時間可能差好幾分鐘。如果老闆用這個不穩定的計時來評分，你根本搞不清楚自己是真的變快了，還是今天爐子比昨天旺。更糟的是，有時候你可以耍個小聰明：把菜做得半生不熟——表面看起來快，但其實不合格。如果老闆的評分系統對這種情況不敏感，你可能就會朝著"快但不熟"的方向越走越偏。
AI訓練代碼也面臨著完全相同的困境。電腦程序的運行時間充滿了"噪聲"，即便是同一段代碼在同一台機器上跑兩遍，時間也可能差出幾十毫秒。更要命的是，如果訓練時獎勵"運行快的代碼"，AI可能學會寫出"運行快但答案錯了"的代碼——速度獎勵到手了，正確性卻丟了。這篇論文把這個問題歸結為三個相互咬合的環節：測試數據要能區分快慢、獎勵信號要正確地把速度和正確性結合起來、訓練算法本身要在這種稀疏和嘈雜的信號下保持穩定。任何一個環節出了問題，整個系統就會失效。
---
二、打地基：構建一個能測速度的數據集
要教AI寫快代碼，首先得有一套能準確衡量"快不快"的測試題。但研究團隊發現，他們手頭現有的數據集——來自DeepMind Code Contests（DMC）的約12,275道競賽編程題——根本不適合做這件事。
原因在於，這些題目原本附帶的測試用例太小、太快。絕大多數測試輸入只有十幾二十個字符，運行一次只需要不到一百毫秒。在這個速度量級上，作業系統的調度延遲、內存分配的隨機波動，就已經能讓同一段代碼的運行時間抖動出幾十毫秒的誤差——噪聲和信號幾乎一樣大，根本無法分辨代碼究竟是快還是慢。
研究團隊用一個形象的方式呈現了這個問題：如果你用一把精度只有半米的捲尺去量一個人的身高，量出來的結果毫無意義。要讓測量有意義，測試用例本身就必須足夠"重"，讓不同質量的程序在運行時間上產生可以被可靠識別的差異。
為了解決這個問題，他們系統性地重建了測試集。首先，他們把12,275道題目重新執行，核驗每道題的答案是否真的正確，把那些標註有誤的題目過濾掉。然後，他們用AI模型為剩餘的3,928道題目各自生成了10個"輸入生成器"——這是一種能自動產生符合題目要求的輸入數據的小程序。每個生成器產生15個候選測試用例，只有當多個人類標準答案對同一輸入給出相同輸出時，這個測試用例才被認可。這一輪篩選產生了43萬多個新的"正確性測試"，專門用來判斷程序答案對不對。
與此同時，他們還額外生成了35萬多個"優化測試"，這些測試的輸入規模被刻意設計得非常大，足以讓慢速程序耗費數秒才能完成，而快速程序只需零點幾秒。這就像是給運動員設計了一條真正有難度的跑道，而不是讓他們在原地踏步然後宣布誰跑得快。
經過層層篩選，最終有1,302道題目達到了"時間可分辨"的標準——在這些題目上，不同質量的正確程序之間存在足夠明顯的運行時間差異，可以用來訓練和評估AI的優化能力。這1,302道題被分成1,000道訓練題和302道測試題，構成了這項研究的核心數據集，研究團隊將其命名為DMC-Optim。
---
三、測量本身是個技術活：為什麼本地計時不可用
數據集有了，但測量工具同樣關鍵。這裡有一個讓人有點意外的發現：研究團隊最初嘗試在訓練機器上直接運行代碼來計時，結果發現這條路完全走不通。
想像一下，你在一個嘈雜的菜市場裡試圖用手機麥克風錄製一段小提琴演奏。背景噪聲實在太大，音樂信號完全被淹沒了。訓練機器上同時跑著AI模型推理、數據加載、多GPU通信……這些工作本身就會占用大量CPU時間。在這種環境下量出來的程序運行時間，誤差大得驚人。實驗結果顯示，同一段代碼在同一台機器上反覆運行，其"排名"（與人類參考答案相比的速度百分位）會來回抖動41個百分位點——等於說今天它看起來比80%的人類答案都快，明天又變成只比30%的人類答案快，代碼本身根本沒變。
研究團隊為此專門使用了一套獨立的遠程代碼執行服務（他們稱之為CES），這套服務在獨立的CPU集群上運行每一段代碼，每次執行都在隔離的沙箱環境中進行，最大程度排除了外部干擾。在這套系統上，同一段代碼反覆運行的排名波動只剩下2個百分位點左右——小到可以接受的程度。
但即便用了這套精確的服務，還有一個更隱蔽的問題：數據集裡儲存的人類參考答案運行時間，是在幾個月前某個時間點測量的，而AI生成的代碼是在今天測量的。這兩次測量之間，伺服器的硬體配置、系統軟體版本可能已經發生了變化，導致今天測出來的1秒和幾個月前測出來的1秒並不完全可比。研究團隊通過採集33道題目上超過1,369萬個測量數據點，發現了一個系統性的漂移：舊時間數據需要按照一個線性校正公式（新時間 ≈ 0.63 × 舊時間 + 0.053秒）來換算，才能和今天的測量結果對齊。將這個校正應用到參考數據後，排名一致性從0.54的Spearman相關性提升到了0.96，基本消除了跨時間比較的偏差。
---
四、設計獎勵：如何告訴AI"你寫的代碼夠快了嗎"
有了可靠的測量工具和數據集，下一步是設計一套把"速度測量結果"轉換成"訓練信號"的機制。這個設計空間極其龐大，稍有不慎就會出問題。
研究團隊把所有可能的設計方案按照"優化約束在哪個環節進入訓練流程"分成了三大類。
第一類叫做"執行前過濾"——在代碼跑之前，先篩選測試用例。比如，只選擇那些平均運行時間低於某個閾值的測試用例（絕對時間過濾），或者只選擇輸入輸出字符數低於某個上限的測試（字符長度過濾），或者只保留最快的那部分測試（相對時間過濾）。這樣做的好處是不需要過於精確的速度測量，降低了對測量噪聲的敏感度；缺點是優化壓力可能不夠直接。
第二類叫做"執行中限制"——在代碼運行過程中設置時間限制。比如，給每個測試用例設置一個絕對的時間上限（超過就算超時），或者把時間上限設成人類參考答案的某個百分位（比如最好30%的人類解法的用時上限）。這類方案直接強制要求代碼足夠快，壓力很明確，但設置不當會讓絕大多數代碼都超時，導致AI根本拿不到獎勵、無從學習。
第三類叫做"執行後排名"——讓代碼跑完以後，把它和人類參考答案比一比，看它排在什麼位置。比如，計算AI代碼在每個測試上的速度排名，取平均值，看它是否落在前30%或前50%之內。這類方案最為靈活，同一次執行的數據可以在不同排名門檻下反覆使用，但需要有可靠的人類參考答案庫。
為了在正式訓練之前就能排除那些明顯不好用的方案，研究團隊構建了一個"離線模擬器"。這個模擬器用真實的人類解法來代替AI生成的代碼，用預先儲存的運行時間來代替實時測量，然後觀察：當模擬的代碼質量從差到好逐漸提升時，獎勵信號是否也穩定地從低到高變化？如果變化太平穩（說明獎勵對代碼質量不敏感），或者變化只集中在極端情況（說明大多數時候拿不到有效信號），這個方案就會被排除。通過這個廉價的預篩選，他們節省了大量實際訓練所需的GPU計算資源。
在正式的獎勵信號設計上，研究團隊還測試了多種把"正確性"和"速度"結合起來的方式。有些方案對錯誤代碼和慢速正確代碼分別給出不同程度的負獎勵，讓AI學會區分；有些方案用加權求和把兩個目標混在一起；有些方案完全把速度和正確性分成兩個獨立目標輪流訓練。實驗結果顯示，最好用的是一種叫做"摺疊二值獎勵"的方案——要麼代碼既正確又夠快，得到正獎勵；要麼得到負獎勵，兩種情況之間沒有中間灰色地帶。這個發現和DeepSeek-R1等研究的結論一脈相承：簡單清晰的二值信號往往比複雜的連續信號更有利於訓練穩定。
---
五、強化學習算法的適配：讓訓練在稀疏嘈雜的信號下不崩潰
設計好獎勵方案還不夠，強化學習算法本身也需要針對這個特殊場景做調整。這裡用到的核心算法叫做GRPO（Group Relative Policy Optimization，分組相對策略優化），它的基本思路是：對同一道題生成一批不同的答案，然後比較這批答案的好壞，讓AI朝著好的方向調整。
但在代碼優化場景下，這套機制會遇到一個棘手的問題：速度獎勵的信號比純正確性獎勵稀疏得多。對於很多難題，AI生成的16個答案可能一個都跑不過30%的人類參考，這16個答案拿到的獎勵都是負的。當整批答案的獎勵一模一樣時，GRPO就無法計算"這批答案中誰更好"，這一批數據就只能被丟棄，什麼也沒學到。在實驗中，這種"全是負獎勵，無法更新"的情況在訓練開始時高達40%至50%的批次。
為了應對這個問題，研究團隊做了幾項重要調整。他們增加了對同一道題生成的答案數量，從而降低"所有答案都一樣糟"的概率，讓訓練能更頻繁地從有差異的答案中獲得信號。他們還增大了訓練批次，讓梯度估計更穩定——在噪聲大的場景下，批次越小越容易受到偶然波動的干擾，就像用十個數據點估計平均值比用一千個數據點估計的可靠性差很多。
在計算獎勵基準線時，他們採用了"按token加權的均值"而不是簡單平均，確保長答案和短答案對訓練信號的貢獻是公平的。他們還用一個固定的"token預算"（32768個token）來歸一化損失，而不是用每個答案的實際長度——這樣可以防止訓練過度偏袒簡短的答案或過度懲罰長而複雜的推理過程。
此外，他們還實施了一個"新鮮度過濾"機制：如果某批答案是在30個優化步驟之前收集的，就直接丟棄不用。這是因為在那段時間裡，模型參數可能已經更新了，或者代碼執行服務的狀態可能發生了變化，導致舊的獎勵信號不再反映當前模型的真實水平。使用過時的獎勵就像用幾個月前的導航地圖走今天的路，可能會把AI引向錯誤的方向。
---
六、實驗結果：AI究竟學會了多少優化技巧
經過上述所有設置，研究團隊在三個不同規模和起點的模型上進行了實驗：70億參數的Qwen 2.5 7B、320億參數的Qwen 2.5 32B，以及320億參數的CWM 32B（後者是Meta AI自己發布的一個已經過代碼推理微調的模型）。
評估方式同樣經過精心設計。研究團隊引入了一個叫做"pτ pass@1"的評估指標，其中τ表示百分位門檻。具體來說，p100表示"只要代碼正確就算通過"，等價於傳統的正確性評估；p50要求代碼正確且速度排在人類參考答案中前50%；p30要求前30%；以此類推，τ越小要求越嚴格。這套指標能清晰地區分"AI只是學會了寫對代碼"和"AI真的學會了寫快代碼"。
結果是鮮明的。在p50（前50%速度門檻）上，Qwen 2.5 7B的得分從18.0%提升到了31.3%，提升幅度約74%；Qwen 2.5 32B從21.1%提升到39.6%，提升約88%；CWM 32B從30.7%提升到50.4%，提升約64%。在更嚴格的p30門檻下，提升幅度更為顯著：CWM 32B從13.7%一路升到30.9%，相對提升達到125%。與此同時，所有模型的p100分數（純正確性）基本保持不變甚至略有提升，說明速度的提升並沒有以犧牲正確性為代價。
在另一個公開基準測試LiveCodeBench（LCB）上，研究團隊採用了速度勝率（win rate）這個更穩健的評估方式，因為LCB的測試用例太小，絕對時間比較意義不大。結果同樣令人印象深刻：經過優化訓練的CWM 32B，在和標準正確性訓練的基線模型的配對速度比較中，勝率高達83%——也就是說，從兩個模型各自隨機生成20個答案，取中位速度者相互比較，優化訓練的模型有83%的概率更快。
研究團隊還通過一項"盲審"分析深入探究了AI到底學到了什麼。他們讓一個大型語言模型（GPT-OSS 120B）對比AI優化版和基線版的代碼，判斷兩者的速度差異來自哪類改進。結果顯示，約47%的速度優勢來自更快的輸入輸出處理（比如用更高效的方式讀取數據），34%來自常數因子優化
（比如減少不必要的中間計算），另有6%來自算法層面的改進，6%來自數學捷徑，2%來自數據結構的替換，1%來自完全不同的算法思路。這意味著AI的優化不只是耍小聰明，而是在一定程度上掌握了真正有意義的代碼改進技巧。
---
七、與人類頂尖程序員的差距還有多遠
當然，AI並沒有完全超越人類。研究團隊把優化訓練後的AI和數據集中記錄的最快人類提交方案做了對比，發現人類在67%的情況下仍然更快。但另一個角度同樣值得關註：AI在33%的情況下已經比人類的最快解法更快了，這並不是一個微不足道的數字。
更有意義的參照是"複雜度改進率"這個指標——當一個解法不只是常數倍地更快，而是從根本上降低了算法複雜度時（比如從O(n?)變成O(n)，這就像把一個需要走遍城市每條街才能找到目的地的導航換成了直接算出最短路徑），這才是真正的算法突破。在這個維度上，人類的最快解法在28%的情況下實現了複雜度改進，而優化訓練的AI在14%的情況下也做到了這一點——大約是人類水平的一半。
這個對比揭示了當前AI優化能力的輪廓：AI已經相當擅長IO優化和常數因子調整，但在發現真正的算法洞察方面，還遠不如頂尖人類程序員。研究團隊認為，現有的獎勵信號只告訴AI代碼快了多少，卻不告訴AI為什麼快，也不區分"快了一點"和"換了個根本思路變快"——如果未來能設計出算法感知型的獎勵，或者引入價值模型來引導AI更多地探索算法層面的改進，效果有望進一步提升。
---
八、這項研究意味著什麼
歸根結底，這項研究回答了一個很多人可能覺得理所當然但其實非常困難的問題：能不能通過強化學習，在不犧牲代碼正確性的前提下，讓AI寫出更快的程序？答案是可以，但需要在測試數據、執行環境、獎勵設計和訓練算法每一個環節都認真打磨。
這件事的實踐意義可能比它看起來更深遠。研究團隊在論文末尾明確指出，AI在真實軟體工程場景下的"效率差距"比競賽編程中更嚴重——在一個名為SWE-fficiency的工業級代碼效率測試平台上，Claude 4.5 Sonnet能正確修復81%的軟體問題，但只捕獲了人類專家優化效果的4.1%。這說明，從競賽編程遷移到真實代碼庫，這個問題還需要更多探索。但這項研究提供的方法論——如何構建可靠的速度測量體系、如何設計正確性與速度並重的獎勵機制、如何在稀疏嘈雜信號下穩定訓練——為未來的遷移奠定了基礎。
在代碼效率這件事上，AI正在慢慢補上自己的短板。它現在寫出的程序，開始不只是能跑，而且跑得還不錯了。
---
Q&A
Q1：DMC-Optim數據集是什麼，為什麼普通測試數據不能用來訓練代碼速度優化？
A：DMC-Optim是研究團隊從DeepMind Code Contests原始題庫重新構建的專用數據集，包含2,723道經過清洗的編程題，其中1,302道有足夠大的速度差異可以用於優化訓練。普通測試數據運行時間太短（通常不超過100毫秒），作業系統調度等隨機噪聲的影響已經和代碼本身的速度差異一樣大，根本無法可靠區分快慢。DMC-Optim專門生成了大規模輸入測試，讓優化測試的運行時間達到數秒，噪聲影響相對可以忽略。
Q2：GRPO強化學習算法在代碼優化訓練中遇到了什麼特殊問題，研究團隊如何解決？
A：核心問題是獎勵信號極度稀疏，訓練初期有40%至50%的批次因為所有生成的代碼都拿不到正獎勵而被完全丟棄。研究團隊通過三項調整應對：增加同一題目生成的答案數量以降低全負概率、擴大訓練批次以穩定梯度估計、以及丟棄超過30個優化步驟的舊數據以避免過時獎勵信號污染訓練。
Q3：代碼優化強化學習訓練後，AI程序的速度提升主要來自哪類改進？
A：根據對174對代碼的盲審分析，約47%的速度提升來自更高效的輸入輸出處理，34%來自常數因子優化（如減少不必要計算），6%來自算法改進，6%來自數學捷徑，還有少部分來自數據結構替換。AI在IO優化和常數因子調整上表現很好，但在發現根本性的算法複雜度改進方面，還只達到了頂尖人類程序員約一半的水平。
