Amazon Bedrock 上的 OpenAI 模型迎来全新的成本检验
9 月 11 日，Amazon Bedrock 上的 OpenAI 模型迎来了一项新的生产基准测试，其结果挑战了“选择最便宜 token”的规则。AWS 与 OpenAI 在学术题目、研究 Agent、专业文档和延迟测量等场景中测试了五种配置。核心发现始终一致：当计算中纳入较弱回答、重复搜索和人工返工时，token 更便宜的模型仍可能成本更高。
此次比较涵盖 GPT-5.6 Luna、Terra 和 Sol，以及 GPT-5.4 Mini 和 Nano。基准研究并未宣称存在一个通用赢家，而是考察每个成功结果消耗了什么资源。这包括失败尝试、累积上下文、工具调用、延迟，以及未能满足验收评分标准的交付物。
这重新定义了部署 Agent 和文档工作流的团队的采购决策。主要竞争不再是便宜 token 对昂贵 token，而是标价中的 token 价格与获得可接受结果的完整成本之间的较量。新的开源测试框架让开发者能够用自己的任务检验这一点。
该基准以结果排名取代 token 排名
该基准将比较单位从生成的 token 转为达到既定质量门槛的工作成果。
这听起来像是一次小小的成本核算调整，却会改变哪种模型看起来更经济。
AWS 和 OpenAI 评估了多种工作负载形态，因为单一准确率测试无法代表生产系统。他们的学术测试套件包括 AIME、GPQA Diamond 和 MMLU-Pro。样本量从 60 道 AIME 题目到 198 道 GPQA Diamond 问题不等，其间还有 140 道 MMLU-Pro 问题。
每个模型都会产生成功与失败尝试的使用量。评估者将观察到的总使用成本除以正确答案数量，由此得到每个正确答案的成本，而非单次请求的成本。
当准确率差异显著时，这一区别尤为重要。GPT-5.6 Sol 正确回答了抽样 AIME 题目中的 75%。GPT-5.4 Mini 的正确率为 37%。Sol 在 GPQA Diamond 上也领先 Mini，分别为 68% 和 43%；在 MMLU-Pro 上则分别为 82% 和 59%。
准确率为 37% 的模型，平均每成功一次大约需要 2.7 次独立尝试。不过，生产环境中的重试很少彼此独立。同一个模糊提示或缺失证据，可能让每次尝试都走向类似的失败。
Luna 在测试样本中取得了最低的每个正确答案观察成本。这也包括与 Nano 的比较，尽管 Nano 在记录的假设条件下名义 token 费率略低。Luna 在测试配置中使用了更少的计费 token，并将更多尝试转化为可接受的答案。
这一结果并不证明 Luna 始终是最便宜的模型。它表明，不能仅根据价目表推断最终账单。提示长度、输出长度、推理设置、重试策略和所需准确率都会影响最终排名。
该测试框架使这些依赖关系清晰可见。它记录答案、token 消耗、质量分数和计算出的结果成本。团队可以检查底层结果，而不是直接接受一个综合排行榜分数。
这种透明度很重要，因为模型评估经常将多项权衡压缩为一个数字。生产负责人需要知道模型是因事实错误、结构缺失、轮次过多还是输出截断而失败。每种失败都对应不同的应对方式。
事实错误可能意味着应采用更强的模型。结构问题或许可以通过更清晰的评分标准修复。重复搜索可能表明工具选择较弱或 Agent 循环效率低下。截断则更指向输出限制，而非推理质量。
因此，对于 Amazon Bedrock 上的 OpenAI 模型，这项基准提出了一个更有用的首要问题：在这个特定工作流中，什么才算成功？只有定义了这一门槛，团队才能比较达到它所需的资源。
每个正确答案的成本揭示重试惩罚
每个错误答案都应计入模型选择预算，即使应用程序会悄然重试它。
按 token 比较通常假定两个模型完成了等价的工作。学术测试结果说明了这一假设为何不成立。更高的准确率会改变预期调用次数，而 token 效率则会改变每次调用的规模。
设想一个在向客户发布前回答技术问题的应用。错误答案可能触发自动重试、后备模型或人工审核。这些后果都不会出现在最初的 token 报价中。
每个正确答案的成本计算能够捕捉失败尝试产生的直接模型使用成本。更完整的生产计算还可以加入验证、审核时间、下游修正和面向客户的风险。合适的边界取决于谁负责该工作流。
AWS 的研究有意使用观察样本，而不是承诺一个通用排名。这一选择限制了结论的适用范围，但提升了其实用价值。所记录的任务、提示、设置和评分规则均可检查和调整。
团队在改造该测试框架时应保持这种严谨性。已知答案集需要接近真实流量。过于简单的问题会让所有模型显得可以互换，而异常困难的问题则可能夸大对高端模型的需求。
失败成本也会因使用场景而异。不完美的内部摘要或许几秒钟就能修正。一项错误的合规声明则可能启动更漫长的审核流程。在开始任何模型运行之前，准确率门槛应反映这种差异。
这正是路由策略比单一企业默认模型更有价值的地方。常规分类任务可以交给高效达到适度门槛的模型。困难分析任务则可以在验证器检测到不确定性或失败后升级处理。
路由同样需要测量。低成本的首次尝试若频繁升级，成本可能高于一开始就将任务交给更强模型。它还可能增加延迟，并在调用之间重复传递上下文。
基准结果表明，Luna 值得成为许多高吞吐量任务的首个评估对象。它在研究的学术样本中取得了最低的观察结果成本。但当高难问题的准确率构成硬性门槛时，Sol 仍是更强的选择。
这是工作负载决策，而非品牌层级。Luna、Terra、Sol、Mini 和 Nano 分别处于质量、速度和消耗的不同位置。它们的名称并不能说明哪个位置符合特定验收规则。
推理设置使情况更加复杂。Amazon Bedrock 的比较为所测模型禁用了推理，从而建立了一个有意设置的成本下限。启用推理可能提升结果、增加使用量，或同时带来两者。
公平评估必须将每个模型和每个推理级别视为独立配置。将一个未启用推理的模型与另一个采用更高推理设置的模型比较，会掩盖结果背后的机制。
结果框架也让价格变化不再那么具有破坏性。团队可以在评估记录中更新当前费率，并重新计算排名。每次商业条款变动时，都不必重建质量研究。
这种将稳定的质量证据与变化的商业输入分离的做法很有价值。它将模型选择转变为一套运营流程，而不是一次性的采购决策。
Agent 轨迹成本让额外步骤演变为累积上下文
对于研究 Agent 而言，昂贵的行为通常并非一段很长的回答，而是一连串不必要的工具调用。
该研究使用一个包含 50 个问题、经过分层抽样的 DeepSearchQA 样本测试了这一问题。这些是通过实时网页搜索和页面抓取工具处理的多步骤研究问题。
该 Agent 使用由客户端管理的对话历史记录，并禁用了存储。每一轮都会重新发送系统提示、此前的工具结果和累积上下文。随着轨迹增长，每个请求都会比前一个更大。
这会产生累积效应。当历史持续累积时，单轮输入会大致线性增长。随着轮次增加，累计计费输入可能接近二次增长。
因此，与五轮 Agent 相比，八轮 Agent 不只是多进行了三次调用。其后续调用还携带更多先前材料。每一次往返都会增加延迟，而重复的上下文也会增加消耗。
Mini 在每个 DeepSearchQA 问题上平均进行了 7.6 轮，是受测模型中最高的。许多轮次属于额外的搜索循环。其每个问题的平均输入量达到 114,000 个 token，而 Terra 为 50,000 个。
在不考虑回答质量之前，这已是 Terra 输入量的 2.3 倍。Mini 的平均 F1 分数为 0.39，Terra 则达到 0.50。F1 衡量预期答案内容与生成答案内容的重合度，并平衡精确率与召回率。
当 F1 分数达到至少 0.7 时，回答即视为通过。该评估先使用确定性的预检查，随后采用固定的 GPT-5.5 自动评分器。固定评分器减少了不同模型运行之间的一项变异来源。
Terra 相比 Mini 用更少轮次完成研究轨迹，并取得更高的平均质量。其更高的名义 token 费率并未决定最终结果，因为 Mini 反复重新发送了更多累积证据。
Luna 的轮次少于 Mini，且每个通过答案的观察 Agent 轨迹成本显著更低。在该样本中，其通过级别成本约为 Mini 的八分之一。Nano 的名义 token 更便宜，但仅通过了 18% 的问题。
三种 GPT-5.6 配置的平均 F1 分数均高于两个基线模型。这支持了文章更广泛的主张，但样本仍然有限。50 个问题无法确定所有研究领域中的细微差异。
即使另一个工作负载颠倒了模型排名，这一机制仍值得关注。任何重新发送历史记录的客户端管理 Agent，都要为其轨迹设计付费。更好的模型行为和更好的编排都能缩短这段历史。
模型可以通过选择更相关的搜索查询、识别充分证据，或在无需再次查找的情况下撰写答案来节省轮次。编排器则可以通过裁剪工具输出、总结历史记录或强制执行搜索预算来节省轮次。
这些改进应分别评估。否则，团队可能会将编排变更的效果归功于模型，或将应用程序插入的不必要上下文归咎于模型。
Responses API通过 Amazon Bedrock 提供兼容 OpenAI 的请求结构。兼容性简化了模型替换，但等价请求并不保证产生等价轨迹。
工具 Schema、停止规则、提示设计和区域行为仍会影响观察到的运行结果。一项有用的测试会固定这些要素，同时每次只切换一个模型配置。
团队还应记录的不只是总 token 数。轮次、工具选择、检索字节数、重复查询、完成状态和验证器结果，能够揭示为何某条轨迹成本更高。
对智能体而言，实用指标是每次完整运行所获得的通过答案数。智能体轨迹成本则解释了那些在单次调用价目表上看似相近的模型为何会产生差异。
专业交付物让质量成为账单的一部分
文档生成后仍会产生成本，因为一份看似合理的草稿，依然可能无法满足专业人士必须遵守的要求。
许多企业级产出无法通过精确字符串匹配来评估。合规简报需要包含必要的免责声明。财务方案需要采用一致的假设。护理方案必须具备特定保障措施和可用的结构。
该研究通过 GDPval 中抽取的 48 项任务来解决这一问题。GDPval 使用围绕专业任务制定的标准，评估贴近现实的知识工作交付物。更广泛的 GDPval framework 覆盖九个行业中的 44 种职业。
AWS 评估采用人工编写的评分量表，并对其要求进行加权。文档获得至少 70% 的可用量表分数后即可通过。这将主观质量转化为明确的验收门槛。
在关闭推理功能的情况下，三种 GPT-5.6 配置的观测量表得分均高于 Mini 和 Nano。报告中最大的差异出现在法律、护理和财务建议任务中。
由于各子组样本量较小，这些类别发现仍属探索性结论。但它们仍说明，格式与完整性为何应纳入基准测试。回答即便包含正确事实，也可能遗漏使专业文档真正可用的关键免责声明。
Luna 在 48 项交付物中的 31 项得分高于 Mini，在 9 项中得分较低，并在 8 项中持平。Luna 通过了 27 项任务，而 Mini 通过了 20 项。
Nano 通过了 35% 的任务。Mini 达到 42%，Luna 达到 56%。Sol 在 48 项交付物中通过了 31 项，支持其在质量是硬性要求时的定位。
这些结果改变了经济性问题的定义。如果员工必须反复补全缺失章节，较低的模型收费价值有限。审阅和返工的成本可能远高于生成首稿的成本。
因此，设有质量门槛的文档生产需要两项相互关联的衡量指标。第一项是每份通过交付物的模型用量。第二项是将失败或勉强达标的产出转化为通过版本所需的人力投入。
该基准直接衡量第一项。组织必须从自身工作流程中提供第二项数据。审阅时间可通过审批系统、编辑日志或结构化评估者反馈收集。
这些额外证据可能改变首选模型。若 Terra 或 Sol 的草稿所需专业审阅显著更少，即便模型消耗更高也可能合理。若 Luna 的通过率在总用量更低的情况下超过业务门槛，它仍可能更具优势。
输出限制带来了另一项不确定性。该评估将交付物上限设为 8,192 个 token。这导致 6 个 Luna 输出、9 个 Terra 输出、7 个 Sol 输出、0 个 Mini 输出和 1 个 Nano 输出被截断。
在所测试的配置下，这些截断应视为真实结果。它们也使人难以将模型质量与施加的长度上限区分开来。更高的上限或许能提高量表完成度，但也会增加消耗。
严谨的复现应同时测试上限和模型。还应检查更长的文档是否增加了有用内容，还是只是重复表述。更多输出并不自动意味着更好的交付物。
评分量表同样需要仔细审查。通用评分表会遗漏领域特有的失败模式。法律、临床、财务和工程工作需要不同的证据、资质要求和升级规则。
团队可以像基准作者建议的那样，从 50 至 100 项代表性任务开始。每项任务都应包含一个已知良好的结果，或一套审阅者能够一致应用的验收量表。
一套有用的任务集应包含常见工作、困难边界情形和对失败敏感的示例。它还应保留员工实际使用的输入文件和上下文。经过净化的玩具提示词往往会低估检索和格式问题。
对于知识密集型文档团队，维护这些评估集会成为运营记忆的一部分。可搜索的工程知识库可帮助保留评分量表、参考文件和既往失败分析。
目标并非消除专业判断，而是将这种判断用于有代表性的评估和影响重大的例外情况，而不是审阅每份生成草稿中本可避免的缺陷。
Amazon Bedrock 上的 OpenAI 模型仍需本地验证
已发布的排名是判断应优先测试什么的证据，而不是跳过测试的许可。
该评测工具提供了更强的模型选择方法，但其自身局限性使其无法给出普遍适用的建议。样本构成、区域、推理设置、输出上限和评分器选择都会影响结果。
作者于 2026 年 7 月进行了延迟对比。Luna 和 Terra 在 AWS 美国西部区域采用单区域配置。由于 Sol 的行为和可用性不同，它使用了美国东部区域。
在 12 种匹配配置中，Luna 在 Amazon Bedrock 上的首 token 时间中位数平均低 21%。Terra 平均低 5%。首 token 时间衡量流式输出开始前的延迟。
对于至少包含 500 个 token 的输出，Luna 在 Amazon Bedrock 上的吞吐量平均高 43%。Terra 的优势平均为 4%。这些测量比较了同一模型在两条应用路径中的表现。
在 Amazon Bedrock 上，观测到的最坏情况延迟相对于中位数为 2.1 至 2.5 倍。OpenAI API 上相应的范围为 4.6 至 6.6 倍。
这些最大值并非第 99 百分位延迟的估计。研究明确将其描述为特定时点的观测结果。共享基础设施会随着区域、负载、配额、路由和请求形态而变化。
生产团队应从自身部署区域重复进行延迟测试。应测试真实的并发度、提示词规模、流式行为和服务级别目标。仅看中位数结果可能掩盖用户可感知的长尾延迟。
质量测试也采用了一项有意的配置选择：关闭推理功能，以建立较低用量的基线。依赖复杂规划或综合分析的应用，应在预期部署的推理级别下重复测试。
评分也带来另一项顾虑。DeepSearchQA 将确定性步骤与 GPT-5.5 自动评分器结合。这一过程可复现，但任何模型评分器都可能带有偏好，或忽略领域特有的错误。
人工审阅仍有助于校准。审阅者可以检查接近通过门槛的分歧，再调整评分量表或确定性检查。但他们不应在看到哪个模型获胜后再修改规则。
GDPval 有不同的限制。其 48 项任务切片足以揭示模式，但规模太小，无法对单个职业得出可靠结论。报告中的类别差异需要更大、更具针对性的样本。
团队还必须防范基准泄漏。如果提示词与公开评测过于相似，结果可能高估真实表现。从实际工作流程中收集的私有任务，能更好地检验本地价值。
开源的benchmark harness支持这种适配。它包括用于学术评估、DeepSearchQA 轨迹、GDPval 交付物和性能比较的脚本。
可复现性并不能消除运营变量。模型修订、服务更新和提示词变更都可能改变结果。因此，评估记录应保存模型标识符、日期、区域、设置和量表版本。
安全和治理要求也可能比微小的效率差异更重要。OpenAI 模型于 2026 年 6 月通过 AWS 正式全面可用，并使用 AWS 原生控制措施和采购流程。对于已在该环境实现标准化的组织而言，AWS availability具有重要意义。
但平台适配度仍应与模型质量分开考量。Bedrock 可以简化治理，但并不意味着每个模型都适合每项任务。该工具可帮助团队在基础设施要求缩小可选范围后测试质量。
因此，合理的决策应结合四道关卡。模型必须满足治理规则、达到质量门槛、符合延迟预期，并最小化通过工作所消耗的总资源。
没有任何公开基准能为单个组织设定这些门槛。它只能展示哪些衡量方法能够揭示隐藏的权衡。
三个信号将显示结果定价是否成为标准
下一项检验在于，团队是否会将结果衡量纳入运营，而不是将这一基准视为又一个静态排行榜。
第一个信号是采用私有的、针对工作负载的评估集。在未来几个月，最具参考价值的组织将公布方法细节，而非通用模型排名。
一套良好的评估集包含常规任务、高代价失败情形和已验收的参考输出。它还会记录重试策略、人工审阅流程和生产配置。
如果更多团队报告每个通过结果的成本，该基准的核心判断将更有说服力。如果大多数比较仍局限于 token 价格和公开考试，基于结果的选择将仍然只是专业实践。
第二个信号是由轨迹遥测驱动的模型路由。研究型智能体应公开轮次、重复搜索、上下文增长、验证器失败和升级频率。
路由系统可以利用这些证据，将简单任务分配给 Luna，并将困难工作升级给 Terra 或 Sol。不过，在计入所有失败的首次尝试后，路由策略必须优于单模型基线。
如果路由在不削弱质量或延迟的情况下，降低了通过结果成本，工作负载形态就已成为实际的定价输入。如果升级消耗了节省的成本，较简单的模型分配仍会更可信。
第三个信号是在模型、服务或商业条款变化后重复进行基准测试。OpenAI 和 AWS 于 2026 年开启了更广泛的合作，包括将 OpenAI 模型和智能体基础设施引入 Bedrock。Amazon partnership使两家公司都有理由持续调整其联合产品。
每项变化都可能改变首选配置。修订后的模型可能使用更少 token、更可靠地遵循工具调用，或提升长文档完成度。区域服务更新则可能在不影响质量的情况下改变延迟。
原始基准已展示了重新运行测试的重要性。更新后的商业条款在不改变先前答案的情况下改变了结果排名。未来的模型修订可能改变等式的两端。
团队应在模型版本变更、出现重大费率更新或生产提示词发生变化时安排重新评估。当观测到的失败模式不再类似于原始评估集时，也应重新运行测试。
可执行的起点并不复杂：选择 50 至 100 项已知任务，定义通过规则，并在预期的生产设置下运行每个候选模型。统计失败、重试、轮次、token、延迟和审阅投入。
然后计算通过结果所消耗的资源。在选定赢家前，检查失败类别。平均来看似乎经济的模型，仍可能在业务风险最高的情形中失败。
Amazon Bedrock 上的 OpenAI 模型现在已有一个公开框架，可据此作出这一决策。持久的洞见并非某个 GPT-5.6 变体能够胜出所有工作负载，而是最便宜的 token 在系统将其转化为可接受的工作成果之前，并不具备任何业务价值。
在续用默认模型选择之前，不妨先问一个可量化的问题：对于组织实际能够使用的每一份回答、执行轨迹或交付成果，完整工作流究竟消耗了多少资源？
