Reunalaiteesi benchmarkattiin yhdellä eteenpäin suorituksella. Agenttisi suorittaa silmukan.

Laitteistokeskustelu reunalla tapahtuvasta tekoälystä on viimeisen vuoden aikana tullut paljon rehellisempi. Viimeaikainen artikkeli tällä sivustolla väitti, että vanha suunnitteluhierarkia — “maksimoi läpäisykyky, sitten hallitse virtaa ja lämpöä sen ympärillä” — on kääntynyt ylösalaisin, ja että teollisissa käyttöönotossa virta on nyt tärkein, kun taas raaka läpäisykyky on viimeinen. Tämä jatkaa argumenttia, jota julkaisu on pitkään esittänyt: reunalaitteet ovat “lämpörajoitettu, ei MIPS/laskentarajoitettu“, ja älypuhelimet ovat jo näiden rajojen päässä. Molemmat ovat todellisia korjauksia, ja ne ovat pitkään viivästyneet.

Mutta se kantaa edelleen yhtä oletusta korjattavasta maailmasta. Jokainen kohde tässä hierarkiassa budjetoidaan oletettua työkuormaa vastaan, ja työkuorma, johon lähes kaikki edelleen budjetoivat, on yksi eteenpäin suoritus: malli saa syötteen, tuottaa tuloksen, ja piiri saa hetken jäähdytellä.

Se ei ole se, mitä agentti tekee. Agentti päättää, kutsuu työkalua, lukee sen palauttaman tiedon ja päättää uudelleen. Kuinka monta kertaa se kiertää silmukassa, ei ole laitteistosi ominaisuus, eikä myöskään mallisi ominaisuus. Se on sen aamuna annetun ongelman ominaisuus. Minulla on agenteja, jotka toimivat reunalaitteessa, ja asia, jonka hyväksymiseen kesti eniten, ei ollut se, että ne olivat hitaita. Se oli se, että suorituksen kustannus asetettiin jonnekin, johon minulla ei ollut suunnitteluvaiheessa näkyvyyttä.

The Loop Is Unbounded Until Someone Types a Number

Kyse ei ole retorinen kehä, vaan se on tapa, jolla kehykset todellisuudessa on rakennettu. OpenAI:n Agents SDK:ssa suorittaja “ajaa silmukkaa”, ja kun malli tuottaa työkalukutsuja, ajonaikainen ympäristö “ajaa ne työkalukutsut, liittää tulokset ja ajaa silmukan uudelleen”. Ainoa asia, joka pysäyttää sen, on kierrosraja — ylitä max_turns ja saat poikkeuksen — ja dokumentaatiossa mainitaan, että voit asettaa max_turns=None poistaaksesi rajan kokonaan.

Palvelimella tuo luku on laskutuspäätös. Joku huomaa laskun.

Laitteessa tuo luku on lämpöpäätös, koska silmukan pituus on käyttöaste. Ja käyttöaste on se muuttuja, jonka passiivinen jäähdytys ei voi kiistää.

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

Maaliskuun 2026 benchmark asetti neljä alustaa juuri tällaiseen kuormitukseen: kvantisoitu 1,5 miljardin parametrin malli, kiinteä 258 tokenin prompt, kaksikymmentä peräkkäistä suoritusta, joista mitattiin läpäisykyky, virrankulutus ja lämpötila. Kyse on esijulkaisusta, jossa yksi malli benchmarkataan neljällä laitteella, joten käsittele tarkkoja lukuja näiden alustojen karakterisointina, ei luonnonlakina. Tuloksen muoto on se, mikä merkitsee.

iPhone 16 Pro saavutti huippunsa 40,35 tokenia sekunnissa, eikä pystynyt ylläpitämään sitä. Heikkeneminen ilmestyi kahden inferenssin sisällä. Se asettui 22,56 tokeniin sekunnissa — 44 prosentin väheneminen — ja pysyi rajoitettuna 65 prosentissa benchmarkista. Dynaaminen jännite- ja taajuusasteistus, mekanismi, joka laskee kellotaajuuksia, kun liitoslämpötila nousee, teki juuri sen, mihin se on suunniteltu.

