JetBrains打造的"聪明小模型"：用一半算力，干两倍的活

这项由JetBrains研究团队与德国不来梅Constructor University联合开展的研究，于2026年5月以技术报告形式发布，编号为arXiv:2605.31268v1，感兴趣的读者可通过该编号检索完整论文。

**一个让程序员烦恼的老问题**

每当程序员打开电脑，面对一个需要写代码、改bug、查文档、问AI的下午，他们都在隐隐期待着一件事——有一个既聪明又响应迅速的AI助手，随时等在旁边帮忙。问题是，聪明的AI通常需要消耗大量算力，运行起来要么很贵，要么很慢，要么两者兼而有之。便宜又快的AI，又常常在遇到复杂任务时掉链子。

JetBrains是一家以开发专业编程工具闻名的公司，他们的产品每天都在全球数百万程序员的电脑上运行。正因如此，他们比任何人都清楚：一个真正好用的AI编程助手，不能只会填写代码片段，还要能写整个函数、改旧代码、找出bug、调用各种工具、在一个大项目的文件之间穿梭导航，甚至要能像一个经验丰富的同事那样和你聊编程。而这一切，都必须在程序员的普通电脑上流畅运行，不能让人等到抓狂。

为了解决这个矛盾，JetBrains推出了他们的新一代模型——Mellum 2。这是他们早期那个只会填写代码的简单模型Mellum的全面升级版。新模型拥有120亿个参数，却只在处理每个词的时候激活其中25亿个，相当于一个拥有丰富知识储备的专家，思考时只调用最相关的部分，而不是把所有记忆都翻一遍。

**一、大脑的结构：为什么不是"越大越好"**

要理解Mellum 2的设计思路，可以把AI模型的参数想象成一家大型图书馆的藏书量。藏书越多，能回答的问题就越广泛；但每次有人来查资料，如果必须把整个馆的书都翻一遍，那效率就太低了。聪明的图书管理员只会在相关的书架上查找。Mellum 2采用的核心技术叫"混合专家架构"（Mixture-of-Experts，简称MoE），正是这个道理：模型里有64位"专家"，每次处理一个词时，只有其中8位专家真正参与工作。这样，模型总共存储了120亿参数的知识，但实际运算量只相当于一个25亿参数的小模型。

JetBrains在选择这个架构之前，做了大量的对比实验。他们首先尝试了密集型模型（Dense Model），也就是每次处理都激活所有参数的传统方式。他们测试了各种不同深度和宽度的配置，层数从24层到40层不等，隐藏维度从2304到4096不等，甚至还尝试了DeepSeek团队设计的一种叫做"多头潜在注意力"（MLA）的特殊架构。结果发现，在他们设定的速度约束下，没有任何一个密集模型能稳定地超越Qwen2.5-7B这个7B参数的标杆模型。MLA架构确实允许把模型扩展到约55亿参数，同时保持相同速度，但质量提升并不足以弥补训练复杂度增加带来的代价，而且当时支持的潜在秩维度对他们的模型规模来说太大了。

转向MoE架构后，他们参考了Qwen3-30B-A3B这个模型的设计，按比例缩小以适配单张H100显卡的内存上限（低于180亿总参数）。专家数量固定为64个，因为更多专家会超出显卡内存。他们测试了不同的激活专家数量：激活2个专家的模型比激活8个的快约1.5倍，但质量明显变差；而在小规模模型上，稀疏度过高确实有损质量，这与学术界此前的研究结论一致。最终，"64个专家，每次激活8个"成为质量与速度的最佳平衡点，在这个配置下，模型最高可以扩展到约150亿总参数，同时与Qwen2.5-7B保持相当的推理速度。

**二、注意力机制的精心裁剪**

除了专家架构本身，模型里还有一套叫做"注意力机制"的装置，负责让模型理解文字之间的关联——比如，在一段代码里，"这个变量"到底指的是前面哪个定义。这部分的设计对运行速度影响极大。

