AREX-2 : la config promet une tête MTP absente

Ce qui se passe

BAAI a publié AREX-2 le 29 septembre, sous licence Apache 2.0, sans accès restreint : un modèle de 27 milliards de paramètres entraîné à travailler par tours (proposer, mesurer, réfléchir, réviser). Son config.json ouvre sur Qwen3_5ForConditionalGeneration, la même classe que Qwen3.8-27B, que l'équipe du billet sert déjà avec sglang. Tentation : changer --model-path et relancer.

L'équipe a comparé les deux configurations. Elles ne diffèrent que par transformers_version et deux clés redondantes ; le gabarit de conversation chat_template.jinja est identique octet pour octet. S'arrêter là, c'est conserver l'ancienne commande. Précision utile : les auteurs n'ont pas fait tourner AREX-2 ; toutes les vitesses citées viennent du modèle de base.

Vérifier les poids, pas la config

Le modèle de base embarque une tête de prédiction multi-token (MTP), une petite couche qui devine quelques jetons d'avance pour en émettre plusieurs par pas. La configuration d'AREX-2 la déclare toujours ; ses fichiers de poids ne la contiennent pas :

config.json                    "mtp_num_hidden_layers": 1
safetensors index (AREX-2)     0 tenseur MTP
safetensors index (Qwen3.8)    15 tenseurs MTP

L'index safetensors liste chaque tenseur de la publication : c'est l'inventaire honnête. Autre différence discrète, dans tokenizer_config.json : un repaquetage communautaire signale que le pré-tokenizer et le décodeur diffèrent de Qwen3.8. Probablement sans effet — mais c'est le genre de détail qui se manifeste en appel d'outil illisible plusieurs heures après le début d'une session d'agent.

Ce qui était juste pour le modèle de base

La configuration la plus rapide de l'équipe tournait sur une RTX PRO 5000 (CUDA 13) avec un quant NVFP4 de RadixArk et le drafter DFlash2 de z-lab : 115 à 136 tok/s en décodage. Peu de choses survivent au changement :

• Pas de build NVFP4 d'AREX-2 à ce jour. Au choix : BF16 de BAAI (54,7 Go), FP8 de prithivMLmods (35,9 Go), AWQ INT4 de cyankiwi (20,2 Go) ou INT4 W4A16 de numsu (18,6 Go).
• Le drafter a été entraîné pour un autre modèle. Le décodage spéculatif ne paie que si la plupart des propositions sont acceptées ; DFlash2 vise le modèle de base, et personne ne connaît son taux d'acceptation sur AREX-2.
• mamba_ssm_dtype : AREX-2 demande float32, la commande de base forçait bfloat16.
• Les parseurs sont une supposition. qwen3 et qwen3_coder devraient convenir puisque le gabarit est identique, mais aucun passage sous sglang n'est publié.
• Contexte long ou spéculation, pas les deux. Le million de jetons du modèle de base est un dépassement YARN de ses 262 144 positions natives, avec lequel DFlash2 ne tourne pas : 1M sans drafter, ou 256K avec.

Le FP8 sur Ampère, l'erreur coûteuse

La RTX A6000 est une Ampère sans matériel FP8 : sglang garde les poids en FP8 et les décompresse à la volée par des noyaux Marlin. Le modèle de base y décodait à 24 tok/s. Le quant INT4 W4A16 de RedHatAI, même carte, même million de contexte : 41 tok/s. Une A100 est aussi une Ampère : y préférer l'INT4.

Les poids ne sont pas toute la facture. En INT4 à 1M de contexte, sglang a pris environ 46 Go, dont 17,8 Go de poids, 11,5 Go d'état pour les couches d'attention linéaire et 12,8 Go de cache KV.

Première exécution

Commencer ennuyeux : BF16 sur une carte de 80 Go, contexte natif de 256K, sans option de spéculation, mêmes parseurs, une longue tâche d'agent. Ne changer qu'un paramètre par exécution, et surveiller les appels d'outil encore bien formés tard dans la session, le débit contre le modèle de base sur la même carte, la longueur d'acceptation si un drafter est ajouté (le chiffre que personne n'a publié) et les heures de GPU par tâche : le protocole d'évaluation autorise jusqu'à 1 500 appels et 24 heures par cas.

Les scores annoncés (70,7 sur Frontier-CS, 84,0 sur BrowseComp) sont déclarés par BAAI, sans reproduction indépendante trouvée par les auteurs.

Source : Same config.json, different serve command, DEV Community, 15 octobre 2026.