- Mercury é um novo modelo de linguagem de grande porte (LLM) comercial que utiliza o método de difusão (Diffusion)
- O modelo é baseado na arquitetura Transformer e tem como característica prever vários tokens em paralelo
- Mercury Coder é o primeiro conjunto de LLMs de difusão, desenvolvido para escrita de código, e é oferecido em dois tamanhos: Mini e Small
- Em GPUs NVIDIA H100, registra throughput de 1109 (Mini) e 737 (Small) tokens/segundo, mostrando desempenho até 10 vezes mais rápido do que modelos existentes focados em velocidade, com a mesma qualidade
- Também registrou 2º lugar em qualidade e 1º lugar em velocidade em benchmarks de uso real e avaliações de desenvolvedores como o Copilot Arena, além de oferecer API pública e playground
Visão geral
- Mercury é uma nova série de modelos de linguagem de grande porte baseada em difusão (diffusion), uma nova geração de LLMs que opera em escala comercial
- Todos os modelos são parametrizados com a arquitetura Transformer e treinados para prever vários tokens em paralelo
- Este relatório apresenta principalmente a primeira linha do Mercury Coder, projetada para aplicativos de geração de código
- O Mercury Coder está disponível atualmente em dois tamanhos de modelo: Mini e Small
Principais contribuições
- O Mercury Coder alcança um novo nível state-of-the-art no equilíbrio entre velocidade e qualidade
- Segundo a instituição de avaliação externa Artificial Analysis:
- Mercury Coder Mini: 1109 tokens por segundo
- Mercury Coder Small: 737 tokens por segundo em GPUs NVIDIA H100
- Mostra qualidade semelhante com velocidade média até 10 vezes maior em comparação com os melhores modelos de fronteira em velocidade
- Também são fornecidos resultados adicionais de avaliação em benchmarks de código para diversas linguagens de programação e casos de uso
- Em ambientes reais de desenvolvimento (Copilot Arena), também alcançou:
- 2º lugar em qualidade
- 1º lugar geral em velocidade
- Oferece API pública ( platform.inceptionlabs.ai ) e playground de chat gratuito ( chat.inceptionlabs.ai ) para uso por qualquer pessoa
Explicação da estrutura do índice
- Introduction (introdução)
- principais contribuições (Contributions)
- Inception Mercury Model Family (explicação da família de modelos)
- processo de treinamento (Training)
- método de inferência (Inference)
- Capabilities (recursos do modelo)
- desempenho de baseline (Baselines)
- capacidades de geração de código (Coding Capabilities)
- benchmarks de avaliação (Evaluation Benchmarks)
Resumo
- O Mercury combina um design inovador de LLM baseado em difusão com uma arquitetura de previsão paralela para entregar velocidade impressionante e alta qualidade na geração de código
- Com modelos de vários tamanhos, benchmarks robustos em serviços reais e fácil acessibilidade, oferece uma opção competitiva tanto para ambientes comerciais quanto de desenvolvimento
1 comentários
Comentários no Hacker News
Destaca que, com a adoção de agentes LLM, o desempenho dos testes deve se tornar um gargalo de CPU ainda mais grave, e que já hoje todas as equipes sofrem com gargalos por causa da velocidade do CI
Mesmo que o agente escreva código 100 vezes mais rápido que uma pessoa, se os testes levarem uma hora, isso não adianta
Em muitos projetos em que trabalhei, muito tempo de desenvolvedor era desperdiçado esperando mudanças serem refletidas, e muitas execuções ficavam limitadas por I/O ou falta de workers
À medida que agentes de código converterem tickets simples rapidamente em PRs e reagirem a falhas de teste corrigindo em tempo real, o gargalo do CI vai piorar ainda mais
A maioria dos ambientes de teste de projetos tem bastante espaço para melhoria, mas na prática nos acostumamos por anos com CI lento e custos altos sem grande avanço
Desligar cache para isolar totalmente os builds, ou migrar de on-premises para VMs lentas na nuvem, acabou deixando o CI ainda mais lento
A velocidade do Mercury é absurda e, nas poucas vezes que testei, a qualidade e a precisão do código foram excelentes, mas agora o desafio é fazer a execução dos testes acompanhar essa velocidade
Não me convence muito a ideia de que, na maioria dos projetos em que trabalhei, o tempo dos desenvolvedores seria desperdiçado esperando aprovação de PR
Do ponto de vista da empresa, tempo de desenvolvimento é muito mais caro que tempo de máquina, então, se houver reclamação dos desenvolvedores, isso se resolve dobrando o número de workers do CI
No Google, ao depurar instabilidade em testes, às vezes rodávamos o mesmo teste 10 mil vezes em 10 mil máquinas para encontrar falhas raras
No meu trabalho atual também temos algo parecido, com um comando que executa todos os testes em paralelo em mil workers, com a meta de dar feedback em menos de 5 minutos até para um projeto com 1M LOC
Isolar totalmente o build e não usar cache são coisas diferentes; a visão aqui é que se deve isolar completamente o build e ainda assim aproveitar ao máximo todos os caches
Se a velocidade de implementação aumentar, o gargalo vai migrar para o lado de PM, e nesse caso as mudanças devem ficar mais serializadas, o que provavelmente reduzirá bastante os conflitos
Também pode haver uma volta das linguagens de especificação formal, como TLA+, já que agentes poderiam escrevê-las e validá-las rapidamente, reduzindo o número total de testes de integração
Quando agentes em background reorganizarem código duplicado, talvez também reorganizem os testes duplicados
Ao contrário de equipes de engenheiros humanos, a IA parece trabalhar com mais eficiência em estruturas monolíticas, o que aumentaria a cobertura de testes que podem rodar localmente, reduzindo flaky tests e a carga no CI
Mesmo que a IA aumente a eficiência, isso também significará mais código, geração e execução mais rápida, então novos problemas continuarão surgindo, e sigo convencido de que sempre aparecerão novos problemas para engenheiros humanos resolverem
LLM serve bem para correções rápidas de menos de 100 linhas ou como rubber duck, mas colocá-lo diretamente no pipeline de CI de um projeto grande pode causar queda de produtividade na casa de centenas de horas
Não faz sentido passar o tempo ajustando prompt e contexto quando esse tempo deveria ser usado para melhorar a habilidade real de escrever código
Sinto que existe confiança demais em tooling com LLM, e acho que isso não se aplica bem a sistemas complexos
Tenho um nível de desconfiança tão grande que só colocariam um LLM sem supervisão em um repositório importante “sob a mira de uma arma”
No fim, você acaba retrabalhando metade do resultado do LLM, e, nesse caso, é melhor fazer você mesmo
Antes do automóvel, quase não se gastava dinheiro com gasolina, óleo e manutenção, mas, à medida que o sistema evolui, a infraestrutura e os custos auxiliares vêm junto
A ideia é um ciclo em que se usa IA para resolver gargalos ou criar mais funcionalidades e maximizar receita, e com essa receita extra se compra mais recursos de CI
IA não é diferente de contratar mais 10 desenvolvedores, então é natural que os custos de suporte aumentem
Vale refletir se é possível justificar logicamente mais recursos de CI com base em eficiência, ou indicar um caminho de otimização
Fico curioso sobre quanto custa cada máquina de recurso de CI
Em um app Python, tive uma grande melhora na velocidade do CI usando o toolchain da astral.sh e instalação de pacotes com uv + cache
Em breve pretendo migrar do mypy para o type checker da Astral, o que deve deixar tudo ainda mais rápido
No caso de apps com frontend, os testes de Playwright provavelmente serão a parte mais lenta, mas em outros apps isso nem se aplica
(P.S.: se o Mike estiver certo, acho que é o SRE com quem trabalhei no Google Maps no começo dos anos 2000; é uma opinião em que confio)
Quando pedi um padrão de expressão regular no playground do Mercury, o modelo começou a planejar sozinho, escreveu o padrão e depois começou a gerar testes
Só que ele foi expandindo os testes sem parar até bater no limite de contexto, e a resposta foi interrompida
Depois de uns 30, começou a colocar comentários errados nos resultados dos testes, e depois de mais de 120 até as entradas dos testes ficaram estranhas, cheias de caracteres aleatórios
O padrão em si também não estava correto, mas esse fenômeno de “loop infinito” foi ainda mais interessante
A propósito, lembro que, até bem pouco tempo atrás, LLMs comuns também às vezes produziam saídas repetitivas que pareciam esse tipo de “quase loop infinito”
Ficavam presos em padrões de saída que mudavam só um pouquinho
Acho que esse caso é uma prova representativa de que “só prever tokens” não basta para produzir código correto
Na origem, LLMs não foram projetados de forma adequada para raciocínio sobre código
Pelo que li no relatório técnico, confirmei que o Mercury é baseado no artigo Lou et al. 2023, SEDD
Eu fui o primeiro (acho) a reimplementar SEDD do zero, e aqui está o código aberto
Também implementei diretamente o método complexo de denoising
Projetei tudo para ficar mais limpo e legível que o SEDD original, e roda em poucas horas em uma única GPU com dataset de brinquedo
Só como referência, a DeepMind também tem um modelo Gemini baseado em diffusion (link)
Testando por conta própria, achei que, como o Mercury, a velocidade é absurda, mas a qualidade das respostas ficou bem abaixo das outras variantes do Gemini
Pelo uso rápido que fiz, concordo que a velocidade impressiona, mas a taxa de acerto cai bastante
Fico curioso se o demo do Gemini Diffusion é gratuito
Estou na lista de espera há dias, então ainda não tive chance de testar de verdade
Pessoalmente, acho esse tipo de avanço muito empolgante
Recentemente, em uma game jam, usei IA para programar um jogo simples, e mais da metade do tempo foi gasto esperando os resultados
Se, em vez de 1 ou 2 minutos por prompt, eu precisasse esperar só 10 segundos, daria para fazer de cinco a dez experimentos no tempo em que hoje se faz um teste
O Mercury ainda não está maduro o suficiente para uso prático, mas o Claude 3.0 também deixava a desejar há um ano, então a tendência é melhorar
É realmente um momento animador para o futuro
Usei o playground do Mercury e a velocidade é realmente impressionante
A visualização do modo diffusion também é interessante, mas, na prática, parece mostrar o processo de refinamento gradual a partir de um ruído linear visualizado até um estado mais preciso
Na prática, vejo isso como um processo em um espaço vetorial arbitrário que converge gradualmente para tokens mais definidos
Alguns modelos de diffusion para texto usam um espaço latente contínuo, mas o desempenho não costuma ser muito bom
Hoje em dia, em geral o foco está em prever a saída em tokens reais, corrigindo os valores anteriores em cada etapa até convergir no resultado final
Recomendo este link com explicação de como diffusion para texto funciona que escrevi
Link: https://chat.inceptionlabs.ai/
Sinceramente, parece rápido num nível absurdo
A maior parte do código adjacente a GPU ainda tem enorme margem para otimização de desempenho
Mas há a dúvida se o paper no arXiv é pesquisa de verdade ou mais marketing que ciência
Opiniões contrárias são bem-vindas
Política de preços do modelo Mercury
US$ 1 por 1 milhão de tokens de saída e US$ 0,25 por 1 milhão de tokens de entrada
Mais detalhes de preço aqui
Para casos sensíveis a desempenho, comparando Mercury com Groq (Llama 3.1 8b, Llama 4 Scout), o desempenho foi parecido, mas o preço do Groq ficou muito mais vantajoso
Estou acompanhando com interesse, na expectativa de surgir um modelo de diffusion open source
No código do playground e na resposta da API aparecem
gpt-3.5-turboe"openai": true, então fiquei na dúvida se eles na verdade chamam a OpenAI em vez de usar o próprio dLLMO efeito diffusion no canto superior direito parece ser só uma animação
Tudo isso soa muito legal, mas
os termos de uso, ao enviar posts de usuário para o serviço, você concede à Inception uma licença global, não exclusiva, perpétua, sem royalties, gratuita e totalmente sublicenciável
Ou seja, seu conteúdo pode ser usado para treinar modelos de IA
(Mas há uma cláusula de exceção dizendo que acessos via OpenRouter não são usados para treinamento)