传统的多头注意力机制，就像让一群人同时盯着整篇文档的每个角落做笔记，然后汇总。JetBrains在Mellum 2中使用了分组查询注意力（Grouped-Query Attention，GQA），把存储中间结果（也就是KV缓存）所需的"记录员"数量从通常的很多个压缩到只有4个。这个数字的选择经过了仔细权衡：8个记录员会导致在高并发场景下吞吐量大幅下降，而只用2个记录员时，模型质量又会明显变差。4个恰好是甜蜜点。实验数据显示，Qwen2.5-7B用4个KV头能达到的并发吞吐量，与他们的前代模型Mellum-4B用8个KV头时大致相当，尽管前者参数量几乎是后者的两倍。

另一个关键设计是"滑动窗口注意力"（Sliding Window Attention，SWA）。正常的注意力机制，每个词都要关注输入文本里所有其他词，随着输入文本变长，计算量会急剧膨胀。滑动窗口注意力则像一个焦点灯，每次只照亮附近一小段区域，大大降低了大多数层的计算量。Mellum 2把28层Transformer中的21层（即四分之三）设置为滑动窗口注意力，窗口大小为1024个词元（token），剩余7层保持全局注意力，以确保模型在需要时仍能捕捉远距离的上下文信息。实验表明，窗口大小1024比512在质量基准上表现更好；而且带有滑动窗口注意力的MoE模型，在输入长度翻倍的情况下仍能保持与Qwen2.5-7B相当的延迟，在需要处理长代码文件的工作流程中优势显著。

还有一个颇具巧思的设计：多词元预测头（Multi-Token Prediction，MTP）。通常模型每次预测下一个词，而MTP让模型在训练时额外预测再下一个词，用一个额外的Transformer层实现，训练时额外增加的时间约7%。这个头在正式推理时会被移除，不影响模型本身的预测，但它带来了双重好处：一方面作为辅助训练目标提升了模型质量，另一方面可以充当"推测解码"（speculative decoding）的草稿生成器，加速推理。在对比实验中，加入MTP的模型在HumanEval代码生成测试上提升了10.4个百分点，在MMLU知识测试上提升了3.6个百分点，在MMLU-Pro上提升了3.3个百分点，在GSM8K数学测试上提升了3个百分点。

**三、训练数据的三段式厨艺哲学**

模型的"智慧"来源于它看过的文本数据。Mellum 2的训练数据约达10.6万亿个词元，涵盖网页文本、源代码和数学内容三大类别。如果把训练过程比作一道精心设计的套餐，那这三个阶段的安排就像是先打底、再提质、最后精炼。

第一阶段叫"基础建设"，处理了约6.18万亿词元，占总量58%。这一阶段以网页和通用知识为主（约70%），代码占23%，数学只有6%。目的是让模型先建立宽泛的语言理解能力和基础代码理解。这一阶段涵盖了学习率预热和保持阶段。

第二阶段叫"质量提升"，处理了约2.79万亿词元，占总量26.2%。代码比例大幅提升至42%，高质量精选数据集（包括指令跟随数据、推理问答、STEM教学数据、知识对齐文章）被引入。此阶段的精选数据是在学习率稳定后引入的，因为精选数据在这个时候效果更好。同时引入了新的合成代码数据集，原始代码语料库进入第二轮学习。

第三阶段叫"能力锐化"，处理了约1.69万亿词元，占总量15.9%。学习率进入线性衰减，代码比例进一步升至59%，网页内容缩减为只有最高质量的精选来源。额外引入了代码审查和跨语言代码转换等合成数据集，原始代码语料库进入第三轮学习。

代码数据本身分为三类：一是来自公开仓库的原始代码，按文件去重；二是从Common Crawl（一个大规模网页快照）提取的含代码网页；三是合成和衍生代码数据集，通过代码摘要、功能扩展、语言转换、测试生成、提交信息等方式为代码附上自然语言注解，还有问答、代码重写、代码审查、代码教学解释等合成数据。研究发现，合成代码数据对小规模MoE模型的帮助尤为明显，因为这类模型更需要数据的多样性。

网页和通用知识数据包括大规模合成网页语料、教育类网页内容、教育PDF、多语言推理和问答数据集，以及精选知识来源——维基百科改写、合成百科条目等。数学数据则包含数学指令调优数据、多质量层级的数学网页内容、数学教材和数学SFT数据。

