推出 Composer 2.5
Composer 2.5 現已在 Cursor 推出。
相較於 Composer 2，它在智慧與行為表現上都有大幅提升。它更擅長長時間持續處理任務，更可靠地遵循複雜指示，也更容易與之協作。
我們透過擴大訓練規模、產生更複雜的 RL 環境，以及引入新的學習方法，進一步改進了 Composer。
除了讓 Composer 2.5 在更困難的任務上接受訓練之外，我們也改善了模型在溝通風格與投入程度校準等行為面向的表現。現有基準測試無法充分捕捉這些維度，但我們發現它們對真實世界中的實用性非常重要。
Composer 2.5 建立於與 Composer 2 相同的開源檢查點之上，也就是 Moonshot's Kimi K2.5。
我們正與 SpaceXAI 一起，從零開始訓練一個規模大得多的模型，使用的總算力是原本的 10 倍。憑藉 Colossus 2 的百萬個 H100 當量，以及我們結合的資料與訓練技術，我們預期這將帶來模型能力的一次重大飛躍。
Composer 2.5 的訓練
Composer 2.5 針對我們的訓練堆疊帶來了多項新改進。這些變更同時著重於模型智慧表現與易用性。
以文字意見回饋進行定向 RL
隨著 rollout 可能長達數十萬個 token，RL 過程中的 credit assignment 也變得愈來愈困難。當 reward 是根據整個 rollout 計算時，model 往往很難判斷究竟是哪個特定決策改善了結果，或讓結果變差。這在我們想抑制某種局部行為時尤其受限，例如錯誤的 tool call、令人困惑的說明，或風格違規。最終 reward 可以告訴我們哪裡出了問題，但對於問題是在哪裡發生的，它只是帶有雜訊的 signal。
為了解決這個問題，我們以定向文字意見回饋訓練 Composer 2.5。1 其核心想法，是在 model 原本可以表現得更好的 trajectory 節點上直接提供意見回饋。針對目標 model 訊息，我們會建構一段描述期望改進方向的簡短提示，將這段提示插入局部上下文中，並使用得到的 model distribution 作為 teacher。我們以原始上下文下的 policy 作為 student，並加入 on-policy distillation KL loss，讓 student 的 token probabilities 朝 teacher 靠攏。這讓我們能為想要變更的行為提供局部化的 training signal，同時保留涵蓋整段 trajectory 的更廣泛 RL 目標。
為了說明文字意見回饋的流程，請考慮一段較長的 rollout，其中包含一次 tool call 錯誤：model 嘗試呼叫一個不可使用的工具。在 rollout 過程中，model 會收到「Tool not found」錯誤，然後繼續進行其他有效的 tool call。在數百次 tool call 的過程中只出現一次這樣的錯誤，對最終 reward 的 impact 會非常小。
透過文字意見回饋，我們可以在有問題的回合上下文中插入提示，來鎖定這個特定錯誤，例如「提醒：可使用的工具……」以及可使用工具的清單。這個提示會改變 teacher 的 probabilities，降低錯誤工具的機率，並提高有效替代工具的機率。接著，僅針對該回合，我們會更新 student weights，使其朝新的 probabilities 靠攏。
在 Composer 2.5 的訓練過程期間，我們將這個方法應用於各種類型的 model behavior，從 coding 風格到 model 溝通。
合成資料
在 RL 訓練期間，Composer 的程式撰寫能力大幅提升，進步到足以正確解決大多數訓練問題。為了持續提升智慧，我們會在整個訓練過程中動態挑選並建立更高難度的任務。Composer 2.5 使用的合成任務數量是 Composer 2 的 25 倍。
我們採用多種方法來建立以真實程式碼庫為基礎的合成任務。舉例來說，其中一種合成方法是刪除功能。在這類任務中，代理會拿到一個包含大量測試的程式碼庫，並被要求以特定方式刪除程式碼與檔案，使程式碼庫在移除特定可測試功能的同時，仍能維持正常運作。合成任務則是重新實作該功能，而這些測試會作為可驗證的 reward。
大規模建立合成任務的一個連帶後果，是可能導致出乎意料的 reward hacking。隨著模型愈來愈擅長這類任務，Composer 2.5 也越來越能找出更精巧的 workaround 來完成眼前的任務。在其中一個例子中，模型找到殘留的 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 模型上，optimizer step 時間為 0.2 秒。
這也和我們如何將 HSDP 用於 MoE 模型密切相關。HSDP 會建立多個 FSDP 複本，並在對應分片之間對梯度執行 all-reduce。我們對非 expert 權重與 expert 權重使用不同的 HSDP 版面配置：非 expert 權重相對較小，因此其 FSDP 群組可以維持較窄，通常侷限於單一節點或機架內；而 expert 權重承載了大多數參數與大部分 Muon 運算，因此會使用更寬的 expert 分片網格。
將這些版面配置分開，也能讓彼此獨立的並行能力維度互相重疊：CP=2 和 EP=8 可在 8 個 GPU 上執行，而不是在單一共享網格中需要 16 個 GPU。這可避免小型非 expert 狀態進行大範圍通訊，同時將 expert 優化器工作分散到多個 GPU 上。
試用 Composer 2.5
Composer 2.5 的定價為每百萬輸入 tokens 2.50。
另外還有一個具備同等智慧、速度更快的變體，定價為每百萬輸入 tokens 15.00，成本低於其他尖端模型的快速方案。與 Composer 2 類似，fast 是預設選項。完整資訊請參閱我們的模型文件。
Composer 2.5 在首週提供雙倍用量。
