Din Edge-enhed blev benchmarket på et fremadrettet pass. Din agent vil køre en løkke.

Hardware‑diskussionen om edge AI er blevet meget mere ærlig det sidste år. Et senere indlæg på dette site argumenterede for, at den gamle designhierarki — “maksimér gennemløb, og håndtér derefter strøm og termik omkring det” — er vendt på hovedet, og at for industrielle implementeringer er strøm nu i første række, mens rå gennemløb kommer sidst. Det følger en argumentation, som denne publikation har fremført i et stykke tid: at edge‑enheder er “termisk begrænsede, ikke MIPS/compute‑begrænsede”, og at smartphones allerede befinder sig ved disse grænser. Begge er reelle korrektioner, og de er over tid.

Men den bærer stadig én antagelse fra den verden, den korrigerer. Hvert element i den hierarki budgetteres mod en antaget arbejdsbyrde, og den arbejdsbyrde, som næsten alle stadig budgetterer mod, er et enkelt fremadrettet pass: en model modtager en input, producerer en output, og silicium får et øjeblik til at køle ned.

Det er ikke, hvad en agent gør. En agent beslutter, kalder et værktøj, læser hvad der kommer tilbage, og beslutter igen. Hvor mange gange den går rundt i den løkke, er ikke en egenskab ved din hardware, og det er heller ikke egentlig en egenskab ved din model. Det er en egenskab ved det problem, nogen gav den om morgenen. Jeg har agenter kørende på edge‑hardware, og det, der tog mig længst tid at acceptere, var ikke, at de var langsomme. Det var, at omkostningen ved en kørsel blev sat et sted, jeg ikke havde indsigt i på designtid.

The Loop Is Unbounded Until Someone Types a Number

Dette er ikke en retorisk indramning; det er sådan, rammerne faktisk er bygget. I OpenAI’s Agents SDK “kører” runneren en løkke, og når modellen producerer værktøjskald, vil runtime “køre de værktøjskald, tilføje resultaterne og køre løkken igen.” Det eneste, der stopper den, er en turgrænse — overskrid max_turns får du en undtagelse — og dokumentationen bemærker, at du kan sætte max_turns=None for at deaktivere grænsen fuldstændigt.

På en server er det tal et faktureringsvalg. En eller anden lægger mærke til fakturaen.

På en enhed er det tal et termisk valg, fordi løkkelængden er arbejdscyklus. Og arbejdscyklus er den ene variabel, som passiv køling ikke kan argumentere imod.

Sustained Load Does Something Different to a Phone Than a Benchmark Does

Et benchmark fra marts 2026 satte fire platforme under netop denne form for belastning: en kvantiseret 1,5‑milliard‑parameter‑model, en fast 258‑token‑prompt, tyve på hinanden følgende kørsel, hvor gennemløb, strøm og temperatur blev målt for hver. Det er en preprint, og den benchmarker én model på fire enheder, så betrag de specifikke tal som en karakterisering af de platforme frem for en lovmæssighed. Formformen af resultatet er det, der betyder noget.

En iPhone 16 Pro toppede ved 40,35 token per sekund og kunne ikke holde den hastighed. Forringelse viste sig inden for to inferenser. Den stabiliserede sig på 22,56 token per sekund — et fald på 44 % — og forblev throttlet i 65 % af benchmarken. Dynamisk spændings‑ og frekvensskalering, mekanismen der sænker clock‑hastigheder, når junction‑temperaturen stiger, gjorde præcis, hvad den er designet til.

Galaxy S24 Ultra fejlede på en anden måde, og værre. I stedet for at degradere pålagde Android‑thermal‑governoren et hårdt GPU‑frekvensgulv ved iteration seks, ved 78,3 °C, og inferensen stoppede. Forfatterne påpeger bedre, end jeg kunne, at for agent‑implementeringer er dette “mere forstyrrende end en gradvis degradering”, fordi systemet ikke blot bliver langsommere; det bliver ubrugeligt.

Hold nu fast i detaljen, der gør dette fordømmende snarere end blot interessant. Hver af de tyve kørsel brugte den samme prompt. Det er den mest venlige arbejdsbyrde, en agents hardware nogensinde vil se, og to flaggskibe‑telefoner kunne ikke opretholde den i tyve gentagelser. Dette er heller ikke en ny opdagelse — MELT‑point, præsenteret på MobiCom i 2024, konkluderede, at på energi‑ og termisk grundlag “den kontinuerlige udførelse af LLM‑er forbliver undvigende.” To år og flere proces‑nodes senere er den samme mur stadig der.

Two Curves Move Toward Each Other, and Your Product Breaks Where They Cross

En agents løkke er værre end en gentaget prompt på en specifik, mekanisk måde.

Dekodning er begrænset af hukommelses‑båndbredde: gennemløb styres af, hvor hurtigt modellen kan læse sin key‑value‑cache, ikke af hvor mange operationer chippen teoretisk kan udføre. Cachen vokser med konteksten. Hvert løkketrin tilføjer et værktøjsresultat, en observation, en delvis plan — så trin ti genererer token mod en væsentligt større cache end trin et.

