AREX-2 : un modèle d'agent de 27B qui se sert comme Qwen3.8-27B

BAAI a publié AREX-2 le 29 septembre : un modèle de 27B entraîné à travailler longtemps sur un problème, par rounds. Proposer une solution, la mesurer, réfléchir, réviser, recommencer. Apache 2.0, pas de gating, 54.7 GB de poids en BF16.

Ce qui a retenu mon attention, ce n'est pas le tableau de benchmarks. C'est la première ligne de son config.json : Qwen3_5ForConditionalGeneration, la même classe que Qwen3.8-27B. Le 4 octobre, le jour même où AREX-2 est apparu dans notre fil, nous servions Qwen3.8-27B de base avec sglang sur trois GPU : deux qui ont servi et un qui a manqué de mémoire pendant le warmup. Même architecture veut dire que l'essentiel de ce travail se transpose. L'essentiel, pas tout, et c'est sur les écarts que cet article passe son temps.

Pour être clair d'entrée : nous n'avons pas fait tourner AREX-2. Tous les chiffres de tokens/s que nous avons mesurés viennent de Qwen3.8-27B de base, utilisé comme proxy d'architecture. Les seuls chiffres de débit d'AREX-2 ci-dessous viennent de tiers, et sont indiqués comme tels. C'est pour ça que ce texte est dans news et pas dans research.

Ce qu'est AREX-2

D'après la model card et le papier (arXiv 2609.38288, "AREX-2: Advancing Self-Improving Agents through Long-Horizon Reflective Tasks") :

• Un modèle multimodal dense de 27B, compatible Qwen3.8, fine-tuné à partir de Qwen/Qwen3.8-27B. La card le classe en image-text-to-text.
• 262,144 tokens de contexte natif.
• Entraîné sur des trajectoires d'amélioration longues et synthétisées, tirées de tâches d'ingénierie ML et de programmation algorithmique où le feedback se vérifie. Le papier affirme que le comportement se transfère à la recherche approfondie et continue de s'améliorer à mesure qu'on lui donne plus de rounds.
• Apache 2.0, avec une note demandant de respecter aussi les conditions du modèle de base Qwen (lui aussi sous Apache 2.0). L'usage commercial est possible.

Je l'ai repéré dans la revue d'actualité du 4 octobre d'AI Search (vers 38:20), qui le décrit comme "a pretty tiny 27 billion parameter model based off of Qwen" qui "learns to repeatedly improve its own answer". Minuscule, c'est relatif : ça reste 55 GB en BF16.

Même châssis que Qwen3.8-27B, vérifié

J'ai comparé le config.json d'AREX-2 avec celui de Qwen3.8-27B. Les seules différences sont la transformers_version (5.2.0 contre 5.8.0.dev0) et deux clés de premier niveau redondantes. Tout ce qui détermine la mémoire et les kernels est identique :

Les quants du modèle de base que nous avons fait tourner (RedHatAI INT4, RadixArk NVFP4, le FP8 de Qwen lui-même) utilisent la même classe et la même disposition en 64 couches, 16 complètes + 48 linéaires. Le chat_template.jinja est identique octet pour octet lui aussi, gestion des appels d'outils comprise.

Deux différences qui comptent plus loin :

1. Pas de tête MTP. La config indique mtp_num_hidden_layers: 1, mais l'index safetensors ne contient aucun tenseur mtp. Qwen3.8-27B de base en livre 15, et environ 425M de paramètres de plus au total. Le speculative decoding MTP intégré n'a rien à charger.
2. La config du tokenizer diffère. Pas le template, mais tokenizer_config.json, et un repack communautaire signale que les réglages du pre-tokenizer et du decoder d'AREX-2 diffèrent de ceux de Qwen3.8. Probablement sans conséquence pour le serving, mais c'est exactement le genre de détail qui transforme "même architecture" en bug bizarre à 2 h du matin.

Choisir un fichier de poids pour sa carte

Voici ce qui existe aujourd'hui sur Hugging Face, avec les tailles mesurées depuis les dépôts. Ce sont les poids seuls : le KV cache et l'état de l'attention linéaire s'ajoutent par-dessus.

Ce que coûte le reste : sur notre run INT4 du modèle de base (RTX A6000, 1M de contexte via YARN), sglang utilisait environ 46 GB au total : 17.8 GB de poids, 11.5 GB d'état de type Mamba pour les couches d'attention linéaire et 12.8 GB de KV cache. Même disposition des couches, donc attendez-vous à la même forme d'overhead sur AREX-2 au même contexte. Sur un long contexte, les poids sont la partie bon marché.

Donc, carte par carte, en estimations et pas en mesures :

