Benchmark VibeQwen da Baseten supera vLLM em até 90%, com uma ressalva

A Baseten afirma que seu mecanismo VibeQwen superou o vLLM em até 90% depois que o Claude Code passou uma semana otimizando uma implantação rigidamente definida. O benchmark VibeQwen da Baseten combinou o Qwen-3.6-35B-A3B com pesos NVFP4 e uma única GPU NVIDIA B200.

O resultado parece uma derrota direta para os mecanismos abertos de inferência mais consolidados. É mais bem entendido como um desafio às suas prioridades de design. O VibeQwen mirou um único modelo, acelerador, formato de precisão e carga de trabalho, enquanto o vLLM suporta um cenário amplo e em constante mudança de implantações.

O experimento também reposiciona o papel dos agentes de programação. O Claude Code não se limitou a sugerir kernels CUDA isolados. Segundo a Baseten, ele montou um mecanismo de inferência funcional, implantou candidatos, mediu endpoints de produção, verificou a precisão e iterou por aproximadamente uma semana.

Os números de destaque continuam sendo resultados do próprio benchmark da Baseten. O VibeQwen não recebeu testes independentes amplos, e a vantagem reportada de 90% apareceu em texto repetitivo e estruturado, que favorecia a decodificação especulativa. A questão mais relevante é se esse processo especializado e orientado por agentes pode se tornar engenharia repetível, em vez de um resultado impressionante de laboratório.

O que o benchmark VibeQwen da Baseten realmente mediu

O resultado mais forte da Baseten veio de uma configuração restrita e explicitamente otimizada, não de um substituto universal para o vLLM.

O engenheiro da Baseten Shawn Rushefsky publicou o experimento em 2 de outubro de 2026. Seu benchmark de inferência descreve um mecanismo gerado para o Qwen-3.6-35B-A3B, usando precisão NVFP4 em um acelerador B200.

NVFP4 é um formato de ponto flutuante de quatro bits projetado para reduzir o tráfego de memória e acelerar a computação em hardware NVIDIA compatível. Essa escolha de precisão importa porque a velocidade de inferência depende fortemente do modelo, do formato de quantização, da arquitetura da GPU e dos kernels disponíveis.

A Baseten chamou o mecanismo gerado de VibeQwen. A empresa o comparou a uma implantação ajustada do vLLM 0.25.1 usando hardware idêntico com uma única B200.

Em texto de fluxo único favorável ao especulador, o VibeQwen teria gerado 1.792 tokens de saída por segundo. A implantação do vLLM produziu 943 tokens por segundo nas mesmas condições de teste reportadas.

Essa diferença produziu a melhoria de 90% destacada no título. “Favorável ao especulador” descreve saídas repetitivas ou estruturadas nas quais um decodificador especulativo pode propor vários tokens prováveis para verificação paralela.

O tempo até o primeiro token, ou TTFT, caiu de 28 milissegundos com o vLLM para 12 milissegundos com o VibeQwen. O TTFT mede o atraso entre o envio de uma solicitação e o recebimento do primeiro token gerado.

A Baseten caracterizou essa mudança como uma melhoria de 2,33 vezes. O atraso menor importa para assistentes interativos, conclusão de código e interfaces de voz, nas quais os usuários percebem imediatamente a pausa inicial.

O VibeQwen também teria liderado sob tráfego mais intenso. Com concorrência 32, uma réplica gerou 10.307 tokens de saída por segundo, em comparação com 6.030 para o vLLM.

Isso representou uma taxa agregada de saída 71% maior. O resultado sugere que a vantagem do mecanismo não se limitou a um teste isolado de usuário único, embora tenha abrangido apenas um nível de concorrência reportado.

A comparação usou o vLLM 0.25.1, identificado pela Baseten como atual quando o experimento começou. O histórico de versões do projeto mostra que essa versão foi uma atualização de correção contendo dois consertos de bugs direcionados.

A Baseten não afirmou que todos os modelos, distribuições de prompts ou GPUs produziriam a mesma margem. Os resultados publicados dizem respeito a essa combinação específica de modelo, hardware e carga de trabalho.