数据重复策略也经过了精心设计。高质量数据因为稀缺，会被多次使用。小型精选代码数据集贯穿三个阶段，原始代码语料库经历三轮学习，总计贡献约9580亿词元。但没有任何数据集被重复超过4次，因为实验发现超过这个次数之后，继续重复已经带不来收益了。而且对于MoE训练来说，高质量数据的多次训练能有效锐化专家专业化，这是只看一遍嘈杂数据做不到的。

**四、填空训练：为IDE设计的特殊技能**

除了标准的"下一词预测"训练，Mellum 2还专门做了填空中间（Fill-in-the-Middle，FIM）训练。这对IDE代码补全至关重要——当程序员把光标停在代码中间某处，需要AI补全这段内容时，AI必须同时看到光标前后的上下文，而不只是前面的部分。

FIM训练把文档随机分成三段（前缀、中间、后缀），用特殊标记重新排列后作为训练样本。研究团队使用PSM（前缀-后缀-中间）和SPM（后缀-前缀-中间）两种排列各占50%。FIM的比例也随训练阶段动态调整：第一阶段50%（应用于所有数据）；第二阶段降至10%（精选数据主要用标准预测方式消化）；第三阶段恢复至50%，但只应用于源代码文件，非代码数据继续用标准预测。

**五、优化器的选择：Muon的胜利**

选择合适的优化器（即控制模型学习方式的算法）对训练质量至关重要。研究团队测试了AdamW（深度学习领域最常用的优化器）和Muon（一种新型优化器，对隐藏层参数使用正交化更新）两种方案，并在两种不同的Muon配置下进行了对比：Megatron默认配置（额外缩放因子1.0）和Moonlight配置（额外缩放因子0.2）。

在密集型7B架构上，Megatron默认配置在训练约210亿词元时直接发散崩溃，而Moonlight配置大幅击败AdamW，验证损失降低了约0.028（相当于约2.5%的改进）。在MoE 14B架构上，两种Muon配置都能收敛，Megatron默认配置最终损失略好（低约0.026，约2.4%），Moonlight紧随其后。最终选择Moonlight配置，因为它在密集和MoE架构上都保持了稳定性。

学习率采用"预热-保持-衰减"（Warmup-Hold-Decay，WHD）策略：先线性预热2000步到峰值3×10??，在第一和第二阶段保持峰值，在第三阶段（约49306步，占总训练时间15%）线性衰减到零。线性衰减到零比余弦衰减到非零最小值效果更好，能以更低的有效计算量达到同等损失。全局批量大小从2048个序列线性斜升到4096个序列，每步处理约3360万词元。训练精度以BF16为基础，配合FP8混合精度训练，梯度规约保持FP32精度以确保数值稳定性。

**六、训练过程中的意外插曲**

任何大规模训练都会遇到意想不到的麻烦，Mellum 2也不例外，而且研究团队选择坦诚地记录了这些经历。

训练初期出现了两次损失尖峰，追查后发现是数据中有些序列词汇多样性极低——比如整个上下文窗口里就重复同一个词元。解决方案是过滤掉独特词元少于82个（占8192上下文长度1%）的样本。

此外，数据准备管道按词元序列的哈希值排序，导致一些足够长的文档被切割成多个8192词元的块之后，这些块变成了完全相同的副本。哈希排序把这些副本放在每个数据分片的相同位置，而每个训练阶段由16个均匀分片组成，导致每个阶段出现16次周期性的损失下降。这些影响不大，是小幅且孤立的，对训练动态没有可测量的影响，研究团队决定不处理。

训练中途，计算集群从32节点迁移到16节点，保持全局批量大小不变。迁移后全局负载均衡损失明显下降，但这不是模型行为的变化，而是Megatron-LM实现全局辅助损失的方式在节点数变化时产生的累积语义差异——节点减少意味着每步梯度累积的微批次更多，运行平均值更接近真实分布，算出的损失系统性地更低，但优化信号是等价的。

**七、扩展到超长上下文：从8K到128K的跨越**

基础预训练完成后，Mellum 2的上下文窗口还只有8192个词元，大约只能装下十几页代码。为了让模型处理更大的代码库和更长的对话，研究团队进行了专门的长上下文扩展训练，将上下文扩展至131072个词元（约128K）。

