LLM de difusão: Mercury 2.5 e o roteamento de modelos

Em 2026-09-08 a Inception Labs lançou o Mercury 2.5, o maior LLM de difusão já treinado, com 40% mais inteligência que o Mercury 2, 1.107 tokens por segundo em GPUs NVIDIA e preço de US$0,20 por milhão de tokens de entrada e US$0,75 por milhão de saída, conforme o anúncio oficial: Introducing Mercury 2.5. A data segue o rodapé do anúncio; a página foi consultada em 2026-09-15. A implicação que importa: uma arquitetura de difusão que vence em tokens por segundo por dólar muda qual modelo cada tipo de tráfego deve receber.

O que a Inception Labs anunciou no Mercury 2.5

O Mercury 2.5 é um modelo de difusão, não um transformer autoregressivo, e é a maior variante já treinada nessa classe. Em vez de emitir um token por vez, da esquerda para a direita, um LLM de difusão gera um bloco inteiro de tokens mascarados em paralelo e refina todas as posições ao longo de um número fixo de passos de denoising. O ganho de throughput e latência vem dessa geração paralela por passo, não de um processo iterativo genérico. A Inception Labs posiciona o resultado como comparável, em inteligência, a modelos de fronteira otimizados para custo: GPT-5.6 Luna (Low), Gemini 3.5 Flash-Lite e Claude Haiku 4.5. O throughput é o que separa a linha: 1.107 tokens por segundo em GPUs NVIDIA.

A arquitetura é o ponto de partida. Difusão e transformer autoregressivo produzem texto por caminhos diferentes, e é daí que vem a diferença de velocidade. O número de 1.107 tokens por segundo é medido em GPUs NVIDIA, por requisição e em fluxo único. Vale qualificar: modelos autoregressivos servidos com batching contínuo e hardware acelerado, na classe de Cerebras e Groq, já alcançam quatro dígitos de tokens por segundo por requisição. A diferenciação do Mercury não é velocidade bruta isolada, é a economia de servir uma arquitetura de difusão. A janela de contexto chega a 260 mil tokens.

O preço de lançamento é US$0,20 por milhão de tokens de entrada e US$0,75 por milhão de saída. Durante a promoção de lançamento, a Inception Labs pratica US$0,04 e US$0,15. Dois produtos foram anunciados em prévia no mesmo dia: o Mercury Voice e o Mercury Router. O Router coloca um fornecedor de modelos dentro da camada que decide qual modelo atende cada chamada, algo que até aqui era território de gateways independentes ou de decisões tomadas pela própria aplicação.

As provas de cliente vieram junto. A Augment Code reportou redução de 82% na latência de compactação, de 150 segundos para 27, e corte de 90% no custo dessa etapa. A OpenCall levou o P99 de minutos para cerca de um segundo. São casos de um fornecedor divulgando casos de clientes, então vale ler como relato da fonte primária, não como auditoria independente.

Por que o custo por tarefa muda a decisão de rota

A métrica que decide orçamento em inferência não é preço por milhão de tokens, é custo por tarefa concluída. Se a arquitetura de difusão entrega respostas úteis com mais throughput por GPU, cada minuto de GPU produz mais trabalho, e a conta por requisição pode cair mesmo com preço nominal parecido com o de um concorrente. Só que custo por tarefa não é preço por token vezes velocidade: a inferência por difusão gasta GPU em passos iterativos de denoising, e o resultado depende de tamanho de batch, número de passos e eficiência de tokens, nada disso divulgado pela fonte. O número de 1.107 tokens por segundo é medido pelo fornecedor, em configuração de serving não especificada, então a conta real de custo por tarefa precisa ser medida na carga de quem compra.

Considere o caso da compactação. A Augment Code reportou que o mesmo passo caiu de 150 segundos para 27, com 90% menos custo. Um engenheiro que roda compactação dezenas de vezes por dia sente a diferença em minutos, não em fração de centavo.

Esse é o ponto.

O eixo da disputa saiu do preço por token e foi para tokens por segundo por dólar. Quem roteia só por custo de tabela está medindo a variável errada em cargas interativas.