Essa distinção deve orientar a interpretação dos números pelos compradores. Uma liderança de 90% em texto selecionado é uma evidência significativa de margem para otimização, mas não representa uma melhoria de 90% no serviço de IA em geral.

Portanto, o benchmark muda a questão competitiva. As equipes agora precisam perguntar se um runtime amplamente compatível continua sendo o melhor destino para uma carga de trabalho estável e de alto volume.

Por que um agente de programação conseguiu encontrar tanta margem de otimização

A otimização de inferência é adequada a agentes de programação porque velocidade, qualidade de saída e comportamento do hardware podem ser testados por meio de feedback mensurável.

A Baseten adaptou ideias do MetaInfer, um sistema experimental que trata um LLM como um compilador para software de inferência. Em vez de manter um único mecanismo para todos os ambientes, o sistema gera software compacto em torno de restrições explícitas de runtime.

O projeto MetaInfer combina agentes de programação com uma base de conhecimento de contratos. Essa base registra restrições, testes, padrões que funcionam e lições de tentativas malsucedidas.

Um agente pode propor uma implementação, compilá-la, executar uma suíte de correção, medir o desempenho e revisar o código. Cada ciclo retorna um sinal mais claro do que o fornecido por muitas tarefas comuns de software.

Um redesign visual, por exemplo, depende parcialmente do julgamento humano. Um mecanismo de inferência oferece medições objetivas, como latência, throughput, utilização da GPU, consumo de memória e precisão da saída.

Essa clareza torna prática a otimização de longa duração. Um agente não precisa convencer um revisor de que um candidato parece mais rápido. Ele deve superar uma referência numérica enquanto atende a critérios de correção predefinidos.

A Baseten deu ao Claude Code acesso aos materiais do MetaInfer, aos pesos do modelo e a uma estação de trabalho B200 via SSH. Também forneceu o modelo em precisão total como um oráculo de precisão, ou seja, uma referência confiável para verificar a qualidade da saída.

O objetivo inicial era exigente. A Baseten pediu ao agente que superasse o vLLM em 20% nas métricas de desempenho sem perder precisão em relação à referência NVFP4.

O Claude Code podia implantar candidatos na Baseten e executar o AIPerf contra cada endpoint. O AIPerf é um gerador de carga de trabalho que mede o comportamento de serviço de modelos implantados, em vez de apenas cronometrar um kernel isolado.

Rushefsky afirma que o processo durou aproximadamente uma semana. Ele consumiu cerca de 1,7 bilhão de tokens, majoritariamente de entrada em cache, e aproximadamente 200 horas de B200.

O mecanismo teria alcançado paridade com o vLLM nos primeiros dias. A Baseten permitiu que o sistema continuasse buscando, o que produziu as maiores margens finais.

A supervisão humana não desapareceu. Rushefsky ocasionalmente redirecionava o sistema quando ele se concentrava demais em um único formato de tráfego.

O Claude Code também interrompeu o trabalho quando mudanças propostas alteravam as saídas numéricas. A Baseten acabou aceitando diferenças sutis em relação à sua referência NVFP4 quando a precisão geral contra o modelo BF16 permanecia pelo menos tão forte.

BF16, ou bfloat16, mantém maior faixa numérica e precisão do que um formato de quatro bits. A comparação com uma implementação BF16 pode revelar se mudanças de quantização ou de kernel prejudicam a qualidade do modelo.

Esses controles explicam por que isso foi mais do que um prompt estendido de geração de código. A Baseten construiu um ambiente no qual o agente podia agir, observar resultados, reter conhecimento útil e encontrar barreiras antes de aceitar mudanças arriscadas.

O experimento também aproveitou implementações abertas. A Baseten permitiu que o agente inspecionasse vLLM e TensorRT-LLM, incluindo kernels pré-otimizados quando apropriado.

Essa escolha torna o projeto mais relevante para a engenharia de produção, mas menos útil como evidência de invenção algorítmica sem assistência. O VibeQwen representa integração e especialização orientadas por agentes em componentes existentes e recém-escritos.

O resultado ainda é notável. Engenheiros há muito usam profilers, benchmarks e sistemas de autotuning. Aqui, um LLM teria coordenado decisões entre kernels, lógica do mecanismo, comportamento de serving, implantação e validação.

