Uw edge‑apparaat werd getest op een enkele voorwaartse stap. Uw agent draait een lus.

Het hardware‑gesprek over edge‑AI is het afgelopen jaar veel eerlijker geworden. Een recent artikel op deze site betoogde dat de oude ontwerp‑hiërarchie — “maximaliseer doorvoersnelheid, beheer daarna vermogen en thermiek eromheen” — is omgekeerd, en dat bij industriële implementaties vermogen nu de hoogste prioriteit krijgt, terwijl ruwe doorvoersnelheid als laatste komt. Het volgt een argument dat deze publicatie al geruime tijd maakt: dat edge‑apparaten “thermisch beperkt, niet MIPS/rekengelimiteerd” zijn, en dat smartphones al op die limieten zitten. Beide zijn reële correcties en ze waren lang nodig.

Maar het draagt nog steeds één aanname uit de wereld die het corrigeert. Elk onderdeel in die hiërarchie wordt begroot tegen een veronderstelde werklast, en de werklast waar bijna iedereen nog steeds tegen budgetteert, is een enkele forward pass: een model ontvangt een invoer, produceert een uitvoer, en de silicium krijgt een moment om af te koelen.

Dat is niet wat een agent doet. Een agent beslist, roept een tool aan, leest wat terugkomt, en beslist opnieuw. Hoe vaak hij die lus doorloopt, is geen eigenschap van uw hardware, en het is ook niet echt een eigenschap van uw model. Het is een eigenschap van het probleem dat iemand die ochtend heeft meegegeven. Ik heb agents die op edge‑hardware draaien, en het ding dat het langst duurde om te accepteren was niet dat ze traag waren. Het was dat de kostprijs van een run ergens werd vastgesteld waar ik tijdens het ontwerp geen zicht op had.

The Loop Is Unbounded Until Someone Types a Number

Dit is geen retorische omkadering; het is hoe de frameworks daadwerkelijk zijn gebouwd. In OpenAI’s Agents SDK “loopt de runner een lus”, en wanneer het model tool‑calls produceert, zal de runtime “die tool‑calls uitvoeren, de resultaten toevoegen en de lus opnieuw uitvoeren.” Het enige dat het stopt, is een turn‑limiet — overschrijd max_turns en je krijgt een uitzondering — en de documentatie vermeldt dat je max_turns=None kunt doorgeven om de limiet volledig uit te schakelen.

Op een server is dat getal een factureringsbeslissing. Iemand merkt de factuur op.

Op een apparaat is dat getal een thermische beslissing, omdat de lengte van de lus de duty‑cycle is. En duty‑cycle is de enige variabele waar passieve koeling geen bezwaar tegen kan maken.

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

Een benchmark uit maart 2026 zette vier platformen precies onder dit soort belasting: een gekwantiseerd model met 1,5 miljard parameters, een vaste prompt van 258 tokens, twintig opeenvolgende runs, waarbij doorvoersnelheid, vermogen en temperatuur per run werden gemeten. Het is een preprint, en het benchmarkt één model op vier apparaten, dus beschouw de specifieke cijfers als een karakterisering van die platformen in plaats van een natuurwet. De vorm van het resultaat is wat telt.

Een iPhone 16 Pro piekte op 40,35 tokens per seconde en kon het niet volhouden. De degradatie verscheen al na twee inferenties. Het stabiliseerde op 22,56 tokens per seconde — een daling van 44 procent — en bleef 65 procent van de benchmark gedempt. Dynamische spanning‑ en frequentieschaal (DVFS), het mechanisme dat de kloksnelheden verlaagt wanneer de junctietemperatuur stijgt, deed precies wat het moet doen.

De Galaxy S24 Ultra faalde op een andere, en slechtere, manier. In plaats van te degraderen legde de Android‑thermal governor een harde GPU‑frequentie‑bodem vast bij iteratie zes, op 78,3 °C, en stopte de inferentie. De auteurs maken het punt dat hier belangrijker is dan ik kon: voor agent‑implementaties is dit “meer storend dan een gracieuze degradatie”, omdat het systeem niet langzamer wordt; het wordt onbruikbaar.

Houd nu de detail in gedachten die dit veroordelend maakt in plaats van slechts interessant. Elk van die twintig runs gebruikte dezelfde prompt. Dat is de vriendelijkste werklast die de hardware van een agent ooit zal zien, en twee vlaggenschip‑telefoons konden het niet volhouden voor twintig herhalingen. Dit is ook geen nieuwe bevinding — het MELT‑punt, gepresenteerd op MobiCom in 2024, concludeerde dat op energie‑ en thermische gronden “de continue uitvoering van LLM’s ongrijpbaar blijft.” Twee jaar en verschillende proces‑nodes later, dezelfde muur.

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

De lus van een agent is in een specifieke, mechanische zin slechter dan een herhaalde prompt.

Decodering is geheugen‑bandbreedte‑gebonden: doorvoersnelheid wordt bepaald door hoe snel het model zijn key‑value‑cache kan lezen, niet door hoeveel bewerkingen de chip theoretisch kan uitvoeren. Die cache groeit met de context. Elke lusstap voegt een tool‑resultaat, een observatie, een gedeeltelijk plan toe — dus stap tien genereert tokens tegen een materieel grotere cache dan stap één.

