Cómo ProsGrow aumentó un 132% el rendimiento por lotes de Qwen3

El problema: una cola larga con muy pocas solicitudes activas

Una cola de solicitudes ocupada no garantiza que una GPU realice trabajo útil a toda su capacidad disponible. Con Qwen3-30B-A3B en vLLM 0.25.1, ProsGrow observó que la configuración inicial limitaba qué parte de un lote de prompts cortos podía ejecutarse simultáneamente. Entregaba 17,961 tokens de salida/s pese a disponer de abundante trabajo en cola.

Analizar y ajustar la planificación elevó esa tasa a 41,651 tokens de salida/s: una mejora del 132%, o 2.32×. Se mantuvieron la GPU, el entorno, el checkpoint, la precisión, el número de solicitudes y las especificaciones de prompt/salida. Es una mejora medida frente a la configuración inicial de ProsGrow, no frente a una referencia de vLLM con ajuste óptimo.

Referencia → Ajuste de ProsGrow

La mediana de latencia de las solicitudes también mejoró, de 15.91 a 11.70 segundos, en esta comparación controlada. La mejora identifica capacidad recuperable para esta carga; no demuestra una ventaja general sobre otros motores de inferencia o despliegues completamente optimizados.

Por qué importaba el planificador

ProsGrow separó la carga ofrecida del trabajo que el motor admitía realmente y comparó el rendimiento completado y la latencia con la misma carga. La evidencia apuntó a un cuello de botella de planificación: la configuración inicial no convertía una cola larga en suficiente ejecución simultánea. No permite aislar una aceleración a nivel de kernel.

El trabajo de ingeniería consistió en identificar el componente limitante de esta pila de servicio, evaluar su efecto en condiciones controladas y validar un punto de operación útil. Como el modelo cabe en una GPU, las réplicas independientes ofrecieron una forma práctica de comprobar si la capacidad recuperada en una GPU se trasladaba al nodo completo.

La contrapartida: más concurrencia acaba generando más espera

Una configuración de saturación independiente alcanzó 45,941 y 46,701 tokens de salida/s en dos ejecuciones aisladas, con una mediana de latencia cercana a 20 segundos. Aumentar la carga más allá de ese punto solo añadió un 0.91% de rendimiento en el mismo barrido, mientras la mediana de latencia pasó de 20.04 a 29.85 segundos. Más espera en cola ya no aportaba capacidad significativa.

La memoria también limitó la elección: la sobrecarga del servicio redujo el espacio disponible para la caché de claves y valores. Los prompts cortos dejaban espacio suficiente para la configuración elegida. Los contextos más largos o un objetivo de latencia interactiva requieren su propia evaluación.

De una GPU ajustada a un servicio por lotes con ocho GPU

Con ocho réplicas independientes, dos ejecuciones sincronizadas entregaron 362,812 y 361,679 tokens de salida/s. Utilizamos el resultado menor para estimar la capacidad. Cada ejecución completó las 32,768 solicitudes y los 8,388,608 tokens de salida, sin respuestas fallidas ni más cortas de lo previsto.

La ejecución menor utilizó una ventana común de tiempo real de 23.19 segundos, desde el inicio del primer cliente hasta la última finalización. Contabilizar todo el trabajo dentro de ese intervalo compartido evita inflar el resultado del nodo sumando tasas de réplicas cronometradas por separado.

Cómo se relacionan la mejora local del 132% y la comparación pública del 8.17%

La mejora del 132% anterior mide un ajuste de planificación para solicitudes cortas en cola. La comparación del 8.17% de nuestro informe de capacidades responde a otra pregunta: ¿cómo rinde una ejecución local frente a una referencia pública conservada bajo unas especificaciones de solicitudes más largas?

La ejecución con las especificaciones públicas utilizó solicitudes sintéticas en cola y TensorRT-LLM 1.3.0rc24, frente a 1.1 en la referencia conservada de NVIDIA. Su latencia media por solicitud fue de 173.04 segundos bajo esa cola larga. La página de referencia de NVIDIA es la fuente de la cifra 9,938 capturada el 17 de agosto de 2026; la fila ya no aparecía en nuestra revisión posterior de la fuente. La conservamos como comparación fechada, con la receta pública de rendimiento que define la carga.

El +8.17% corresponde al resultado aislado de una GPU. Ni ese resultado ni la diferencia entre 85,409 y 361,679 tokens/s de nodo aíslan una mejora exclusivamente de software: la última comparación cambia el entorno y las longitudes de solicitud. Estas tasas describen capacidad por lotes; un servicio interactivo necesita su propio objetivo de latencia.

Qué cambia para un cliente

Las colas privadas de generación y los trabajos de datos sintéticos pueden beneficiarse de terminar antes con la capacidad instalada. ProsGrow puede medir la capacidad recuperable del servicio antes de recomendar más GPU.

La configuración de rendimiento elegida requiere una cola larga y acepta una mediana de latencia de aproximadamente 20 segundos. La validación del despliegue debe utilizar el modelo del cliente, su distribución de longitudes, controles de calidad y traza de tráfico. Los asistentes interactivos necesitan su propio objetivo de latencia.

Metodología y limitaciones

• Hardware y software: las pruebas se ejecutaron el 18 de agosto de 2026 en un nodo con ocho GPU NVIDIA RTX PRO 6000 Blackwell Server Edition. El barrido controlado utilizó una GPU. El entorno fue vllm/vllm-openai:v0.25.1, con pesos ModelOpt NVFP4 y caché de claves/valores FP8.
• Modelo y solicitudes: el checkpoint NVIDIA Qwen3-30B-A3B-FP4 fijado utilizó la revisión 2538ded2a4edb247b4d2b4a8ba24e44bd4c017c3. Un prompt repetido de guía técnica con un identificador de solicitud cambiante produjo entre 63 y 66 tokens de entrada según la API. La temperatura fue cero, el pensamiento estaba desactivado y todas las respuestas alcanzaron el límite de 256 tokens.
• Medición: el rendimiento es el número de tokens de salida completados dividido por el tiempo observado por el cliente, incluido el procesamiento del prompt y la sobrecarga de HTTP local. La comparación del 132% utiliza una medición por configuración. La configuración de saturación elegida tiene dos repeticiones aisladas y dos sincronizadas del nodo; estas últimas duran solo unos 23 segundos cada una.
• Calidad y operación: una longitud de salida fija verifica la cantidad de trabajo generado, no la calidad de la tarea. Son mediciones locales de saturación sobre un checkpoint anterior de Qwen3, no una prueba prolongada en producción, un SLA de cliente ni una prueba de equivalencia de calidad. Los prompts representativos, la latencia p95/p99, la sobrecarga de red, los fallos y la calidad del dominio siguen siendo criterios de aceptación en producción.

La comparación histórica con vLLM 0.23 también queda fuera de la mejora del titular porque no se conservaron sus solicitudes originales de prompts sin procesar. La comparación local con la misma versión proporciona la referencia controlada.

Despliegue privado de Qwen3 e inferencia por lotes con vLLM

Los equipos que planifican un despliegue privado de Qwen3 pueden usar este benchmark para analizar la capacidad de inferencia por lotes, la utilización de GPU y la espera aceptable en cola. Los tokens de salida por segundo miden el rendimiento de generación completada, mientras que la latencia recoge cuánto espera y se ejecuta un trabajo. Un despliegue de vLLM debe dimensionarse según la mezcla de solicitudes y el objetivo de entrega del cliente.