Galaxy S24 Ultra epäonnistui eri tavalla, ja pahempaa. Sen sijaan, että se heikkenisi, Androidin lämpöviranomainen asetti kovaksi GPU-taajuusrajaksi kuudennen iteraation kohdalla, 78,3 °C, ja inferenssi pysäytettiin. Tekijät tuovat esiin tärkeän kohdan paremmin kuin minä pystyn: agenttien käyttöönotossa tämä on “häiritsevämpää kuin sulava heikkeneminen”, koska järjestelmä ei vain hidastu; siitä tulee käyttökelvoton.

Pidä nyt mielessä se yksityiskohta, joka tekee tästä tuomitsevan eikä vain mielenkiintoisen. Kaikissa niissä kaksikymmentä suorituksessa käytettiin samaa promptia. Se on ystävällisin työkuorma, jonka agentin laitteisto koskaan näkee, ja kaksi lippulaivapuhelinta eivät pystyneet ylläpitämään sitä kahdenkymmenen toiston ajan. Tämä ei ole myöskään uusi havainto — MELTing point, esitelty MobiComissa 2024, totesi, että energian ja lämmön näkökulmasta “LLM:ien jatkuva suorituskyky on edelleen saavuttamaton”. Kaksi vuotta ja useita prosessisolmuja myöhemmin, sama este.

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

Agentin silmukka on huonompi kuin toistuva prompti erityisellä, mekaanisella tavalla.

Purku on muistikaistanleveyteen sidottua: läpäisykykyä ohjaa se, kuinka nopeasti malli voi lukea avain-arvo-välimuistinsa, ei se, kuinka monta operaatioita piiri teoreettisesti voi suorittaa. Tämä välimuisti kasvaa kontekstin mukana. Jokainen silmukan askel lisää työkalutuloksen, havainnon, osittaisen suunnitelman — joten askel kymmenen tuottaa tokenit merkittävästi suuremmasta välimuistista kuin askel yksi.

Sillä välin laite lämpenee, ja viranomainen laskee kelloja.

Niinpä per askel -kustannus nousee juuri sillä hetkellä, kun laitteen kyky maksaa se laskee. Kaksi käyrää lähestyvät, ja missä tahansa ne kohtaavat, siellä tuotteesi epäonnistuu. Se ei koskaan ole askel yksi. Askelen yksi kohdalla testasit.

Taustalla on myös mittakaavaproblema. Generatiivinen työ on vain erilainen kulurakenne kuin mitä reunasilikoni kulutti vuosikymmenen ajan: mitattu 88 mallin yli, tekstiluokittelun kustannus on noin 0,002 kWh tuhatta inferenssiä kohti verrattuna 0,047 kWh tekstin generointiin — noin kaksikymmentä kertaa enemmän, ennen kuin silmukka moninkertaistaa sen. Nämä mittaukset tehtiin datakeskuksen GPU:lla, ei puhelimessa, joten tulkitse ne työn tyypin suhdelukuna, ei laitteesi teholukuna. Suuruusluokassa sama tutkimus asettaa täyden älypuhelimen latauksen 0,022 kWh:iin.

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

Tuon 2026 benchmarkin hyödyllisin tulos on se, joka näyttää vähiten vaikuttavalta.

Hailo-10H NPU saavutti 6,9 tokenia sekunnissa alle 2 watin teholla. Hidas — todella hidas, ja tekijät sanovat niin. Mutta sen läpäisykyvyn vaihtelukerroin oli 0,04 prosenttia, kaksi suuruusluokkaa tasaisempi kuin mikään muu testattu. Samassa tutkimuksessa kannettavan tietokoneen GPU tuotti 131,7 tokenia sekunnissa 34,1 watilla.