Mecanismos especializados pressionam runtimes de uso geral

A principal disputa não é VibeQwen versus vLLM como produtos. É especialização versus generalidade como estratégia de engenharia.

vLLM, SGLang e TensorRT-LLM resolvem um amplo problema de compatibilidade. Eles precisam suportar muitas arquiteturas, formatos de quantização, aceleradores, padrões de batching, APIs e requisitos operacionais.

Essa abrangência cria enorme valor prático. Uma equipe pode implantar um novo modelo sem antes construir um runtime em torno de cada camada, kernel ou padrão de serving incomum.

Ela também cria abstrações. Agendadores, executores de modelos, camadas de compatibilidade, caminhos de fallback e kernels configuráveis acrescentam ramificações que um mecanismo de propósito único poderia eliminar.

A tese do MetaInfer é que essas abstrações deixam desempenho sobre a mesa. Quando uma implantação se torna estável, um agente pode especializar o mecanismo em torno de suas restrições exatas.

O VibeQwen mirou o Qwen-3.6-35B-A3B em NVFP4 em uma B200. Ele não precisava preservar uma rota elegante para modelos não relacionados ou aceleradores mais antigos.

Um mecanismo especializado pode fundir operações que sempre ocorrem juntas. Ele pode remover conversões, transferências de memória, verificações em runtime e interfaces genéricas que não atendem à carga de trabalho selecionada.

O trabalho anterior de otimização de kernels da Baseten ilustra o espaço de busca disponível. Seus agentes teriam combinado profiling no nível do modelo com experimentação por kernel em modelos de difusão e de linguagem.

Nesses projetos, mudanças úteis incluíram pré-empacotar escalas constantes, fundir normalização com quantização e remover operações intermediárias de memória. Essas técnicas reduzem trabalho sem alterar a computação pretendida pelo modelo.

O experimento VibeQwen estendeu esse raciocínio a toda a pilha de serving. Um endpoint de produção envolve mais do que multiplicação rápida de matrizes.

As solicitações precisam entrar por uma API, passar por agendamento e batching, executar kernels do modelo, transmitir tokens em fluxo e compartilhar memória limitada da GPU. Otimizar apenas um kernel pode deixar intocado o gargalo dominante.

Um agente de programação pode investigar interações entre essas camadas. Ele também pode executar vários experimentos sem se cansar ou se apegar a uma implementação projetada manualmente.

Essa pressão não torna os mecanismos de uso geral obsoletos. Em vez disso, ela pode mudar seu lugar no ciclo de vida de uma implantação.

Uma equipe pode começar com o vLLM porque ele oferece compatibilidade, manutenção ativa e uma interface de serving familiar. Quando o tráfego se torna previsível, um agente poderia gerar uma ramificação especializada para esse perfil de produção.

O mecanismo geral continuaria sendo a referência e o fallback. O mecanismo personalizado lidaria com cargas de trabalho nas quais a latência economizada ou o throughput adicional justifiquem seu ônus de manutenção.

Isso se assemelha à compilação guiada por perfil, mas o alvo da otimização inclui o comportamento da aplicação e a infraestrutura de serving. O agente está buscando no código-fonte, nos kernels, na configuração do runtime e nas decisões de implantação.

A abordagem também pode aumentar a pressão sobre mecanismos consolidados para expor mais pontos de especialização. Um runtime modular poderia permitir que agentes otimizem caminhos selecionados sem substituir todo o sistema de serving.

O vLLM não está parado. Suas versões mudam regularmente executores de modelos, decodificação especulativa, suporte a quantização e caminhos de hardware.

Portanto, o benchmark VibeQwen da Baseten deve ser lido como um retrato de uma disputa em movimento. A referência pode melhorar, enquanto descobertas reutilizáveis do VibeQwen podem eventualmente entrar em runtimes mais amplos.

A mudança duradoura é estratégica. O desempenho de uso geral não é mais necessariamente a etapa final de otimização para cargas de trabalho valiosas.

A afirmação de 90% vem com limites importantes

O benchmark é suficientemente crível para justificar investigação, mas é estreito e baseado em autorrelato demais para sustentar uma conclusão universal sobre desempenho.

