# GPT-5.6 Sol 跑分更高了，为什么我的周额度反而更快见底？ **Summary:** 从我对 GPT-5.6 Sol 的复杂感受出发，用具体例子解释上下文、智能体群，以及 Artificial Analysis 当前所有 LLM 指数到底测量什么。 - Canonical: https://markhuang.ai/zh/blog/what-ai-benchmarks-actually-measure - Language: zh-CN - Author: [Mark Huang](https://markhuang.ai/about) - Published: 2026-07-12 - Section: AI 与 LLM - Tags: GPT-5.6, AI 基准测试, 上下文窗口, AI 智能体, Codex, Artificial Analysis - License: https://creativecommons.org/licenses/by-nc/4.0/ --- ![开发者在 AI 控制台前，对比一台专注的推理引擎和一群忙碌的辅助机器](https://cdn.markhuang.ai/blog/what-ai-benchmarks-actually-measure/hero.webp) *更高的分数可能描述的是引擎本身、测试框架，或是整套系统——这三者根本不是一回事。* 我用了几天 GPT-5.6 Sol，感受真是喜忧参半。 在我的 Codex 会话中，显示的上下文预算比用 GPT-5.5 时要大——在我的环境下大约是 356K 对 250K。听起来像是个不错的升级。但实际上，我每周的额度消耗得快多了。Sol 也明显比 GPT-5.5 慢。在 Max 模式下，Sol 比 GPT-5.5 在 xhigh 模式下问的问题多得多，而 Ultra 到目前为止还不太对我的胃口。 Ultra 给我的感觉不像一个可控的工作台，倒像是推开一扇门，看到满屋子的智能体都在忙活*些什么*。我能看见各种活动，却感觉不到自己有一个清晰的控制界面来理解它们在做什么、随时叫停，或者判断哪些中间结果值得信任。 这种体验让我开始思考一个更大的问题：当模型公司或排行榜说某个模型更好时，到底是什么变得更好了？ ## 核心要点速览 | 说法 | 通常意味着什么 | 没告诉我们的事 | | ------------------------ | ------------------------------- | --------------------------------------- | | 「1M 上下文窗口」 | 模型或产品在特定条件下能接受很大的最大 Token 预算 | 每个 Token 是否都能被有效利用、产品何时压缩上下文，以及我的额度消耗速度 | | 「更高的 Intelligence Index」 | 在一组公开的智能体、编程、通用和科学评测中获得了更好的加权成绩 | 产品是否更快、更少打扰我、更容易操控，或者是否更适合我的具体工作流 | | 「更高的 Agentic Index」 | 在指定测试框架中，多步骤工具任务的最终结果更好 | 系统是否使用了智能体群、是否展示了执行计划，或者是否验证了子智能体的输出 | | 「更高的 Coding Index」 | 在该指数包含的编程基准测试中表现更好 | 完整的编程助手在代码库导航、代码审查、中断响应或成本控制方面是否更出色 | | 「Ultra」 | 一种将适合的任务分配给多个子智能体的多智能体产品模式 | 更多的并行工作会自动带来更高的准确率或更强的可控性 | 我现在的结论很简单：**基准分数是一份测量契约，而不是模型评测报告**。如果我不知道具体的任务、工具、设置、评分标准和汇总规则，那个醒目的数字对我来说几乎毫无意义。 ## 上下文窗口的数字其实并不矛盾 我首先需要理清自己对上下文窗口的理解。 OpenAI 当前的 API 页面将 [GPT-5.6 Sol](https://developers.openai.com/api/docs/models/gpt-5.6-sol) 和 [GPT-5.5](https://developers.openai.com/api/docs/models/gpt-5.5) 的上下文窗口都标为 1.05M Token。但这显然和我在 Codex 中看到的约 356K 和 250K 不符。另外，在 OpenAI 的 [ChatGPT Business 模型与限制页面](https://help.openai.com/en/articles/12003714)中，GPT-5.6 Sol 的窗口又被记录为 272K。 这不一定是谁出错了，而是因为「上下文窗口」可能指代几个不同的层面： | 层面 | 回答的问题 | 示例 | | ------ | ------------------------------- | ------------------------------------------ | | 模型上限 | API 模型在公开限制下最多能接受多少内容？ | OpenAI 目前将 GPT-5.6 Sol 和 GPT-5.5 都列为 1.05M | | 产品暴露窗口 | ChatGPT、Codex 或工作区实际向用户开放了多少？ | 产品可以只开放 API 上限的一部分 | | 会话预算 | 扣除系统指令、工具定义、文件、消息和输出预留后，还剩多少空间？ | 我在活跃编程会话中看到的数字 | | 压缩阈值 | 智能体何时开始总结历史而不是继续扩展上下文？ | 用户配置的阈值可能远低于模型上限 | | 有效上下文 | 模型在这类任务中能可靠利用多少信息？ | 取决于具体任务，通常小于宣传的最大值 | 这个区别很重要。我在 Claude Code 中使用支持 1M 上下文的模型，但会将 `CLAUDE_CODE_AUTO_COMPACT_WINDOW` 设置在约 300K。Anthropic 的 [Claude Code 环境变量文档](https://code.claude.com/docs/en/env-vars)明确支持将 1M 模型当作较小窗口来处理自动压缩。Anthropic 的 [平台发布说明](https://platform.claude.com/docs/en/release-notes/overview)也确认，支持的 Claude 模型已普遍提供 1M 上下文。 所以当我说 300K–400K 是个甜点区间时，并不是在否认模型无法处理更多内容。我描述的是一种操作偏好：有足够的空间进行认真的编程会话，但又能及时压缩，避免会话变成充斥着过时决策、旧错误和无关工具输出的垃圾场。 ## 最大上下文不等于有效上下文 长上下文确实解决了实际问题。我不希望智能体忘记二十分钟前讨论的架构设计，不想让它反复读取相同的文件，也不想让它在修改进行到一半时丢失验收标准。 但更大的窗口也会带来三种不同的失败模式，人们常常把它们都笼统地称为「上下文腐化」： | 失败模式 | 问题所在 | 实际体验 | | ------ | ------------------------- | ---------------------------- | | 中间信息丢失 | 相关信息因位置不同而获得的关注度不够可靠 | 模型记得开头的规则和最新消息，却漏掉了夹在中间的关键决策 | | 上下文腐化 | 随着输入内容增加，性能反而下降，即使答案仍在提示中 | 会话掌握的信息更多了，但做出的决策却更糟糕 | | 上下文拖累 | 每一轮都要携带更多历史、工具输出和冲突状态 | 延迟更高、消耗更大，也更容易遵循过时的指令 | [Lost in the Middle](https://arxiv.org/abs/2307.03172) 的研究显示，长上下文的性能会因相关信息的位置不同而显著变化。Chroma 的 [Context Rot 研究](https://www.trychroma.com/research/context-rot)则测试了输入量增长时性能下降的更广泛问题。这些研究并不能证明 300K 是普适的最佳值，但确实证明了「能装下」和「能用好」是两个完全不同的概念。 即使是 Artificial Analysis 的长上下文组件 [AA-LCR](https://artificialanalysis.ai/evaluations/artificial-analysis-long-context-reasoning)，每道题测试的也是大约 10 万 Token 的跨文档推理能力。这为长文档推理提供了有用的证据，但并不能证明模型在一场包含多次编辑、失败命令和意图变化的百万 Token 编程会话中，从头到尾都能保持同样可靠的性能。 ## 为什么我的每周额度消耗得更快 仅凭我的使用体验，无法判断 Sol 变慢究竟是因为发布初期的高需求、后端负载、模型行为，还是我自己的任务特点。OpenAI 并未公开足够的遥测数据让我区分这些因素，所以「大家都在用」只能作为一个假设。 额度消耗方面则更容易解释。OpenAI 的 [Codex 定价文档](https://learn.chatgpt.com/docs/pricing)指出，消耗量取决于模型选择、上下文、推理、工具使用、检索和缓存；看似相似的任务可能消耗不同的额度。文档还提到可能会有额外的每周限制。 因此，即使最终答案很短，更大的保留上下文也可能让智能体会话变得更昂贵。模型可能需要处理更多历史、进行更长时间的推理、发出更多工具调用，并反复检查更多证据。缓存输入可以让重复的前缀更便宜，但并不会让长智能体循环变成免费操作。 这就是为什么我觉得「Token 高效的模型」和「我的额度消失得更快」并不矛盾。前者是模型层面的说法，讨论的是模型在基准测试中完成任务所需的输出或推理量；后者是我整个会话的产品层面结果。 > **我真正关心的指标不是每个回答消耗多少 Token，而是每个被接受的结果消耗多少额度。** 如果 Sol 能一次性正确完成困难的重构，更高的消耗可能是值得的。但如果它消耗更多、问更多问题、运行更慢，最终仍然需要同样的审查，那么基准测试的优势就还没有真正惠及我的工作流。 ## Max 和 Ultra 是不同的产品 OpenAI 的 [Codex 模型指南](https://learn.chatgpt.com/docs/models)做出了一个关键区分，这也解释了我部分的感受： | 控制级别 | 改变的内容 | 最适合的场景 | 主要风险 | | ------------------ | --------------- | ---------------------- | -------------------------- | | Extra High / xhigh | 提高所选模型的推理强度 | 包含多个步骤、多个信息源或复杂权衡的困难任务 | 延迟和消耗增加，但不一定带来明显的改进 | | Max | 给所选模型更多时间思考单个任务 | 深度比速度或消耗更重要的最难单一问题 | 长时间的单智能体运行仍可能走上错误路径 | | Ultra | 使用子智能体并行处理不同部分 | 能清晰拆分为多个独立工作流的任务 | 活动更多、协调开销更大、输出可能冲突，且控制更不直观 | 同一份文档还指出，GPT-5.5 和 GPT-5.6 的推理强度没有精确的对应关系。Max 模式改变的也不仅仅是标准的推理级别选择器。这意味着我对 GPT-5.5 xhigh 与 GPT-5.6 Max 的比较是一个有效的体验报告，但不是一个受控的模型实验。 提问频率也是如此。我注意到了这个问题，但不能仅凭几天的体验就断定 GPT-5.6 总是问更多问题。提示结构、产品指令、安全检查和任务模糊性都会影响这种行为。我能确定的是，提问频率应该纳入我的评估范围，因为每一次不必要的澄清都会打断工作流。 ![卡通 AI 助手依次经过任务、工具、设置、验证和最终结果等独立基准测试站](https://cdn.markhuang.ai/blog/what-ai-benchmarks-actually-measure/measurement-layers.webp) *排行榜的一行数据，实际上是将工作负载、测试框架、推理设置、评分标准和汇总规则压缩成了一个数字。* ## 基准分数由什么构成 现在，在查看任何排行榜之前，我都会先关注五个层面： | 层面 | 关键问题 | 为何会影响结果 | | ---- | ---------------------------- | --------------------------------------------- | | 工作负载 | 实际测试的是什么任务？ | 物理问题、银行客服流程和代码库补丁衡量的是完全不同的能力 | | 测试框架 | 模型获得了哪些工具、提示、沙盒、记忆和轮次限制？ | 同一个模型在 Claude Code、Codex、Cursor 或中立框架中的表现可能不同 | | 推理设置 | 使用了哪个模型快照、推理强度、温度和 Token 预算？ | high 和 Max 模式下的「GPT-5.6 Sol」并不是相同的测试条件 | | 评分标准 | 谁或什么来判断结果是否正确？ | 单元测试、数据库状态、精确匹配、评分细则和 LLM 评委都有不同的失败模式 | | 汇总方式 | 任务分数如何变成headline数字？ | 加权平均可能会用其他方面的优势掩盖重大弱点 | 这通常就是那种「信我就对了」式基准测试让人不舒服的原因。基准测试本身可能是正规的，但问题在于headline图表隐藏了测量契约。 ## Artificial Analysis 当前所有 LLM 指数：按实用热度排序 Artificial Analysis 并未公开每个排行榜的访问量，因此无法做出精确的热度排名。以下是我截至 2026 年 7 月的实用排序：先列出网站位置最显眼、适用范围最广的综合指数；然后是跨领域的专项指数；最后的专业指数则按照 [Artificial Analysis 能力导航](https://artificialanalysis.ai/models/capabilities)中的顺序排列。这里涵盖了当前 12 个文本模型和编程智能体指数——不包括其独立的图像、视频、语音、音乐或硬件排行榜。 ### 1–6：大多数人应该先了解的指数 | 排序 | 指数及构成 | 具体场景 | 高分不能证明什么 | | -- | ----------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------- | ------------------------------------- | | 1 | **[Intelligence Index v4.1](https://artificialanalysis.ai/methodology/intelligence-benchmarking)** 智能体 34%、编程 24%、科学推理 24%、通用能力 18% | 创建电子表格和备忘录、解决需要工具的银行业务、完成终端任务、回答研究级科学问题，并从长文档中寻找证据 | 模型在每个组件中都领先、运行速度快、额度消耗少，或在我的产品中表现良好 | | 2 | **[Coding Index](https://artificialanalysis.ai/models/capabilities/coding)** Terminal-Bench v2.1 和 SciCode 各占 50% | 通过终端修复损坏的环境，或将科学算法描述转换为能通过测试的 Python 代码 | 完整的编程产品能理解我的代码库、审查自己的补丁，或易于中断 | | 3 | **[Agentic Index](https://artificialanalysis.ai/models/capabilities/agentic)** GDPval-AA v2 和 τ³-Banking 各占 50% | 使用沙盒和网络工具制作专业交付物，或搜索政策并执行正确的多步骤账户工作流 | 产品使用了智能体群、委派效果好，或验证了子智能体的输出 | | 4 | **[Coding Agent Index v1.1](https://artificialanalysis.ai/agents/coding-agents)** DeepSWE、Terminal-Bench v2 和 SWE-Atlas-QnA 的等权平均 | 阅读代码库、实施长期变更、操作终端，并回答有关代码库架构的问题 | 底层模型单独获得了这个成绩；智能体框架、模型和设置都是被测变体的一部分 | | 5 | **[Multilingual Index](https://artificialanalysis.ai/models/multilingual)** 覆盖 16 种语言的 Global-MMLU-Lite | 不仅用英语，还能用中文、印地语、阿拉伯语、约鲁巴语或缅甸语回答等价的通识和推理问题 | 高质量翻译、本地化语调、长文写作、文化安全建议或多语言工具使用 | | 6 | **[Openness Index](https://artificialanalysis.ai/evaluations/artificial-analysis-openness-index)** 模型访问和授权的 0–100 分评分，加上训练数据和方法透明度 | 判断我能否下载权重、商业使用、检查披露的数据，并复现或审计训练方法 | 智能程度、安全性、事实准确性，或「开放权重」意味着完全开放的数据和训练代码 | ### 7–12：专业领域指数 这些[行业指数](https://artificialanalysis.ai/methodology/capability-indices)重复使用了许多相同的底层基准测试，然后根据类似 O\*NET 的职业能力图谱，按各项能力在该领域中的出现频率进行加权。它们是有用的筛选信号，而非专业认证。 | 排序 | 指数及权重 | 具体场景 | 高分不能证明什么 | | -- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------ | ------------------------------------------- | | 7 | **[Finance & Accounting](https://artificialanalysis.ai/models/capabilities/finance-and-accounting)** 商业知识 30%、智能体工作 30%、推理 20%、客户互动 10%、长上下文 5%、非幻觉 5% | 阅读财务文件、建立估值和敏感性模型、核对数据，并制作投资或管理备忘录 | 每个公式都经过审计、市场数据是最新的，或工作符合我的司法管辖区和内部控制要求 | | 8 | **[Strategy & Ops](https://artificialanalysis.ai/models/capabilities/strategy-and-ops)** 商业知识 30%、智能体工作 30%、客户互动 30%、指令遵循 5%、长上下文 5% | 将运营数据、政策文件和利益相关者需求转化为人员配置计划、流程变更和完整的办公室工作流 | 良好的组织判断力、政治可行性、员工采纳度，或在我系统中的可靠执行 | | 9 | **[Legal](https://artificialanalysis.ai/models/capabilities/legal)** 法律知识 35%、智能体工作 25%、推理 15%、长上下文 10%、非幻觉 10%、客户互动 5% | 审查合同和判例资料包、识别冲突的权威、起草备忘录，并避免编造引用 | 掌握我所在司法管辖区的现行法律、保护特权信息、引用有效性，或无需律师即可安全提交的工作 | | 10 | **[Healthcare & Medical](https://artificialanalysis.ai/models/capabilities/healthcare-and-medical)** 医学知识 35%、智能体工作 25%、非幻觉 15%、推理 15%、客户互动 10% | 结合症状、病史、药物和指南形成临床推理摘要，然后协调电子病历或药房工作流 | 诊断、安全的个体化治疗、监管批准，或替代临床审查 | | 11 | **[Engineering](https://artificialanalysis.ai/models/capabilities/engineering)** 工程知识 35%、推理 35%、智能体工作 25%、终端使用 5% | 根据疲劳和极端载荷设计风力涡轮机支撑结构、论证安全裕度，并自动化计算 | 设计经过仿真、独立检查、符合规范、可制造，或可签字批准 | | 12 | **[Economics](https://artificialanalysis.ai/models/capabilities/economics)** 经济学知识 35%、推理 35%、智能体工作 15%、长上下文 15% | 估算关税的归宿和弹性效应、量化福利权衡，并综合相互冲突的研究 | 数据、因果假设、预测或最终政策建议对现实经济有效 | 有一个历史细节值得一提。[Artificial Analysis Data API 页面](https://artificialanalysis.ai/data-api)仍然提到了 Math Index 字段，但当前的 Intelligence 方法说明 MATH-500 和 AIME 2025 已退出主动报告。除非 Artificial Analysis 恢复实时的方法论和排行榜，否则我会将 Math 视为遗留/API 字段，而不是第十三个当前的公开指数。 ## Artificial Analysis Intelligence Index：一个组合，而非单一测试 截至 2026 年 7 月，[Artificial Analysis Intelligence Index v4.1](https://artificialanalysis.ai/methodology/intelligence-benchmarking) 结合了九项评测。类别权重为：智能体 34%、编程 24%、科学推理 24%、通用能力 18%。 因此，Intelligence Index 分数既不是「对一个难题的深度推理」，也不是「智能体群的编排」。它是一个组合： | 类别 | 包含内容 | 通俗场景 | | ---------- | ------------------------------------------ | ------------------------------------------ | | 智能体 — 34% | GDPval-AA v2 和 τ³-Banking | 根据提供的材料创建专业文件，或通过查找政策并进行正确的工具介导账户变更来解决银行业务 | | 编程 — 24% | Terminal-Bench v2.1 和 SciCode | 完成多步骤终端任务，或编写能通过测试的科学 Python 代码 | | 科学推理 — 24% | Humanity's Last Exam、GPQA Diamond 和 CritPt | 解决科学和研究物理领域的困难专家级问题 | | 通用能力 — 18% | AA-LCR 和 AA-Omniscience | 跨长文档推理、回答事实问题，并在不确定时不胡猜 | 这比单一的学术选择题分数有用得多。但这也是一个编辑选择。Artificial Analysis 在 v4.1 中增加了智能体任务的权重。一个模型可以在headline指数上有所提升，主要是因为它在工具使用任务上表现更好，即使它在最难的单一科学问题上的改进较小。 ## 底层基准测试的实际体验 | 基准测试 | 通俗解释 | 如何验证成功 | | -------------------- | ----------------------------- | --------------------------- | | GDPval-AA v2 | 完成 44 个职业中的一个现实专业任务并提交可用文件 | 盲测评分，转换为以人类专家工作为基准的 Elo 评分 | | τ³-Banking | 搜索大型银行政策库、与模拟用户对话，并执行正确的账户工作流 | 最终后端数据库状态，多次尝试的平均值 | | Terminal-Bench v2.1 | 操作真实终端完成软件、系统管理、数据、训练或安全工作 | 任务特定测试，通过或失败 | | SciCode | 将科学问题描述转换为可工作的 Python 代码 | 代码执行和单元测试 | | AA-LCR | 从约 10 万 Token 的长文档中寻找并组合分散的证据 | 答案等效性评分器 | | AA-Omniscience | 回答 42 个知识主题的问题，但在不确定时选择放弃而非编造 | 准确率加上独立的非幻觉组件 | | Humanity's Last Exam | 回答横跨科学、数学和人文学科的困难专家编写问题 | 答案相等性，pass\@1 | | GPQA Diamond | 解决非专家通常会错过的研究生级生物、物理和化学问题 | 四选项选择题，pass\@1 | | CritPt | 解决未发表的研究级物理挑战 | 通过官方服务器进行数值、符号或 Python 函数评分 | 现在，headline Intelligence Index 有了具体的形状。如果我的工作是合同审查、客户支持、代码库维护或科学研究，我就不应该同等重视每个组件。 ## Coding Index 不等于 Coding Agent Index 这种命名确实容易让人困惑，这是完全可以理解的。 [Artificial Analysis Coding Index](https://artificialanalysis.ai/models/capabilities/coding) 是一个模型能力指数。它将 Terminal-Bench v2.1 和 SciCode 等权重结合。通俗地说：模型能否在终端中操作，能否生成正确的科学代码？ 而独立的 [Artificial Analysis Coding Agent Index](https://artificialanalysis.ai/agents/coding-agents/) 则评估编程智能体变体在 DeepSWE、Terminal-Bench v2 和 SWE-Atlas-QnA 上的表现。其场景包括长期代码库变更、终端执行，以及需要理解代码库才能回答的问题。Artificial Analysis 甚至会展示在固定模型的情况下，比较 Claude Code、Cursor CLI 和 OpenCode 等产品的测试框架差异。 | 如果我想知道…… | 应该看…… | | --------------------------- | ------------------------------ | | 原始模型能否解决终端和科学编程问题？ | Coding Index 及其两个组件 | | 配置好的编程智能体能否制作补丁、使用终端并理解代码库？ | Coding Agent Index 和各基准测试的详细分解 | | Codex 在我的订阅中是否会感觉快速、可控且经济？ | 仅靠这两个指数都不够；我需要产品和工作负载的实际测量数据 | Coding Agent Index 更接近我的日常体验，但它仍然无法衡量我能否干净地中止智能体群、UI 是否解释每个工作者在做什么，或者我多久会达到每周限额。 ## Agentic Index 不意味着 Swarm Index [Artificial Analysis Agentic Index](https://artificialanalysis.ai/models/capabilities/agentic/) 是 GDPval-AA v2 和 τ³-Banking 的等权重组合。它衡量规划、工具使用、自主性、专业交付物、知识检索、客户互动和最终任务完成。 这些都是智能体技能，但并不需要智能体群。 Artificial Analysis 通过其开源 Stirrup 测试框架运行 GDPval-AA。一个模型获得工具和沙盒，在任务中工作，并提交交付物。该基准测试可以告诉我，某个模型加测试框架在完成这类工作方面是否更好。但它并不能告诉我该模型是否是一个强大的多智能体编排器。 ![主智能体将多个工作者的输出通过可见的测试关卡，然后向开发者呈现一个经过审查的结果](https://cdn.markhuang.ai/blog/what-ai-benchmarks-actually-measure/swarm-validation.webp) *委派产生输出，验证才产生这些输出值得信任的证据。* ## 智能体群的好坏取决于其控制循环 我对编排问题的回答是肯定的：工作者模型的选择确实重要。但它只是系统中的一个因素。 | 阶段 | 可能的失败点 | 良好的控制表现 | | ----- | ---------------------------- | --------------------- | | 任务分解 | 编排器沿错误边界分割任务 | 独立的作用域、明确的输入、明确的验收标准 | | 工作者执行 | 工作者误解其任务或缺乏能力 | 适合任务的模型选择和有限的工具 | | 结果聚合 | 父智能体在未注意到的情况下合并了不兼容的答案 | 冲突检测、来源追踪和结构化交接 | | 验证 | 系统将自信的工作者输出视为证据 | 测试、模式、独立审查、源检查和可重现的命令 | | 恢复 | 一个失败的分支污染最终答案或导致无限重试 | 可见的失败状态、重试限制、取消和回滚 | | 人工控制 | 用户无法看到成本、进度，或不知道智能体群为何选择某个方向 | 预算、检查点、暂停/停止控制和可审查的产物 | 父智能体总结五个工作者的响应并不是验证。父智能体通过测试、证据、模式或独立审查来检查这些响应才是验证。 基准测试在这里又增加了混淆。Terminal-Bench 的测试、τ³-Banking 的数据库检查和 GDPval-AA 的评委小组验证的是*基准测试结果*。它们并不能证明智能体或智能体群在提交前内部验证了自己的工作。 这个区别对我很重要。我不仅希望最终答案在外部评委检查后通过。我还希望操作系统能展示足够的证据，让我在运行过程中就能信任、中断和修复它。 ## 那些热门但不是指数的排名 模型页面还按速度、延迟、价格、上下文和效率对模型进行排名。这些列与我的 Sol 体验相关，但它们并没有将多个能力基准测试组合成一个指数。 | 排名 | 衡量内容 | 回答的具体问题示例 | 常见误解 | | ------------------ | ---------------------------------------------- | ------------------------------- | ---------------------------- | | **输出速度** | 生成开始后每秒接收的答案 Token 数；当前默认性能工作负载使用约 1 万输入 Token | Sol 开始回答后，可见文本出现的速度有多快？ | 快速输出并不意味着答案开始前的等待时间短 | | **首 Token 时间** | 从 API 请求到第一个流式 Token 的秒数 | 多久能看到任何活动？ | 对于推理模型，第一个 Token 可能是思考过程而非答案 | | **首答案 Token 时间** | 输入处理时间加上隐藏或可见推理，直到第一个答案 Token | 多久能收到有用的答案文本？ | 它仍然不包括完成响应或智能体工作流的时间 | | **端到端响应时间** | 接收 500 Token 答案的估计秒数，包括输入、推理和生成时间 | 哪个 API 能更快返回中等长度的答案？ | 它不是十分钟编码任务从提示到审查结果的总时间 | | **每百万 Token 价格** | 公布的 API Token 价格，通常显示为缓存/输入/输出的混合费率 | 在指定的 Token 组合下，原始 API 流量的成本是多少？ | 它不是订阅的每周额度或每个成功结果的成本 | | **每项指数任务成本** | 观察到的基准测试 Token 使用量乘以相关的输入、缓存、推理和答案价格 | 模型的平均基准测试工作负载有多昂贵？ | 「平均任务」可能与我的代码库或提示完全不同 | | **每项指数任务时间** | 每项任务的加权输出 Token 除以输出速度；不包括 TTFT 和测试框架开销 | 解码指数典型输出需要多长时间？ | 它不是真实的墙钟完成时间 | | **每项指数任务输出 Token** | 平均每项指数任务产生的加权推理和答案 Token | 哪个模型花费更多生成的 Token 来达到其分数？ | 更少的 Token 并不自动意味着更便宜、更快或更好 | | **上下文窗口** | 模型报告的最大输入和输出 Token 限制 | 这个请求能否容纳？ | 它不衡量有效回忆、上下文腐化、产品压缩或额度使用 | ## 我应该关注哪个数字？ | 我的工作负载 | 有用的公开信号 | 我仍需自行测试的内容 | | -------------- | ----------------------------------------------- | ---------------------------------- | | 一个非常困难的科学或推理问题 | HLE、GPQA Diamond、CritPt，加上所选的推理设置 | 我的领域的准确性、延迟，以及引用是否能通过审查 | | 科学或算法代码生成 | Coding Index，特别是 SciCode | 我的语言、库、测试和可维护性 | | 大型代码库变更 | Coding Agent Index，特别是 DeepSWE 和 Terminal-Bench | 代码库约定、回归率、审查时间，以及从失败命令中恢复的能力 | | 客户支持自动化 | Agentic Index，特别是 τ³-Banking | 我的政策、防护措施、升级规则和真实后端状态 | | 长篇报告、财务文件或法律包 | AA-LCR 和相关专业指数 | 在我的文档长度下的证据回忆能力和引用准确性 | | 必须承认不确定性的事实助手 | AA-Omniscience 的准确性和非幻觉性 | 我的权威来源和弃权政策 | | 多智能体编码智能体群 | 没有单一的 headline 指数 | 任务分割、重复工作、冲突、验证器覆盖率、停止行为、总成本和接受结果率 | ## 我真正想要的 Sol 评分卡 经过几天的使用，我还没有足够的数据来宣布 GPT-5.6 Sol 在我的工作中比 GPT-5.5 更好或更差。但我对应该记录什么有了更好的想法： - **接受结果率：**我无需重大修复就能接受工作的频率。 - **端到端时间：**从提示到审查结果的时间，而不是每秒输出 Token 数。 - **每个接受结果的额度消耗：**任务消耗了多少五小时和每周额度。 - **干预负担：**澄清问题、权限暂停、纠正和重启的次数。 - **上下文持久性：**早期约束和决策是否仍能影响后期工作。 - **控制能力：**我能否看到进度、限制范围、停止分支，并理解发生了什么。 - **验证能力：**系统是否产生了测试、证据和可审查的产物，而不是自信的总结。 这张评分卡可能与公开排行榜不一致。这没关系。排行榜在回答它的问题，我在回答我的问题。 ## 我认为 LLM 的发展方向 我不认为方向仅仅是「让单一模型更聪明」。三个方向正在同时演进： 1. 单一模型在推理、编程、工具使用和判断重要性方面变得更好。 2. 运行时在上下文管理、缓存、压缩、权限和恢复方面变得更好。 3. 产品在编排方面变得更好：子智能体、专家、并行工作、评委和验证器。 基准测试也在朝同一方向发展。Artificial Analysis v4.1 在其 Intelligence Index 中给予智能体工作最大的类别权重。编程智能体排行榜越来越多地比较测试框架，而不仅仅是模型名称。这是合理的，因为有用的单元正变得越来越像一个系统。 但行业仍然过于急切地将系统重新压缩成一个数字。 我目前对上下文的看法仍然是，300K–400K 是长时间编码会话的舒适操作范围。我目前对 Ultra 的看法是，在获得更清晰的控制循环之前，我不想要更多的智能体。而我目前对 GPT-5.6 Sol 的看法是复杂的：我能看到能力的发展方向，但速度、限制、问题数量和可控性也是能力的一部分。 当基准测试说一个模型更强时，它并没有撒谎。它只是在回答一个比大多数人以为自己在问的更窄的问题。