• Une carte de 80 GB (A100, H100) en BF16. 54.7 GB de poids laissent de la place pour un budget KV utile. Plausible, mais ni nous ni BAAI ne l'avons documenté. Notre catalogue interne de modèles estime environ 66 GB avec l'overhead, ce qui est aussi une estimation. Pour l'ordre de grandeur, l'A100 SXM 80 GB était à $1.79/h dans notre catalogue le 18 septembre, quand nous avons enregistré la démo de notre dernier article. Vérifiez le prix actuel avant de faire un budget.
• Une carte de 48 GB en INT4. C'est la configuration la plus proche de ce que nous avons vraiment fait tourner sur le modèle de base, contexte long compris.
• Une carte de 24 GB en INT4. Les 18.6 à 20.2 GB de poids rentrent, mais le seul déploiement INT4 publié utilisait deux RTX 3090 (tensor parallel 2, 16,784 MiB par GPU après de courts tests) avec un KV cache en FP8 et 28 GiB de KV déchargés sur le CPU. Une seule carte de 24 GB demanderait sans doute un contexte bien plus court ; nous ne l'avons pas essayé, et personne n'a publié ce run.

Quel quant pour quelle génération de GPU

C'est là que les runs du modèle de base se rendent utiles. Tous : sglang 0.5.21, Qwen3.8-27B de base, un seul GPU, sur une A6000 et des cartes RTX Blackwell, pas sur une A100 ni une H100. Tout ce qui concerne l'A100 et en dessous est une extrapolation depuis l'A6000, puisque les deux sont Ampere.

Ce que j'en retiens :

• Le FP8 sur Ampere est un piège. L'A6000 n'a pas de FP8 natif, donc sglang l'exécute en weight-only via Marlin et on obtient 24 tok/s. La card du FP8 d'AREX-2 dit la même chose à sa façon : la pleine vitesse demande Hopper, Ada ou plus récent. Sur une A100, même famille, je ne m'embêterais pas avec le FP8.
• L'INT4 est le plancher raisonnable sur Ampere. 41 contre 24 tok/s sur la même carte, avec le contexte long intact.
• NVFP4 plus speculative decoding, c'est le bon coup sur Blackwell, et il faut un pod CUDA 13 : avec notre image par défaut en CUDA 12.4, sglang meurt avec SM 12.x requires CUDA>=12.9. Le hic pour AREX-2 : personne n'en a encore publié de quant NVFP4, à ce jour.

La commande que nous avons utilisée, et ce qui change pour AREX-2

Voici la config rapide du modèle de base, telle quelle (RTX PRO 5000, pod 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

Sur InferenceKey, nous avons aussi augmenté la patience du worker, parce que le premier warmup est long et que le superviseur le tuerait sinon : INFERENCEKEY_HEALTH_POLL_SECS=30, INFERENCEKEY_HEALTH_MISS_THRESHOLD=40, INFERENCEKEY_SGLANG_READY_TIMEOUT_SECS=1800. L'image du pod était le template RunPod CUDA 13 runpod/pytorch:1.0.7-cu1300-torch291-ubuntu2404-cluster.

Pour AREX-2, impossible de coller ça et de partir :

• Il n'existe pas de NVFP4 d'AREX-2, donc --model-path devient l'un des quatre fichiers ci-dessus.
• Le drafter est fait pour un autre modèle. z-lab/Qwen3.8-27B-DFlash2 indique Qwen3.8-27B de base comme modèle de base. Un fine-tune déplace la distribution des tokens, donc son taux d'acceptation sur AREX-2 est inconnu. La card de l'INT4 de numsu rapporte un décodage avec un drafter DFlash2 externe sur sa configuration 2x3090 (225.6 tok/s en médiane avec un prompt de 1K et 512 tokens de sortie, 42.6 tok/s avec un prompt de 128K), mais sans accept length, donc ces chiffres ne répondent pas à la question.
• Le MTP intégré est exclu (pas de tenseurs MTP). Il existe une tentative communautaire, numsu/AREX-2-27B-INT8-W8A16-MTP : un module MTP initialisé à partir des poids de Qwen3.8 et entraîné sur 1,228 séquences générées par AREX-2, sur une seule RTX 3090. Elle rapporte une acceptation offline de 87.4 % en position 1, 79.7 % en 2 et 74.8 % en 3, soit environ 2.88 draft tokens acceptés par étape. Sa propre card précise que c'est offline, pas un test de vitesse de bout en bout, et qu'il faut un build de vLLM avec le support du vocabulaire de draft (vLLM standard peut échouer sur draft_lm_head).
• L'astuce du contexte 1M et le speculative decoding ne se mélangent pas. 1M est un override YARN par-dessus les 262,144 natifs (en bref, --json-model-override-args qui règle YARN avec un facteur de 4.0, plus --context-length 1000000 ; c'est un résumé de notre recette, pas un flag à copier-coller). Sur le modèle de base, DFlash2 refusait de fonctionner avec cet override : c'était donc 1M sans speculative, ou 256K avec. Nous ne l'avons pas retesté sur AREX-2, mais rien dans la config ne laisse penser que ça change.
• Les parsers sont déduits. --reasoning-parser qwen3 et --tool-call-parser qwen3_coder devraient s'appliquer, puisque le chat template est identique octet pour octet. Devraient. La config du tokenizer diffère et personne n'a publié de run sglang d'AREX-2.
• Un détail dans nos flags : la config d'AREX-2 fixe mamba_ssm_dtype à float32 ; notre commande de base le forçait en bfloat16. Sans problème pour Qwen3.8 dans nos runs, non testé sur un modèle entraîné pour de longues trajectoires réflexives.