A maior preocupação é a seleção de cargas de trabalho. A Baseten afirma que o resultado de 90% veio de texto estruturado e repetitivo, favorável ao seu especulador.

A decodificação especulativa acelera a geração ao propor vários tokens futuros e verificá-los em conjunto. Sua eficácia depende da frequência com que essas propostas correspondem ao que o modelo-alvo geraria.

Código estruturado, templates e dados repetitivos podem produzir altas taxas de aceitação. Prosa aberta, idiomas incomuns, escrita criativa ou contextos que mudam rapidamente podem se comportar de forma diferente.

A Baseten relatou que o VibeQwen liderou em todos os padrões de tráfego testados. No entanto, o resumo público não fornece dados granulares suficientes para reconstruir cada distribuição de prompts e taxa de aceitação.

O benchmark também vem da empresa que desenvolveu e hospeda o mecanismo. Nenhuma parte independente reproduziu os resultados do VibeQwen com hardware e pesos de modelo idênticos.

Isso não invalida as medições. Limita a afirmação a “a Baseten afirma” até que código, fixtures de teste ou resultados de terceiros permitam replicação direta.

O padrão de precisão merece cuidado semelhante. A Baseten começou exigindo que não houvesse perda de precisão em relação a uma referência NVFP4.

Durante a otimização, a equipe permitiu pequenas diferenças numéricas quando a precisão agregada em relação à linha de base BF16 permanecia pelo menos tão boa. Trata-se de um compromisso de engenharia razoável, mas exige avaliação detalhada por tarefa.

Uma pontuação média pode ocultar regressões em domínios específicos. Empresas precisariam de testes que cubram seus próprios prompts, chamadas de ferramentas, saídas estruturadas, comportamento de segurança e cargas de trabalho de contexto longo.

A confiabilidade operacional é outra questão em aberto. Uma execução de benchmark não mede meses de atualizações em produção, solicitações malformadas, mudanças no tokenizer, atualizações de drivers ou comprimentos de sequência incomuns.

Mecanismos gerais conquistam confiança em parte pelo uso disseminado. Seus casos extremos são encontrados e corrigidos por uma base maior de colaboradores e clientes.

Um mecanismo personalizado concentra a responsabilidade. A mesma especialização que elimina sobrecarga pode criar pressupostos frágeis sobre formatos, lotes, precisão ou comportamento do hardware.

O custo de desenvolvimento também importa, mesmo sem atribuir um preço público. O VibeQwen teria consumido cerca de 200 horas de B200 e 1,7 bilhão de tokens de modelo.

Esses insumos podem se justificar para uma carga de trabalho grande e persistente. Eles são menos atraentes quando um modelo muda semanalmente ou o tráfego permanece pequeno demais para recuperar o esforço de engenharia.

O orçamento de iteração do experimento também complica a comparação direta. O vLLM precisa distribuir seu trabalho de desenvolvimento entre muitos usuários, modelos e dispositivos.

O Claude Code passou uma semana otimizando um único alvo. A liderança do VibeQwen, portanto, demonstra tanto o valor do esforço concentrado quanto a superioridade de software escrito por agentes.

O segundo experimento da Baseten oferece evidências encorajadoras, mas incompletas, de reutilização. A empresa aplicou sua base de conhecimento ampliada a um servidor de segmentação de imagens SAM 3.1.

Esse sistema, chamado Sammie, teria processado 91 imagens por segundo em uma H100. A Baseten afirma que isso ficou 50% acima do servidor de referência da Meta após vários dias e aproximadamente 200 milhões de tokens.

O modelo, a GPU, a arquitetura e a linha de base eram todos diferentes dos do VibeQwen. A Baseten também observou a ausência de um experimento de controle.

O Sammie, portanto, sugere que o conhecimento acumulado ajudou, mas não isola a contribuição da base de conhecimento. Uma conclusão mais rápida poderia ter resultado de uma carga de trabalho mais simples ou de outras diferenças procedimentais.

A interpretação mais segura não é nem rejeição nem celebração. O VibeQwen fornece um forte sinal de que agentes de programação podem coordenar uma otimização profunda de sistemas.

