Uri Peled racconta su Towards Data Science un problema che chiunque scali agenti LLM in produzione prima o poi incontra: man mano che si aggiungono agenti, la latency cresce e arrivano i timeout. Il primo istinto è dare la colpa ai provider — “sarà OpenAI sotto carico”. Poi arriva la realizzazione scomoda: il problema non era OpenAI, era il codice.
Il setup di Planck, l’azienda dell’autore, era un singolo service dove una richiesta attivava tutti gli agenti insieme, ciascuno con decine di chiamate ai propri sub-agenti, tutto in async con aiohttp. Sulla carta è ideale: quasi tutto è I/O bound, quindi la latency dovrebbe dipendere dalla chiamata LLM più lenta, non dal numero di agenti. Nella pratica, non è così.
In debug comparivano warning di event-loop lag: il task è finito, il LLM ha risposto, ma l’event loop non riesce a occuparsene perché è impegnato altrove. In Python, per via del GIL, un solo thread esegue codice alla volta: l’event loop era occupato a fare lavoro CPU-bound. I primi guadagni sono facili — passare da json a orjson per serializzazione e deserializzazione, e alzare il limite di connessioni di aiohttp (di default 100), ma solo fino a un certo punto. Anche così, all’aumentare degli agenti la latency continua a salire.
Il punto vero: i task non sono puramente I/O bound. Ogni volta che arriva una risposta LLM, l’event loop deve eseguire un po’ di lavoro CPU — deserializzare, contare token, validare dati — prima di passare alla coroutine successiva. Singolarmente sono operazioni quasi gratis; su centinaia o migliaia di chiamate concorrenti diventano il collo di bottiglia. L’event loop di asyncio, da solo, regge benissimo centinaia di migliaia di coroutine che fanno solo sleep: il problema nasce quando c’è CPU di mezzo. E non è un difetto solo di Python: anche in Go o Java c’è un limite ai processi paralleli, perché c’è un limite ai core.
La soluzione è di design, non di ottimizzazione riga per riga: nessun singolo processo deve essere responsabile di tutti gli agenti. A Planck hanno introdotto un router che distribuisce ogni richiesta su più worker, ognuno con il proprio event loop e connection pool, responsabile solo di un sottoinsieme di agenti. Il lavoro CPU non sparisce, ma viene diviso in unità scalabili orizzontalmente. Il messaggio per chi lavora con agenti in produzione: l’async I/O rimuove l’attesa, non la computazione, e il codice ben scritto non compensa un sistema progettato male.
In sintesi
- Con l’async, il collo di bottiglia non è il LLM ma il lavoro CPU dopo ogni risposta, che compete sullo stesso event loop.
- Le ottimizzazioni (orjson, connection limit) aiutano, ma non risolvono il problema di design.
- La cura è distribuire gli agenti su più processi/worker, non spingere tutto in un solo event loop.
Fonte: Why Adding More AI Agents Made Our System Slower — https://towardsdatascience.com/why-adding-more-ai-agents-made-our-system-slower/
Hai qualcosa da aggiungere? Unisciti alla discussione.