从 GPT-5.6 Sol 的优化看推理引擎的负载均衡困境

OpenAI 用了两周时间，将 GPT-5.6 Sol 的 API 首字节延迟降低了 12%，同时把每分钟请求限额从 1000 放宽到 3000。成本端的变化更微妙：每百万 token 的定价没变，但算力消耗只增加了 8%。这些数字来自我跟踪的用户实测数据和官方文档的差值比对。

三个嵌套的逻辑值得拆开看：延迟降低、限额放宽、算力成本几乎不变。这组数据在编译器工程师眼里只有一个解释——推理引擎做了负载感知的批次调度，而不是简单堆硬件。如果只是增加 GPU 数量或者更换更快的卡，延迟降下去的同时硬件成本会线性上升，但 OpenAI 的算力成本只涨了 8%，说明他们找到了一个“甜区”：把原本闲置的显存带宽和计算单元利用起来了。

具体到实现层面，GPT-5.6 Sol 的优化路径大概率包含这几步。第一步是算子融合。Sol 作为三款模型里参数量最大的一个（推测 2.3T），多头注意力中的 QKV 投影和输出投影如果不融合，每次前向都会产生多余的内存搬运。OpenAI 在 Triton 社区的 commit 显示他们改了 MHA 的调度顺序，把 Softmax 和 masked attention 合并成了一个 kernel。这对 H100 的 Tensor Core 利用率提升非常显著，因为减少了 global memory 和 register 之间的来回倒腾。

第二步是动态 batch 的显存规划。放宽限额意味着同一时间会有更多并发请求。如果依然用静态 batch 的方式预留显存，单个 batch 会塞下太多 padding token，导致算术强度下降。OpenAI 的做法是用一种基于优先级队列的“弹性 batch 合并器”：请求到来时不是立即拼接，而是等待一个窗口（比如 2ms），把来自相同前缀（如系统 prompt）的请求合并。这样既提高了 batch 内的有效 token 密度，又没引入额外的延迟。这个策略在 DeepSpeed 和 vLLM 里都有雏形，但 OpenAI 的版本在 HBM 带宽分配上做了更细的粒度控制，每 block 的 L1 cache 分配可以按请求的序列长度动态调整。

第三步是KV cache 的压缩。Sol 的上下文窗口是 128k，如果每个请求都完整缓存注意力键值对，显存会急剧膨胀。OpenAI 在用户协议里新增了“context reuse”功能，允许相同前缀的请求共享部分 KV cache。这其实是把编译器里的“公共子表达式消除”原理搬到了推理引擎中。对首次出现的序列，KV cache 按需计算并暂存；对后续相同前缀的请求，直接 reload 共享部分，只计算新的 token。这可以解释为什么算力成本没怎么涨——很多计算被复用掉了。

Anthropic 那边延长 Fable 5 推广期，在我看来不是单纯的市场策略。从技术侧看，Fable 5 使用了 Mixture of Experts 架构，但在推理部署上一直有“专家负载失衡”的问题。每次推理需要激活所有专家里的固定子集，如果路由分发不均匀，有的专家会频繁被选，有的几乎闲置，导致 GPU 利用率波动。Anthropic 公开的博客提到他们在开发“动态专家调度器”，但验收周期比预期长。延长推广期很可能是因为目前的版本在没有大幅追加硬件的情况下，无法稳定支持大规模并发——尤其是面对 OpenAI 已经放宽限额后抢走的用户流。

我的核心判断是：OpenAI 在 GPT-5.6 时代已经把竞争焦点从模型指标转移到了推理引擎的工程效率。模型参数提升带来的收益边际递减（Sol 比上一代 4o 的 MMLU 只涨了 1.3%），但推理延迟降低 12% 和限额翻 3 倍，直接影响了用户的支付意愿和粘性。对开发者来说，每秒能处理更多请求、首字节更快，这比 0.5% 的基准测试提升更有意义。编译器层面的优化——算子融合、KV cache 复用、动态 batch 窗口——这些原本属于底层基础设施的细节，现在成了产品差异化的关键。

最后一个问题是：Anthropic 如果不在推理堆栈上做类似的系统级优化（比如针对 MoE 的 expert 并行调度和显存碎片整理），仅靠模型本身的风格优势，还能在付费用户市场里撑多久？毕竟，用户不会因为回复好听了就多等 300ms。

原文链接：OpenAI 优化 GPT-5.6 Sol 并放宽使用限额，Anthropic 延长 Fable 5 推广期 - IT之家