GPT-6 Sol 延迟实测：首 token 要等 102 秒

你把 gpt-6-astra 换成了 gpt-6-sol，因为 token 价格从每百万 $10 和 $50 降到了 $2 和 $10。账单看起来漂亮极了。然后你的 p95 响应时间越过两分钟，负载均衡器开始返回网关超时，客服那里塞满了问页面为什么卡住的人。

没有任何东西坏掉。你改变的是任务负载的形态，而不只是它的价格。

Artificial Analysis 测得 GPT-6 Sol 的输出速率为 115.2 token/秒，首 token 时间 102.15 秒；GPT-6 Luna 为 153.9 token/秒，首 token 时间 124.23 秒。这两个数字带着一大堆前提，本文前半部分讲的就是这些前提。后半部分讲该怎么办：如何在你自己的任务负载上诚实地测量首 token 延迟，以及四项设计改动，让一个要 100 秒才开口的模型不至于把你的 API 一起拖垮。

想了解两天内三款前沿模型发布的整体背景，请看 2026 年 9 月的模型价格战。

AI Coding 交流群

如果你也在用 AI 写代码，或者正在研究 Cursor、Claude Code 这些工具，欢迎加入以下交流群。群里平时会聊一些 AI 编程的实际用法、开发工作流，还有各种新工具和新玩法。

这个数字，以及引用它时的一切毛病

先看限制条件那一列，再看数字那一列。

这一列在告诉你的三件事。

这些是 Artificial Analysis 的数字，不是 OpenAI 的。OpenAI 在发布时公布了价格、上下文、可用性以及一堆基准测试分数，但在我们读到的材料里并没有公布延迟数字。所以 102.15 秒是第三方在自己的网络、自己的测试框架上跑出来的，你应当把它当作方向性参考，而不是规格指标。在你自己的文档里，也按我们这里的标注方式来标注它。

它们描述的是“max” reasoning 档位。两家厂商发布时的基准测试表格里到处都是 effort 标签：low、medium、high、xhigh、max。max 是这条阶梯的顶端，而 reasoning effort 是影响首 token 延迟的最大单一杠杆。对最慢配置的测量，不等于你会在生产环境运行的配置的表现。

它们只是一家提供商的接口在某一时刻的测量值。服务容量、路由和排队深度都会变。在流量高峰期间取的 发布周数字，是最坏情况伪装成的常数。

能穿透这三条限制条件留下来的，是方向，而方向正是本文的重点。便宜的模型并不是快的模型。Sol 每 token 的成本是 Astra 的五分之一，Luna 是 Sol 的二十分之一，而这些折扣都换不来更快的首字节。在这次测量里，家族中最便宜的模型恰恰是最慢才开口的那个。

“首 token 时间”这个名字并不能准确描述你实际测到的东西

在非 reasoning 模型上，首 token 时间大致等于网络加排队加 prefill。它随 prompt 长度增长，落在几百毫秒的量级。

在 reasoning 模型上，它是贴着同一个标签的另一种量。模型先完成思考，然后才输出你要的任何内容，所以第一个可见 token 之前的这段空档里装着整个 reasoning 阶段。这个阶段与你的 prompt 长度无关，只与模型判断这道题有多难有关。

由此产生两个后果，它们在线上都会咬人。

第一，token 速率快救不了你。Sol 一旦开始输出，速度是 115.2 token/秒，确实很快。但这没多大意义，因为几乎整个墙钟时间都花在第一个 token 之前。

生成时间等于输出长度除以 115.2 token/秒，所以这张表是对两个实测数字做的算术，而不是一次新的测量。缩短回答几乎不改变总时长。把一个啰嗦的回答从 2,000 token 裁到 500 token，只给一次两分钟的调用省下十三秒。

第二个后果是，排名会随回答长度翻转。Luna 的 token 速率更快、开局更慢。把两条线放在一起跑，它们大约在 10,100 个输出 token 处交叉：低于这个点，Sol 尽管生成更慢却先完成；高于这个点，Luna 的速率才终于抵得上它更长的等待。你面向用户提供的内容几乎没有 10,000 token 的回答，所以对大多数任务负载来说，开局更慢的模型就是更慢的模型。

先出问题的是什么

出问题的很少是模型调用本身，而是围着它、按快速 API 来设计的一整套东西。

Idle timeouts. 负载均衡器、反向代理、API 网关和无服务器平台都会限制一条连接可以在没有字节流动的情况下挂多久。很多默认值远低于两分钟。不要相信你在博客文章里读到的数字，包括这一篇：去读你自己的配置。修法通常只需要一条指令，比如 nginx 上的 proxy_read_timeout，再加上它前面每一跳的对应设置，包括客户端 SDK 自己的超时。

Retries. 一套在 300 毫秒时合理的重试策略，放到 100 秒时就很危险。三次带退避的尝试现在变成了一次五分钟的请求，而慢速期里的一波重试，会给本来就已经吃力的那个接口压上更多并发。给尝试次数设上限、保留熔断器，并让每次调用都幂等，这样重试就不会重复扣费或重复写入。

Concurrency, which is the one people miss. 利特尔法则说的是，在途请求数等于到达率乘以在系统内的时间。每秒一个请求、每次调用 120 秒，你就需要 120 个并发在途请求才跟得上。这些连接每一个都要占用两分钟的 socket、线程或函数调用，而这一切都不会出现在 token 账单上。一个每次调用很便宜的模型，按占用容量的每秒成本算仍然可能很贵。

