Mercury 3: difusão supera GPT-6 Luna em velocidade?

Mercury 3 promete acabar com a espera dos LLMs

Mercury 3 é o tipo de lançamento que incomoda quem opera IA em produção. A startup Inception diz que seu novo modelo de linguagem por difusão não apenas acompanha GPT-6 Luna e Claude Haiku 5.5, como vence em oito de doze benchmarks e roda de quatro a oito vezes mais rápido. Para quem vive de agente travando, de suporte que demora cinco segundos para responder e de conta de inferência que estoura no fim do mês, a promessa soa boa demais. E é exatamente por isso que vale destrinchar com calma.

A tese central é simples e provocadora. E se o futuro dos LLMs não for prever a próxima palavra? Modelos autoregressivos como GPT e Claude escrevem um token por vez, cada palavra esperando a anterior. Funciona bem para qualidade, mas cria um gargalo sequencial impossível de paralelizar por completo. Em agentes que fazem dezenas de chamadas encadeadas, essa latência acumula e mata a experiência. A Inception aposta que difusão resolve isso ao gerar a resposta inteira de uma vez e refinar por etapas.

O fato sem hype

O fato é este. A Inception lançou o Mercury 3 como o maior e mais capaz modelo de difusão para texto até agora. Segundo a empresa, ele gera 1.068 tokens por segundo em GPUs da Nvidia, contra cerca de 240 do Claude Haiku 5.5 e 130 do GPT-6 Luna nas comparações internas. Ele suporta até 1 milhão de tokens de contexto e usa API compatível com OpenAI, o que facilita o teste por quem já tem pipeline pronto.

Nos números divulgados pela própria Inception, o Mercury 3 vence oito de doze testes com os três modelos em configuração média. A vantagem mais clara aparece em seguir instruções. No IFBench ele marca 76.84 pontos, cerca de 15 pontos acima do GPT-6 Luna. Em código autônomo no SWE-Bench Atlas, faz 51.08 contra 33.33 e 32.26 dos rivais. Por outro lado, perde no teste mais longo de código DeepSWE para o Claude Haiku 5.5, perde em recuperação de informação em textos longos e fica atrás do GPT-6 Luna em dois testes do Artificial Analysis. No resumo curto, a própria empresa recua um pouco e fala em qualidade equivalente ou melhor, não em domínio absoluto.

Tem ainda o argumento de escala. A Inception afirma que o Mercury 3 tem mais de 40 vezes os parâmetros do Mercury 1 e roda na mesma velocidade, com desempenho triplicado desde o pequeno Mercury 1 mini. A contagem exata de parâmetros não foi revelada, e ainda não existem testes independentes públicos para confirmar throughput e qualidade fora do ambiente controlado da empresa.

Como funciona na visão de quem opera

Na prática de operador, a diferença é arquitetural. Um modelo autoregressivo é como uma linha de montagem serial. Você só coloca a peça seguinte depois que a anterior foi fixada, com cache KV crescendo a cada token. Isso dá boa coerência, mas latência cresce de forma quase linear e o paralelismo da GPU fica subutilizado na decodificação.

Difusão para texto inverte a lógica. Pense em como funciona geração de imagem. O modelo começa com um rascunho ruidoso da resposta completa, com vários trechos mascarados ou incertos, e depois refina tudo em conjunto ao longo de algumas passagens. Em vez de 200 passos sequenciais para 200 tokens, ele faz, por exemplo, 8 a 16 passos de refinamento global onde dezenas de posições são atualizadas em paralelo. O relatório técnico do DiffusionGemma do Google explica bem essa base, e a ideia da Inception segue na mesma linha.

O que isso implica para API, custo e latência? Primeiro, throughput alto não significa necessariamente time to first token baixo em todos os casos. Para respostas curtas, o overhead das etapas de difusão pode anular parte do ganho. Para respostas médias e longas, típicas de agentes e RAG, o ganho paralelo compensa e muito. Segundo, 1.068 tokens por segundo provavelmente foi medido com batching otimizado e saída longa em hardware topo de linha da Nvidia, então não espere o mesmo número com batch 1 e prompt de 1 milhão de tokens. Terceiro, preço de lançamento é de 0.20 dólar por milhão de tokens de entrada e 0.70 por milhão de saída, com 50% de desconto inicial por tempo indeterminado. É agressivo para a categoria rápida e sugere que a Inception quer comprar adoção antes de provar consistência.

