GPT-5.5 自举推理栈拆解：Codex 改写负载均衡启发式，同硬件吞吐提升 20% 的技术细节

GPT-5.5 发布说明里最容易被跳过的一句话，不是跑分，而是「模型帮助改进了服务它自己的基础设施」。

OpenAI 明确写到：Codex 分析了数周的真实生产流量，写出自定义的负载均衡与分区启发式算法。

最终结果是 token 生成速度提升超过 20%，而且是在同一批硬件上拿到的。

这不是一次常规的性能调优。

它意味着模型第一次以工程主体的身份，参与改写了承载自己的推理栈。

要理解这件事的分量，得先看清它替换掉的到底是什么。

一、被替换掉的是什么

在 GPT-5.5 之前，OpenAI 会把进入单块加速器的请求切成固定数量的分块。

这样做的目的是让大请求和小请求能在同一张 GPU 上共存。

固定分块的好处是实现简单，调度器不需要理解请求形状。

固定分块的代价是它建立在一个静态假设之上。

真实流量里，请求长度分布、到达间隔、并发形状每小时都在变化。

一个为平均情况调好的固定分块数，在流量偏斜时必然造成核心空转或排队堆积。

OpenAI 自己的表述是：预先确定的静态分块数对所有流量形状都不是最优的。

这句话点出了问题的本质——分块数是一个超参数，而流量分布是一个函数。

用单一超参数去适配一个持续变化的函数，注定在某些区间失效。

OpenAI 给出的解法是让 Codex 去写针对性的启发式分区与均衡算法。

换人来做这件事，通常需要几个月的数据分析与灰度实验。

而这次是代码智能体读完数周生产流量，直接产出可基准测试的实现。

20% 以上的速度提升，性质上属于「同硬件再挤出余量」。

它没有靠加卡、换机、堆算力，而是靠更聪明地分配已有算力。

对推理服务来说，这类收益的性价比远高于单纯扩容。

因为扩容要付真金白银，而调度优化只付一次性的搜索成本。

二、为什么这次自述不是营销话术

怀疑是合理的，厂商自述的优化数字向来需要打折看。

但这次的自述有一个可交叉验证的锚点：它嵌在硬件共同设计的叙事里，而不是孤立出现。

OpenAI 说明，GPT-5.5 是「为 NVIDIA GB200 与 GB300 NVL72 系统共同设计、共同训练、并部署其上」的。

NVIDIA 方面由企业 AI 副总裁 Justin Boitano 出面背书，给出了同向的技术描述。

按 NVIDIA 公布的数据，GB200 NVL72 相较上一代系统，每百万 token 成本低 35 倍。

同一份数据还提到，每兆瓦 token 产出高出 50 倍。

这些数字说明硬件侧提供的是量级上的经济性改善。

而 Codex 写出的负载均衡启发式，提供的是同硬件上再挤出 20%。

两者属于不同层面的收益，不能互相替代，也不该互相掩盖。

更值得关注的是延迟这条线。

更大的模型通常意味着更慢的服务，这是行业里反复验证过的经验。

OpenAI 声称 GPT-5.5 在真实服务中与 GPT-5.4 保持每 token 延迟持平。

与此同时，它的智能水平显著更高，输出 token 显著更少。

要同时做到更强、不更慢、还更省，推理栈本身必须被重新设计。

OpenAI 的表述是：把推理当作一个集成系统来重新思考，而不是一组孤立的优化。

这恰好解释了为什么模型会参与到基础设施工作中——瓶颈已经不在模型单点。

当模型能力快速提升时，真正稀缺的是系统协同效率。

三、自举闭环的三个技术环节

把这次改进拆开，可以看到三个彼此衔接的环节。

它们分别是读取真实流量、生成分区策略，以及人对投入方向的判断。

三个环节缺一不可：没有真实数据则策略失真，没有算法生成则无法覆盖策略空间。

而缺少人的判断，则会出现优化了一个不值得优化的目标这种典型浪费。

环节一：代码智能体读生产流量

Codex 拿到的是数周的真实生产流量模式，而不是合成基准。

