El soporte de vLLM para Nanbeige4.2-3B está llegando: el modelo agente 3B en bucle de BOSS Zhipin deja atrás su era de solo fork

Nanbeige4.2-3B — el modelo agéntico compacto que el Laboratorio Nanbeige de BOSS Zhipin lanzó a finales de julio de 2026 — está a punto de poder servirse por primera vez en una instalación estándar de vLLM. Una solicitud de cambios abierta el 9 de septiembre de 2026 añade la arquitectura al registro de modelos de vLLM a través del backend de transformers. Si se fusiona, «vllm serve Nanbeige/Nanbeige4.2-3B» se convierte en un comando estándar en lugar de un ritual de bifurcación del proveedor. Eso es un cambio real en lo que puede hacer quien se autoaloja: durante las seis semanas desde que se publicó el modelo, todos los motores de servicio que enumera su tarjeta de modelo — vLLM, SGLang, llama.cpp, Ollama — han apuntado a una bifurcación mantenida por Nanbeige, no a una instalación sin modificar.

El modelo en sí no es la noticia; se puede descargar desde la última semana de julio. La noticia es que la era del fork como única opción está terminando, y termina esta semana. SGLang fusionó una implementación nativa de Nanbeige4.2 en su rama principal el 5 de septiembre, y la pull request de vLLM se abrió cuatro días después. Ambos son soporte upstream, de instalación estándar, para una arquitectura que todos los motores trataban anteriormente como un caso especial. A continuación, todo está etiquetado: qué hacen realmente las pull requests, qué está verificado frente a lo que sigue abierto, las afirmaciones de benchmark del proveedor y los números independientes que las ponen en contexto.

¿Qué cambió esta semana, precisamente?

El pull request de vLLM es vllm-project/vllm #56071, «[Model] Add support for Nanbeige4.2 (transformers backend)», abierto el 9 de septiembre por un ingeniero de Nanbeige y aún abierto al momento de escribir esto. Es deliberadamente pequeño: dos archivos. El primero añade una línea al registro de modelos de vLLM que asigna el nombre de arquitectura de Hugging Face NanbeigeForCausalLM a TransformersForCausalLM, el respaldo genérico de vLLM que ejecuta un modelo a través del backend de transformers. El segundo añade un NanbeigeModelArchConfigConvertor, cuyo único trabajo es decirle a vLLM cuántas capas presupuestar: devuelve el num_hidden_layers de la configuración multiplicado por num_loops, porque el transformer en bucle de Nanbeige repite su pila de capas y vLLM debe dimensionar su caché KV e instancias de atención en consecuencia.

