三个模型差点被误判报废，问题出在"思考模式"

一次基准测试，三个模型得分不到15%。Kimi K2.5只有10%，MiniMax M2.5勉强15%，Gemma 4更是每次调用都返回HTTP 400错误。我差点把它们从候选名单里划掉，标记为"故障模型"。

但它们没坏。坏的是我的调用方式。

这篇文章记录了我踩过的坑，以及你在给自己的智能体系统选型时，如何避免同样的时间浪费。

空回复与超时：异常现象复盘

Kimi K2.5的10%得分是怎么来的？每次返回恰好300个token的空白内容。finish_reason显示为"length"——模型还没开始输出可见答案，token预算就已经耗尽。

MiniMax M2.5的情况类似，但更严重。某个任务跑了88分钟，消耗98000个token后，我被迫手动终止。Gemma 4则干脆拒绝所有请求，每次返回HTTP 400。

三个不同厂商的模型，三种不同的故障表现，根源却完全相同。

默认开启的"思考模式"

这些模型出厂即启用内部思维链推理。每个请求都会先静默"思考"，消耗大量token，然后才生成可见输出。当max_tokens设置为300时，思考过程就把额度吃光了，留给实际答案的空间为零。

问题在于，关闭这个功能的参数名称，三家各不相同：

Kimi K2.6需要设置reasoning: {"effort": "none"}，这会完全禁用内部推理，推理token归零。

MiniMax M2.7使用include_reasoning: false，但这只是隐藏思考过程不让用户看见，模型内部仍会消耗约400个token。必须把max_tokens提升到2000才够用。

Gemma 4同样用include_reasoning: false，但还要注意模型ID的格式——需要加-it后缀，26B变体还要加-a4b。

这些细节分散在各家的文档角落，没有统一标准。

修正后的排名逆转

调整参数后，成绩完全改观。Kimi K2.6从10%跃升至75%。MiniMax M2.7从15%提升到60%。Gemma 4 31B从"无法连接"变成80%——在所有18个测试模型中排名第二。

最意外的是MiniMax的隐藏实力。在它成功完成的6个任务上，M2.7得分97.2%，超过Claude Sonnet 4。这个模型在能正常输出时，表现是基准测试中的最佳水平。

但致命缺陷也在这里：它有40%的任务失败率。强制性的内部推理无法关闭，输出预算被提前耗尽，导致答案难产。这是一个 brilliance 与 reliability 无法兼得的案例—— brilliant model you can't rely on，作者如此评价。

四个自查信号

如果你的基准测试结果看起来不对劲，按以下顺序排查：

第一，finish_reason为"length"且内容为空。这是思考模式在吞噬token预算的信号。尝试reasoning: {"effort": "none"}或include_reasoning: false。

第二，全部HTTP 400错误。检查模型ID是否缺少后缀，-it、-a4b、-preview等变体标识容易被忽略。

第三，得分异常低但有实际输出。模型可能不是错了，而是话太多。检查它是否无视了"只输出代码"之类的指令。

第四，某个任务消耗量是其他的50倍。这说明该模型在这类任务上陷入了病态思考循环。这是有价值的数据，不是bug——记录下来，避开这个组合即可。

文档缺口与选型成本

作者为此浪费了一个上午调试参数，而这些信息本该出现在官方文档的显眼位置。对于正在为自己构建智能体技术栈的团队，这个教训很直接：先看推理配置，再跑完整基准。

完整测试结果覆盖18个模型，每日更新，地址见benchmarks.workswithagents.dev。