JetBrains Mellum2.1：架构一点没变，后训练让它学会干活
JetBrains Mellum2.1 仍是 12B MoE、约 2.5B 活跃参数，靠百万级沙箱 RL 后训练学会干活，适合给 coding agent 当子代理。
如果现在做一个问卷调查，问大家"一个 coding agent 最需要什么样的模型？"
我相信，大多数人会回答：越强越好。
这个回答没错，但只说对了一半。
一个 agent 改一个 bug，往往不是调用一次模型就结束了。
它要先翻目录，再打开几个文件，再搜一下某个函数在哪里被调用，再改代码，再跑一遍检查。
每一步，都是一次模型调用。
如果每一步都交给最大、最贵的模型，就会又慢又贵。
所以，越来越多的 agent 采用分工的做法：大模型负责拿主意，小模型负责跑腿。
那么，问题就来了：跑腿的小模型，从哪里来？
2026 年 10 月 8 日，JetBrains 发布了 Mellum2.1，给出了自己的答案。
它是一个开源的快模型，定位就是给 coding agent 和本地子代理用。
架构没变，变的是训练
先看规格。
Mellum2.1 仍然是 12B 参数的 MoE 模型，每次大约只激活 2.5B 参数，采用 Apache 2.0 许可证。
这三项，跟上一代 Mellum2 完全一样。
也就是说，模型的"身体"一点没动。
那它变了什么呢？
变的是后训练。
按照官方的说法，Mellum2.1 在真实环境里，经过了百万级沙箱的强化学习（RL）。
训练之后，它能够自己探索代码仓库、修改文件、检查自己的改动。
这几件事，恰恰就是 coding agent 每天在做的事。
官方还拿它跟同一档的两个开源模型----Qwen3.5-9B 和 Gemma 4 E4B----做了对比，提升最大的一项，就是 agentic coding。
速度方面，官方给了两个数字。
一个是高负载下的吞吐量，大约是 Qwen3.5-9B 的两倍。
另一个是单个请求时，借助 MTP，速度大约提高到 1.6 倍。
上面这段话里，有三个词值得解释一下：MoE 活跃参数、RL 后训练、MTP。
弄懂了它们，也就弄懂了这个模型为什么"快"，为什么"能干活"。
一、MoE：12B 的模型，为什么只用 2.5B
先说 MoE，它的全称是"混合专家模型"（Mixture of Experts）。
普通的模型，生成每一个 token，都要把全部参数计算一遍。
MoE 模型不一样。
它把参数分成很多组，每一组称为一个"专家"。
生成某个 token 的时候，有一个"路由"负责挑选，只让其中几个专家参与计算，其他专家都休息。
你可以把它想象成一家大医院。
医院里有几百位医生，但是一个病人进来，分诊台只会把他分给相关的几位医生。
医院的总人数，相当于总参数；这一次真正出诊的医生，相当于活跃参数。
Mellum2.1 的总参数是 12B，活跃参数大约 2.5B。
做一个除法，2.5 除以 12，大约是五分之一。
也就是说，它每生成一个 token，只动用了大约五分之一的参数。
计算量小了，速度自然就快了。
但是，这里有一个容易误解的地方。
活跃参数少，不等于占用的内存少。
因为路由每次挑哪几个专家，事先并不知道，所以全部 12B 参数还是要放在内存里，随时待命。
总参数决定"装不装得下"，活跃参数决定"跑得快不快"。
这就是 MoE 适合当跑腿模型的原因：它用较小的计算量，保留了较大模型的知识容量。
二、RL 后训练：从读书到实习
再说 RL 后训练。
一个大模型的训练，通常分成两个阶段。
第一阶段是预训练，让模型读海量的文本和代码，学会"下一个词应该是什么"。
第二阶段是后训练，在预训练的基础上，教模型按照人们希望的方式做事。
强化学习（Reinforcement Learning，简称 RL）是后训练的一种方法。
它的思路很简单：让模型自己去尝试，做对了给奖励，做错了不给，模型就会慢慢倾向于做对的那些动作。
这很像学开车。
驾校的理论课，相当于预训练，你背熟了交通规则，但还不会开车。
真正上路练习，才相当于 RL。你一次次起步、转弯、倒车，教练告诉你哪次对、哪次错。
对于 coding agent 来说，"上路"就是进入一个真实的代码环境。
在里面翻文件、改代码、执行命令，看看结果对不对。
为了安全，这种练习一般放在沙箱里进行。
沙箱就是一个隔离的环境，模型在里面怎么折腾，都不会影响外面的系统。
Mellum2.1 做的，就是把这种练习的规模拉到了百万级沙箱。
所以，它跟 Mellum2 的区别，不在于"读过多少书"，而在于"实习过多少次"。
这也解释了，为什么架构一点没变，能力却能明显提升：同一个身体，经过大量实操，学会了另一套本领。
我觉得，这是一个值得注意的信号。
过去大家比较模型，习惯先看参数量。
但是 Mellum2.1 说明，对于 agent 来说，后训练教会模型怎么干活，可能跟模型有多大同样重要。
三、MTP：一次多猜几个字
最后说 MTP，它的全称是"多 token 预测"（Multi-Token Prediction）。
大模型生成文本，通常是一个 token 一个 token 往外蹦。
每蹦一个，就要把模型完整地跑一遍。
这就像打字时每次只能按一个键，按完还要等一下，才能按下一个。
MTP 的思路是：既然很多时候后面几个字很好猜，那就一次多猜几个。
通常的做法是，在模型旁边加一个额外的小结构，称为 MTP head，专门负责往后多猜几个 token。
然后，主模型一次性检查这几个猜测。
猜对的直接收下，猜错的从出错的地方重新来。
只要猜对的比例够高，平均下来，每跑一遍模型就能产出不止一个 token，速度就上去了。
写代码特别适合这种方法。
因为代码里有大量固定的写法，比如括号、缩进、常见的函数调用，后面的内容往往很好猜。
Mellum2.1 官方给出的数字是，单个请求下，MTP 带来大约 1.6 倍的速度。
这里要分清两个"快"。
一个是单个请求有多快，这是 MTP 解决的问题，用户感受到的是"等待时间变短"。
另一个是高负载下的吞吐量，也就是同一时间能服务多少请求。官方说这一项大约是 Qwen3.5-9B 的两倍。
前者影响一个 agent 每一步等多久，后者影响一台机器能同时跑多少个 agent。
为什么是"子代理"
把上面三点合在一起，就能看清 Mellum2.1 想站的位置。
MoE 让它算得快。
RL 后训练让它会翻仓库、改文件、自检。
MTP 让单次回答再快一截。
这些特点，正好对应 agent 里那些"量大、步骤多、单步不太难"的活儿。
比如，主 agent 想知道某个配置在哪里定义，就可以派一个子代理去仓库里找。
又比如，一个改动涉及很多文件，可以让子代理逐个去改，再各自检查一遍。
这些活儿，交给最大的模型是浪费，交给什么都不会的小模型又不放心。
一个专门为干活训练过的快模型，正好填在中间。
而且，它是开源的。
Apache 2.0 许可证，意味着你可以自己部署，可以放进自己的产品，也可以在公司内网里运行，代码不必离开自己的机器。
对于很多团队来说，这一点可能比速度更重要。
现在能用到什么程度
说完优点，也要说清楚现状。
目前，Mellum2.1 已经上架了 Hugging Face，可以下载权重。
但是，大家熟悉的几种本地运行方式，还没有准备好。
按照官方的说法，GGUF 格式，以及 Ollama 和 LM Studio 的支持，都还是"即将提供"。
vLLM 所需的 MTP head，同样是"即将提供"。
换句话说，截至发稿时，这些都还没有正式提供。
如果你想今天就在笔记本上一键跑起来，可能还要再等一等。
另外，有两点值得提醒。
第一，前面的对比和速度数字，都来自 JetBrains 自己的发布文章，还需要更多第三方的实测来验证。
第二，活跃参数虽然只有大约 2.5B，但是全部 12B 参数仍然需要装进内存，本地部署时要先看看自己的硬件够不够。
总结
Mellum2.1 的故事，可以用一句话概括。
同样的 12B MoE 架构，同样大约 2.5B 的活跃参数，靠百万级沙箱的 RL 后训练，从一个会写代码的模型，变成了一个会干活的模型。
MoE 决定它算得快，RL 决定它会干活，MTP 决定它答得快。
它不是用来替代最强的大模型的，而是给 agent 当一个又快又便宜、还可以自己部署的帮手。
如果你正在搭建自己的 coding agent，需要一个跑腿的子代理，可以关注一下它。等 GGUF、Ollama、LM Studio 的支持到位以后，再拿到本地试试。
（完）
来源：JetBrains AI 博客：Mellum2.1 Gets to Work: A Fast Open Model for Coding Agents（2026-10-08）。文中关于 Mellum2.1 的事实与数字仅取自该来源；MoE、RL、MTP 的原理部分为通用概念解释，不代表 Mellum2.1 的具体实现细节。