AREX-2: un modelo de agente de 27B que se sirve como Qwen3.8-27B

BAAI publicó AREX-2 el 29 de septiembre: un modelo de 27B entrenado para trabajar en un problema durante mucho tiempo, por rondas. Propone una solución, la mide, reflexiona, la revisa y vuelta a empezar. Apache 2.0, sin acceso restringido, 54.7 GB de pesos en BF16.

Lo que me llamó la atención no es la tabla de benchmarks. Es la primera línea de su config.json: Qwen3_5ForConditionalGeneration, la misma clase que Qwen3.8-27B. El 4 de octubre, el mismo día que AREX-2 apareció en nuestro feed, habíamos estado sirviendo el Qwen3.8-27B base con sglang en tres GPUs: dos que sirvieron y una que se quedó sin memoria en el warmup. Misma arquitectura significa que casi todo ese trabajo se aprovecha. Casi todo, no todo, y los huecos son donde este post pasa su tiempo.

Que quede claro desde el principio: no hemos ejecutado AREX-2. Todas las cifras de tokens/s que medimos son del Qwen3.8-27B base, usado como proxy de la arquitectura. Las únicas cifras de throughput de AREX-2 que aparecen abajo son de terceros, y están marcadas como tales. Por eso esto va en news y no en research.

Qué es AREX-2

Según la model card y el paper (arXiv 2609.38288, "AREX-2: Advancing Self-Improving Agents through Long-Horizon Reflective Tasks"):

• Un modelo multimodal denso de 27B, compatible con Qwen3.8, con fine-tuning a partir de Qwen/Qwen3.8-27B. La card lo etiqueta como image-text-to-text.
• 262,144 tokens de contexto nativo.
• Entrenado con trayectorias sintéticas de mejora de largo recorrido, sacadas de tareas de ingeniería de ML y de programación algorítmica en las que el feedback se puede comprobar. El paper dice que el comportamiento se transfiere a la investigación profunda (deep research) y sigue mejorando a medida que le das más rondas.
• Apache 2.0, con una nota para respetar también los términos del modelo base de Qwen (que también es Apache 2.0). El uso comercial es posible.

Lo vi en el resumen de noticias del 4 de octubre de AI Search (hacia el 38:20), que lo describe como "a pretty tiny 27 billion parameter model based off of Qwen" que "learns to repeatedly improve its own answer". Lo de diminuto es relativo: sigue ocupando 55 GB en BF16.

El mismo chasis que Qwen3.8-27B, comprobado

Comparé el config.json de AREX-2 con el de Qwen3.8-27B. Las únicas diferencias son el transformers_version (5.2.0 frente a 5.8.0.dev0) y dos claves redundantes en el nivel superior. Todo lo que decide la memoria y los kernels es idéntico:

Las cuantizaciones del modelo base que ejecutamos (INT4 de RedHatAI, NVFP4 de RadixArk, el FP8 del propio Qwen) usan la misma clase y la misma disposición de 64 capas, 16 completas + 48 lineales. El chat_template.jinja también es idéntico byte a byte, gestión de tool calls incluida.

Dos diferencias que importan más adelante:

1. No hay cabeza MTP. La config dice mtp_num_hidden_layers: 1, pero el índice de safetensors tiene cero tensores mtp. El Qwen3.8-27B base trae 15 y unos 425M de parámetros más en total. El speculative decoding MTP integrado no tiene nada que cargar.
2. La config del tokenizer es distinta. No la plantilla, sino tokenizer_config.json, y un repack de la comunidad señala que los ajustes de pre-tokenizer y decoder de AREX-2 difieren de los de Qwen3.8. Probablemente inofensivo para servir, pero es justo el tipo de cosa que convierte "misma arquitectura" en un bug raro a las 2 de la madrugada.

Elige un fichero de pesos para tu tarjeta

Esto es lo que hay hoy en Hugging Face, con los tamaños medidos en los repos. Son solo pesos: la KV cache y el estado de la atención lineal van aparte.

Lo que cuesta el resto: en nuestra ejecución INT4 del modelo base (RTX A6000, 1M de contexto mediante YARN), sglang usó unos 46 GB en total: 17.8 GB de pesos, 11.5 GB de estado estilo Mamba para las capas de atención lineal y 12.8 GB de KV cache. Misma disposición de capas, así que espera la misma forma de overhead en AREX-2 con el mismo contexto. En un contexto largo, los pesos son la parte barata.

Así que, tarjeta a tarjeta, como estimaciones y no como mediciones:

• Una tarjeta de 80 GB (A100, H100) en BF16. 54.7 GB de pesos dejan sitio para un presupuesto de KV útil. Plausible, pero ni nosotros ni BAAI lo hemos documentado. Nuestro catálogo interno de modelos estima unos 66 GB con overhead, y eso también es una estimación. Como referencia, la A100 SXM 80 GB estaba a $1.79/h en nuestro catálogo el 18 de septiembre, cuando grabamos la demo de nuestro último post. Mira el precio actual antes de hacer el presupuesto.
• Una tarjeta de 48 GB en INT4. Es la configuración más parecida a lo que de verdad ejecutamos con el modelo base, contexto largo incluido.
• Una tarjeta de 24 GB en INT4. Caben 18.6 a 20.2 GB de pesos, pero el único despliegue INT4 publicado usó dos RTX 3090 (tensor parallel 2, 16,784 MiB por GPU tras pruebas cortas) con KV cache en FP8 y 28 GiB de KV volcados a la CPU. Una sola tarjeta de 24 GB probablemente necesitaría un contexto mucho más corto; no lo hemos probado y nadie ha publicado esa ejecución.

Qué cuantización para qué generación de GPU

Aquí es donde las ejecuciones del modelo base se ganan el sueldo. Todas ellas: sglang 0.5.21, Qwen3.8-27B base, una sola GPU, en una A6000 y en tarjetas RTX Blackwell, no en una A100 ni en una H100. Todo lo que esté por debajo de la A100, más o menos, es una extrapolación desde la A6000, ya que las dos son Ampere.

Lo que saco de aquí:

• FP8 en Ampere es una trampa. La A6000 no tiene FP8 nativo, así que sglang lo ejecuta solo con pesos en FP8 a través de Marlin y sacas 24 tok/s. La card del AREX-2 en FP8 dice lo mismo con sus palabras: la velocidad completa necesita Hopper, Ada o algo más nuevo. En una A100, de la misma familia, yo no me molestaría con FP8.
• INT4 es el suelo sensato en Ampere. 41 frente a 24 tok/s en la misma tarjeta, con el contexto largo intacto.
• NVFP4 más speculative decoding es la jugada en Blackwell, y necesita un pod con CUDA 13: con nuestra imagen por defecto de CUDA 12.4, sglang muere con SM 12.x requires CUDA>=12.9. La pega para AREX-2: a día de hoy nadie ha publicado una cuantización NVFP4 suya.

El comando que usamos, y qué cambia para AREX-2

Esta es la configuración rápida del modelo base, literal (RTX PRO 5000, pod con CUDA 13):

sglang serve --trust-remote-code \
  --model-path RadixArk/Qwen3.8-27B-NVFP4 \
  --tp-size 1 --context-length 262144 \
  --kv-cache-dtype fp8_e4m3 --attention-backend flashinfer \
  --mamba-ssm-dtype bfloat16 --mamba-radix-cache-strategy extra_buffer_lazy \
  --chunked-prefill-size 4096 --max-prefill-tokens 8192 \
  --max-running-requests 8 --mem-fraction-static 0.90 \
  --speculative-algorithm DFLASH \
  --speculative-draft-model-path z-lab/Qwen3.8-27B-DFlash2 \
  --speculative-num-draft-tokens 8 \
  --reasoning-parser qwen3 --tool-call-parser qwen3_coder \
  --host 0.0.0.0 --port 30000

En InferenceKey también le dimos más paciencia al worker, porque el primer warmup es largo y si no el supervisor lo mataría: INFERENCEKEY_HEALTH_POLL_SECS=30, INFERENCEKEY_HEALTH_MISS_THRESHOLD=40, INFERENCEKEY_SGLANG_READY_TIMEOUT_SECS=1800. La imagen del pod era la plantilla de RunPod con CUDA 13 runpod/pytorch:1.0.7-cu1300-torch291-ubuntu2404-cluster.

Para AREX-2 no basta con pegar eso y olvidarte:

