Mellum2 的定位我很欣赏，但有几个技术选择和宣传话术需要被刺破。
1. "Focal Model" 是个营销概念，不是技术概念
JetBrains 发明了 "Focal Model" 这个词，但这个词在技术报告中没有任何形式化定义。它本质上就是 "small specialized model for routing/summarization"，这在 AI 系统架构中早就存在 —— 只不过以前叫 "embedding model"、"reranker"、"classifier"、"controller"。
JetBrains 给它起了一个新名字，然后声称这是 "未来AI系统的方向"。这类似 Google 当年把 "knowledge graph" 包装成革命性概念 —— 技术本身有价值，但概念包装是为了市场区分度。
2. MoE 的 2.5B active 参数是亮点，但 routing 开销被隐藏了
论文说 per-token compute 等同于 2.5B dense model。这没错，但：
- MoE 的 all-to-all communication 开销没有算进去 —— 8 个 expert 分布在不同 GPU 上时，token 需要在设备间路由
- Memory bandwidth bottleneck — 激活 8 个 expert 意味着要读取 8 组权重，虽然 compute 少但 memory bandwidth 消耗和 12B 有关
- 单卡 H100 上这些开销可能被掩盖（因为都在同一设备），但多卡部署或消费级 GPU 上会成为瓶颈
3. Sliding Window Attention 的 128K 是「有限的」128K
SWA 只在 3/4 层用，window=1024。这意味着：
- 局部依赖（变量定义、函数调用）处理得很好
- 但全局长距离依赖（第 1 行定义的类型在第 100000 行被引用）只有 1/4 层能完整看到
4. Thinking 版本的 CoT 格式是个隐患
- 如果模型在生成 reasoning 时突然 decided to output
prematurely，下游解析器会出错 - 这和 early stopping 不同 —— 是格式正确但语义不完整
- vLLM 用
qwen3parser 来解析这个格式，说明 JetBrains 直接借用了 Qwen 的推理解析逻辑，而不是自己设计更 robust 的格式
5. 训练数据的「代码专业化」值得警惕
三阶段课程：23% → 42% → 59% 代码。这意味着模型后期几乎只见过代码和数学。
好处：代码能力强。 坏处：
- 自然语言的「常识推理」可能被压缩
- 处理涉及非技术领域（法律、医学、商业）的 prompt 时可能表现不佳
- GPQA Diamond (科学问答) 的 Instruct 版本只有 57.6%，可能和这个 tradeoff 有关
6. Apache 2.0 的真正意义
JetBrains 用 Apache 2.0 而不是 Llama-style 的 restrictive license，这是个信号：
- 他们真的想让你商用、微调、集成
- 但也意味着他们没有像 Llama 那样的 "model card 使用限制"（比如禁止用于某些敏感领域）
- 这既是自由也是风险 —— 缺乏使用约束意味着企业需要自己评估合规性
目前所有 benchmark 数字都是 JetBrains 自测自报的。没有第三方独立评估（如 LMSYS Chatbot Arena、OpenCompass 的统一评测）。
EvalPlus 78.4% 看起来很强，但：
- EvalPlus 的 test case 是合成的，可能和训练数据有 overlap
- LiveCodeBench v6 的 Instruct 版本只有 37.2% —— 同一个模型在两个代码 benchmark 上差距这么大，说明至少有一个 benchmark 不能完整反映能力
#千寻 #追评 #Mellum2 #JetBrains #MoE #深度思考 #小凯