El benchmark VibeQwen de Baseten supera a vLLM hasta en un 90%, con una salvedad

Baseten afirma que su motor VibeQwen superó a vLLM hasta en un 90% después de que Claude Code dedicara una semana a optimizar un despliegue muy delimitado. El benchmark VibeQwen de Baseten combinó Qwen-3.6-35B-A3B con pesos NVFP4 y una sola GPU NVIDIA B200.

El resultado parece una derrota directa para los motores de inferencia abiertos más consolidados. Es más acertado entenderlo como un desafío a sus prioridades de diseño. VibeQwen se centró en un único modelo, acelerador, formato de precisión y carga de trabajo, mientras que vLLM admite un panorama de despliegues amplio y cambiante.

El experimento también modifica el papel de los agentes de programación. Claude Code no se limitó a sugerir kernels CUDA aislados. Según Baseten, ensambló un motor de inferencia funcional, desplegó candidatos, midió endpoints de producción, verificó la precisión e iteró durante aproximadamente una semana.

Las cifras destacadas siguen siendo resultados del propio benchmark de Baseten. VibeQwen no ha recibido pruebas independientes amplias, y la ventaja comunicada del 90% apareció en texto repetitivo y estructurado que favorecía la decodificación especulativa. La cuestión más relevante es si este proceso especializado y guiado por agentes puede convertirse en ingeniería reproducible, en lugar de un impresionante resultado de laboratorio.

Qué midió realmente el benchmark VibeQwen de Baseten

El resultado más sólido de Baseten provino de una configuración limitada y explícitamente optimizada, no de un sustituto universal de vLLM.

El ingeniero de Baseten Shawn Rushefsky publicó el experimento el 2 de octubre de 2026. Su benchmark de inferencia describe un motor generado para Qwen-3.6-35B-A3B, que utiliza precisión NVFP4 en un acelerador B200.

NVFP4 es un formato de coma flotante de cuatro bits diseñado para reducir el tráfico de memoria y acelerar el cómputo en hardware NVIDIA compatible. Esta elección de precisión importa porque la velocidad de inferencia depende en gran medida del modelo, el formato de cuantización, la arquitectura de la GPU y los kernels disponibles.

Baseten denominó VibeQwen al motor generado. La compañía lo comparó con un despliegue ajustado de vLLM 0.25.1 que utilizaba hardware idéntico de una sola B200.

En texto de un solo flujo y favorable para el especulador, VibeQwen supuestamente generó 1.792 tokens de salida por segundo. El despliegue de vLLM produjo 943 tokens de salida por segundo bajo las mismas condiciones de prueba comunicadas.

Esa diferencia dio lugar a la mejora destacada del 90%. “Favorable para el especulador” describe una salida repetitiva o estructurada en la que un decodificador especulativo puede proponer varios tokens probables para verificarlos en paralelo.

El tiempo hasta el primer token, o TTFT, cayó de 28 milisegundos con vLLM a 12 milisegundos con VibeQwen. TTFT mide el retraso entre enviar una solicitud y recibir el primer token generado.

Baseten caracterizó ese cambio como una mejora de 2,33 veces. La menor demora importa para asistentes interactivos, autocompletado de código e interfaces de voz, donde los usuarios perciben de inmediato la pausa inicial.

VibeQwen también supuestamente lideró bajo tráfico más intenso. Con una concurrencia de 32, una réplica generó 10.307 tokens de salida por segundo, frente a los 6.030 de vLLM.

Eso representó un rendimiento agregado de salida un 71% mayor. El resultado sugiere que la ventaja del motor no se limitó a una prueba aislada con un solo usuario, aunque solo cubrió un nivel de concurrencia comunicado.

La comparación utilizó vLLM 0.25.1, que Baseten identificó como la versión actual cuando comenzó el experimento. El historial de versiones del proyecto muestra que esa versión era una actualización de parche con dos correcciones de errores específicas.

Baseten no afirmó que todos los modelos, distribuciones de prompts o GPU fueran a producir el mismo margen. Los resultados publicados se refieren a esta combinación concreta de modelo, hardware y carga de trabajo.

Esa distinción debería guiar la interpretación de las cifras por parte de los compradores. Una ventaja del 90% en texto seleccionado es una evidencia significativa de margen de optimización, pero no supone una mejora del 90% en el servicio general de IA.

