O echipă de cercetători a publicat pe 7 noiembrie studiul Hibana, despre rularea agenților AI pe calculatoare în care procesorul și grafica împart memoria. Pe un singur NVIDIA DGX Spark, autorii raportează până la 3,4 ori mai multe sarcini de agent finalizate pe oră și un debit de generare de până la 3,9 ori mai mare față de cea mai rapidă implementare de referință în testele respective. Studiul este publicat ca preprint, iar cifrele provin din evaluarea autorilor.
De ce memoria partajată schimbă problema de inferență
DGX Spark folosește cipul GB10, cu 128 GB de memorie unificată LPDDR5X și o lățime de bandă de vârf de 273 GB/s, conform specificațiilor NVIDIA. Procesorul și unitatea grafică accesează această capacitate în comun. Volumul de memorie permite încărcarea unor modele mari pe un sistem compact. La generarea succesivă a tokenurilor, citirea ponderilor și transferul lor către unitățile de calcul pot însă limita ritmul în care sunt produse răspunsurile.
Un agent revine de mai multe ori la același model. Într-o sarcină de programare, poate cere o propunere, executa un test printr-un instrument și trimite apoi rezultatul acestuia modelului. Fiecare revenire extinde sau modifică materialul deja procesat. Motorul de inferență poate păstra în memorie o reprezentare a contextului și o poate reutiliza. Cu mai multe sesiuni active, contextul uneia poate fi evacuat pentru a face loc alteia, iar revenirea la prima sesiune presupune refacerea unei părți din calcule.
Hibana abordează atât transferul ponderilor, cât și păstrarea stării între pași. În implementarea descrisă, unele ponderi folosite la generare sunt stocate într-o reprezentare pe trei biți, cu o tabelă de valori în format FP8. Autorii adaptează și selecția experților în modelele care activează doar o parte din rețea la fiecare pas. Scopul este ca mai multe cereri procesate împreună să refolosească aceleași date încărcate, reducând citirile repetate din memoria partajată.
Motorul poate muta starea unor sesiuni pe SSD când spațiul de lucru din memorie se umple, apoi o poate încărca la următoarea cerere. O a treia tehnică privește decodarea speculativă. O componentă mai mică propune mai multe tokenuri, iar modelul țintă le verifică. Hibana adaptează numărul de propuneri la cât de des au fost acceptate recent și la costul verificării. La o acceptare scăzută, un șir prea lung de propuneri ar consuma resurse pentru rezultate care sunt apoi respinse.
Cum au fost măsurate viteza și sarcinile finalizate
Autorii au testat Qwen3.8-27B, Qwen3.8-Flash-Next și două modele din familia NVIDIA Nemotron, Bolt și Super. Au inclus vLLM, NVIDIA Flare, llama.cpp și TensorFold ca referințe. Testul SPEED-Bench măsoară debitul de generare pe măsură ce crește numărul de cereri simultane. În configurația cu Qwen3.8-Flash-Next, vârful Hibana la 64 de cereri a fost de 3,9 ori cel al Flare la 32 de cereri. La același nivel de 32 de cereri, raportul a fost de 3,1 ori, potrivit lucrării.
Pentru sarcinile complete, cercetătorii au redat sesiuni înregistrate din AgentPerf-Local. În acest test, debitul depinde și de cât context refolosește motorul la întoarcerea unui agent. În condițiile optime de concurență ale fiecărui sistem, Hibana a finalizat între 1,5 și 3,4 ori numărul de sarcini pe oră al celei mai rapide referințe, în funcție de model. Cu Qwen3.8-Flash-Next, autorii raportează 168 de sarcini pe oră la 32 de agenți în acel protocol.
În unele sesiuni redate, ultima porțiune a cererii se modifică de la un pas la altul. Un motor care poate recupera o stare salvată înainte de acea porțiune evită recalcularea materialului comun. Cercetătorii au rulat și o variantă în care au eliminat rescrierea din acele sesiuni. La 16 agenți cu Qwen3.8-Flash-Next, avantajul față de vLLM s-a redus de la 3,1 ori la 1,9 ori în această variantă. Experimentul separă astfel o parte din câștigul produs de refolosirea contextului de diferența de debit la decodare.
Lucrarea măsoară separat efectul reluării unei sesiuni în condiții de memorie solicitată. Un experiment a redat 192 de conversații, cu câte 32 de agenți care trimiteau cereri succesive. Contextul cumulat a ajuns la aproximativ dublul capacității de cache din memoria grafică. Pentru acel test, păstrarea stării pe SSD a redus partea de context recalculată la revenirea unei sesiuni. Condițiile experimentului includ lipsa timpului de așteptare pentru instrumente și folosirea unor conversații înregistrate.
Precizia modelului și stadiul proiectului
Studiul raportează și costul unor optimizări în scorurile de calitate. Pentru Qwen3.8-Flash-Next, configurația orientată spre viteză a rămas la cel mult 3,6 puncte procentuale sub implementarea exactă în evaluările raportate în tabelul dedicat. Modificarea ponderilor și acceptarea mai permisivă a unor propuneri pot schimba distribuția rezultatelor. Autorii prezintă aceste cifre separat de cele de debit, deoarece o sarcină poate termina mai repede și poate produce un rezultat diferit.
În aceste evaluări, LiveCodeBench urmărește sarcini de programare, iar IFBench măsoară respectarea instrucțiunilor. Scorurile testează comportamentul modelului în condițiile stabilite pentru fiecare set. Debitul indică numărul de tokenuri produse sau de sarcini terminate într-un interval. Pentru un agent care revine frecvent după rezultate intermediare contează și timpul până la primul token al noului răspuns.
Lucrarea indică un depozit public pentru codul Hibana. La verificarea din 11 noiembrie, depozitul nu conținea fișiere. Rezultatele descriu configurațiile evaluate de autori, cu modelele, precizia și cererile specificate. Pentru o instalare într-o firmă contează în plus disponibilitatea efectivă a software-ului, numărul de sesiuni și timpul petrecut în aplicațiile chemate de agenți. Un test de generare pe o singură stație și o automatizare care așteaptă după alte sisteme măsoară componente diferite ale timpului total.
