DevNews

OpenAI Ultrafast: 14× tokens is not 14× every task

On this page
  1. What the preview promises
  2. Read the benchmark's comparator
  3. A complete task has a smaller speedup

Ultrafast changes the speed of a model-serving path. A finished application still waits on retrieval, tools and other services, so its total acceleration depends on how much of the delay inference actually owns.

Fictional latency example: 14 seconds accelerated plus 10 seconds unchanged totals 24. Speeding the first part by 14× yields 1 + 10 = 11 seconds, or 2.18× overall. Bars share a scale; not a measurement of OpenAI or Cerebras.
Fictional latency example: 14 seconds accelerated plus 10 seconds unchanged totals 24. Speeding the first part by 14× yields 1 + 10 = 11 seconds, or 2.18× overall. Bars share a scale; not a measurement of OpenAI or Cerebras. Chart : PeopleAreGeek. Data source.
View full-size image

What the preview promises

OpenAI's August 13 announcement describes GPT-5.6 Sol on a new service tier, with up to 750 output tokens per second and up to 14× Standard processing speed. It remains described there as a limited API preview for selected customers, expanding with capacity. These are announced upper figures, not a guaranteed request latency or a public price quote.

The release concerns GPT-5.6 Sol. It does not establish the same performance for every later OpenAI model, nor does an API tier imply access in every ChatGPT plan.

Read the benchmark's comparator

Cerebras' technical account describes layers pipelined across wafers with on-chip SRAM. The earlier text could suggest the whole model fits in one 44 GB chip; that is not what the described multi-wafer arrangement establishes.

Cerebras reports a 5.6× GDP-Val speedup comparing Sol with Sol Ultrafast. Its HLE timing compares Sol Ultrafast with Claude Fable 5, using different agents. Those are different comparisons and vendor-run evaluations. The HLE result must not be relabeled as a Standard-versus-Ultrafast test.

A complete task has a smaller speedup

Our fictional workflow spends 14 seconds in the component being accelerated and ten seconds elsewhere. Its initial duration is 24 seconds. If that component becomes fourteen times faster, it takes one second; the complete task now takes 11 seconds, a speedup of about 2.18×.

The cover uses those explicit assumptions. They are not measurements of Sol. Even infinitely fast processing of that component leaves the other ten seconds, limiting this example to 2.4× overall. This is why output throughput cannot, alone, guarantee a voice response within a few hundred milliseconds.

Measure time to first output, generation time, tool duration and full task completion separately. For a sequence of calls, record dependencies and retries rather than multiplying one impressive throughput figure across the whole application. Keep equivalent quality criteria: a fast incorrect completion is not a completed business task. Before making the preview a dependency, verify the supported request path, access terms and fallback behavior actually available to your account.

Separate output throughput from end-to-end latency and different benchmark baselines; correct across-wafer architecture and retain limited-preview status.