合成流量最大的问题是分布失真。

它很难复现真实世界里的请求长度长尾、突发并发和时段波动。

用真实流量做输入，才可能针对真实的偏斜形状写启发式。

否则优化出来的策略只会适配想象出来的平均情况。

这一步的价值在于，它把经验驱动的调度调优，变成了数据驱动的算法生成。

环节二：从静态分块到启发式分区

原始方案是固定分块数，新方案是按流量形状动态决定如何分区与均衡。

这是一次典型替换：用对输入分布敏感的策略，替换对输入分布不敏感的策略。

分区问题的本质是一个负载均衡问题。

它的目标是最小化最忙计算核心的空闲等待时间。

当每条请求的计算量不同、到达时间不同，最优分区本质上是一个在线调度问题。

在线调度没有完美的通用解，理论上的最优需要预知未来。

所以工程上只能寻找足够好的启发式。

而「寻找好的启发式」恰好是代码模型擅长的事情。

它需要对大量候选策略反复试错、快速实现、跑实验、看结果。

这解释了为什么这项工作的形态是模型写算法，而不是人调参数。

调参数是在既定策略里找最佳取值，写算法是在策略空间里找新的形状。

后者能到达的收益上限明显更高。

环节三：人保留判断，模型承担搜索

注意 OpenAI 的措辞：Codex 帮助团队更快地从想法走到可基准测试的实现。

具体动作包括勾勒方案、接通实验，以及识别哪些优化值得深入投入。

「帮助识别哪些优化值得投入」这句话，暗示人的位置仍然在决策环上。

模型负责搜索空间里的大量试错，人负责决定往哪里投入资源。

这是一个比「AI 全自动运维」更可信、也更接近现实的分工描述。

把它拔高成完全自治是过度解读。

但把它贬低成营销辞令，同样不符合已披露的细节密度。

四、对使用者的实际含义

这件事对一线工程师有相当具体的启示。

下面三条分别对应成本判断、产品竞争与个人技能迁移三个层面。

它们都不是抽象的趋势判断，而是可以立刻落到工作里的动作。

1. 效率提升未必体现在单价上

GPT-5.5 的 API 定价是每百万输入 5 美元、输出 30 美元。

这个价格恰好是 GPT-5.4 的两倍。

但官方补充了 token 效率：完成同样的 Codex 任务，输出 token 减少约 40%。

两相抵消，重度 Codex 用户的实际成本上升幅度接近 20%，而不是 100%。

这个折算有个前提：40% 更少 token 必须在你自己的工作负载上成立。

它是厂商自述数字，需要在自己的任务分布上验证，不能默认套用。

工程上正确的做法是：先在小样本上跑自己的任务集，量出真实 token 消耗比。

下面这段脚本就是用来做这件事的——把同一批任务分别打到两代模型上，统计 token 与耗时。

import os, json, time
from openai import OpenAI

client = OpenAI(api_key=os.environ["OPENAI_API_KEY"])

# 用你自己的真实任务集替换这里，不要用玩具样例
TASKS = json.load(open("my_codex_tasks.json", encoding="utf-8"))

MODELS = ["gpt-5.4", "gpt-5.5"]

def run_once(model: str, prompt: str) -> dict:
    start = time.perf_counter()
    resp = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
    )
    elapsed = time.perf_counter() - start
    usage = resp.usage
    return {
        "model": model,
        "prompt_tokens": usage.prompt_tokens,
        "completion_tokens": usage.completion_tokens,
        "total_tokens": usage.total_tokens,
        "latency_s": round(elapsed, 3),
    }

def compare(tasks: list) -> dict:
    rows = []
    for task in tasks:
        pair = {}
        for model in MODELS:
            pair[model] = run_once(model, task["prompt"])
        rows.append({
            "task_id": task["id"],
            "prompt_tokens": pair["gpt-5.5"]["prompt_tokens"],
            "completion_ratio": round(
                pair["gpt-5.5"]["completion_tokens"]
                / max(pair["gpt-5.4"]["completion_tokens"], 1), 3
            ),
            "latency_delta_s": round(
                pair["gpt-5.5"]["latency_s"] - pair["gpt-5.4"]["latency_s"], 3
            ),
        })
    return {"tasks": len(rows), "rows": rows}