Ondertussen warmt het apparaat op, en de governor verlaagt de kloksnelheden.

Dus de kosten per stap stijgen precies op het moment dat de capaciteit van het apparaat om die kosten te betalen daalt. De twee curven convergeren, en waar ze elkaar ontmoeten, faalt uw product. Het is nooit stap één. Stap één is waar u testte.

Er zit ook een schaalprobleem onder. Generatief werk is simpelweg een andere kostenvolgorde dan wat edge‑silicon een decennium lang uitvoerde: gemeten over 88 modellen kost tekstclassificatie ongeveer 0,002 kWh per duizend inferenties versus 0,047 kWh voor tekstgeneratie — ruwweg twintig keer meer, nog voordat een lus het vermenigvuldigt. Die metingen werden gedaan op een datacenter‑GPU, niet op een handset, dus lees ze als een verhouding tussen soorten werk in plaats van als een vermogenscijfer voor uw apparaat. Voor schaal plaatst dezelfde studie een volledige smartphone‑lading op 0,022 kWh.

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

Het meest bruikbare resultaat in die benchmark uit 2026 is degene die het minst indrukwekkend lijkt.

Een Hailo‑10H NPU leverde 6,9 tokens per seconde bij minder dan 2 watt. Traag — echt traag, en de auteurs zeggen het. Maar de doorvoersnelheidscoëfficiënt van variatie was 0,04 procent, twee orders van magnitude stabieler dan alles wat getest werd. De laptop‑GPU in dezelfde studie leverde 131,7 tokens per seconde bij 34,1 watt.

Vergelijk dan de twee op energie in plaats van snelheid: 270,5 millijoule per token op de kleine NPU versus 297,3 millijoule op de GPU. Ondanks een negentien‑voudig gat in doorvoersnelheid, deed het kleine onderdeel iets meer berekening per joule — en dat met praktisch geen variatie.

Als u hardware selecteert op tokens per seconde, koopt u de snelle. Als u selecteert op het vermogen om een begrensde lus met voorspelbare kosten te voltooien, wat een agent werkelijk nodig heeft, verandert de rangschikking. De eenheid die op het datasheet moet staan, is joules per voltooide taak, met een variatiecijfer ernaast. Een benchmark die piek‑doorvoersnelheid rapporteert, vertelt u over de eerste inferentie van de dag.

The Honest Objection, and What It Does Not Solve

Het voor de hand liggende antwoord is dat dit een tijdelijk probleem is: silicium verbetert, NPU’s rijpen, en alles wat over een telefoon uit 2026 geschreven is, zal ouderwets lijken. Of, praktischer, de dure stappen naar een server uitbesteden.

Ik zou zelf de hardware‑weddenschap aangaan. Maar uitbesteding is de round‑trip die u naar de edge hebt verplaatst om te vermijden, en een agent betaalt die niet één keer — hij betaalt per lusstap, en de lengte van de lus is wat u niet kunt voorspellen. Hybride ontwerpen verwijderen de variatie niet; ze verplaatsen die naar een netwerk.

De diepere asymmetrie beweegt niet met proces‑nodes. Het budget van een apparaat is vast bij het ontwerp. De vraag van een agent wordt beslist tijdens runtime, door wat een gebruiker vraagt. Betere silicium verhoogt het plafond. Het vertelt de agent niet waar het plafond is.

Dus vertel het. Stel de turn‑limiet in de productspecificatie in plaats van die te ontdekken tijdens een code‑review, en kies het getal uit de thermische envelope: bepaal hoeveel stappen passen, ontwerp de agent vervolgens om zijn best mogelijke antwoord binnen die grens te leveren in plaats van zijn ideale antwoord bij een willekeurige. Beschouw het als een deadline, niet als een target.

Geef de agent daarna het budget als invoer. Resterende headroom, batterijlading, of het platform al begonnen is met throttling — dat hoort in de context, net zoals de huidige tijd. Een agent die weet dat hij op stap acht van tien zit, kan samenvatten en committen. Een agent die dat niet weet, blijft verkennen tot het besturingssysteem voor hem beslist.

En test de tail, niet de median, wat op een fysiek apparaat betekent dat je in simulatie test. Het faalfall is nooit de schone run. Het is de run die veertien stappen duurde omdat een tool iets onduidelijks teruggaf op stap drie, en je die niet handmatig kunt opsommen op een telefoon die tussen pogingen moet afkoelen. Mijn eigen systemen trainen grotendeels tegen simulaties om deze reden: het interessante gedrag zit in de lange runs, en lange runs zijn precies wat hardware je niet handmatig laat bemonsteren.

Niets hiervan vereist een snellere chip. Het vereist toegeven dat de werklast van vorm is veranderd. Niemand brengt een apparaat op de markt waarvan de batterij is afgestemd op één foto. We blijven apparaten leveren waarvan het thermische budget is afgestemd op één inferentie.