Sitten vertaile molempia energian, ei nopeuden, perusteella: 270,5 millijoulea per token pienellä NPU:lla vastaan 297,3 GPU:lla. Huolimatta yhdeksästoista kertaa suuremmasta läpäisykyvystä, pieni osa teki hieman enemmän laskentaa per joule — ja teki sen lähes ilman vaihtelua.

Jos valitset laitteiston tokenia sekunnissa -mittarina, ostat nopeimman. Jos valitset sen kyvyn suorittaa rajoitettu silmukka ennustettuun kustannukseen, mikä on se, mitä agentti todella tarvitsee, ranking muuttuu. Yksikkönä, jonka pitäisi näkyä teknisissä tiedoissa, on jouleja per suoritettu tehtävä, jonka vieressä on vaihteluluku. Benchmark, joka raportoi huippuläpäisykyvyn, kertoo sinulle päivän ensimmäisestä inferenssistä.

The Honest Objection, and What It Does Not Solve

Ilmeinen vastaus on, että tämä on väliaikainen ongelma: piiro paranee, NPU:t kypsyy, ja kaikki 2026 puhelimesta kirjoitettu näyttää vanhanaikaiselta. Tai käytännöllisemmin, siirrä kalliit vaiheet palvelimelle.

Ottaisin itsekin riskin laitteistosta. Mutta offloading on se kiertomatka, jonka siirsit reunalle välttääksesi, ja agentti ei maksa sitä kerran — se maksaa sen jokaisesta silmukan askeleesta, ja silmukan pituus on se asia, jota et voi ennustaa. Hybridisuunnitelmat eivät poista vaihtelua; ne siirtävät sen verkkoon.

Syvempi epäsymmetria ei siirry prosessisolmujen mukana. Laitteen budjetti on kiinteä suunnitteluvaiheessa. Agentin vaatimus päätetään ajonaikaisesti, sen mukaan, mitä käyttäjä pyysi. Parempi piiro nostaa kattoa. Se ei kerro agentille, missä katto on.

Joten kerro se. Aseta kierrosraja tuotteen spesifikaatioon sen sijaan, että löytäisit sen koodikatselmuksessa, ja valitse luku lämpötilarajasta: päätä, montako askelta mahtuu, sitten suunnittele agentti tuottamaan paras mahdollinen vastaus kyseisessä rajassa sen sijaan, että se pyrkisi ihanteelliseen vastaukseen mielivaltaisessa tilanteessa. Kohtele sitä määräaikana, ei tavoitteena.

Anna sitten agentille budjetti syötteenä. Jäljellä oleva varaus, akun tila, onko alusta jo alkanut rajoittaa — kaikki kuuluu kontekstiin, kuten nykyinen aika. Agentti, joka tietää olevansa kahdeksannen askeleen kohdalla kymmenestä, voi tiivistää ja sitoutua. Agentti, joka ei tiedä, jatkaa tutkimista, kunnes käyttöjärjestelmä päättää sen puolesta.

Testaa myös hännän, ei mediaanin, mikä fyysisessä laitteessa tarkoittaa testaamista simulaatiossa. Epäonnistumistapaus ei ole koskaan puhdas suoritus. Se on suoritus, joka kesti neljätoista askelta, koska työkalu palautti jotain epäselvää kolmannessa askeleessa, eikä näitä voi käydä läpi käsin puhelimessa, jonka täytyy jäähdytellä yritysten välillä. Omien järjestelmiini koulutan pääosin simulaatioiden avulla juuri tästä syystä: mielenkiintoinen käyttäytyminen ilmenee pitkissä suorituksissa, ja pitkät suoritukset ovat juuri sitä, mitä laitteisto ei anna sinun näytteillä käsin.

Tämä kaikki ei vaadi nopeampaa piiriä. Se vaatii myöntymistä, että työkuorma on muuttanut muotoaan. Kukaan ei toimita laitetta, jonka akku on mitoitettu yhteen valokuvaan. Me edelleen toimitamme laitteita, joiden lämpöbudjetti on mitoitettu yhteen inferenssiin.