Há um limite honesto nessa leitura. A empresa não publicou, no anúncio, uma comparação independente de qualidade tarefa a tarefa contra os modelos de fronteira que ela mesma nomeia. O que existe é a afirmação de paridade de inteligência e um punhado de casos de cliente. A Inception Labs é a fonte desses números, e a leitura correta é tratar a paridade como alegação de fornecedor até que comparativos de terceiros apareçam. Nada disso retira o valor do lançamento: o preço e a velocidade já mudam a aritmética mesmo com a paridade em aberto.

Onde um modelo speed-first entra na política de roteamento

Modelo rápido e barato não substitui a fronteira em tudo. Ele substitui a fronteira em tráfego de alto volume e baixa ambiguidade, onde a tarefa tem formato previsível e o custo do erro é baixo. É onde o volume come inflação de conta e onde a latência aparece para o usuário final.

Vale a contraposição honesta: uma faixa barata e rápida para produção não é novidade, e já existe nos modelos otimizados para custo que a própria Inception Labs nomeia. Quem roteia por custo e latência já manda tráfego para essa classe. O que o Mercury 2.5 traz de novo não é o conceito de tier não-fronteira em produção, é a arquitetura de difusão e o ponto de preço e velocidade onde ela chega.

A lista de candidatos é previsível: classificação, extração de campos, resumo de trecho, reescrita curta, preenchimento de template e triagem de primeira linha. É rotina.

O tráfego de raciocínio profundo segue na fronteira. Análise com múltiplos saltos, código com dependências longas, decisão regulatória, tudo que exige a última milha de qualidade justifica pagar mais por token e esperar mais por resposta. A fronteira de inteligência medida por índices independentes mostra onde ela está hoje, sem afirmar posição específica do Mercury 2.5 nesse índice, e a política de rota boa não escolhe um vencedor: ela escreve a regra de qual tráfego vai para qual classe.

O Mercury Router anunciado pela Inception Labs é o sinal de mercado aqui. Quando quem treina o modelo também lança a camada que decide qual modelo atende cada chamada, o roteamento deixa de ser detalhe de implementação e vira plano de controle. Muda também a relação de poder: o fornecedor passa a querer controlar a decisão de rota que antes ficava com o comprador.

• Alto volume, baixa ambiguidade, tolerância a erro: candidato natural ao modelo difusão, pela velocidade e pelo custo por tarefa.
• Raciocínio profundo, poucas chamadas, alto custo de erro: segue na fronteira, aceitando preço e latência maiores.
• Interativo com limite de tempo no P99: o modelo rápido é o que salva a experiência, e o número da OpenCall mostra o tamanho do ganho.

O que muda na prática

O eixo mudou. A tabela abaixo compara como a decisão de rota era tomada antes de a classe difusão entrar em produção e como ela fica depois, com a variável de custo por tarefa concluída na conta e o preço por token rebaixado a um dos fatores. As linhas de roteamento dinâmico e de fornecedor na camada de rota são tendência a observar, não capacidade em produção: o Mercury Router foi anunciado apenas em prévia.

A tabela resume o deslocamento. O preço por token continua existindo e continua importando, mas parou de ser o critério único. Quem compra inferência passa a precisar de três números por candidato: custo por milhão de tokens, tokens por segundo e latência de ponta a ponta no P99.

Como avaliar sem se enganar com o benchmark

O erro clássico é escolher pela tabela de preço e só descobrir a conta real quando ela aparece na fatura de GPU, no estouro do orçamento mensal ou no limite de tempo que o usuário tolera. O caminho correto é medir por tarefa, no seu próprio tráfego, com a taxa de acerto da sua aplicação.

1. Defina a tarefa e o critério de aceite antes de comparar modelos. "Respondeu" não é critério, "passou no teste de extração em 96% dos casos" é.
2. Meça custo por tarefa concluída, não preço por token. Divida o custo total pelo número de tarefas que passaram no critério. O custo de contexto como vetor de decisão entra nessa conta, não só o preço de tabela.
3. Meça latência de ponta a ponta, e olhe o P99, não a média. A média esconde exatamente a cauda que derruba a experiência interativa.
4. Rode o mesmo prompt em paralelo nos candidatos e compare os três números lado a lado. O ranking de modelos serve para escolher os finalistas, nunca para encerrar a decisão.
5. Reavalie a rota quando preço, velocidade ou um modelo novo mudam. Eles mudam toda semana.

