10款大模型计数能力实测：让模型自己数330个ID，最贵的Claude Opus 5只对了9次

核心洞察

这个测试最让我意外的不是模型数数会出错，而是贵的不一定对。Claude Opus 5Anthropic发布的旗舰级大语言模型，以高性能和高价格著称。 花了最贵的钱，数 330 个 ID 只对了 9 次；一个开源小模型 Gemma 4 26BGoogle发布的开源权重语言模型，参数量260亿。 反而对了 20 次。问题出在工具设计上：你让模型自己去数返回的列表，它就可能偷懒。

---

核心结论

1. 在 330 个 ID 的计数任务要求模型统计工具返回结果中满足特定条件的记录数量。中，当工具直接返回数量（count-engine）时，10 个模型中有 9 个答对了全部 21 道题，每题仅消耗 35 到 451 个输出 token，且 token 消耗不随列表长度增长。

2. 当工具返回 ID 列表、由模型自行计数（count-rows-tool）时，8 个在 11 个 ID 上全对的模型中有 5 个在 330 个 ID 上只数对了 21 道中的 10 道或更少，且没有任何报错提示。

3. 数得对的模型 token 消耗显著更高：Gemma 4 26B 在 330 个 ID 时每题消耗 8,153 个输出 token，数对 20/21；而最贵的 Claude Opus 5 每题仅消耗 579 个 token，只数对 9/21。

4. 所有错误均源于算术而非查询：两个任务中没有任何一个答案是建立在错误的 ID 过滤条件上的，Rows 工具上的每个错误都是把正确的列表数错了。

5. 使用 Python 工具时，10 个模型中有 7 个拿到 68/68 满分，前提是模型主动调用工具并打印结果。

我测了什么

起因是十一个 ID：

0, 2, 3, 20, 21, 22, 23, 10, 11, 12, 13

问模型：大于等于 10 的有几个？答案是 8 个。所有模型都答对了。十一个 ID 太短了，短到看不出任何问题，而大多数人的快速测试也就用这个量级。

语言模型不擅长数数，这事从“数一个单词里有几个字母”那类例子就有人知道了。我想测的是它在 agent 场景下的表现：工具返回一堆记录，用户问有多少条，模型自己数。这个环节平时没人单独测，因为少量数据的时候它看起来永远是对的。

测试固定了所有变量，只改一件事：谁来数。

前两个任务里 ID 不会出现在 prompt 中，唯一的区别就是工具返回的是一个数字还是一个列表。两个任务都会检查模型发出的过滤条件是否正确，id > 9 对于“大于等于 10”算对。每个错误答案都能追溯到是查询写错了还是数错了。

每个任务 68 道题：列表长度分别为 11、110、330 个 ID，七种不同的阈值表述（“大于等于 10”、“不少于”、“小于”、“5 到 9 之间含两端”等等），每种三个随机种子，再加上原始那十一个 ID 重复五次。每个阈值都是列表里真实存在的 ID，所以 > 和 >= 的结果一定不同。

测了哪些模型

每个厂商取了小杯、中杯、大杯，再加上 Google 和 OpenAI 的开源权重模型，这样价格、参数量、以及普通人能不能跑起来都覆盖到了。每个模型用 Kaggle全球最大的数据科学竞赛平台和社区，提供数据集和机器学习挑战 模型代理提供的默认设置运行。有些模型回答前会先推理，有些直接给答案，这个设置对结果的影响比模型大小和价格都大。

GPT-6 Astra 被代理拒绝了 function tools（Function tools with reasoning_effort are not supported for gpt-6-astra in /v1/chat/completions）。Gemini 3.5 Flash-Lite 和两个 Qwen 3 Next 80B 模型大部分调用返回 429 或 503。

结果

330 个 ID 的时候，模型之间的差距拉开了：

Claude 系列的 Rows 工具数据来自 2026-09-25 那轮运行，同样的 68 道题、同样的工具；他们 2026-09-28 的 Rows 工具运行因为每日配额用尽中断了。其他所有数据来自 2026-09-28 的运行。

一、工具直接返回数量时，所有模型都对，成本也平稳

除了一个模型，其他所有模型在 330 个 ID 的 Engine 任务上都答对了全部 21 道题，每题输出 35 到 451 个 token，而且从 11 个 ID 到 330 个 ID，每个模型的 token 消耗基本没变。把“不少于 244”翻译成 id >= 244 再把工具返回的数字念出来，这里每个模型都能稳定做到。唯一的例外是 gpt-oss-20b，它在 68 道 Engine 题里有 5 道给出了和工具返回值不一样的数字，全是 0、1 或 2，还有一次没调工具就回答了。

二、返回列表时，短列表能过，长列表就崩

十个模型里有八个在 11 个 ID 的 26 道题上全部数对。到了 330 个 ID，这八个里有五个只数对了 21 道中的 10 道或更少。它们没有报错，也没有犹豫，每个答案都是一个自信的数字。

三、数得对的模型，token 花得多