扩展的核心技术是YaRN——一种调整模型位置编码频率的方法，帮助模型理解更长序列中词语的相对位置。但有一个关键的巧思：研究团队并没有把YaRN应用到所有层，而是只应用到全局注意力层（每四层中的那一层），让滑动窗口层保持原来的位置编码参数。这种"层选择性YaRN"的思路最早由Gemma 3团队提出，OLMo 3也随后采用。Mellum 2的消融实验与他们的发现一致：在64K评估上下文下，层选择性YaRN的RULER评分（一个测试长上下文理解能力的基准）为0.64，明显优于统一调整RoPE基础（0.52）和不做任何调整（0.33）。差距随上下文长度增加而扩大，不调整的模型在超过32K后完全崩溃，统一调整则不必要地干扰了本来运作正常的滑动窗口层。

长上下文训练数据是第三阶段预训练数据的重新平衡版本，加入了一部分自然包含长上下文示例的智能代理SFT数据。重新平衡时专门下采样了长推理链，因为发现它们主导了长上下文数据的尾部，会让模型偏向推理风格输出而牺牲通用长上下文能力。研究团队还在扩展数据中加入了基于仓库级上下文的FIM格式样本，延续Mellum 1的做法，将相关文件级联接成前缀，确保模型在长距离跨文件代码补全时也能学到正确的注意力模式。

训练约300亿词元后，RULER评分在所有测试上下文长度上就已经接近最终值（误差约1个百分点），但MoE路由器的负载均衡损失在此后仍持续下降——路由器还在继续适应新的序列长度模式。基于这个信号，研究团队将训练延长到3500轮（约1170亿词元），让路由器充分稳定后再退火。峰值学习率为3×10??，比预训练低一个量级。

**八、两个性格不同的"学生"：Instruct和Thinking**

长上下文训练完成的基础模型还不能直接被用户使用，还需要"后训练"：先做监督微调（SFT），再做强化学习。研究团队从同一个长上下文检查点出发，训练出两个风格不同的变体。

Instruct（无思考）变体是一个直接回答助手，不展示内部推理过程，损失计算覆盖对话中的每个助手轮次，来源数据中的推理字段会被丢弃。Thinking（思考）变体是一个推理增强助手，在给出最终答案前会先生成一段内部推理链，只有最后一个助手轮次（连同它的推理轨迹）贡献损失，缺乏推理轨迹的对话会被排除，而且为了放大多轮对话数据的有效信号，每段多轮对话最多会产生5个训练样本（通过在连续助手轮次上滑动损失目标实现）。

两个SFT版本的数据涵盖多个大类。通用对话和指令跟随，包括开放域问答、阅读理解、多选题和短格式指令跟随。单轮编码，涵盖多种编程语言的代码生成、编辑、解释和翻译，有专门针对C++、Python、C#、JavaScript和TypeScript竞赛编程的子集。智能代理编码，包括长程交互代理轨迹（早期和修订版），包含SWE风格的仓库级编辑任务，为模型提供导航代码库、规划多步骤编辑、验证中间结果的模式。工具使用和函数调用，涵盖通用函数调用格式、Bash执行、澄清工具和搜索工具，教会模型正确调用工具并从工具错误中恢复。推理轨迹，包含带有思维链的示例，涵盖数学、代码和通用推理，在处理时为Instruct变体过滤掉。安全数据，来自开放许可安全语料库，目的是减少有害输出而不损害良性代码提示的有用性。身份示例，一小组自我标识对话，过采样3倍，让模型可靠地以"Mellum 2"介绍自己。有趣的是，在没有这类数据的初始训练中，模型始终把自己描述为谷歌开发的AI助手，尽管训练中没有使用任何谷歌模型生成的合成数据。

SFT训练从长上下文YaRN检查点初始化，与预训练使用相同的分布式Muon优化器，在各自的打包数据集上训练三轮。学习率峰值为3×10??（预训练峰值的十分之一），余弦衰减至3×10??（峰值的10%）。MoE辅助负载均衡系数从10??降至10??，因为路由器在预训练后已经均衡，更小的系数避免在较窄的SFT分布上过度约束专家利用率。Instruct版本消耗约470亿词元，Thinking版本消耗约1670亿词元。

**九、用奖励机制打磨最终技能**

