Muestreo particionado por lotes de Qwen4Exp: dentro de vLLM PR #61018, y lo que dice sobre Qwen 4

El número más informativo en la pull request #61018 de vLLM es una pérdida: 1,5 %. Ese es el límite superior que el autor atribuye a su propio cambio — aproximadamente entre 0,6 y 0,8 milisegundos ahorrados de un paso promedio de 42 milisegundos, medidos en una máquina que no es suya, en un parche que no puede ejecutar en absoluto. La pull request, titulada «[Modelo] Qwen4Exp: soporte para muestreo con sharding por lotes (compute_logits_local)» y abierta el 2026-10-10 por el colaborador kimseunghyun-kr, añade tres líneas de código del modelo a dos archivos para que la arquitectura Qwen4Exp pueda tomar una ruta de muestreo que vLLM lanzó en agosto. Es un borrador. Son 14 líneas de código del modelo más 57 líneas de pruebas. Y aun así vale la pena leerla con atención, por aquello que esas tres líneas están parcheando: Qwen4Exp es la arquitectura dentro de Qwen3.8-Flash-Next, el modelo de pesos abiertos de 125 mil millones de parámetros que el proveedor publicó el 2026-08-24 como «una vista previa experimental de la arquitectura que sustentará Qwen4» — y un error de dos rutas en la mitad exclusiva de texto de esa arquitectura es exactamente el tipo de detalle que solo se capta observando la capa de servicio en lugar de la publicación de lanzamiento.

Para que no haya ambigüedad en el planteamiento, porque eso importa aquí: Qwen 4 en sí no se ha publicado. El proveedor nombró cuatro niveles de Qwen 4 —Qwen 4 Max, Flash, Plus y 27B— en su conferencia Apsara el 22 de septiembre de 2026, y no ha publicado pesos, ni identificador, ni precio, ni longitud de contexto, ni benchmark para ninguno de ellos. Nada de lo que sigue es un lanzamiento. Esto es un informe de lo que sabemos hasta ahora sobre una única pull request en borrador, y todo lo que contiene un número es o bien una marca temporal que puedes verificar, una cifra que el colaborador escribió en el cuerpo de su propia PR, o un valor leído de un archivo público de configuración de modelo.

Qué es el muestreo con fragmentación por lotes, en un párrafo

El paralelismo tensorial divide los pesos de un modelo entre varias GPU; la proyección del vocabulario es el tensor individual más ancho de la pila, por lo que cada rank normalmente calcula solo su propia porción del vocabulario, y luego todos los ranks hacen un all-gather, de modo que cada uno termina conteniendo los logits completos de todas las solicitudes del lote. El muestreo fragmentado invierte ese intercambio. En lugar de replicar el vocabulario entre los ranks, fragmenta el lote: cada rank muestrea una porción de las solicitudes, y los ranks intercambian entre sí porciones del vocabulario mediante un all-to-all. La propia documentación de la CLI de vLLM describe el flag de forma clara —"Cada rank muestrea una porción del lote en lugar de que todos los ranks muestreen todo él"— y establece las restricciones: --enable-batch-sharded-sampling tiene un valor predeterminado de False, requiere que tensor_parallel_size sea mayor que 1, al menos tensor_parallel_size secuencias máximas, y un max_logprobs no negativo. La última línea de esa documentación es el gancho del que pende este pull request: "Los modelos se adhieren implementando compute_logits_local".

La función en sí no es nueva. vLLM la fusionó como el PR #50465 —"[Model Runner V2] batch-sharded sample", de Giancarlo Delfin— el 2026-08-24, el mismo día en que se publicaron los pesos de Qwen3.8-Flash-Next. La motivación allí era la memoria y la latencia: materializar los logits objetivo completos cuesta del orden de tamaño de lote × (tokens especulativos + 1) × tamaño del vocabulario, y el sharding reduce esa asignación por un factor igual al grado de paralelismo tensorial, a la vez que permite que el trabajo de top-k y top-p del muestreador se ejecute en paralelo. Es el paso habilitante, no el destino: el propio texto del PR señala los draft-logits fragmentados como trabajo futuro.

Por qué tres líneas eran todo el trabajo

Aquí está el defecto real, y es uno bueno porque es invisible desde fuera del código. La implementación de Qwen4Exp de vLLM se distribuye como dos clases. Qwen4ExpForConditionalGeneration es el envoltorio de visión-lenguaje —una torre de visión Qwen3-VL añadida al modelo de lenguaje— y Qwen4ExpForCausalLM es la ruta solo de texto. El envoltorio hereda compute_logits_local de Qwen3_5ForConditionalGeneration, que reenvía la llamada a language_model.compute_logits_local. Pero la clase del modelo de lenguaje a la que apuntaba el envoltorio nunca definió ese método.

