Dispozitivul tău Edge a fost evaluat pe un pas înainte. Agentul tău va rula o buclă.

Discuția despre hardware în contextul AI la margine a devenit mult mai sinceră în ultimul an. Un articol recent de pe acest site a susținut că vechea ierarhie de proiectare — „maximiză debitul, apoi gestionează energia și termica în jurul lui” — s-a inversat, iar pentru implementările industriale energia ocupă acum poziția principală, în timp ce debitul brut a ajuns la final. Aceasta continuă un argument pe care această publicație îl promovează de ceva timp: dispozitivele la margine sunt „limitate termic, nu de MIPS/compute”, iar smartphone‑urile se află deja la aceste limite. Ambele sunt corecții reale și întârzie de mult.

Dar încă poartă o presupunere din lumea pe care o corectează. Fiecare element din acea ierarhie este bugetat în funcție de o sarcină presupusă, iar sarcina pe care aproape toată lumea încă o bugetează este un singur pas înainte: modelul primește o intrare, produce o ieșire și siliciul are un moment să se răcească.

Asta nu este ceea ce face un agent. Un agent decide, apelează o unealtă, citește ce primește înapoi și decide din nou. De câte ori parcurge acea buclă nu este o proprietate a hardware‑ului tău și nici nu este, în mod real, o proprietate a modelului tău. Este o proprietate a problemei pe care cineva i‑a încredințat-o în acea dimineață. Am agenți care rulează pe hardware la margine și lucrul care mi‑a luat cel mai mult timp să accept nu a fost că erau lenți, ci că costul unei rulări era stabilit undeva la care nu aveam vizibilitate în timpul proiectării.

Bucla este nelimitată până când cineva introduce un număr

Acesta nu este un cadru retoric; este modul în care cadrele sunt construite în realitate. În SDK‑ul OpenAI pentru Agenți, executorul „rulează o buclă”, iar când modelul produce apeluri de unealtă, mediul de execuție va „rula acele apeluri de unealtă, va adăuga rezultatele și va rula din nou bucla”. Singurul lucru care o oprește este o limită de tururi — depășești max_turns și primești o excepție — iar documentația menționează că poți transmite max_turns=None pentru a dezactiva complet limita.

Pe un server, acel număr reprezintă o decizie de facturare. Cineva observă factura.

Pe un dispozitiv, acel număr reprezintă o decizie termică, deoarece lungimea buclei este ciclul de lucru. Iar ciclul de lucru este singura variabilă cu care răcirea pasivă nu poate concura.

Încărcarea susținută ceva diferit unui telefon decât un benchmark

Un benchmark din martie 2026 a supus patru platforme exact acestui tip de încărcare: un model cuantizat de 1,5 miliarde de parametri, un prompt fix de 258 de tokeni, douăzeci de rulări consecutive, măsurând debitul, energia și temperatura la fiecare. Este un preprint și evaluează un singur model pe patru dispozitive, așa că tratează cifrele specifice ca o caracterizare a acelor platforme, nu ca o lege a naturii. Forma rezultatului este cea care contează.

Un iPhone 16 Pro a atins un maxim de 40,35 tokeni pe secundă și nu a putut menține acest nivel. Degradarea a apărut în primele două inferențe. S-a stabilit la 22,56 tokeni pe secundă — o reducere de 44 % — și a rămas limitat pentru 65 % din benchmark. Scalarea dinamică a tensiunii și frecvenței, mecanismul care scade viteza ceasului când temperatura joncțiunii crește, a făcut exact ce există să facă.

Galaxy S24 Ultra a eșuat diferit și mai grav. În loc să se degradeze, guvernatorul termic Android a impus un plafon dur al frecvenței GPU la a șasea iterație, la 78,3 °C, și inferența s‑a oprit. Autorii subliniază, mai bine decât aș fi putut eu, că pentru implementările de agenți, aceasta este „mai disruptivă decât degradarea grațioasă”, pentru că sistemul nu devine doar mai lent; devine inutilizabil.

Acum reține detaliul care face această constatare condamnatoare și nu doar interesantă. Fiecare dintre cele douăzeci de rulări a folosit același prompt. Acesta este cel mai prietenos workload pe care hardware‑ul unui agent îl va vedea vreodată, iar două telefoane flagship nu l‑au putut susține pentru douăzeci de repetiții. Nu este o descoperire nouă — punctul MELT, prezentat la MobiCom în 2024, a concluzionat că, din motive de energie și termice, „execuția continuă a LLM‑urilor rămâne evazivă”. Două ani și mai multe noduri de procesare mai târziu, aceeași barieră.

Două curbe se apropie una de cealaltă, iar produsul tău se rupe unde se intersectează

Bucla unui agent este mai gravă decât un prompt repetat într-un mod specific și mecanic.

Decodarea este limitată de lățimea de bandă a memoriei — debitul este guvernat de cât de repede modelul poate citi memoria cache de tip cheie‑valoare, nu de câte operații poate efectua teoretic cipul. Acea cache crește odată cu contextul. Fiecare pas al buclei adaugă un rezultat de unealtă, o observație, un plan parțial — așa că pasul zece generează tokeni pe o cache semnificativ mai mare decât pasul unu.

