2026年十大LLM实测：榜单第一名，可能不是你该用的模型

一份模型排行榜能告诉你哪个模型「能力最强」，却回答不了你真正关心的问题——「哪个模型适合我的任务」。这是两个完全不同的问题，而它们的答案差距之大，往往超出工程师的预期。

一位开发者在 2026 年 10 月 12 日同一天采集了 Artificial Analysis Intelligence Index v4.3.2 的全部数据，并对榜单上的模型逐一做了 API 实测。结论很直接：榜单第一名在拿到第一名的那个配置下，首个 token 要等 748 秒——整整十二分钟。

分数差 13 分，延迟差 265 倍

按智能指数排序的前十名（因并列实际为 11 个模型）里，分数从 58 跌到 45，差距只有 13 分。但首个 token 返回时间（Time to First Token，TTFT）从 748.61 秒到 2.82 秒，差距高达 265 倍。

#	模型（配置）	Index	成本/任务(USD)	TTFT
1	Claude Opus 5.5 (max)	58	5.98	748.61 s
2	Claude Sonnet 5.5 (max)	56	5.46	484.09 s
3	GPT-6 Astra (max)	53	3.26	383.62 s
6	GPT-6.1 Sol (max)	52	0.72	330.58 s
8	MiMo-V2.6-Pro	46	0.13	3.51 s
10	Qwen3.8 Max	45	5.41	2.82 s
10	GLM-5.3 (max)	45	2.01	3.36 s

三个比名次更有价值的观察：延迟差远大于分数差，屏幕前有人等待时，最后一列比分数更重要；分数与成本不成线性关系——Opus 5.5 比 GPT-6.1 Sol 多 6 分，成本却是约 8.3 倍；同分模型的工程特性天差地别，三个并列第三名的模型成本从 1.99 到 7.63 USD 不等。

Time to First Token（TTFT） 是指从客户端发出请求到服务器返回第一个 token 之间的时间，也称为「首字延迟」。它与总生成时间（Total Latency）是两个不同的指标：总生成时间包含所有 token 的输出过程，而 TTFT 只衡量用户感知到「模型开始响应」的那一刻。在有人实时等待的交互场景中，TTFT 直接决定界面是否看起来「卡住了」；在批处理场景中，它则影响任务队列的吞吐量。对推理型模型（reasoning model）而言，TTFT 通常远高于普通模型，因为模型必须先在内部完成一段不可见的思维链（chain-of-thought）推导，才会输出第一个可见 token——这正是表格中 max 配置下 TTFT 极高的根本原因。

从 API 响应里抠出三个关键字段

作者的测试方法非常朴素：通过一个 OpenAI 兼容端点，对每个模型做一次调用，不用任何评测框架或库，关键只在于从响应里提取什么。

真正值得记录的三个字段：

• prompt_tokens：与实际发送的长度对比，偏差大意味着存在固定开销；
• reasoning_tokens：有多少预算流向了你永远看不到的推理过程；
• completion_tokens：如果它恰好等于你设的 max_tokens，说明被截断了——返回文本可能是空的。

作者强调，后文的两个「隐形坑」完全是靠这三个字段发现的。所有被测模型都返回 HTTP 200，耗时在 1.80 到 7.80 秒之间，表面上一切正常。

还有一个现实陷阱：榜单里的模型 ID 直接抄过来往往用不了。 作者测试的 11 个模型中有 3 个在目录里根本调用不到。Grok 是个典型案例——榜单列的是 Grok 4.7 (xhigh)，实际可用的只有 Grok 4.6，这是两个不同版本，榜单上的 46 分和 3.74 USD 并不能套用到 4.6 上。正确做法是把顺序倒过来：先确认你真正能调用哪些 ID，再去榜单里查它们的数值。

两个不写在文档里的隐形坑

坑一：一个「hi」被算成 4223 个输入 token

作者给 gpt-6.1-sol 发了一条内容只有 hi 的请求，回来的 prompt_tokens 竟是 4223。而同一时刻用 claude-sonnet-5-5 发 18 个 token 的请求，prompt_tokens 就是 18。两次复测，数值稳定在 4223 到 4227 之间。

这意味着存在一个 约 4200 token 的固定输入开销。对长文档这无足轻重，但如果你每天跑 20 万条短请求，这个开销就是你的账单主体。验证方法只需十秒：发出你最短的典型请求，把 usage.prompt_tokens 和预期长度比一下。

坑二：max_tokens 不是回答上限，而是总预算

作者给 glm-5.3 设了 max_tokens=64，结果 completion_tokens 用满 64，其中 60 个全花在了 reasoning 上，留给真正回答的只有 4 个 token——文本实际为空。改成 max_tokens=512 后，输出 34 token、其中 32 个推理，回答恢复正常。而同样请求发给 claude-sonnet-5-5，reasoning_tokens 为 0。