SFT之后是强化学习（RL）阶段，用程序可验证的奖励信号（RLVR）进一步精炼。选择RLVR而非依赖人类反馈强化学习（RLHF）的原因是：训练语料库中每个提示都有明确的程序化正确性检查方法，不需要训练一个单独的奖励模型（那个模型的误差会污染梯度信号）。

RL基础设施分为训练节点（持有策略权重、运行梯度更新）和推理节点（托管生成引擎、产生训练样本）两组，由Ray调度、Kubernetes编排。训练用NeMo-RL框架，通过Megatron-Bridge配置，精度与预训练相同（BF16/FP8混合）。生成用vLLM。奖励计算独立运行在单独的微服务集群，通过验证网关路由到不同后端：代码执行沙箱（基于单元测试）、数学答案验证器（符号和数值比较）、LLM-as-a-Judge服务（评判自由形式输出），以及其他专用环境（如有状态工具对话的会话管理）。

RL数据分为Instruct和Thinking两套组合，各约26万条训练提示和3600条验证提示，按能力领域分布。代码域各占22%，各57500条。数学域在Instruct中占23%（6万条），Thinking中占28%（7.2万条）。智能工具使用在Instruct中占14%（3.6万条），Thinking中占12%（3.1万条）。指令跟随在Instruct中占19%（4.95万条），Thinking中占21%（5.35万条）。推理在两套中各占13%（3.5万条）。知识在Instruct中占9%（2.25万条），Thinking中仅占4%（1万条），因为过多MCQA暴露会损害指令跟随质量。

代码域数据结合了竞赛编程题库、数学与代码配对数据集（让模型用Python执行工具解决数学问题，也计入数学域），以及研究团队自建的12种编程语言真实任务集——覆盖全新实现、从堆栈跟踪调试、测试生成、行为修改、文件系统与API集成、安全加固六类工作，每个任务附带测试套件，通过率定义奖励信号。

数学域数据以三种互补风格组成：纯数学（无工具，严格匹配验证）、带计算器工具的数学（模型发出计算器工具调用并使用返回值）、带代码执行的数学（用Python执行工具计算中间量）。

RL算法是GRPO（一种近端策略优化变体）的定制版本。损失在词元层面计算，每个有效生成词元对梯度贡献相同（遵循DAPO和Dr. GRPO的建议）。优势用留一基线计算，不做标准差归一化（遵循Dr. GRPO）。每个提示采样G个响应，过采样约1.5倍，丢弃组内奖励方差为零的提示组。PPO裁剪使用不对称范围（低裁剪低于高裁剪），"更高裁剪"设置让正优势更新比负优势更新流动得更自由（来自DAPO）。不使用KL惩罚项将策略锚定到SFT参考，与最近的大规模开放RL系统一致。

MoE路由器带来了一个特殊挑战：即使推理时和训练时用的是同一套权重，同一个隐藏状态可能被路由到不同专家，导致对同一词元的对数概率不同。研究团队用IcePop截断方法解决这个问题：对每个生成词元，只在训练-推理比率（ρ_t）处于[α, β]区间内时才保留其损失贡献，超出区间则直接归零，而不是像PPO裁剪那样压缩到边界值。这是更安全的做法，因为大ρ_t很可能是专家切换导致的，而不是真正值得应用的策略更新。

奖励塑形还加入了两条规则。一是软超长惩罚（来自DAPO）：在最大响应长度的缓冲区内，奖励在区间下边缘的原始分数和长度上限处的配置下限之间线性插值，超过长度上限的完全从损失中删除。二是简洁性惩罚，专门应用于非思考型响应：在早期Instruct运行中发现模型开始在没有think标签的情况下产生内嵌推理，与Instruct模型的部署规范相悖。这种"等等，我再想想"式的推理模式有相当稳定的词汇标记，研究团队按触发词数量分三个强度档乘性地缩减正确响应的奖励，只在这些词汇不属于合法输出的任务上应用。这个惩罚效果显著：在接近训练结束时采样的数学响应中，无简洁惩罚版本平均每个响应有7.3个反思触发词（每千字符0.75个），而启用惩罚的生产版本只有0.6个（每千字符0.21个）。