Entonces, los dos caminos estaban en estados diferentes. Un despliegue de visión-lenguaje de Qwen3.8-Flash-Next podría tomar la ruta fragmentada; uno de solo texto no podría, porque el método al que delegaba el wrapper no existía. La solución es un método, idéntico en las copias de NVIDIA y AMD del archivo del modelo:

• El método devuelve self.logits_processor(self.lm_head, hidden_states, skip_gather=True) — el fragmento de vocabulario propio del rank, sin gather ni materialización del vocabulario completo en ningún rank.

• Sigue lo que el PR llama «el mismo patrón de 3 líneas que Qwen3.5 y MiniMax M3», lo cual vale la pena detenerse a considerar: otras dos familias de modelos del mismo repositorio ya se habían adherido. Qwen4Exp era simplemente la que no lo había hecho.

El archivo de prueba es donde la honestidad del parche es más fácil de comprobar, y donde sus límites son más fáciles de ver. Tiene 57 líneas, está parametrizado sobre los módulos tanto de NVIDIA como de AMD, y no descarga un modelo. La función auxiliar construye la clase con object.__new__, sustituye nn.Identity por la cabeza del modelo de lenguaje, e instala un procesador de logits falso que devuelve su entrada más uno mientras registra cómo se lo llamó. La primera prueba afirma que un 4.0 que entra sale como 5.0 y que la llamada registrada llevaba skip_gather=True. La segunda envuelve el modelo de lenguaje en la clase de generación condicional y afirma que la delegación se produce. Eso es una prueba real del cableado y una prueba de nada más — no se ejecuta ningún kernel, no se cruza ningún límite de rango, y el número de GPUs implicadas es cero.

Ambos hechos se declaran en el PR en lugar de quedar enterrados. El propio docstring del archivo de pruebas llama a Qwen4Exp «un pequeño doble de prueba solo para CPU». La sección de validación del autor señala que no pudo importar el modelo en su configuración de macOS en absoluto, porque la compilación de transformers que tenía no incluía un Qwen4ExpConfig. La ejecución en CUDA seguía pendiente. El benchmark de extremo a extremo —conjunto de datos agéntico de MLPerf, 20 sesiones concurrentes, tres brazos de 60 minutos— seguía pendiente. La propia ruta de logits del drafter de MTP está marcada como sin verificar. LoRA ya es rechazado por el flag en el upstream, así que queda fuera del alcance en lugar de ser una regresión. También hay una línea que revela que el borrador se escribió con ayuda de IA, y el tráiler del commit nombra a Claude Opus 5.5 como coautor, que es el tipo de divulgación que debería ser normal en un stack de este tamaño y que en su mayoría no lo es.

La estimación del 1,5%, y las mediciones junto a las que se encuentra

La estimación del colaborador es una traza de nsys en 16 sesiones concurrentes en Qwen3.8-Flash-Next-FP8 con paralelismo tensorial 8 y paralelismo de expertos en ocho tarjetas A100-SXM4-40GB: alrededor de 1,6 milisegundos de un paso de 42 milisegundos, reducido a aproximadamente un tercio de eso, para una ganancia de extremo a extremo de 1,5 a 2 %. Su titular es la aritmética — 0,6 a 0,8 ms sobre 42 ms. Nótese lo que está asociado a eso: 42 ms es una cifra de latencia entre tokens, así que una reducción del 1,7 % es una reducción del 1,7 % en el tiempo de generación de tokens, no una afirmación de rendimiento en abstracto.

La comparación honesta es contra las propias cifras fusionadas de la funcionalidad principal, porque alguien con el hardware las midió de extremo a extremo. En las ejecuciones de Speed-Bench 2K/2K publicadas en el PR #50465, el muestreo con particionado por lotes llevó a DeepSeek V4 con DSpark, con 7 tokens especulativos y concurrencia 64, de 2,62 a 2,66 solicitudes por segundo —una ganancia de rendimiento del 1,53 %—, con una caída del 3,09 % en la mediana de la latencia entre tokens y un aumento del 1,45 % en el tiempo hasta el primer token. En MiniMax M3 con DSpark y 8 tokens especulativos, el rendimiento de solicitudes aumentó un 5,38 % y la mediana de TPOT cayó un 8,33 %, de 15,61 a 14,31 milisegundos. Y el mismo plan documenta dónde no ayuda: con concurrencia de 4 a 16, las ejecuciones resultaron planas o ligeramente negativas, con la rama de concurrencia 16 bajando un 0,54 % en rendimiento y un 1,89 % en longitud de aceptación.

