Mercury 3 entrega 1.000 tok/s e supera GPT-6 Luna

O gargalo nunca foi inteligência, foi espera

Se você já colocou um agente de browser em produção, conhece essa dor de perto: o modelo até raciocina bem, mas gera token por token e cada etapa soma segundos até o usuário abandonar a tarefa. O Mercury 3, novo diffusion LLM da Inception, ataca exatamente esse ponto com a promessa de 1.068 tokens por segundo, contexto de 1M de tokens e qualidade no nível de modelos rápidos de fronteira. Não se trata apenas de mais um modelo um pouco melhor no benchmark, e sim de uma tentativa de mudar a física da inferência para aplicações que vivem de latência. Quando a resposta demora cinco segundos em um óculos inteligente ou em um tutor por voz, a experiência quebra, mesmo que a resposta esteja correta.

Eu já testei agentes suficientes para desconfiar de número bonito em blog de lançamento. Mas o argumento aqui é operacional, não acadêmico. Velocidade vira margem para tentar de novo, ler mais documentos, corrigir uma navegação errada e ainda responder dentro da janela de atenção do usuário. A Inception diz que o Mercury 3 empata ou supera o GPT-6 Luna e o Claude Haiku 5.5 enquanto roda de 4 a 8 vezes mais rápido. Se isso se confirmar fora do ambiente controlado, a conversa deixa de ser sobre quem é mais inteligente no papel e passa a ser sobre quem entrega qualidade utilizável sem estourar timeout ou orçamento. É por isso que difusão merece atenção agora, mesmo para quem já está cansado de promessa de modelo revolucionário.

O fato: Mercury 3 chegou com números agressivos

O anúncio é direto. O Mercury 3 é apresentado como o LLM de difusão mais capaz lançado até hoje, com mais de 40 vezes o total de parâmetros do Mercury 1 e inteligência cerca de 3 vezes maior em benchmarks padrão desde a versão mini original. A empresa afirma que as leis de escala que funcionaram para modelos autoregressivos também valem para difusão, o que responde à principal dúvida da comunidade desde o Mercury 1: se essa arquitetura conseguiria competir em casos complexos ou ficaria restrita a demos rápidas. O salto de contexto também é relevante, de 260K no Mercury 2.5 para 1M de tokens agora, o que coloca o modelo na faixa necessária para agentes que precisam manter histórico longo, logs e múltiplas páginas abertas.

Nos números comerciais, o preço cheio é de 0,20 dólar por milhão de tokens de entrada e 0,70 dólar por milhão de saída, com 50% de desconto no lançamento, caindo para 0,10 e 0,35 respectivamente, além de 90% de desconto para tokens em cache. A velocidade citada é de 1.068 tokens por segundo em GPUs da NVIDIA. Em produção, os parceiros de acesso antecipado já usam o modelo para suporte por voz e chat, tutoria em tempo real, engenharia de dados e navegação web. No teste interno com 50 tarefas ao vivo de navegação Mind2Web, a Inception diz que o Mercury 3 completou 50% das tarefas, acima do GPT-6.1-Sol, usando volume de tokens e número de passos de agente semelhantes, mas com custo por token bem menor. Parceiros como TinyFish, RevisionDojo e Octen relatam geração mediana em torno de 0,9 segundo e resposta ponta a ponta em 2,2 segundos em busca em tempo real.

Como funciona: difusão em vez de autoregressão

Para entender o porquê da velocidade, é preciso lembrar como um LLM tradicional funciona. Um modelo autoregressivo gera um token por vez, sempre olhando para o que já gerou, o que cria um gargalo sequencial difícil de paralelizar. Um diffusion LLM trabalha de outro jeito, começa com uma sequência ruidosa ou mascarada e refina vários trechos em paralelo ao longo de passos de denoising. Na prática, isso permite aproveitar muito melhor o paralelismo da GPU, porque o modelo não precisa esperar o token anterior para avançar em várias posições. O custo disso é um número fixo de passos de refinamento e a necessidade de calibrar bem quantas iterações valem a pena para cada tipo de prompt, algo que afeta diretamente latência e qualidade.

