同一天，國內(nèi)大模型廠商扎堆發(fā)起了新模型。

AI「六小龍」中的 MiniMax 和月之暗面各自公布了開源新成果。

其中，MiniMax 啟動(dòng)了「MiniMax Week」，并在第一天開源了其最新的長上下文推理 LLM——MiniMax-M1。該模型支持全球最長的上下文窗口，包括 100 萬 tokens 輸入、8 萬 tokens 輸出。

不僅如此，MiniMax-M1 還實(shí)現(xiàn)了開源模型中最強(qiáng)的智能體工具使用能力。強(qiáng)化學(xué)習(xí)效率也驚人，僅僅需要 53.47 萬美元即可完成訓(xùn)練。

目前，MiniMax-M1 已經(jīng)集成到了 MiniMax Chat 中。

如此強(qiáng)大的 MiniMax-M1 有哪些亮點(diǎn)功能呢？首先，它支持 UI 組件聚焦（Spotlight），只需輸入提示詞，立即就可以構(gòu)建一個(gè)具有基于畫布的動(dòng)畫粒子背景的 HTML 頁面。

其次，MiniMax-M1 支持交互式應(yīng)用程序。比如要求它構(gòu)建一個(gè)打字速度測試，很快就生成一個(gè)干凈、實(shí)用的 Web 應(yīng)用程序，可以實(shí)時(shí)跟蹤 WPM（每分鐘字?jǐn)?shù)）。不需要插件，也不需要設(shè)置。

此外，MiniMax-M1 的可視化效果很強(qiáng)。比如輸入提示詞：創(chuàng)建具有基于畫布的動(dòng)畫粒子背景的 HTML 頁面，顆粒應(yīng)平穩(wěn)移動(dòng)并在靠近時(shí)連接，在畫布上添加中心標(biāo)題文本。（Create an HTML page with a canvas-based animated particle background. The particles should move smoothly and connect when close. Add a central heading text over the canvas.）

最后，MiniMax-M1 可以玩游戲。比如輸入提示詞：創(chuàng)建迷宮生成器和尋路可視化工具，隨機(jī)生成一個(gè)迷宮，并可視化 A * 算法逐步解決它。使用畫布和動(dòng)畫，使其具有視覺吸引力。（Create a maze generator and pathfinding visualizer. Randomly generate a maze and visualize A* algorithm solving it step by step. Use canvas and animations. Make it visually appealing.）

評論區(qū)的網(wǎng)友對 MiniMax-M1 也是翹首以盼，如今終于放出來了。

與此同時(shí)，月之暗面發(fā)布了強(qiáng)大的開源編程大模型 ——Kimi-Dev-72B。

在所有開源模型中，Kimi-Dev-72B 在代碼生成評估基準(zhǔn) SWE-bench Verified 中取得了全新的 SOTA 分?jǐn)?shù)。

目前，Kimi-Dev-72B 已向社區(qū)開放，以供進(jìn)一步研發(fā)，主要資源包括了模型權(quán)重、源代碼和技術(shù)報(bào)告（即將發(fā)布）。月之暗面希望開發(fā)者和組織能夠探索、集成和擴(kuò)展該模型的應(yīng)用。

• Hugging Face 地址：https://huggingface.co/moonshotai/Kimi-Dev-72B
• GitHub 地址：https://github.com/MoonshotAI/Kimi-Dev
• 博客地址：https://moonshotai.github.io/Kimi-Dev/

面對同一天發(fā)布的這兩個(gè)大模型，已經(jīng)有人進(jìn)行了代碼實(shí)測 PK。

一位推特用戶使用 three.js 生成拆煙囪 demo，結(jié)果顯示，MiniMax-M1-80K 一把過，而 Kimi-Dev-72B 生成的代碼需要使用 Claude-4-Sonnet 修復(fù) 3 個(gè) bug 才能運(yùn)行。

圖源：https://x.com/karminski3/status/1934791130165727445

我們接下來介紹兩款開源大模型的技術(shù)細(xì)節(jié)。

MiniMax-M1

• Hugging Face：https://huggingface.co/collections/MiniMaxAI/minimax-m1-68502ad9634ec0eeac8cf094
• GitHub 地址：https://github.com/MiniMax-AI/MiniMax-M1
• 技術(shù)報(bào)告：https://github.com/MiniMax-AI/MiniMax-M1/blob/main/MiniMax_M1_tech_report.pdf
• 體驗(yàn)地址：https://chat.minimax.io/

