Mellum2.1 發表：2.5B 活躍參數，本機 coding 代理能接班嗎？（2026）

2026 年 10 月 8 日，JetBrains 的 Bulat Salimzianov 在官方部落格發布了〈Mellum2.1 Gets to Work: A Fast Open Model for Coding Agents〉。Mellum2.1 的重點，是讓一個可自行部署的模型更會在程式專案裡找線索、改檔案、驗修改。真正值得追問的是：速度與開放權重，能否換來你願意交付的本機工作？

下面先看這次訓練改了什麼，再對照模型卡與原始測試，最後判斷哪些工作適合交給它。先留一條界線：能呼叫工具、能跑完一次任務、能長期可靠交付，是三個不同的門檻。

Mellum2.1 的改變：把訓練放進工作的回合裡

What has changed is everything that happens after pre-training.

中文：改變的是預訓練之後的整個階段。

JetBrains／Mellum2.1 發布文章

原文的主張很集中：架構延續 Mellum2，這次主要增加後訓練，尤其是強化學習。JetBrains 表示，它把軟體工程任務放進真實 repository 與隔離環境，也加入數學、程式競賽、科學及工具使用資料，並過濾難以驗答案或測試有問題的題目。數百萬次沙盒執行是公司的訓練規模說明，不能直接當成完成率。

這和單純補完下一行程式有不同要求。修一個失敗測試，助手需要先找相關檔案，讀錯誤訊息，提出修改，接到新測試結果後再決定下一步。每一回合都可能走錯路；練習如何利用環境回饋，比只讓最後一段答案像正確程式更貼近工作。官方模型卡 說明軟體工程訓練以測試通過作為獎勵。

但獎勵怎麼定義，就決定它在優化什麼。測試覆蓋不到的需求、專案風格與相容性，仍需要額外驗收。你可以把「通過測試」當作一張收據，再問它到底覆蓋了哪些承諾。理解這層分工，可先讀 Agent Harness 原理。

Mellum2.1 跑分：相較前代躍升，並非每一欄都領先

下表從 模型卡 Evaluation 選出三個代理任務指標，單位為百分比。JetBrains 在同一 Pi v0.73.1 執行框架、shell 與檔案工具、114K 上下文及每回合最多 16K tokens 下比較，採各模型預設取樣，Mellum2.1 的 temperature 為 1.0。這是廠商同管線評測，不是 AlphaLab 重現或第三方認證。

指標	Mellum2.1	Mellum2	Qwen3.5-9B
SWE-bench Verified	47.0	2.0	50.0
Terminal-Bench 2.1	17.4	0.6	21.7
SWE-bench Pro	28.0	0.0	38.0

這組數字支持「代理能力比前代更值得試」，也顯示同場 Qwen 的三欄較高。把 47% 除以 2% 做成巨大倍數，容易放大低基期；讀者更需要知道，在這套條件下尚有多少任務未解決。不同榜單使用不同 Agent、預算與工具，不能只把模型名與分數搬到一起排名。

SWE-bench 官方介紹 將 Verified 定義為經人工篩選的 500 個問題，並區分不同系統與執行框架的比較。它驗的是特定程式問題與測試；47% 不是「任意公司專案有 47% 機率自動修好」，更不是開發者生產力增加 47%。

同一模型卡也有不同方向的變化，例如 WorkBench 從前代的 45.1 變成 44.6。因此，原文對整體提升的樂觀敘述，要和逐欄結果一起讀。對需要某一種工具的讀者，該工具流程的失敗率，比跨題型平均印象更有用。

速度圖最該讀的，是上面的測試條件

圖中 Mellum2.1 的單請求輸出由 339 tokens/s 增至啟用 MTP 後的 557，約 1.64 倍；右側飽和服務吞吐量則由 7,969 增至 8,533。這是兩種負載。原文「接近 Qwen 兩倍」說的是重負載吞吐量，不能拿來預測你筆電上一個任務的完成時間。

MTP（multi-token prediction，多 token 預測）在這裡用於推測解碼：先提出候選，再由模型驗證，藉此加快生成。圖中的 Gemma 加 drafter 單請求值 607，也高於 Mellum 加 MTP 的 557；「最快」必須保留是哪一組負載、哪一種指標的限定。本文把這張圖視為 JetBrains 的硬體與工作負載測量。

一次修補還包括讀檔、搜尋、執行測試、等程序結束，以及失敗後重試。假設生成快一倍，測試仍要等同樣久，整個任務就不會自動快一倍。你應記錄「開始到合格 diff 出現」的時間，並把未完成的跑次一起算進去。這也是 AI Evals 入門 最值得先定義的完成條件。

2.5B 活躍參數，為何不等於 2.5B 模型的記憶體？

