Inteligența artificială agentică va întâmpina un zid de infrastructură înaintea unuia de inteligență

Modelele se îmbunătățesc mai repede decât capacitatea noastră de a le deservi în funcție de ceea ce li se cere.

Cele mai multe dezbateri despre direcția în care se îndreaptă agenții AI se concentrează asupra capabilităților. Poate modelul să planifice în mod fiabil? Își poate corecta propriile greșeli? I se poate încredința o acțiune cu consecințe?

Acestea sunt întrebări reale. Dar nici ele nu vor decide dacă agenții vor fi implementați la scară largă în următorii câțiva ani, pentru că există o constrângere mai apropiată, care se face simțită mai repede. Agenții sunt dificil și costisitor de deservit, iar această dificultate crește odată cu capabilitățile pe care toată lumea vrea să le adauge.

Un chatbot și un agent presupun sarcini diferite

O solicitare conversațională presupune un singur schimb complet de cerere și răspuns. Trimiți promptul, primești tokenurile, apoi conexiunea se închide. Poți grupa solicitările, poți memora în cache prefixul și poți estima debitul folosind o singură valoare.

O solicitare adresată unui agent este o sesiune. Agentul apelează un instrument, așteaptă, citește rezultatul, decide ce să facă în continuare, apelează alt instrument și, în cele din urmă, răspunde. O sarcină relativ simplă poate presupune șase sau opt apeluri ale modelului, cu perioade de așteptare între ele.

Această diferență contează dintr-un motiv care nu are nicio legătură cu inteligența. Între pași, agentul păstrează starea — conversația, rezultatele instrumentelor și raționamentul acumulat. În timpul servirii modelului, starea este păstrată în memoria GPU sub forma cache-ului pentru chei și valori (KV), care ocupă memorie pe toată durata sesiunii, inclusiv în secundele în care agentul așteaptă răspunsul unui API care nu-ți aparține.

Prin urmare, capacitatea nu se mai măsoară în „cereri pe secundă”, ci în „sesiuni concurente rezidente în memorie”. Un sistem care putea deservi fără probleme o mie de solicitări conversaționale pe secundă poate ajunge să deservească doar câteva zeci de sesiuni concurente cu agenți, pe același hardware.

Așteptarea este partea costisitoare

Iată aspectul incomod: în timpul unui apel către un instrument, agentul nu face nimic. Nu generează tokenuri. Nu consumă putere de calcul. Memoria GPU rămâne însă ocupată, deoarece eliminarea contextului din memorie și recalcularea lui ar costa mai mult decât păstrarea acestuia.

Cel mai costisitor hardware al tău este rezervat unei solicitări care, în acel moment, așteaptă rezultatul unei interogări în baza de date.

În sistemele distribuite tradiționale, problema aceasta a fost rezolvată cu mult timp în urmă: eliberezi resursa, apoi reiei lucrul când sosește răspunsul. Pentru a face același lucru la servirea modelelor, trebuie să muți cache-ul KV în memoria gazdei sau pe disc, apoi să-l restaurezi, iar costul transferului este suficient de mare încât majoritatea sistemelor nu se obosesc. Cercetările exact pe această temă sunt în plină desfășurare tocmai pentru că problema este costisitoare.

Execuția secvențială agravează problema mai mult decât ar fi necesar

Aproape toate cadrele de lucru pentru agenți execută apelurile către instrumente unul după altul. Modelul solicită o verificare a vremii, o primește, solicită verificarea calendarului, o primește, apoi solicită o căutare de zboruri și o primește.

Adesea, aceste trei apeluri nu depind unul de altul. Ar putea fi executate simultan. Dacă sunt executate secvențial, latența este suma duratelor lor. Dacă sunt executate concurent, latența este egală cu durata celui mai lung apel.

Aceasta nu este o observație nouă despre agenți, ci același principiu structural care se aplică oricărui sistem ce rulează mai multe modele sau servicii în limita unui singur buget de latență. Latența totală ar trebui să fie determinată de cel mai lung traseu din graful de dependențe, nu de suma duratelor tuturor etapelor. Acest lucru contează mai mult în cazul agenților deoarece sesiunea rămâne în memoria GPU pe toată durata sa; prin urmare, reducerea timpului total nu doar îmbunătățește experiența utilizatorului, ci mărește în mod direct numărul de sesiuni care încap pe hardware.

