Composer 2.5 現已在 Cursor 推出。

相較於 Composer 2，它在智慧與行為表現上都有顯著提升。它更擅長持續處理長時間執行的任務，能更可靠地遵循複雜指示，也更容易合作。

我們透過擴大訓練規模、產生更複雜的 RL 環境，以及引入新的學習方法，進一步改進了 Composer。

除了用更高難度的任務來訓練 Composer 2.5 之外，我們也改善了模型在溝通風格與推理強度校準等行為層面的表現。現有基準測試不太能充分反映這些面向，但我們發現，這些面向對真實世界中的實用性非常重要。

Composer 2.5 奠基於與 Composer 2 相同的開放原始碼檢查點，也就是 Moonshot 的 Kimi K2.5。

我們正與 SpaceXAI 攜手，從零開始訓練一個規模大得多的模型，使用的總算力是原先的 10 倍。憑藉 Colossus 2 的百萬 H100 等效算力，以及雙方整合的資料與訓練技術，我們預期這將成為模型能力的一次重大躍進。

#試用 Composer 2.5

Composer 2.5 的定價為每百萬輸入 token $0.50、每百萬輸出token$2.50。

另有一個智慧相同但速度更快的版本，定價為每百萬輸入 token $3.00、每百萬輸出token$15.00，成本低於其他尖端模型的 fast 層級。與 Composer 2 類似，fast 為預設選項。請參閱我們的模型文件以了解完整資訊。

Composer 2.5 在第一週提供雙倍用量。

#訓練 Composer 2.5

Composer 2.5 在我們的訓練堆疊中帶來了幾項新改進。這些變更同時著眼於模型的智慧與可用性。

#以文字意見回饋進行針對式 RL

在 RL 中進行獎勵歸因正變得愈來愈困難，因為 rollout 可能長達數十萬個 token。當獎勵是根據整個 rollout 計算時，模型可能很難判斷究竟是哪個具體決策促成了結果，或損害了結果。當我們想要抑制某種局部行為時，這個限制尤其明顯，例如錯誤的工具呼叫、令人困惑的解釋，或風格違規。最終獎勵可以告訴我們哪裡出了問題，但對於問題究竟出在哪裡，它只是個帶有雜訊的訊號。

為了解決這個問題，我們以針對式文字意見回饋來訓練 Composer 2.5。¹ 其核心想法是：直接在模型本來可以表現得更好的軌跡位置提供意見回饋。針對目標模型訊息，我們會建構一段簡短提示來描述期望的改進，將這段提示插入局部上下文中，並將得到的模型分佈作為 teacher。我們則使用原始上下文下的 policy 作為 student，加入 on-policy distillation KL loss，讓 student 的 token 機率朝 teacher 的機率靠攏。這樣一來，我們就能為想要改變的行為提供局部化的訓練訊號，同時仍保留涵蓋整段軌跡的整體 RL 目標。

舉例來說，假設有一段很長的 rollout，其中包含一次工具呼叫錯誤：模型嘗試呼叫某個不可使用的工具。在 rollout 過程中，模型會收到「找不到工具」錯誤，然後繼續進行其他有效的工具呼叫。在數百次工具呼叫中只發生這一次錯誤，對最終獎勵的影響通常非常有限。

透過文字意見回饋，我們可以在有問題的 turn 上下文中插入提示，來針對這個特定錯誤，例如「提醒：可使用的工具……」，並附上可使用工具清單。這個提示會改變 teacher 的機率分佈，降低錯誤工具的機率，並提高有效替代選項的機率。僅針對該 turn，我們接著會更新 student 的權重，使其朝新的機率靠攏。

在 Composer 2.5 的訓練過程中，我們將這種方法應用於各種模型行為，從程式碼風格到模型溝通皆然。

#合成資料

在 RL 訓練期間，Composer 的程式設計能力大幅提升，甚至開始能正確解出大多數訓練題目。為了持續提升智慧，我們會在整個訓練過程中動態挑選並建立更困難的任務。Composer 2.5 使用的合成任務數量是 Composer 2 的 25 倍。

我們採用多種方法來建立以真實程式碼庫為基礎的合成任務。例如，其中一種合成方法是功能刪除。對於這類任務，代理會拿到一個含有大量測試的程式碼庫，並被要求以特定方式刪除程式碼和檔案，讓程式碼庫在移除特定且可測試的功能後，仍能維持正常運作。接著，合成任務就是重新實作該功能，而這些測試則作為可驗證的獎勵機制。

大規模建立合成任務的一個連帶後果，是可能導致出乎意料的獎勵投機取巧。隨著模型愈來愈熟練，Composer 2.5 也愈來愈能找出更精巧的變通方式來完成眼前的任務。在一個例子中，模型找到殘留的 Python 型別檢查快取，並逆向分析其格式，藉此找出已刪除的函式簽章。在另一個例子中，它甚至能找到並反編譯 Java 位元組碼，進而重建第三方 API。我們透過代理式監控工具找出並診斷了這些問題，但這也顯示出，在大規模 RL 中必須更加審慎。

#分片 Muon 與雙網格 HSDP

在持續預訓練中，我們使用搭配分散式正交化的 Muon。在形成動量更新後，我們會依照模型的自然粒度執行 Newton-Schulz：注意力投影以每個 attention head 為單位，而堆疊式 MoE 權重則以每個 expert 為單位。

主要成本在於對 expert 權重做正交化。對於分片參數，我們會將形狀相同的張量批次化，透過 all-to-all 把分片重組成完整矩陣，執行 Newton-Schulz，接著再透過 all-to-all 將結果傳回原本的分片版面配置。這些傳輸是非同步的：當某個任務在等待通訊時，最佳化器執行階段會繼續推進其他 Muon 任務，讓網路通訊與運算重疊進行。這在效果上等同於完整矩陣 Muon，同時也能讓分片群組持續保持忙碌；在 1T 模型上，最佳化器步驟時間為 0.2 秒。

這也和我們在 MoE 模型中使用 HSDP 的方式緊密相關。HSDP 會建立多個 FSDP 複本，並在對應的分片之間對梯度執行 all-reduce。我們對非 expert 權重與 expert 權重採用不同的 HSDP 版面配置：非 expert 權重相對較小，因此其 FSDP 群組可以維持較窄，通常限制在單一節點或機架內；而 expert 權重承載了大部分參數，也包含大部分 Muon 運算，因此會使用更寬的 expert 分片網格。

將這些版面配置分開，也能讓彼此獨立的並行能力維度相互重疊：CP=2 與 EP=8 可以在 8 個 GPU 上執行，而不必在單一共享網格中需要 16 個 GPU。這樣可避免讓規模較小的非 expert 狀態進行大範圍通訊，同時把 expert 最佳化器的工作分散到更多 GPU 上。