Inception Labs releases diffusion LLM Mercury 3, up to 8x faster than GPT-6 Luna

Is GPT-6 Luna about to have its lunch stolen by diffusion LLMs?

The newly released Mercury 3 model has been scaled up more than 40 times, yet its generation speed remains astonishingly fast, and its price per million output tokens is as low as $0.35. The diffusion model that once focused on speed is now directly challenging mainstream large models.

On October 19, Inception Labs, co-founded by Stanford University professor Stefano Ermon, delivered an impressive report card: Mercury 3 outperforms GPT-6 Luna and Claude Haiku 5.5 on multiple officially published benchmarks, with an output speed of 1,068 tokens per second, up to about 8 times faster than GPT-6 Luna.

In fact, the first-generation Mercury had already achieved generation speeds on the order of a thousand tokens per second. What is truly noteworthy this time is that after the model was scaled up more than 40 times and its capabilities greatly improved, Mercury 3 still maintains this speed.

What diffusion LLMs need to prove has shifted from "I can run fast" to "I can still run fast after I get bigger and smarter."

Diffusion LLMs begin to compete with GPT and Claude on capability

First, let's look at the report card Inception provided.

In the official same-tier comparison, Mercury 3 scored 89.23 on GPQA Diamond, higher than GPT-6 Luna's 86.36 and Claude Haiku 5.5's 84.51. This test examines graduate-level specialized scientific knowledge and reasoning ability. Switching to tasks closer to real-world development, the gap becomes even more striking: on SWE-Bench Atlas, Mercury 3 scored 51.08, compared with 33.33 and 32.26 for the two models. On the instruction-following test IFBench, Mercury 3 also scored 76.84.

In other words, Inception is not pitting a model that can only quickly output simple answers against mainstream LLMs in a speed contest. It is demonstrating that the diffusion approach can also handle knowledge Q&A, complex instructions, and real software engineering tasks.

Now for speed: Mercury 3 achieves an output throughput of 1,068 tokens/s on NVIDIA GPUs; Inception gives the corresponding speeds of GPT-6 Luna and Haiku 5.5 as approximately 130 and 240 tokens per second, respectively.

Beyond capability and speed, there are two more sets of numbers worth noting. Mercury 3's context window has been expanded to 1 million tokens, up from 260,000 in the previous generation Mercury 2.5; during the launch period, it charges $0.10 per million input tokens and $0.35 per million output tokens, with standard pricing at $0.20 and $0.70, respectively.

With parameter count surging more than 40 times, how do diffusion LLMs preserve their speed advantage?

To understand this, we first need to look at how the large models we are familiar with write a sentence.

Mainstream autoregressive language models such as GPT and Claude typically predict the next token one at a time in left-to-right order. Only after writing the preceding content can they continue predicting what comes next. Even though GPUs excel at parallel computing, this step-by-step generation chain cannot simply disappear. Diffusion language models adopt a different generation approach. They predict content at multiple positions simultaneously, then continuously adjust through multiple rounds of iteration to ultimately generate complete, coherent text.

You can think of it as two ways of writing: one is to write word by word while thinking, and the other is to first lay out a whole draft, then revise multiple places at once. The latter also requires repeated refinement, but each round can advance multiple positions simultaneously. This parallel processing capability is the key to the high-speed generation of diffusion language models: one forward computation can update a batch of tokens, reducing the serial steps needed to generate an entire passage. Therefore, even if multiple rounds of iteration are required, the overall generation speed can still potentially exceed token-by-token prediction.

Of course, moving image diffusion to text is not as simple as it sounds. Noise in images can gradually become clear pixels, but language consists of discrete tokens, and the model must decide which positions to determine first and which still need further modification. The more parallelism in one pass, the faster generation may be; but if there are not enough revision rounds, sentences, code, and reasoning steps can easily conflict with one another. What diffusion LLMs truly need to solve is finding the balance between the degree of parallelism and generation quality.

As early as the first-generation Mercury technical report, the team introduced the approach of using a Transformer to predict in parallel at multiple text positions and complete generation from coarse to fine. Mercury Coder Mini, released in 2025, was measured by third parties at 1,109 tokens/s; but at that stage, what people remembered most about diffusion models was still speed, and complex task capability was not yet its strongest calling card.