Do ponto de vista de operador, o que importa são três variáveis: throughput, latência por resposta e previsibilidade. Throughput de mais de 1.000 tokens por segundo não significa necessariamente time to first token menor, mas significa que respostas longas, típicas de agentes que citam fontes ou explicam passo a passo, chegam completas muito mais rápido. Minha inferência técnica, olhando para o histórico do Mercury, é que a Inception deve estar usando refinamento paralelo com cache agressivo de prefixo e kernels otimizados para NVIDIA, além de uma API compatível com o padrão de chat para permitir troca direta de stack. O contexto de 1M sugere atenção esparsa ou compressão eficiente de KV cache, porque manter 1M de tokens densos em alta velocidade seria inviável em custo. Para quem opera, o ponto central é testar p50 e p95 de latência com suas ferramentas reais, não apenas média de geração, porque agente com tool calling sofre mais com variação do que com média.

O que isso muda na prática

Quem ganha primeiro são os casos onde cada segundo conta e o modelo é consultado várias vezes por tarefa. Agentes de uso de browser são o exemplo clássico, porque eles esperam o modelo a cada clique, cada pesquisa e cada análise de log, e pequenos atrasos se acumulam rápido. Tutoria interativa também ganha, porque feedback em cerca de um segundo mantém o aluno no fluxo em vez de quebrar concentração. Busca em tempo real e suporte para empresas reguladas completam a lista, já que precisam de resposta conversacional sem abrir mão de precisão. Quem perde, pelo menos no curto prazo, são os modelos rápidos generalistas que cobravam mais caro pela mesma faixa de qualidade, além de infraestruturas montadas para esconder latência com streaming agressivo e respostas curtas artificiais.

• Agentes web e de pesquisa: conseguem fazer mais tentativas por tarefa e ler mais documentos antes de responder, sem estourar timeout.
• Educação e voz: conseguem manter raciocínio e correção com latência próxima do tempo real, o que antes exigia trocar para um modelo menor e mais burro.
• Suporte e operações: conseguem manter contexto longo de tickets e logs por um custo menor, principalmente com cache de 90% para prompts repetidos.

A ação prática mais sensata agora é isolar um fluxo com latência crítica e rodar um teste A/B controlado. Pegue seu agente de suporte ou seu tutor, congele prompt e ferramentas, e meça taxa de conclusão, número de passos, tokens por tarefa e custo total, não apenas qualidade percebida. Ative o cache de contexto para instruções de sistema e base de conhecimento, porque é ali que o desconto de 90% realmente pesa na conta do mês. Se você usa API compatível com OpenAI, a troca tende a ser simples no código, mas reserve tempo para recalibrar temperatura e limite de passos, porque um modelo mais rápido muda o comportamento do agente e pode deixá-lo mais ansioso para responder antes de checar fontes.

A tensão que ninguém quer comentar

Aqui entra a dúvida real: difusão escala em inteligência ou só escala em demonstração? A Inception diz que sim, com 40 vezes mais parâmetros e 3 vezes mais inteligência desde o Mercury 1, mas triplicar benchmark partindo de uma base pequena ainda deixa perguntas sobre raciocínio longo, uso de ferramentas e aderência a instruções complexas. Velocidade impressiona, mas agente bom não vive só de gerar rápido, vive de planejar, chamar função certa e evitar alucinação em ambiente regulado. Também há o risco de que a qualidade citada contra GPT-6 Luna e Claude Haiku 5.5 reflita um recorte favorável de tarefas curtas e bem estruturadas, onde difusão brilha, e não o caos real de produção com páginas quebradas e PDFs mal formatados.

Outro ponto é custo e lock-in. O preço de lançamento com 50% de desconto é agressivo, mas preço de lançamento sempre é. A pergunta que importa é quanto custa depois, com tráfego real, contexto de 1M e picos de concorrência. Throughput alto em GPU da NVIDIA é ótimo no papel, mas precisamos ver disponibilidade, rate limits e estabilidade de latência em horário de pico. E há um efeito sutil: quando gerar fica barato e rápido, todo mundo passa a gerar mais, com mais passos de agente e mais documentos lidos, e a conta total pode subir mesmo com token mais barato. Isso resolve o gargalo da espera ou só move o gargalo para orquestração, avaliação e observabilidade? Minha aposta é que resolve metade do problema e expõe a outra metade, que é a nossa dificuldade de construir agentes que sabem quando parar.

Conclusão

O Mercury 3 é o primeiro sinal forte de que difusão em texto pode competir de frente com autoregressão em qualidade, mantendo uma vantagem brutal de velocidade e custo para casos sensíveis à latência. Vale testar agora em um fluxo real com métricas de conclusão e custo total, mas sem aposentar sua stack atual antes de validar p95 e comportamento com ferramentas. Afinal, se gerar 1.000 tokens por segundo ficar comum, qual será sua desculpa quando o agente ainda errar devagar, só que mais rápido?