Din Edge‑enhet benchmarkades på ett framåtpass. Din agent kommer att köra en slinga.

Diskussionen om hårdvara för edge‑AI har blivit mycket ärligare det senaste året. En nyligen publicerad artikel på den här webbplatsen hävdade att den gamla designhierarkin — ”maximera genomströmning, sedan hantera ström och termik kring den” — har vänt upp och ner, och att för industriella implementationer är ström nu högst prioriterat, medan rå genomströmning hamnar sist. Detta följer ett resonemang som den här publikation har förespråkat ett tag: att edge‑enheter är ”termiskt begränsade, inte MIPS-/beräkningsbegränsade”, och att smartphones redan befinner sig vid dessa gränser. Båda är faktiska korrigeringar, och de är försenade.

Men den bär fortfarande på ett antagande från den värld den korrigerar. Varje del i den hierarkin budgeteras mot en antagen arbetsbelastning, och den arbetsbelastning som nästan alla fortfarande budgeterar mot är ett enda framåtpass: en modell får en indata, producerar en utdata, och silikonen får ett ögonblick att svalna.

Det är inte vad en agent gör. En agent fattar beslut, anropar ett verktyg, läser vad som kommer tillbaka och fattar beslut igen. Hur många gånger den går runt den slingan är inte en egenskap hos din hårdvara, och det är egentligen inte heller en egenskap hos din modell. Det är en egenskap hos det problem någon gav den på morgonen. Jag har agenter som kör på edge‑hårdvara, och det som tog längst tid för mig att acceptera var inte att de var långsamma. Det var att kostnaden för ett körning sattes någonstans där jag inte hade någon insyn under designfasen.

Slingan är obegränsad tills någon anger ett tal

Detta är inte en retorisk inramning; det är så ramverken faktiskt är konstruerade. I OpenAI:s Agents SDK kör “runnern” en slinga, och när modellen genererar verktygsanrop kommer runtime att “köra de verktygsanropen, lägga till resultaten och köra slingan igen.” Det enda som stoppar den är en vändningsgräns — överskrid max_turns så får du ett undantag — och dokumentationen noterar att du kan skicka max_turns=None för att inaktivera gränsen helt.

På en server är det talet en faktureringsbeslut. Någon märker fakturan.

På en enhet är det talet ett termiskt beslut, eftersom slinglängden är arbetscykel. Och arbetscykeln är den enda variabel som passiv kylning inte kan motsäga.

Uthållig belastning gör något annorlunda med en telefon än vad ett benchmark gör

Ett benchmark från mars 2026 satte fyra plattformar under exakt denna typ av belastning: en kvantiserad modell med 1,5 miljarder parametrar, en fast prompt på 258 token, tjugo på varandra följande körningar, och mätte genomströmning, effekt och temperatur för varje. Det är en preprint, och den benchmarkar en modell på fyra enheter, så behandla de specifika siffrorna som en karaktärisering av dessa plattformar snarare än en naturlag. Resultatets form är det som spelar roll.

En iPhone 16 Pro nådde högst 40,35 token per sekund och kunde inte hålla den nivån. Nedgången visade sig redan efter två inferenser. Den stabiliserades på 22,56 token per sekund — en minskning med 44 % — och var strypad under 65 % av benchmarket. Dynamisk spännings‑ och frekvensskalning, mekanismen som sänker klockfrekvensen när övergångstemperaturen stiger, gjorde exakt det den är avsedd för.

Galaxy S24 Ultra misslyckades på ett annat sätt, och värre. Istället för att degraderas införde den Android‑termiska styrningen ett hårt GPU‑frekvensgolv vid iteration sex, vid 78,3 °C, och inferensen stoppades. Författarna poängterar bättre än jag kan: för agent‑distributioner är detta ”mer störande än en graciös degradering”, eftersom systemet inte bara blir långsammare; det blir oanvändbart.

Håll nu fast vid detaljen som gör detta fördömande snarare än bara intressant. Varje av de tjugo körningarna använde samma prompt. Det är den mest vänliga arbetsbelastning som en agents hårdvara någonsin kommer att möta, och två flaggskepps‑telefoner kunde inte hålla den i tjugo upprepningar. Detta är inte ett nytt fynd heller — MELTing‑punkten, presenterad på MobiCom 2024, drog slutsatsen att ur energi‑ och termiska perspektiv ”den kontinuerliga exekveringen av LLM:er förblir svårfångad.” Två år och flera process‑noder senare är samma vägg fortfarande närvarande.

Två kurvor rör sig mot varandra, och din produkt går sönder där de korsas

En agents slinga är sämre än en upprepad prompt på ett specifikt, mekaniskt sätt.

