JetBrains 在 10 月 8 日开源了 Mellum2.1 Thinking：一个 12B 总参数、每 token 只激活 2.5B 的混合专家（MoE）模型，Apache 2.0 协议，专门给编码 Agent 当”干活的手脚”用。这次升级没有动架构，几乎全部精力花在强化学习上——数百万次沙箱化真实仓库运行，让模型学会逛代码库、改文件、自己跑测试。结果是 SWE-bench Verified 从上一代的 2.0 分直接跳到 47.0 分，跟 Qwen3.5-9B（50.0）站在了同一档。
我在 M4 MacBook（16GB 内存）上把官方 Q4_K_M 量化版完整跑了一遍：找 bug、写 TypeScript、调工具、5 千 token 上下文检索，全部通过，生成速度稳定在 54-57 token/秒。这篇把完整的实测过程、两个必须绕开的坑、以及”什么场景值得用它”一次讲清。
官方博客里有一句话值得留意：”GGUF builds for llama.cpp, Ollama, and LM Studio are coming soon”。我 10 月 9 日早上实际去下载时发现，官方 GGUF 仓库早就挂出来了，四个量化版本全都能下。新模型发布期，博客文案经常落后于仓库本身，要下载直接去 HF 的 GGUF 仓库页，别信博客的”coming soon”。
这模型是干嘛的：不是聊天玩具，是 Agent 的工人
Mellum 的血统值得交代一下。2024 年 10 月，JetBrains 发了第一代 Mellum，一个封闭的代码补全模型，装在自家 AI Assistant 里；今年 6 月开源的 Mellum2 转向了通用编码 Agent 底座；2.1 是第三次迭代。三代模型的三次转向很直白：JetBrains 想把自家 IDE 的 AI 供应链握在自己手里，而不是每个补全建议都给 OpenAI 或者 Anthropic 交租金。
2.1 的核心参数：28 层，64 个专家激活 8 个，GQA 注意力（32 个 Q 头、4 个 KV 头），131072 token 上下文，每 4 层有 3 层用 1024 的滑动窗口。基座是 Qwen3-MoE 衍生架构，词表 98304。官方推荐的采样参数是 temperature 0.6、top_p 0.95、top_k 20，评测用的是 Pi v0.73.1 这个开源 Agent 框架（shell + 文件工具），每个模型给 114K 上下文、单轮最多 16K token。
基准数字里最有信息量的是这组：SWE-bench Verified 从 2.0 到 47.0（同管线重评），Terminal-Bench 2.1 从 0.6 到 17.4，SWE-bench Pro 从 0.0 到 28.0。上一代 Mellum2 在真实仓库任务上基本是”不会干活”的水平，这一代靠 RL 补上了。代价也有：GPQA Diamond 64.6，比 Qwen3.5-9B 的 77.8 低一截——它是给 Agent 干活用的，不是知识问答选手。
对个人开发者和公司来说，这个模型的准确定位是：私有化部署的编码子代理（sub-agent）。你有一个主力模型做规划和决策，把”找根因、改文件、跑测试”这类重复劳动交给一个跑在自己机器上、代码不出本地的便宜工人。这跟之前写过的 Codex Harness 开源 Agent 框架是天然的搭配——harness 管流程，Mellum2.1 管动手。
Mac 部署：一条命令装 llama.cpp，四档量化怎么选
安装环节我要先复述上期的一个教训：上周跑决策模型时，Homebrew 的 llama.cpp 0.5.0（build 11146）加载新模型直接报错，最后是靠官方安装脚本装到最新 dev 构建解决的。这次同样是 build 11429 的 dev 构建正常工作，别用 brew 那个 0.5.0 去碰 10 月的新模型：
# 安装最新 llama.cpp（自动探测 Apple Silicon Metal）
curl -LsSf https://llama.app/install.sh | sh
# 下载官方 Q4_K_M 量化版（7.52GB）
curl -L -C - -o Mellum2.1-12B-A2.5B-Thinking-Q4_K_M.gguf \
"https://huggingface.co/JetBrains/Mellum2.1-12B-A2.5B-Thinking-GGUF/resolve/main/Mellum2.1-12B-A2.5B-Thinking-Q4_K_M.gguf"官方 GGUF 仓库有五个文件，我的选择建议：
- Q4_K_M（7.52GB）：16GB 内存的 Mac 就选它，实测质量没有可感知的损失
- MXFP4_MOE（6.55GB）：想再省 1GB 可以试，MoE 权重用 MXFP4 格式
- Q6_K（10.13GB）/ Q8_0（12.04GB）：32GB 以上内存再考虑
- BF16（22.64GB）：16GB 机器直接排除
启动命令就一行，上下文别照抄官方的 131K，16GB 内存老老实实开 8K 到 16K：
~/.llama-app/llama serve \
--model Mellum2.1-12B-A2.5B-Thinking-Q4_K_M.gguf \
--port 8642 --ctx-size 8192内存实况比想象中有意思。第一次冷启动加载花了约 18 秒；第二次重启只要 1.1 秒就绪——7.5GB 权重还在页缓存里，mmap 直接映射。ps 里看到的 RSS 是 7.87GB，但其中大部分是可回收的 mmap 文件页，真正的匿名内存占用只有约 400MB（KV 缓存和计算缓冲区）。对 16GB 机器的实际含义是：跑得动，但别同时开一堆吃内存的大户，权重文件页被系统赶回 SSD 后生成速度会肉眼可见地掉。
实测四关：找 bug、写代码、调工具、长上下文
第一关用官方 quickstart 的原题：找出 def mean(xs): return sum(xs) / len(xs) - 1 的 bug。这是检验”读题是否仔细”的基本盘。模型先在思考块里复述函数定义、推理正确均值公式，然后给出结论：去掉 - 1。答案完全正确。这次请求 880 个 completion token（含思考），16.2 秒完成，54.2 token/秒。
curl http://127.0.0.1:8642/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"messages": [{"role": "user", "content": "Find the bug in this function and explain the fix: def mean(xs): return sum(xs) / len(xs) - 1"}],
"temperature": 0.6, "top_p": 0.95, "top_k": 20, "max_tokens": 4096
}'第二关是写代码：一个带 leading 选项的 TypeScript debounce。模型输出了 2852 个 token，其中最终代码只占 620 字符，大头全是思考过程，泛型签名、可选参数对象、leading 首次立即执行加冷却窗口的实现都对，能直接用。速度 51.6 秒看着慢，但其中大半时间在生成思考内容——这类模型的思考是真实消耗 token 的，后面踩坑部分细说。
第三关是工具调用，这是编码 Agent 的命根子。同一个进程里传一个 get_current_weather 的 function 定义，模型直接返回了结构化的 tool_calls：函数名、JSON 参数（location: “Paris”）全部正确，llama.cpp 的 jinja 模板引擎开箱即用，不需要手动改聊天模板。官方在 vLLM 那边推荐 hermes 工具解析器，llama.cpp 这边实测无感适配。
第四关是上下文能力：4802 个 token 的文本里埋了 100 个编号标记，问”所有 item 是 9 的倍数的标记号”。模型答 0,9,18,27,36,45,54,63,72,81,90,99，12 个全对零遗漏。生成速度 53.9 token/秒，跟短上下文相比几乎没有衰减——滑动窗口注意力在这种检索型任务上确实省心。
两个必须绕开的坑
坑一：思考模型会吃满你的 max_tokens。 这是我实测里唯一翻车两次的地方：max_tokens 给 1024，请求”写个 debounce”，返回的 content 是空的——1024 个 token 全被思考过程吃掉，正文一个字没轮到就截断了；另一次在 4802 token 的检索任务里只给 256，同样空。给到 4096 才完整出结果。llama.cpp 会把思考内容单独放在 reasoning_content 字段里，正文在 content 字段，但截断发生时你拿到的就是空 content。给编码 Agent 用的时候，把这个模型的 max_tokens 预算按 2000 起步规划，多轮工具调用场景还要留思考余量。
坑二：别把它当补全模型用。 第一代 Mellum 是 FIM（fill-in-the-middle）补全模型，网上关于 Mellum 的旧教程大量在讲代码补全集成。2.1 Thinking 是聊天式的思考模型，定位是 Agent 对话和工具调用，拿去做 IDE 内联补全属于用错工具，补全场景连官方模型卡都没再承诺支持。
不建议使用的场景也说一句：8GB 内存的机器别碰这个模型，7.5GB 权重加上系统占用已经贴着极限；需要 131K 全量上下文的任务，16GB 机器的 KV 缓存压力会先于模型能力成为瓶颈；对知识问答有要求的场景，它 GPQA 64.6 分的水平扛不住，该上云端旗舰就上。
什么场景值得用它，怎么上手
三种情况我会选它：代码涉密不能出本地的团队，Apache 2.0 允许商用部署，数据全程不碰第三方 API；需要批量跑子任务（批量代码审查、批量单测生成）的场景，2.5B 激活参数意味着推理开销远低于同级别稠密模型，长时间挂着跑也不心疼；想给 Claude Code Mods 这类框架或者本地 Agent 流水线配一个便宜工人的场景。反过来，如果你追求单任务最高质量、不想折腾部署，云端 API 仍然是更省心的选择——小米 MiMo-V2.6 那篇提过，开源大模型走 API 的成本已经卷到很低了。
上手路径建议三步走：先用官方 Q4_K_M 在 llama.cpp 里把四关测试跑一遍，确认自己机器的实际速度；然后接一个真实的小任务（比如让它在你的某个仓库里找一个已知 bug）观察思考和工具调用的行为；最后再考虑把它挂进 Agent 框架当工人。想看更小的本地方案可以对照 MiniCPM5-2B 端侧部署那篇——2B 模型省内存但干不了仓库级的活，Mellum2.1 是”能干活”和”跑得动”之间目前比较均衡的一个点。
模型权重和更详细的技术文档在 JetBrains 的 HF 主仓库，架构细节见 Mellum2 技术报告，社区量化版本可以看 bartowski 的 GGUF 仓库。