Il tuo dispositivo edge è stato valutato su un passaggio in avanti. Il tuo agente eseguirà un ciclo.

La discussione sull’hardware per l’edge AI è diventata molto più trasparente nell’ultimo anno. Un recente articolo su questo sito sosteneva che la vecchia gerarchia di progettazione — “massimizzare il throughput, poi gestire potenza e termiche intorno ad esso” — si è invertita, e che per le implementazioni industriali la potenza ora è al primo posto, mentre il throughput grezzo è l’ultimo. Segue un argomento che questa pubblicazione porta avanti da tempo: i dispositivi edge sono “limitati termicamente, non da MIPS/calcolo”, e gli smartphone già operano a quei limiti. Entrambi sono correttivi reali, ed erano già attesi.

Ma conserva ancora un’assunzione del mondo che sta correggendo. Ogni elemento di quella gerarchia è dimensionato rispetto a un carico di lavoro presunto, e il carico di lavoro su cui quasi tutti continuano a basare le loro previsioni è un singolo passaggio in avanti: il modello riceve un input, produce un output e il silicio ha un momento per raffreddarsi.

Non è così che funziona un agente. Un agente decide, chiama uno strumento, legge la risposta e decide nuovamente. Quante volte percorre quel ciclo non è una proprietà del tuo hardware, né è davvero una proprietà del tuo modello. È una proprietà del problema che gli è stato assegnato quella mattina. Ho agenti in esecuzione su hardware edge, e la cosa che ho impiegato più tempo ad accettare non è stata la loro lentezza. È stato il fatto che il costo di un’esecuzione veniva impostato da qualche parte a cui non avevo visibilità al momento della progettazione.

Il ciclo è illimitato finché qualcuno non inserisce un numero

Non si tratta di una formulazione retorica; è così che i framework sono realmente costruiti. Nell’Agents SDK di OpenAI, l’esecutore “esegue un ciclo”, e quando il modello produce chiamate a strumenti, il runtime “esegue quelle chiamate, aggiunge i risultati e riesegue il ciclo”. L’unica cosa che lo ferma è un limite di turni — superare max_turns genera un’eccezione — e la documentazione segnala che è possibile impostare max_turns=None per disabilitare del tutto il limite.

Su un server, quel numero è una decisione di fatturazione. Qualcuno nota la fattura.

Su un dispositivo, quel numero è una decisione termica, perché la lunghezza del ciclo corrisponde al duty cycle. E il duty cycle è l’unica variabile con cui il raffreddamento passivo non può competere.

Un carico sostenuto influisce su uno smartphone in modo diverso rispetto a quanto fa un benchmark

Un benchmark di marzo 2026 ha sottoposto quattro piattaforme a esattamente questo tipo di carico: un modello quantizzato da 1,5 miliardi di parametri, un prompt fisso di 258 token, venti esecuzioni consecutive, misurando throughput, potenza e temperatura per ciascuna. Si tratta di un preprint, e valuta un unico modello su quattro dispositivi, quindi i numeri specifici vanno considerati come una caratterizzazione di quelle piattaforme piuttosto che come una legge della natura. È la forma del risultato che conta.

Un iPhone 16 Pro ha raggiunto un picco di 40,35 token al secondo ma non è riuscito a mantenerlo. La degradazione è comparsa entro due inferenze. Si è stabilizzato a 22,56 token al secondo — una riduzione del 44 % — e ha rimasto sotto throttling per il 65 % del benchmark. Il dynamic voltage and frequency scaling, il meccanismo che riduce la frequenza di clock quando la temperatura della giunzione aumenta, ha fatto esattamente quello per cui è stato progettato.

Il Galaxy S24 Ultra ha fallito in modo diverso, e peggio. Invece di degradare, il governor termico di Android ha imposto un limite minimo di frequenza GPU alla sesta iterazione, a 78,3 °C, e l’inferenza si è interrotta. Gli autori sottolineano meglio di quanto io possa: per le distribuzioni di agenti, ciò è “più dirompente di una degradazione graduale”, perché il sistema non diventa più lento; diventa inutilizzabile.

Ora concentrati sul dettaglio che rende questo damning piuttosto che semplicemente interessante. Ognuna delle venti esecuzioni ha utilizzato il stesso prompt. Quello è il carico di lavoro più amichevole che l’hardware di un agente potrà mai vedere, e due telefoni di punta non sono riusciti a sostenerlo per venti ripetizioni. Non è neanche una scoperta nuova — il punto MELT, presentato al MobiCom nel 2024, ha concluso che per motivi energetici e termici “l’esecuzione continua di LLM rimane sfuggente”. Due anni e diversi nodi di processo più avanti, lo stesso ostacolo.

Due curve si avvicinano e il tuo prodotto si rompe dove si incrociano

Il ciclo di un agente è peggiore di un prompt ripetuto in un modo specifico e meccanico.

Il decoding è limitato dalla larghezza di banda della memoria: il throughput è determinato da quanto velocemente il modello può leggere la sua cache chiave-valore, non dal numero di operazioni che il chip può teoricamente eseguire. Tale cache cresce con il contesto. Ogni passo del ciclo aggiunge un risultato di uno strumento, un’osservazione, un piano parziale — così il decimo passo genera token contro una cache materialmente più grande rispetto al primo passo.

