# GPT-5.6 Sol 跑出每秒 750 Token：瓶颈转移后，什么才是真慢？

**Summary:** Cerebras 称 GPT-5.6 Sol Ultrafast 可达每秒 750 输出 token；我认为只有当模型延迟仍是工作流主导因素时，这个速度才有意义。

- Canonical: https://markhuang.ai/zh/news/gpt-5-6-sol-750-tps-bottleneck-moves
- Language: zh-CN
- Author: [Mark Huang](https://markhuang.ai/about)
- Published: 2026-08-13
- Section: News
- Tags: GPT-5.6 Sol, Cerebras, AI 推理
- Source: [Cerebras](https://www.cerebras.ai/blog/accelerating-gpt-5-6-sol-ultrafast-with-openai)
- License: https://creativecommons.org/licenses/by-nc/4.0/

---

![一块发光的晶圆级处理器向一系列较慢的机械闸门发送明亮的数据流](https://cdn.markhuang.ai/news/gpt-5-6-sol-750-tps-bottleneck-moves/hero.webp)

*当模型输出几乎瞬间送达，模型周围那些瓶颈也就浮出水面了。*

2026 年 8 月 13 日，[Cerebras 推出了 GPT-5.6 Sol Ultrafast](https://www.cerebras.ai/blog/accelerating-gpt-5-6-sol-ultrafast-with-openai)，这是一个限量预览的 OpenAI API 服务层级，每秒最多可生成 750 个输出 token。[OpenAI 表示](https://openai.com/index/previewing-ultrafast/)，这比标准处理快了最多 14 倍。目前只有部分客户能用，后续会随容量增长逐步开放。

看着文字以这种速度出现，大概能让你兴奋五分钟。我更关心接下来什么会变慢。一旦模型能在几秒内完成长篇回答，网络调用、工具执行、测试、审批和人工审核就成了计时器上的主角。Ultrafast 或许能改变哪些智能体工作流变得可行——但前提是你真的需要立刻拿到模型结果才能走下一步。

速度这东西，看着爽容易，算账就难了——生产系统正在出故障的时候，我愿意花钱把事故响应时间缩短；但一个明天才进审核队列的后台重构，完全可以再等等。

## 基准测试很快，但它仍是厂商自己的基准

Cerebras 在 Humanity's Last Exam 的全部 2500 道题目上跑了测试，Sol Ultrafast 耗时 11 小时 11 分钟。对比之下，Claude Fable 5 花了 78 小时 27 分钟。Cerebras 说两者准确率相当，但端到端速度快了将近七倍。在 GDP-Val 上，相比标准版 Sol，端到端速度提升了 5.6 倍。

这些数字有用，是因为它们覆盖的是完整工作负载，而不是几秒钟的输出峰值。但它们终究是 Cerebras 自己跑的评估。测试分在七月不同日期进行，相关的推理参数也披露了，这多少有帮助——不过工作负载怎么配、并发多少、测试框架怎么跑、服务端当时什么状态，都会影响最终耗时。原始的[Humanity's Last Exam 论文](https://doi.org/10.1038/s41586-025-09962-4)定义的是一个 2500 道题的专家级基准，考的是高难度封闭式学术题，不是生产环境里智能体调数据库、等测试套件那种乱糟糟的延迟。

“每秒最多 750 个输出 token”这句话得连着上下文看。输出速度衡量的是请求到达模型、开始处理之后的 token 生成速率。它不保证每个 prompt 都能立即开始，也不意味着智能体循环里的每个工具都能快 14 倍。OpenAI 自己的[推理工程说明](https://openai.com/index/gpt-5-6-frontier-intelligence-efficiency/)指出，一次 Codex 交互可能涉及 30 次模型请求外加工具调用。在重复步骤中节省一秒，积少成多；但步骤之外的每一秒也同样重要。

## Cerebras 攻克了内存移动难题

Cerebras 把速度归功于它的晶圆级引擎（Wafer-Scale Engine）。解释很具体：大模型推理需要反复在计算单元和片外内存之间搬运权重，而它的晶圆尺寸处理器在每个芯片上集成了 44GB SRAM。Cerebras 说权重可以留在片上，token 则通过跨晶圆流水线的方式穿过模型各层。

比起 token 数奖杯，我更感兴趣的是这种架构押注。OpenAI 现在把同一个前沿模型接上了截然不同的推理路径，推理硬件本身变成了产品选项。这也和 OpenAI 自研推理处理器的工作互为补充——我在[Jalapeño 发布公告](https://markhuang.ai/news/openai-jalapeno-inference-bet)里写过。OpenAI 一边在内部堆栈上做垂直整合，一边把晶圆级合作伙伴拉进了 API。

## 更快的模型改变了产品的形态

OpenAI 指出，事故响应、实时研究、语音支持、电商和金融分析是早期目标场景。这些例子有个共同点：有用的答案保质期很短。故障正在发生时送达的诊断，能立刻影响下一步排查；而一个暂停一分钟的语音助手，无论最终答案多好，都已经失败了。

750 token/秒的速度下，一个团队可以保持一条思路不断，看完结果马上决定下一个实验。OpenAI 说他们的研究人员正在测试：以前要跑一整晚的任务，能不能变成工作日里迭代好几轮。听起来靠谱，不过预览阶段光靠发布时的几句证言还不够，得有更多客户实际数据。

> **Info:**
>
> 我会把 Ultrafast 留给那些“答案快一步，下一步就不一样”的场景：事故处理、实时客户交互、交互式实验，或者有人等着审补丁提案。批量任务得拿实测的总耗时节省来证明多花的钱值。

## 速度无法修正判断力

更快的智能体也可能让错误的循环跑得更快。一位独立开发者的[Sol 实践报告](https://awaited.dev/experiments/gpt-5-6-sol-overengineering/)称赞了它发现风险的能力，但也描述了自己不得不回滚过度设计的修复方案。这是一位从业者的报告，并非对照研究。但实际担忧很简单：生成速度决定不了一项改动该不该做、范围对不对、上线安不安全。

OpenAI 在其事故响应描述中划定了同样的边界。工程师仍需对判断和部署负责。跟模型的速度一比，测试、策略检查和人工审批都显得慢得刺眼——但我还是会把它们留在流程里。再短的反馈循环也需要刹车。

## 缺失的数字是价格

两篇发布文章都未公布 Ultrafast 的定价。[OpenAI 当前的 API 页面](https://developers.openai.com/api/docs/models/gpt-5-6-sol)列出标准版 Sol 的价格为每百万输入 token 5 美元，每百万输出 token 30 美元，但这不等于预览版的价格。容量也是未知数——访问受限，得等 Cerebras 和 OpenAI 真正扩容才能放开。

把生产负载迁过去之前，我会拿同一批 trace 对比总任务时间、总成本、首 token 延迟、工具等待、重试率和人工审核负担。每秒 token 数该看，但不该只看它。

Ultrafast 把瓶颈挪了个位置。对交互式场景来说，这可能就够了。但对其他情况，我会先量一遍整个循环，看看等模型到底是不是那个最贵的环节。