先说结论：这份 benchmark 测的根本不是模型有多聪明，是工具 schema 有多蠢。拿它照一照，照出来的不是模型智商，是接口设计的原形。
同一个任务，同一批模型，同一批 330 个 ID。工具直接返回计数，全体答对！工具返回原始行、让模型自己数，10 个模型里 5 个在 21 道题里答对不超过 10 道。
count_ids 工具返回计数 330 IDs / 21 题 → 除 gpt-oss-20b 外全对
list_ids 模型自己数 330 IDs / 21 题 → 8 个模型里 5 个 ≤ 10/21
差了一个返回字段。
这也配叫能力差距？这是把一件 O(1) 的事，硬塞给一个按 token 计费的东西去做 O(n)。
而且模型不是听不懂话。过滤条件那边，10 个模型每次都把「不少于 244」正确翻成 id >= 244，一次没翻错。错的全部发生在数数这一步。
模型没输在理解，输在算术，却输得毫无自觉。
数错不要紧，数错了还给你一个自信的数字
list_ids 那 21 道题里，所有错误答案都是单个、干净、毫不犹豫的数字。
没有一个模型返回“我不确定”，没有一个报错。
Gemini 3.7 Flash 那次更绝。把 1100 个 ID 塞进上下文，输出上限开到 8192 token，它在 list_ids 上答对 1/21。把上限撤掉，同样的模型答对 19/21 和 15/21——而两次它都照样给了你一个数字。
第一次那个 1/21，不是它不会，是它数到一半被截断了，然后对着截断的结果继续给你报数。
这种失败模式比直接报错恶心十倍！因为下游代码会开开心心地把这个数字写进数据库。
真正扎眼的不是准确率，是账单
按每题输出 token 分组，模型干净利落地劈成两拨：
高 token 组 330 IDs 每题 2700 – 8200 token 答对 15 – 21 / 21
低 token 组 330 IDs 每题 < 600 token 答对 0 – 10 / 21
低 token 组不是省，是压根没在数！
GPT-5.4 nano 在 11、110、330 三种规模下每题都稳定吐约 35 token，330 个 ID 时 list_ids 答对 0/21。它从第一条题到最后一条题都在敷衍你，用同一个长度敷衍你。
另一边，Gemma 4 26B A4B 在 330 个 ID 上答对 20/21，每题 8153 token——是它自己跑 count_ids 时成本的 18.6 倍。Gemini 3.8 Flash 全对 21/21，每题 2742 token，14.3 倍。
这就是评论里那位说的隐藏成本：你为了省掉一行 count()，把 330 行原始数据灌进会话历史，后面每一次调用都要扛这些 token 的缓存和延迟。
最贵的那位最有意思。Claude Opus 5 是整轮里单价最高的模型，list_ids 上每题只花 579 token，答对 9/21。它的 token 全花在价格上，没花在计数上。
价格和参数量都不能预测它落哪一组。 这轮里唯一稳定的规律是：同一个模型在几次重跑里始终在同一组，组内排序才有点波动。也就是说，这不是随机波动，是稳定的习惯。
该给的分还是得给
丑话说在前面，count_ids 那一侧是真的漂亮。
11 个 ID 到 330 个 ID，每题输出 35 到 451 token，基本不随列表长度增长。21 道 330 规模的题全对。
这份设计我原本预期会有个别模型在长列表上掉链子，结果没有——预期拉满被往好的方向打脸了一次。
还有那个把全部 ID 放进提示词、配 run_python 的版本：10 个模型 7 个 68 题全对。也就是说模型只要被允许写代码，它就自己去写循环了，根本不屑于一行行数。
这条我记下来：给模型一条代码路径，比给它一万 token 的上下文有用。
（顺带说一句，Gemini 2.5 Flash 在那个任务上 110 和 330 规模的 42 道题里只调了 1 次工具，拿 37 分。它就是硬数，还数得不错。这种我服！）
别急着看榜
那批被排除的模型里，有因为 Kaggle 模型代理不支持带 reasoning_effort 的函数工具被刷掉的，也有在多数调用里返回 429 或 503 的。这些都不算数。
但它们会不会在排行榜上留点痕迹？
会。排行榜单元格显示的是这个模型最近一次运行的结果。一次配额失败的空跑，能把之前跑完整的那份成绩直接盖掉。
所以看榜之前先干两件事：确认配额，以及配额失败之后把配对任务重跑一遍。不然你看到的那格数字，可能是一具尸体。
还有个更实在的坑：Kaggle 模型代理按输出上限预留最坏情况费用。不设上限时，GPT-6 Astra 单次调用预留 6.40 美元，Claude Opus 5 预留 3.20 美元。把 max_completion_tokens 设成 8192，预留就掉到几美分。
跑 benchmark 跑到钱包出血，多半就是没设这个参数！
锐评评分卡
这题值不值得现在跟？值得——但跟的方向别搞错了。
这不是一份“某某模型更聪明”的排名，是一份 API 设计的事故报告。当工具已经知道自己返回了多少行、最小值和最大值是多少，还让模型拿原始列表去数，这不是模型能力问题，是接口设计缺陷——而且这缺陷是按 token 计费的，跑得越久越贵。
把这钱花得冤不冤？ 花在列表