The two architectures
Autoregressive is what almost everything uses - GPT, Claude, Gemini, Llama, Qwen. The model writes one token, appends it to the context, reads the whole thing back, then writes the next. Each token waits for the one before it. Output speed is bounded by that loop, not by how fast the chip is.
Diffusion starts from noise across the entire output and refines all of it at once, over a fixed number of passes. It is how image generators work. Because every position is updated in parallel, the sequential bottleneck disappears, and the generation time depends on the number of refinement passes rather than the length of the output.
That difference is why Inception Labs can report Mercury 3 at over 1,000 tokens per second with a 1 million token context window. The number is architecturally credible. It is not a hardware claim and it is not an optimisation claim.
What is actually missing
Quality. Inception has published a throughput figure and a context window. It has not published comparative benchmark results against frontier autoregressive models, and no third party has evaluated it.
That matters because diffusion language models have historically traded accuracy for speed. The technique is well established in research and has not yet displaced autoregressive models in production, which is itself information. Until there are numbers, 1,000 tokens per second is a throughput claim and nothing more. A model that is fast and wrong is not useful at any speed.
We are flagging this rather than reporting the speed figure as a capability result, because most coverage this week has not.
Where the architecture would matter
| Workload | Does speed change the product? |
|---|
| Live voice | Yes. Latency is the entire experience. A pause before a reply is the difference between a conversation and a transaction. |
| Agent loops | Yes. Dozens of sequential model calls, each waiting on the last. Per-call latency compounds across the whole run. |
| Code completion | Yes. A suggestion that arrives after you have typed the line is worthless regardless of quality. |
| Long-form writing | Rarely. Nobody abandons a draft because it took nine seconds instead of three. |
| Batch processing | No. Throughput is already solved by running more requests in parallel, and batch pricing is usually half. |
| Deep reasoning | No, and possibly the opposite. Extended thinking deliberately spends more time to get a better answer. |
The honest comparison today
- Known speed advantage - diffusion, by roughly an order of magnitude on reported figures.
- Known quality - autoregressive, because it is the only one with published, independently replicated results.
- Ecosystem - autoregressive, overwhelmingly. Tooling, evaluation harnesses, fine-tuning recipes and serving stacks all assume it.
- Context window - no advantage either way. Mercury 3's 1M matches Claude Opus 5.5's 1M and sits just under GPT-6 Astra's 1.05M.
- Cost - unknown. Inception has not published pricing alongside the throughput figure.
What to do
Do not migrate anything. There is no quality evidence to migrate on.
Do run your own evaluation if latency is genuinely your constraint - live voice, interactive agents, inline completion. Take fifty real prompts from your own workload, run them through Mercury 3 and your current model, and compare outputs side by side. You will learn more in an afternoon than from any benchmark table, and you will learn it on the distribution you actually serve.
Watch for the first independent evaluation. The moment a diffusion LLM posts a competitive score on a harness someone else runs, this stops being an architecture curiosity and becomes a genuine fork in how models are served. Until then it is a fast engine with no published lap time.
Verdict
The architecture is real and the speed claim follows from it. The capability question is open and nobody has answered it.
Treat Mercury 3 the way you would treat any model that published one impressive number and no others: interesting, testable on your own data, and not something to build on yet.