价格差了 20 倍，效果却差得有限：大模型的价格墙正在松动

TLDR

同一份代码审计任务，MiniMax M3 花 $0.07 找到 13 个问题，Claude Opus 4.8 最贵一档花 $3.39 也不过找到 15 个——便宜模型正在逼近专有模型的能力边界，这个趋势值得每个重度使用 LLM 的开发者认真对待。

引言

大模型的定价，一直有一道隐形的逻辑：贵的就是好的，好的就该贵。

这个逻辑最近开始动摇。Kilo 上周发布了一次测试：用同一份预埋了 17 个已知问题的 webhook 服务代码，分别让 Claude Opus 4.8 和 MiniMax M3 做代码审计，记录每次运行的费用、耗时和发现问题数。结果有点让人意外——MiniMax M3 花了 $0.07，找到了 13 个问题；Claude Opus 4.8 最便宜的一档花了 $1.30，同样找到 13 个；最贵的 max 档花了 $3.39，也不过找到 15 个。

价格差了将近 50 倍，能力差了 2 个问题。

我自己没有用过 MiniMax M3，没办法给出第一手的体验。但我用过 Claude Opus 4.x，从 4.7 升到 4.8，说实话感知不太明显——也许任务场景不同，也许差异在我日常用的场景里还没有明显体现。如果你用过 M3，欢迎在评论区聊聊实际效果，我很想知道这个测试结论在更多场景下是否成立。

测试是怎么设计的

Kilo 的测试设计有一个值得关注的细节：被审计的代码库不是随机找的，而是他们自己写的——一个用 TypeScript、Bun 和 SQLite 实现的 webhook 投递服务，接收事件、存储并向订阅者投递带签名的 payload。更关键的是，他们在代码里故意留了 17 个已知问题，覆盖安全、可靠性、正确性和测试覆盖率四个维度，然后用这份清单作为答题本，逐一核对每次审计报告。

每次运行使用相同的 prompt：

Treat this webhook delivery service as production-bound code and audit it for security, reliability, correctness, and test coverage, without editing any files. Write your report to audit.md.

把这个 webhook 投递服务当作即将上生产的代码，从安全、可靠性、正确性和测试覆盖率四个维度审计，不要修改任何文件，把报告写入 audit.md。

工具统一用 Kilo Code CLI，每次独立会话，不共享上下文，跑完记录 token 数、费用和耗时。

Claude Opus 4.8 跑了四档推理强度：medium、high、xhigh、max。MiniMax M3 没有同等的推理强度控制，只跑了一次默认设置。评分规则也很严格：某个问题必须被明确列为独立发现才算，部分提及不计数。

这个设计的好处是排除了大量干扰变量——输入固定、工具固定、评分标准固定，唯一变量就是模型和推理强度。结论因此可比，也因此刺眼。

数字说话

五次运行，结果如下：

MiniMax M3 的 token 用量也更少——比 Claude Opus 4.8 medium 少了 41%，比 xhigh 少了 53%。价格差来自两头：token 少，单价也低。

最让人意外的不是 M3 便宜，而是 Claude Opus 4.8 max 的表现。它是最贵的一档，比 xhigh 多花了 67%，耗时将近 10 分钟，但发现的问题数和 xhigh 完全一样——而且还漏掉了一个 xhigh 抓到的问题。多花的钱，没买到更好的报告。

如果按「每发现一个问题的费用」来算，MiniMax M3 的性价比遥遥领先，Claude Opus 4.8 max 垫底。

推理档越高，不一定越好

Claude Opus 4.8 的四档推理强度，结果没有呈现一条直线上升的曲线——这是这次测试里另一个值得细看的发现。

medium 和 high 都找到了 13 个问题，从 medium 升到 high，token 只多了 6%，费用却多了 48%，发现数没有任何变化——钱花出去了，什么都没多找到。

从 high 升到 xhigh 才算买到了东西：token 多了 17%，费用只涨了 5%，发现数增加了 2 个，是四档里性价比最好的一跳。但 xhigh 升到 max 就又掉回来了——token 数量甚至略有下降，费用却猛涨 67%，发现数纹丝不动，还丢了一个 xhigh 找到的问题。

更有意思的是 medium 和 high 抓到了一个 xhigh 和 max 都漏掉的 bug：async callback 跑在了 synchronous transaction 里面。推理强度越高，模型花的注意力越多，但注意力的分配方向变了——它在更深的地方挖，却可能错过了某些表层问题。

Kilo 在报告里写道：

