同一个 12B 架构，同一批工程师，只是换了训练方法：SWE-bench Verified 从 2.0 分干到 47.0 分。这不是新模型的宣传话术，而是 JetBrains 在 2026 年 10 月 8 日上架 Hugging Face 的 Mellum2.1 交出的自测成绩单。2% 到 47%，中间隔着的不是更多参数，而是一次训练配方层面的豪赌——把强化学习从训练流水线的"收尾润色"环节，提到整个训练的主体位置。
对关注开源 AI 编程模型的人来说，这次发布值得认真读一遍：它证明了在 agent 时代，训练方法本身可以成为最大的杠杆。当然，47 分是 JetBrains 自己的 harness 跑出来的数字，第三方尚未复跑，这一点先说清楚。
仓库地址与发布背景
先给仓库。Mellum2.1 的完整模型名为 Mellum2.1-12B-A2.5B-Thinking，托管在 Hugging Face 上：JetBrains/Mellum2.1-12B-A2.5B-Thinking。
仓库地址：huggingface.co/JetBrains/Mellum2.1-12B-A2.5B-Thinking
几个发布时点的事实，均经 HF API 实核（2026-10-10，经 hf-mirror 读取）：许可为 Apache 2.0，仓库 ungated，无需登录任何账号即可直接下载全部权重。发布初期数字为 198 次下载、77 个 likes——刚上架几天的状态，这个数字只反映发布初期热度，不代表长期采用量。
ungated 这一点值得单独强调。上一批我们写过 LTX-2.5，仓库 gated=auto，下载前要先提交信息等审批。Mellum2.1 则是完全开放：打开仓库页，点下载，权重到手。对想快速验证的企业团队来说，省掉的是一整道流程。
发布背景方面，Mellum2.1 是对 2026 年 6 月发布的 Mellum2 的配方升级：架构完全相同，许可相同，唯一变化是训练方法。JetBrains 官方博客同步发布了公告。没有托管 API，想用就得自己拉权重部署——这也解释了为什么本文后面要花笔墨讲部署边界。
架构不变，卖的是配方
Mellum2.1 的模型规格：12B MoE 总参数，2.5B 激活参数，上下文长度 131,072 token。这套规格与 Mellum2 完全同构。换句话说，JetBrains 没有堆参数、没有扩上下文、没有改稀疏度——它改的东西在训练室里。
改动核心是 RL（强化学习）的角色重定位。在传统训练流水线里，RL 通常是最后一步：先做预训练和 SFT（监督微调），再用 RL 对齐或强化少数能力，占比小、周期短。Mellum2.1 把 RL 变成训练主体，配套的工程规模是"数千个环境、数百万次沙盒 run"——模型在大量隔离沙盒里反复执行真实任务，从反馈中学习。
任务面也扩了。Mellum2 时代主要围绕代码补全和软件工程，Mellum2.1 新增了数学、竞赛、科学、工具使用类任务。数据侧的做法是源数据过滤，JetBrains 的原话是：开源数据常带坏测试与不可验证答案。这句话翻译过来就是：RL 训练的奖励信号必须可验证，如果一个任务的"正确答案"本身说不清对错，放进训练集只会污染模型。所以 JetBrains 宁可过滤掉大量数据，只保留有明确判定标准的任务。
这套配方的结果就是开头那个数字：同架构、同许可，SWE-bench Verified 从 2.0 到 47.0。23 倍的提升来自纯训练方法变更，这也是本文标题里"RL 赌注"的含义——赌注赢了，至少在 JetBrains 自己的测试环境里赢了。
值得多说一句的是这背后的行业含义。过去两年开源编程模型的竞争焦点几乎全在参数量和数据规模上：更大的模型、更多的 token、更长的上下文。Mellum2.1 提供了另一条叙事线——在 agent 时代，模型能力的天花板越来越取决于"能不能在可验证的环境里反复试错"，而不是静态数据集的规模。数千个沙盒环境本质上就是一个自动出题、自动判卷的考场，模型在里面跑几百万次，跑出来的不是背题能力而是解题习惯。JetBrains 作为 IDE 厂商做这件事有天然优势：它比谁都清楚程序员在真实工程里会踩什么坑，出题自然更贴近实战。这也解释了为什么一家做开发工具的公司，忽然成了开源 agent 模型赛道里不可忽视的玩家。
自测分数：怎么读这张表
JetBrains 公布的自测在 Pi harness v0.73.1 上跑，开启 thinking mode，同环境与 Qwen3.5-9B 对比。必须先声明口径：这是官方自测，第三方未复跑；且分数多以图表呈现，部分原始数字无法逐项核对。以下数字以官方口径转述，请带着这个前提阅读。
| 基准 | Mellum2.1 | Qwen3.5-9B | 谁胜 |
|---|---|---|---|
| SWE-bench Verified | 47.0 | 50.0 | Qwen |
| SWE-bench Pro | 28.0 | 38.0 | Qwen |
| Terminal-Bench 2.1 | 17.4 | 21.7 | Qwen |
| LiveCodeBench v6 | 82.0 | 75.4 | Mellum |
| BFCL v4 | 62.3 | 58.5 | Mellum |
| GPQA Diamond | 64.6 | 77.8 | Qwen |
这张表最容易被误读，所以单独讲判读纪律。
第一，"各引各表"。Mellum2.1 的 47.0 和 Qwen3.5-9B 的 50.0 出自 JetBrains 的同一张自测表，口径统一；但如果你在别处看到 Qwen3.5-9B 的其他分数，那是 Qwen 官方在不同环境下的数字，两者不能混着排名。本文只用 JetBrains 这张表。
第二，看结构而不是看总分。Qwen3.5-9B 在三个真实仓库类长任务基准上领先（SWE-bench 两项、Terminal-Bench），Mellum2.1 在竞赛编程（LiveCodeBench）和工具调用（BFCL）上反超。粗略概括：真实仓库长任务 Qwen 胜，短任务、竞赛、工具调用 Mellum 胜。这不是"全面超越"，而是两种训练取向在不同任务形态上的分化。
第三，别把 Mellum2 的 2.0 分当成模型本身的质量结论。Mellum2 是补全导向的模型，SWE-bench 这类 agent 任务对它本来就不公平；2.0 到 47.0 说明的是配方变化的效果，而不是"老模型很烂"。
第四，GPQA Diamond（科学问答）Mellum 落后 13 分以上，说明这次 RL 配方强化的是可验证的工程类任务，科学推理不是卖点。拿它去做题不合适。
速度数字与 MTP 未发布的真相
JetBrains 给出的速度口径：在 H200 上重负载吞吐"接近 Qwen3.5-9B 的两倍"。注意两个限定：一是官方口径，具体数值只在图表里，没有文字数字；二是"重负载吞吐"指的是高并发场景，不是单请求延迟。
单请求场景另有说法：靠 MTP（Multi-Token Prediction）投机解码可达 1.6x 提速。但这里有个关键事实——MTP head 未随权重发布。JetBrains 标注 coming soon，也就是说，你现在从 Hugging Face 拉到的权重里没有 MTP head，1.6x 这个数字当前买不到。等后续放出才可复现。
这个细节对部署决策很重要。如果你看到网上教程宣称"Mellum2.1 提速 1.6 倍"，请检查它有没有自己实现或等待 MTP head——大概率是把官方宣传数字当成了默认能力。类似的还有 GGUF：llama.cpp/Ollama/LM Studio 支持同样是 coming soon，今天拉不到 GGUF 量化包，宣称"Ollama 一键跑 Mellum2.1"的整合包都是超前宣传。
现在能跑的路径只有 vLLM：官方已支持，reasoning-parser 用 qwen3 配置，可选 Hermes 工具调用模板。
部署边界：12GB 与 24GB 之间
官方没有给出硬件需求，这里给出可查证的估算口径：BF16 权重约 24GB 级。按这个数字推边界：
- 24GB 卡（4090/3090）：全量 BF16 起步可行，但 131K 上下文的 KV cache 会挤占余量，长上下文场景建议更多显存或多卡。
- 12GB 卡：跑不动全量权重，只能等 GGUF 量化版发布后再看。
- 8GB 卡：当前无路可走。
由于 MoE 架构激活参数只有 2.5B，推理时的计算量不大，瓶颈主要在显存容量与带宽。这也是 JetBrains 主打"固定 GPU 预算下高吞吐 agent 密度"的底气所在——单卡 24GB 就能跑一个专用 agent 模型，并发吞吐还是竞品近两倍（官方口径）。
要提醒的是：无官方托管 API，一切都要自托管。对没有 GPU 运维能力的团队，这个门槛是实打实的。具体的 vLLM 部署步骤、坑点清单（含 thinking 模型的 reasoning parser 配置），我们单独写了一篇部署 SOP（mellum-2-1-local-deploy-sop）。
再补充一点部署视角的判断。MoE 架构的显存账本和稠密模型不一样：12B 总参意味着权重本身要占约 24GB 的显存，2.5B 激活意味着算得快但省不了存放空间。所以"激活小"并不降低显存门槛，只是降低了算力门槛——这也是为什么 12GB 卡跑不动全量，而 24GB 卡跑起来之后吞吐表现反而突出。等 GGUF 量化版放出，权重体积可能压到 12GB 以下，届时 12GB 卡才有入场券；但量化对 agent 长任务能力的影响需要实测，不能想当然认为无损。这块等量化包落地后我们会单独补测。
生态定位：谁该用，谁不该用
把 Mellum2.1 放进 45 批之后的本地模型生态里，它的位置其实很清晰。
该用的场景：
- 固定 GPU 预算跑 agent 农场。如果你的核心需求是"一张卡上并发跑尽量多的 agent 任务"，Mellum2.1 的高吞吐设计正对这个场景。代码补全起家的模型对 IDE 内 agent 场景也天然亲和。
- 数据不出域。Apache 2.0 许可、纯自托管，代码和任务数据全程不过第三方服务器。这是企业选型的硬需求。
- 短任务与工具调用密集的工作流。LiveCodeBench 和 BFCL 的领先说明竞赛类代码任务、函数调用场景是它的优势区。
不该用或谨慎的场景：
- 你的主战场是真实仓库的长周期任务。SWE-bench Pro 和 Terminal-Bench 上 Qwen3.5-9B 更强，这是自测表里的明确信号。别为了"新"选弱的那边。
- 8GB 显卡用户。现在 GGUF 没放出，量化生态空窗期，Qwen3.5-9B 或其他小模型才是你的菜。
- 需要多模态输入。Mellum 是纯代码模型，不支持图像输入。
- 不想自己运维 GPU。无托管 API，vLLM 是唯一路径，运维成本要自己扛。
横向对比的完整版——Mellum2.1、Qwen3.5-9B、DeepSeek-V4.1-Flash、GLM-5.3-Flash 四强在许可、上下文、硬件门槛、运行支持五个轴上的对照——见本批横评（local-coding-model-comparison-review）。那里有一个关键反差点："Flash"后缀不等于小，GLM-5.3-Flash 是 321B 的节点级模型，反而 12B 的 Mellum 是四强里唯一消费卡可跑的。
从更大的时间线看，Mellum2.1 出现在一个微妙的节点上。编程模型市场正在分化成三条路线：闭源旗舰（Claude 系、GPT 系）继续拉高能力上限但价格昂贵；开源通用模型（Qwen、GLM、DeepSeek 系）走均衡路线覆盖面广；而 Mellum 代表的专用路线，押注的是"在固定硬件上把某一类任务做到极致"。三条路线没有绝对胜负，但专用模型的价值会随着 agent 工作负载的规模化而放大——当你需要同时跑几十个 agent 时，单位算力的任务密度比单任务的天花板更重要。JetBrains 显然想清楚了这个账。
如果你想把它放进 IDE 工作流里和 Claude Code、Cursor 这类 agent 工具搭配，可以参考我们之前的编程 agent 横评（ai-coding-agent-comparison-review）；以及针对部署工具选择的推理工具横评（local-llm-deployment-comparison-review）。
FAQ
Q1: Mellum2.1 和 Mellum2 有什么区别？
架构、参数量、上下文长度、许可完全相同，唯一区别是训练配方：Mellum2.1 把 RL 从收尾环节变成训练主体，用数千环境数百万沙盒 run 训练，并新增数学、竞赛、科学、工具使用任务。效果是 SWE-bench Verified 从 2.0 提升到 47.0（JetBrains 自测口径，第三方未复跑）。
Q2: Mellum2.1 真的比 Qwen3.5-9B 强吗？
不是。按 JetBrains 自测表，真实仓库长任务（SWE-bench Verified 47.0 vs 50.0、SWE-bench Pro 28.0 vs 38.0、Terminal-Bench 17.4 vs 21.7）Qwen3.5-9B 更强；Mellum2.1 在竞赛编程（LiveCodeBench 82.0 vs 75.4）和工具调用（BFCL v4 62.3 vs 58.5）反超。选型应按你的任务形态定，不存在"全面超越"。
Q3: 说的 1.6 倍提速现在能用上吗？
不能。1.6x 依赖 MTP 投机解码，但 MTP head 未随权重发布，官方标注 coming soon，当前下载的权重无法复现这个提速。H200 重负载吞吐"接近两倍"也是官方口径且未给出具体数值。现在能验证的只有 vLLM 路径的基础性能。
Q4: Mellum2.1 支持哪些运行方式？Ollama 能跑吗？
当前只有 vLLM 官方支持，需配置 reasoning-parser qwen3。GGUF（llama.cpp/Ollama/LM Studio）均为 coming soon，不是已支持状态，市面上的整合包属于超前宣传。Ollama 用户需要等 GGUF 量化版发布。
Q5: 下载 Mellum2.1 需要登录或申请吗？
不需要。仓库 ungated，许可 Apache 2.0，打开 Hugging Face 仓库页即可直接下载全部权重（2026-10-10 经 hf-mirror 实核）。发布初期下载量 198、likes 77，属于刚上架状态。无官方托管 API，使用需自托管。
收尾
2% 到 47% 的故事讲完了，但真正的考验在社区手里：JetBrains 的自测数字需要第三方 harness 复跑验证，MTP head 和 GGUF 的放出时间会直接决定它的采用速度。我们也会在拿到量化版本后补测 12GB 显卡的可行性。
如果你已经拉了权重跑起来，欢迎在评论区晒一下你的 harness 分数和 tokens/s——尤其是和 Qwen3.5-9B 同环境对比的数据，这正是双跑对账最有价值的部分。部署过程遇到坑，也可以去看那篇部署 SOP，评论区互相捞。