AREX-2: ein 27B-Agent-Modell, das sich wie Qwen3.8-27B betreiben lässt

BAAI hat AREX-2 am 29. September veröffentlicht: ein 27B-Modell, das darauf trainiert ist, lange an einem Problem zu arbeiten, in Runden. Eine Lösung vorschlagen, messen, reflektieren, überarbeiten, wiederholen. Apache 2.0, kein Gating, 54.7 GB BF16-Gewichte.

Was mir ins Auge gesprungen ist, ist nicht die Benchmark-Tabelle. Es ist die erste Zeile der config.json: Qwen3_5ForConditionalGeneration, dieselbe Klasse wie bei Qwen3.8-27B. Am 4. Oktober, demselben Tag, an dem AREX-2 in unserem Feed auftauchte, hatten wir das Basismodell Qwen3.8-27B mit sglang auf drei GPUs betrieben: zwei, die liefen, und eine, der im Warmup der Speicher ausging. Gleiche Architektur heißt, dass sich der Großteil dieser Arbeit übertragen lässt. Der Großteil, nicht alles, und genau um die Lücken geht es in diesem Beitrag.

Damit es gleich klar ist: Wir haben AREX-2 nicht laufen lassen. Jede tokens/s-Zahl, die wir gemessen haben, stammt vom Basismodell Qwen3.8-27B, als Stellvertreter für die Architektur. Die einzigen Durchsatzwerte für AREX-2 weiter unten kommen von Dritten und sind auch so gekennzeichnet. Deshalb steht das hier unter News und nicht unter Research.

Was AREX-2 ist

Laut Model Card und Paper (arXiv 2609.38288, "AREX-2: Advancing Self-Improving Agents through Long-Horizon Reflective Tasks"):

• Ein dichtes, Qwen3.8-kompatibles multimodales 27B-Modell, feinabgestimmt aus Qwen/Qwen3.8-27B. Die Card taggt es als image-text-to-text.
• 262,144 Token nativer Kontext.
• Trainiert auf synthetisierten Verbesserungstrajektorien mit langem Horizont aus ML-Engineering- und Algorithmik-Programmieraufgaben, bei denen sich das Feedback überprüfen lässt. Laut Paper überträgt sich das Verhalten auf Deep Research und wird weiter besser, je mehr Runden man ihm gibt.
• Apache 2.0, mit dem Hinweis, auch die Bedingungen des Qwen-Basismodells einzuhalten (das ebenfalls Apache 2.0 ist). Kommerzielle Nutzung ist drin.

Entdeckt habe ich es im News-Roundup von AI Search vom 4. Oktober (etwa bei 38:20), das es „a pretty tiny 27 billion parameter model based off of Qwen“ nennt, das „learns to repeatedly improve its own answer“. Winzig ist relativ: In BF16 sind es immer noch 55 GB.

Dasselbe Chassis wie Qwen3.8-27B, geprüft

Ich habe die config.json von AREX-2 mit der von Qwen3.8-27B verglichen. Die einzigen Unterschiede sind die transformers_version (5.2.0 gegenüber 5.8.0.dev0) und zwei redundante Schlüssel auf oberster Ebene. Alles, was über Speicher und Kernels entscheidet, ist identisch:

Die Quants des Basismodells, die wir betrieben haben (RedHatAI INT4, RadixArk NVFP4, Qwens eigenes FP8), nutzen dieselbe Klasse und dasselbe Layout mit 64 Layern, 16 Full + 48 Linear. Auch das chat_template.jinja ist Byte für Byte identisch, die Behandlung von Tool Calls eingeschlossen.

Zwei Unterschiede, die später wichtig werden:

