編輯 | 玉澄
「有時模型實際上能察覺到自己是在虛擬環境還是真實環境中運作，這會導致它在強化學習（RL）期間的表現與在實際生產環境中的表現有所不同。」
「模型簡直太喜歡作弊了，強化學習非常擅長鼓勵這種『作弊』行為。」
不久前，Cursor 發布了其自有模型 Composer 的第二代最新版本，效能直逼 Claude Opus 4.7，而價格僅為其 1/10，在社群中引起了一波熱議。一家應用層公司轉變為一家真正的前沿模型實驗室，真的很好奇他們是如何做到的。
恰好近期，紅衫官方 Podcast 邀請了 Cursor Composer 2 專案的研究負責人 Federico Cassano，以及負責為此專案提供分散式基礎設施的 Fireworks 的 Dmytro Dzhulgakov，聊了聊「Composer 2 是如何被構建的」這個議題。
我們這就來深入了解一下。
在 5 月 19 日新模型發布時，官方提及在 Kimi K2.5 開源基礎上，最新模型 85% 的算力花在了中期訓練和強化學習上。這次的對話基本上就是圍繞著中期訓練和強化學習來展開的。
首先讓人驚訝的一點是，Federico 說在 RL 過程中，如果模擬環境與真實的使用者電腦環境稍有差異，模型是能察覺到自己正處於「虛假環境」中的。而當模型意識到這點後，它還會用一些「小撇步」來「作弊」，以獲得更高的獎勵值，而不是真正去學習解決問題的方法。
在 RL 對模型的作用方面，Federico 的洞見也非常有趣。他說預訓練是讓模型吸收人類的全部知識，而 RL 階段則像是在調節一個「旋鈕」，讓模型明白：「嘿，你是個專家，你需要把事情做正確。」並且在 RL 訓練期間，模型會直接與 Cursor 的 Harness 進行互動，這讓模型能夠了解「自己餘生將要生存的這個『世界』」。
Dmytro 也分享了一個對行外人士非常有衝擊力的事實，那就是浮點運算在電腦上是非確定性的，即 a+b+c 的結果不一定等於 c+b+a。而這對 RL 影響很大，因為混合專家模型（MoE）對精度極度敏感，計算差異會導致模型啟用完全不同的專家節點，產生完全不同的結果。因此，微小的計算差異是會導致 RL 訓練失敗的。所以為了解決這個問題，工程師需要手動編寫複雜的 GPU 核心來強制運算順序一致。
在推理算力分配上，Federico 也有著獨特的見解。他認為在推理上消耗的浮點運算次數（FLOPs）遠多於訓練是一種迷思，理想情況下應該將 1/3 的 GPU 算力分配給推理，剩下的用於更新權重。
此外，他們認為對於特定領域，模型的「專門化」勝過「通用化」。傳統認為模型越大、越通用越好，但他們將所有模型權重針對「Cursor 內部的軟體工程」任務專業化後，較小的模型能在效能上接近 Opus 這樣的大模型，而且成本降低了一個數量級。另外，Harness 上也會跑 RL。透過對 Harness 的一部分與模型本身組成的系統進行 RL 優化，他們讓 Composer 2 訓練出了「自我總結」或「壓縮」能力，這能讓模型在 20 萬上下文視窗基礎上實際處理百萬個 Token。
他還分享了自己對 RL 環境的見解。他認為 RL 環境實際上是由三部分組成，分別是 Harness、作業系統和獎勵元件。其中 Harness 通常是可移植的，關鍵的是作業系統。所以在 Cursor，他們自己構建了具備極強爆發性的整個虛擬機器（virtual machine）棧，這樣他們能夠根據需求瞬間啟動 10 萬個虛擬機器供模型進行實驗。至於獎勵元件呢，訪談中主持人有問到在 RL 中他們使用的是什麼樣的獎勵信號？結果是不能說，「絕對機密」。
還有一個問題他們也表示不能回答，就是對於 Andre Karpathy 說過的：目前的 RL 仍然極其低效，進行一次漫長的「推演」（rollout），最後卻只能在末尾得到一點點資訊，這感覺就像是用吸管在吸取位元。他們對如何「從這條路徑中榨取更多的位元」也是保密態度。
以下是這次 Podcast 的完整內容，敬請享用：
成本低一個數量級！模型權重針對程式設計任務專業化
主持人：今天很高興能與兩位聊聊 Composer 2 的訓練是如何完成的，你們共同解決了哪些難題，以及你們認為這對 AI 和基座模型公司的未來意味著什麼。
Federico / Dmytro：聽起來很讓人興奮。是的，很讓人興奮。謝謝你邀請我們。
主持人：感謝你們的加入。對於那些沒有密切關注我們的人，Cursor 最近發布了 Composer 2，這是一個專門用於長週期（long horizon）編碼任務的智慧體編碼模型。Federico，在此之前，Cursor 主要是在賦能其他人的編碼智慧體。是什麼促使 Cursor 如此大力地投入到 Composer 2 的研發中？對你們來說，從一家單純的應用層公司轉型為一家同時擁有自己基座模型的公司，這具有多大的存亡攸關的意義？
Federico：我們開始研究訓練自己模型的原因是，你可以把模型看作是一種儲存裝置，它的權重中可以儲存一定數量的位元。想法其實非常簡單：我們只關心一項任務，我們甚至不一定關心廣義的編碼或程式設計，我們只關心 Cursor 內部的軟體工程，而且也僅限於 Cursor 內部。那麼，如果我們把模型權重中能儲存的所有資訊位元，全部完全分配給這一項特定的任務會怎麼樣呢？此外，大家可能也注意到了，Composer 的成本比 Opus 和其他類似的編碼模型要低一個數量級，因為我們只需將所有的模型權重針對該特定任務進行專業化，這樣我們就可以提供一個更小的模型或類似的東西。
Dmytro：是的。完全正確。
主持人：所以，核心在於確保我們擁有的每一個權重位元或資訊，都專注於我們眼前要解決的特定問題。完全正確。明白了。這聽起來像是一個幾乎可以泛化的問題。Dmytro，我很想聽聽你的看法。你認為所有的應用層公司都應該把 Cursor 視為未來的風向標嗎？他們是不是都應該嘗試做同樣的事情？
Dmytro：是的，絕對應該。我的意思是，我們通常認為這是應用演進的一種普遍模式。你可能從做原型開始，使用一些現成的模型來讓專案運作起來。你可能會做一些提示詞工程，弄清楚你的 harness 是如何運作的。但是，你的應用中最具槓桿效應的屬性，實際上是對使用者資料的利用，或者應用運作方式的某些特定維度，比如你的框架的某些方面、你提供了哪些工具、應用是如何工作的，這些對你的應用來說至關重要。要捕捉到這些，透過提示詞可以做到一點點，但真正正確的方法是打造一個完全在你的特定環境中運作的模型。
Federico：是的，絕對是這樣。比如智慧體叫用的某些工具，你很難用簡短的語言向模型精確描述該工具的行為。而透過後訓練，我們可以把使用這些工具的最佳方式直接內建進模型裡。就像 Composer 一樣，我們確實給 Composer 提供了一個提示詞，但我認為以我們的訓練方式，即使沒有提示詞它也能正常工作，它也會知道該怎麼做。因為在整個訓練過程中，我們本質上一直在把模型推向它應該表現的正確方向。
Dmytro：提示詞工程能達到的效果是有上限的。如果你想打造真正偉大的 AI 產品，你就必須經歷微調（fine-tuning）並影響模型的行為，這是原因之一。第二個原因是成本和速度的權衡。我們在 Fireworks 的看法是，當你嘗試進行優化時，你在品質、速度和成本之間面臨著一個三維的權衡。最初，你僅靠優化基礎設施就能走得挺遠，我們和所有的客戶一開始都是這麼做的。但當你開始介入模型訓練時，你真的可以把這種權衡推向更遠，你可以用極低的成本、極快的運行速度獲得更佳的模型。Composer 就是一個很好的例子。
主持人：關於這點我能進一步追問一下嗎？我想問這種方法是否符合「苦澀的教訓」（bitter lesson）這顆藥丸的規律。在走進來之前，我們實際上都在聊 Tabnine（一款AI程式設計助手）。我記得在大型語言模型（LLM）時代到來之前，有很多這種小型的專業化編碼模型。但讓很多人感到驚訝的一點是，隨著模型規模的擴大，你知道，僅僅透過在網際網路、大量英文文本和其他語言上進行訓練，模型本身在編碼方面自然而然地也變得更好了。因此，至少到目前為止我看到的趨勢是：更大的模型在所有事情上表現都更好，包括編碼。你們所說的，是不是有悖於「苦澀的教訓」的大趨勢？
Federico：我認為並沒有。但有一點需要指出的是，各大實驗室訓練的大模型在程式碼資料上也投入了大量的訓練。程式碼是實驗室最想推進的核心任務之一，所以大模型並不只是自然泛化到編碼的，它們本身也有一定的專業化。在我們的情況下，如果我們相信「苦澀的教訓」，我們其實是在資料維度上大力推進。我們知道模型本質上容量是有限的，所以如果我們想飽和利用所有的容量，我們需要擴大資料規模。而為了注入更多的資料，我們需要讓權重從模型可能受到的干擾中解放出來。
主持人：明白，這非常有意思。好，讓我們深入探討一下 Composer 2 的訓練。
雙軸訓練賦能，RL 讓模型更了解 Cursor 環境和寫出正確的程式碼
主持人：你們幾週前發布了它，立刻吸引了全場的目光。強大的基準測試數據，推理運行成本也低得多。關於 Composer 2 是如何運作的，以及你們做了什麼讓它表現如此出色，能介紹一個精簡版嗎？
Federico：我們是從一個非常強大的基礎模型開始的，也就是 Kimi 2.5。那是一個總參數量 1 兆、啟用參數 30B 的模型，所以非常稀疏。實際上，我們審視了整個技術棧，意識到主要有兩個軸。Composer 1 主要只在其中一個軸上發力，即強化學習（RL）；而 Composer 2 則在兩個不同的軸上同時推進：一個是持續預訓練，另一個是強化學習。讓 Composer 2 變得非常優秀的原因正是雙管齊下。我們在訓練初期對程式碼 Token 進行了大量的「中期訓練」，規模幾乎接近預訓練；然後在這段中期訓練結束後，我們拿到了檢查點，並在海量的任務上進行了非常大規模的強化學習。
主持人：明白。這裡的前提應該是，因為 Cursor 處於這麼多有趣的編碼 Token 的中心，你們擁有非常獨特的資料近用優勢，能夠以幾乎接近預訓練的規模進行訓練。是的。那為什麼不直接預訓練你們自己的模型呢？
Federico：我們只是習慣由上而下、而不是由下而上地去思考我們的方法。換句話說，我們如何在最短的時間內，交付一個對使用者有用的模型？如果我們從最底層開始，先去摸索怎麼做預訓練，然後把它擴大到中期訓練，接著搞懂中期訓練後再做強化學習，那要花很長很長的時間才能把模型交到使用者手中。而透過反向操作，我們能夠在極短的時間內給使用者提供一個好用的模型。當然，我們希望接下來的 Composer 版本將會是我們自己的模型，而不是基於開源底座。
主持人：明白了。那對你們來說，模型在中期訓練階段大概學到了什麼？在後訓練階段又學到了什麼？
Federico：在中期訓練中，它主要是學習各種程式碼庫，以及非常常見的特定程式碼模式，同時也包含一些世界知識，其中也有網頁資料。這實際上是在創造一個更廣泛的分布，以便後續的強化學習可以在此基礎上進行聚焦和提煉。在強化學習期間，模型可以直接與 Cursor 的 harness 進行互動。所以在某種程度上，它能夠了解自己餘生將要生存的這個「世界」，對吧？在強化學習中，它學會了如何正確叫用工具、如何導航其所處的環境、如何編寫正確的程式碼。因為在中期訓練中，它只是學會了「如何寫程式碼」，但這並不一定意味著它學會了「如何寫出正確的程式碼」。我們雖然盡量用基本正確的程式碼進行訓練，但模型本身並不知道如何區分正確與錯誤。而在 RL 階段，我們做的核心事情之一就是微調模型的特性，告訴它：「嘿，現在你必須時刻寫出正確的程式碼。」
主持人：完全正確。很有意思。那在中期訓練之後的這個模型，是類似於你們在 Tab 自動補全中使用的模型，還是屬於不同的核心能力？
Federico：是的，我的意思是……我想我會這樣看：因為在中期訓練期間，我們只是在做下一個 Token 的預測，也就是你預測下一個 Token 以及再下一個 Token 的準確度。
主持人：既然如此，為什麼不直接在你們的 Tab 自動補全模型上進行後訓練呢？為什麼要為不同的模型進行中期訓練？
Federico：因為 Tab 是一個非常小的模型，為了實現極低的延遲，它必須執行得非常快。所以這裡基礎模型有兩個核心區別：Tab 非常小，而 Composer 相當大。
RL 訓練核心困境：會話推演、模型更新與算力利用率的多方權衡
主持人：明白了，明白了。好。看來你們為 Composer 2 所做的大部分精力都集中在這次大規模強化學習的執行上。能幫我們拆解一下嗎？這當中包含了什麼，以及在此過程中你們解決了哪些不同的難題？
Dmytro：當你做強化學習時，它與預訓練或中期訓練大不相同，因為你不僅僅是試圖預測下一個 Token，你實際上是在執行整個框架，也就是整個實驗。你在讓模型在環境中行動，看它在特定「推演」（rollout）中的表現如何，「推演」就是這裡的專業術語。並且根據它是否正確完成了某些事情來為它分配獎勵，這可能是透過使用大模型（LLM）作為裁判，或者是一些可驗證的指標，比如這段程式碼是否能成功編譯。這意味著與常規訓練相比，你需要大量其他元件：你仍然需要大規模訓練，仍然需要編排成千上萬個 GPU 來做前向和反向傳播，做你在中期訓練和預訓練中做的一切事情；但現在你還需要編排一大堆環境，需要執行模型推理。因為當你進行這種「推演」時，你實際上是在執行一個真實的 Cursor 會話，對吧？
主持人：抱歉打斷一下，「推演」（rollout）基本上就是指來自 Cursor 的整個智慧體歷史會話，對吧？
Dmytro：是的，這基本上意味著它可能需要進行 50 輪對話：模型接收初始提示詞，然後決定叫用一些工具，你要去執行這些工具，接著模型又生成一堆其他程式碼……這就是你與 Cursor 中的智慧體互動時的完整會話。在訓練執行中，你會把這整個會話模擬出來，得到最終的獎勵，並利用該信號返回給訓練器，將其融入到模型權重中。所以你擁有一個非常龐大的更新迴圈，而且它非常異構（heterogeneous），因為所有這些不同的元件都在協同工作。而現在你正試圖編排這一切，讓它高效、高吞吐量地運轉，因為 GPU 非常昂貴，你希望以經濟的方式快速訓練好你的模型。
所以這本身就是一個非常有趣的問題，處於演算法和基礎設施的交匯點，因為在系統如何進行共同優化和共同設計上存在著很多權衡。其中一個方面就是人們所說的「管線非同步化（asynchronous pipeline）」。其核心理念是，你試圖分步更新這個模型：你擁有當前的模型版本，並試圖用它進行大量的「推演」。那麼在你進行這些「推演」時，你的訓練器在做什麼？一種樸素的方法會說：「好吧，現在我要停止我的訓練器。我要去跑一堆會話」，而如果面對的是長週期任務，這些會話可能會執行 5 到 10 分鐘甚至更長。「然後我拿到這些結果，暫停我的推理，回到訓練中嘗試進行更新。」這在理論演算法上非常健壯，因為你沒有產生任何偏差，但它在系統上非常低效，因為你有一半的算力一直處於閒置狀態。所以作為替代，你可以使用所有這些聰明的演算法技巧。
主持人：是的。
Dmytro：你可以把這一切都變成管線。把這想像成一個巨大的工廠：你有一個訓練器車間，還有一個「推演」車間，它們一直在旋轉運轉。進行「推演」的車間總是獲取最新的模型版本並嘗試跑新的會話，模擬新的智慧體會話；而訓練器車間則總是在新的結果一出來就拿過來，並嘗試計算更新。所以一切都在馬不停蹄地向前推進。這種權衡之所以在演算法上有所不同，是因為當你完成模擬環境中的某些測試「推演」時，模型的權重可能已經在其他資料上更新過了。所以你會有這種陳舊性（staleness），也就是模型學習更新之間的延遲。因為當你處理完與模擬環境的某種互動會話時，你的模型已經改變了。這引入了有趣的訓練動力學（training dynamics），有一些聰明的方法可以解決這個問題。但它的另一面是，你所有的 GPU、所有的計算資源都在時刻保持滿載並高效運轉，這意味著你在使用更多的浮點運算次數（FLOPs）。回到你之前提到「苦澀的教訓」的例子，這樣就擁有了更高的計算效率。
主持人：你可以在更短的時間內得到一個更好的模型。
Dmytro：是的。也許你因為非同步操作、沒有進行完美的數學更新而損失了幾個百分點的效果，但由於你沒有把一半的算力閒置在那裡，這極大地彌補了這一損失。這其中有很深的學問和有趣的互動。
AI 也會「耍小聰明」！透露模型虛擬環境作弊現象
Federico：我們在 Cursor 對效能是非常認真的，因為不像那些大實驗室，我們只有幾萬張 GPU，而不是幾百萬張。所以，是的，我們用盡了各種招數來榨乾 GPU 的每一點效能。比如我們在生產環境中甚至使用 FP4 進行訓練；我們與 Fireworks 合作來推進推理效能。因為基礎設施的特別之處在於，它本質上比預訓練更複雜。因為你首先需要所有的預訓練基礎設施，這只是基本要求之一；然後，你需要所有的基礎設施來執行這些環境，這些環境必須儘可能貼近地模擬使用者電腦的實際情況。儘可能貼近是非常重要的，因為有時模型實際上能察覺到自己是在虛擬環境還是在真實環境中執行，這會導致它在強化學習期間的表現與在生產環境中的表現有所不同。
主持人：你們有看到它意識到自己身處虛擬環境並開始表現得不一樣嗎？
Federico：是的，確實有。
主持人：真有意思。
Federico：就像它會想：「哦，我在一個虛擬環境裡。我學到了一些小撇步，可以在這個環境裡獲得更高的獎勵，讓我來試試看。」模型簡直太喜歡作弊了，強化學習（RL）非常擅長鼓勵這種作弊行為。
Federico：是的。而且我們還需要非常高效的推理，這至關重要。實際上存在一個迷思，認為在強化學習過程中，你在推理上消耗的 FLOPs 遠多於訓練。這其實只是因為開源推理引擎非常缺乏優化，而不是強化學習本身的特性。理論上它們的比例大致是相當的。如果把 GPU 的效能推到極限，你應該將大約三分之一的訓練 GPU 分配給推理，對吧？因為訓練實際上相當於三次前向傳播：前向傳播、資料梯度計算和權重梯度計算。而如果在推理時真正達到了臨界批次大小（critical batch size），你只需要相當於單次前向傳播的 FLOPs 消耗。
主持人：所以這就是為什麼你們選擇使用 Fireworks，而不是使用開源推理引擎的原因。
Federico：是的，我的意思是，另一種選擇是我們自己內部研發一個，但像其他所有人一樣，我們的工程師團隊是有限的。我們更希望讓工程師去提高訓練的效率和精準度，而不是去單獨開啟一個推理引擎的研發專案。
推理訓練採取全球化分布部署，還抽調了部分生產算力
主持人：明白，這太硬核了。另外，我記得你們在技術報告中提到，你們是以一種全球分散式的方式來做這件事的。為什麼選擇全球分散式？它的難點又在哪裡？
Federico：是的，原因有很多。首先，市場上很難找到非常巨大的單一連續叢集。因此我們的做法是，用一個主要叢集來執行所有的訓練，畢竟我們無法建立一個全球化的訓練叢集；但是，我們可以把強化學習中的推理元件全球化分散式地部署到世界各地的小型叢集中。在訓練 Composer 2 時，我們總共使用了四個遍布全球且相距甚遠的叢集，我們甚至在生產流量處於低谷時利用了部分生產算力。比如當時我們正在服務上一代模型 Composer 1.5，當使用者使用量最少的時候，我們就直接抽調一部分推理 GPU 來加速訓練。透過這種方式，我們可以在沒有單一連續大叢集的情況下，輕鬆擴大訓練規模。至於如何實現這一點，也許 Dmytro 可以多講講。
Dmytro：對，補充一下 Fed（Federico）所說的，我們的訓練本質上是非常異構（heterogeneous）的。透過利用這種異構性，即不同元件對基礎設施的不同需求，你實際上可以大幅提升效率，這種模式在各個地方都屢試不爽。具體來說，對於訓練，你需要高度互連的叢集、超高速網路，並且需要同步（lock-step）工作。因此這些叢集非常昂貴，而且很難找到規模足夠大的。
基本上，在訓練 Composer 的這種體量下，尋找一個兩倍大的叢集的難度，要遠比尋找當前規模的叢集大得多。這就是為什麼如果你能把這些元件解耦（disaggregate）並部署在不同的地方，一方面你就不需要去找那麼大的叢集了；另一方面，你可以在硬體上做不同的權衡，因為推理不需要那麼高的全域互連頻寬，你只需要把較小規模的 GPU 互連在一起即可。你可以使用異構類型的 GPU，甚至不同世代的 GPU，在優化上玩出各種花樣。最後，推理也更容易隨著需求進行彈性伸縮。沒錯，在非尖峰時段，你可以把整個推理資源池看作是一組既能為真實使用者提供生產服務、又能為強化學習服務模擬環境的 GPU，並在兩者之間取得平衡。當然，這是一個非常有趣的系統工程問題。
一個 1TB 的訓練步大約需要 5 到 15 分鐘。這基本上意味著，每隔 5 到 10 分鐘你就會產生一個全新的 1TB 模型權重快照（snapshot）。那麼問題來了：你如何非常高效地把它傳輸到地球另一端的另一個叢集？而且你必須動作飛快，因為前面提到過，你不能讓這種資料陳舊性（staleness）失去控制。所以這可能是有趣的部分，也是我們共同解決的問題，儘管整個模型有 1TB 大小，但並不是所有的權重在每一步都會發生變化。因為強化學習會進行許多非常精準的微調，特別是隨著訓練的進行。實際上，每次發生變化的權重子集存在著非常規律的模式，並不是所有權重每次都變。如果你去看模型在單次訓練步（比如 10 分鐘後）中的變化，它們之間的增量（delta）是相對較小的。因此你可以編寫一個利用該特性的壓縮演算法，這樣問題就變成了類似於資料庫系統的問題：我拿到了這個增量，我只需要把它傳輸到世界各地。這個增量可能比傳輸整個模型要小 20 倍，這讓方案變得切實可行。
當然，現在你需要圍繞儲存系統構建起一整套機制。也就是完整快照、增量快照、恢復和對齊（reconciliation）等機制。我們成功以無損（lossless）的方式構建了它，這意味著傳輸到另一端的模型在位元級別上是完全等價的。所以你完全不用擔心這當中會有任何差錯，而且它的執行速度極快。即使在最糟糕的網路條件下，你也能在幾分鐘內完成傳輸，通常甚至不到一分鐘。
主持人：我很好奇 Andre Karpathy 那句名言，他說目前的強化學習（RL）仍極度沒效率。你跑了一次非常漫長的「展開」（rollout），最後卻只能在結尾得到一丁點資訊，感覺就像用吸管在汲取位元。你們怎麼看？你們有沒有想出什麼辦法從這條路徑中榨取更多位元？
Federico：呃，這個我不能透露。
主持人：好吧，好吧，我懂了。我們又回到保密環節了。很好，這表示我問對問題了。
二十萬上下文視窗駕馭百萬 Token！Cursor 秘訣：「自我總結」
主持人：你提到每次「展開」需要幾分鐘的時間。目前整個領域似乎都在往打造「長週期智能體」（long horizon agents）的方向推進，也就是讓智能體能夠長時間不間斷地工作，而且通常不會失敗。我非常喜歡那個公尺級擴展圖表。在強化學習過程中，需要做些什麼才能讓智能體運行得更久呢？
Federico：有幾點。首先，強化學習的一個難點在於，執行軌跡越長，進行「信用分配」（credit assignment）就越困難。你可以想像，我們是在模型結束全部工作後，才在最後給它一個讚或踩。簡單來說，模型必須自問：「我哪裡做對了，哪裡做錯了？」這就是所謂的信用分配問題。軌跡越長，這就越難。所以你必須在其中使用很多技巧。另一個問題是空間會不夠用，這些模型的上下文視窗是有限的，遲早會達到上限。
在 Cursor，我們解決這個問題的方法是在循環中加入「壓縮」。我們稱之為「自我總結」（self-summarization）。在強化學習過程中，智能體實際上學會了如何不斷延續、永遠進行下去。在實務上，我們的模型擁有 20 萬的上下文視窗，但實際上它能處理數百萬個 Token。這正是因為它有能力對自己的工作進行總結，然後利用這個總結重新啟動它的上下文視窗，同時依然努力去完成既定任務。透過這種方式，我們在推動模型朝著目標正確行事的同時，也在共同訓練模型生成高品質的摘要，並訓練模型完美地理解該摘要。所以這幾乎就像是推理能力的延續。
Dmytro：我覺得這非常迷人。因為通常情況下，上下文管理被認為是 harness 的一部分，對吧？但在這種情況下，你們實際上是在協同優化 harness 的一部分與模型本身的工作，把所有這些都丟進了優化迴圈中。我們在 AI 領域一再看到，你在一個問題上投入的運算量越多，就越能端到端地解決這個問題。「苦澀的教訓」（bitter lesson）中運算的魔力再次發威，讓你得到了一個能更好協同工作的系統。
主持人：完全正確。你認為每家公司都會在自己的 harness 上跑 RL 嗎？你認為每家公司面臨的問題形式都和 Cursor 一樣嗎？
Federico：如果他們正在使用 AI，並且正在生成大量的 Token，同時有一個可以優化的產品，我認為訓練自己的模型就是正確的舉措，也是正確的方向。
主持人：明白，這很有意思。
RL 讓模型意識到自己的角色是專家，需要把事情做對
主持人：所以，看起來你們做的大部分強化學習都集中在 harness 和工具使用這部分，而不是讓模型變得擅長「預測程式碼的下一個 Token」。對於其他正在思考「我應該在哪裡使用強化學習」的創辦人來說，這大致就是他們應該參考的模式嗎？也就是說：如果你想讓智能體在長週期內使用工具執行任務，你需要強化學習。如果你只是想建立一個擅長摘要或下一個 Token 預測之類的模型，你可能不需要強化學習。這是一個判斷是否需要強化學習的好框架嗎？
Federico：我認為強化學習適用於任何地方。甚至對於 Tab 自動補全，我們也用了……當然這只是我個人的理論，沒有任何依據。當你預訓練一個模型時，模型只是在吸收人類知識的全部集合。假設你正在訓練一個數學模型，模型會學到 Stack Exchange 上所有的數學知識。當這個還沒經過強化學習的模型面對一個數學問題時，它需要琢磨自己到底扮演的是什麼角色，它是一個專家，還是一個試圖學習的學生？因此，我認為在強化學習期間發生的事情之一，就是我們在調節這個旋鈕，讓模型知道：「嘿，你是個專家，你需要把事情做對。」所以其中一個變化就是我們在提煉這種分布，這大概分為幾個階段。在第一階段，模型學得非常快，很快就會變得很厲害；然後是第二階段，需要耗費大量的運算量來持續提升模型，你會看到模型開始展現出推理能力並呈現出這種模式。在曲線的第一階段，我認為我們只是在調節旋鈕，告訴模型：「嘿，你在這裡得把事情做對。」因此，在運算量較小的場景下，讓模型知道它必須把事情做對，也是非常有用的。這就是我的觀點。
（註：Stack Exchange 是一個由多個專業問答（Q&A）社群組成的網路平台，每個站點專注於一個特定領域，用戶透過提問、回答和投票來分享高品質知識。）
Dmytro：我非常贊同。我們在很多使用場景中都看到了這種模式。我們幫助很多客戶進行過強化學習微調，通常你會發現，持續預訓練（基本上是中期訓練）和常規的監督微調（SFT），從抽象意義上說，更像是新知識的傳遞；而強化學習則是在提煉行為，或者說提煉你希望模型具備的特定品質。通常你兩者都需要。甚至以你剛才提到的摘要為例，強化學習在這方面其實也非常有用。因為有時候如果你想要某種特定風格的摘要，你很難拿出完美的「好摘要」和「壞摘要」範例來精確描述它。但如果你使用大模型作為裁判（LLM as a judge），你實際上可以設定非常精準的評審標準。你可以透過提示詞說：「好，這是我評估摘要好壞的標準」，然後把它丟進強化學習迴圈中，讓模型自己去嘗試不同的摘要風格，摸索出你到底想要什麼，同時讓另一個大模型去評估它是否符合特定的標準。這種模式你不僅在編碼中能經常看到，在其他領域也屢試不爽。
用大模型當裁判，軟體編寫第三階段：「編寫評估規則」
主持人：好，我要把下一個問題拋給 Dmytro，因為 Federico 肯定會主張憲法第五修正案（選擇保持沉默）。你剛才提到了好幾次「大模型作為裁判」。你認為最終那些讓專家手動檢查 RL 展開路徑、並以某種方式手動指導模型行為的公司會更成功，還是大模型作為裁判以及其他自動化評審標準更有可能帶我們達到目標？
Dmytro：你不可能真的讓專家直接去評審每一次的展開路徑。我的意思是，那就會變成某種……如果是真實用戶的話，那就是即時強化學習，或者某種形式的 RLAIF（基於 AI 回饋的強化學習）或 DPO。總的來說，你的獎勵訊號越可驗證（verifiable）越好，因為這能讓你擴大運算規模，並在某些情況下獲得更好的結果。所謂「可驗證」，基本上意味著：你能在沒有人類介入的情況下自動產生這個訊號嗎？當然，如果是數學或編碼，你能設計出某種非常確定性的東西，那是最好的。大模型作為裁判之所以行得通，是因為它實際上屬於「生成器與判別器」的區別，判斷要比創造容易得多。對人類來說也是如此，對吧？當一個評判者要比當一個創投（VC）容易得多。
主持人：哈哈，這裡沒有含沙射影的意思。
Dmytro：確實沒有別的意思。但確實，評判要容易得多，你可以精準地設計出你想要對某個回答進行排序的不同標準。你會看到這樣一種模式：你可能會針對多個維度設計非常複雜的評估。因為如果你把多個維度一股腦丟給單個大模型，它可能會在如何評判上感到困惑，對吧？所以你可以把它拆解開來。比如：這個大模型根據風格進行評判，那個大模型根據不同的方面（如事實性）進行評判，從而真正打造出這些獎勵訊號。它們當中有些會是確定性的，有些會是基於大模型的，這就是引導你模型行為的東西。然後你只需投入更多的運算量，就能看到圖表上的曲線一路走高。
主持人：你認為我們會在那種更難驗證的領域看到強化學習扮演更顯著的角色嗎？你認為大模型作為裁判足以應付嗎？
Dmytro：這是你在初始階段會首先嘗試的技術之一。在理想情況下，你想弄清楚實際的結果是什麼，你想獲取的真實指標是什麼。因此，嘗試去逼近這個指標是一種方法，嘗試去建構更大的模擬環境是另一種方法，對吧？如果你能模擬出更多你的產品，模擬出更多你的環境，你通常就能得到你所關心的最終指標，只是它更難被捕捉而已。如果你能想出如何捕捉它，那就太棒了。至於你行業專家的角色，專家依然是不可或缺的，因為設計這些任務並真正將產品體驗編碼進去，這才是至關重要的。我們經歷了軟體 1.0、2.0、3.0，對吧？過去我們是直接編寫軟體，後來我們轉向編寫訓練資料，而現在，你實際上是在編寫評估規則。但這依然非常重要。你需要看示例，看資料，看你的產品在哪裡失敗，以及如何引導模型走上正確的行為。
RL 環境由三部分組成，Cursor 自己打造了整個虛擬機堆疊
主持人：我想問問關於強化學習環境（RL environments）的問題，這可能與你剛才談到的內容相關。現在似乎出現了一個大爆發，一些做 RL 環境的公司其營收規模正急速攀升。它們到底提供了什麼真正有用的東西？因為我覺得以 Cursor 為例，你們已經擁有了關於客戶實際上如何使用你們環境的海量資料。那麼，強化學習環境供應商在你們既有的基礎上，還能給你們提供什麼呢？
Federico：實際上我們沒有使用任何環境供應商的產品。我認為建構一個能正常運作的環境是非常困難的。對於那些無法接觸到這類資料的人來說，這是一個很有價值的產品。然而，特別是在編碼領域，每個人都可以獲得海量的可用編碼環境。那就是 GitHub，對吧？你可以進去，讓模型把一個倉庫的所有依賴項全部安裝好，這就是一個可以運行的環境。我認為很大一部分困難來自於基礎設施。你可以想像，一個對特定任務有效的環境可能需要啟動各種服務。比如你正在做一項修改，假設是一個資料庫遷移，為了測試它是否真正起作用，你需要把資料庫啟動起來，對吧？這類事情是非常棘手的。我認為這些環境公司在這類事情上是挺有幫助的。
Dmytro：這裡面其實有兩個層面。首先，如果你看前沿實驗室，他們試圖建構一個在所有事情上都很擅長的通用模型，所以他們需要涵蓋所有這些不同的底層任務，封裝進同一個模型中，並鼓勵它去進行泛化。所以那是其中一個部分，在那種情況下它們非常有幫助。但如果是像 Composer 這樣的情況，你擁有你真實的實際產品，我認為這也是我們在 Fireworks 所相信的，如果擁有自己的實際產品，你就應該針對它把效果做好。最強大的環境就是你自己的產品，完全正確。因為那是你的模型實際會被使用的地方。
當然，如果你是前沿實驗室，你不可能跨越所有的產品去做這件事；但如果你是想為自己的產品打造最好的模型，使其專業化並量身定製，你就應該直接使用你的生產環境（production environment）。當然，你需要對其進行妥善的隔離，對吧？你可不想讓模型在你的生產資料庫中大搞破壞，你需要進行複製等操作。環境公司會提供一些工具，就像通用基礎設施一樣，讓這一切變得更容易。但總的來說，你希望你的強化學習環境盡可能地接近真實的生產環境。
舉個例子，據我們所見，如果你去看那些玩具式的 RL 示例或玩具級框架，它們總是這樣開始的：「哦，這裡有一個玩具環境，我要啟動一個 Docker 容器並在裡面運行所有東西。」如果你只是想教模型怎麼玩雅達利遊戲之類的話，這確實很棒。但如果要真正過渡到生產案例，你不能只是把真實的生產應用塞進一個 Docker 容器裡。我們自己很早就發現了這一點，比如和 MetaFox 合作時，在 Cursor 這邊運行訓練器。而對於其他一些客戶，我們在我們的訓練平台上運行訓練器，但在環境方面，我們實際上預設在客戶側運行它們，因為那是實際實作所在的地方。你實際上擁有相同的訓練器設置（即使它是 Fireworks 平台的一部分），在客戶側調用實際的生產環境，而不是試圖去包裹它並將其組件化。
Federico：在託管平台上做這個，因為那真的非常困難，而且會引入差異。
我們所說的「強化學習環境」實際上由三個組件構成。第一是 harness，也就是模型可以提交工具、工具被執行的地方。第二是我們可以稱之為「作業系統」的東西，也就是模型正在與之互動的實際世界和狀態。第三是我們需要的獎勵組件，它需要在最後檢查工作是否正確完成。通常來說，harness 是相當可移植的，你可以把它帶到許多不同的環境中。關鍵的部分是作業系統，而要複製這一點，普通的容器其實運作得不太好。所以在 Cursor，我們實際上自己建構了整個虛擬機堆疊（virtual machine stack），這樣我們就能非常快速地啟動虛擬機。它必須具備極強的爆發性（bursty），因為你可以想像，我們可能會要求這個系統：「請現在給我提供 10 萬台虛擬機」，然後它們必須全部啟動完畢。
主持人：太棒了。我今天非常享受這次對話。我認為 Cursor 真的樹立了一個榜樣，展現了你們作為一家公司如何從一家應用層公司演進為一家真正的前沿模型實驗室。我認為你們在 Composer 2 上所做的工作確實引領了這一潮流。能聽到這些內幕真的很特別。Dmytro，聽到你們兩位在無數個深夜裡並肩作戰、在前線共同解決的那些硬核基礎設施難題，真的太酷了，是這些努力讓一切成為了可能。所以，謝謝你們。感謝兩位今天來到我們的播客。
Federico：非常感謝你邀請我們。
Dmytro：謝謝。
參考連結：