Ese patrón es lo que hay que llevarse. El muestreo fragmentado compensa cuando el muestreo es intensivo y el lote es amplio —alta concurrencia, muchos tokens especulativos, top-k y top-p haciendo trabajo real—, y cuesta un poco cuando el lote es lo bastante pequeño como para que la comunicación all-to-all sea pura sobrecarga. Una estimación del 1,5 % para un modelo que opta por habilitarlo es coherente con eso, no está en tensión con ello: las cifras del 5,38 % y el 8,33 % pertenecen a modelos diferentes con presupuestos especulativos distintos, y el modelo de este PR tiene su propia configuración, su propio vocabulario de 248.320 tokens y su propia ruta de decodificación especulativa.

Nada de esto está auditado. Los números del PR principal son ejecuciones emparejadas de un solo colaborador en un solo nodo; los números de la prueba de humo que aparecen aquí son una traza sobre hardware que el autor no tiene, de una revisión del parche que, según él, se midió con solo 16 sesiones. Una medición de un solo colaborador y una sola configuración es una señal útil sobre la dirección y una base pobre para un plan de capacidad. La razón por la que vale la pena escribir sobre el tema es la dirección, no el decimal.

Lo que el clúster de parches circundante dice sobre Qwen4Exp

Un solo PR en borrador no sería una historia. La historia es que Qwen4Exp se ha convertido en un objetivo de servicio sostenido en la semana en que esto se integró, y el parche más pequeño de ese grupo es el que hace legible el patrón. En los siete días hasta el 2026-10-10, vLLM incluyó, del mismo contribuyente y de otros: una ruta de caché KV principal en FP8 para atención dispersa en Ampere, con una capacidad de KV 1.83× mayor en ocho A100 y 1.87× mayor en cuatro RTX 3090, y aproximadamente 2.7× las solicitudes con concurrencia 16, a costa de un TPOT de decodificación de flujo único aproximadamente un 6% mayor; una corrección para el padding de MoE W4A4 en paralelismo tensorial 1 y paralelismo de expertos; una ruta de AMD que hace fallback cuando las operaciones de MoE FP8 de AITER no son compatibles y sirve en fp16; una corrección que transporta el estado de convolución corta de PLE a través del modo de alineación; y un kernel de decodificación que desempaqueta bytes e4m3 de a cuatro por registro en sm_80. Uno de ellos, un reajuste del plan QSA LL-GEMM fusionado M=4 de H200, se integró en main el 2026-10-09.

Lee esa lista en su conjunto y dice algo concreto. La arquitectura Qwen4Exp —la que el proveedor no ha publicado— se está ajustando para Ampere, Hopper, ROCm y el fallback de fp16 simultáneamente, en un proyecto que ofrece soporte desde el día cero para modelos que la gente realmente puede descargar. El motivo no es misterioso: Qwen3.8-Flash-Next es un modelo real, descargable y muy usado, y está construido sobre la arquitectura que usará Qwen 4. No se sabe si los pesos de Qwen 4 llegarán alguna vez con este aspecto y el proveedor no ha dicho nada, pero la envolvente de servicio se está ampliando en público, y eso es información verificable, a diferencia de una ventana de octubre a noviembre de la que solo se rumorea.

Parte de la forma arquitectónica también es pública, para quien lee la configuración en lugar del anuncio. La configuración de Qwen3.8-Flash-Next indica un vocabulario de 248.320 tokens repartidos en 48 capas, 512 expertos con 10 enrutados más uno compartido activo por token, con un ancho intermedio de experto de 640, un tamaño oculto de 2.560 y un contexto nativo de 262.144 tokens descrito como extensible a un millón. Es un híbrido: la lista de tipos de capa alterna tres bloques de atención lineal con un bloque de atención completa, y los bloques de atención completa usan la ruta de atención dispersa con un indexador de una sola cabeza que comprime las claves por un factor de cuatro y mantiene un presupuesto de 2.048 posiciones. Hay una tabla de embeddings por capa en la capa 2, un embedding de n-gramas con un vocabulario de 20 millones de entradas —esa es la tabla de 47,7 GiB que otros parches de este clúster están ocupados preparando en el host— y una cabeza MTP de una capa para decodificación especulativa. El propio resumen de la model card es «125B con 6B activados, más 51B de embedding de n-gramas y 4B de MTP». Un vocabulario de 248.320 entradas es la razón por la que vale la pena fragmentar la proyección de logits de entrada.

Lo que esto no cambia para ti