MiniMax-M1 是全球首款開源權(quán)重的大規(guī)模混合注意力推理模型，由混合專家（MoE）架構(gòu)與閃電注意力機(jī)制共同驅(qū)動(dòng)。該模型基于此前的 MiniMax-Text-01 模型開發(fā)而來，總參數(shù)量為 456 B，每個(gè) token 激活 45.9 B 參數(shù)。

與 MiniMax-Text-01 一致，M1 模型原生支持 100 萬 token 的上下文長度，是 DeepSeek R1 上下文規(guī)模的 8 倍。

此外，MiniMax-M1 中采用的閃電注意力機(jī)制實(shí)現(xiàn)了測試時(shí)計(jì)算成本的高效擴(kuò)展 —— 例如，在生成長度為 10 萬 token 時(shí)，M1 所消耗的浮點(diǎn)運(yùn)算次數(shù)（FLOPs）僅為 DeepSeek R1 的 25%。這些特性使得 M1 尤其適用于需要處理長輸入并進(jìn)行深度思考的復(fù)雜任務(wù)。

MiniMax-M1 在從傳統(tǒng)數(shù)學(xué)推理到基于沙盒的真實(shí)世界軟件工程環(huán)境等各種問題上，均采用了大規(guī)模強(qiáng)化學(xué)習(xí)（RL）進(jìn)行訓(xùn)練。MiniMax 為 M1 開發(fā)了一個(gè)高效的強(qiáng)化學(xué)習(xí)擴(kuò)展框架，重點(diǎn)突出以下兩個(gè)方面：

1. 提出了一種名為 CISPO 的新穎算法，該算法通過裁剪重要性采樣權(quán)重而非 token 更新來優(yōu)化模型。 在 AIME 的實(shí)驗(yàn)中，研究團(tuán)隊(duì)發(fā)現(xiàn)這比包括字節(jié)近期提出的 DAPO 等強(qiáng)化學(xué)習(xí)算法收斂性能快了一倍，顯著的優(yōu)于 DeepSeek 早期使用的 GRPO。

2. MiniMax 的混合注意力設(shè)計(jì)天然地提升了強(qiáng)化學(xué)習(xí)的效率，在此過程中，解決了在混合架構(gòu)下擴(kuò)展強(qiáng)化學(xué)習(xí)時(shí)遇到的獨(dú)特挑戰(zhàn)。

整個(gè)強(qiáng)化學(xué)習(xí)階段只用到 512 塊 H800 三周的時(shí)間，租賃成本只有 53.47 萬美金，這比一開始的預(yù)期少了一個(gè)數(shù)量級。MiniMax 訓(xùn)練了兩個(gè)版本的 MiniMax-M1 模型，分別具有 40k 和 80k 的思考預(yù)算。

在標(biāo)準(zhǔn)基準(zhǔn)測試上的實(shí)驗(yàn)表明，該模型在性能上超越了其他強(qiáng)大的開源權(quán)重模型，如原始的 DeepSeek-R1 和 Qwen3-235B，尤其在復(fù)雜的軟件工程、工具使用和長上下文任務(wù)上表現(xiàn)突出。

對領(lǐng)先的商業(yè)模型與開源模型在競賽級數(shù)學(xué)、編程、軟件工程、智能體工具使用以及長上下文理解等任務(wù)中的基準(zhǔn)性能進(jìn)行對比評估。其中，MiniMax-M1 結(jié)果使用其 MiniMax-M1-80k 模型。

MiniMax 在 17 個(gè)業(yè)內(nèi)主流評測集上對 M1 模型進(jìn)行了全面評估，結(jié)果顯示，M1 在軟件工程、長上下文處理和工具使用等面向生產(chǎn)力的復(fù)雜場景中，擁有顯著優(yōu)勢。

• MiniMax-M1-40k 和 MiniMax-M1-80k 在 SWE-bench 驗(yàn)證基準(zhǔn)上分別取得 55.6% 和 56.0% 的優(yōu)異成績，這一成績略遜于 DeepSeek-R1-0528 的 57.6%，但顯著超越其他開源權(quán)重模型。
• 依托其百萬級上下文窗口，M1 系列在長上下文理解任務(wù)中表現(xiàn)卓越，不僅全面超越所有開源權(quán)重模型，甚至超越 OpenAI o3 和 Claude 4 Opus，全球排名第二，僅以微弱差距落后于 Gemini 2.5 Pro。
• 在代理工具使用場景（TAU-bench）中，MiniMax-M1-40k 同樣領(lǐng)跑所有開源權(quán)重模型，并戰(zhàn)勝 Gemini-2.5 Pro。

