做集成开发环境起家的 JetBrains，最近干了一件耐人寻味的事。他们把自研代码模型升级到了 Mellum2.1，并以 Apache 2.0 协议彻底开源。最抓人眼球的不是它宣称的 12B 总参数、每 token 仅激活 2.5B 的 MoE 混合专家架构，而是其软件工程基准测试成绩：在没有动底座架构分毫的前提下，SWE-bench Verified 的解题率从上一代 Thinking 版本的 2.0% 直接飙到了 47.0%。
这种几十倍的涨幅在模型迭代中极不寻常。通常参数量不变意味着能力上限大致封死，但 JetBrains 换了一条路：他们不再把精力耗在千亿参数的规模竞赛上，而是把一个原本只能单行补全的代码小模型，直接扔进数千个真实代码仓库和数百万次沙盒环境里，用强化学习（RL）硬生生训成了一个懂终端交互、会改文件、能根据测试报错自行纠偏的执行型智能体。
+-------------------------------------------------------------------------+
| Mellum2.1 核心架构与工程指标全景 |
+-------------------------------------------------------------------------+
| 总参数规模：12B MoE (28 层，64 专家) 激活参数：2.5B (每次激活 8 专家) |
| 上下文窗口：131,072 Tokens 开源协议：Apache 2.0 |
| 单次请求加速：约 1.6 倍 (MTP 机制) 单张 H200 吞吐：接近 Qwen3.5-9B 两倍 |
+-------------------------------------------------------------------------+架构未动，成绩从 2% 飙到 47% 的秘密
Mellum2.1 沿用了 Mellum2 的硬件骨架：12B 总参数、28 层、64 个专家中激活 8 个的 MoE 结构，上下文窗口达 131,072 token。底层配置一个字没改，它的能力跃升完全来自后训练阶段的方法论变革。
过去的代码模型训练主要吃高质量文本和语法补全，面对现实工程时往往眼高手低。JetBrains 依靠老牌工具链积累，搭建了覆盖数千个真实代码工程的沙盒环境。在强化学习阶段，模型必须亲自在 Shell 终端执行指令、调用工具编辑真实文件，并以测试用例是否通过作为最硬核的奖励信号。经历了数百万次沙盒运行后，模型掌握了软件工程师最底层的本能：报错了看堆栈、改坏了看 diff、改完跑测试。
这种对齐手段的效果极其立竿见影。除了 SWE-bench Verified 达到 47.0%，工程难度更高的 SWE-bench Pro 也从 0.0% 拔高到了 28.0%，用于衡量命令行操作能力的 Terminal-Bench 2.1 从 0.6% 跃升至 17.4%。在单轮代码能力与工具调用基准上，它同样表现强悍：LiveCodeBench v6 达到 82.0%，高于 Qwen3.5-9B 的 75.4%；BFCL v4 工具调用得分 62.3%，高于后者的 58.5%。
但跑分狂飙的背后需要保持冷静。SWE-bench 的表现高度受制于具体的评测脚手架（例如 Pi v0.73.1）、补丁策略和轮次预算。若拿它去碰头部顶尖模型，天花板依旧明显：SWE-bench Verified 的 47.0% 虽然逼近了 Qwen3.5-9B 的 50.0%，但面对 DeepSeek-V3.2-Exp 的 67.8% 以及 Qwen3-Coder-Next 的 70.6%–71.3%，依然存在一道参数与逻辑容量筑成的硬鸿沟。
- 结论.通过真实环境执行而非静态语料刷题，中轻量模型完全可以对齐出成熟的工程行为，但在多分支、复杂决策的长程任务上，小模型的认知深度仍有物理上限。
显存墙与量化折损：端侧部署的认知落差
不少人听到每 token 仅激活 2.5B 参数，便下意识认为轻薄本或普通消费级显卡可以无压力常驻。这恰恰是 MoE 架构最容易让人产生的误区：计算轻量化不等于显存轻量化。
无论每次参与推算的专家有多小，MoE 的 64 个专家权重全部必须加载进显存。Mellum2.1 的 BF16 完整权重达到 24.3 GB，官方和开源社区给出的最低显存基线是 24GB。若换用 Q4_K_M 格式量化，权重可压至 8.1 GB；MXFP4 格式约为 7.0 GB。但显卡里除了权重，还有暴涨的 KV Cache。若真要把 131K 上下文拉满，消费级单卡会瞬间遭遇内存溢出（OOM）。
更现实的工程阻力在于推理栈的适配。官方引入了多 Token 预测（MTP）功能，让单次请求推理速度提升了约 1.6 倍，在单张 H200 满载时吞吐量接近 Qwen3.5-9B 的两倍。但初期 MTP 权重在主流开源推理框架中的原生集成仍在过渡期。社区测试显示低比特量化（如 MXFP4）导致模型推理稳定性出现明显下滑，且 Thinking 版本的工具解析容错率不如 Instruct 稳健。在本地部署时，若想兼顾吞吐与准确度，把上下文控制在 16K–32K 才是实际可用的甜点区间。
- 提醒.不要被 2.5B 激活参数误导，12B 的常驻权重加上长上下文的显存开销依然是实打实的硬约束，盲目上极低量化只会毁掉来之不易的指令遵循率。
它不是指挥官，而是多智能体体系里的执行工蜂
看懂了这些指标与限制，Mellum2.1 的真实价值反而清晰了：它从来不是为了取代云端数百亿乃至上千亿参数的模型。
不要在小模型里寻找全知全能的架构师，工程最稀缺的是不知疲倦的泥瓦匠。
在当下的软件工程智能体系统里，最大的痛点是交互成本与推理延迟。让云端旗舰模型频繁去读几十个小文件的内容、反复调用 Shell 检查编译错误，既昂贵又迟钝。JetBrains 深知自身 IDE 生态需要什么样的常驻工具：他们不需要模型能写出一套复杂的大型分布式架构，而是需要一个响应快、成本极低、执行指令不走形的背景劳动力。
| 评估维度 | Mellum2.1 (MoE 12B/2.5B) | Qwen3.5-9B (Dense 9B) | 旗舰级模型 (如 DeepSeek-V3.2-Exp) |
|---|---|---|---|
| 激活参数与硬件开销 | 激活 2.5B / 总权重 24.3GB | 全量 9B / 显存开销中等 | 全量数百 B / 需多卡或云端 API |
| 单轮生成 (LiveCodeBench v6) | 82.0% | 75.4% | 极高水准 |
| 工具调用 (BFCL v4) | 62.3% | 58.5% | 极高水准 |
| 复杂工程 (SWE-bench Verified) | 47.0% | 50.0% | 67.8%（Qwen3-Coder-Next 达 71.3%） |
| 推理吞吐表现 | 单张 H200 接近竞品 2 倍 | 标准基准吞吐 | 依赖云端调度，单请求延迟长 |
| 最适部署角色 | 本地/私有子任务执行者 (Worker) | 本地综合辅助编码 | 全局规划大脑与复杂 Bug 攻坚 |
借助 1.6 倍 MTP 加速和 MoE 带来的高吞吐，Mellum2.1 恰恰卡死在执行型子智能体（Worker Sub-agent）的岗位上。主控大脑负责把需求拆解成具体的代码巡检、局部重构或单测生成，随后把高频的终端交互和文件改写全部甩给 Mellum2.1。即使在单张显卡或私有集群上，它也能以极低算力消耗并发处理大量此类杂活。
这也是老牌软件工具厂商在开源浪潮中摸索出的差异化打法。它没有跟着行业陷入堆参数的虚假繁荣，而是把自身最熟悉的测试驱动开发搬进沙盒，把 12B 的模型磨成了一把轻量却极度耐磨的手术刀。真正的生产力落地，往往就发生在这样剥离了概念神话、回归工程妥协的细节之中。