MiniMax-M2.7 实测：离 Claude 还有多远？

起因

每次有国产编程大模型发布，我都会关注一个问题：它的代码能力跟 Claude 还差多远？ 我们此前写过一篇文章，介绍如何将复杂的模型适配任务拆解为 TDD 驱动的 Skill，Claude Opus 4.6 能直接通过，但国产 SOTA 编程模型 GLM-5 没能跑通。从那之后我就一直在等：什么时候能有一个国产模型通过这个测试？

3 月 18 日，MiniMax 发布了 M2.7。官方公告中给出了一组亮眼数据：M2.7 在 40 个复杂 Skills（> 2000 Token）上保持 97% 的 Skills 遵循率，在 OpenClaw 使用和 MMClaw 评测中接近最新的 Sonnet 4.6。看到公告的当天，我就决定立刻测试——既然 M2.7 宣称在复杂 Skills 上有极高的遵循率，那它能不能通过我们这个真实工程任务？

测试设计

任务

在 MNN 推理框架中端到端地支持 LFM2-350M 模型的导出和推理。LFM2 是 Liquid AI 提出的混合架构 LLM，包含两种 Decoder 层——ShortConv（短卷积门控线性注意力）和标准 Full Attention。任务的特殊之处在于 ShortConv 是一种全新的算子，仓库中没有现成模板可以直接套用。

同一任务此前已在 GLM-5 和 Claude Opus 4.6 上测试过：GLM-5 未通过，Opus 4.6 完全通过。这次加入 MiniMax-M2.7 作为新的测试对象。

一条指令触发全程，模型完全自主：

claude --dangerously-skip-permissions "请帮我支持 LFM2 模型（/home/yanxing/data/models/LFM2-350M），支持模型导出和推理；其中ShortConv算子实现在LinearAttention中，作为LinearAttention的一个type实现。"

为什么这个任务有区分度

这不是写一个函数或改一个 Bug，而是一个跨 7+ 文件、跨 Python/C++ 两种语言、跨导出/转换/推理三个阶段的端到端工程任务。仓库虽然提供了 Skill 指引文件，但 LFM2 的 ShortConv 机制与已有的 Attention/LinearAttention 都不同，不能简单复制粘贴。模型需要：

1. 读懂 LFM2 模型的 Python 源码，理解 ShortConv 的计算逻辑
2. 修改 Python 导出管道（配置映射、模型导出、自定义算子 ONNX 符号化）
3. 定义新算子的 Schema
4. 写 C++ 算子实现（含推理时的状态管理）
5. 确保导出和推理都能正确运行

测试过程

我一开始使用 MiniMax 赠送的 15 元免费额度进行测试，结果模型还在探索代码阶段额度就耗尽了——15 元大概只够模型读几轮代码文件。

于是我充值了 29 元/月的入门款 Coding Plan（可用额度：600 次模型调用 / 5 小时），继续之前中断的测试。由于 MiniMax-M2.7 的响应速度较慢，我直接把任务挂在服务器上，第二天查看结果。最终 API 耗时 53 分钟，wall time 13 小时 38 分钟（wall time 长主要因为模型响应慢加上编译等待）。Claude Code 的 /cost 命令推算的等价费用为 $190.19——这不是实际花费，但反映了 token 消耗量级。

测试结果

推理失败的报错：

Broad cast error, dim1 = 3072, dim2 = 1024
Compute Shape Error for /blocks.1/self_attn/Mul_output_0
code=3 in onForward, 602

MiniMax-M2.7 做对了什么

公允地说，MiniMax-M2.7 展现了不错的工程素养：

管线完整性：它正确识别了任务需要修改的所有层级——Python 模型映射、配置处理、导出逻辑、FlatBuffers Schema、ONNX 转换器、C++ 算子实现、算子注册——并为每个层级都产出了代码。模型导出阶段（Python → ONNX → MNN）没有报错，说明管线的”上半段”是通的。

模型映射准确：LFM2 的命名与标准 LLaMA 架构有不少差异（比如 default_theta 代替 rope_theta，operator_norm 代替 input_layernorm），MiniMax-M2.7 正确处理了这些映射关系。

C++ 代码规范：算子实现遵循了 MNN Execution 的标准范式——onResize 分配缓冲区、onExecute 执行计算、onClone 支持克隆，代码组织清晰。

问题分析

审查 MiniMax-M2.7 的代码变更后，我发现了四个问题，按严重程度排列：