After that, the Mercury series continued to iterate, from general chat to reasoning models, and then to Mercury 2.5. Inception previously described a series of improvement directions, including scaling up training, optimizing the denoising network, training objectives, inference algorithms, as well as the underlying operators and serving engine.

By Mercury 3, the changes officially given were very direct: the total parameter count expanded more than 40 times relative to Mercury 1, comprehensive capability on standard benchmarks improved about 3 times relative to Mercury 1 mini, while generation speed still remained at the level of a thousand tokens per second.

This also gave more direct validation to the scaling potential of diffusion LLMs: as model scale expands and complex task capability keeps improving, the speed advantage brought by parallel generation can still be retained.

In the Agent era, diffusion LLMs have found a new role

Faster answers are certainly welcome. But in AI Agents, fast means something else: whoever finishes the task first is the one that is truly fast.

Suppose you ask a browser Agent to look up quotes from several suppliers and organize them into a table. It needs to open web pages, find information, judge whether a page is useful, go to the next layer of links, extract data, and may also find that the materials are incomplete and then go back to search again. Throughout the process, after every observation of the page and decision on an action, it has to wait for the model to give the next judgment. When a dozen or dozens of calls stack up, the latency of each step becomes the waiting time the user actually feels.

Inception's partnership cases this time further demonstrate Mercury 3's actual performance in multi-step web operations and real-time interactive scenarios.

Browser Agent company TinyFish integrated Mercury 3 into its production-grade web agent system and tested it against frontier models on 50 Mind2Web navigation tasks on real websites. Co-founder Shuhao Zhang revealed that Mercury 3 successfully completed 25 of those tasks, reaching a 50% completion rate, clearly higher than GPT-6.1 Sol. Moreover, the number of tokens consumed and execution steps used by Mercury 3 were comparable to the comparison models, while the cost per token was much lower.

For browser Agents that need to repeatedly observe web pages and decide the next operation, faster model responses mean tasks can be advanced in a shorter time, and lower call costs also make high-frequency, multi-round operations more economical.

Another case comes from real-time search company Octen AI. It provides search capabilities for scenarios such as smart glasses. In its Sense API tests, the search step took only about 80 milliseconds, and what actually slowed down the answer was model generation. After switching to Mercury 3, the median model generation time dropped to 0.9 seconds, and the median end-to-end response was 2.2 seconds, achieving the best balance of speed and quality among the tested high-speed models. Asking a question to smart glasses and waiting five seconds before hearing an answer is a completely different experience from getting a response in about two seconds. The former is more like "submitting a request," while the latter only begins to approach natural conversation.

At this point, a comment from FlashAttention author Tri Dao is quite interesting.

When reposting Mercury 3, he wrote that he had always hoped to combine a sufficiently intelligent "coordinator/architect" model with an extremely fast "executor" model; diffusion LLMs might be exactly suited to serve as the latter.

This sentence offers another angle for looking at competition among large models.

In the past, when discussing a new model, people always habitually asked whether it could defeat the smartest model and obtain a higher benchmark score. But an Agent that actually does work does not necessarily need every step to be personally completed by the most expensive and strongest model.

The model responsible for understanding goals, breaking down difficult problems, and making plans can put capability first; while the model that retrieves information, checks pages, extracts fields, and repeatedly executes operations cares more about response speed, reliability, and cost. The former is like a project leader, and the latter is like an execution team on standby at all times.

This also changes how "fast" is measured. In chat, the difference between one second and three seconds may only be whether it feels smooth; if an Agent needs to make twenty or thirty consecutive tool calls, the time saved at each step may ultimately become the time needed to complete the entire task.

In such a division of labor, Mercury 3's positioning also gradually becomes clear: to become the role in an Agent system that is both sufficiently intelligent and able to respond quickly and continuously execute tasks.

Reference links:

This article comes from the WeChat public account "Machine Heart" (ID: almosthuman2014), author: Neo, published by 36Kr with authorization.