Por tanto, el benchmark cambia la cuestión competitiva. Los equipos ahora deben preguntarse si un runtime ampliamente compatible sigue siendo el mejor destino para una carga de trabajo estable y de gran volumen.

Por qué un agente de programación pudo encontrar tanto margen de optimización

La optimización de inferencia se adapta a los agentes de programación porque la velocidad, la calidad de salida y el comportamiento del hardware pueden evaluarse mediante feedback medible.

Baseten adaptó ideas de MetaInfer, un sistema experimental que trata a un LLM como un compilador para software de inferencia. En lugar de mantener un motor para cada entorno, el sistema genera software compacto en torno a restricciones explícitas de ejecución.

El proyecto MetaInfer combina agentes de programación con una base de conocimientos de contratos. Esa base registra restricciones, pruebas, patrones que funcionan y lecciones de intentos fallidos.

Un agente puede proponer una implementación, compilarla, ejecutar un conjunto de pruebas de corrección, medir el rendimiento y revisar el código. Cada ciclo devuelve una señal más clara que la que ofrecen muchas tareas de software convencionales.

Un rediseño visual, por ejemplo, depende en parte del juicio humano. Un motor de inferencia ofrece mediciones precisas como latencia, rendimiento, utilización de GPU, consumo de memoria y precisión de salida.

Esa claridad hace práctica la optimización de larga duración. Un agente no necesita convencer a un revisor de que un candidato parece más rápido. Debe superar una referencia numérica mientras satisface controles de corrección predefinidos.

Baseten proporcionó a Claude Code acceso a los materiales de MetaInfer, los pesos del modelo y una estación de trabajo B200 mediante SSH. También suministró el modelo de precisión completa como oráculo de precisión, es decir, una referencia fiable para comprobar la calidad de salida.

El objetivo inicial era exigente. Baseten pidió al agente superar a vLLM en un 20% en las métricas de rendimiento sin perder precisión frente a la referencia NVFP4.

Claude Code podía desplegar candidatos en Baseten y ejecutar AIPerf contra cada endpoint. AIPerf es un generador de cargas de trabajo que mide el comportamiento de modelos desplegados, en lugar de limitarse a cronometrar un kernel aislado.

Rushefsky afirma que el proceso se prolongó aproximadamente una semana. Consumió alrededor de 1.700 millones de tokens, en su inmensa mayoría de entrada en caché, y aproximadamente 200 horas de B200.

El motor supuestamente alcanzó la paridad con vLLM durante los primeros días. Baseten permitió que el sistema siguiera explorando, lo que produjo los márgenes finales más amplios.

La supervisión humana no desapareció. Rushefsky redirigió ocasionalmente al sistema cuando se centraba demasiado en una única forma de tráfico.

Claude Code también se detenía cuando los cambios propuestos alteraban las salidas numéricas. Baseten terminó aceptando diferencias sutiles respecto a su referencia NVFP4 cuando la precisión global frente al modelo BF16 seguía siendo al menos igual de sólida.

BF16, o bfloat16, conserva un rango numérico y una precisión mayores que un formato de cuatro bits. Compararlo con una implementación BF16 puede revelar si los cambios de cuantización o de kernel perjudican la calidad del modelo.

Estos controles explican por qué esto fue más que un prompt prolongado de generación de código. Baseten construyó un entorno en el que el agente podía actuar, observar resultados, conservar conocimiento útil y encontrarse con controles antes de aceptar cambios arriesgados.

El experimento también se apoyó en implementaciones abiertas. Baseten permitió que el agente inspeccionara vLLM y TensorRT-LLM, incluidos kernels preoptimizados cuando resultaba apropiado.

Esta decisión hace que el proyecto sea más relevante para la ingeniería de producción, pero menos útil como prueba de una invención algorítmica sin asistencia. VibeQwen representa integración y especialización dirigidas por agentes a través de componentes existentes y de nueva creación.

El resultado sigue siendo notable. Los ingenieros llevan mucho tiempo utilizando perfiles, benchmarks y sistemas de autoajuste. Aquí, un LLM supuestamente coordinó decisiones entre kernels, lógica del motor, comportamiento de serving, despliegue y validación.

