2026 年 8 月 13 日夜间，OpenAI 用三条推文预览了 GPT-5.6 Sol 的 Ultrafast 模式：同一个旗舰模型，跑在 Cerebras 的晶圆级芯片上，输出速度最高 750 tokens/秒，约为标准处理模式的 14 倍。这条预览当天拿到 170 万次浏览，但狂欢之外有两个冷静的事实：它目前只对一小部分 API 客户开放，价格、区域、速率限制全部未公布。
也就是说，大多数人短期内调不到它。那这篇文章的价值在哪？在于 Ultrafast 不是孤立事件——它是「推理速度分层」这个时代正式到来的标志。Cerebras 自己就有公开 API，Groq、各家推理厂商都在卖「极速档」。当模型输出从每秒几十 token 跳到几百上千 token，应用的交互设计、Agent 的循环结构、成本账的算法都要跟着变。这篇文章走通三件事：把 Ultrafast 的事实边界划清楚，写一个今天就能用的推理速度实测脚本，以及列出应用侧现在就该做的四个改造。
一、Ultrafast 的事实边界
先把已确认的信息和未知的部分分开，避免基于传言做架构决策。
| 项目 | 状态 | 说明 |
|---|---|---|
| 模型 | GPT-5.6 Sol（5.6 家族旗舰） | 速度与标准模式对比的基准是同一模型 |
| 峰值输出速度 | 最高 750 tokens/秒 | 官方口径，约为标准模式的 14 倍；「最高」意味着不是保证值 |
| 硬件 | Cerebras 晶圆级芯片（WSE 系列） | OpenAI 自 7 月起就在为部分客户悄悄用 Cerebras 跑 Sol |
| 开放范围 | 仅限少数 API 客户 | 会随产能扩大逐步开放；ChatGPT、Codex 侧未宣布接入 |
| 价格 | 未公布 | 标准档为输入 $5 / 输出 $30 每百万 token，极速档大概率有溢价 |
| 区域与速率限制 | 未公布 | 无 SLA 承诺 |
为什么 Cerebras 能这么快？简单说，它的 WSE-3 是一整块晶圆大小的芯片，片上 SRAM 带宽极高，权重不用反复从显存搬运，解码阶段（逐 token 生成）的速度瓶颈被大幅缓解。这条路线和 GPU 集群是两种工程哲学，GPU 强在通用和生态，晶圆级芯片强在单请求解码速度。
一个要守住的事实边界：750 tokens/秒是 OpenAI 对这一个模型、这一个服务层给出的峰值数字，不代表所有 Cerebras 托管的模型都能跑到这个速度，也不代表你的实际负载能稳定吃到峰值。
二、750 tokens/秒到底改变了什么
很多人对「快 14 倍」没有体感，换算成交互时间就有了。假设一次典型的代码补全输出 500 token：
- 标准模式按 50 tokens/秒估算：约 10 秒，用户会盯着转圈。
- 750 tokens/秒：约 0.7 秒，比人眼读完第一段还快，「等待」这个概念消失了。
过了某个速度阈值，产品形态会跟着变。三件以前不成立的事现在成立了：
- 语音 Agent 的全双工对话：人说话的自然语速约每秒 3-5 个词，语音 Agent 要在用户停顿的 300-500 毫秒内开始回应，整条链路（识别→推理→合成）里推理必须压到一秒以内，极速推理层让大模型首次够格进这条链路。
- 「写完即改完」的结对编程：补全速度快过阅读速度时，交互从「请求-等待-阅读」变成「模型一直在你旁边写，你负责随时打断和接管」。
- Agent 循环的步数预算重算：一个 20 步的工具调用循环，每步省 8 秒就是 160 秒——长任务 Agent 的「跑几个小时」可以压缩到「跑几分钟」，长时任务的可交互性完全变了。
反过来，纯离线批处理（夜间跑评测、批量打标）对速度不敏感，这类负载继续用便宜的标准档甚至批价档就好，没必要为极速档的溢价买单。
三、今天就能跑：推理速度实测脚本
Ultrafast 还没开放，但速度分层不是只有 OpenAI 一家在做。Cerebras 有公开 API，Groq、Fireworks 等厂商也提供高速托管的开源模型。在等 Ultrafast 开放的同时，完全可以先用这些端点把自己的「速度适配」工作做掉。下面这个 Node 脚本测量两个关键指标：首 token 延迟（TTFT）和稳态输出速度（tokens/秒），任何兼容 OpenAI 流式接口的端点都能测。
// bench-speed.mjs — 用法：node bench-speed.mjs
// 依赖：项目里装 openai（npm i openai），或直接用 fetch 改写
import OpenAI from "openai";
const endpoint = {
baseURL: process.env.API_BASE_URL, // 例：https://api.cerebras.ai/v1
apiKey: process.env.API_KEY,
model: process.env.MODEL || "llama-3.3-70b",
};
const client = new OpenAI(endpoint);
async function bench(prompt, maxTokens = 512) {
const t0 = performance.now();
let ttft = null;
let tokens = 0;
const stream = await client.chat.completions.create({
model: endpoint.model,
messages: [{ role: "user", content: prompt }],
max_tokens: maxTokens,
stream: true,
stream_options: { include_usage: true },
});
for await (const chunk of stream) {
if (ttft === null && chunk.choices?.[0]?.delta?.content) {
ttft = performance.now() - t0;
}
if (chunk.choices?.[0]?.delta?.content) tokens++;
if (chunk.usage) tokens = chunk.usage.completion_tokens; // 以 usage 为准
}
const total = performance.now() - t0;
const genTime = (total - ttft) / 1000;
console.log(`TTFT: ${ttft.toFixed(0)}ms | 输出 ${tokens} tokens | 生成耗时 ${genTime.toFixed(2)}s | 速度 ${(tokens / genTime).toFixed(0)} tok/s`);
}
// 预热一次再测三次，取稳定值
await bench("用一句话介绍你自己。", 64);
for (let i = 0; i < 3; i++) {
await bench("用 Python 写一个支持断点续传的分片下载器，带上完整注释。", 512);
}
测的时候记住三个口径问题：一是峰值与稳态，短输出测出来的速度偏高，512 token 以上的输出才有参考意义；二是负载时段，共享端点在高峰期会掉速，固定每天同一时段测才能横向比；三是模型不同不可比，Cerebras 上跑开源 70B 的速度和 GPT-5.6 Sol 的 750 tok/s 不构成「谁更快」的对比，只能说明这条硬件路线的能力上限。
四、应用侧现在就该做的四个改造
不管最后拿到的是 Ultrafast 还是别家的极速档，这些改造都是通用的，而且今天做今天受益。
1. 把流式渲染当成默认路径，而不是增强项。 检查你的前端：是不是还在等完整响应返回再渲染？极速档下 TTFT 可能只有 100-200 毫秒，逐 token 渲染的「打字机效果」反而成了瓶颈。该改的是渲染管线的节流策略（requestAnimationFrame 批量提交），不是等模型。
2. 给调用链加「速度档位」抽象。 在封装 LLM 调用的那一层加 speed: "fast" | "standard" | "batch" 参数，把语音回复、实时补全标记为 fast，后台总结、报告生成标记为 standard 或 batch。等 Ultrafast 开放或你接入别家极速档时，只需要改路由表，不需要改业务代码。这也呼应我们之前讲过的多模型备胎方案——速度档和模型档本质上是同一张路由表的两个维度。
3. Agent 循环里区分「思考步」和「执行步」。 规划和决策走标准档旗舰模型，读文件、格式转换、简单改写这类高频低难度步骤走极速档或本地小模型（Nemotron 3.5 Lightning 这类 A3B 模型就是为这一层设计的）。速度分层和成本分层在这里是同一件事。
4. 重算超时与重试参数。 按 50 tok/s 设的 60 秒超时，在 750 tok/s 的世界里等于允许模型磨蹭 45 秒。极速档的超时可以激进地压到 5-10 秒，配合快速失败重试，整体可用性反而上升。
五、注意事项与常见问题
Q：Ultrafast 值得等吗，还是现在就用别家极速档？ 看负载形态。实时交互类负载（语音、结对编程、Agent 循环）现在就该上极速档，谁家便宜好用用谁家，抽象做好之后换供应商是改配置的事。离线批处理不用等也不用换。
Q：750 tok/s 会不会很快降价普及？ 可以参考的规律是：任何「专用硬件保证速度」的服务层，初期都带着明显溢价，且优先服务大客户。把架构准备好，等价格落到你的区间再切，比押注时间表靠谱。
Q：速度上去之后，质量会不会掉？ Ultrafast 跑的是同一个 GPT-5.6 Sol，官方口径是同一模型的不同服务层，不是蒸馏小模型。但「最高 750」不是承诺值，接入后用自己的评测集回归一遍质量和速度，是任何供应商切换的标准动作。
Q：测速脚本里的 token 计数为什么以 usage 为准？
流式分片和 token 不是一一对应的（一个 token 可能跨分片，一个分片也可能带多个 token），自己数 delta 会有几个点的误差，include_usage 返回的 completion_tokens 才是计费口径。
小结
GPT-5.6 Sol Ultrafast 的意义不在于「OpenAI 又快了 14 倍」，而在于推理速度正式成为一个可以单独购买的商品维度。短期动作：用文中的脚本把手头负载的速度基线测出来，给调用层加速度档抽象。中期动作：Agent 循环拆分思考步与执行步，执行步切到极速档或本地小模型。等 Ultrafast 或同类服务落到你的价格区间，切换只是改一行路由配置。先把架构做对的人，会是速度红利的第一批收割者。