Si j'avais une carte de 80 GB cet après-midi, mon premier essai serait le plus ennuyeux : BAAI/AREX-2 en BF16, le contexte natif de 256K, aucun flag de speculative, les mêmes parsers, et une longue tâche d'agent pour voir si les appels d'outils se parsent. Puis ajouter une chose à la fois. Comme une balance : la grosse caisse d'abord, puis le reste de la batterie.

Les benchmarks, avec leurs astérisques

Les chiffres de la card sont solides pour un 27B :

Maintenant, les astérisques. Ces chiffres sont auto-déclarés et la card dit qu'ils "follow the protocols reported in the AREX-2 paper". Je n'ai trouvé aucune reproduction indépendante. Le dépôt d'évaluation montre ce que coûte ce protocole : le profil research autorise jusqu'à 10 rounds externes et jusqu'à 1,500 appels au modèle par cas, 240,000 tokens de contexte avec un refresh à 128,000, un timeout de 24 heures par cas, et un modèle juge externe. Le chiffre HLE porte sur le sous-ensemble texte seul, pas sur le HLE complet.

Ce n'est pas de la triche, c'est tout l'intérêt du modèle : il s'améliore à mesure qu'on le laisse itérer. Mais ça veut dire qu'une comparaison honnête oppose "AREX-2 avec un gros budget de rounds" à "un modèle frontière avec le budget qu'on lui a donné", et la question pratique devient combien d'heures de GPU un seul cas consomme. Payer à l'heure de GPU plutôt qu'au token ne gagne que si le GPU reste occupé, par exemple en faisant tourner plusieurs cas en parallèle ; le profil research du dépôt d'évaluation fait tourner un cas à la fois avec un timeout de 24 heures, ce qui est à peu près l'inverse.

Ce que cela dit, et ce que cela ne dit pas

Les limites, sans détour :

• Nous n'avons pas servi AREX-2. Tous les chiffres de débit et de VRAM que nous avons mesurés viennent de Qwen3.8-27B de base sur une A6000 et une RTX PRO 5000 (la RTX 5090 a manqué de mémoire pendant le warmup et ne nous a donné aucun chiffre).
• La seule recette d'inférence de la model card est Transformers (AutoModelForMultimodalLM, BF16, device_map="auto"). Aucune commande vLLM ou sglang de BAAI. Le dépôt GitHub contient des runners d'évaluation qui parlent à n'importe quel endpoint compatible OpenAI, pas du code de serving.
• Les quants communautaires sont peu testés. L'INT4 de numsu a été validé sur 2x RTX 3090 avec un vLLM 0.29.0 épinglé, jusqu'à 128K tokens de prompt, sans évaluation de qualité ni multimodale (seulement une erreur de reconstruction des poids, 0.12). L'AWQ de cyankiwi et le repack FP8 ne publient aucune mesure à eux.
• Le speculative decoding sur AREX-2 n'est pas mesuré de bout en bout, par personne, d'après ce que j'ai pu trouver.
• Les benchmarks sont ceux des auteurs, selon leur propre protocole.

Ce que cela dit : si vous servez déjà Qwen3.8-27B, AREX-2 devrait tenir dans le même budget mémoire avec les mêmes kernels, et probablement les mêmes flags, jusqu'à ce qu'un vrai run dise le contraire. Le choix du fichier de poids suit le GPU que vous avez : BF16 sur 80 GB, INT4 sur 48 GB, INT4 sur 24 GB seulement avec un contexte court et toujours pas prouvé, FP8 seulement sur Ada, Hopper ou plus récent, et gardez NVFP4 plus speculative pour le jour où quelqu'un publiera un NVFP4 d'AREX-2 et un drafter entraîné dessus. Un vrai run d'AREX-2, avec ses propres chiffres, est le prochain morceau de la setlist.

Sources : model card, papier, dépôt d'évaluation, config.json.