Il problema: il modello è piccolo, la batteria dura poco
Un sensore raccoglie un dato, un piccolo modello AI lo interpreta e il dispositivo aspetta la misura successiva. Se il calcolo dura pochi millisecondi, perché la batteria si scarica comunque rapidamente? Una risposta possibile è che il sistema trascorra quasi tutto il tempo ad aspettare consumando energia. Metterlo in una modalità di riposo sembra la soluzione naturale. Eppure, se le pause sono brevi, questa scelta può consumare più energia di quanta ne risparmi.
La domanda centrale è: quanto deve durare una pausa perché il risparmio durante il sonno compensi il costo di entrare e uscire da quello stato? Costruiremo il bilancio di un dispositivo ipotetico, distinguendo potenza, energia, durata della pausa e ritardo di risposta. Il risultato sarà una soglia calcolabile e un modo per capire cosa misurare su una scheda. Tutti i parametri numerici sono sintetici: non sono misure di un microcontrollore commerciale, di un prodotto EL-AI o di una batteria reale.
Potenza ed energia: rubinetto e serbatoio, con un limite
La potenza indica quanto rapidamente consumiamo energia: si misura in watt, equivalenti a joule al secondo. L’energia è la quantità consumata in un intervallo e si misura in joule. Un rubinetto più aperto ricorda una potenza maggiore, mentre l’acqua uscita ricorda l’energia. L’analogia serve soltanto a distinguere velocità e quantità: una batteria ha fenomeni elettrici e chimici che un serbatoio ideale non descrive. Per il nostro bilancio basta la relazione E = P × t quando la potenza è costante.
Un’elaborazione a 100 milliwatt per 20 millisecondi consuma 2 millijoule: 0,100 W × 0,020 s = 0,002 J. Il dato «100 mW» da solo non dice quanto costa una decisione, perché manca il tempo; il dato «2 mJ per decisione» non dice la potenza media senza sapere quante decisioni avvengono al secondo. È per questo che un confronto fra due modelli deve dichiarare anche frequenza di esecuzione, lavoro svolto e confine del sistema misurato.
La stessa attività, due modi di aspettare
Definiamo un ciclo di durata T, dall’inizio di una decisione all’inizio della successiva. La fase attiva dura tA = 20 ms a PA = 100 mW. Il tempo restante è G = T − tA. Confrontiamo due strategie che eseguono esattamente lo stesso lavoro: nella prima, il processore resta inattivo ma pronto, a PI = 30 mW; nella seconda attraversa una transizione, dorme a PS = 0,1 mW e torna pronto prima del ciclo successivo. «Inattivo» e «addormentato» sono due stati diversi, non due sinonimi.
Le transizioni di ingresso e uscita occupano complessivamente tX = 4 ms e consumano EX = 0,3 mJ. EX è l’energia totale durante quei quattro millisecondi, non un sovraccosto da sommare a un altro consumo già contato nello stesso intervallo. Questa convenzione evita un doppio conteggio. Supponiamo che il sonno conservi ciò che serve per ripartire e che il lavoro attivo non cambi: se occorre ricaricare il modello o ricostruire buffer, il costo deve entrare nel bilancio. G deve essere almeno tX perché lo stato sia temporalmente possibile.
Il bilancio, spiegato un termine alla volta
La prima domanda quantitativa è quanta energia spendiamo nell’intero ciclo. In entrambe le strategie compare PA × tA, cioè il lavoro utile. La strategia sempre pronta aggiunge PI × G. Quella con riposo aggiunge EX e soltanto PS × (G − tX), perché una parte della pausa è già stata occupata dalle transizioni. Tutti i tempi devono essere espressi nella stessa unità: nel codice usiamo secondi, watt e joule, convertendo i risultati soltanto per mostrarli.
Con una decisione al secondo, T = 1 s e G = 0,98 s. Restare pronti costa 2 + 29,4 = 31,4 mJ per ciclo. Dormire costa 2 + 0,3 + 0,0976 = 2,3976 mJ. Il termine del sonno usa 0,976 s, non 0,98 s. In questo esempio l’attesa pesa molto più del calcolo quando il processore resta pronto. Ottimizzare soltanto la rete neurale lascerebbe quindi intatta la parte maggiore del consumo di quella strategia.
La sorpresa delle pause brevi
Ripetiamo esattamente lo stesso lavoro ogni 25 ms. La pausa diventa appena 5 ms. La modalità di riposo trova spazio, perché quattro millisecondi bastano alle transizioni, ma resta soltanto un millisecondo di sonno. Restare pronti costa 2,15 mJ per ciclo; dormire costa 2,3001 mJ. La potenza durante il sonno è sempre bassissima, eppure l’energia totale è maggiore. Abbiamo pagato l’ingresso e il ritorno per un intervallo troppo breve: è questo il costo nascosto che il solo dato di potenza non mostra.
| T (ms) | G (ms) | E inattivo (mJ) | E riposo (mJ) |
|---|---|---|---|
| 25 | 5 | 2.15 | 2.3001 |
| 30 | 10 | 2.3 | 2.3006 |
| 100 | 80 | 4.4 | 2.3076 |
| 1000 | 980 | 31.4 | 2.3976 |
Derivare la soglia: quanto deve durare la pausa?
Ora possiamo rispondere senza provare tutte le durate. Sottraiamo le due energie: il lavoro attivo si cancella perché è identico. Il riposo conviene quando il suo costo di transizione è inferiore al risparmio ottenuto durante l’attesa. Riordinando i termini, con PI maggiore di PS, troviamo la soglia G*. Il piccolo termine PS × tX corregge il fatto che l’energia EX copre già tutto il tempo di transizione. Non va eliminato cambiando silenziosamente la definizione di EX.
Nel nostro esempio la pausa deve superare circa 10,02 ms, oltre a contenere le transizioni. Poiché il calcolo attivo dura 20 ms, il periodo completo deve superare circa 30,02 ms. Soglia della pausa e soglia del periodo non sono la stessa cosa. A 30 ms siamo appena dalla parte sfavorevole: la differenza è soltanto 0,0006 mJ per ciclo. Non sarebbe sensato trattare quei decimali sintetici come precisione garantita di una misura reale; vicino al pareggio, errori di misura e variabilità possono invertire la scelta.
Per leggere il grafico seguiamo prima la linea dell’attesa pronta: cresce rapidamente perché ogni millisecondo aggiunge consumo a 30 mW. La linea del riposo parte più in alto, a causa del costo fisso delle transizioni, e cresce lentamente grazie ai soli 0,1 mW durante il sonno. A sinistra dell’incrocio conviene restare pronti; a destra conviene dormire secondo queste ipotesi. Il grafico non mostra l’energia totale della decisione: aggiungere 2 mJ a entrambe le curve le sposterebbe verso l’alto senza cambiare l’incrocio.
Risparmiare energia non basta: bisogna svegliarsi in tempo
Il criterio energetico non garantisce che il sistema risponda in tempo. tX somma ingresso e uscita; il ritardo di risveglio, invece, è la parte necessaria a tornare operativo dopo un evento. Con una misura periodica nota possiamo anticipare il risveglio. Con un evento imprevedibile non possiamo farlo: la latenza di uscita entra nel tempo di risposta. Una modalità può quindi risparmiare energia ma essere incompatibile con la scadenza entro cui l’applicazione deve produrre un risultato.
La documentazione Zephyr descrive una politica di residenza che confronta il tempo fino al prossimo evento programmato con la somma di residenza minima e latenza di uscita. È un riferimento utile per collegare il ragionamento al software embedded, ma i parametri sono quelli della piattaforma: il nostro G* non configura automaticamente una scheda. Occorre verificare quali sorgenti di risveglio rimangono attive, quali periferiche perdono stato e quali vincoli impone l’applicazione. Una formula energetica non sostituisce queste informazioni.
Il sensore può cambiare la conclusione sulla batteria
Il bilancio finora comprende soltanto il sottosistema di elaborazione scelto. Supponiamo che un sensore separato, escluso da quelle potenze, resti acceso a 5 mW. In un ciclo di un secondo aggiunge 5 mJ a entrambe le strategie. Con riposo passiamo così da 2,3976 a 7,3976 mJ per decisione. La scelta tra le due strategie non cambia, perché il termine comune si cancella; cambia molto la stima dell’energia totale e di quanto ulteriore miglioramento possa arrivare dal processore.
Non possiamo spegnere il sensore e continuare a dichiarare lo stesso servizio senza verificarlo. Potrebbero servire tempo di stabilizzazione, una nuova calibrazione o campioni continui che andrebbero persi durante il sonno. Se un modello deve riconoscere eventi brevi, campionare meno spesso cambia ciò che può osservare. È un compromesso tra disponibilità dell’informazione ed energia, non un risparmio gratuito. Anche una radio, un regolatore e le perdite di alimentazione appartengono al bilancio quando l’obiettivo è la durata della batteria del dispositivo completo.
Tre numeri diversi: energia, media e picco
La potenza media si ottiene dividendo l’energia del ciclo per T. Nel caso di un secondo, 2,3976 mJ corrispondono a 2,3976 mW medi per il sottosistema senza sensore. Nel caso di 25 ms, 2,3001 mJ diventano 92,004 mW: l’energia per decisione è simile, ma le decisioni sono quaranta al secondo. La somiglianza dei millijoule non implica una durata simile della batteria. Occorre sempre chiedere quante volte viene ripetuto quel lavoro.
Il picco di potenza è un’altra informazione ancora. La nostra energia di transizione e la sua durata determinano soltanto una potenza media durante la transizione, pari a 75 mW. Non descrivono la forma temporale né escludono un picco molto maggiore. Senza una traccia di corrente e tensione con risoluzione sufficiente, non possiamo dedurre il dimensionamento dell’alimentazione. Allo stesso modo, una latenza media di risveglio non garantisce un percentile alto o una scadenza in ogni ciclo.
Dal calcolo alla misura: cosa manca davvero
Per trasformare il modello in una valutazione hardware occorre identificare scheda e revisione, microcontrollore o SoC, firmware, runtime AI, compilatore, clock e modalità di potenza. Bisogna indicare ingresso, dimensione del batch e lavoro attivo incluso: acquisizione, preparazione del dato, inferenza e comunicazione non sono intercambiabili. Il protocollo dovrebbe integrare V(t) × I(t) su cicli completi, includere le transizioni e distinguere avvio a freddo e regime. Temperatura e condizioni di alimentazione vanno registrate, perché i parametri possono cambiare.
Queste sono verifiche proposte, non esperimenti già svolti. Il materiale scaricabile esegue soltanto l’aritmetica del modello, controlla il pareggio e genera i grafici. Non usa casualità né richiede un seed; conserva ingressi, versioni e risultati. Il codice breve rende visibile il passaggio decisivo: sottrarre il tempo di transizione dalla pausa ed evitare di contare due volte la stessa energia. Il JSON permette di confrontare ogni riga della tabella con l’output calcolato.
La risposta: il sonno va guadagnato
Far dormire un dispositivo AI conviene quando il tempo disponibile permette sia di recuperare il costo delle transizioni sia di rispettare il servizio richiesto. Nel nostro esempio il pareggio energetico arriva con una pausa di circa 10,02 ms: una pausa di 5 ms peggiora il consumo, una di 980 ms lo riduce nettamente. Il messaggio non è scegliere sempre una modalità più profonda, ma misurare l’intero ciclo e chiedere se il risparmio arriva abbastanza presto. Solo dopo ha senso discutere autonomia, mantenendo nel conto sensori, comunicazione e perdite.
Fonti e riproducibilità
La fonte software primaria è la documentazione Zephyr, sezioni sugli stati e sulle politiche di gestione dell’alimentazione, consultata nella versione pubblicata all’indirizzo latest il 27 settembre 2026. Il bilancio e i parametri numerici sono una costruzione didattica indipendente, non un benchmark di Zephyr. Non dichiariamo un’implementazione su scheda né prodotti embedded già disponibili da EL-AI. L’approfondimento esplora un tema editoriale richiesto, senza trasformarlo in un’affermazione commerciale.
Zephyr Project — System Power Management: Power States and Policies.
P_idle, P_sleep = 0.030, 0.0001 # W
E_transition, t_transition = 0.0003, 0.004 # J, s
P_active, t_active, T = 0.100, 0.020, 1.0
G = T - t_active
assert G >= t_transition
E_idle = P_active*t_active + P_idle*G
E_sleep = P_active*t_active + E_transition + P_sleep*(G-t_transition)
G_break_even = (E_transition-P_sleep*t_transition)/(P_idle-P_sleep)
print(f"{1000*E_idle:.4f} mJ; {1000*E_sleep:.4f} mJ")
print(f"{1000*G_break_even:.6f} ms")
Codice, dati e istruzioni · JSON. Calcoli didattici eseguiti con Python 3.14.0; figure con Matplotlib 3.11.2. Analisi con assistenza AI, senza dichiarare peer review o revisione umana. Copertina originale ImageGen, illustrativa: non documenta persone, sedi o installazioni EL-AI. Fonti consultate il 27 settembre 2026.