上周三我们团队在做一个客服对话摘要的项目，需要选一个主力模型。老板的原话是"便宜的那个，但别太拉胯"。MiniMax 上个月刚发了 M2.5，价格确实便宜得离谱，但到底能不能打？我花了两天时间跑了一轮对比，把数据贴出来给大家参考。

说实话一开始我是拒绝拿 MiniMax 跟 Claude 比的，毕竟定位差太多。但跑完数据发现 M2.5 在某些场景下的表现确实超出预期，不是那种"便宜没好货"的感觉。

先说结论

Claude Sonnet 4.6 综合能力依然是第一梯队，但 MiniMax M2.5 在长文本处理和中文生成上性价比极高。如果你的场景是中文为主的文本处理（摘要、改写、客服），M2.5 完全够用，成本能省 70% 以上。代码生成和复杂推理，还是老老实实用 Claude。

评测维度

这次我测了三个大方向：

• 代码生成：用 HumanEval 的 50 道题 + 我们项目里 10 个真实的 Python 函数补全
• 长文本理解：喂 50K token 的中文会议记录，要求提取关键决策和 action items
• 逻辑推理：GPQA 里抽了 30 道物理/数学题 + 5 道多步推理的业务逻辑题

每个测试跑 3 遍取平均值，温度统一 0.3。

评测结果天梯图

维度	MiniMax M2.5	Claude Sonnet 4.6	备注
HumanEval Pass@1	78.2%	89.6%	Claude 领先明显
真实函数补全（10题）	6/10	9/10	M2.5 在异步代码上翻车
50K 中文摘要准确率	91.3%	93.7%	差距不大
摘要遗漏关键信息	1.2 条/篇	0.4 条/篇	M2.5 偶尔漏掉隐含决策
GPQA 物理/数学	52.1%	71.8%	差距拉开了
多步业务推理	3/5	5/5	Claude 全对
平均首 token 延迟	380ms	520ms	M2.5 快不少
输入价格 (per 1M tokens)	¥1.0	¥21.6	差了 20 倍
输出价格 (per 1M tokens)	¥8.0	¥108	差了 13 倍

Claude Sonnet 4.6

没什么悬念。代码生成这块 Claude 依然是同级别里最能打的，HumanEval 89.6% 的 Pass@1 跟上个月我测 GPT-5.5 的 91.2% 差不了多少。

让我印象深的是那 10 道真实函数补全——其中有一道是我们项目里一个比较恶心的异步队列消费逻辑，涉及到 asyncio.gather + 超时重试 + 死信队列。Claude 直接一把过，连 edge case 的 type hint 都给补上了。M2.5 在这道题上生成了一个看起来对但实际会死锁的版本。

推理能力更不用说了，GPQA 71.8% vs 52.1%，这个差距在复杂场景下会被放大。

但 Claude 的问题也很现实：贵。我们项目每天大概处理 2000 条对话摘要，平均每条输入 3K token、输出 500 token。算下来：

每天输入：2000 × 3000 = 6M tokens → ¥129.6
每天输出：2000 × 500 = 1M tokens → ¥108
日成本：¥237.6
月成本：¥7,128

对我们这种小团队，一个月七千多就为了做摘要，有点肉疼。

MiniMax M2.5

M2.5 的定位很清晰——中文场景的性价比选手。长文本摘要 91.3% 的准确率，跟 Claude 只差两个多点。关键是价格：

同样的日处理量：
每天输入：6M tokens → ¥6.0
每天输出：1M tokens → ¥8.0
日成本：¥14.0
月成本：¥420

一个月 420 vs 7128，差了 17 倍。测完数据我人傻了。

不过 M2.5 也有明显短板。代码生成的时候，它对 Python 类型系统的理解比较浅，生成的代码经常缺少类型标注，对 async/await 的模式掌握不太行。还有一次它给我生成了一个用 threading.Lock 的方案，但我的上下文明明写的是 asyncio——它没读懂。

