A provedora de inferência Baseten publicou em 2 de outubro um post técnico: usando o Claude Code para conduzir o Fable 5, a empresa deixou um agente escrever do zero um motor de inferência dedicado a um único modelo, que superou o vLLM em todos os padrões de tráfego testados.
O motor se chama VibeQwen e foi feito especificamente para o Qwen-3.6-35B-A3B, da Alibaba. O autor Shawn Rushefsky escreve no texto:
"the generated engine, called VibeQwen, outperformed vLLM across all tested traffic patterns, and by very large margins in some cases"
(O motor gerado, chamado VibeQwen, superou o vLLM em todos os padrões de tráfego testados, e por margens muito grandes em alguns casos.)
De onde vêm os números
O hardware de teste foi a Nvidia B200, o grupo de comparação foi o vLLM 0.25.1, e a ferramenta de carga foi o AIPerf. Alguns resultados:
- Decodificação de fluxo único em 1792 TPS, contra 943 TPS do vLLM, cerca de 90% mais rápido;
- Latência até o primeiro token cai de 28 para 12 milissegundos, cerca de 2,3 vezes;
- Com 32 requisições simultâneas, o throughput é 71% maior.
Em termos de custo, o VibeQwen levou cerca de uma semana, consumiu cerca de 1,7 bilhão de tokens (a maior parte em cache), cerca de 200 horas de B200, com custo total na faixa de alguns milhares de dólares.
A Baseten também testou o mesmo método em segmentação de imagem. O segundo resultado se chama Sammie, serve o SAM 3.1 da Meta, roda em H100, foi concluído em poucos dias, custou algumas centenas de dólares e cerca de 200 milhões de tokens. Com 32 requisições simultâneas, o throughput foi 50% maior que o servidor de referência oficial da Meta, chegando a 91 imagens por segundo.
O que o agente realmente fez
A Baseten expandiu seu próprio framework, chamado MetaInfer, para uma pilha de serviço completa e deixou o agente preenchê-la. O agente podia consultar soluções open source existentes como referência, media com o AIPerf depois de cada rodada de mudanças e decidia o próximo passo com base nos números.
Uma restrição foi escrita de forma bem específica: qualquer mudança que pudesse afetar a precisão da saída obrigava o agente a parar e pedir aprovação humana. Pequenos desvios numéricos são o que há de mais difícil de detectar em um motor de inferência; se o ganho de velocidade vier às custas da precisão, isso não aparece no placar de benchmark — é exatamente isso que essa restrição bloqueia.
O próprio post traça limites. VibeQwen e Sammie ainda são experimentos e não atenderam tráfego de produção. A comparação do Sammie é ainda mais rudimentar, e o autor admite que esses números servem apenas como "evidência sugestiva": arquiteturas diferentes, aceleradores diferentes, sem teste controlado.
O que isso significa para equipes na China
O alvo do VibeQwen é o modelo open source Qwen, e muitos serviços em produção na China também rodam, por coincidência, na combinação Qwen com vLLM ou SGLang — então esses números têm relação direta com o dia a dia de boa parte dessas equipes.
Vale comparar a conta econômica das duas abordagens. Um motor genérico precisa atender centenas de arquiteturas de modelo, então muitas otimizações agressivas voltadas a uma única arquitetura não cabem nele; um motor dedicado foca em apenas um modelo e pode ajustar os kernels de atenção, o roteamento de MoE e a estratégia de escalonamento inteiramente para o formato do 35B-A3B. Antes, escrever um motor dedicado exigia uma equipe trabalhando meses; a Baseten comprimiu isso para uma semana e alguns milhares de dólares — em conta grosseira, mais barato que um mês de trabalho de um engenheiro de inferência.
As limitações também são claras:
- O motor fica preso ao modelo. Se o Qwen for atualizado com mudanças estruturais, o motor provavelmente precisará ser regerado.
- Os testes só cobriram o B200. Os modelos de GPU disponíveis na China variam bastante, e se o mesmo processo se reproduz em outros aceleradores, o post não traz dados sobre isso.
- A estabilidade de cauda longa, a fragmentação de memória e o tratamento de requisições anômalas que a produção exige podem não estar cobertos pelos benchmarks.
Mesmo assim, a abordagem de "cada modelo principal com um motor dedicado gerado automaticamente" já tem uma amostra verificável. Se a posição do vLLM vai migrar de "pilar de produção" para "linha de base e solução de reserva" depende de equipes colocarem esse tipo de motor de fato em produção e publicarem dados ao longo de alguns meses.
Fontes: blog de engenharia da Baseten, CocoLoop; TPS, latência até o primeiro token, throughput em concorrência, consumo de tokens e horas de GPU verificados pelo blog da Baseten.