O que isso muda na prática

Quem ganha primeiro são os casos onde pequenos atrasos se somam. A Inception mira agentes autônomos, busca, suporte ao cliente e tutoria. Os parceiros de acesso antecipado reforçam essa tese com números de campo. A Octen AI, que monta busca para óculos inteligentes, diz que a busca em si levava só 80 milissegundos e o gargalo era o LLM. Com o Mercury 3, a mediana de resposta caiu para 0.9 segundo e o processo completo para 2.2 segundos. Em óculos, como diz o fundador Kuan Zou, uma resposta que leva cinco segundos parece quebrada.

Outros relatos seguem o mesmo padrão. A General Learning afirma entregar dicas e correções para estudantes em cerca de um segundo. A Lorikeet, de atendimento ao cliente, fala em respostas mais rápidas com qualidade melhor. A TinyFish AI testou 50 tarefas de navegação em sites reais e diz que o Mercury 3 resolveu 25, superando o GPT-6.1-Sol, embora sem divulgar o número do modelo da OpenAI. São anedotas de parceiros, não benchmarks independentes, mas apontam para onde a arquitetura brilha. Interação em tempo real, não raciocínio longo e solitário.

Se você opera hoje, a ação prática é direta. Pegue um fluxo seu que faz de 5 a 15 chamadas sequenciais por tarefa, como um agente de suporte ou de pesquisa web, e replique esse fluxo no endpoint compatível com OpenAI do Mercury 3 sem mudar prompts. Meça p50 e p95 fim a fim, taxa de conclusão e custo por tarefa resolvida, não apenas tokens por segundo. Minha aposta é que você vai ver a maior diferença não no benchmark acadêmico, mas no tempo total da tarefa. Se o p95 cair de 18 para 6 segundos com qualidade aceitável, isso muda UX e permite loops de agente que antes eram inviáveis por custo de espera.

• Teste em tarefa completa com multi-step, não em prompt isolado.
• Compare custo por tarefa resolvida com preço cheio, sem desconto de lançamento.
• Valide instruções complexas e long context no seu domínio, onde ele ainda perde.

A tensão que ninguém quer admitir

Aqui entra a dúvida real. Difusão escala tão bem quanto autoregressão quando o assunto é raciocínio difícil? O histórico dos LLMs mostra que escalar parâmetros e dados melhora autoregressivos de forma previsível. A Inception diz ver o mesmo padrão em difusão, com salto de 40 vezes nos parâmetros mantendo velocidade. Parece ótimo no papel, mas a tabela deles mesmos mostra brechas em código longo e em busca de informação em contexto extenso. São justamente as tarefas onde coerência global e dependência de longa distância importam, e onde refinamento paralelo pode borrar detalhes.

Tem também a questão do controle. Modelos autoregressivos têm ecossistema maduro de structured output, tool calling, streaming token a token e observabilidade. Em difusão, o streaming é diferente porque a resposta nasce inteira e vai ficando nítida. Como fica o cancelamento precoce, o parsing parcial de JSON, o uso de ferramentas no meio do raciocínio? Dá para adaptar, mas é atrito real para quem já tem stack pronta. E preço promocional pela metade é ótimo para testar, porém ninguém constrói roadmap em cima de desconto sem data para acabar. Se o preço dobrar amanhã, a conta por tarefa ainda fecha?

Conclusão prática para quem constrói

Mercury 3 não precisa vencer tudo para ser relevante. Se entregar 800 a 1.000 tokens por segundo com qualidade próxima de Haiku e Luna em instruções e agentes, ele abre uma faixa nova de produto em tempo real que hoje vive no limite entre usável e irritante. A pergunta que fica é simples. No seu caso de uso, velocidade é luxo ou é o que destrava o produto?