北京
一次基准测试，Kimi K2.5得分10%，MiniMax M2.5得分15%，Gemma 4直接报错。作者几乎要把它们踢出候选名单——结果发现问题根本不在模型，而在调用方式。
这是Vilius Vystartas在2026年5月的真实经历。他原本想测试一批新模型的代理任务能力，却花了整个上午排查"故障"。最终发现，三个模型都没坏，只是默认开启了"思考模式"，在输出答案前就耗尽了token预算。
症状：空回复与超长耗时
Kimi K2.5的表现最诡异：每次返回正好300个token，内容却全是空的。日志显示finish_reason为length——模型还没开始写答案，预算就用完了。
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的坑在模型ID命名：需要带-it后缀，26B变体还要加-a4b。参数名倒是和MiniMax一样用include_reasoning: false，但作者之前根本没走到调参数这一步，因为ID错误直接400了。
修正后成绩翻天覆地：Kimi K2.6从10%跳到75%，MiniMax M2.7从15%升到60%，Gemma 4 31B从"无法连接"直接拿下80%——全场第二。
MiniMax的隐藏实力
在它能完成的6个任务上，M2.7得分97.2%，超过Claude Sonnet 4。这是该基准测试中的单任务最高分。
但致命伤无法忽视：它40%的任务会直接失败。强制内部推理无法关闭，输出预算被提前耗尽，导致模型空转。作者的评价很直接： brilliant model you can't rely on—— brilliant model you can't rely on。
这个矛盾揭示了一个行业现实：模型能力与应用可靠性是两回事。实验室分数漂亮，不代表能塞进生产管线。
排查清单：当基准成绩异常时
finish_reason:length加上空内容，等于思考模式在吞噬预算。优先尝试reasoning: {"effort": "none"}或include_reasoning: false。
全量HTTP 400先查模型ID。后缀-it、-a4b、-preview这些变体命名很容易踩坑。
分数低但输出存在，可能是模型话太多而非答错。检查它是否无视了"只输出代码"之类的指令约束。
单个任务耗时/耗token是其他任务的50倍以上，说明该模型在这类任务上有病理性思考循环。这是数据特征，不是bug。
作者把完整结果放在benchmarks.workswithagents.dev，每晚更新。18款模型的对比数据里，藏着更多类似的调用陷阱。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