Los motores especializados presionan a los runtimes de propósito general

La competencia principal no es VibeQwen contra vLLM como productos. Es la especialización frente a la generalidad como estrategia de ingeniería.

vLLM, SGLang y TensorRT-LLM resuelven un amplio problema de compatibilidad. Deben admitir muchas arquitecturas, formatos de cuantización, aceleradores, patrones de batching, API y requisitos operativos.

Esa amplitud crea un enorme valor práctico. Un equipo puede desplegar un modelo nuevo sin tener que construir primero un runtime para cada capa, kernel o patrón de serving inusual.

También genera abstracciones. Planificadores, ejecutores de modelos, capas de compatibilidad, rutas de respaldo y kernels configurables añaden ramas que un motor de propósito único podría eliminar.

La tesis de MetaInfer es que esas abstracciones dejan rendimiento sobre la mesa. Una vez que un despliegue se estabiliza, un agente puede especializar el motor en torno a sus restricciones exactas.

VibeQwen se centró en Qwen-3.6-35B-A3B en NVFP4 sobre una B200. No necesitaba conservar una ruta elegante para modelos no relacionados o aceleradores antiguos.

Un motor especializado puede fusionar operaciones que siempre se producen juntas. Puede eliminar conversiones, transferencias de memoria, comprobaciones en tiempo de ejecución e interfaces genéricas que no sirven a la carga de trabajo seleccionada.

El trabajo anterior de optimización de kernels de Baseten ilustra el espacio de búsqueda disponible. Sus agentes supuestamente combinaron profiling a nivel de modelo con experimentación por kernel en modelos de difusión y de lenguaje.

En esos proyectos, los cambios útiles incluyeron preempaquetar escalas constantes, fusionar normalización con cuantización y eliminar operaciones intermedias de memoria. Estas técnicas reducen el trabajo sin cambiar el cálculo previsto del modelo.

El experimento VibeQwen extendió ese razonamiento a toda la pila de serving. Un endpoint de producción implica más que una multiplicación de matrices rápida.

Las solicitudes deben entrar mediante una API, pasar por planificación y batching, ejecutar kernels del modelo, transmitir tokens y compartir memoria limitada de GPU. Optimizar un único kernel puede dejar intacto el cuello de botella dominante.

Un agente de programación puede investigar las interacciones entre estas capas. También puede ejecutar varios experimentos sin fatigarse ni apegarse a una implementación diseñada manualmente.

Esta presión no vuelve obsoletos a los motores de propósito general. En cambio, podría cambiar su lugar en el ciclo de vida de un despliegue.

Un equipo podría comenzar con vLLM porque ofrece compatibilidad, mantenimiento activo y una interfaz de serving conocida. Cuando el tráfico se vuelve predecible, un agente podría generar una rama especializada para ese perfil de producción.

El motor general seguiría siendo la referencia y el respaldo. El motor personalizado gestionaría cargas de trabajo en las que la latencia ahorrada o el mayor rendimiento justifiquen su carga de mantenimiento.

Esto se parece a la compilación guiada por perfiles, pero el objetivo de optimización incluye el comportamiento de la aplicación y la infraestructura de serving. El agente explora código fuente, kernels, configuración de runtime y decisiones de despliegue.

Este enfoque también puede aumentar la presión sobre los motores consolidados para que expongan más puntos de especialización. Un runtime modular podría permitir a los agentes optimizar rutas seleccionadas sin sustituir todo el sistema de serving.

vLLM no está quieto. Sus versiones cambian regularmente los ejecutores de modelos, la decodificación especulativa, el soporte de cuantización y las rutas de hardware.

Por tanto, el benchmark VibeQwen de Baseten debe leerse como una instantánea de una competencia en movimiento. La referencia puede mejorar, mientras que los descubrimientos reutilizables de VibeQwen podrían terminar incorporándose a runtimes más amplios.

El cambio duradero es estratégico. El rendimiento de propósito general ya no es necesariamente la etapa final de optimización para cargas de trabajo valiosas.

La afirmación del 90% tiene límites importantes

El benchmark es lo bastante creíble como para investigarlo, pero demasiado limitado y basado en autoinformes como para respaldar una conclusión universal sobre el rendimiento.