模型按 token 消耗量分成两组，模型大小和价格都预测不了这个分组。这是最让我意外的地方。数得对的模型，列表越长花得越多：Gemma 4 26B 从 11 个 ID 时每题 394 个输出 token，涨到 330 个 ID 时的 8,153。数错的模型在每个长度上花的 token 差不多：GPT-5.4 nano 在 11、110、330 个 ID 时每题都花 35 个 token，根本没留出数数的空间。Claude Opus 5 是这里最贵的模型，330 个 ID 时每题花 579 个输出 token，数对了 9 道；Gemma 4 26B 是开源权重模型，花了 8,153 个 token，数对了 20 道。

同一个模型在每一轮 Rows 工具运行里都落在同一组，每个模型在 2026-09-25 到 2026-09-28 之间跑了三到四轮。组内排名会波动几道题。

靠推理来数对，成本是 Engine 方案的 5 到 19 倍。之前一轮把 1,100 个 ID 放进 prompt 的实验从另一个方向印证了同样的关联：输出限制在 8,192 个 token 时，Gemini 3.7 Flash 只数对了 21 道中的 1 道，不限制时是 19 道和 15 道，而且每次都照样给数字。

四、查询每次都写对了

两个任务里没有任何一个答案是建立在选错 ID 的过滤条件上的。Rows 工具上的每一个错误，都是模型把正确的列表数错了，除了 3 次没调工具就回答和 1 次答案读不出数字。问题出在算术上。

五、Python 工具只要用了就管用

prompt 里包含所有 ID，外加一个 Python 工具，10 个模型里有 7 个拿了 68/68 满分。Gemini 2.5 Flash 在 110 和 330 个 ID 的 42 道题里只调了 1 次工具，得了 37 分。

这改变了我对这些模型的看法

在这些运行里，数一个列表是模型用 token 做的工作，直接给答案的模型根本没做这个工作。一个返回列表的工具把这项工作转嫁给了模型，让准确率取决于调用方可能从来没看过的某个设置。数量应该放在工具里：返回数量、最小值和最大值，这个阵容里的每个模型都能以零头的 token 成本答对。

对比

所以选哪个

• Engine — 把数量、最小值和最大值放进工具。每个模型都对，成本平稳。
• Python 工具 — 模型用了就可靠，前提是它打印结果并把结果念出来。
• Rows 工具 — 只有在模型会逐条推理列表时才正确，每题成本是 Engine 的 5 到 19 倍。

接下来想测什么

同一个模型开推理和关推理的对比。 Claude Opus 5 开扩展思考对比默认设置。这里的运行显示 token 和准确率跨模型是联动的；这个实验能看出对单个模型来说打开推理是否就够了。

其他算术操作。 求和、平均值、返回行里的最大值，同样的工具形态问题也适用于这些。

更难的过滤条件。 “至少 10 但小于 20”和“5 到 9 之外”，这种条件下如果过滤写错了但数量算对了就会暴露出来。

怎么复现

以下步骤从仓库重建整个基准测试；任务、运行、以及上面每一张表都来自这些命令。

准备工作

• 一个 Kaggle 账号，装好 Kaggle CLI（pip install kaggle，这里用的是 2.2.4 版本），用 kaggle auth login 登录
• Python 3，用于本地检查和报告生成；任务导入的 kaggle_benchmarks 库在 Kaggle 上已经装好了
• 克隆仓库：git clone https://github.com/xbill9/devto-kaggle，然后 cd devto-kaggle

第一步 — 本地检查题目

每道题都是代码生成的，期望数量来自对 ID 跑一遍过滤条件。check.py 构建全部 68 道题，不调模型也不需要 Kaggle 库：

python3 tasks/check.py

ok: 68 rows per task, by size {11: 26, 110: 21, 330: 21}

第二步 — 推送每个任务

tasks/ 里每个文件是一个 Kaggle 任务。文件里第一个 @kbench.task 返回正确率，因为 Kaggle 用第一个找到的任务来命名和读取分数。第二个任务回答一道题，每道题运行一次：

