Rosa Del Mar

Daily Brief

Issue 85 2026-03-26

Performance-Positioning-And-Current-Product-Limits

Issue 85 Edition 2026-03-26 8 min read
General
Sources: 1 • Confidence: Medium • Updated: 2026-03-27 10:09

Key takeaways

  • Mercury 2 does not match the highest-quality frontier models when maximum intelligence is the primary requirement.
  • Diffusion language models can be cheaper to serve than autoregressive LLMs because they can deliver more tokens per GPU at inference time.
  • Diffusion models generate by starting from noise and iteratively denoising using a stable training objective that learns to remove noise from corrupted samples.
  • Inception designed its diffusion language models to be backwards compatible so customers can quickly swap them in place of existing LLMs.
  • Inception reports its diffusion model ranks at the top of Copilot Arena evaluations for code completion quality and is embedded in multiple IDE products.

Sections

Performance-Positioning-And-Current-Product-Limits

  • Mercury 2 does not match the highest-quality frontier models when maximum intelligence is the primary requirement.
  • Inception's diffusion LLMs use a transformer backbone, so context-length scaling limitations are primarily due to attention architecture rather than the diffusion objective.
  • Mercury 2 is described as currently limited to a 128k context window and lacks multimodal support.
  • Mercury 2 is claimed to match speed-optimized frontier-model quality while being about 5–10x faster.
  • Artificial Analysis evaluated Mercury 2 as comparable in quality to speed-optimized frontier models while being roughly 5–10x faster depending on the comparison.

Inference-Economics-And-Parallel-Generation

  • Diffusion language models can be cheaper to serve than autoregressive LLMs because they can deliver more tokens per GPU at inference time.
  • A diffusion language model can start from an all-masked sequence and iteratively fill tokens out of order while emitting multiple tokens per step, reducing the number of forward passes versus left-to-right generation.
  • Increasing the number of denoising iterations can trade more inference compute for higher answer quality via in-place error correction rather than longer visible reasoning traces.
  • Market focus has shifted from training-time scaling laws to inference-time scaling due to post-training/test-time compute gains and the production economics of price per token.

Discrete-Diffusion-Core-Mechanism-And-Constraints

  • Diffusion models generate by starting from noise and iteratively denoising using a stable training objective that learns to remove noise from corrupted samples.
  • Applying diffusion to text is harder than images because text tokens are discrete and lack a natural continuous geometry for defining small perturbations and denoising.
  • Embedding-space diffusion approaches for language have struggled because outputs must be decoded back to discrete tokens and small latent errors may not map cleanly to valid words.
  • A practical discrete-noise process for diffusion language modeling is token masking, training the model to fill missing tokens using both left and right context.

Productization-Requires-New-Serving-Infrastructure

  • Inception designed its diffusion language models to be backwards compatible so customers can quickly swap them in place of existing LLMs.
  • Existing serving engines optimized for autoregressive LLMs cannot directly serve diffusion language models, so Inception built its own serving engine.
  • Inception's Mercury API is described as OpenAI-compatible and includes an effort parameter that controls compute versus quality.
  • Inception claims it has an internal solution for variable-length outputs in diffusion language models.

Near-Term-Use-Cases-Editing-And-Interactive-Agents

  • Inception reports its diffusion model ranks at the top of Copilot Arena evaluations for code completion quality and is embedded in multiple IDE products.
  • Ermon reports strong current usage of diffusion LLMs in latency-sensitive agentic settings, especially voice agents and fast human-in-the-loop agent loops where speed compounds across iterations.
  • Diffusion language models appear to perform especially well on editing-style tasks such as IDE autocomplete where both left and right context are valuable.
  • Ermon says Mercury is not a good fit for extremely long-running autonomous agent tasks but is well-suited for fast interactive human-in-the-loop workflows.

Watchlist

  • Diffusion language model inference and sampling algorithms for discrete diffusion are characterized as a relatively immature area with open questions about noise processes and training recipes.
  • Ermon claims Google announced Gemini Diffusion with numbers comparable to Mercury 1 but it is not in production or available to customers, possibly due to serving efficiency and internal switching costs.
  • Ermon describes growing diffusion-language research activity including efforts linked to Alibaba collaborations and ByteDance Seed, with cross-pollination from image/video diffusion techniques like distillation and inference acceleration.

Unknowns

  • What are the measured tokens/sec/GPU, tail latency under load, and $/1M tokens for diffusion versus autoregressive models at matched quality across representative workloads?
  • How does output quality scale with the effort parameter and denoising iteration count, and what is the latency-quality curve in practice?
  • What specific method enables variable-length generation in the described diffusion LM, and what are its failure modes (truncation, repetition, length bias)?
  • How competitive is Mercury 2 (and successors) on standardized reasoning, coding, instruction-following, and tool-use benchmarks when evaluated independently with disclosed settings?
  • What are the practical limits and roadmap constraints for extending context beyond 128k and adding multimodality within this diffusion+transformer approach?

Investor overlay

Read-throughs

  • If diffusion language models deliver materially better throughput per GPU at comparable quality, they could pressure inference cost structures and pricing for code completion and other high volume workloads, shifting value toward providers with efficient serving stacks and swap in compatible APIs.
  • If quality latency tradeoffs via denoising iterations work reliably, diffusion could enable new product tiers where customers pay for faster acceptable answers or slower higher quality, influencing monetization in IDE copilots and interactive agent loops.
  • If discrete diffusion sampling remains immature and requires new serving infrastructure, adoption may concentrate in vendors that can ship specialized engines and integrations, while incumbents face switching costs that slow competitive responses.

What would confirm

  • Independent benchmarks reporting tokens per second per GPU, tail latency under load, and dollars per 1M tokens for diffusion versus autoregressive at matched quality across representative code and chat workloads.
  • Clear latency quality curves showing how output quality scales with effort or iteration count, including stability across prompts and low variance under production traffic.
  • Evidence of broad productization such as more IDE embeddings, OpenAI compatible swap in deployments, and disclosed context scaling progress beyond 128k or credible roadmap execution.

What would kill

  • Matched quality evaluations show diffusion fails to beat autoregressive on cost or tail latency, or requires so many iterations that latency advantage disappears in real serving conditions.
  • Variable length generation exhibits frequent truncation, repetition, or strong length bias, limiting reliability for coding and agent loops and undermining swap in compatibility claims.
  • Serving stack complexity and infrastructure rewrites block deployments, with customers reverting to autoregressive models or diffusion remaining limited to narrow demos and non production pilots.

Sources