• No hay AREX-2 en NVFP4, así que --model-path pasa a ser uno de los cuatro ficheros de arriba.
• El drafter es de otro modelo. z-lab/Qwen3.8-27B-DFlash2 indica el Qwen3.8-27B base como su modelo base. Un fine-tune desplaza la distribución de tokens, así que su tasa de aceptación en AREX-2 es desconocida. La card del INT4 de numsu publica cifras de decode con un drafter DFlash2 externo en su montaje de 2x3090 (225.6 tok/s de mediana con un prompt de 1K y 512 tokens de salida, 42.6 tok/s con un prompt de 128K), pero sin accept length, así que esas cifras no responden a la pregunta.
• El MTP integrado queda descartado (no hay tensores MTP). Hay un intento de la comunidad, numsu/AREX-2-27B-INT8-W8A16-MTP: un módulo MTP que parte de los pesos de Qwen3.8, entrenado con 1,228 secuencias generadas por AREX-2 en una sola RTX 3090. Publica una aceptación offline del 87.4% en la posición 1, del 79.7% en la 2 y del 74.8% en la 3, unos 2.88 draft tokens aceptados por paso. Su propia card dice que eso es offline, no una prueba de velocidad de extremo a extremo, y necesita un build de vLLM con soporte de vocabulario de draft (el vLLM de serie puede fallar en draft_lm_head).
• El truco del contexto de 1M y el speculative decoding no se llevan. 1M es un override de YARN sobre los 262,144 nativos (en resumen, --json-model-override-args configurando YARN con un factor de 4.0, más --context-length 1000000; es un resumen de nuestra receta, no un flag para copiar y pegar). Con el modelo base, DFlash2 se negó a funcionar con ese override, así que era 1M sin especulación o 256K con ella. No lo volvimos a probar con AREX-2, pero nada en la config sugiere que cambie.
• Los parsers son una inferencia. --reasoning-parser qwen3 y --tool-call-parser qwen3_coder deberían valer, porque la plantilla de chat es idéntica byte a byte. Deberían. La config del tokenizer es distinta y nadie ha publicado una ejecución de AREX-2 con sglang.
• Un detalle de nuestros flags: la config de AREX-2 pone mamba_ssm_dtype a float32; nuestro comando base lo forzaba a bfloat16. Bien para Qwen3.8 en nuestras pruebas, sin probar en un modelo entrenado para trayectorias reflexivas largas.

Si esta tarde tuviera una tarjeta de 80 GB, mi primer intento sería el aburrido: BAAI/AREX-2 en BF16, el contexto nativo de 256K, sin flags de speculative, los mismos parsers y una tarea de agente larga para ver si las tool calls se parsean. Después, añadir una cosa cada vez. Como en una prueba de sonido: primero el bombo, luego el resto de la batería.

Los benchmarks, con sus asteriscos

Las cifras de la card son fuertes para un 27B:

Ahora los asteriscos. Son cifras autodeclaradas y la card dice que "follow the protocols reported in the AREX-2 paper". No encontré ninguna reproducción independiente. El repo de evaluación muestra lo que cuesta ese protocolo: el perfil de investigación permite hasta 10 rondas externas y hasta 1,500 llamadas al modelo por caso, 240,000 tokens de contexto con un refresco a los 128,000, un timeout de 24 horas por caso y un modelo juez externo. La cifra de HLE es el subconjunto solo de texto, no el HLE completo.

Eso no es hacer trampa, es la gracia del modelo: mejora cuanto más le dejas iterar. Pero significa que una comparación justa es "AREX-2 con un presupuesto grande de rondas" frente a "un modelo frontera con el presupuesto que le tocara", y la pregunta práctica pasa a ser cuántas horas de GPU se come un caso. Pagar por hora de GPU en lugar de por token solo sale a cuenta si mantienes la GPU ocupada, por ejemplo ejecutando varios casos en paralelo; el perfil de investigación del repo de evaluación ejecuta un caso cada vez con un timeout de 24 horas, que es casi lo contrario.

Qué te dice esto y qué no

Los límites, sin rodeos:

• No hemos servido AREX-2. Todas las cifras de throughput y VRAM que medimos son del Qwen3.8-27B base en una A6000 y una RTX PRO 5000 (la RTX 5090 se quedó sin memoria en el warmup y no nos dio cifras).
• La única receta de inferencia de la model card es Transformers (AutoModelForMultimodalLM, BF16, device_map="auto"). Ningún comando de vLLM ni de sglang por parte de BAAI. El repo de GitHub contiene runners de evaluación que hablan con cualquier endpoint compatible con OpenAI, no código para servir el modelo.
• Las cuantizaciones de la comunidad están poco probadas. El INT4 de numsu se validó en 2x RTX 3090 con vLLM 0.29.0 fijado, hasta 128K tokens de prompt, sin evaluación de calidad ni multimodal (solo un error de reconstrucción de pesos, 0.12). El AWQ de cyankiwi y el repack FP8 no publican mediciones propias.
• El speculative decoding en AREX-2 está sin medir de extremo a extremo, por nadie, hasta donde he podido encontrar.
• Los benchmarks son de los propios autores, con su propio protocolo.

Lo que sí te dice: si ya sirves Qwen3.8-27B, AREX-2 debería caber en el mismo presupuesto de memoria y con los mismos kernels, y probablemente con los mismos flags, hasta que una ejecución real diga lo contrario. La elección del fichero de pesos depende de la GPU que tengas: BF16 en 80 GB, INT4 en 48 GB, INT4 en 24 GB solo con un contexto corto y todavía sin demostrar, FP8 solo en Ada, Hopper o más nuevo, y deja NVFP4 más especulación para cuando alguien publique un AREX-2 en NVFP4 y un drafter entrenado con él. Una ejecución real de AREX-2, con sus propias cifras, es lo siguiente en el setlist.

Fuentes: model card, paper, repo de evaluación, config.json.