JetBrains 发布 Mellum2:12B MoE 编码模型,握 IDE 入口的人在自己造模型
JetBrains 在 Hugging Face 开源 12B MoE 的 Mellum2,只激活 2.5B 参数,主打路由/RAG/子代理的高频低延迟环节。这是 IDE 厂商把模型握进自己手里的信号。
概述
JetBrains 在 Hugging Face 官方博客发布了 Mellum2,一个 12B 参数的混合专家(Mixture-of-Experts)模型,每个 token 只激活 2.5B 参数,Apache 2.0 开源。值得注意的不是参数表,而是出手的人:JetBrains 是做 IDE 的,不是做大模型的,它选择从零训练一个自己的编码模型,而且不打算用它去和最大的模型拼能力上限。
这件事的判断价值在于它指向编码 AI 的一个分岔:赢家可能是握住开发者入口的人,而不是做出最大模型的人。JetBrains 手里有几千万开发者每天打开的 IDE,它造的模型贴着自家工作流的高频环节,分发渠道本身就是护城河。官方把 Mellum2 定位成系统里的「focal model」,这个措辞值得拆开看:它承认自己不是栈里最强的那个,而是要做那个被调用得最频繁、必须最快最便宜的那个。
发生了什么
Mellum2 是一个 12B 的混合专家模型,从零在自然语言和代码上训练,每个 token 只激活 2.5B 参数,Apache 2.0 许可。JetBrains 称它在和同尺寸开源模型比较时跑分有竞争力,同时推理快 2 倍以上,跑分细节放在 arXiv 技术报告里(论文号 2605.31268),博客本身没列具体数字。模型权重已在 Hugging Face 放出,模型 id 是 JetBrains/Mellum2-12B-A2.5B-Thinking。
Mellum 这条线最早是个代码补全模型,Mellum2 把它从单纯补全扩展到更广的自然语言和软件工程任务,但刻意守住「高效推理、易部署」这条线。官方点名的用途是路由与编排(提示分类、工具选择、中间控制流)、RAG 管线(上下文压缩、摘要、检索后处理)、子代理(规划、校验、转换、上下文准备)、以及涉及私有代码或内部数据的自托管部署。它明确不做多模态,只做文本和代码,JetBrains 说这种专一让模型保持紧凑高效。
为何重要
把这件事放进编码 AI 的竞争格局里看,它暴露了一条容易被忽视的逻辑链。过去两年的叙事是模型能力军备竞赛:谁的编码跑分高、谁的上下文长、谁能一次写完更大的功能。但用户真正每天碰的不是模型,是 IDE、是编辑器里那个补全框。JetBrains 的 IntelliJ、PyCharm 这些产品装在几千万开发者机器上,这个分发位置是任何一个纯模型厂商砸钱也买不到的。当 JetBrains 决定自己训模型,它不需要赢能力榜,它只需要一个贴着自家工作流、便宜到能默认开着、快到不打断敲键盘的模型。分发即护城河,这句话在编码这个品类里成立得格外彻底。
更耐人寻味的是 JetBrains 给 Mellum2 选的定位。它没有把这个模型包装成「IDE 里的写代码助手」,而是讲了一套更通用的故事:现代 AI 系统越来越依赖多次模型调用(路由、检索、摘要、规划、校验、工具调用),其中很多步骤对延迟敏感、又用不着最大的模型,Mellum2 就盯这些环节。这套话术把它从「JetBrains 的补全引擎」抬成了「任何 AI 栈里的高频中间件」。这里有真实的产品判断:补全和代理流程里那些中间步骤,调用频率极高、对成本极敏感,谁能在这些位置上提供一个快而便宜的模型,谁就拿住了一块别人很难抢的体量。但也有一层包装,见下文。
这对通用编码模型厂商意味着什么?意味着市场正在分层。最大的模型继续在最难的推理、最复杂的整段生成上有不可替代的价值,但围绕它的那一圈高频、低延迟、可自托管的活,正在被 IDE 厂商用自己的小模型收回去。OpenAI、Anthropic 这些厂商的编码模型仍然会被调用,但越来越多是在「真的需要推理」的关键步骤被调用,而不是默认的那个。对一个靠 API 调用量赚钱的模型厂商,这是收入结构上的慢性失血:最频繁的那部分调用,正在迁移到部署在用户基础设施里的开源小模型上。
对建设者的影响
如果你在搭 AI 编码相关的系统,Mellum2 给的具体动作是重新审视你的模型分层。它对应的判断是:不是每一步都该调最贵的模型。路由、上下文压缩、检索后处理、子代理的规划与校验,这些中间步骤用一个每 token 只算 2.5B 的模型完全够用,把贵的大模型省给真正需要推理的那一步。官方明说 Mellum2 的目标是让栈更快、更便宜、更可控,而非替换栈里每个模型,这个分工思路本身就值得照搬,不管你最后用不用 Mellum2。
选型上,12B MoE 的这个尺寸有明确的取舍可以拿来对照。总参数 12B 保住能力的天花板,每 token 激活 2.5B 压住推理成本和延迟,Apache 2.0 让你能合规地塞进自己的产品和私有部署。如果你的瓶颈是高吞吐下的单位成本(比如给每个用户实时跑补全),这种「大容量、小激活」的结构正是为你这种负载设计的。但要诚实:博客没有给出任何具体跑分数字,只说「和同尺寸模型有竞争力」「快 2 倍以上」,真要选型,得自己去 arXiv 报告里核对那些数字,再在自己的任务上实测,别只凭一句「有竞争力」就下决定。
对做开发者工具的创业者,这里还有一条战略提醒。JetBrains 这步说明:握住入口的玩家会往上游走,自己造模型来锁住高频环节。如果你的产品是接别人 API 的薄壳,你和你依赖的模型厂商,都在被这种「入口方自造模型」的趋势两头夹。要么你也有难以替代的分发位置,要么你提供的价值得在模型本身之上,光做 API 转发的中间层会越来越难站住。
该忽略什么
忽略「JetBrains 要和 GPT/Claude 在编码跑分上正面开战」这种解读。官方话讲得很清楚:它要当的是那个快、范围明确的高频组件,而非栈里能力最强的那个。把 Mellum2 读成「挑战 frontier 编码模型」是误读,它的设计前提恰恰是承认自己不做最强,而做最常被调用的。拿它的跑分去比最大模型的能力上限,比错了对象。
也要看穿 JetBrains 给它套的「通用 focal model」叙事里有几分包装。博客通篇把 Mellum2 讲成任何 AI 栈都能用的路由/RAG/子代理中间件,反而很少正面提 IDE。但这个模型最自然、最有护城河的落点,恰恰是 JetBrains 自己那几千万装机量的 IDE 里的高频补全。把它讲成通用中间件,既能吸引更广的开发者来试,也淡化了「这其实是我自家工具链的专用引擎」这层。真实的战略价值在 IDE 入口,通用叙事是顺带的市场动作,别被它带着高估 Mellum2 在 JetBrains 生态之外的即战力。
最后,别把「开源 + 跑分有竞争力」直接等同于「你该现在就换上它」。Apache 2.0 和 2 倍推理速度是实打实的好处,但博客没给绝对数字、没给和具体竞品的逐项对比,「有竞争力」是个需要你自己验证的措辞。它适不适合你,取决于你的负载是不是真的高频低延迟、你是不是真的需要自托管。对的姿态是:把它列进候选,在你的任务上实测,而不是因为一篇发布博客就改路线。
常见问题
Mellum2 是编码模型还是编排模型?
官方博客把它定位成系统里的「focal model」,主打路由、RAG 后处理、子代理规划这些高频低延迟环节,而不是一个一上来就写整段代码的主力。它从代码补全模型 Mellum 演化而来,所以编码能力是底子,但 JetBrains 这次卖的是「在多模型栈里当快而便宜的中间件」。
Mellum2 能替代通用 frontier 编码模型吗?
按官方说法不能,也不想。博客明说目标不是替换栈里的每个模型,而是让栈更快、更便宜、更可控。它每 token 只激活 2.5B 参数,适合做路由、压缩上下文、跑子任务,把贵的大模型留给真正需要推理的步骤。
12B MoE 只激活 2.5B 参数适合什么场景?
适合高吞吐、低延迟、要自托管的场景:IDE 里的补全、RAG 管线的检索后处理、代理流程里的中间控制步骤。总容量 12B 保住能力上限,每 token 算 2.5B 压住推理成本,官方称比同尺寸模型快 2 倍以上。
来源
无官方一手源；本文基于可靠二手报道（具名媒体、交叉印证）写成。