问题在于这个模型默认开启推理，且推理 token 计入 max_tokens。如果你按预期回答长度去设这个值，就会收到空回答，且没有任何报错。验证方法是把 usage.completion_tokens_details.reasoning_tokens 打印出来。

OpenAI 兼容端点（OpenAI-compatible endpoint） 是指遵循 OpenAI Chat Completions API 接口规范的第三方或自托管服务。由于 OpenAI 的 API 格式已成为行业事实标准，众多模型提供商（包括本文涉及的 GLM、MiMo 等）都提供相同的 /v1/chat/completions 路径和请求/响应结构，使得同一套客户端代码可以切换不同的 base_url 来调用不同厂商的模型。usage 字段（包含 prompt_tokens、completion_tokens 及其子字段 reasoning_tokens）是该规范中用于计费和调试的核心返回字段。值得注意的是，「兼容」并不等于「行为一致」——各厂商对 token 计数规则、max_tokens 语义的具体实现可能存在差异，本文揭示的两个隐形坑正是这种差异的典型体现。

推理档位比名次更重要

榜单永远展示评分最高的那个配置，但在实际运行中，推理档位往往比选哪个模型更关键。

模型	档位	Index	成本/任务	TTFT
Claude Opus 5.5	max	58	5.98	748.61 s
Claude Opus 5.5	high	54	1.82	44.34 s
Claude Opus 5.5	medium	51	1.34	21.61 s
GPT-6.1 Sol	max	52	0.72	330.58 s
GPT-6.1 Sol	medium	48	0.21	7.55 s

Opus 5.5 从 max 降到 high：少 4 分，成本降约 70%，等待时间减少 94%。 GPT-6.1 Sol 从 max 降到 medium：少 4 分，成本降约 71%，等待时间减少 98%。

在绝大多数生产场景里，用 4 分换 94% 的等待时间都是划算的买卖。真正的教训是：把推理档位当成一个需要测试的参数，而不是默认值。 推理是应对困难任务的开关，不是常开设置——坑二就是推理被用在了一个根本不需要它的任务上。

「推理档位」（reasoning budget / thinking level）是部分大模型 API 提供的参数，用于控制模型在给出最终答案前投入多少计算资源进行内部推导。以 Anthropic 和 OpenAI 的产品为例，通常提供 low / medium / high / max 等档位，档位越高，模型在隐藏的思维链上消耗的 token 越多，推理质量通常也越高，但延迟和成本随之大幅上升。这一机制本质上是「用时间和金钱换准确率」的旋钮。对于结构简单、答案明确的任务（如工单分类、格式转换），high 甚至 medium 档位的输出质量与 max 几乎无差别；而对于需要多步骤推导的数学证明或复杂架构决策，max 档位的额外推理才真正有价值。因此，推理档位应当被视为需要针对具体任务做消融实验（ablation）的超参数，而非固定不变的默认值。

不同任务该选哪个模型

作者给出的任务-模型对照表里，最有意思的是最后一行：Claude Haiku 5.5（235 tok/s、0.21 USD/任务）根本不在前十，却是工单分类、高吞吐场景的最优解。

几个代表性建议：

• 架构评审、关键重构（离线）：选 Opus 5.5，但先测 high，过了就省下 max；
• 日常编码、交互式、有人等待：选 Sonnet 5.5，medium 档 TTFT 仅 0.87 秒，但要测 P95 延迟而非均值；
• 小预算高能力（离线）：GPT-6.1 Sol 是唯一一个 50 分以上且低于 1 USD 的模型，但务必先查 prompt_tokens；
• 海量分类、需自托管：MiMo-V2.6-Pro，0.13 USD/任务、开放权重；
• 均衡且带 Tool-Call：GLM-5.3，三项指标无明显短板，但 max_tokens 要设得宽裕些。

这篇文章的核心正在于此：在合适的任务上，43 分的模型可以击败 58 分的模型。

这些数字的边界

作者坦诚地标出了数据的局限：指数、成本、速度和延迟都来自公开榜单而非自测，自己只测了可达性和 token 计数；采集日为 2026 年 10 月 12 日，采集日并非各模型的测试日；该指数偏重英文和纯文本，对图像、语音或多语任务参考价值有限；11 个模型中有 3 个在目录里找不到，不作推荐。

归根结底，排行榜是按能力排序的参考，不是选型决策本身。真正决定成败的，是你把自己的任务放进真实环境里跑出来的那几个数字。你是否曾经记录过 reasoning_tokens？很多隐形错误从不写在文档里，只在踩过坑的人之间流传。