Dekodning är begränsad av minnesbandbredd: genomströmning styrs av hur snabbt modellen kan läsa sitt nyckel‑värde‑cache, inte av hur många operationer chipet teoretiskt kan utföra. Cachen växer med kontexten. Varje slingsteg lägger till ett verktygsresultat, en observation, en partiell plan — så steg tio genererar token mot ett materiellt större cache än steg ett.

Samtidigt värms enheten upp, och styrningen drar ner klockorna.

Så kostnaden per steg ökar exakt när enhetens kapacitet att betala den minskar. De två kurvorna konvergerar, och var de möts är där din produkt misslyckas. Det är aldrig steg ett. Steg ett är där du testade.

Det finns också ett skalproblem under detta. Generativt arbete är helt enkelt en annan typ av kostnad än vad edge‑silicon spenderade under ett decennium: mätt över 88 modeller låg kostnaden för textklassificering omkring 0,002 kWh per tusen inferenser jämfört med 0,047 kWh för textgenerering — ungefär tjugo gånger mer, innan någon slinga multiplicerar den. Dessa mätningar gjordes på ett datacenter‑GPU, inte på en mobil, så läs dem som ett förhållande mellan olika arbetsformer snarare än som ett effektvärde för din enhet. För skala placerar samma studie en full laddning av en smartphone på 0,022 kWh.

Köp på joule per färdig uppgift, inte på token per sekund

Det mest användbara resultatet i det benchmarket från 2026 är det som ser minst imponerande ut.

En Hailo‑10H‑NPU klarade 6,9 token per sekund under 2 watt. Långsam — verkligen långsam, och författarna påpekar det. Men dess genomströmningskoefficient för variation var 0,04 %, två storleksordningar jämnare än något annat som testades. Laptop‑GPU:n i samma studie levererade 131,7 token per sekund vid 34,1 watt.

Jämför sedan de två på energi snarare än hastighet: 270,5 millijoule per token på den lilla NPU:n mot 297,3 på GPU:n. Trots ett nittonfalt gap i genomströmning utförde den lilla delen något mer beräkning per joule — och det gjorde den i princip utan någon variation.

Om du väljer hårdvara baserat på token per sekund köper du den snabba. Om du väljer baserat på förmågan att slutföra en begränsad slinga till en förutsägbar kostnad, vilket är vad en agent faktiskt behöver, förändras rangordningen. Enheten som bör finnas på specifikationsbladet är joule per slutförd uppgift, med en variationssiffra bredvid. Ett benchmark som rapporterar toppgenomströmning berättar bara om den första inferensen på dagen.

Det ärliga invändningen, och vad den inte löser

Det uppenbara svaret är att detta är ett övergående problem: silikonen förbättras, NPU:er mognar, och allt som skrivits om en telefon från 2026 kommer att se föråldrat ut. Eller, mer praktiskt, avlasta de kostsamma stegen till en server.

Jag skulle själv satsa på hårdvaran. Men avlastning är den rundresa du flyttade till kanten för att undvika, och en agent betalar den inte en gång — den betalar den per slingsteg, och slinglängden är det du inte kan förutsäga. Hybriddesigner tar inte bort variansen; de flyttar den till ett nätverk.

Den djupare asymmetrin rör sig inte med processnoderna. En enhets budget är fastställd vid designtid. En agents efterfrågan beslutas vid körtid, av vad en användare begär. Bättre silikongör taket högre. Det talar inte för agenten var taket ligger.

Så tala om det. Ange vändningsgränsen i produktspecifikationen snarare än att upptäcka den i en kodgranskning, och välj talet från det termiska omfånget: bestäm hur många steg som får plats, designa sedan agenten att leverera sitt bästa tillgängliga svar vid den gränsen istället för sitt ideala svar vid en godtycklig. Behandla det som en deadline, inte ett mål.

Ge sedan agenten budgeten som en inparameter. Återstående marginal, batteristatus, om plattformen redan börjat strypa — det hör till kontexten, på samma sätt som den aktuella tiden. En agent som vet att den är på steg åtta av tio kan sammanfatta och begå. En agent som inte gör det kommer fortsätta utforska tills operativsystemet bestämmer åt den.

Och testa svansen, inte medianen, vilket på en fysisk enhet betyder att testa i simulering. Felfallet är aldrig den rena körningen. Det är körningen som tog fjorton steg eftersom ett verktyg returnerade något tvetydigt på steg tre, och du kan inte räkna upp dem för hand på en telefon som måste svalna mellan försöken. Mina egna system tränas mot simuleringar främst av den anledningen: det intressanta beteendet ligger i de långa körningarna, och långa körningar är exakt vad hårdvaran inte låter dig provta för hand.

Ingenting av detta kräver ett snabbare chip. Det kräver att man erkänner att arbetsbelastningen förändrades i form. Ingen levererar en enhet vars batteri är dimensionerat för ett foto. Vi lever fortfarande med enheter vars termiska budget är dimensionerad för en enda inferens.