Mercury 3 makes a commercial case for diffusion language models at 1,068 tokens per second

Inception says Mercury 3 generates 1,068 tokens per second on NVIDIA GPUs, bringing a different text-generation architecture into competition for latency-sensitive applications. The diffusion model refines multiple token positions together rather than following the usual one-token-at-a-time process. Its commercial pitch combines that speed with a one-million-token context window and comparatively inexpensive token rates.[1]

To understand why the claim is interesting, it helps to consider how most chat models write. An autoregressive model predicts the next token after the preceding tokens, then repeats. Each later step depends on the text already produced. That arrangement supports strong reasoning, but a long response accumulates sequential delay. Diffusion language models instead work by producing and refining groups of token candidates through iterative denoising. They can create or revise multiple positions together rather than accepting the familiar one-token-at-a-time progression.[1]

Scaling without surrendering the speed advantage

Mercury 3 is, according to Inception, more than forty times larger than its original Mercury 1 while retaining a similarly high output rate. The company says the context window has increased from 260,000 tokens in Mercury 2.5 to one million. This matters because the history of text diffusion has involved a question about scaling: could its parallel generation advantages survive as the model became more capable, or would the computational work needed for quality erase them?[1]

Output throughput is only one part of latency. A service must also process the prompt, wait for available capacity and communicate with other tools. Long prompts and concurrent requests can change the balance. Mercury’s million-token limit describes how much context it accepts, while retrieval accuracy and response time at that limit require separate evaluation.[1]

The company describes early commercial tests in browser navigation, real-time search, tutoring and support. One partner reported completing half of 50 Mind2Web-style web navigation tasks under a defined agent setup. Another gave a median generation time around 0.9 seconds in its application and a median end-to-end time around 2.2 seconds. These are encouraging operational anecdotes; they were reported by partners whose systems used the model, rather than by an independently organised, blinded cross-provider laboratory.[1]

The pricing comparison has two answers

Inception lists Mercury 3 at $0.20 per million input tokens and $0.70 per million output tokens, with a launch promotion of $0.10 and $0.35 respectively. That distinction is crucial for any product builder pricing a service. Comparing a temporary discounted Mercury price against rivals' ordinary rates can make the apparent cost advantage look more durable than it is. For a service handling many short requests, network overhead, queueing and integration costs may dominate token pricing; for long reports or agents making many calls, token rates may become central.[1]

The comparative benchmark figures in the launch post are Inception’s own report. They help identify workloads worth testing, but differences in model settings, hardware and task mix limit a blanket ranking. For an application already using another model, a representative set of real requests provides a more useful comparison than one throughput number.[1]

Which applications really need speed?

A conversational tutor waiting for the next turn, a voice system struggling to avoid awkward pauses, or a browser agent that pauses between each page interaction could benefit from lower latency. The same benefit is less obvious for a nightly report that can run for minutes without disrupting anyone. Faster token streams also provide more opportunities to recover from a poor first plan, but that advantage only appears if the application can detect the error and use its time intelligently.[1]

Mercury 3 gives developers a concrete reason to test text diffusion in applications where pauses accumulate: voice exchanges, tutoring and agents making repeated decisions. The useful comparison is the complete task—how long it takes, whether it succeeds and what it costs. A fast generator matters most when those gains survive the rest of the application.[1]

Report an error or suggest a correction