Il Beijing Academy of Artificial Intelligence (BAAI) ha rilasciato AREX-2, un modello agente da 27 miliardi di parametri basato su un’architettura densa compatibile con Qwen3.8. La notizia non è solo l’ennesima famiglia di modelli da laboratorio: AREX-2 codifica un comportamento che sposta il costo dell’inference dal singolo passaggio alla gestione di un ciclo iterativo esplicito. Il modello propone una soluzione, misura il risultato tramite punteggi, log, errori e tempi, riflette su cosa non ha funzionato e rivede la risposta. Questo ciclo si ripete per più round in fase di test.

Il team lo ha addestrato su task di machine learning e programmazione algoritmica con feedback verificabile, insieme ai dati di ricerca profonda già usati per AREX. Il punto interessante è il trasferimento: il comportamento di auto-miglioramento appreso si estende alla ricerca profonda senza aggiungere nuove traiettorie di ricerca. Detto altrimenti, non serve riprogettare l’agente per ottenere benefici in domini diversi: il ciclo di riflessione diventa una proprietà del modello, non una feature del singolo task.

Per chi osserva il deployment on-premise, AREX-2 introduce una variabile che spesso manca nelle schede tecniche: il budget di test-time compute. Non basta stimare i token generati per una risposta; bisogna considerare quanti round di revisione il sistema eseguirà, perché ogni round consuma token aggiuntivi e conserva stato. Un contesto da 262.144 token rende questo aspetto più marcato: la cache chiave-valore cresce con la lunghezza della sessione e con la quantità di log e punteggi che il modello deve rileggere per riflettere. In ambiente self-hosted, la VRAM disponibile smette di essere solo un vincolo di caricamento dei pesi: diventa la capacità di tenere viva una sessione lunga e iterativa senza degradare la latency. Un modello denso da 27B in FP16 occupa già decine di gigabyte di VRAM solo per i pesi, a cui si aggiungono attivazioni e cache: il costo reale va calcolato su sessioni complete, non su completamenti singoli.

La disponibilità di file GGUF su Hugging Face, curata dalla community, indica che l’esecuzione locale è già nei pensieri di chi vuole evitare le API. Ma la quantization, necessaria per far girare un modello denso da 27B su hardware comune, va valutata con attenzione: la capacità di leggere errori e punteggi e decidere il prossimo passo può essere sensibile alla riduzione di precisione. Non c’è una risposta unica, ma il trade-off tra ingombro e fedeltà della riflessione è un tema da mettere in cantiere.

A livello strutturale, modelli come AREX-2 spingono le piattaforme di serving a trattare le sessioni come oggetti di prima classe, non come richieste isolate. I framework di orchestrazione devono mantenere la storia delle revisioni, passare di nuovo al modello il contesto esteso e gestire i timeout in modo coerente con un’attività che può estendersi. Chi offre stack self-hosted non può limitarsi a ottimizzare il throughput: deve progettare pipeline che tollerino l’iterazione e che non buttino via il lavoro già svolto. Questo cambia anche gli incentivi: un modello che produce una risposta mediocre al primo colpo può diventare accettabile se il ciclo di riflessione lo porta a una soluzione migliore, ma solo se il costo aggiuntivo dei round resta sotto controllo. Il TCO, quindi, si sposta dal costo per token al costo per soluzione utile.

A beneficiare sono chi ha già infrastrutture locali con GPU sufficienti a sostenere contesti lunghi e sessioni iterative: può ottenere un agente più robusto senza cambiare hardware, a patto di ridisegnare il serving. Ci perdono le piattaforme cloud pensate per completamenti brevi e stateless, che rischiano di moltiplicare le fatture quando il modello richiama se stesso più volte. La sovranità dei dati, già centrale per molti team che scelgono il self-hosted, diventa ancora più rilevante perché i log di punteggio e le tracce di errore sono materiale sensibile: farli uscire verso API esterne equivale a consegnare un diario dettagliato delle proprie pipeline. Per chi valuta deployment on-premise, i trade-off tra contesto, VRAM e numero di round si leggono con i framework analitici su /llm-onpremise.

Il vero test per AREX-2, però, non sarà il benchmark di ricerca ma la capacità di mantenere il ciclo propose-misurare-riflettere-revisionare su hardware reale, senza che il costo dei round cancelli il guadagno di qualità.