Kant-enheten din ble benchmarket på en fremoverpassering. Agenten din vil kjøre en løkke.

Samtalen om maskinvare for kant‑AI har blitt betydelig mer ærlig det siste året. Et nylig innlegg på dette nettstedet hevdet at den gamle designhierarkien – «maksimer gjennomstrømning, så håndter strøm og termikk rundt den» – har snudd på hodet, og at for industrielle utrullinger er strøm nå hovedfokus, mens rå gjennomstrømning kommer sist. Det følger et argument dette publikasjonen har fremmet en stund: at kant‑enheter er «termisk begrenset, ikke MIPS/beregningsbegrenset», og at smarttelefoner allerede befinner seg ved disse grensene. Begge er reelle korreksjoner, og de er på høy tid.

Men den bærer fortsatt en antakelse fra verden den korrigerer. Hvert element i den hierarkien budsjetteres mot en antatt arbeidsbelastning, og arbeidsbelastningen de fleste fortsatt budsjetterer mot er en enkelt fremoverpassering: en modell mottar en inngang, produserer et utdata, og silisiumet får et øyeblikk til å kjøle seg ned.

Det er ikke hva en agent gjør. En agent bestemmer, kaller et verktøy, leser hva som kommer tilbake, og bestemmer igjen. Hvor mange ganger den går rundt den løkken er ikke en egenskap ved maskinvaren din, og det er egentlig ikke en egenskap ved modellen din heller. Det er en egenskap ved problemet noen ga den den morgenen. Jeg har agenter som kjører på kant‑maskinvare, og det som tok lengst tid for meg å akseptere var ikke at de var trege. Det var at kostnaden for en kjøring ble satt et sted jeg ikke hadde innsikt i på designtid.

Løkken er ubegrenset til noen taster inn et tall

Dette er ikke en retorisk innramming; det er hvordan rammeverkene faktisk er bygget. I OpenAI’s Agents SDK «kjører» runneren en løkke, og når modellen produserer verktøy‑kall, vil kjøretiden «kjøre de verktøy‑kallene, legge til resultatene, og kjøre løkken på nytt». Det eneste som stopper den er en tur‑grense – overskrid max_turns får du en unntak – og dokumentasjonen bemerker at du kan sende max_turns=None for å deaktivere grensen helt.

På en server er det tallet en faktureringsbeslutning. Noen legger merke til fakturaen.

På en enhet er det tallet en termisk beslutning, fordi løkkelengde er arbeidsforholdet. Og arbeidsforholdet er den ene variabelen som passiv kjøling ikke kan argumentere mot.

Vedvarende belastning gjør noe annet med en telefon enn en benchmark gjør

En benchmark fra mars 2026 satte fire plattformer under akkurat denne typen belastning: en kvantisert modell med 1,5 milliarder parametere, en fast prompt på 258 token, tjue påfølgende kjøringer, med måling av gjennomstrømning, strøm og temperatur for hver. Det er en preprint, og den benchmarker én modell på fire enheter, så behandle de konkrete tallene som en karakterisering av disse plattformene snarere enn en naturlov. Formen på resultatet er det som betyr noe.

En iPhone 16 Pro nådde topp med 40,35 token per sekund og klarte ikke å holde den. Nedbrytning viste seg innen to inferenser. Den stabiliserte seg på 22,56 token per sekund – en reduksjon på 44 % – og var throttlet i 65 % av benchmarken. Dynamisk spenning‑ og frekvens‑skalering, mekanismen som senker klokkehastigheten når overgangstemperaturen stiger, gjorde akkurat det den er laget for.

Galaxy S24 Ultra feilet på en annen måte, og verre. I stedet for å degradere påla Android‑termisk governor et hardt GPU‑frekvensgulv ved iterasjon seks, ved 78,3 °C, og inferensen stoppet. Forfatterne påpeker bedre enn jeg kan: for agent‑utrullinger er dette «mer forstyrrende enn en grasiøs degradering», fordi systemet ikke bare blir tregere; det blir ubrukelig.

Hold nå på detaljen som gjør dette fordømmende snarere enn bare interessant. Hver av de tjue kjøringene brukte den samme prompten. Det er den mest vennlige arbeidsbelastningen en agents maskinvare noen gang vil se, og to flaggskip‑telefoner klarte ikke å opprettholde den i tjue repetisjoner. Dette er heller ikke en ny oppdagelse – MELT‑punktet, presentert på MobiCom i 2024, konkluderte med at på energi‑ og termisk grunnlag «den kontinuerlige kjøringen av LLM‑er fortsatt er unnvikende». To år og flere prosess‑noder senere, samme vegg.

To kurver beveger seg mot hverandre, og produktet ditt bryter der de krysser

En agents løkke er verre enn en gjentatt prompt på en spesifikk, mekanisk måte.

Dekoding er minnebåndbredde‑begrenset: gjennomstrømning styres av hvor raskt modellen kan lese sin nøkkel‑verdi‑cache, ikke av hvor mange operasjoner brikken teoretisk kan utføre. Cachen vokser med kontekst. Hvert løkkesteg legger til et verktøyresultat, en observasjon, en delplan – så steg ti genererer token mot en materiell større cache enn steg ett.