值得注意的是，MiniMax-M1-80k 在大多數(shù)基準(zhǔn)測試中始終優(yōu)于 MiniMax-M1-40k，這充分驗(yàn)證了擴(kuò)展測試時(shí)計(jì)算資源的有效性。

 MiniMax 還采取了極具誠意的開放策略：新模型在 MiniMax APP 和 Web 上都保持不限量免費(fèi)使用，并以業(yè)內(nèi)最低的價(jià)格在官網(wǎng)提供 API。

前面兩種模式都比 DeepSeek-R1 性價(jià)比更高，后面一種模式 DeepSeek 模型不支持。

 發(fā)布 M1 只是一個(gè)開始。據(jù) MiniMax 透露，在接下來的數(shù)個(gè)工作日內(nèi)，還將公布一系列令人期待的技術(shù)更新，敬請關(guān)注。 

Kimi-Dev-72B

作為一個(gè)強(qiáng)大的開源 LLM，Kimi-Dev-72B 具有以下亮點(diǎn)：

• Kimi-Dev-72B 在 SWE-bench Verified 上取得了 60.4% 的成績，在開源模型中創(chuàng)下了新的 SOTA 紀(jì)錄。
• Kimi-Dev-72B 通過大規(guī)模強(qiáng)化學(xué)習(xí)進(jìn)行優(yōu)化。它能夠自主在 Docker 中修補(bǔ)真實(shí)代碼倉庫，并且只有在整個(gè)測試套件通過的情況下才會獲得獎(jiǎng)勵(lì)。這確保了其提供的解決方案是正確且穩(wěn)健的，符合現(xiàn)實(shí)世界中的開發(fā)標(biāo)準(zhǔn)。
• Kimi-Dev-72B 可在 Hugging Face 和 GitHub 上下載和部署。

下圖為 SWE-bench Verified 基準(zhǔn)上，Kimi-Dev-72B 與其他開源模型的性能比較。

下圖為 SWE-bench Verified 基準(zhǔn)上，Kimi-Dev-72B 與閉源模型的性能比較。

以下是 Kimi-Dev-72B 的設(shè)計(jì)理念與技術(shù)細(xì)節(jié)，包括 BugFixer 與 TestWriter 的協(xié)作機(jī)制、中期訓(xùn)練、強(qiáng)化學(xué)習(xí)以及測試階段自博弈等內(nèi)容。

BugFixer 與 TestWriter 的協(xié)作機(jī)制

一個(gè)成功的漏洞修復(fù)補(bǔ)丁，應(yīng)該能夠通過準(zhǔn)確反映該漏洞的單元測試。同時(shí)，一個(gè)成功的測試用例在復(fù)現(xiàn)漏洞時(shí)應(yīng)能觸發(fā)斷言錯(cuò)誤，并且在正確的補(bǔ)丁應(yīng)用到代碼庫后能夠通過測試。這就形成了 BugFixer 和 TestWriter 的互補(bǔ)角色：BugFixer 負(fù)責(zé)修復(fù)問題，TestWriter 負(fù)責(zé)驗(yàn)證和復(fù)現(xiàn)問題。一個(gè)足夠強(qiáng)大的編程 LLM 應(yīng)當(dāng)在這兩方面都表現(xiàn)出色。

BugFixer 和 TestWriter 遵循著相似的流程：它們都需要先找到正確的待編輯文件，然后執(zhí)行相應(yīng)的代碼更新 —— 無論是修正脆弱的代碼實(shí)現(xiàn)（BugFixer 的任務(wù)），還是插入單元測試函數(shù)（TestWriter 的任務(wù)）。

因此，為了同時(shí)支持這兩個(gè)角色，Kimi-Dev-72B 采用了一個(gè)統(tǒng)一的極簡框架，該框架僅包含兩個(gè)階段：(1) 文件定位 (File Localization) 和 (2) 代碼編輯 (Code Edits)。BugFixer 與 TestWriter 的這種協(xié)作機(jī)制的設(shè)計(jì)，為 Kimi-Dev-72B 的整體架構(gòu)奠定了基礎(chǔ)

中期訓(xùn)練 

為了提升 Kimi-Dev-72B 作為 BugFixer 和 TestWriter 的基礎(chǔ)能力，使用了約 1500 億個(gè) token 的高質(zhì)量真實(shí)世界數(shù)據(jù)對其進(jìn)行了中期訓(xùn)練。以 Qwen 2.5-72B 作為基礎(chǔ)模型，收集了數(shù)百萬個(gè) GitHub 上的問題報(bào)告 (issues) 和拉取請求中的代碼提交記錄 (PR commits) 作為中期訓(xùn)練數(shù)據(jù)集。