The user interface. 没有任何加载动画能撑过 102 秒。如果 reasoning 阶段位于你的同步请求路径上，那要改的是架构，而不是外观。

如何在自己的任务负载上测量它

厂商和第三方的数字只是最初的假设。你的 prompt、你的区域、你的 effort 设置和你的流量模式才决定真实数字。

先从 传输层视角入手，它只需要一条命令：

curl -N -s -o /dev/null \
  -w 'dns=%{time_namelookup} connect=%{time_connect} first_byte=%{time_starttransfer} total=%{time_total}\n' \
  https://api.openai.com/v1/responses \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"gpt-6-sol","input":"Summarise this OpenAPI operation.","stream":true}'

然后带着怀疑去读 first_byte。在流式接口上，最初的字节通常是 流打开事件，而不是内容 token，所以 time_starttransfer 测量的是服务端什么时候开始说话，而不是模型什么时候开始回答。而这段差距恰恰就是你想估算的东西，这也是为什么粗糙的测试框架会报出一个好看的数字。

对第一个内容增量计时，才是有意义的测量：

import time
from openai import OpenAI

client = OpenAI(timeout=600)

t0 = time.perf_counter()
first_content = None

with client.responses.stream(
    model="gpt-6-sol",
    input=PROMPT,
    reasoning={"effort": "low"},
) as stream:
    for event in stream:
        if event.type == "response.output_text.delta" and first_content is None:
            first_content = time.perf_counter() - t0
    total = time.perf_counter() - t0

print(f"ttft={first_content:.2f}s total={total:.2f}s")

这些代码片段里的字段名和事件名来自当前的 OpenAI API 形态，而不是来自 GPT-6 的发布公告，所以上线前请对照参考文档核查一遍。真正能沿用的是测量纪律：把首内容 token 时间和总时间作为两个独立指标记录，按模型、按 effort 档位分别保留，并且报告 p95 而不是平均值。首 token 延迟在 reasoning 模型上有很长的长尾，而平均值恰恰会把那些超时的请求藏起来。

把它当作定时检查来跑，而不是一次性操作。把流式请求保存到 Apifox，对响应时间做断言，并在 CI 里按计划运行这个场景，这样提供方一侧的退化或者 effort 档位的变动，会表现为一个失败的测试，而不是一张客服工单。同一个项目还能给前端工作一条绕开等待的路：把客户端指向你自己接口的 Apifox mock，这样在真实集成还在开发时，没人会因为每次迭代要等两分钟而被卡住。如果你想了解这些指标背后的基础知识，我们的 API 延迟指南梳理了相关术语。

四个真正有用的改动

Get the reasoning call off the synchronous path. 先接受请求，立刻返回带 job id 的 202 Accepted，再通过轮询或 webhook 交付结果。这是唯一一个能让其他所有问题都变小的改动，因为那 102 秒不再活在一个上游正在等待的 HTTP 请求里。

Route by effort, not by model. 那些实测数字描述的是 max reasoning。大多数流量并不需要它。先给任务分类，让常规的大多数走 low effort，把昂贵的档位留给真正够格的情况。OpenAI 自己的发布基准测试正是出于这个原因才按 effort 档位分别报告，所以这个设置是 一等的设计决策，而不是调参细节。

Stream, and show the wait honestly. 如果有真人在看，就流式返回响应，并告诉他当前在做什么。一个反映真实进展的状态，胜过暗示着出问题的转圈动画。

Budget wall clock separately from tokens. 单任务成本和单任务延迟是两条独立的轴，而 9 月的这几次发布把其中一条狠狠地推动了。在每个接口的成本预算旁边再放一份延迟预算，任何一方的退化都当作发布阻塞项。

有一点不要假设：GPT-6 的提示缓存发布把缓存输入读取的价格降低了 90% 并提升了命中率，这是实打实的省钱。但两家厂商都没有为它公布延迟方面的说法，所以缓存带来的任何首 token 改善，都应当当作要测的东西，而不是可以依赖着做规划的东西。

便宜的模型不是快的模型

GPT-6 Sol 每百万 token $2 和 $10 的价格是真实的降价动作，支撑它的基准测试结果也确实很强。但这些都不能让它更快开口。在目前唯一公开的延迟测量中，那个能帮你在 Astra 的 token 价格上省下 80% 的模型，要等一分半以上才说出第一个字，而它更便宜的兄弟等得更久。

价格写在账单上，延迟写在你的架构里。在你把一个更便宜的模型推进一条为更快的模型而建的请求路径之前，先用自己的测试框架测一测后者，而且要测的是第一个内容 token，而不是第一个字节。

开发必备：API 全流程管理神器 Apifox

介绍完上文的内容，我想额外介绍一个对开发者同样重要的效率工具 —— Apifox。作为一个集 API 文档、调试、设计、测试、Mock、自动化测试于一体的工具，Apifox 是目前提升研发效率的首选。

如果你正在开发项目，不妨试试其极其友好的界面设计，它完全兼容 Postman 和 Swagger 数据格式，导入数据非常方便，，即使是新手也能很快上手，点击这里即可注册使用。

值得一提的是，除了个人和常规团队使用，针对有高安全合规要求、或需要在内网环境协作的企业，Apifox 还提供了深度定制的私有化部署方案。

获取专属报价与部署方案

详细的私有化部署系统架构与安全白皮书

针对您公司规模的专属报价单

免费的 1v1 专属产品演示 (Demo) 机会

获取部署方案

* 提交后，我们的客户经理将在 1 个工作日内与您联系

林俊锋 企业微信

@Apifox 专属顾问

扫码备注: 私有化 + 公司名