Între timp, dispozitivul se încălzește, iar guvernatorul trage în jos ceasurile.

Astfel, costul per pas crește exact în momentul în care capacitatea dispozitivului de a-l plăti scade. Cele două curbe converg, iar oriunde se întâlnesc este locul în care produsul tău eșuează. Nu este niciodată pasul unu. Pasul unu este acolo unde ai testat.

Există și o problemă de scară în spatele acestui fenomen. Munca generativă este pur și simplu un tip diferit de cheltuială față de ceea ce siliconul de margine a consumat un deceniu: măsurat pe 88 de modele, costul clasificării textului este în jur de 0,002 kWh la o mie de inferențe, comparativ cu 0,047 kWh pentru generarea de text — aproximativ de douăzeci de ori mai mult, înainte ca orice buclă să îl amplifice. Aceste măsurători au fost luate pe un GPU de centru de date, nu pe un telefon, așa că ele trebuie citite ca un raport între tipurile de muncă, nu ca o valoare de putere pentru dispozitivul tău. Pentru scară, același studiu estimează că o încărcare completă a unui smartphone consumă 0,022 kWh.

Cumpără pe jouli per sarcină finalizată, nu pe tokeni pe secundă

Cel mai util rezultat din acel benchmark din 2026 este cel care pare cel mai puțin impresionant.

Un NPU Hailo‑10H a gestionat 6,9 tokeni pe secundă la sub 2 watti. Lent — cu adevărat lent, și autorii confirmă asta. Dar coeficientul său de variație al debitului a fost de 0,04 %, cu două ordine de magnitudine mai stabil decât orice altceva testat. GPU‑ul laptopului din același studiu a livrat 131,7 tokeni pe secundă la 34,1 watti.

Apoi compară-le din punct de vedere al energiei, nu al vitezei: 270,5 miliojouli per token pe NPU‑ul mic versus 297,3 pe GPU. În ciuda unei diferențe de nouăsprezece ori în debit, micuțul component a efectuat puțin mai multă calculare per joule — și a făcut-o practic fără variație.

Dacă selectezi hardware pe baza tokenilor pe secundă, cumperi pe cel rapid. Dacă selectezi pe baza capacității de a finaliza o buclă limitată la un cost previzibil, ceea ce are cu adevărat nevoie un agent, ierarhia se schimbă. Unitatea care ar trebui să apară pe fișa tehnică este jouli per sarcină finalizată, cu o valoare de variație lângă ea. Un benchmark care raportează debitul maxim îți spune despre prima inferență a zilei.

Obiecția sinceră și ce nu rezolvă

Răspunsul evident este că aceasta este o problemă tranzitorie: siliciul se îmbunătățește, NPU‑urile evoluează, iar orice scris despre un telefon din 2026 va părea nostalgic. Sau, mai practic, să descarci pașii costisanți către un server.

Aș paria eu însumi pe hardware. Dar descărcarea este drumul pe care l‑ai mutat la margine pentru a-l evita, iar un agent nu plătește o singură dată — plătește la fiecare pas al buclei, iar lungimea buclei este lucru pe care nu îl poți prezice. Design‑urile hibride nu elimină variația; o relocă pe rețea.

Asimetria mai profundă nu se mută odată cu nodurile de procesare. Bugetul unui dispozitiv este fixat în timpul proiectării. Cererea unui agent este decisă în timp de execuție, de ceea ce un utilizator a solicitat. Un silicon mai bun ridică plafonul. Nu îi spune agentului unde este plafonul.

Așadar, spune-i. Stabilește limita de tururi în specificația produsului în loc să o descoperi într-o revizuire de cod și alege numărul din învelișul termic: decide câte etape încap, apoi proiectează agentul să producă cel mai bun răspuns disponibil la acea limită, în loc de răspunsul ideal la una arbitrară. Trateaz‑o ca pe un termen limită, nu ca pe un țintă.

Apoi oferă agentului bugetul ca intrare. Spațiul rămas, starea bateriei, dacă platforma a început deja să limiteze — acestea fac parte din context, la fel ca ora curentă. Un agent care știe că se află la pasul opt din zece poate rezuma și comite. Un agent care nu știe va continua să exploreze până când sistemul de operare decide în locul lui.

Și testează coada, nu media, ceea ce pe un dispozitiv fizic înseamnă testare în simulare. Cazul de eșec nu este niciodată rularea curată. Este rularea care a durat paisprezece pași pentru că o unealtă a returnat ceva ambiguu la pasul trei, și nu poți enumera acele cazuri manual pe un telefon care trebuie să se răcească între încercări. Sistemele mele se antrenează în principal pe simulări din acest motiv: comportamentul interesant apare în rulările lungi, iar rulările lungi sunt exact ceea ce hardware‑ul nu îți permite să probezi manual.

Nimic din toate acestea nu necesită un cip mai rapid. Necesită să recunoaștem că sarcina și‑a schimbat forma. Nimeni nu livrează un dispozitiv a cărui baterie este dimensionată pentru o singură fotografie. În continuare livrăm dispozitive a căror buget termic este dimensionat pentru o singură inferență.