模型卡與 公開配置 列出 12B 總參數、2.5B 活躍參數、64 個專家，每 token 選 8 個，以及 131,072 tokens 的上下文上限。MoE（混合專家）像把工作分配給不同小組；這次只讓部分小組計算，不表示其他小組的權重從模型裡消失。

截至 2026 年 10 月 10 日，JetBrains 官方 GGUF 倉庫 已提供檔案：BF16 約 24.3 GB、Q8_0 約 12.9 GB、Q4_K_M 約 8.1 GB。這修正了發布文章仍寫「coming soon」的 GGUF 狀態。檔案大小不是整個程序的記憶體需求；上下文快取、工作緩衝與執行後端也會占用容量，能否順暢執行要用實際設定量。

同樣地，131K 是可配置的窗口，並不是每種硬體都適合直接開滿，也不是長文理解品質保證。先用任務需要的短窗口，再逐步增加；把後端、量化、提示長度與記憶體峰值一起保存。已有 Intel Arc 的讀者，可以接著看 本機推論後端與 GPU 驗收，但不要把另一款模型的量測當成 Mellum 的成績。

早期使用者測試：適合找問題，尚不足以替所有專案下結論

在 r/LocalLLaMA 的原始測試貼文，u/SoAp9035 描述用 Q8、Pi 與 llama-server 在本機做五個一次生成任務：三題結果較差，一題物理行為尚可卻做成終端版本，Flappy Bird 完成但視覺簡單且難度偏高。他也回報一次工具呼叫失敗後停止，以及另一個既有遊戲的跳躍高度修改成功。

這些是作者的觀察，不是受控盲測。貼文未在這段紀錄提供完整 GPU 型號、所有提示、版本與重跑分布，因此本文不採它的速度值作為購機或部署預估，也不把單次失敗推論成模型普遍無法用工具。一次生成完整遊戲與在既有 repository 修改單一參數，本來就有不同難度與驗收方式。

它仍提供有價值的方向：把「從空白做一切」和「在清楚邊界裡改一件事」分開測。下一份更有說服力的證據，會包含可重跑提示、完整工具軌跡、同一驗收與多次失敗紀錄。公開票數是發現線索，本文不把它當模型品質。

AlphaLab 的判讀：本機工作者的價值，在邊界與退路

一、我同意：可以自行部署，讓小工作更容易試

Apache 2.0 權重讓團隊有自行部署與調整的空間。對已具備硬體與維運能力的人，檔案定位、錯誤訊息整理、有限範圍修補，是合理的候選。這是用途判斷，實際採用要看你自己的成果。開放權重的價值，是把選擇權交還給部署者；硬體、供電與維護時間仍需計入。

二、我存疑：低活躍參數就等於低總成本

一次便宜的錯修，可能讓主代理重讀專案、讓人重查差異，再多跑一次測試。比較時用「所有嘗試的運算與人力成本／通過驗收的成果數」，並另列延遲。若只看 tokens/s，生成更多無用內容也會被算成進步。Haiku 小模型分工分析 從 API 價格談同一問題；Mellum 則增加本機資源與維運這張帳。

三、本機推論的資料邊界，還要看工具往哪裡走

把模型放在本機，能讓推論路徑留在你控制的環境；若 Agent 的搜尋、遙測、遠端模型備援或工具輸出外送，仍會形成其他資料路徑。這是部署設計的條件推論，不是對 Mellum 本身外送行為的指控。先畫清楚讀檔、模型、工具與日誌的流向，私有部署才有可核對的意義。

四、測試綠燈，要連回需求與允許動作

小模型可以提出補丁；系統負責限制能改的檔案、能跑的程序、重試次數與停止出口。驗收時同時看功能測試、diff 是否超出範圍，以及原本的成功行為是否保留。只把模型換成更強版本，不會替你補上這些規則。Agent 回歸測試 能幫你把成果與執行過程放在同一份驗收裡。

下一步：先交一張窄工單，保留完整失敗紀錄

先選一個你有權使用、已有答案的小專案，給出單一任務，例如修一個已知失敗測試。固定模型檔案與雜湊、量化、後端、工具模板、上下文、取樣與時間上限；讓 Mellum2.1 和現有方案面對相同起始 commit，保存每次提示、工具回傳、修改與測試結果。這是建議的評估設計，本次沒有下載大型模型或執行本機推論。

先驗讀檔與一個無副作用工具能否往返，再驗修改、測試與失敗後停止。官方 vLLM 設定 明列 qwen3 推理解析器、hermes 工具解析器與自動工具選擇；vLLM 工具文件 也區分模板、解析與參數約束。收到一句「我要跑測試」，和程序真的收到有效工具呼叫，是不同證據。

原文最後邀請開發者試用並回報，最值得對帳的就是：它能否在你的 repository 裡交出正確、可審查、成本合理的修改。先跑同一小批任務，報通過率、完整完成時間、重試與人力介入；遇到越權修改、連續失敗或無法解析的工具回傳，就停回既有流程。