推理这块，52.1% 的 GPQA 分数说明它在需要多步逻辑链的场景下还是会断。我测的 5 道业务推理题里，有 2 道它给出了看起来合理但逻辑链断了一环的答案。

调用链路对比

graph TD
 A[业务代码] --> B{场景判断}
 B -->|代码生成/复杂推理| C[Claude Sonnet 4.6]
 B -->|中文摘要/对话处理| D[MiniMax M2.5]
 C --> E[聚合 API 网关]
 D --> E
 E --> F[结果返回]
 F --> G[后处理 + 质量检查]
 G -->|质量不达标| H[fallback 到 Claude]

我们最后的方案就是上面这个——按场景分流。摘要类任务走 M2.5，代码和推理走 Claude，M2.5 输出质量不行的时候 fallback。

踩坑记录

跑测试的时候遇到几个坑：

1. MiniMax 的 max_tokens 行为不一致

设置 max_tokens=2048 的时候，M2.5 有时候会在 1500 左右就停了，返回的 finish_reason 是 stop 而不是 length。排查了半天发现是它内部有个重复检测机制，觉得内容开始重复就自动停了。解决办法是把 repetition_penalty 从默认值调到 1.05。

2. Claude 的 429 限流

测试跑到一半收到了这个：

Error code: 429 - {'type': 'error', 'error': {'type': 'rate_limit_error', 'message': 'Number of request tokens has exceeded your per-minute rate limit'}}

Anthropic 官方的 RPM 限制对 Sonnet 4.6 是 4000 RPM，但 TPM 限制才是真正的瓶颈。我的测试脚本并发太高了，每分钟打了 800K tokens 进去。后来改成用聚合 API 走多通道分流才解决——OpenRouter 收 5.5% 手续费，ofox.ai 是 0% 加价直接对齐官方价格，我们最后用的后者，改个 base_url 就行。

from openai import OpenAI

# 走聚合网关，自动负载均衡避免单通道限流
client = OpenAI(
 api_key="your-key",
 base_url="https://api.ofox.ai/v1"
)

response = client.chat.completions.create(
 model="claude-sonnet-4.6",
 messages=[{"role": "user", "content": "..."}],
 max_tokens=2048
)

3. M2.5 的 JSON mode 偶尔抽风

要求输出 JSON 的时候，大概有 3% 的概率会在 JSON 外面包一层 markdown 代码块。我加了个正则后处理才稳定住：

import re, json

def safe_parse(text):
 # 去掉可能的 markdown 代码块包裹
 cleaned = re.sub(r'^```(?:json)?\n?|\n?```$', '', text.strip())
 return json.loads(cleaned)

不同需求怎么选

说几个典型场景：

日常中文文本处理（摘要/改写/分类）→ MiniMax M2.5。准确率够用，成本低到几乎可以忽略。我们的客服摘要场景切过去之后，月成本从七千降到四百多，质量只掉了 2-3 个点。

代码生成 / Copilot 场景 → Claude Sonnet 4.6。这个没啥好犹豫的，M2.5 写的代码你还得花时间 review 和修 bug，算上人力成本反而更贵。

复杂推理 / 数学 / 多步逻辑 → Claude Sonnet 4.6，或者直接上 Opus 4.7。M2.5 在这类任务上的错误率太高，不适合放在需要高可靠性的地方。

预算极其有限的个人项目 → M2.5 无脑选。一天处理几百条请求的话，月成本可能就几十块钱。

小结

这次对比下来，我的感受是：2026 年选模型已经不是"谁最强"的问题了，而是"什么场景用什么模型"。M2.5 不是 Claude 的替代品，但在它擅长的领域（中文长文本、高并发低成本场景），确实是个很实在的选择。

M2.5 下个版本能不能补上推理的短板我不好说——MiniMax 的迭代速度挺快的，但目前代码和推理这两块跟 Claude 的差距肉眼可见。反正我们现在的方案就是混着用，按场景分流，月底算账的时候老板终于不皱眉头了。