1. Kein MTP-Head. Die Config sagt mtp_num_hidden_layers: 1, aber der Safetensors-Index enthält null mtp-Tensoren. Das Basismodell Qwen3.8-27B liefert 15 davon mit und hat insgesamt etwa 425M Parameter mehr. Das eingebaute MTP-Speculative-Decoding hat nichts zu laden.
2. Die Tokenizer-Config ist anders. Nicht das Template, sondern die tokenizer_config.json, und ein Community-Repack merkt an, dass sich die Pre-Tokenizer- und Decoder-Einstellungen von AREX-2 von denen von Qwen3.8 unterscheiden. Für das Serving vermutlich harmlos, aber genau die Art Detail, die aus „gleiche Architektur“ um 2 Uhr nachts einen seltsamen Bug macht.

Eine Gewichtsdatei für deine Karte wählen

Das gibt es heute auf Hugging Face, mit den aus den Repos gemessenen Größen. Das sind nur die Gewichte: KV-Cache und der Zustand der Linear Attention kommen obendrauf.

Was der Rest kostet: Bei unserem INT4-Lauf mit dem Basismodell (RTX A6000, 1M Kontext über YARN) belegte sglang insgesamt etwa 46 GB: 17.8 GB Gewichte, 11.5 GB Mamba-artiger Zustand für die Linear-Attention-Layer und 12.8 GB KV-Cache. Gleiches Layer-Layout, also ist bei AREX-2 mit gleichem Kontext dieselbe Form von Overhead zu erwarten. Bei langem Kontext sind die Gewichte der billige Teil.

Also Karte für Karte, als Schätzungen und nicht als Messungen:

• Eine 80-GB-Karte (A100, H100) in BF16. 54.7 GB Gewichte lassen Platz für ein brauchbares KV-Budget. Plausibel, aber weder wir noch BAAI haben es dokumentiert. Unser interner Modellkatalog schätzt etwa 66 GB mit Overhead, was ebenfalls eine Schätzung ist. Zur Einordnung: Die A100 SXM 80 GB kostete am 18. September, als wir die Demo für unseren letzten Beitrag aufgenommen haben, in unserem Katalog $1.79/h. Prüf den aktuellen Preis, bevor du ein Budget planst.
• Eine 48-GB-Karte in INT4. Das ist die Konfiguration, die dem am nächsten kommt, was wir mit dem Basismodell tatsächlich betrieben haben, langer Kontext eingeschlossen.
• Eine 24-GB-Karte in INT4. 18.6 bis 20.2 GB Gewichte passen, aber das einzige veröffentlichte INT4-Deployment nutzte zwei RTX 3090 (Tensor Parallel 2, 16,784 MiB pro GPU nach kurzen Tests) mit FP8-KV-Cache und 28 GiB KV auf die CPU ausgelagert. Eine einzelne 24-GB-Karte bräuchte wahrscheinlich einen deutlich kürzeren Kontext; wir haben es nicht probiert, und niemand hat diesen Lauf veröffentlicht.

Welcher Quant für welche GPU-Generation

Hier zahlen sich die Läufe mit dem Basismodell aus. Für alle gilt: sglang 0.5.21, Basismodell Qwen3.8-27B, eine GPU, auf einer A6000 und RTX-Blackwell-Karten, nicht auf einer A100 oder H100. Alles unterhalb von etwa der A100 ist eine Extrapolation von der A6000, da beide Ampere sind.

Was ich daraus mitnehme:

• FP8 auf Ampere ist eine Falle. Die A6000 hat kein natives FP8, also führt sglang es nur gewichtsseitig über Marlin aus, und du bekommst 24 tok/s. Die FP8-Card von AREX-2 sagt dasselbe mit eigenen Worten: volle Geschwindigkeit braucht Hopper, Ada oder neuer. Auf einer A100, derselben Familie, würde ich mir FP8 sparen.
• INT4 ist auf Ampere die vernünftige Untergrenze. 41 gegenüber 24 tok/s auf derselben Karte, mit intaktem langem Kontext.
• NVFP4 plus Speculative Decoding ist der Weg auf Blackwell, und dafür braucht es einen CUDA-13-Pod: Mit unserem Standard-Image mit CUDA 12.4 stirbt sglang mit SM 12.x requires CUDA>=12.9. Der Haken für AREX-2: Bis heute hat niemand einen NVFP4-Quant davon veröffentlicht.