Imens varmer enheden op, og governoren sænker clock‑hastighederne.

Så omkostningen pr. trin stiger præcis i det øjeblik, hvor enhedens kapacitet til at betale den falder. De to kurver konvergerer, og hvor de mødes, fejler dit produkt. Det er aldrig trin et. Trin et er, hvor du testede.

Der er også et skaleringsproblem under dette. Generativt arbejde er simpelthen en anden udgiftsorden end hvad edge‑silicium har brugt et årti på at køre: målt på tværs af 88 modeller, tekstklassificering koster omkring 0,002 kWh per tusinde inferenser mod 0,047 kWh for tekstgenerering — cirka tyve gange mere, før nogen løkke multiplicerer det. Disse målinger blev foretaget på en datacenter‑GPU, ikke på en håndholdt enhed, så læs dem som et forhold mellem typer af arbejde frem for et strømforbrugstal for din enhed. For skalaen placerer den samme undersøgelse en fuld smartphone‑opladning på 0,022 kWh.

Buy on Joules per Finished Task, Not on Tokens per Second

Det mest nyttige resultat i det 2026‑benchmark er det, der ser mindst imponerende ud.

En Hailo‑10H NPU håndterede 6,9 token per sekund under 2 watt. Langsom — virkelig langsom, og forfatterne siger det. Men dens gennemløb‑koefficient for variation var 0,04 %, to størrelsesordener mere stabil end alt andet testet. Laptop‑GPU’en i samme studie leverede 131,7 token per sekund ved 34,1 watt.

Sammenlign så de to på energi i stedet for hastighed: 270,5 millijoule per token på den lille NPU mod 297,3 på GPU’en. På trods af en nitten‑gange forskel i gennemløb udførte den lille del lidt mere beregning per joule — og det gjorde den med stort set ingen variation.

Hvis du vælger hardware på token per sekund, køber du den hurtige. Hvis du vælger på evnen til at fuldføre en begrænset løkke til en forudsigelig pris, som en agent faktisk har brug for, ændres rangeringen. Enheden, der bør stå på specifikationsarket, er joule per færdig opgave, med et variations‑tal ved siden af. Et benchmark, der rapporterer spidst gennemløb, fortæller dig kun om den første inferens på dagen.

The Honest Objection, and What It Does Not Solve

Det åbenlyse svar er, at dette er et forbigående problem: silicium forbedres, NPU’er modnes, og alt skrevet om en telefon fra 2026 vil fremstå som gammeldags. Eller, mere praktisk, at de dyre trin flyttes til en server.

Jeg ville selv tage hardware‑væddemålet. Men offloading er den rundtur, du flyttede til kanten for at undgå, og en agent betaler den ikke én gang — den betaler den pr. løkketrin, og løkkelængden er det, du ikke kan forudsige. Hybrid‑design fjerner ikke variansen; de flytter den til et netværk.

Den dybere asymmetri flytter sig ikke med proces‑nodes. En enheds budget er fastlagt på designtid. En agents efterspørgsel afgøres på køretid, af hvad en bruger har bedt om. Bedre silicium hæver loftet. Det fortæller ikke agenten, hvor loftet er.

Så fortæl den. Sæt turgrænsen i produktspecifikationen i stedet for at opdage den i en kodegennemgang, og vælg tallet ud fra det termiske omslag: beslutte hvor mange trin der passer, design så agenten til at levere sit bedste tilgængelige svar inden for den grænse i stedet for sit ideelle svar ved en vilkårlig grænse. Betragt det som en deadline, ikke som et mål.

Giv så agenten budgettet som input. Resterende headroom, batteristatus, om platformen allerede er begyndt at throttle — det hører til i konteksten, på samme måde som den aktuelle tid gør. En agent, der ved, at den er på trin otte af ti, kan sammenfatte og forpligte. En agent, der ikke ved det, vil fortsætte med at udforske, indtil operativsystemet beslutter for den.

Og test halen, ikke medianen, hvilket på en fysisk enhed betyder test i simulation. Fejlsituationen er aldrig den rene kørsel. Det er den kørsel, der tog fjorten trin, fordi et værktøj returnerede noget tvetydigt på trin tre, og du kan ikke enumerere dem manuelt på en telefon, der skal køle ned mellem forsøg. Mine egne systemer træner mod simulationer stort set af denne grund: den interessante adfærd ligger i de lange kørsel, og lange kørsel er netop det, hardware ikke vil lade dig prøve manuelt.

Intet af dette kræver en hurtigere chip. Det kræver at indrømme, at arbejdsbyrden har ændret form. Ingen sender en enhed, hvis batteri er dimensioneret til ét fotografi. Vi sender stadig enheder, hvis termiske budget er dimensioneret til én inferens.