La principal preocupación es la selección de la carga de trabajo. Baseten afirma que el resultado del 90% provino de texto estructurado y repetitivo, favorable para su especulador.

La decodificación especulativa acelera la generación al proponer varios tokens futuros y verificarlos en conjunto. Su eficacia depende de la frecuencia con la que esas propuestas coinciden con lo que generaría el modelo objetivo.

El código estructurado, las plantillas y los datos repetitivos pueden producir tasas de aceptación elevadas. La prosa abierta, los idiomas poco comunes, la escritura creativa o un contexto que cambia rápidamente pueden comportarse de forma distinta.

Baseten informó que VibeQwen lideró en todos los patrones de tráfico que probó. Sin embargo, el resumen público no ofrece suficientes datos granulares para reconstruir cada distribución de prompts y tasa de aceptación.

El benchmark también procede de la empresa que desarrolló y aloja el motor. Ninguna parte independiente ha reproducido los resultados de VibeQwen con hardware y pesos de modelo idénticos.

Eso no invalida las mediciones. Limita la afirmación a “Baseten afirma” hasta que el código, los fixtures de prueba o los resultados de terceros permitan una replicación directa.

El estándar de precisión merece una cautela similar. Baseten empezó exigiendo que no hubiera pérdida de precisión frente a una referencia NVFP4.

Durante la optimización, el equipo permitió pequeñas diferencias numéricas siempre que la precisión agregada frente a la línea base BF16 se mantuviera como mínimo igual de buena. Es un compromiso de ingeniería razonable, pero exige una evaluación detallada a nivel de tarea.

Una puntuación media puede ocultar regresiones en dominios concretos. Las empresas necesitarían pruebas que cubran sus propios prompts, llamadas a herramientas, salidas estructuradas, comportamiento de seguridad y cargas de trabajo de contexto largo.

La fiabilidad operativa es otra cuestión abierta. Una ejecución de benchmark no mide meses de actualizaciones de producción, solicitudes malformadas, cambios en el tokenizador, actualizaciones de controladores o longitudes de secuencia poco habituales.

Los motores generales se ganan la confianza en parte mediante un uso extendido. Sus casos límite son detectados y corregidos por una base más amplia de colaboradores y clientes.

Un motor personalizado concentra la responsabilidad. La misma especialización que elimina sobrecarga puede crear supuestos frágiles sobre formas, lotes, precisión o comportamiento del hardware.

El coste de desarrollo también importa, incluso sin asignarle un precio público. Según los informes, VibeQwen consumió unas 200 horas de B200 y 1.700 millones de tokens de modelo.

Esos recursos pueden justificarse para una carga de trabajo grande y persistente. Son menos atractivos cuando un modelo cambia cada semana o el tráfico sigue siendo demasiado reducido para recuperar el esfuerzo de ingeniería.

El presupuesto de iteración del experimento también complica la comparación directa. vLLM debe repartir su trabajo de desarrollo entre muchos usuarios, modelos y dispositivos.

Claude Code dedicó una semana a optimizar un único objetivo. Por tanto, la ventaja de VibeQwen demuestra tanto el valor del esfuerzo concentrado como la superioridad del software escrito por agentes.

El segundo experimento de Baseten ofrece indicios alentadores, pero incompletos, sobre la reutilización. La empresa aplicó su base de conocimiento ampliada a un servidor de segmentación de imágenes SAM 3.1.

Ese sistema, llamado Sammie, procesó supuestamente 91 imágenes por segundo en un H100. Baseten afirma que esto superó en un 50% al servidor de referencia de Meta tras varios días y aproximadamente 200 millones de tokens.

El modelo, la GPU, la arquitectura y la línea base diferían todos de VibeQwen. Baseten también señaló la ausencia de un experimento de control.

Por tanto, Sammie sugiere que el conocimiento acumulado ayudó, pero no aísla la contribución de la base de conocimiento. Una finalización más rápida podría deberse a una carga de trabajo más sencilla u otras diferencias de procedimiento.

La lectura más prudente no es ni el rechazo ni la celebración. VibeQwen ofrece una señal seria de que los agentes de programación pueden coordinar una optimización profunda de sistemas.