該數(shù)據(jù)配方經(jīng)過精心設(shè)計(jì)，旨在讓 Kimi-Dev-72B 學(xué)習(xí)人類開發(fā)者如何根據(jù) GitHub 問題進(jìn)行推理、構(gòu)建代碼修復(fù)方案以及編寫單元測試。此外還進(jìn)行了嚴(yán)格的數(shù)據(jù)去污染處理，以排除任何來自 SWE-bench Verified 測試集的代碼倉庫。

中期訓(xùn)練充分增強(qiáng)了基礎(chǔ)模型在實(shí)用性錯(cuò)誤修復(fù)和單元測試方面的知識，使其成為后續(xù)強(qiáng)化學(xué)習(xí)（RL）訓(xùn)練的更佳起點(diǎn)。

大規(guī)模強(qiáng)化學(xué)習(xí)

通過適當(dāng)?shù)闹衅谟?xùn)練和監(jiān)督微調(diào) (SFT)，Kimi-Dev-72B 在文件定位 (File Localization) 方面已取得了優(yōu)異的性能。因此，強(qiáng)化學(xué)習(xí) (RL) 階段專注于提升其代碼編輯 (Code Edits) 的能力。

月之暗面采用了一種在 Kimi k1.5 中描述過的策略優(yōu)化方法，該方法已在推理任務(wù)中展現(xiàn)出卓越成果。針對 SWE-bench Verified 測試基準(zhǔn)，重點(diǎn)介紹以下三項(xiàng)關(guān)鍵設(shè)計(jì)：

• 僅基于結(jié)果的獎(jiǎng)勵(lì)機(jī)制（Outcome-based Reward Only）。只采用 Docker 最終執(zhí)行結(jié)果（0 或 1）作為獎(jiǎng)勵(lì)信號，在訓(xùn)練過程中不使用任何基于格式或過程的獎(jiǎng)勵(lì)。這意味著，只有當(dāng)模型生成的補(bǔ)丁能夠使所有測試用例通過時(shí)，才會獲得獎(jiǎng)勵(lì)，從而確保模型關(guān)注于實(shí)際有效的代碼修復(fù)結(jié)果。
• 高效的提示集（Efficient Prompt Set）。過濾掉了模型在多樣本評估中成功率為零的提示（即過于困難的任務(wù)），從而能夠更有效地利用大批量數(shù)據(jù)進(jìn)行訓(xùn)練。同時(shí)應(yīng)用了課程學(xué)習(xí)策略，即逐步引入新提示，漸進(jìn)式地增加任務(wù)難度。
• 正面范例強(qiáng)化（Positive Example Reinforcement）。在訓(xùn)練的最后階段，將先前迭代中近期成功的樣本重新加入到當(dāng)前的訓(xùn)練批次中。這有助于模型鞏固成功的模式并提升性能。

Kimi-Dev-72B 通過使用高度并行、強(qiáng)大且高效的內(nèi)部智能體基礎(chǔ)設(shè)施，從可擴(kuò)展數(shù)量的問題解決任務(wù)訓(xùn)練中受益匪淺。

測試時(shí)自博弈（Test-time Self-Play）

經(jīng)過強(qiáng)化學(xué)習(xí)后，Kimi-Dev-72B 能夠同時(shí)掌握 BugFixer 和 TestWriter 的角色。在測試過程中，該模型會采用自博弈機(jī)制，協(xié)調(diào)自身 Bug 修復(fù)和測試編寫的能力。

BugFixer 和 TestWriter 之間的測試時(shí) self-play。

每個(gè)問題最多可以生成 40 個(gè)補(bǔ)丁候選和 40 個(gè)測試候選（按照標(biāo)準(zhǔn) Agentless 設(shè)置），可以觀察到測試時(shí)自博弈的擴(kuò)展效應(yīng)。

下一步計(jì)劃

最后，月之暗面表示，他們正在積極研究和開發(fā)擴(kuò)展 Kimi-Dev-72B 功能的方法，并探索更復(fù)雜的軟件工程任務(wù)。未來的迭代將側(cè)重于與流行的 IDE、版本控制系統(tǒng)以及 CI/CD 流水線進(jìn)行更深入的集成，使 Kimi-Dev-72B 更加無縫地融入開發(fā)人員的工作流程。

在持續(xù)改進(jìn) Kimi-Dev-72B 的同時(shí)，月之暗面還將進(jìn)行嚴(yán)謹(jǐn)?shù)募t隊(duì)測試，并向社區(qū)發(fā)布更強(qiáng)大的模型。