In molti uffici sopravvive un oggetto antico: la busta interna, quella cartellina di carta ruvida con una griglia di nomi stampata davanti. Un documento ci entra, il primo destinatario lo legge, aggiunge la sua parte, cancella il proprio nome e la passa al successivo. Nessuno, in tutto questo, tiene un registro centrale di dove si trovi ogni cartellina in ogni istante: le istruzioni per il viaggio sono scritte sulla busta stessa. Il documento sa da solo dove andare.
Matrix, il framework presentato a fine novembre 2025 da un gruppo di FAIR at Meta, applica questa idea alla generazione di dati sintetici con sciami di agenti. Al posto della cartellina c’è un messaggio; al posto del documento, lo stato di un compito: la cronologia della conversazione, i risultati intermedi, l’indicazione di quale agente tocca dopo. E al posto dell’ufficio con il suo smistatore c’è un cluster di macchine in cui decine di migliaia di compiti viaggiano in parallelo, ciascuno portandosi dietro le proprie istruzioni. Il «direttore d’orchestra» — l’orchestratore centralizzato che nei sistemi tradizionali coordina tutto — semplicemente non c’è.
Perché generare dati con degli agenti
I modelli linguistici si addestrano su dati, e i dati buoni scarseggiano: sono costosi, a volte proprietari, spesso sensibili per la privacy. Da qualche anno la risposta dell’industria è produrli sinteticamente, facendoli generare ad altri modelli. La forma più recente di questa pratica non usa un modello solo, ma diversi agenti che collaborano: uno pone una domanda, un altro risponde, un terzo verifica, un quarto assegna un punteggio. Kimi K2 e CWM, due sistemi citati nel paper, costruiscono così le loro dimostrazioni di ragionamento e di uso degli strumenti. Il flusso non è più una catena di montaggio lineare: ci sono cicli, ripensamenti, condizioni che decidono a runtime chi parla dopo.
Il problema è che gli strumenti esistenti mal si adattano alla scala. I framework generici come Autogen, LangGraph e CrewAI sono pensati per chatbot e assistenti personali, non per sfornare milioni di esempi. Quelli specializzati — AgentInstruct, SWE-Agent, TaskCraft — producono dati di qualità ma hanno la logica di orchestrazione cucita addosso a un dominio specifico. E quasi tutti condividono lo stesso punto debole: un coordinatore centrale che deve seguire ogni singolo compito. Finché i compiti sono cento, regge. Quando diventano decine di migliaia, quel coordinatore è il collo di bottiglia — lo smistatore travolto dalle buste.
L’orchestratore che diventa un messaggio
L’intuizione di Matrix è tanto semplice quanto radicale: rendere lo stato del compito serializzabile e farlo viaggiare dentro il messaggio. Ogni riga di dati in ingresso è un compito indipendente. Attorno a essa il sistema crea un oggetto orchestrator che contiene tutto: la cronologia, la logica di controllo, il prossimo agente da attivare. Un agente riceve l’orchestrator dalla propria coda, esegue il suo pezzo di lavoro — una chiamata a un modello, l’esecuzione di uno strumento — aggiorna lo stato e inoltra l’oggetto all’agente successivo, scelto a caso tra le repliche disponibili di quel ruolo. Quando un flag is_done si accende, il messaggio finisce a un agente terminale chiamato sink, che salva il risultato.
La conseguenza architetturale è che gli agenti sono senza stato. Non custodiscono nulla tra un messaggio e l’altro, quindi si possono moltiplicare o spostare sul cluster liberamente, come cassieri intercambiabili a cui basta la ricevuta che il cliente porta con sé. I calcoli pesanti — l’inferenza dei modelli, i container con gli strumenti — sono delegati a servizi distribuiti separati. Il tutto poggia su Ray, con ogni agente implementato come un Ray Actor, e si aggancia a motori d’inferenza come vLLM e SGLang, a container Apptainer e allo scheduler SLURM; la configurazione passa da Hydra.
A sinistra il modello tradizionale: un unico orchestratore fa da mozzo, e ogni compito deve ripassare da lì. A destra Matrix: lo stato del compito viaggia dentro il messaggio, passa direttamente da un agente al successivo fino al sink, e i calcoli pesanti restano in servizi condivisi a lato.
C’è un secondo cambiamento, meno vistoso ma decisivo, nel modo di programmare il lavoro. I motori di calcolo distribuito classici, come Spark o Ray Data, procedono a lotti: raggruppano i compiti in blocchi e non aprono il blocco successivo finché il precedente non è chiuso. Se in un lotto un compito è lento — e nei flussi con agenti, dove il percorso dipende dai dati, capita di continuo — trascina tutti gli altri, e le GPU restano ferme ad aspettare. Matrix schedula invece riga per riga: appena un compito finisce, il successivo parte, senza barriere di sincronizzazione. La concorrenza si regola con una formula lineare nel numero di GPU, $50 \times N_{\text{GPU}}$, cioè cinquanta compiti attivi per scheda; su 248 GPU diventano $248 \times 50 = 12\,400$ compiti in volo contemporaneamente. Un semaforo interno tiene sotto controllo il numero massimo, per non saturare la memoria.
Tre banchi di prova, e il numero che conta davvero
Gli autori misurano Matrix su tre scenari di generazione, sempre confrontandolo con l’implementazione ufficiale di riferimento sullo stesso hardware. Il primo è Collaborative Reasoner: due agenti che discutono, dissentono e cercano un accordo su domande di MMLU-Pro, con Llama-3.1-8B-Instruct a interpretare entrambi i ruoli. Su 31 nodi A100 (248 GPU), Matrix genera circa 2 miliardi di token in poco più di quattro ore, contro le nove ore abbondanti del sistema originale: 6,8 volte il throughput, 129.833 token al secondo contro 18.917. Il dato che invece non cambia è la qualità: la metrica di accordo tra gli agenti resta praticamente identica, 0,478 contro 0,473.
Il secondo scenario, NaturalReasoning, è una pipeline di curatela su 25 milioni di documenti web: un modello da 3 miliardi di parametri filtra, un 70B assegna punteggi ed estrae domande. Qui solo il 5,45% dei documenti supera tutti i filtri, distillando circa un milione di domande di ragionamento. È il caso in cui Matrix mostra i muscoli della schedulazione riga-per-riga: 2,1 volte il throughput rispetto a una linea di base a lotti costruita con Ray Data (5.853 token al secondo contro 2.778). Il paper è onesto anche nel documentare cosa non aiuta: raddoppiare le repliche degli agenti dà un guadagno modesto, e portarle a dieci volte non porta benefici — il throughput scende anzi leggermente sotto il livello di partenza — perché in questo flusso gli agenti sono limitati dall’I/O, non dal calcolo. Il dimensionamento è calcolato a mano — le repliche del modello grande devono reggere circa quindici richieste ciascuna:
$$14\,000 \times \left(1 – 3{,}68\% – 90{,}24\%\right) \div 56 \approx 15$$
Il terzo scenario, Tau2-bench, genera traiettorie di assistenza clienti nel settore telecom: quattro agenti — utente simulato, assistente, esecutore di strumenti, calcolatore di ricompensa — con gpt-oss-120b sotto, su 13 nodi H100. Qui il divario è massimo: la linea di base ufficiale, vincolata a una singola macchina, si satura intorno ai 500 thread; Matrix continua a scalare fino a 1.500 compiti concorrenti e produce 15,4 volte più token al secondo (41.003 contro 2.654), con la ricompensa media dei compiti sostanzialmente invariata, 0,592 in entrambi i casi. Una nota tecnica interessante: per non intasare la rete, i pezzi di conversazione oltre i 512 byte (circa il 12% del totale) vengono spostati nell’object store distribuito di Ray, e il picco di banda cala da circa 1 GB/s a 760 MB/s, un quinto in meno.
Il numero grande è sempre lo stesso: da 2 a 15 volte più veloce. Il numero piccolo — la qualità — è quello che, di proposito, non si muove.
Cosa Matrix non fa
Vale la pena leggere questi risultati per ciò che sono: guadagni di ingegneria, non di intelligenza. In tutti e tre i casi la qualità dei dati resta pari a quella della linea di base — accordo, ricompensa, punteggi non migliorano di una virgola. Matrix genera gli stessi dati più in fretta e a costo minore; non li rende più buoni. È un merito, non un difetto, ma va detto chiaro per non confondere velocità e valore.
Il secondo limite è la soglia d’ingresso. Tutto questo presuppone un cluster serio: SLURM, Ray, decine o centinaia di GPU A100 e H100, container e servizi d’inferenza distribuiti. È uno strumento per chi genera dati su scala industriale, non per un portatile. Il vantaggio dipende inoltre dal carico: dove il calcolo domina la parallelizzazione paga, dove domina l’I/O molto meno, come gli autori stessi mostrano. Anche la tolleranza ai guasti è pragmatica più che completa: invece di ricostruire le code interrotte, Matrix confina gli agenti sui nodi «permanenti» e lascia solo l’inferenza sulle macchine opportunistiche che possono sparire. Infine, il paper valuta il throughput e la parità di qualità sui benchmark, ma non entra nel merito di quanto quei dati sintetici migliorino davvero i modelli addestrati a valle: quella verifica sta altrove.
Perché è importante
Per anni la parte affascinante dell’AI è stata l’architettura dei modelli. Oggi una fetta crescente del lavoro reale è idraulica: come far scorrere abbastanza dati, abbastanza in fretta, attraverso abbastanza macchine. Matrix è un pezzo di quell’idraulica, e la sua tesi è che la strozzatura non stia nei modelli ma nel modo in cui li si coordina — nel direttore d’orchestra che pretende di seguire ogni strumento. Toglierlo, e lasciare che ogni compito porti con sé la propria partitura, è il tipo di semplificazione che libera un ordine di grandezza di velocità senza inventare nulla di nuovo sul fronte dell’intelligenza. Gli autori annunciano il rilascio open source del framework, il che rende la mossa verificabile e, per chi ha il cluster, riutilizzabile. In un settore che misura sempre più i propri progressi dalla quantità di dati che riesce a fabbricarsi da solo, chi controlla l’idraulica ha un vantaggio silenzioso ma concreto.
Il paper
Dong Wang, Yang Li, Ansong Ni et al. (FAIR at Meta), Matrix: Peer-to-Peer Multi-Agent Synthetic Data Generation Framework, arXiv, 27 novembre 2025. Disponibile su arXiv: arxiv.org/abs/2511.21686. Codice: github.com/facebookresearch/matrix.
I commenti sono riservati agli iscritti.
Accedi per commentare