1. 算子注册管线不完整（推理崩溃的直接原因）：MNN 的每个自定义算子都需要注册形状推理器，MiniMax-M2.7 遗漏了这一步。运行时不知道 ShortConv 算子的输出形状，后续算子维度不匹配，推理直接崩溃。如果按指令要求复用 LinearAttention 的管线，这步会被自动继承，根本不会出错。

2. 融合算子内外计算重复：C++ 算子内部已经完成了完整的 C * conv(B*x) 计算，但导出的计算图中又在算子外面多乘了一次 C，实际变成了 C² * conv(B*x)。即使修复问题 1，结果也是错的。

3. 卷积状态管理错误：Decode 阶段（逐 token 生成）需要维护滑动窗口状态，应保存最近几步的卷积输入，MiniMax-M2.7 存了卷积输出，且窗口滑动时机也不对。即使修复前两个问题，生成阶段结果仍然会出错。

4. 未遵循设计约束：指令要求”作为 LinearAttention 的一个 type 实现”，MiniMax-M2.7 创建了全新的独立算子，手动修改了约 180 行 Schema 生成代码，增大了出错面。

四个问题环环相扣：问题 4（未复用已有管线）直接导致了问题 1（遗漏形状推理），问题 2 和 3 则反映了对算子设计和有状态推理的理解不足。

效率分析

重点看 API 耗时和 token 用量——这两个指标不受模型响应速度影响，能真实反映模型的工作效率：

API 耗时差距：MiniMax-M2.7 为 53 分钟，Opus 4.6 为 14 分 30 秒，差距约 3.7 倍。这意味着 MiniMax-M2.7 经历了更多轮的编译-测试-修复循环，但始终没有定位到核心问题。

Token 用量差距：MiniMax-M2.7 消耗了 35.6M input tokens，Opus 4.6 仅 15.5K，差距约 2300 倍。即使考虑到大量 cache read（6.8M），MiniMax-M2.7 的策略仍然是”大面积反复阅读代码 + 多轮试错”，而非精准定位。

等价费用差距：按 Claude Code /cost 推算，$190 vs $6.57，差距 29 倍——消耗了 29 倍的 token，产出了 1.8 倍的代码变更，但最终没有通过。

结论

MiniMax-M2.7 的能力边界

MiniMax-M2.7 能读懂一个复杂的 C++ 框架项目，正确识别需要修改的所有子系统，并产出结构规范的代码。模型导出阶段（管线的”上半段”）完全跑通了。这本身已经是不低的能力水平。

但在这个任务上，它暴露了三个层面的短板：

1. 模式匹配 vs 深度理解：能模仿仓库中已有算子的注册模式，但无法推断出完整管线的所有必要步骤——遗漏了形状推理这一关键环节
2. 系统设计能力：在融合算子的输入输出边界设计上缺乏严谨性，导致内外计算重复
3. 执行效率：消耗了大量 token 反复阅读和试错，API 耗时是 Opus 4.6 的 3.7 倍，input tokens 更是 2300 倍，说明它在信息检索和决策上效率较低

用一句话总结：MiniMax-M2.7 能走完 80% 的路程，但最后 20% 正是区分”导出成功”和”推理可用”的关键。

关于”97% Skills 遵循率”

MiniMax 官方宣称的 97% 遵循率来自 40 个 > 2000 Token 的 Skill 测试。本次测试的 Skill（skills/support-new-llm/SKILL.md）确实超过 2000 Token，但它的难度不仅在于 Skill 的长度，更在于：

• 需要理解一个陌生的模型架构（LFM2 的 ShortConv），而非套用已知模式
• 需要跨 Python + C++ 两种语言、7+ 个文件协同修改
• 需要修改的每一处都必须独立正确，任何一处遗漏都会导致失败

这类需要深度理解框架全貌并做出正确设计决策的任务，可能是当前 Benchmark 难以充分覆盖的维度。在标准化的 Skill 遵循测试中拿到高分，与在真实工程场景中可靠地完成复杂任务之间，仍然存在显著的 gap。

写在最后

我对国产编程模型的期待是真诚的。GLM-5 没过的时候我就在等下一个，看到 MiniMax-M2.7 发布当天就去测了。结果虽然没有通过，但说实话 MiniMax-M2.7 的表现已经比我预期的好——它确实走完了大部分路程，管线搭建和模型导出都是对的。

这个任务本身就很难。它不是 Benchmark 里那种有标准答案的题目，而是一个需要理解陌生框架、做出设计决策、跨多个子系统协同修改的真实工程场景。目前只有 Claude Opus 4.6 能直接通过，这本身就说明了任务的区分度。

我会继续关注国产模型的进展，也会用同样的任务测试后续发布的新模型。期待有一天，能看到一个国产模型一次跑通这个测试。