开发者接入大模型时，常见做法是打开榜单选择综合分最高的型号。但一项发布于2026年10月12日的实测记录显示，榜单分数并不能覆盖真实调用中的计费口径、推理开关和延迟成本。作者基于 Artificial Analysis Intelligence Index v4.3.2 榜单，对其中“TOP 10”相关模型进行同一请求测试，发现向 gpt-6.1-sol 发送正文仅为“hi”的请求时，usage 返回的 prompt_tokens 达到4223。测试过程中接口返回 HTTP 200，没有报错，问题只藏在返回字段里。由于榜单和在售清单变动较快，作者也提醒读者先核对日期。
榜单之外：型号、延迟与可调用的现实差距
这次实测使用的榜单权重为 Agent 30%、编程 20%、科学推理 20%、通用 30%。由于同分并列，榜单上的“TOP 10”实际包含11款模型。表面看，分数区间从58到45，跨度13分；更值得注意的是首字延迟：从748.61秒到2.82秒，跨度265倍。榜单第一名在其取得第一的配置下，首字延迟达到748秒，接近十二分钟。对需要实时反馈的产品而言，这类延迟已不是前端提示能解决的问题。
作者还发现，榜单型号并不都能直接调用：Gemini 4 Argon 和 Muse Spark 1.3 未出现在服务商在售清单中；Grok 榜单版本为4.7（xhigh），在售版本为4.6，二者不是别名，不能直接用4.7的分数推断4.6。因此，实测建议的顺序不是先抄榜单型号，而是先确认服务商实际提供哪些模型，再查询对应成绩。
在验证方式上，作者使用同一条最小请求，只替换 model 字段，并重点打印 usage 相关字段。10款模型全部返回 HTTP 200，耗时在1.80秒到7.80秒之间。以 claude-haiku-5-5 为例，一次要求模型“Reply with exactly: OK”的请求耗时2.69秒，返回 prompt_tokens 42、completion_tokens 4、total_tokens 46，completion_tokens_details.reasoning_tokens 为0。这类低成本请求足以暴露字段差异。
4223个prompt_tokens：短请求下的固定输入开销
第一个问题出现在计费口径上。当作者向 gpt-6.1-sol 发送正文只有“hi”的请求时，返回的 prompt_tokens 为4223；同一时间，向 claude-sonnet-5-5 发送一条18 token的请求，prompt_tokens 返回18。作者复测两次，gpt-6.1-sol 的结果稳定在4223到4227之间。这意味着调用该模型存在约4200 token的固定输入开销。
这一开销会改变短请求场景下的成本预期。榜单数据显示，gpt-6.1-sol 得到52分，任务成本为0.72美元，是全表唯一“50分以上 + 成本低于1美元”的组合，看起来适合高频场景。然而，固定输入开销一旦叠加到高频调用中，榜单上的性价比优势就需要重新计算。
作者给出的检查方法很直接：把业务中最短的一条典型请求发给候选模型，读取 usage.prompt_tokens，再与预期长度比对。十秒钟的验证，可以避免上线后才发现账单量级异常。
max_tokens被推理吃掉：返回200，但正文几乎为空
第二个问题影响功能可用性。作者给 glm-5.3 设置 max_tokens=64，返回的正文几乎为空。查看 usage 后发现：completion_tokens 为64，其中 completion_tokens_details.reasoning_tokens 为60，留给正文的只有4个token。将 max_tokens 改为512后重发，输出34个token，推理占32，正文正常返回。同一组请求发给 claude-sonnet-5-5 时，reasoning_tokens 为0。
这说明 glm-5.3 默认开启推理，而推理 token 会占用 max_tokens 的额度。如果开发者按“预期回答长度”设置 max_tokens，模型可能因推理消耗过大而无法输出正文。更麻烦的是，接口仍返回 HTTP 200，没有错误提示。日志层面看似正常，业务侧却只能看到空结果，属于典型的静默失败。
- 对可能默认开启推理的模型，应打印 usage.completion_tokens_details.reasoning_tokens。
- max_tokens 不应只按正文长度估算，还要考虑推理开销。
- 接口返回成功不等于业务结果可用，需要加入空内容或低内容校验。
行业意义：从“最高分”转向“可运行配置”
这两个坑指向同一个变量：推理。推理能力在榜单中可能体现为更高分数，但在真实调用中，它是会消耗延迟、输出额度和费用的开关。榜单展示的通常是各模型已测的最高分配置，而开发者上线时使用的是某个具体型号、某个档位和某个默认参数。作者提到，将配置降低一档可能少4分，但能省掉约十二分钟的首字等待；对线上服务来说，这类取舍往往比分数更容易决策。
这也让大模型选型从“看排名”转向工程化核验。开发者需要确认模型是否在售、版本是否一致、请求是否可复现、usage 字段是否透明、推理是否默认开启，以及延迟和计费是否匹配业务形态。一个43分的模型，在特定工作上可以胜过58分的那个；榜单回答的是综合能力，真正要回答的是这份任务应该交给谁。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/liang-ge-zi-mu-xiao-hao-4223-ge-token-top-da-mo-xing-shi-ce