Aún no demuestra que las empresas puedan generar motores personalizados fiables bajo demanda, conservarlos a través de actualizaciones de modelos y superar de forma consistente a los runtimes mantenidos por expertos.

Por qué el resultado importa más allá de un despliegue de Qwen

La oportunidad más amplia es un proceso de despliegue en el que la optimización comienza después de conocer el modelo, el hardware y el patrón de tráfico.

Los marcos de inferencia tradicionales deben tomar decisiones de diseño antes de conocer la carga de trabajo exacta de cada usuario. Los motores construidos por agentes invierten esa secuencia.

Parten de los hechos del despliegue. Estos pueden incluir el modelo seleccionado, las longitudes de prompt esperadas, la distribución de salida, los objetivos de concurrencia, los requisitos de precisión y el tipo de acelerador.

Un asistente empresarial de programación ofrece un ejemplo útil. Sus salidas suelen contener sintaxis, sangría, llamadas comunes a bibliotecas y convenciones de proyecto repetidas.

Esa regularidad puede favorecer la decodificación especulativa. Un TTFT bajo también mejora la sensación interactiva de la finalización de código en línea.

Un sistema de voz tiene otra prioridad. Puede aceptar un menor rendimiento total si el primer token llega rápido y la generación se mantiene lo bastante estable para un habla natural.

Un servicio de resumen por lotes puede priorizar en cambio el rendimiento agregado. Puede tolerar un primer token más lento cuando miles de documentos comparten rangos de entrada y salida predecibles.

Los runtimes generales deben acomodar los tres casos. Un motor especializado puede optimizarse para uno solo.

Este enfoque podría flexibilizar la selección de modelos. Un modelo que antes no cumplía un objetivo de latencia podría volverse viable tras una optimización específica para la carga de trabajo.

Esa posibilidad afecta a los compradores de infraestructura y a los equipos de aplicaciones. Las comparaciones de calidad de modelos suelen asumir que el software de serving ya ha capturado la mayor parte del rendimiento disponible.

VibeQwen cuestiona esa suposición. Las decisiones sobre el runtime pueden cambiar de forma sustancial qué modelo ofrece la mejor calidad, capacidad de respuesta y capacidad sobre hardware fijo.

Esto es especialmente relevante para los modelos de mezcla de expertos. Qwen-3.6-35B-A3B activa solo una parte de su conjunto total de parámetros para cada token, lo que crea un comportamiento distintivo de enrutamiento y memoria.

Un runtime que conoce la disposición exacta de los expertos y el esquema de cuantización puede dirigirse a esos patrones. Un motor genérico debe conservar rutas para otras arquitecturas.

Baseten ya ha explorado otra vía mediante la decodificación especulativa. Su implementación DFlash mejoró supuestamente el rendimiento de Qwen3-8B al predecir varios tokens en paralelo.

Ese trabajo anterior exigía entrenamiento e implementación específicos para el modelo. VibeQwen, en cambio, enfatiza a un agente que coordina la optimización en torno a un modelo existente y pesos cuantizados.

Ambos enfoques pueden converger. Un agente de optimización podría elegir entre modelos borrador, fusión de kernels, caché, batching y cambios en la disposición de memoria.

Esa búsqueda amplia es valiosa porque los cuellos de botella cambian con la carga de trabajo. Mejorar la velocidad de decodificación puede revelar la sobrecarga del planificador, la latencia de red o el preprocesamiento como la siguiente limitación.

La base de conocimiento reutilizable puede convertirse en el activo más importante. Los kernels exitosos importan, pero los fallos documentados pueden evitar que futuros agentes repitan experimentos costosos.

Una biblioteca creciente de contratos de hardware y reglas de validación podría reducir el trabajo necesario para cada motor nuevo. La prueba de Sammie de Baseten fue un intento temprano de observar ese efecto.

Si la reutilización mejora, la optimización se parecerá menos a un proyecto de consultoría personalizado. Empezará a asemejarse a una fase de compilación automatizada para servicios de IA en producción.

Esa transformación exige registros cuidadosos. Los equipos deben conservar las entradas de benchmark, versiones de compiladores, controladores, kernels, hashes de modelos, suites de precisión y configuración de despliegue.

