MiMo-V2-Pro 测评：同一模型，两种结局
起因
上一篇 MiniMax-M2.7 的评测发出后，很多读者留言希望我测试 MiMo-V2-Pro。作为当前国产推理模型的代表之一，MiMo-V2-Pro 在各大榜单上表现亮眼，自然是大家最关注的选手之一。
任务和上次完全一致：在 MNN 推理引擎中从零添加 LFM2 模型支持。这是一个 Tier 6 级别的任务——需要跨语言（Python 导出 + C++ 推理）、理解新的模型架构（ShortConv 短卷积门控线性注意力）、实现自定义算子，端到端跑通模型导出和推理。
先说结论：MiMo-V2-Pro 在 Claude Code 环境下 28 分钟完成实现，提醒一次后自主修复通过，在这个任务上接近 Claude Opus 4.6，代表了当前国产模型在复杂工程任务上的领先水平。
声明：我先后使用了 opencode 和 Claude Code 两个工具进行测试。opencode 使用的是免费额度，速度较慢；Claude Code 是自费充值 token，速度快且效果稳定。我对 opencode 使用经验有限，首测结果可能不完全反映 MiMo-V2-Pro 在该工具上的最佳表现，这里仅做记录对比。
测试结果
MiMo-V2-Pro 经历了两次测试，结果截然不同。
首测：opencode（免费额度）
| 指标 | 数据 |
|---|---|
| 工具 | opencode |
| 耗时 | 约 11 小时 |
| Token | 755K input + 141K output + 58M cache read |
| 花费 | ¥0（免费额度） |
| 代码变更 | 8 文件，+1618 / -1024 |
| 结果 | 导出失败 |
opencode 环境下的 MiMo-V2-Pro 产出了大量代码，但质量堪忧：model_mapper.py 多了 1329 行（大部分是格式化噪音），transformers.py 多了 675 行，还动了 model.py 265 行。代码量大但有效改动少，最终连 ONNX 导出都没跑通。
如果只看这个结果，MiMo-V2-Pro 的表现甚至不如 M2.7（后者至少导出成功了）。但我总觉得这不像是模型本身的能力问题——代码里的架构理解是对的（选择复用 LinearAttention、卷积方向正确），只是执行质量差。于是我决定换个环境重测。
重测：Claude Code（充值 token）
| 指标 | 数据 |
|---|---|
| 工具 | Claude Code |
| 耗时（API） | 28 分 40 秒 |
| 耗时（Wall） | 38 分 44 秒 |
| Token | 11.1M input + 85.7K output + 9.6M cache read |
| 花费 | ¥25.68（账户实际扣费） |
| 代码变更 | 6 文件，+297 / -44 |
| 结果 | 提醒一次后通过 |
第一次实现就能导出、能推理，但输出乱码。我只告诉它”测试输出是乱码”，没有做任何方向性引导（没有指出哪个文件有问题、没有提示 bug 类型）——它自己定位了问题并修复，第二次输出完全正确：
我是一个人工智能助手。它通过自然语言处理技术来理解和回应用户的询问。
同一个模型，换了工具环境，从”11 小时导出失败”变成”28 分钟提醒一次通过”。
代码分析
以下分析基于重测（Claude Code）的代码，修改共 6 个文件、+297/-44 行。
架构决策正确：复用现有的 FusedLinearAttention 管线，通过 attn_type == "short_conv" 分支区分，没有创建新算子、没有动 schema。相比 M2.7 创建全新 ShortConv 算子的方案，MiMo 的路径更轻量，也更符合 MNN 的设计理念。
Python 导出完整：模型映射、ONNX 自定义算子、导出路径三个环节都正确处理，仅用 +46 行完成映射、+4 行改动 custom_op。
C++ 实现规范：卷积方向正确（cross-correlation，与 PyTorch nn.Conv1d 一致），多线程并行，状态管理完备。存在 batch > 1 时的指针偏移小 bug，不影响标准 LLM 推理。
三模型对比
| 指标 | Claude Opus 4.6 | MiMo-V2-Pro（重测） | MiniMax-M2.7 |
|---|---|---|---|
| 最终结果 | 完全通过 | 提醒一次后通过 | 导出成功，推理失败 |
| 工具 | Claude Code | Claude Code | Claude Code |
| 耗时（API） | 14 分 30 秒 | 28 分 40 秒 | 53 分 31 秒 |
| Token 用量 | 15.5K in + 40.1K out | 11.1M in + 85.7K out | 35.6M in + 107.8K out |
| 花费 | ~¥45 | $62.44 | ¥29（Coding Plan） |
| 代码变更 | +414 / -40（~7 文件） | +297 / -44（6 文件） | +451 / -14（9 文件） |
| 架构决策 | 复用 LinearAttention | 复用 LinearAttention | 创建新 ShortConv 算子 |
| 卷积方向 | ✅ 正确 | ✅ 正确 | ❌ 内外重复 |
| ONNX 导出 | ✅ | ✅ | ✅ |
| C++ 推理 | ✅ | ✅ | ❌ 推理失败 |
| 自主调试 | 不需要（一次通过） | ✅ 仅告知乱码，自行定位修复 | 未验证 |
关键差异分析
Opus 4.6 vs MiMo-V2-Pro：两者的架构决策一致（都复用 LinearAttention），代码质量接近。核心差距在于 Opus 一次通过不需要人工干预，而 MiMo 首次输出乱码需要提醒一次。这说明 Opus 在实现完成后会主动验证结果的正确性，而 MiMo 缺少这一步。此外，Opus 的 token 效率远高于 MiMo（15.5K vs 11.1M input）。
MiMo-V2-Pro vs M2.7：差距体现在架构决策上。M2.7 选择创建全新的 ShortConv 算子，修改了 FlatBuffers schema、新增了 ONNX 自定义算子和 op 注册——这条路更重、更容易出错。M2.7 的 Python 导出管线实际上更完整（处理了 full_attn_idxs、layer_types 等细节），但 C++ 卷积实现有 bug，最终推理失败。MiMo 选了更轻的路，反而走通了。
两次测试的代码对比
| 维度 | opencode 首测 | Claude Code 重测 |
|---|---|---|
| 代码量 | +1618/-1024（8 文件） | +297/-44（6 文件） |
| 格式噪音 | 大量（model_mapper +1329 行） | 几乎没有 |
| 架构决策 | 正确（复用 LinearAttention） | 正确（复用 LinearAttention） |
| ONNX 导出 | 不完整 | 完整 |
| C++ 卷积方向 | 正确 | 正确 |
| 多线程 | 无 | 有 |
| 导出成功 | ❌ | ✅ |
| 推理成功 | ❌ | ✅（提醒一次） |
两次测试中 MiMo 的架构理解是一致的（都选择复用 LinearAttention，卷积方向都正确），说明模型本身的能力没有问题。差距主要体现在代码组织和执行效率上——opencode 环境下产生了大量低效的格式化改动，有效代码被淹没；Claude Code 环境下改动精准，每一行都有意义。
结论
MiMo-V2-Pro 在 Claude Code 环境下的表现让人刮目相看：28 分钟完成实现，提醒一次后自主修复并通过——这是继 Claude Opus 4.6 之后，第二个在这个任务上成功跑通的模型。
与 M2.7 相比，MiMo 的架构决策更轻量准确，代码更精简，最终走完了 M2.7 没走完的路。与 Opus 相比，MiMo 的差距主要在”最后一公里”的自主验证上——如果它能在输出结果后自己跑一遍验证，可能就不需要那次提醒了。
同时，这次测试也再次验证了一个规律：工具环境对模型发挥的影响是决定性的。 同一个模型在 opencode 下 11 小时导出失败，在 Claude Code 下 28 分钟提醒一次通过。模型能力是基础，但工具链的质量决定了这个能力能发挥几成。当然，我对 opencode 使用经验有限，这个结论仅供参考。
下一篇文章将加入 GPT-5.4、GLM-5、Kimi-K2.5、Qwen 等更多模型的测试数据，做一次完整的横向对比。敬请期待。
Enjoy Reading This Article?
Here are some more articles you might like to read next: