Twoje urządzenie brzegowe zostało przetestowane na pojedynczym przejściu w przód. Twój agent będzie wykonywał pętlę.

Rozmowy o sprzęcie w kontekście edge AI stały się w ciągu ostatniego roku znacznie bardziej szczere. Niedawny artykuł na tej stronie argumentował, że dawna hierarchia projektowa — „maksymalizuj przepustowość, a potem zarządzaj mocą i termiką wokół niej” — odwróciła się, i że w zastosowaniach przemysłowych moc jest teraz najważniejsza, a surowa przepustowość ostatnia. To kontynuuje argument, który ta publikacja podnosiła od pewnego czasu: że urządzenia brzegowe są „ograniczone termicznie, a nie MIPS/obliczeniowo”, i że smartfony już znajdują się na tych granicach. Obie korekty są rzeczywiste i są już dawno potrzebne.

Jednak wciąż niesie ze sobą jedno założenie z świata, który koryguje. Każdy element tej hierarchii jest budżetowany względem przyjętego obciążenia, a obciążeniem, przeciw któremu większość wciąż planuje, jest pojedynczy forward pass: model otrzymuje dane wejściowe, generuje wyjście i krzem ma chwilę na ochłodzenie.

To nie jest to, co robi agent. Agent podejmuje decyzję, wywołuje narzędzie, odczytuje zwrócone wyniki i ponownie decyduje. Liczba obrotów w tej pętli nie jest własnością twojego sprzętu, ani właściwie nie jest własnością twojego modelu. To właściwość problemu, który ktoś mu rano zlecił. Mam agenty działające na sprzęcie brzegowym i najdłużej przyjmowałem do wiadomości, że nie chodzi o ich wolność, lecz o to, że koszt jednego uruchomienia był ustalany w miejscu, którego nie widziałem w czasie projektowania.

The Loop Is Unbounded Until Someone Types a Number

To nie jest retoryczne ujęcie; tak naprawdę frameworki są tak zbudowane. W OpenAI’s Agents SDK uruchomieniowiec „uruchamia pętlę”, a gdy model generuje wywołania narzędzi, środowisko „uruchamia te wywołania narzędzi, dołącza wyniki i ponownie uruchamia pętlę”. Jedynym czynnikiem, który to zatrzymuje, jest limit liczby tur — przekroczenie max_turns powoduje wyjątek — a dokumentacja zauważa, że można przekazać max_turns=None, aby całkowicie wyłączyć limit.

Na serwerze ta liczba jest decyzją billingową. Ktoś zauważa fakturę.

Na urządzeniu ta liczba jest decyzją termiczną, ponieważ długość pętli to współczynnik wypełnienia. A współczynnik wypełnienia jest jedyną zmienną, z którą chłodzenie pasywne nie może konkurować.

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

Benchmark z marca 2026 umieścił cztery platformy pod dokładnie takim obciążeniem: kwantyzowany model o 1,5‑miliardzie parametrów, stały prompt liczący 258 tokenów, dwadzieścia kolejnych uruchomień, przy czym mierzono przepustowość, moc i temperaturę przy każdym z nich. To preprint, w którym jeden model testowano na czterech urządzeniach, więc konkretne liczby należy traktować jako charakterystykę tych platform, a nie jako prawidłowość przyrody. Kształt wyniku jest tym, co ma znaczenie.

iPhone 16 Pro osiągnął szczyt 40,35 tokenów na sekundę i nie utrzymał tego tempa. Degradacja pojawiła się już po dwóch inferencjach. Ustabilizował się na poziomie 22,56 tokena na sekundę — spadek o 44 % — i był przycięty przez 65 % benchmarku. Dynamiczne skalowanie napięcia i częstotliwości, mechanizm obniżający częstotliwość zegara, gdy temperatura złącza rośnie, wykonało dokładnie to, do czego zostało stworzone.

Galaxy S24 Ultra zachował się inaczej i gorzej. Zamiast stopniowej degradacji, termiczny regulator Androida na szóstej iteracji narzucił twardy dolny limit częstotliwości GPU przy 78,3 °C i inferencja się zatrzymała. Autorzy podkreślają, że ma to „większy wpływ niż łagodna degradacja”, ponieważ system nie staje się po prostu wolniejszy; staje się nieużyteczny.

Trzymajmy się teraz szczegółu, który czyni to osądem, a nie jedynie ciekawostką. Każde z tych dwudziestu uruchomień używało tego SAMEGO promptu. To najłagodniejsze obciążenie, jakie sprzęt agenta kiedykolwiek zobaczy, a dwa flagowe telefony nie były w stanie utrzymać go przez dwadzieścia powtórzeń. To nie jest nowy wniosek — punkt MELT, prezentowany na MobiCom w 2024 roku, doszedł do wniosku, że pod względem energii i termiki „ciągłe wykonywanie LLM pozostaje nieuchwytne”. Dwa lata i kilka generacji procesorów później, ta sama bariera.

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

Pętla agenta jest gorsza niż powtarzany prompt w specyficzny, mechaniczny sposób.

Dekodowanie jest ograniczone przepustowością pamięci‑pasma: wydajność zależy od tego, jak szybko model może odczytać swoją pamięć podręczną klucz‑wartość, a nie od liczby operacji, które chip teoretycznie może wykonać. Ta pamięć rośnie wraz z kontekstem. Każdy krok pętli dopisuje wynik narzędzia, obserwację, częściowy plan — więc dziesiąty krok generuje tokeny przy znacznie większej pamięci niż pierwszy krok.

