GPT-5.6 的效率不是只靠模型更快

先说结论

Agent 的总耗时不是“模型生成速度”一个数。一次任务会重复准备上下文、调用模型、运行工具和传输结果；循环三十次的小浪费，会被放大三十次。真正有效的优化顺序是：先减少重复工作，再提高每次推理的硬件效率，最后才比较单次跑分。

问题

只盯首 token 延迟，容易忽略三个账单：同一长前缀反复计算、工具一次吐回过多内容、请求落到没有可复用缓存的实例。结果可能是模型基准更强，端到端任务反而更慢、更贵。效率还受正确率和可靠性约束；少调用一次却漏掉测试，不算优化。

核心机制

OpenAI 把改进分成三层。模型训练同时优化任务成功与 token 效率，让推理少绕路。推理层联合处理全局与集群内负载均衡、kernel、推测解码、KV cache 和工作负载配置。Agent harness 则缩小重复区域：能力按需发现，工具输出默认封顶；历史只追加不插入，工具顺序保持确定，使重复前缀更容易命中 prompt cache。

这三层会复利。原文报告，生产 kernel 等改进使端到端 serving cost 降低 20%，改进 draft model 使 token 生成效率提高超过 15%。这些是 OpenAI 在自身栈上的结果，本教程没有独立复现。

如何接到 Zero-to-AI 学习实践

给每个 Agent 任务画一条简单流水账：模型请求次数、每次输入规模、工具输出规模、缓存是否可用、最终验证是否通过。把长期说明放在稳定前缀，把变化信息追加到末尾；大工具只在需要时加载；日志先筛选再送给模型。优化目标写成“在相同验收下减少总请求或总上下文”，而不是“让回答更短”。

实践时先优化重复次数最多的环节。例如每轮都附带一万字构建日志，就先改成错误摘要和按需展开；只出现一次的启动提示，即使能省几十毫秒，也不该排在主线前面。每次只改一个变量，才能知道收益来自哪里。

低成本实验

选一个固定的小任务，例如读取三个文件并回答一个带测试依据的问题，连续做三组：A 组原样传完整工具输出；B 组给输出设上限并只取命中片段；C 组在 B 上保持指令和工具顺序稳定。记录请求数、可见输入 token、墙钟时间、答案与测试结果。每组跑三次即可；若正确性不同，实验作废。没有缓存指标时，只比较输入规模与时间，不推断后台缓存命中率。

成功证据： 三组使用同一任务、模型和验收；原始记录能复算请求数、输入规模与时间，且只有在正确性一致时才比较效率。

停止线： 任一组换了模型、工具或验收，缓存命中不可观察却被当作结论，或者正确率下降时，停止声称优化有效。

误区

• “token 少就是好”错在忽略任务成功率；省掉必要证据会制造返工。
• “prompt cache 等于网络压缩”不准确。前者复用模型对相同前缀的计算，后者减少传输字节。
• “20% 与 15% 可以相加”不成立。指标、基线和作用层不同，不能拼成个人环境收益。

原文与证据边界

页面说明的是 OpenAI 自有模型与生产系统，未公开足以在普通电脑重建同等环境的全部配置。本文把可迁移部分限定为测量方法和 harness 设计，不声称复现厂商性能。

本文是原创中文实践解读，不是逐句译文。英文原文见 OpenAI 官方文章。