RL超参数两个阶段共享，每步256个提示，每提示16个生成，全局批量大小4096，过采样因子1.5倍，轨迹最大滞后2步，PPO裁剪范围0.2/0.28，IcePop区间[0.5, 5.0]，KL系数为零，AdamW优化器（β?=0.9, β?=0.999，权重衰减0.01），峰值学习率1×10??，衰减至1×10??，梯度范数上限1.0，最多10轮工具调用。主要差异在于：Instruct最大序列16384词元，训练500步；Thinking最大序列40960词元（需要更长思维链），训练100步，每步微批次大小降至1。

**十、实战表现：哪里强，哪里弱**

预训练评估将Mellum 2 Base与OLMo-3-7B、Qwen2.5-7B、Qwen3-4B-Base和Qwen3.5-4B-Base对比。尽管只激活25亿参数，Mellum 2在多个推理和代码任务上能与7B密集模型竞争甚至超越。在MMLU-Pro（高级多任务知识测试）上达到59.3%，超过Qwen3.5-4B（52.4%）和Qwen2.5-7B（48.6%）。BBH（复杂推理）达74.9%，超越OLMo-3-7B（63.6%）、Qwen2.5-7B（69.0%）和Qwen3-4B（71.3%）。GSM8K（数学文字题）达81.7%，与Qwen2.5-7B（81.9%）和Qwen3-4B（82.0%）持平。MBPP/MBPP+（代码生成）分别达62.4%/61.4%，超越OLMo-3-7B和Qwen3.5-4B。GPQA Main（研究生级科学问答）达35.0%，超越OLMo-3-7B（27.9%）和Qwen2.5-7B（34.2%）。相对薄弱的是HumanEval（41.5%），不过后训练阶段显著提升了这个指标。

后训练评估则将两个变体与Qwen3.5-4B、Qwen3.5-9B、OLMo-3-7B、Ministral-3-14B、Seed-Coder-8B对比，覆盖代码、工具使用、数学、知识、对话和安全七个能力域。

在代码域，EvalPlus（HumanEval+和MBPP+的平均，测试函数级代码合成能力）上Mellum 2-RL达78.4%，领先所有对比模型，包括Qwen3.5-9B（71.8%）和代码专用的Seed-Coder-8B（73.8%），这正是预训练数据直接针对的领域。LiveCodeBench v6（竞赛编程）上Instruct变体为37.2%，落后Qwen3.5系列（51.0%和63.7%），但Thinking变体的SFT版本达75.1%，成为测试组中的最高分，领先Qwen3.5-9B-Thinking 6.8个百分点，说明算法推理在模型能力范围内，但需要显式思考预算才能释放。MultiPL-E（多语言代码）居中。

在工具使用域，RL带来了最大的单步提升：BFCL v3（多轮函数调用）从43.1%跳至66.3%（Instruct），Thinking变体的SFT到RL从60.5%升至69.4%，超过Qwen3.5-9B-Thinking（68.5%）。BFCL v4（加入智能网页搜索和记忆工具）上，Mellum 2-RL-Thinking以45.6%领先全组，高于Qwen3.5系列（42.9%/42.7%）。

数学域同样受益于RL：AIME（高中数学竞赛，2025和2026各30题）从SFT-Instruct的29.9%提升至RL-Instruct的41.7%，Thinking模式从20.0%提升至58.4%。SFT-Thinking的AIME得分低于SFT-Instruct，研究团队认为这是因为Thinking头需要经过RL阶段的数学推理训练才能正确校准。GSM-Plus（数学鲁棒性测试）RL-Thinking达87.0%，接近Qwen3.5-9B-Thinking（90.7%）。

知识域是最明显的弱点：MMLU-Redux和GPQA Diamond上Qwen3.5系列领先显著（91.1%/79.8% vs. 78.1%/40.9% Instruct），GPQA（研究生级科学问答）尤为明显，这直接反映了训练数据倾向代码和开发者文档而非广泛百科知识的权衡。

对话域呈现有趣分化：JetBrains内部对比Qwen2.5-7B-Instruct的配对胜率，Mellum 2-RL-Thinking以69.5%领先全组，高于Ministral-3-14B-Thinking（63.8%）和Qwen3.5-9B-Thinking（56.7%），说明在代码感知的开发者场景下，领域熟悉度转化为了真实优势。而在通用对话（IFEval、MixEval）上则居中。BS-Bench（测试对错误前提的反驳能力）上Mellum 2得分14-24，明显低于Qwen3.5系列（56-70），说明SFT/RL信号倾向服从而非反驳，这是后续版本需要改进的方向。