Der Befehl, den wir verwendet haben, und was sich für AREX-2 ändert

Das ist die schnelle Config für das Basismodell, wörtlich (RTX PRO 5000, CUDA-13-Pod):

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

Auf InferenceKey haben wir außerdem die Geduld des Workers erhöht, weil der erste Warmup lang ist und der Supervisor ihn sonst abschießen würde: INFERENCEKEY_HEALTH_POLL_SECS=30, INFERENCEKEY_HEALTH_MISS_THRESHOLD=40, INFERENCEKEY_SGLANG_READY_TIMEOUT_SECS=1800. Das Pod-Image war das RunPod-Template für CUDA 13, runpod/pytorch:1.0.7-cu1300-torch291-ubuntu2404-cluster.

Für AREX-2 kannst du das nicht einfach einfügen und weggehen:

• Es gibt kein AREX-2 in NVFP4, also wird --model-path zu einer der vier Dateien oben.
• Der Drafter ist für das falsche Modell. z-lab/Qwen3.8-27B-DFlash2 nennt das Basismodell Qwen3.8-27B als Base Model. Ein Fine-Tune verschiebt die Token-Verteilung, also ist seine Acceptance Rate auf AREX-2 unbekannt. Die INT4-Card von numsu nennt Decode-Werte mit einem externen DFlash2-Drafter auf ihrem 2x3090-Setup (225.6 tok/s im Median bei 1K Prompt und 512 Output-Token, 42.6 tok/s bei 128K Prompt), aber keine Accept Length, also beantworten diese Zahlen die Frage nicht.
• Eingebautes MTP fällt weg (keine MTP-Tensoren). Es gibt einen Community-Versuch, numsu/AREX-2-27B-INT8-W8A16-MTP: ein MTP-Modul, das von den Gewichten von Qwen3.8 ausgeht und auf 1,228 von AREX-2 erzeugten Sequenzen auf einer einzigen RTX 3090 trainiert wurde. Es meldet eine Offline-Acceptance von 87.4% an Position 1, 79.7% an Position 2 und 74.8% an Position 3, etwa 2.88 akzeptierte Draft-Token pro Schritt. Die eigene Card sagt, dass das offline gemessen ist, kein End-to-End-Geschwindigkeitstest, und dass es einen vLLM-Build mit Unterstützung für Draft-Vokabular braucht (Standard-vLLM kann an draft_lm_head scheitern).
• Der 1M-Kontext-Trick und Speculative Decoding vertragen sich nicht. 1M ist ein YARN-Override auf die nativen 262,144 (kurz gesagt --json-model-override-args, das YARN mit Faktor 4.0 setzt, plus --context-length 1000000; das ist eine Zusammenfassung unseres Rezepts, kein Flag zum Kopieren). Beim Basismodell verweigerte DFlash2 die Arbeit mit diesem Override, also hieß es 1M ohne Speculation oder 256K mit. Auf AREX-2 haben wir das nicht erneut getestet, aber nichts in der Config deutet darauf hin, dass es sich ändert.
• Die Parser sind abgeleitet. --reasoning-parser qwen3 und --tool-call-parser qwen3_coder sollten passen, weil das Chat-Template Byte für Byte identisch ist. Sollten. Die Tokenizer-Config ist anders, und niemand hat einen sglang-Lauf von AREX-2 veröffentlicht.
• Ein Detail in unseren Flags: Die Config von AREX-2 setzt mamba_ssm_dtype auf float32; unser Befehl für das Basismodell hat das auf bfloat16 überschrieben. Bei Qwen3.8 in unseren Läufen kein Problem, ungetestet bei einem Modell, das auf lange reflektierende Trajektorien trainiert wurde.

Hätte ich heute Nachmittag eine 80-GB-Karte, wäre mein erster Versuch der langweilige: BAAI/AREX-2 in BF16, der native 256K-Kontext, keine Speculative-Flags, dieselben Parser, und eine lange Agent-Aufgabe, um zu sehen, ob die Tool Calls geparst werden. Dann eine Sache nach der anderen dazunehmen. Wie beim Soundcheck: erst die Bassdrum, dann der Rest des Schlagzeugs.