De lo contrario, un resultado rápido se convierte en un artefacto irrepetible. El agente puede saber cómo alcanzó la puntuación, pero la organización no puede reproducirlo ni auditarlo de forma segura.

Aquí es donde la ingeniería humana sigue siendo central. Los desarrolladores definen objetivos útiles, evitan que se manipulen los benchmarks, eligen los datos de validación y deciden qué compromisos entre rendimiento y calidad son aceptables.

VibeQwen no elimina esa responsabilidad. Permite que un agente de programación explore un espacio de implementación más amplio después de que los ingenieros definan los límites.

Tres señales determinarán si los motores construidos por agentes perduran

La próxima prueba es la repetibilidad entre cargas de trabajo, cambios de ciclo de vida y entornos independientes, no otro récord aislado.

La primera señal es un paquete reproducible de VibeQwen. Los equipos independientes necesitan suficiente código, configuración, datos de prompts y lógica de evaluación para volver a ejecutar la comparación.

La replicación debería abarcar prosa común, código, salida estructurada, varios idiomas, contextos largos y distintos niveles de concurrencia. También debería informar las tasas de aceptación especulativa.

Un resultado amplio reforzaría el argumento de Baseten de que la especialización capturó margen de mejora duradero. Una ventaja considerablemente reducida limitaría el titular a tráfico favorable.

La segunda señal es la supervivencia ante el cambio. Los proveedores de modelos revisan pesos, tokenizadores, recetas de cuantización y requisitos de serving.

NVIDIA también actualiza compiladores, controladores, bibliotecas y generaciones de GPU. Un motor personalizado útil debe absorber esos cambios sin exigir otra semana de reconstrucción frágil.

Habrá que observar con qué rapidez un agente puede portar VibeQwen a otra versión de Qwen o a un acelerador distinto. La comparación debe incluir el tiempo de revisión humana, el presupuesto de cómputo y las regresiones encontradas tras el despliegue.

Una migración rápida y fiable respaldaría la idea de que la base de conocimiento se acumula. Los rescates manuales repetidos sugerirían que los motores personalizados siguen siendo proyectos costosos para especialistas.

La tercera señal es una respuesta de los runtimes de propósito general. vLLM, SGLang y TensorRT-LLM pueden adoptar nuevos kernels, interfaces de especialización o técnicas de ajuste automatizado.

Algunas mejoras de VibeQwen pueden incorporarse a motores compartidos una vez que los mantenedores comprendan las rutas pertinentes. Eso reduciría la brecha directa del benchmark al tiempo que validaría el trabajo de optimización subyacente.

Una respuesta más profunda permitiría a los usuarios generar planes de ejecución especializados dentro de un runtime mantenido. Este modelo híbrido podría preservar la compatibilidad al tiempo que elimina sobrecarga en despliegues fijos.

Puede que el ganador no sea un motor completamente generado ni uno completamente genérico. Podría ser un marco general con límites de especialización controlados por agentes y sólidas rutas de respaldo.

Para los desarrolladores, la lección inmediata es práctica. Traten el software de inferencia como un componente medible, no como un contenedor intercambiable alrededor de los pesos del modelo.

Registren las distribuciones de prompts y salidas antes de elegir objetivos de optimización. Prueben TTFT, latencia de tokens de salida, rendimiento, memoria, precisión y comportamiento de cola mediante solicitudes similares a las de producción.

Para los compradores empresariales, pregunten a los proveedores qué optimizó su benchmark y qué excluyó. Una única cifra máxima de rendimiento dice poco sobre la latencia interactiva, la calidad, la portabilidad o el esfuerzo operativo.

Pregunten también si las mejoras informadas se mantienen con datos variados. El benchmark VibeQwen de Baseten es más útil cuando inicia una evaluación cuidadosa, no cuando la termina.

El experimento ofrece una visión convincente de la ingeniería autónoma de sistemas. También muestra por qué los agentes necesitan pruebas diseñadas con rigor y límites definidos por humanos.

Los próximos uno a tres meses deberían revelar si VibeQwen se vuelve reproducible, portable y mantenible. ¿Qué resultado cambiaría más su plan de despliegue: una replicación independiente, una migración rápida de modelos o una especialización similar dentro de vLLM?