编程智能体每天要干的活里，有一大半压根不需要旗舰模型。读一遍文件、总结一段改动、决定先跑哪个测试、写一句提交信息、改三行代码、把报错贴回去再试一次。
这些调用一个都不难，但加起来的账单比大多数人以为的贵得多。
十月八日，JetBrains 在 Hugging Face 上放出了 Mellum 2.1，模型名 JetBrains/Mellum2.1-12B-A2.5B-Thinking，Apache 2.0 协议，可以商用。它冲的就是上面这部分活。
架构一个字母没改，动的全是训练方式
先把”新”这个字说清楚。
Mellum 这个系列 2026 年六月就已经开源过一次，骨架那时候就定下来了：一百二十亿总参数，走混合专家（MoE）路线，每次推理只激活二十五亿。 具体是六十四位专家里挑八位干活，二十八个层，分组查询注意力（三十二个查询头配四个键值头），上下文窗口十三万一千零七十二个 token，每四层里有三层挂了一千零二十四个 token 的滑动窗口，词表九万八千三百零四。
JetBrains 的研究员在发布说明里那句话很直白：「架构从 2 版起就没变过。」
那 2.1 改了什么？事后训练。 他们把强化学习从一个短暂的收尾环节，提到了训练的主线位置：模型在真实仓库里跑，自己读写文件、执行命令，测试通过就得分。官方说法是训练期间跑了「数百万次沙箱运行，覆盖数千个环境」，任务来源既有公开的强化学习数据集，也有内部现做的题，每一份都先过滤过——因为公开数据里经常带着跑不通的测试和没法验证的答案。
这个方向的转变很关键，也解释了后面那组夸张的跑分差。
跑分：修真实 bug 从 2% 跳到 47%
JetBrains 自己给出的数字是这样的：
- SWE-bench Verified（修真实 GitHub issue）：47.0，上一版是 2.0
- SWE-bench Pro（更难的缺陷修复）：28.0，上一版是 0.0
- Terminal-Bench 2.1（命令行任务）：17.4，上一版是 0.6
- LiveCodeBench v6（编程竞赛题）：82.0
- HumanEval+（代码生成）：91.5
- AIME 25/26（数学）：83.3
- GPQA Diamond（硬科学问答）：64.6
- BFCL v4（函数与工具调用）：62.3
数字很漂亮，但有三处必须一起看。
第一，这些全是 JetBrains 自测，外部还没有人复现过。 发布说明里明说了。
第二，也是最该注意的一条：阿里 Qwen3.5-9B 在更贴近日常工作的项目上仍然在前头。 同一张对比表里，Qwen3.5-9B 的 SWE-bench Verified 是 50.0、SWE-bench Pro 是 38.0、Terminal-Bench 2.1 是 21.7、GPQA Diamond 是 77.8。Mellum 2.1 赢的是另外两块：编程题 82.0 对 75.4，工具调用 62.3 对 58.5。
翻译一下：拼手速的题它更稳，进真实代码库里改活它还没赢。
第三，评测口径值得单独记一笔。所有模型都跑在同一套开源 Agent 骨架里（Pi v0.73.1，带 shell 和文件编辑工具），上下文 11.4 万 token，每轮最多输出 1.6 万 token。JetBrains 把口径写清楚这件事是加分项，但它同时也说明了一件事：这类跑分越来越像「模型加工具链」的合成成绩，不是模型的单独成绩。 换个骨架，分数就会动。
它真正的卖点不是更聪明，是更便宜
JetBrains 争的其实是吞吐。
它说在单张 H200 满载的情况下，Mellum 2.1 每秒吐出的 token 数接近 Qwen3.5-9B 的两倍——注意，具体数值只出现在一张图里，没有给表格。另外那个”单请求快 1.6 倍”的说法，靠的是一个多 token 预测（MTP）头，而这个头这次没跟着模型一起发出去，官方写的是”即将推出”。
所以现在能确认的速度优势只有一条：架构没变，所以它和上一版一样快。
自托管的门槛反而更值得关心：
- BF16 全精度权重大概需要二十四 G 显存（这是估算，官方没给硬件要求）
- 官方这次一起发了 GGUF，最小量化版本七 G，Q4 量化约八点一 G
- 但真要跑得舒服，十六 G 内存的机器是现实底线，八 G 机器别抱太大希望
- 推理引擎今天能用 vLLM，Ollama 和 LM Studio 的支持在跟进
还有一个容易被忽略的成本：这是”思考型”模型，答案前面会先输出一段推理过程。同样一句提问，它产出的 token 比普通对话模型多不少。按对话模型的延迟去预期，会落空。
谁该试，谁不用试
该试的： 你在同一张显卡上跑很多个 Agent 或子 Agent，源码不允许出内网，预算又卡得紧。这种情况下别信别人的表，在自己的仓库里量两个数——每秒 token 数和真正解决掉的工单数，两个模型用同一套骨架跑。
不用试的： 你已经在自托管 Qwen3.5-9B 干编程 Agent 的活。它在你最像日常工作的那些任务上分数更高。
完全不用看的： 你只是想要一个更聪明的助手。JetBrains 自己说了，这东西不是来替旗舰模型当大脑的，它的岗位是那些”顺手就能做完、但调用很频繁”的小活。
老达点评
第一，这次发布最值钱的看点不是跑分，是”后训练决定一切”在小模型上被完整演示了一遍。 参数一个没加，架构一个没改，光把强化学习从配角提成主角，修真实 bug 的能力就翻了二十多倍。对做垂直场景的人来说这是个挺提气的信号——你手上那点算力，可能还远没有摸到天花板。
第二，四十七这个数字要放在正确的位置上读。 它一半是模型能力的提升，另一半是脚手架的功劳。JetBrains 把评测口径写出来值得点个赞，但它顺带也暴露了一个行业现实：既然分数可以被脚手架抬起来，那”跑分领先”这件事的含金量，就越来越取决于谁把工具链调得更顺，而不是谁的模型更聪明。
第三，阿里 Qwen 又一次成了别人自测表里的那条基准线。 这一年多我写过的国产开源模型里，能在别人家的表上把对手压住的越来越多。JetBrains 拿 Qwen3.5-9B 当对标对象，本身就是一种承认——它是这个尺寸段里大家默认要跨过去的那道线。
第四，对企业来说，真正的价值不在分数，在账单和内网。 很多公司卡的从来不是模型够不够聪明，是源码能不能出防火墙。一个 Apache 协议、能自己部署、真实缺陷修复率接近一半的模型，解决的是”能不能用”，不是”好不好用”。这两件事的价值差得很远。
结尾
如果你在给编程 Agent 做分层——大模型负责规划和判断，小模型负责杂活——这篇和站内 JetBrains Air 那篇 其实是一套组合：Air 解决”用谁家的 Agent”，Mellum 解决”Agent 自己用什么脑子”。
想横向比开源小模型，可以看 德国发布的 Kolibri 和 Cloudflare 开源的决策模型 Clef，后者干的是比编程更窄的活——只做判断，不写代码。要评估本地跑不跑得动，DGX Spark 那篇 把带宽这笔账算得挺清楚；如果你更在意部署的省心程度，阿里 Qwen3.8-27B 的本地跑法 也值得对照着看。
这条线往下翻，可以看 AI编程工具专题 和 AI智能体与自动化专题。
