Le swarm di agenti accelerano l'inferenza ma consumano più token

Quattro agenti in parallelo dimezzano il tempo di esecuzione, ma consumano circa il doppio dei token totali: è il compromesso messo a fuoco da Toby Ord sulle “swarms”, ripreso da Import AI 475¹.

Ord tratta le swarm come uno scaling dell’inferenza. Non si potenzia un singolo modello, si moltiplicano gli agenti che lavorano sullo stesso compito. Obiettivo: comprimere la latenza “di muro”, non ottimizzare i token per singola chiamata¹.

Caso esemplare: una swarm a quattro agenti che, a parità di performance con un singolo agente, richiede circa il doppio dei token complessivi. Ogni agente usa metà dei token rispetto al singolo. Eseguendo in parallelo, il sistema punta allo stesso risultato in metà del tempo¹.

Velocità, prima di tutto. Se contano i minuti, il parallelismo rende. Il costo è un consumo totale di token più alto, compensato da passaggi più brevi per singolo agente e da una latenza ridotta sull’intero ciclo¹.

Rendimenti decrescenti in agguato. Aumentare gli agenti non produce benefici lineari. Gli agenti tendono a pestarsi i piedi (“Stepping on Toes”), e ogni nuovo partecipante aggiunge meno del precedente¹.

Il quadro è netto: più agenti riducono la latenza, al prezzo di più token totali. Conviene quando il vincolo è il tempo e si può spendere budget di token per guadagnare minuti o secondi. Se invece il tetto di token è il limite principale, il singolo agente resta la scelta parsimoniosa¹.

Inference‑scaling, in questo senso, significa organizzare il lavoro tra più agenti per tagliare il tempo, senza ridurre il fabbisogno totale di token per una data qualità. La leva è l’architettura della soluzione, non la grandezza del modello¹.

Nessun “numero magico” di agenti è indicato. Esiste però un riferimento pratico: il caso a quattro agenti sopra, con raddoppio dei token complessivi, metà per agente e tempo teorico dimezzato grazie al parallelismo. Oltre, i benefici tendono a calare per le interferenze tra agenti¹.

Quando usarle, dunque? Due criteri operativi emergono da Ord: adottare una swarm se il collo di bottiglia è la latenza e il budget di token consente un aumento complessivo; restare su un singolo agente se la priorità è contenere i token, accettando tempi più lunghi a parità di performance¹. Per esempi e limiti del metodo, rimando all’analisi originale citata in Import AI 475¹.