GPT-5.6 的 20% serving 成本下降：OpenAI 把优化推进到内核和 Agent harness (2026)

OpenAI 7 月 29 日发布的工程博客给出了两个容易被混写的数字：GPT-5.6 相关优化让端到端 serving cost 下降 20%，speculative decoding 让 token-generation efficiency 提升超过 15%。前者是多项推理栈改动合并后的系统指标，后者只描述生成环节的效率；它们都不是「模型本身便宜了多少」的同义词。1

先把两个数字分开

20% 来自更宽的优化组合。OpenAI 说，GPT-5.6 Sol 借助 Codex 分析生产流量、改进路由，并自主重写和优化生产 kernel；这些工作与其他 kernel 改进合并后，把端到端 serving cost 降低了 20%。原文没有给出基线硬件、流量构成、时间窗口、各层贡献或成本会计，所以这个数字不能直接改写成每次 API 请求都便宜 20%。1

超过 15% 则来自 speculative decoding。小型 draft model 先提出多个 token，主模型再并行验证；被接受的候选可以减少主模型逐 token 顺序计算的次数。OpenAI 称 GPT-5.6 Sol 自己设计并运行了数百个 draft model 架构实验，还启动和监控训练，在硬件故障与训练不稳定时介入，最终让 token-generation efficiency 提升超过 15%。这个数字不是端到端延迟下降 15%，也不是 serving cost 下降 15%。1

OpenAI 对 GPT-5.6 效率来源的总览图，展示 Agent harness、API orchestration 与 model inference 如何共同减少网络数据和 CPU 工作，并增加 GPU 输出 — 图中把效率放在同一条系统链路上：Agent harness 减少重复工作，API 编排减少传输和调度开销，模型推理层提高硬件产出。1

serving 的瓶颈不只在 kernel

一段 kernel 变快，不代表整套服务就变便宜。请求可能被分配到错误的机器，硬件可能没有吃满，或者数据搬运和同步又把算力优势抵消掉。

OpenAI 描述的路由有三层：全球层面按地域、可用容量和加速器类型分流；集群内按负载、上下文长度和 cache availability 分配到模型实例；实例内部再把工作切到加速器、模型子网络和计算核心。GPT-5.6 Sol 在 Codex 中分析生产流量、寻找此前被忽略的失衡来源、测试路由策略并持续调整启发式规则。博客只给出「显著降低 serving cost」的定性判断，没有公布这部分的独立百分比。1

kernel 优化发生在 forward pass，也就是把输入变成下一个 token 预测的计算路径上。OpenAI 说，GPT-5.6 Sol 找出可以预计算、跳过或并行化的工作，并用 Codex 自主改写生产 kernel。它依赖模型对 Triton 和 Gluon 的编程能力；Triton 官方文档把 Triton 定义为用于编写并行程序和高吞吐 DNN compute kernel 的语言与编译器。1 2

自动改写不等于可以跳过验证。OpenAI 特别提到使用 FpSan 检查生成的 kernel；Triton 文档将它定位为 kernel-checking 工具，用于比较优化 kernel、融合 kernel 和参考实现的符号计算结果，但也明确它不是 IEEE 浮点模拟器。这个边界很重要：生产推理的收益必须和数值正确性、同步和数据流检查一起验收。1 3

speculative decoding 只解决生成环节

未缓存的输入需要先建立 KV cache；生成输出时，系统又要反复读取并扩展这份 cache。batch、sharding 和 KV 管理的最优配置，取决于 prompt 和 output 长度、batch size、cache hit rate 以及查询特征。OpenAI 称 GPT-5.6 Sol 在 Codex 中分析生产 workload，生成并评估候选配置，再按场景优化 engine 和 model。这让「同一套硬件能处理多少有效推理」从粗粒度启发式，变成可持续调参的问题。1

这里的 speculative decoding 与 workload-specific tuning 处在不同位置：前者减少主模型生成 token 的顺序计算，后者决定 batch、分片和 cache 怎样配合当前流量。15% 以上的数字只属于生成效率，不能替代整条服务链路的延迟、吞吐和成本测量。

Agent harness 节省的是每轮都会重复的工作

Codex 或 ChatGPT Work 完成一个复杂任务时，可能先读代码，再查部署记录、读事故报告、改文件、跑测试。每一步都可能发起新的模型请求。只要一次循环多做一秒，几十次循环就会把这秒钟放大成可感知的等待和额外算力。

OpenAI 的 Rust harness 从三处压缩这种重复成本：

延后发现工具：只有需要时才让 integrations、MCP tools、skills 和 plugins 出现在模型可发现范围，工具输出默认限制为 10,000 tokens，模型需要时才请求不同上限。1
保留可缓存的精确前缀：模型可见历史采用 append-only 结构，新消息、工具结果和环境更新统一追加；工具按确定顺序展示，运行时设置在执行阶段应用。这样，同一轮 Agent 中反复发送的前缀更容易命中 prompt cache。1
减少跨层传输：官方图示区分了持久连接上实际传输的字节、模型看到的增长中上下文，以及仍可复用的缓存前缀。传输变少与模型少重算不是一回事，但两者都会落在多轮任务的总成本上。1

OpenAI 展示 append-only context 如何让多次请求复用 prompt cache 前缀，并减少持久连接上的重复传输 — 这张图对应的是 Agent 多轮循环的编排层：它不改变模型每个 token 的计算方式，而是减少每一轮重新处理同一上下文的机会。1

这份效率报告的公开边界

OpenAI 把 GPT-5.6 的效率写成一个系统结果，而不是单项技术的排行榜。读者能确认的关系是：

路由、调度和 cache 配置决定硬件能否持续有工作可做。
kernel 优化和 speculative decoding 决定单次生成怎样少做顺序计算。
Agent harness 决定多轮任务是否每一轮都重复传输和处理相同信息。

但目前还不能从这篇博客回答四个工程问题：20% 的基线硬件和流量是什么；每项优化各自贡献多少；15% 的接受率、延迟分布和 workload 方差是多少；GPT-5.6 Sol 参与优化所节省的工程人时是否计入成本。博客也没有给出把这些收益迁移到其他模型、其他 GPU 或其他 Agent harness 后的统一比例。1

因此，最稳妥的读法是：GPT-5.6 的效率收益来自多个时间尺度上的复利。一次推理内部，speculative decoding 让主模型少做顺序计算；服务系统层面，路由、kernel、KV cache 和 workload tuning 让同一硬件承载更多有效工作；多轮 Agent 层面，harness 让上下文和工具结果少被重复处理。20% 和 15% 以上都是真实的官方指标，但它们必须和硬件、流量、缓存命中率、工具循环及正确性验证一起看，才有工程意义。

GPT-5.6 的 20% serving 成本下降：OpenAI 把优化推进到内核和 Agent harness

先把两个数字分开

serving 的瓶颈不只在 kernel

speculative decoding 只解决生成环节

Agent harness 节省的是每轮都会重复的工作

这份效率报告的公开边界

References

Related content