if __name__ == "__main__":
    print(json.dumps(compare(TASKS), ensure_ascii=False, indent=2))

这段代码的关键设计，是把成本判断下沉为可测量的 token 结构比。

它不接受厂商给出的单一降幅数字，而是要求你在自己的任务上复现。

completion_ratio 小于 1，说明新一代确实更省输出 token。

如果它接近或大于 1，说明你的任务不吃这套优化，迁移未必划算。

latency_delta_s 用来验证「延迟持平」在你的网络与负载下是否成立。

这两条指标才是迁移决策的真实依据。

2. 服务效率正在变成产品能力

当负载均衡启发式能让吞吐提升 20%，推理成本就直接变成了可运营的竞争变量。

这解释了为什么前沿实验室都在往执行层押注。

模型推理能力在快速商品化，单纯卖 token 很难形成壁垒。

真正能形成壁垒的，是谁来定义 agent 怎么调工具、怎么管上下文、怎么编排业务。

GPT-5.5 的自举优化，是这条逻辑在基础设施层的直接体现。

同一时期 OpenAI 把 Agents API 开放公测，也是同方向的动作。

驱动它的 Codex harness 以 Apache-2.0 开源，同样指向执行层。

开源争的是开发者心智，托管收的是工作负载的账。

而自举优化证明的是：这套执行层确实能持续产生可量化的效率收益。

三者合起来，构成了一条完整的商业闭环叙事。

3. 写算法正在从人转向模型

过去，写一个针对特定硬件拓扑的调度启发式，是资深性能工程师的专属工作。

它需要对执行模型、内存带宽、缓存行为有直觉，还需要大量实验时间。

现在这条路径被拆成了两步：提供真实数据，让模型搜索实现。

这不意味着性能工程会消失。

它意味着性能工程师的产出形态会发生变化。

从亲手写 kernel，转向定义目标函数、构造评测、判断哪些优化值得投入。

OpenAI 的措辞里恰好保留了这后一半。

五、三个容易被误读的点

第一，20% 的加速不是模型变快，而是调度变好。

模型权重没有因为这次优化发生变化。

改变的是请求如何被分发到计算核心上。

把两者混为一谈，会得出新一代模型硬件效率更高的错误结论。

第二，Codex 参与不等于无人监督。

「帮助识别哪些优化值得深入投入」这句话，说明筛选权仍然在人手里。

把这次披露直接推向 AI 自主运维生产集群，是超出证据的推论。

第三，延迟持平不等于体验持平。

每 token 延迟持平，和端到端任务耗时下降，是两件不同的事。

40% 更少的输出 token 会带来更短的完成时间。

这部分收益来自任务效率，而不是服务速度。

报告里这两个数字经常被混着用，读的时候需要分开。

把服务速度的改善算成任务效率，会高估迁移的收益。

反过来把任务效率算成服务速度，则会低估它的实际价值。

六、这条技术路线值怎么看

把这次基础设施改进放进更大的脉络里看，方向是清楚的。

前沿竞争已经从单点跑分，转向谁能把编码、工具调用、电脑操作整合成可用产品。

在这个整合过程里，模型开始参与优化承载自己的系统，是一个自然结果。

它在架构上意味着模型与推理栈的边界正在模糊。

当模型能读生产流量、能写调度算法、能跑基准验证，它就不再只是一个被服务的对象。

它同时成为了服务栈的维护者之一。

对使用者的实操建议可以归纳成三条。

其一，任何厂商自述的效率提升，都要用自己的任务集量一遍再采信。

其二，关注 token 结构比和端到端耗时，而不是只看单价和每 token 延迟。

其三，把性能工作的时间预算，从手写实现往构造评测与定义目标上移。

GPT-5.5 这次披露的价值，不在于 20% 这个数字本身。

而在于它公开承认了一件事：模型改进的下一个增量，越来越多来自模型之外的那层系统。

而那一层，现在也开始由模型自己来写了。