Dacă înjumătățești durata sesiunii, capacitatea concurentă se dublează aproximativ, folosind aceleași GPU-uri și fără să schimbi modelul.

Reîncercările se acumulează într-un mod pe care nimeni nu l-a prevăzut

Cadrele de lucru pentru agenți preiau valorile implicite pentru reîncercări din bibliotecile HTTP pe care le folosesc. De obicei, sunt trei încercări.

Modelul reîncearcă și el, în felul său. Când un instrument returnează ceva inutil, un model de raționament încearcă adesea o abordare diferită — ceea ce constituie o reîncercare, doar că nimeni nu a configurat-o.

Suprapune aceste comportamente și obții o politică de nouă încercări: o politică de trei încercări aplicată unui model care, în mod independent, găsește prin raționament încă trei abordări. Nimeni nu a consemnat această politică. Fiecare încercare reprezintă un apel complet al modelului, cu propriile tokenuri și propriile secunde de utilizare a GPU-ului.

Când o dependență încetinește, această amplificare transformă degradarea serviciului într-o întrerupere, iar costul fiecărei încercări este cu ordine de mărime mai mare decât cel al unui apel REST reîncercat.

Cum arată, de fapt, zidul

Nu este vorba despre o limită a capabilităților, ci despre ceva mai banal: o problemă de economie unitară care blochează proiectele la trecerea de la faza-pilot la producție.

Proiectul-pilot funcționează. Are zece utilizatori, latența este acceptabilă, iar factura este neglijabilă. Apoi cineva face o estimare pentru zece mii de utilizatori, iar necesarul de GPU-uri devine nerealist — nu pentru că modelul este lent, ci pentru că fiecare sesiune concurentă ocupă memorie pe toată durata sa, iar această durată include și timpul de așteptare.

Aceasta este etapa în care multe demonstrații interne promițătoare se opresc discret.

Ce poate deplasa bariera

Nimic exotic, iar toate țin de infrastructură, nu de modelare:

Executați apelurile independente către instrumente în paralel. Cel mai mare câștig individual disponibil astăzi, fără să fie nevoie de hardware nou.

Folosiți durata sesiunii drept indicator al capacității. Nu numărul de tokenuri pe secundă. Nici gradul de utilizare a GPU-ului. Contează cât timp rămâne starea în memorie și câte sesiuni încap.

Stabiliți bugetul de reîncercări la nivelul întregului sistem, nu pentru fiecare apel în parte. O limită globală — reîncercările reprezentând un procent mic din traficul total — împiedică efectul cumulativ descris mai sus. Atât practicile SRE ale Google pentru gestionarea suprasolicitării, cât și bugetele de reîncercări ale Envoy pun în aplicare această idee în afara stivei AI.

Separați raționamentul de execuție. Folosiți un model mare pentru planificare și unul mult mai mic pentru pașii mecanici. Cele mai multe dintre acțiunile unui agent nu necesită un model de ultimă generație.

Faceți ieftină eliminarea contextului. Cache KV cuantizat, atenție paginată și căi de descărcare a sesiunilor inactive. Aici se desfășoară în prezent cele mai interesante lucrări privind servirea modelelor.

Modelele vor continua să se îmbunătățească. Asta pare sigur. Dacă agenții vor deveni infrastructură sau vor rămâne simple demonstrații depinde de ceva mai puțin spectaculos: dacă putem deservi o sarcină de lucru care păstrează memorie costisitoare cât timp așteaptă și dacă încetăm să plătim costul cumulat al unei secvențe atunci când am putea plăti doar pentru calea ei cea mai lungă.

Am publicat modelul de execuție care stă la baza ultimului punct — execuția concurentă a apelurilor dependente către modele, în cadrul unui singur buget de latență — în „Execuția asincronă a grafurilor de inferență pentru rutarea modelelor în sistemele de învățare automată”, International Journal of Computer Trends and Technology 72(10), octombrie 2024. Pentru integrarea modelelor generative în sistemele de decizie cu latență limitată, consultați „Platforme de tranzacționare și decizie îmbogățite cu LLM-uri: conectarea inteligenței generative cu sistemele de decizie financiară”, Journal of Information Systems Engineering and Management 11(1s), 2026.