Ele ainda não demonstra que empresas possam gerar mecanismos personalizados confiáveis sob demanda, preservá-los durante atualizações de modelos e superar runtimes mantidos por especialistas de forma consistente.

Por que o Resultado Importa Além de uma Implantação de Qwen

A maior oportunidade é um processo de implantação no qual a otimização começa depois que o modelo, o hardware e o padrão de tráfego se tornam conhecidos.

Frameworks tradicionais de inferência precisam tomar decisões de projeto antes de conhecer a carga de trabalho exata de cada usuário. Mecanismos construídos por agentes invertem essa sequência.

Eles começam pelos fatos da implantação. Isso pode incluir o modelo selecionado, os comprimentos esperados dos prompts, a distribuição de saídas, metas de concorrência, requisitos de precisão e o tipo de acelerador.

Um assistente de código corporativo oferece um exemplo útil. Suas saídas frequentemente contêm sintaxe, indentação, chamadas comuns de bibliotecas e convenções repetidas de projeto.

Essa regularidade pode favorecer a decodificação especulativa. Um TTFT baixo também melhora a sensação interativa da conclusão de código em linha.

Um sistema de voz tem uma prioridade diferente. Ele pode aceitar menor throughput total se o primeiro token chegar rapidamente e a geração permanecer estável o bastante para uma fala natural.

Em vez disso, um serviço de resumo em lote pode priorizar o throughput agregado. Ele pode tolerar um primeiro token mais lento quando milhares de documentos compartilham faixas previsíveis de entrada e saída.

Runtimes gerais precisam acomodar os três. Um mecanismo especializado pode otimizar para apenas um.

A abordagem poderia tornar a seleção de modelos mais flexível. Um modelo que antes não atendia a uma meta de latência poderia se tornar viável após uma otimização específica para a carga de trabalho.

Essa possibilidade afeta compradores de infraestrutura e equipes de aplicações. Comparações de qualidade entre modelos frequentemente pressupõem que o software de serving já capturou a maior parte do desempenho disponível.

O VibeQwen desafia essa premissa. As escolhas de runtime podem alterar materialmente qual modelo oferece a melhor qualidade, responsividade e capacidade em hardware fixo.

Isso é especialmente relevante para modelos de mistura de especialistas. O Qwen-3.6-35B-A3B ativa apenas parte de seu conjunto total de parâmetros para cada token, criando comportamentos distintos de roteamento e memória.

Um runtime que conhece o layout exato dos especialistas e o esquema de quantização pode direcionar esses padrões. Um mecanismo genérico precisa manter caminhos para outras arquiteturas.

A Baseten já explorou outro caminho por meio da decodificação especulativa. Sua implementação DFlash teria melhorado o desempenho do Qwen3-8B ao prever vários tokens em paralelo.

Esse trabalho anterior exigia treinamento e implementação específicos para o modelo. O VibeQwen, por outro lado, enfatiza um agente coordenando a otimização em torno de um modelo existente e pesos quantizados.

As duas abordagens podem convergir. Um agente de otimização poderia escolher entre modelos de rascunho, fusão de kernels, cache, batching e alterações no layout de memória.

Essa busca ampla é valiosa porque os gargalos mudam conforme a carga de trabalho. Melhorar a velocidade de decodificação pode expor a sobrecarga do agendador, a latência de rede ou o pré-processamento como a próxima restrição.

A base de conhecimento reutilizável pode se tornar o ativo mais importante. Kernels bem-sucedidos importam, mas falhas documentadas podem impedir que futuros agentes repitam experimentos caros.

Uma biblioteca crescente de contratos de hardware e regras de validação poderia reduzir o trabalho necessário para cada novo mecanismo. O teste Sammie da Baseten foi uma tentativa inicial de observar esse efeito.

Se a reutilização melhorar, a otimização se torna menos parecida com um projeto de consultoria personalizado. Ela passa a se assemelhar a uma etapa automatizada de compilação para serviços de IA em produção.

Essa transformação exige registros cuidadosos. As equipes precisam preservar entradas de benchmark, versões de compiladores, drivers, kernels, hashes de modelos, suítes de precisão e configuração de implantação.