Tymczasem urządzenie się nagrzewa, a regulator obniża częstotliwości.

W rezultacie koszt na krok rośnie dokładnie w momencie, gdy zdolność urządzenia do jego pokrycia spada. Dwie krzywe zbliżają się, a w miejscu ich przecięcia twój produkt zawodzi. To nigdy nie jest pierwszy krok. Pierwszy krok to miejsce, w którym testowałeś.

Pod tym problemem kryje się także kwestia skali. Praca generatywna to po prostu inny porządek wydatków niż to, co brzegowy krzem wydatkował przez dekadę: zmierzone na 88 modelach, koszt klasyfikacji tekstu wynosił około 0,002 kWh na tysiąc inferencji, przeciwko 0,047 kWh dla generacji tekstu — czyli mniej więcej dwadzieścia razy więcej, zanim jakakolwiek pętla to pomnoży. Pomiary te wykonano na GPU w centrum danych, a nie w telefonie, więc należy je traktować jako stosunek między rodzajami prac, a nie jako wartość mocy dla twojego urządzenia. Dla skali to samo badanie podaje, że pełne naładowanie smartfona to 0,022 kWh.

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

Najbardziej przydatnym wynikiem tego benchmarku z 2026 roku jest ten, który wydaje się najmniej imponujący.

NPU Hailo‑10H uzyskało 6,9 tokena na sekundę przy mniej niż 2 W. Wolno — naprawdę wolno, i autorzy tak twierdzą. Jednak współczynnik zmienności przepustowości wyniósł 0,04 %, czyli dwa rzędy wielkości bardziej stabilny niż cokolwiek innego testowanego. GPU laptopa w tym samym badaniu dostarczyło 131,7 tokena na sekundę przy 34,1 W.

Porównajmy więc oba pod kątem energii, a nie prędkości: 270,5 mJ na token w małym NPU kontra 297,3 mJ w GPU. Mimo dziewiętnastokrotnej różnicy w przepustowości, mały układ wykonał nieco więcej obliczeń na dżul — i zrobił to praktycznie bez wariancji.

Jeśli wybierasz sprzęt według tokenów na sekundę, kupujesz najszybszy. Jeśli wybierasz według zdolności do zakończenia ograniczonej pętli przy przewidywalnym koszcie, co faktycznie potrzebuje agent, ranking się zmienia. Jednostką, która powinna znaleźć się w specyfikacji, jest dżul na zakończone zadanie, z podaną wartością wariancji. Benchmark podający szczytową przepustowość opisuje jedynie pierwszą inferencję dnia.

The Honest Objection, and What It Does Not Solve

Oczywistą odpowiedzią jest to, że problem jest przejściowy: krzem się poprawia, NPU dojrzewają, a wszystko, co napisane o telefonie z 2026 roku, będzie wyglądać starośnie. Albo, bardziej praktycznie, przenieść kosztowne kroki na serwer.

Sam postawiłbym zakład na sprzęt. Jednak offloading to ta sama podróż w obie strony, którą przeniosłeś na brzeg, aby jej uniknąć, a agent nie płaci jej raz — płaci za każdy krok pętli, a długość pętli jest tym, czego nie możesz przewidzieć. Projektowanie hybrydowe nie usuwa wariancji; przenosi ją na sieć.

Głębsza asymetria nie zmienia się wraz z generacjami procesorów. Budżet urządzenia jest ustalony w czasie projektowania. Zapotrzebowanie agenta decyduje się w czasie działania, w zależności od tego, o co poprosi użytkownik. Lepszy krzem podnosi pułap. Nie mówi jednak agentowi, gdzie ten pułap się znajduje.

Dlatego określ to. Ustaw limit tur w specyfikacji produktu, zamiast odkrywać go w przeglądzie kodu, i wybierz liczbę z zakresu termicznego: zdecyduj, ile kroków się zmieści, a następnie zaprojektuj agenta, by dostarczał najlepszą możliwą odpowiedź w tym limicie, zamiast idealnej odpowiedzi przy dowolnym limicie. Traktuj to jako termin, a nie cel.

Następnie podaj agentowi budżet jako wejście. Pozostała rezerwa, stan baterii, czy platforma już zaczęła przycinać — to elementy kontekstu, tak samo jak aktualny czas. Agent, który wie, że jest na ósmym z dziesięciu kroków, może podsumować i zatwierdzić. Agent, który tego nie wie, będzie dalej eksplorował, dopóki system operacyjny nie zdecyduje za niego.

I testuj ogon, a nie medianę, co na fizycznym urządzeniu oznacza testowanie w symulacji. Przypadek awaryjny nigdy nie jest czystym przebiegiem. To przebieg, który zajął czternaście kroków, bo narzędzie zwróciło coś niejednoznacznego w trzecim kroku, i nie możesz ich ręcznie wyliczyć na telefonie, który musi się schłodzić między próbami. Moje własne systemy trenują w dużej mierze na symulacjach właśnie z tego powodu: interesujące zachowanie pojawia się w długich przebiegach, a długie przebiegi to dokładnie to, czego sprzęt nie pozwoli ci próbować ręcznie.

Żadne z tego nie wymaga szybszego chipu. Wymaga przyznania, że charakterystyka obciążenia się zmieniła. Nikt nie sprzedaje urządzenia, którego bateria jest dobrana do jednego zdjęcia. Wciąż sprzedajemy urządzenia, których budżet termiczny jest dobrany do jednej inferencji.