安全域上，SFT-Instruct在HarmBench（有害率，越低越好）上以8.4%成为Instruct表格中最安全的模型，Ministral-3-14B（56.5%）和Seed-Coder-8B（40.0%）远高于此。RL变体退步至23.1%，与偏好优化阶段放松拒绝行为的已知现象一致，这是研究团队明确标注的待改进项。XSTest（安全合规率）上Mellum 2落后最大基准模型约10个百分点，说明有些安全提示被过度拒绝，与HarmBench退步构成对称问题，需要联合优化。

**十一、跑得快才能留得住：推理效率的实测数据**

在实际部署速度测试中，所有对比在单张H100 GPU（80GB）上使用vLLM服务和动态FP8量化，以代码补全生产工作负载为代表性测试场景（平均输入2304词元，平均输出256词元），测试同步模式（单请求串行延迟）和吞吐量模式（并发高负载持续处理）。

结果数据：同步模式下Mellum 2达192词元/秒，与Qwen2.5-7B的193词元/秒几乎持平，Qwen3-8B只有169词元/秒。吞吐量模式下Mellum 2达5179词元/秒，比Qwen2.5-7B（4283词元/秒）高21%，比Qwen3-8B（2897词元/秒）高79%。持续请求率分别是Mellum 2每秒20.2个请求，Qwen2.5-7B每秒16.7个，Qwen3-8B每秒11.3个。这说明Mellum 2完美达成了设计目标：单请求延迟匹配7B密集基准，并发服务能力大幅领先。

**未来的路和尚待解决的问题**

归根结底，Mellum 2是JetBrains在一个具体工程约束下的认真探索：给定一张普通显卡、一个速度预算，如何在这个约束下塞进尽可能多的能力。他们的答案是120亿总参数、25亿活跃参数的MoE结构，加上层选择性滑动窗口注意力和多词元预测头。

这套方案在代码合成、工具调用、数学推理上表现可观，在广泛世界知识和安全反驳上还有明显差距。研究团队没有回避这些弱点，并且明确指出了下一步方向：把模型推向更复杂的软件工程仓库级任务（SWE RL方向），扩大RL基础设施和环境覆盖，以及重新审视长上下文中期训练数据的配方。此外，他们还打算在下一个版本切换到无辅助损失的负载均衡方案，并重新评估混合注意力架构（如Gated DeltaNet）——前者随着开源推理框架的支持逐渐成熟，后者在短上下文推理效率方面的劣势也在随着内核优化而缩小。

更长远地看，选择架构时以固定推理预算为约束条件的设计方法，本身也为未来更大、依然关注推理效率的Mellum打开了门。所有基础、Instruct和Thinking检查点都以Apache 2.0许可证开放，感兴趣的研究者和开发者可以通过arXiv编号2605.31268v1找到完整技术报告。

Q&A

Q1：Mellum 2的MoE架构和普通AI模型有什么区别？

A：普通模型每次处理都激活全部参数，而Mellum 2的MoE架构在64个"专家"中每次只激活8个，相当于拥有120亿参数的知识储备，但实际运算量只有25亿参数级别。这让模型能在普通显卡上以较低的计算成本提供更强的知识覆盖，推理速度与7B密集模型相当甚至更快。

Q2：Mellum 2的Instruct版和Thinking版有什么区别？

A：Instruct版直接给出答案，不展示推理过程，适合需要快速响应的日常编程任务。Thinking版在回答前会先生成一段内部推理链，类似于先在草稿纸上推演再写答案，在数学竞赛题和复杂算法问题上表现更好，LiveCodeBench上Thinking-SFT版本以75.1%领先所有对比模型。

Q3：Mellum 2的长上下文扩展是怎么做到的？

A：研究团队采用了"层选择性YaRN"技术，只对全局注意力层调整位置编码频率，让滑动窗口层保持原参数，将上下文从8192词元扩展到131072词元（约128K）。关键发现是训练约300亿词元后质量就已接近上限，但路由器还在持续适应，因此将训练延长到1170亿词元让路由器充分稳定。