Caso contrário, um resultado rápido se torna um artefato impossível de repetir. O agente pode saber como alcançou a pontuação, mas a organização não consegue reproduzi-la ou auditá-la com segurança.

É nesse ponto que a engenharia humana permanece central. Desenvolvedores definem metas úteis, evitam manipulação de benchmarks, escolhem dados de validação e decidem quais compromissos entre desempenho e qualidade são aceitáveis.

O VibeQwen não elimina essa responsabilidade. Ele permite que um agente de programação explore um espaço maior de implementação depois que engenheiros definem os limites.

Três Sinais Determinarão se Mecanismos Construídos por Agentes Vão Durar

O próximo teste é a repetibilidade entre cargas de trabalho, mudanças de ciclo de vida e ambientes independentes, e não mais um recorde isolado.

O primeiro sinal é um pacote VibeQwen reproduzível. Equipes independentes precisam de código, configuração, dados de prompts e lógica de avaliação suficientes para executar novamente a comparação.

A replicação deve abranger prosa comum, código, saída estruturada, vários idiomas, contextos longos e diferentes níveis de concorrência. Ela também deve informar as taxas de aceitação especulativa.

Um resultado amplo fortaleceria o argumento da Baseten de que a especialização capturou uma margem de desempenho duradoura. Uma vantagem drasticamente reduzida limitaria a manchete a tráfego favorável.

O segundo sinal é a sobrevivência às mudanças. Provedores de modelos revisam pesos, tokenizers, receitas de quantização e requisitos de serving.

A NVIDIA também atualiza compiladores, drivers, bibliotecas e gerações de GPUs. Um mecanismo personalizado útil deve absorver essas mudanças sem exigir outra semana de reconstrução frágil.

Observe com que rapidez um agente consegue portar o VibeQwen para outra versão do Qwen ou para um acelerador diferente. A comparação deve incluir o tempo de revisão humana, o orçamento de computação e as regressões encontradas após a implantação.

Uma migração rápida e confiável sustentaria a ideia de que a base de conhecimento se acumula. Resgates manuais repetidos sugeririam que mecanismos personalizados continuam sendo projetos caros de especialistas.

O terceiro sinal é uma resposta dos runtimes de uso geral. vLLM, SGLang e TensorRT-LLM podem adotar novos kernels, interfaces de especialização ou técnicas de ajuste automatizado.

Alguns ganhos do VibeQwen podem entrar em mecanismos compartilhados assim que os mantenedores entenderem os caminhos relevantes. Isso reduziria a lacuna direta do benchmark, ao mesmo tempo que validaria o trabalho de otimização subjacente.

Uma resposta mais profunda permitiria que usuários gerassem planos de execução especializados dentro de um runtime mantido. Esse modelo híbrido poderia preservar a compatibilidade e, ao mesmo tempo, remover a sobrecarga de implantações fixas.

O vencedor pode não ser um mecanismo inteiramente gerado nem um inteiramente genérico. Pode ser um framework geral com limites de especialização controlados por agentes e fortes caminhos de fallback.

Para desenvolvedores, a lição imediata é prática. Trate o software de inferência como um componente mensurável, não como um invólucro intercambiável em torno dos pesos do modelo.

Registre as distribuições de prompts e saídas antes de escolher alvos de otimização. Teste TTFT, latência por token de saída, throughput, memória, precisão e comportamento de cauda usando solicitações semelhantes às de produção.

Para compradores corporativos, pergunte aos fornecedores o que o benchmark otimizou e o que excluiu. Um único número de throughput de pico diz pouco sobre latência interativa, qualidade, portabilidade ou esforço operacional.

Pergunte também se os ganhos relatados sobrevivem a dados variados. O benchmark Baseten VibeQwen é mais útil quando inicia uma avaliação cuidadosa, e não quando a encerra.

O experimento oferece uma visão convincente da engenharia autônoma de sistemas. Ele também mostra por que agentes precisam de testes rigorosamente projetados e limites definidos por humanos.

Os próximos um a três meses devem revelar se o VibeQwen se torna reproduzível, portátil e sustentável. Qual resultado mudaria mais seu plano de implantação: replicação independente, migração rápida de modelos ou especialização semelhante dentro do vLLM?