Nel frattempo il dispositivo si sta riscaldando e il governor sta riducendo le frequenze.

Quindi il costo per passo aumenta esattamente nel momento in cui la capacità del dispositivo di pagarlo diminuisce. Le due curve convergono, e dove si incontrano è dove il tuo prodotto fallisce. Non è mai al primo passo. Il primo passo è quello in cui hai testato.

C’è anche un problema di scala sottostante. Il lavoro generativo è semplicemente un ordine di spesa diverso rispetto a quello che il silicio edge ha sostenuto per un decennio: misurato su 88 modelli, il costo della classificazione del testo è circa 0,002 kWh per mille inferenze contro 0,047 kWh per la generazione di testo — circa venti volte di più, prima che qualsiasi ciclo lo moltiplichi. Quelle misurazioni sono state effettuate su una GPU di data center, non su un handset, quindi vanno interpretate come un rapporto tra tipologie di lavoro piuttosto che come una cifra di potenza per il tuo dispositivo. Per scala, lo stesso studio attribuisce una carica completa di smartphone a 0,022 kWh.

Acquista in joule per compito completato, non in token al secondo

Il risultato più utile di quel benchmark del 2026 è quello che sembra meno impressionante.

Un NPU Hailo-10H ha gestito 6,9 token al secondo con meno di 2 watt. Lento — davvero lento, come confermano gli autori. Ma il suo coefficiente di variazione del throughput era dello 0,04 %, due ordini di grandezza più stabile di qualsiasi altro testato. La GPU di un laptop nello stesso studio ha fornito 131,7 token al secondo a 34,1 watt.

Poi confronta i due dispositivi in termini di energia piuttosto che di velocità: 270,5 millijoule per token sul piccolo NPU contro 297,3 sulla GPU. Nonostante un divario di diciannove volte nel throughput, il piccolo chip ha effettuato leggermente più calcoli per joule — e lo ha fatto con praticamente nessuna variazione.

Se scegli l’hardware in base ai token al secondo, acquisti quello più veloce. Se scegli in base alla capacità di completare un ciclo limitato a un costo prevedibile, che è ciò di cui ha realmente bisogno un agente, la classifica cambia. L’unità che dovrebbe comparire nella scheda tecnica è joule per compito completato, con una cifra di variazione accanto. Un benchmark che riporta il throughput di picco ti informa solo sulla prima inferenza della giornata.

L’obiezione onesta, e ciò che non risolve

La risposta ovvia è che si tratta di un problema transitorio: il silicio migliora, gli NPU maturano, e qualsiasi cosa scritta su un telefono del 2026 sembrerà antiquata. Oppure, più pragmaticamente, scaricare i passaggi costosi su un server.

Io stesso scommetterei sull’hardware. Ma lo scaricamento è il viaggio di ritorno che si è cercato di evitare spostandolo sul edge, e un agente non lo paga una sola volta — lo paga per ogni passo del ciclo, e la lunghezza del ciclo è ciò che non si può prevedere. I design ibridi non eliminano la varianza; la spostano su una rete.

L’asimmetria più profonda non cambia con i nodi di processo. Il budget di un dispositivo è fissato al momento della progettazione. La domanda di un agente è decisa a runtime, in base a ciò che l’utente richiede. Un silicio migliore alza il tetto. Non indica all’agente dove si trovi il tetto.

Quindi comunicalo. Imposta il limite di turni nella specifica del prodotto anziché scoprirlo in una revisione del codice, e scegli il numero dall’involucro termico: decidi quanti passi possono essere inseriti, poi progetta l’agente per fornire la migliore risposta disponibile a quel vincolo anziché la risposta ideale a uno arbitrario. Consideralo una scadenza, non un obiettivo.

Poi fornisci all’agente il budget come input. Lo spazio residuo, lo stato della batteria, se la piattaforma ha già iniziato il throttling — tutto ciò fa parte del contesto, così come l’ora corrente. Un agente che sa di essere al passo otto su dieci può riassumere e confermare. Un agente che non lo sa continuerà a esplorare finché il sistema operativo non prenderà una decisione per lui.

E testa la coda, non la mediana, il che su un dispositivo fisico significa testare in simulazione. Il caso di fallimento non è mai l’esecuzione pulita. È l’esecuzione che ha richiesto quattordici passi perché uno strumento ha restituito qualcosa di ambiguo al passo tre, e non puoi elencarli manualmente su un telefono che deve raffreddarsi tra i tentativi. I miei sistemi si allenano su simulazioni proprio per questo motivo: il comportamento interessante si manifesta nelle esecuzioni lunghe, e le esecuzioni lunghe sono esattamente ciò che l’hardware non ti permette di campionare a mano.

Niente di tutto ciò richiede un chip più veloce. Richiede ammettere che il carico di lavoro ha cambiato forma. Nessuno commercializza un dispositivo la cui batteria è dimensionata per una sola fotografia. Stiamo ancora spedendo dispositivi il cui budget termico è dimensionato per una sola inferenza.