Vale la pena ser exacto, porque un cúmulo de parches tan denso puede leerse como un lanzamiento. Nada de lo anterior está fusionado, y una de sus partes —el trabajo de Ampere FP8 KV cache— no está validada explícitamente en CI porque la CI de vLLM no tiene una A100. No hay ninguna versión publicada de vLLM que puedas instalar hoy que incluya la opción opt-in de muestreo fragmentado de Qwen4Exp. No existe ningún benchmark independiente del comportamiento de servicio de Qwen3.8-Flash-Next bajo ninguno de estos cambios; todas las cifras citadas arriba provienen de los cuerpos de los PR, lo que hace que estén reportadas por colaboradores y no auditadas en el sentido específico de que ningún tercero ha reproducido la ejecución. Y la cifra destacada del PR que dio origen a este artículo es 1,5 %, que es una ganancia real en una pila de serving y no una razón para cambiar la elección de un modelo.

Lo que cambiaría una decisión es una ejecución de servicio completa y auditada, y eso todavía no existe. Las mediciones de ritmo que sí existen para Qwen3.8-Flash-Next quedan totalmente fuera de estos parches: el modelo registra un Intelligence Index de 40 en Artificial Analysis, muy por encima de la mediana de 18 para modelos de pesos abiertos de tamaño similar, y esa cifra es independiente de todo lo que se analiza aquí.

Lo que puedes invocar hoy, y el ángulo de enrutamiento

Aquí es donde el panorama se vuelve práctico para cualquiera que haya leído hasta aquí y quiera usar un modelo alojado en lugar de instrumentar uno. Qwen3.8-Flash-Next no está en el catálogo de OrcaRouter: no es uno de los 205 modelos que enrutamos y aquí no hay ningún endpoint alojado para él. Pero el hermano de producción que previsualiza sí lo está: qwen/qwen3.8-flash, la versión oficial de Qwen3.8-Flash que la propia ficha de modelo del proveedor describe como portadora de más funciones que la vista previa, incluido un contexto de un millón de tokens por defecto y herramientas integradas, está disponible a 0,15 $ por millón de tokens de entrada y 0,47 $ por millón de tokens de salida, trasladados al precio de lista del proveedor sin añadir ningún margen. Para hacer una comparación dentro de la misma familia, qwen/qwen3.8-27bcuesta 0,33 $ y 2,40 $, y qwen/qwen3.8-max2,00 $ y 6,00 $, todos accesibles con una sola clave.

Hay dos razones que importan más de lo habitual para un artículo sobre una arquitectura no lanzada. La primera es el costo de cambio. Si quieres calibrar cómo se siente un modelo de atención dispersa con tu tráfico antes de que Qwen 4 exista, la comparación que quieres hacer es contra qwen/qwen3.8-flash a precio de lista — y hacerlo a través de un router significa que el modelo que estás midiendo y el modelo al que podrías recurrir como respaldo están detrás del mismo endpoint, el mismo SDK y la misma clave, sin un segundo contrato que firmar. La segunda es que cada cambio de serving en este clúster de parches apunta a vLLM autoalojado. Si no estás ejecutando ocho A100s, la capacidad de KV de 1,83× y la mejora del 1,5% en muestreo son cosas de las que lees, no cosas que obtienes. Un endpoint enrutado es la versión de esto que llega sin un paso de compilación: conmutación por error automática si un proveedor se degrada, y un DSL de enrutamiento que te permite colocar una llamada alojada junto a una autoalojada en un único endpoint cuando sí tienes hardware propio que medir.

Lo único que no hay que hacer es leer este artículo como una razón para esperar Qwen 4. No hay fecha. No hay precio. No hay recuento de pesos para el producto real — las cifras anteriores describen la compilación de vista previa, no el producto. Lo que existe es un stack de servicio que se está preparando en público para una arquitectura que, por ahora, solo se puede descargar en forma de vista previa.

La versión corta

Tres líneas que cierran una brecha entre las rutas de solo texto y de visión-lenguaje de un archivo de modelo no son, por sí solas, noticia. Es el tipo de parche que quedaría enterrado en un commit de fusión si alguien tuviera tiempo de revisarlo, y bien podría integrarse en un cambio mayor o cerrarse sin más: las propias directrices de agentes del bot de vLLM, citadas en el PR, indican a los colaboradores asistidos por IA que cierren su trabajo si carece de un beneficio significativo, y 1,5 % es una cifra que invita a esa pregunta. Lo que lo hace digno de atención es lo que documenta: una tabla de n-gramas de 20 millones de entradas, un MoE de 512 expertos con diez expertos activos por token, un híbrido de atención lineal y atención dispersa comprimida, una cabeza especulativa — todo ello ajustándose en NVIDIA y AMD, de Ampere a Hopper, antes de que exista el producto que lo incorpora. Si te importa el envolvente de servicio de Qwen4, los cuerpos de los PR son donde viven actualmente sus especificaciones reales. Si quieres invocar un modelo hoy, Qwen3.8-Flash es el que realmente está ahí.

Una API para más de 200 modelos, conmutación por error automática, DSL de enrutamiento. Explora el catálogo de modelos de OrcaRouter