Samtidig varmer enheten opp, og governoren senker klokkene.

Dermed øker kostnaden per steg akkurat i det øyeblikket enhetens kapasitet til å betale den faller. De to kurvene konvergerer, og hvor de møtes er hvor produktet ditt feiler. Det er aldri steg ett. Steg ett er der du testet.

Det er også et skaleringsproblem under dette. Generativt arbeid er ganske enkelt en annen kostnadsrekkefølge enn hva kant‑silisium brukte et tiår på å kjøre: målt på tvers av 88 modeller, kostnaden for tekstklassifisering er rundt 0,002 kWh per tusen inferenser versus 0,047 kWh for tekstgenerering – omtrent tjue ganger mer, før noen løkke multipliserer den. Disse målingene ble gjort på en datasenter‑GPU, ikke en håndholdt enhet, så les dem som et forhold mellom typer arbeid snarere enn som et krafttall for din enhet. For skala viser samme studie at en full ladning av en smarttelefon er 0,022 kWh.

Kjøp på joule per fullført oppgave, ikke på token per sekund

Det mest nyttige resultatet i den 2026‑benchmarken er det som ser minst imponerende ut.

En Hailo-10H NPU håndterte 6,9 token per sekund under 2 watt. Langsom – virkelig langsom, og forfatterne sier det. Men dens gjennomstrømningskoeffisient for variasjon var 0,04 %, to størrelsesordener mer stabil enn alt annet som ble testet. Laptop‑GPU‑en i samme studie leverte 131,7 token per sekund ved 34,1 watt.

Sammenlign deretter de to på energi i stedet for hastighet: 270,5 millijoule per token på den lille NPU‑en mot 297,3 på GPU‑en. Til tross for et nitten‑ganger større gjennomstrømningsgap, gjorde den lille delen litt mer beregning per joule – og den gjorde det med praktisk talt ingen variasjon.

Hvis du velger maskinvare basert på token per sekund, kjøper du den raske. Hvis du velger basert på evnen til å fullføre en begrenset løkke til en forutsigbar kostnad, som er det en agent egentlig trenger, endres rangeringen. Enheten som bør stå på spesifikasjonsarket er joule per fullført oppgave, med en variasjonsverdi ved siden av. En benchmark som rapporterer topp‑gjennomstrømning forteller deg om den første inferensen på dagen.

Det ærlige innvendingen, og hva den ikke løser

Det åpenbare svaret er at dette er et forbigående problem: silisiumet forbedres, NPU‑er modnes, og alt som er skrevet om en telefon fra 2026 vil virke gammeldags. Eller, mer praktisk, avlaste de dyre stegene til en server.

Jeg ville selv satse på maskinvaren. Men avlasting er den rundreisen du flyttet til kanten for å unngå, og en agent betaler den ikke én gang – den betaler den per løkkesteg, og løkkelengden er det du ikke kan forutsi. Hybriddesign fjerner ikke variasjonen; de flytter den til et nettverk.

Den dypere asymmetrien flytter seg ikke med prosessnoder. En enhets budsjett er fastlagt på designtid. En agents etterspørsel bestemmes ved kjøretid, av hva brukeren ber om. Bedre silisium hever taket. Det forteller ikke agenten hvor taket er.

Så fortell den. Sett tur‑grensen i produktspecifikasjonen i stedet for å oppdage den i en kodegjennomgang, og velg tallet fra det termiske omslaget: bestem hvor mange steg som passer, og design deretter agenten til å levere sitt beste tilgjengelige svar innen den grensen i stedet for sitt ideelle svar ved en vilkårlig. Behandle det som en frist, ikke som et mål.

Deretter gi agenten budsjettet som en inngang. Gjenværende margin, batteristatus, om plattformen allerede har begynt å throttle – det hører til i konteksten, på samme måte som klokkeslettet gjør. En agent som vet at den er på steg åtte av ti kan oppsummere og forplikte seg. En agent som ikke vet det vil fortsette å utforske til operativsystemet bestemmer for den.

Og test halen, ikke medianen, noe som på en fysisk enhet betyr testing i simulering. Feiltilfellet er aldri den rene kjøringen. Det er kjøringen som tok fjorten steg fordi et verktøy returnerte noe tvetydig på steg tre, og du kan ikke enumerere dem manuelt på en telefon som må kjøle seg ned mellom forsøk. Mine egne systemer trener mot simuleringer i stor grad av denne grunnen: den interessante oppførselen ligger i de lange kjøringene, og lange kjøringer er nettopp det maskinvaren ikke lar deg prøve manuelt.

Ingen av dette krever en raskere chip. Det krever å innrømme at arbeidsbelastningen har endret form. Ingen leverer en enhet hvis batteri er dimensjonert for ett fotografi. Vi sender fortsatt enheter hvis termiske budsjett er dimensjonert for én inferens.