Die Benchmarks, mit ihren Sternchen

Die Zahlen der Card sind für ein 27B stark:

Jetzt die Sternchen. Die Werte sind selbst berichtet, und die Card sagt, sie „follow the protocols reported in the AREX-2 paper“. Eine unabhängige Reproduktion habe ich nicht gefunden. Das Evaluations-Repo zeigt, was dieses Protokoll kostet: Das Research-Profil erlaubt bis zu 10 äußere Runden und bis zu 1,500 Modellaufrufe pro Fall, 240,000 Token Kontext mit einem Refresh bei 128,000, ein Timeout von 24 Stunden pro Fall und ein externes Judge-Modell. Die HLE-Zahl bezieht sich auf die Text-Teilmenge, nicht auf das volle HLE.

Das ist kein Schummeln, das ist der Sinn des Modells: Es wird besser, je länger du es iterieren lässt. Es heißt aber, dass ein fairer Vergleich „AREX-2 mit großem Rundenbudget“ gegen „ein Frontier-Modell mit dem Budget, das es eben bekommen hat“ lautet, und die praktische Frage wird, wie viele GPU-Stunden ein Fall frisst. Abrechnung pro GPU-Stunde statt pro Token gewinnt nur, wenn du die GPU beschäftigt hältst, zum Beispiel indem du mehrere Fälle parallel laufen lässt; das Research-Profil des Evaluations-Repos lässt einen Fall nach dem anderen laufen, mit einem Timeout von 24 Stunden, und das ist ziemlich genau das Gegenteil.

Was das aussagt und was nicht

Die Grenzen, klar benannt:

• Wir haben AREX-2 nicht betrieben. Alle Durchsatz- und VRAM-Zahlen, die wir gemessen haben, stammen vom Basismodell Qwen3.8-27B auf einer A6000 und einer RTX PRO 5000 (der RTX 5090 ging im Warmup der Speicher aus, und sie lieferte uns keine Zahlen).
• Das einzige Inferenz-Rezept der Model Card ist Transformers (AutoModelForMultimodalLM, BF16, device_map="auto"). Kein vLLM- oder sglang-Befehl von BAAI. Das GitHub-Repo enthält Evaluations-Runner, die mit jedem OpenAI-kompatiblen Endpoint sprechen, keinen Serving-Code.
• Die Community-Quants sind kaum getestet. numsus INT4 wurde auf 2x RTX 3090 mit festgelegtem vLLM 0.29.0 validiert, bis 128K Prompt-Token, ohne Qualitäts- oder Multimodal-Eval (nur ein Rekonstruktionsfehler der Gewichte, 0.12). cyankiwis AWQ und das FP8-Repack veröffentlichen keine eigenen Messungen.
• Speculative Decoding auf AREX-2 ist nicht gemessen, End to End, von niemandem, soweit ich finden kann.
• Die Benchmarks sind die der Autoren, unter ihrem eigenen Protokoll.

Was es aussagt: Wenn du Qwen3.8-27B bereits betreibst, sollte AREX-2 in dasselbe Speicherbudget passen, dieselben Kernels nutzen und wahrscheinlich dieselben Flags, bis ein echter Lauf etwas anderes zeigt. Die Wahl der Gewichtsdatei folgt der GPU, die du hast: BF16 auf 80 GB, INT4 auf 48 GB, INT4 auf 24 GB nur mit kurzem Kontext und noch unbewiesen, FP8 nur auf Ada, Hopper oder neuer, und NVFP4 plus Speculation hebst du dir auf, bis jemand ein AREX-2 in NVFP4 und einen darauf trainierten Drafter veröffentlicht. Ein echter AREX-2-Lauf mit eigenen Zahlen ist als Nächstes auf der Setlist.

Quellen: Model Card, Paper, Evaluations-Repo, config.json.