Dos detalles del hilo de revisión importan para cualquiera que siga esto. Primero, el mapeo del registro es lo que hace que el modelo se ejecute automáticamente a través del backend de transformers — un mantenedor de vLLM señaló que una vez que el mapeo existe, la bandera explícita --model-impl transformers se vuelve redundante, y que el trabajo restante antes de la fusión es una entrada de documentación y una prueba de CI del mapeo de registro. Segundo, los revisores señalaron que un cambio reciente fusionado en vLLM (PR #54941) puede hacer innecesario el convertidor de conteo de capas, al detectar módulos de atención directamente en lugar de inferirlos a partir de un conteo de capas. En términos simples: la corrección puede volverse más simple antes de fusionarse, no más complicada.

La ruta de vLLM importa más por lo que no es. No es el primer intento de integrar Nanbeige4.2 en vLLM de forma nativa. El PR #49433, abierto por el mismo ingeniero a finales de julio como una implementación nativa desde el día cero, se cerró el 9 de septiembre — el mismo día en que apareció el PR del backend de transformers — después de que los mantenedores argumentaran que una implementación de modelo a medida era más trabajo del que la arquitectura justificaba y señalaran al backend de transformers como alternativa. La conclusión para los lectores: el soporte upstream de vLLM está llegando por la vía de la compatibilidad, no mediante una implementación nativa ajustada a mano, y esa distinción tiene consecuencias reales de rendimiento que se analizan a continuación.

El modelo que necesitaba todo este manejo especial.

Para entender por qué Nanbeige4.2-3B rompió los supuestos de todos los entornos de ejecución, ayuda saber qué es el modelo. Es un modelo de aproximadamente cuatro mil millones de parámetros, con tres mil millones de parámetros no incrustados, publicado bajo Apache-2.0 en inglés y chino, y dirigido directamente a cargas de trabajo de agentes: agentes de código, automatización de oficina, uso de herramientas y operación de terminal. El informe técnico (arXiv 2607.22083, con fecha del 24 de julio de 2026) describe el preentrenamiento desde cero con 28 billones de tokens, seguido de una receta de SFT más tres etapas de RL construida en torno a la interacción con el entorno del mundo real. La ventana de contexto llega hasta 262 144 tokens. Todo eso es comprobable.

La parte que no es ordinaria es la arquitectura. Nanbeige4.2-3B utiliza un "{{1}}Transformador en Bucle{{/1}}": la misma pila de 22 capas de transformador se ejecuta dos veces, por lo que un modelo de 3B parámetros realiza aproximadamente el doble de cómputo por token que un 3B convencional sin añadir pesos. Así es como el laboratorio concilia un número pequeño de parámetros con afirmaciones de referencia que superan su categoría de peso — el modelo efectivamente obtiene una segunda pasada sobre sus propias representaciones, y la configuración expresa esa reutilización como un {{2}}num_loops de 2 sobre 22 capas ocultas (44 etapas de atención efectivas){{/2}}. La contrapartida es que a cada motor de inferencia se le debe indicar cómo manejar una pila de capas que se usa dos veces: cómo indexar la atención para la caché KV y los gráficos CUDA, cómo dimensionar la caché, cómo transmitir los pesos. Un motor estándar construido en torno a transformadores de una sola pasada hacia adelante no tiene idea de qué hacer con ello, por eso el código de modelado personalizado viene incluido en el repositorio y requiere {{3}}trust_remote_code=True{{/3}} en Hugging Face Transformers.

Ese código personalizado es también donde viven las mayores asperezas del modelo. Un informe independiente (arXiv 2608.13987, mediados de agosto) documentó cinco errores que impedían que el checkpoint publicado se cargara directamente en Hugging Face Transformers — entre ellos un búfer de embedding de posición rotatoria silenciosamente puesto a cero y llamadas a APIs de caché eliminadas — y las publicaciones de la comunidad describieron soluciones alternativas, como use_cache=False, para que el modelo pudiera ejecutarse siquiera. Esos eran solucionables, y ahora circulan checkpoints y bancos de pruebas parcheados, pero el patrón es la cuestión: esta es una arquitectura inteligente que ha estado pagando un impuesto inusual en fricción de despliegue desde el primer día.

Los números, proveedor e independiente

La afirmación principal sobre los benchmarks, tomada directamente del informe técnico, es que Nanbeige4.2-3B supera a modelos abiertos más grandes — Qwen3.5-9B y Gemma4-12B — en evaluaciones de agentes. La cifra insignia es SWE-Bench Verified con 63.6 frente a los 53.1 de Qwen3.5-9B y los 44.2 de Gemma4-12B. El informe también enumera GPQA-Diamond con 87.4, HMMT-Feb-2026 con 82.8, Terminal-Bench 2.0 con 44.1 y SWE-Bench Pro con 46.9. Ninguna de estas cifras ha sido reproducida de forma independiente en el entorno de evaluación elegido por el proveedor, y deben interpretarse como el propio relato del laboratorio sobre su modelo — el mismo relato que la ficha del modelo resume como situándose en lo más alto del ranking de modelos pequeños de Artificial Analysis.

Lo más parecido a una verificación independiente hasta ahora proviene de una superficie completamente distinta. En una prueba comparativa en dispositivo de Artificial Analysis × Liquid AI, ejecutada en un iPhone 17 Pro y publicada a finales de agosto, una versión de 4 bits de Nanbeige4.2-3B empató en el puntaje promedio más alto entre 33 modelos funcionales de menos de 8 GB con un contexto de 16K (63, a la par de LFM2.5-2.6B y por delante de varios modelos de clase 9B), y en un contexto de 64K obtuvo 65, solo superado por el 66 de Ling 3.0 Tiny. Su perfil por prueba era llamativo: el mejor en MATH-500 (96%) y fuerte en llamadas de función (76% en BFCL), pero una débil tasa de no alucinación de 33% en AA-Omniscience — y, de manera decisiva para el uso real, lento. Generó aproximadamente 14 tokens por segundo y tardó 21.4 segundos y 4.0 GB en responder a un prompt de 1,024 tokens; bajo un límite de respuesta de 60 segundos, su puntaje promedio se desplomó de 63 a 18. En otras palabras: la calidad que supera a los modelos de 9B es real, y también lo es el costo de la arquitectura en bucle que la produce.

Lo que el soporte upstream realmente te ofrece

Al juntar los dos eventos upstream, el panorama práctico para quien se autoaloja es sencillo. Si ejecutas SGLang, Nanbeige4.2-3B ya se puede servir desde una instalación estándar gracias al soporte fusionado en la rama principal — sin fork, con los analizadores de llamada a herramientas y de razonamiento del modelo conectados a los mismos detectores qwen3 que SGLang ya incluye. Si ejecutas vLLM, el soporte estándar está a un merge de distancia: la línea del registro enruta el modelo al backend de transformers, el conversor de arquitectura dimensiona la caché correctamente, y se reutilizan los analizadores de razonamiento y de llamada a herramientas de qwen3, que es como funciona la interfaz de llamada a herramientas compatible con OpenAI.

La advertencia honesta es que la ruta de vLLM es un camino de compatibilidad, no uno optimizado. Ejecutar NanbeigeForCausalLM a través de TransformersForCausalLM significa que vLLM ejecuta el propio código de Hugging Face del modelo dentro de su capa de servicio, en lugar de una implementación nativa con kernels personalizados y manejo de grafos CUDA: esa diferencia es precisamente lo que SGLang eligió construir de forma nativa. Para un modelo de 3B cuyo costo por token ya está duplicado por el bucle, es poco probable que la ruta del backend de transformers sea la vía de servicio más rápida posible, y el historial de cinco errores del código personalizado subyacente implica que la ruta hereda las peculiaridades que queden en él. Para cargas de trabajo agénticas, donde la corrección de las llamadas a herramientas y el comportamiento de contexto largo suelen importar más que los tokens brutos por segundo, ese puede ser un intercambio aceptable; para chat sensible a la latencia, vale la pena hacer benchmarking antes de apostar una ruta de producción a ello. Y dos motores siguen siendo solo bifurcaciones: llama.cpp y Ollama continúan apuntando a ramas de Nanbeige, y el servidor llama.cpp incluido en LM Studio aún no es compatible con la arquitectura.

Qué ver a continuación

Tres cosas cambiarían el panorama. Primero, el PR de vLLM debe fusionarse y publicarse en una versión: sigue el hilo y las notas de la versión de vLLM; los revisores ya han señalado que faltan una entrada en la documentación y un mapeo de puntos de control de CI antes de que esté listo para fusionarse. Segundo, observa si el convertidor de conteo de capas sobrevive a la revisión, ya que los mantenedores creen que el PR #54941 puede haberlo vuelto redundante, una señal de cuánto de esta solución es un andamiaje alrededor de la arquitectura en bucle. Tercero, observa la cuestión del proveedor alojado: la tarjeta de Hugging Face actualmente no muestra ningún proveedor de inferencia sirviendo el modelo, y nosotros tampoco lo alojamos, así que hoy esto es una historia de autoalojamiento. Cuando un proveedor lo incluya, el lado del enrutamiento se vuelve rutinario: una sola API a través de un gran catálogo de modelos con los precios de los proveedores pasados sin margen es la forma de baja fricción de hacer una prueba A/B de un Nanbeige4.2-3B autoalojado contra los modelos alojados que dice superar. Hasta entonces, el hito a destacar es el que acaba de ocurrir: seis semanas después de un lanzamiento que todos los principales runtimes recibieron con un encogimiento de hombros y un fork, dos de ellos ahora sirven Nanbeige4.2-3B desde una instalación sin modificar.