@kbench.task(name="count-engine")
def count_engine(llm) -> float:
    runs = count_engine_row.evaluate(
        llm=[llm], evaluation_data=pd.DataFrame(ROWS), n_jobs=4,
    return summarize(runs, len(ROWS), "engine")

每道题的结果保留了答案、模型发出的每个过滤条件、以及 Kaggle 模型代理报告的 token 和成本。推送的 slug 必须和任务名一致：

kaggle b t push count-engine -f tasks/count_engine.py --wait
kaggle b t status count-engine

Task:     count-engine
Version:  13
Status:   Completed
Created:  2026-09-28 16:11:45

第三步 — 跑模型

kaggle b auth -y 获取 Kaggle 模型代理的短期密钥，kaggle b t models 列出模型 slug。一次运行每个模型一个 -m：

kaggle b t run count-rows-tool -m gemini-2.5-flash -m gemini-3.8-flash -m gemma-4-26b-a4b-it -m gpt-oss-20b -m gpt-5.4-nano-2026-03-17 -m gpt-5.4-mini-2026-03-17 --wait

All runs completed:
  gpt-5.4-mini-2026-03-17: COMPLETED
  gpt-5.4-nano-2026-03-17: COMPLETED
  gpt-oss-20b: COMPLETED
  gemma-4-26b-a4b-it: COMPLETED
  gemini-3.8-flash: COMPLETED
  gemini-2.5-flash: COMPLETED

提示：限制输出以节省配额

Kaggle 模型代理会按输出 token 上限预留最坏情况的成本，当预留超过当天剩余配额时会拒绝调用。不设限制时，GPT-6 Astra 每次调用预留 6.40 美元，Claude Opus 5 预留 3.20 美元。传一个限制能把预留压到几美分：

llm.prompt(prompt, schema=int, extra_api_params={"max_completion_tokens": 8192})

第四步 — 下载运行结果并生成表格

report.py 从下载的运行结果生成这篇文章里的每一张表，包括每题的 token 和成本：

for t in count-engine count-rows-tool count-python-tool; do kaggle b t download $t -o results; done
python3 tasks/report.py results

| Model | Size | Engine correct | Engine out tokens | Engine $ | Rows correct | Rows out tokens | Rows $ |
|---|---|---|---|---|---|---|---|
| Gemini 3.8 Flash | 330 | 21/21 | 140 | 0.0010 | 21/21 | 2,742 | 0.0146 |
| GPT-5.4 nano | 330 | 21/21 | 35 | 0.0002 | 0/21 | 35 | 0.0003 |

第五步 — 把任务组合成基准测试

基准测试在 Kaggle 网页端创建。在基准测试页面上，Add Tasks 添加任务，Add Models 添加模型。在 Settings 下，把总分设为 Average of task scores：默认的 Percentage of tasks passed 会忽略返回数字的任务。可见性设为 Public 后不可撤销。

提示：排行榜显示每个模型的最新一轮

排行榜每个格子显示该模型该任务最近一次运行的结果，所以一次因配额失败的运行会覆盖之前完整的结果。运行前检查配额，如果有一个失败了就重新跑那一对。pending.py 列出最新运行不完整的配对。

我的基准测试

• https://www.kaggle.com/benchmarks/xbillwork/count-it-or-compute-it （基准测试：三个任务及其排行榜）
• https://www.kaggle.com/benchmarks/tasks/xbillwork/count-engine
• https://www.kaggle.com/benchmarks/tasks/xbillwork/count-rows-tool
• https://www.kaggle.com/benchmarks/tasks/xbillwork/count-python-tool

总结

这篇文章的目标是测量模型能否正确数出工具返回的内容。关键在于只改工具返回什么，一个数字还是一个列表，并记录每个过滤条件和每个 token。

结果：

• 工具里带数量时，除了 gpt-oss-20b，每个模型在 330 个 ID 的题目上都答对了。
• 返回列表时，每题花 2,700 到 8,200 个输出 token 的模型，在 330 个 ID 的 21 个列表中数对了 15 到 21 个。
• 600 个 token 以内就回答的模型，21 个里只数对了 0 到 10 个，Claude Opus 5 也在其中，而且没有任何报错提示。

每个模型用 Kaggle 模型代理的默认设置运行每个任务，输出限制在 8,192 个 token；Engine 和 Rows 工具的数据来自 2026-09-28 的运行，Claude 的 Rows 工具数据来自 2026-09-25，Python 工具数据来自 2026-09-28，token 上限的结果来自更早的 1,100 个 ID 上下文内运行。

跨 10 个模型测试数数的策略，是用逐步递进的方式验证的。

参考

• 本基准测试代码：https://github.com/xbill9/devto-kaggle
• Kaggle Benchmarking Challenge：https://dev.to/challenges/kaggle-2026-09-23
• Kaggle Benchmarks：https://www.kaggle.com/benchmarks
• 任务基于 Kaggle 的 kaggle-benchmarks 库：https://github.com/Kaggle/kaggle-benchmarks
• Kaggle 的基准测试编写指南，CLI 工作流参考：https://github.com/Kaggle/kaggle-skills/blob/main/write-kaggle-benchmarks/SKILL.md

常见问题（FAQ）

AI搜索优化中，工具返回ID列表让模型自己数，为什么长列表容易出错？

模型需要自己数列表，长列表时快速回答的模型token消耗少，没留出数数空间，错误率高；愿意花更多token推理的模型才数得对。

如何优化AI搜索中的计数任务，避免模型数错？

把计数逻辑放在工具端，让工具直接返回精确数量、最小值和最大值，而不是返回ID列表让模型自己数。这样所有模型都能答对，成本也平稳。

为什么Claude Opus 5在计数任务上表现不如Gemma 4 26B？

Claude Opus 5虽然贵，但快速回答，token消耗少，数330个ID只对9次；Gemma 4 26B愿意花更多token推理，对了20次。模型大小和价格预测不了计数能力。