Raising the reasoning level changed where the model spent its attention more than it changed how much the model checked.

推理档越高，改变的是模型注意力的分配方向，而不是它检查了多少。

这个结论对日常使用有直接的参考价值：如果你的任务是全面覆盖，不一定要拉满推理强度；如果你想要最高性价比的 Claude 单次审计，xhigh 是目前最合理的选择，max 基本没有理由用。

MiniMax M3 漏掉了什么

13/17 意味着有 4 个问题没有被找到。Kilo 的报告里，M3 漏掉的三个分别是：

• 无效 JSON 返回 500 而不是 400
• 数据库初始化代码在 import 时执行，而不是在启动时
• event 路由里有一个 async callback 跑在 synchronous transaction 里

值得一提的是，第三个问题（async callback）恰好是 Claude Opus 4.8 medium 和 high 找到、而 xhigh 和 max 也漏掉的那一个——这不是 M3 独有的盲点，更像是高推理强度模型的共同弱点。

这三个问题有个共同特点：它们不是会直接造成安全漏洞或数据丢失的致命问题，更多属于「代码质量和健壮性」层面。相比之下，M3 抓住的那些——返回 stored secret 的接口、签名计算用了不同的字节串、没有认证的路由——每一个都是真正的生产事故隐患。

换句话说，M3 的遗漏是有规律的：大 blocker 全捕到了，漏的是更细的代码实现问题。这不是随机的运气，更像是模型在有限的注意力下做了某种隐式的优先级排序。

对大多数审计场景来说，这个取舍是合理的。如果你的目标是「上线前最后一道安全检查」，$0.07 能找到全部高危问题，剩下的 3 个小问题靠 code review 补；如果你需要一份完整详尽的质量报告，那才是 Claude Opus 4.8 xhigh 的用武之地。

价格墙正在松动

这次测试的结论，放进一个更大的背景里看会更清楚：便宜模型追赶专有模型的速度，远比我们预期的快。

一年前，能做代码审计的模型基本只有 Claude 和 GPT-4 这一档。现在 MiniMax M3 在这个任务上和 Claude Opus 4.8 medium 打平，费用是后者的 1/18。这不是孤例——Gemini Flash、Qwen、DeepSeek 这些模型在各自的基准测试上也在持续逼近顶级专有模型的水位。

差距仍然存在，但它在收窄，而且收窄的速度比价格下降的速度更快。Claude Opus 4.8 xhigh 比 M3 多找了 2 个问题，但贵了将近 30 倍。这 2 个问题值不值 30 倍的价格，取决于你的场景——但这个问题本身在一年前根本不需要问，因为那时候根本没有能与之相比的便宜选项。

Kilo 在报告末尾也点到了这个趋势：

The broader trend worth watching is that cheaper models, including open-weight ones, are improving quickly and getting close to proprietary models like Claude Opus at a much lower price.

更值得关注的趋势是：更便宜的模型，包括开源权重模型，正在快速提升，以远低于 Claude Opus 的价格逼近专有模型的能力水位。

这句话的重量，比测试数据本身更大。

按任务选模型

Kilo 的测试给了一个很实用的决策框架，不用再凭直觉选模型：

• 大批量或预算有限的审计 → MiniMax M3。$0.07，13/17，5 分钟，主要安全问题全覆盖。
• 快速过一遍，要 Claude → Opus 4.8 medium。$1.30，同样 13/17，最快，还额外抓到了 async callback in synchronous transaction 这个高档漏掉的问题。
• 要最完整的单次报告 → Opus 4.8 xhigh。$2.03，15/17，性价比最好的高档选择。
• Opus 4.8 max → 基本没有理由用。贵 67%，慢 2 分钟，还不如 xhigh。

背后的逻辑很简单：不同任务对「覆盖率」和「成本」的权衡不一样。一次上线前的快速安全扫描，和一次需要归档留存的完整质量审计，本来就该用不同的模型。问题是过去没有便宜的好选项，只能默认用最贵的。现在选项多了，该想清楚自己真正需要什么。

这也是这次测试真正有价值的地方——不是告诉你哪个模型最好，而是逼着你回答：对你的场景来说，「够用」到底是什么水位。

当然，一个任务、一个代码库不足以说明全部——代码审计只是众多场景里的一种，换成代码生成、重构、调试，结论可能不同。但两件事是清楚的：第一，多个模型在多个基准上都指向同一个方向，便宜模型的追赶不是偶然；第二，别人的测试数据只能给你参考，真正有价值的是拿你自己的任务跑一遍，而不是等别人告诉你答案。