A regra vale para quem roteia mais de algumas centenas de milhões de tokens por mês. Abaixo disso, o ganho de otimizar a rota costuma não pagar o trabalho de medir e manter a política. Acima, se paga no primeiro trimestre de uso.

FAQ

O Mercury 2.5 é um LLM de difusão, e isso muda o quê na prática? Difusão gera um bloco inteiro de tokens mascarados em paralelo e refina todas as posições em passos de denoising, em vez de emitir token a token da esquerda para a direita como o transformer autoregressivo. Na prática, o ganho aparece em throughput por requisição: 1.107 tokens por segundo, segundo a Inception Labs, o que reduz custo por tarefa e latência em cargas interativas de alto volume, com a ressalva de que a medição é do fornecedor em configuração não especificada.

O Mercury 2.5 substitui modelos de fronteira como GPT-5.6 Luna (Low) ou Claude Haiku 4.5? Não. Ele é comparável em inteligência a modelos otimizados para custo, segundo a própria Inception Labs, e entra como candidato para alto volume e baixa ambiguidade. Raciocínio profundo e decisões de alto custo de erro seguem na fronteira. A política de rota combina as duas classes.

Qual é o preço do Mercury 2.5 e o que ele muda no orçamento? US$0,20 por milhão de tokens de entrada e US$0,75 por milhão de saída, com promoção de lançamento em US$0,04 e US$0,15. O efeito no orçamento não vem só do preço, vem do custo por tarefa concluída. Um modelo com mais throughput por GPU pode custar menos por requisição mesmo com preço por token parecido, mas essa conta depende do seu volume, do batch e do número de passos de denoising, e só a medição na sua carga fecha o número.

O que é o Mercury Router e por que ele importa? É um roteador anunciado em prévia pela Inception Labs, junto com o Mercury Voice, e ainda sem data de disponibilidade geral. Ele importa porque coloca um fornecedor de modelos na camada que decide qual modelo atende cada chamada, encaminhando prompts para modelos abertos e fechados. Isso confirma o roteamento como plano de controle da stack de IA, e não como detalhe da aplicação.

Os números de Augment Code e OpenCall foram auditados? Não de forma independente. Os dois casos vêm do anúncio da Inception Labs. A redução de 82% na latência de compactação e o corte de 90% no custo são relatos de cliente publicados pela fonte primária. O P99 da OpenCall, de minutos para cerca de um segundo, segue a mesma origem.

Referências e Leitura Complementar

• Introducing Mercury 2.5, Inception Labs, fonte primária, publicada em 2026-09-08 conforme o rodapé do anúncio; página consultada em 2026-09-15.
• Seis laboratórios acima de 50 no Intelligence Index, onde fica a fronteira de inteligência e o que ela muda na rota (leitura de referência, não posição do Mercury 2.5).
• Qwen3.8-Max: custo de contexto e o que muda no roteamento, o custo de contexto como vetor de decisão de rota.
• Nexforce Router, a camada de roteamento multi-modelo com uma API.

O que fazer agora com a nova classe na rota

O prazo curto é claro: a Inception Labs prometeu o Mercury Voice e o Mercury Router como prévias, sem data de disponibilidade geral no anúncio, então o comprador que quer se preparar trabalha com o que já está datado. O Mercury 2.5, seu preço e sua velocidade já são decisão de arquitetura, não de espera.

A pergunta que fica para o próximo trimestre não é qual modelo é o melhor, e sim quem controla a decisão de qual modelo atende cada chamada. Um fornecedor de modelos lançando o próprio roteador responde essa pergunta de um lado. Do lado do comprador, a resposta é manter a camada de rota sob controle próprio, com critério explícito e observável.

O Nexforce Router existe para isso: mais de 300 modelos por trás de uma única API compatível com OpenAI, com roteamento por custo, performance, latência e contexto, failover automático entre provedores, budget por chave e observabilidade centralizada de cada chamada. Quando uma classe nova de arquitetura entra em produção, como os LLMs de difusão agora, a política de rota é o que decide quanto disso vira economia real e quanto vira complexidade sem dono.