摘要
2026 年 10 月 8 日,JetBrains 发布了其开源编码模型的下一代 Mellum2.1。规格上它几乎没有变化:仍是 12B 总参数、2.5B 激活参数的混合专家(MoE)模型,131K 上下文,Apache 2.0 许可。真正的变化发生在预训练之后——JetBrains 把强化学习(RL)从"收尾环节"提升为训练的主体,在数千个真实仓库、数百万个沙箱里让模型自己探索代码库、改文件、跑测试并根据结果获得奖励。结果是:SWE-bench Verified 从 2.0 暴涨到 47.0,LiveCodeBench v6 达到 82.0,在重负载下的吞吐量还是同组里最快的。它并不试图当"明星模型",而是被明确定位成一个能在你自己的硬件上跑的快速编码工作马与子代理。本文评测它的架构、基准、速度与真实定位。
事件背景
JetBrains 是 IntelliJ、PyCharm 等主流 IDE 的厂商,长期押注"模型不必都是巨无霸“这条路线。它把这类模型称为”focal model(焦点模型)"——不是要取代栈里的每一个模型,而是让整条技术栈更快、更便宜、更可控。2026 年 6 月,JetBrains 把 Mellum2 完全开源:一个刻意放弃多模态、专注软件工程工作流的 12B MoE 模型,靠 64 专家、每 Token 激活 8 个,把 12B 的容量压到 2.5B 的推理成本。
但 Mellum2 有一个明显短板:它快,却"进不了仓库"。它能做补全、路由、摘要,却无法真正完成"探索代码库 → 定位 bug → 改文件 → 自检"的代理式闭环。对自建编码代理的团队来说,这恰恰是最缺的能力。于是,Mellum2.1 的核心任务很明确:架构不动,把"能干活"这件事补上。
核心技术解析
技术架构
Mellum2.1 的架构与 Mellum2 完全一致——这本身就是本次发布最重要的信息点:提升不是靠堆参数,而是靠后训练。
- MoE 设计:64 个专家,每 Token 激活 8 个,总参数 12B、激活 2.5B,约等于一次前向只付出 2–3B 稠密模型的计算量。
- 层与注意力:28 层,采用分组查询注意力(32 个查询头、4 个 KV 头);每 4 层中有 3 层使用 1024 Token 的滑动窗口注意力,大幅压缩 KV Cache、提升长上下文下的显存效率。
- 上下文与词表:上下文长度 131,072 Token,词表 98,304,权重以 bfloat16 发布。
- 多 Token 预测(MTP)头:既用作预训练辅助目标,又充当投机解码的内置草稿模型。在 14B 代理模型的消融实验中,MTP 目标把 HumanEval pass@1 从 20.73 提升到 31.10(+10.4)。
关键创新点
1. 把 RL 变成训练主体。 Mellum2.1 几乎全部的工作量投在后训练上,RL 从"最后一个小阶段"变成了"训练的主要部分"。JetBrains 在数学、竞赛编程、科学、工具调用和软件工程上新增了大量 RL 任务,并对每一个数据源做严格过滤——开源 RL 数据常带坏测试、无法验证的答案,以及过易或不可能完成的任务,这些都在进入训练前被剔除。
2. 在真实环境里训练代理技能。 对软件工程任务,模型在真实仓库中训练,配备 shell 与文件编辑工具,以测试是否通过作为奖励。JetBrains 自建基础设施,内部同时运行数千个 RL 环境,整个训练过程启动了数百万个沙箱。
3. 明确的"工作马/子代理"定位。 它不追求取代 Claude Code 或前沿闭源模型,而是定位为编码代理系统中的快速子代理:负责根因分析、草拟并自检修复,把昂贵的前沿模型留给真正困难的规划。
下面这张图展示了 Mellum2.1 在真实仓库中的代理式 RL 闭环:
graph TD
A[真实代码仓库] --> B[模型探索代码库]
B --> C[定位失败测试根因]
C --> D[编辑文件]
D --> E[运行测试]
E --> F{测试通过?}
F -->|是| G[获得正奖励]
F -->|否| H[获得负奖励并回退]
G --> I[更新策略]
H --> I
I --> B
性能评测
JetBrains 用同一套评测流程(thinking 模式、Pi v0.73.1 代理框架、114K 上下文)对比了 Mellum2.1、Mellum2、Qwen3.5-9B 与 Gemma 4 E4B(分数为厂商自报):
| 基准 | Mellum2.1 | Mellum2 | Qwen3.5-9B | Gemma 4 E4B |
|---|---|---|---|---|
| SWE-bench Verified | 47.0 | 2.0 | 50.0 | — |
| SWE-bench Pro | 28.0 | 0.0 | 38.0 | — |
| Terminal-Bench 2.1 | 17.4 | 0.6 | 21.7 | — |
| LiveCodeBench v6 | 82.0 | — | 75.4 | 69.4 |
| HumanEval+ | 91.5 | — | — | — |
| MBPP+ | 79.4 | — | — | — |
| BFCL v4 | 62.3 | — | — | — |
| HarmBench(越低越好) | 8.5 | 21.5 | — | — |
几个关键结论:
- 代理能力的跃迁最惊人:SWE-bench Verified 从 2.0 到 47.0,说明"架构不变、RL 规模化"能带来质变。
- 它并非全面领先:在硬核代理软件任务上,Qwen3.5-9B 仍更强(SWE Verified 50.0、SWE Pro 38.0),在 AIME、GPQA Diamond 等知识与推理项上也是 Qwen 领先。
- 评测口径很重要:Qwen 官方卡上 LiveCodeBench v6 是 65.6、GPQA Diamond 是 81.7,而 JetBrains 自测同一模型为 75.4 与 77.8——不同 harness 会显著改变结论,跨厂商数字不宜直接横比。
行业影响
对市场的影响
Mellum2.1 代表了一类正在成型的产品形态:“够用且便宜"的专用小模型。当企业发现前沿模型的 Token 账单难以长期承受时,把高频、低难度的编码子任务下沉到自托管的小模型上,是很自然的成本优化路径。JetBrains 用一个开源模型补上了"能进仓库干活"这块拼图,会进一步推动大模型做规划、小模型做执行的混合架构普及。
对开发者的意义
对开发者最直接的价值是可自托管:把权重下载到自己的 GPU 上,用 vLLM 或 SGLang 部署,数据不必出内网,也没有按 Token 计费的持续成本。官方给出的最快启动方式是:
|
|
GGUF 构建从 7.0 GB 起,可跑在 llama.cpp、Ollama、LM Studio 上,MTP 头则用于 vLLM 的投机解码。对做编码代理、路由、RAG 摘要、IDE 补全的团队来说,这是一块可插拔、可控的组件。
商业化前景
开源是 JetBrains 的一贯策略:用开放权重扩大生态、反哺自家 IDE 与 AI 助手。它的商业闭环不在模型本身收费,而在于让更多团队把"跑在本地/私有云的小模型"纳入 JetBrains 的工具链,从而强化 IDE 与企业开发平台的粘性。
实际体验
使用场景演示
一个典型的私有化编码代理流程可以是这样的:团队自建一个代理系统,主规划交给前沿模型,把"找到失败测试的根因并草拟修复"这一步交给 Mellum2.1。因为它激活参数只有 2.5B,重负载下仍能保持高吞吐,很适合并发处理大量子任务(如批量修 lint、补单元测试、做小范围重构)。团队关掉所有外部 API 调用后,代码库数据完全不出内网。
速度表现
由于后训练没有改动架构,Mellum2.1 的推理速度和 Mellum2 一致。JetBrains 称,在单张 NVIDIA H200、重负载条件下,它服务的 Token 量接近 Qwen3.5-9B 的两倍;在单请求场景下,MTP 让速度再提升约 1.6 倍。对于延迟敏感的 IDE 内联补全与后台分析,这是决定体验的关键指标。
优势与不足
优势:
- 代理能力质变:SWE-bench Verified 从 2.0 到 47.0,补齐了 Mellum2 最大的短板;
- 极致轻量:2.5B 激活参数,可在自有 GPU 甚至消费级硬件上部署;
- 高吞吐:重负载下吞吐量接近同组最快,单请求靠 MTP 再提速约 1.6×;
- Apache 2.0 + 完全离线:无 API、无 Token 账单、数据不出内网;
- 安全指标改善:HarmBench 从 21.5 降到 8.5。
不足:
- 硬核代理任务仍逊于 Qwen3.5-9B:SWE Verified、SWE Pro、知识与推理项均落后;
- 放弃多模态:不接受图像/音频输入,界面截图类任务不适用;
- 自报分数:全部基准由厂商自测,缺乏第三方复现;
- 生态仍在补齐:GGUF/Ollama/LM Studio 与 MTP 头部分仍标注"coming soon”。
总结与展望
Mellum2.1 最大的启示不是某个分数,而是它证明的路径:当一个架构够好时,把强化学习从"收尾"提到"主体",就能在参数量不变的前提下,把一个"快但无能"的模型变成"能进仓库干活"的代理。它坦诚地不接受"最强"的头衔,而是把自己定位成代理系统里那颗又快又便宜的螺丝钉。
展望未来,编码 AI 的竞争很可能分成两层:前沿闭源模型负责高难规划,开源小模型负责高频执行。Mellum2.1 是后一层里一个很有代表性的样本。对开发者而言,真正该做的是在自己的代理框架与业务数据上重新跑一遍基准——毕竟,不同的 harness 之间,结论可能天差地别。
参考来源: