我们设计 GPT‑5.6 模型系列，是为了在用户使用我们模型处理的各类任务中平衡能力与成本。我们的旗舰模型 GPT‑5.6 Sol 使用 Max 推理时，在 Artificial Analysis Coding Agent Index 上的表现优于 Claude Fable 5，而成本还不到后者的一半。Terra 在智能基准测试中的表现与 GPT‑5.5 相当，价格仅为其一半；Luna 则是我们速度最快且价格最低的模型，价格比 Sol 低 80%。为实现这些效率提升，我们的研究和技术团队对技术栈的每个主要层面都进行了重大优化。这些改进涵盖模型、推理（即运行模型以生成输出的方式），以及 Codex 和 ChatGPT 工作共同采用的智能体执行框架。
过去四年，我们将模型扩展到服务 10 亿活跃用户和超过 200 万家企业；在此过程中，效率始终是让每个人都能从智能中受益的关键。我们的使命是确保通用人工智能造福全人类。这些年来，我们不断在整个技术栈中发掘更多优化空间，力求在成本与智能曲线的每个位置都提供性能最优的模型。GPT‑5.6 实现了迄今最高的单位 Token 智能效率；我们对其进行训练，使其能够用每个 Token 完成更多工作。训练期间，我们会同时优化任务成功率和效率，引导模型以更直接的路径完成任务。
本文将视角扩展到模型之外，介绍我们如何通过技术栈另外两个主要部分的进步来提升效率：一是优化负载均衡、推测解码、缓存和内核优化等流程的推理，以便从相同硬件中获得更多输出；二是改进上下文膨胀、工具使用和重复工作管理的智能体执行框架。我们还将介绍 GPT‑5.6 Sol 如何自主实现其中多项收益。单项改进看似有限，但这些成果会不断叠加，使我们能够同时推动智能与效率迈向前沿。
在算力受限、模型需求增长快于容量扩充的环境中，效率是每项系统设计的核心。对于运行已训练模型来生成响应的推理技术栈而言，尤其如此。我们的首要目标是在相同硬件上处理更多 Token，同时保持用户期望的智能、延迟、可用性和可靠性。
要实现这一目标，必须优化整个系统。模型本身可以非常高效，但如果请求分配不当、硬件闲置或数据移动拖慢计算，服务成本仍然可能很高。各层改进会产生叠加效应，收益来自路由（将请求发送到何处）、调度（何时发送请求）、内核（在 GPU 上运行的软件）、缓存（保存并复用的工作）和模型实现（GPU 代码的执行顺序）等方面的优化。Codex 中的 GPT‑5.6 Sol 在所有这些优化中都发挥了关键作用。
第一个重要示例是负载均衡。在全球范围内，我们会根据地理位置、可用容量和加速器类型等因素来路由请求。加速器是指运行模型的 GPU 或专用芯片类型。在集群内部，我们会根据负载、上下文长度、缓存可用性和其他请求属性，将工作分配给不同的模型实例。在每个实例内部，还必须将工作高效划分到不同的加速器、模型子网络和计算核心。Codex 中的 GPT‑5.6 Sol 可帮助我们分析生产流量、发现过去被忽视的失衡来源、测试新的路由策略，并持续调整这些启发式规则。仅这些负载均衡改进，就大幅降低了模型的服务成本。
我们还使用 GPT‑5.6 Sol 优化模型的前向传播，即将输入转换为下一 Token 预测的计算过程。即使各项操作本身很快，过多的内存移动、同步和低效的数据布局仍会导致 GPU 闲置。为避免这种情况，GPT‑5.6 Sol 找出了可以预计算、跳过或并行处理的工作。借助 Codex，GPT‑5.6 Sol 自主重写并优化了我们的生产内核，也就是执行构成模型的数学运算的核心代码。这在一定程度上得益于我们训练 GPT‑5.6，使其能够熟练使用 Triton（在新窗口中打开） 和 Gluon（在新窗口中打开） 编写并改进内核。这两种开源 GPU 编程语言均由 OpenAI 维护。这些工作与 GPT‑5.6 Sol 推动的其他内核改进相结合，使端到端服务成本降低了 20%。我们还大力投入验证工具，例如开源工具 FpSan（在新窗口中打开）（浮点净化器），以协助验证 GPT‑5.6 Sol 所编写内核的正确性。
推测解码是提升速度和效率的另一项重要手段。这项技术会让一个较小的草稿模型（或称“推测器”）与主模型同时运行，提出多个 Token，供主模型并行验证。当这些提议被接受时，系统只需运行一次主模型就能生成多个输出 Token，从而减少成本高昂的顺序计算。GPT‑5.6 Sol 针对自身草稿模型的架构设计并运行了数百项实验，测试不同规模、结构和特性，从而改进了该模型。此外，GPT‑5.6 Sol 还启动并监控了推测器的训练过程，在出现硬件故障、训练不稳定等问题时自主介入。由此带来的改进使 Token 生成效率提升了 15% 以上。
处理未缓存的输入 Token 时，模型会通过一次计算密集型处理构建键值（KV）缓存；生成输出时，则会反复读取并扩展该缓存。批处理、分片和 KV 管理等最佳服务配置高度取决于工作负载，包括提示与输出长度、批次大小、缓存命中率、查询特征等。然而，以往的配置空间过于庞大，无法进行系统化调优，工程师只能依赖宽泛的启发式规则。借助 Codex 中的 GPT‑5.6 Sol，我们得以分析生产工作负载、生成并评估候选配置，并针对每种场景对引擎和模型配置进行深度优化。这让更高水平的工作负载专项优化成为现实，可以从相同硬件中获得更多有效推理能力。
推理优化是一个持续运转的反馈循环。我们衡量生产环境中的表现，找出最大差距，实施改动，并验证其改善的是整个系统，而非单项基准测试。GPT‑5.6 Sol 和 Codex 加速了这一循环的每个环节。因此，我们的团队可以探索更多想法，更快响应不断变化的工作负载，并打造延迟更低、容量更大、用户成本更低的推理技术栈。
ChatGPT 工作和 Codex 通过一系列模型请求与工具调用来完成复杂任务。在从用户请求到最终响应的一次交互中，Codex 可能会检查源代码、搜索部署历史、阅读事故报告、编辑文件并运行测试。每个步骤都可能需要发起一次请求。
准备上下文、传输数据、运行推理、调用工具和启动进程都需要时间和算力。如果一项任务需要发起 30 次模型请求，那么每次请求多花一秒，累积起来就相当可观。提升整体性能意味着减少整个系统中的重复工作，而不只是提高模型速度。
一次用户交互可能包含多轮模型处理和工具调用。重复区域内的任何成本都可能产生多次。
这些倍增效应影响了我们的智能体执行框架设计。该框架是一个用 Rust 编写的编排层，用于连接模型、工具和用户环境。接下来，我们将介绍如何通过避免上下文膨胀、按需加载工具和复用工作成果，提高每次请求的效率。
随着智能体获得更多工具、技能、插件和对话历史记录的访问权限，上下文窗口很容易不断扩大。这会增加成本、分散模型注意力，并触发不必要的推理。执行框架可通过延迟发现来降低这项开销，仅在需要时才显示集成、自定义 MCP 工具、技能和插件。执行框架还可以防止单个工具和 MCP 集成意外占用上下文窗口。除非模型请求采用其他限制，否则工具输出默认上限为 10,000 个 Token。
如前所述，在一次交互中，智能体循环可能会多次向 GPU 发送相同的指令、对话历史记录、工具定义和先前结果。处理这些重复输入的成本很高，因此提示缓存会复用与先前已处理提示前缀相关的计算。为保留该前缀，执行框架会将模型可见的所有历史记录视为只能追加：新消息、工具结果和环境更新都添加到末尾，而不会插入之前的上下文。工具也会按确定的顺序呈现，而审批策略等运行时设置则在执行期间应用，不嵌入工具定义中。这一设计有助于 Codex 和 ChatGPT 工作实现较高的整体提示缓存命中率。
增量传输改变的是通过网络传输的内容；提示缓存改变的是模型可以避免重复计算的内容。图中宽度仅表示概念，且未显示额外的压缩层。
GPT‑5.6 带来的效率提升，源于我们多年来在整个技术栈中不断积累的改进，涵盖研究、推理和智能体执行框架。GPT‑5.6 在实现其中许多改进方面发挥的作用，让我们对优化速度进一步加快充满信心。我们将继续推进内核优化等领域的深度优化，同时对技术栈进行基础性改进。我们期待将这些持续进行的底层改进带给用户和客户，让高性价比的智能得到更广泛的应用。
特别感谢技术团队成员 Matthew Ferrari、Philippe Tillet、Ahmed Ibrahim、Joe Gershenson 和 Steve Coffey 对本文的贡献。
