La domanda che la media non risolve
Un sensore ottico controlla un componente e un modello AI deve produrre il risultato entro 10 millisecondi dall’evento di acquisizione. Nel rapporto di prova compare una latenza media di 8 ms. Possiamo dichiarare che il dispositivo arriva in tempo? Non ancora: la media descrive come si distribuisce il tempo complessivo tra le prove, non quante risposte arrivino dopo la scadenza. Se il componente è già passato oltre il punto utile, una classificazione corretta ma tardiva può non servire più.
Abstract. Costruiamo due insiemi di mille latenze con media identica, calcoliamo percentili e ritardi, poi aggiungiamo il tempo delle altre fasi del dispositivo. Infine deriviamo che cosa significa osservare zero ritardi in un campione finito. Il percorso porta dalla domanda pratica alla probabilità binomiale, senza assumere che il lettore conosca la statistica. Tutti i dati sono sintetici e costruiti esplicitamente: non sono misure di una scheda, di un acceleratore o di un prodotto EL-AI.
Prima definiamo quale orologio stiamo leggendo
La latenza è il tempo tra due eventi scelti. “Dal primo comando al ritorno della funzione” e “dal campione del sensore al risultato disponibile per l’attuatore” sono intervalli diversi. La deadline è la scadenza entro cui serve il risultato. Il tempo di inferenza riguarda il calcolo del modello, ma può escludere lettura del sensore, preparazione dei dati, copie di memoria e attese. Fissiamo qui D=10 ms e chiamiamo ritardo il caso L>D; una risposta esattamente a 10 ms è considerata puntuale. La convenzione deve essere esplicita.
Per isolare il problema, le prime tracce descrivono solo l’inferenza. Non simuliamo accodamenti tra richieste: immaginiamo prove separate, abbastanza distanziate da non sovrapporsi. Non c’è un modello neurale in esecuzione. Il sistema A impiega sempre 8 ms nelle mille righe create; B impiega 7,8 ms in 990 righe e 27,8 ms nelle altre dieci. Memorizziamo interi in microsecondi, così 7,8 ms diventa 7800 e il conteggio non dipende dall’arrotondamento dei decimali.
Stessa media, risposte diverse
La media somma tutti i tempi e divide per il numero di prove. Nel sistema B i tanti casi rapidi compensano esattamente i pochi casi lenti. La formula non è sbagliata: risponde a una domanda diversa da quella sulla puntualità.
A non ha ritardi nella traccia; B ne ha dieci, cioè l’1%. B è più rapido nella maggior parte dei casi, ma fallisce la scadenza in una minoranza che la media nasconde. Non sappiamo se A sarebbe sempre regolare su hardware: lo abbiamo costruito così. Il confronto dimostra una possibilità matematica, non la superiorità di un’architettura. Anche un punteggio di accuratezza identico non eliminerebbe questa differenza temporale.
Il percentile è una soglia, non il peggiore caso
Per trovare il percentile 99 ordiniamo i mille tempi dal più piccolo al più grande e prendiamo il valore in posizione 990. Usiamo la convenzione nearest rank: indice matematico ceil(q n), con q tra zero e uno. Nel codice l’indice è diminuito di uno perché le liste iniziano da zero. Almeno il 99% dei valori è minore o uguale alla soglia così scelta. Non stiamo affermando che il restante 1% le somigli. Altre librerie interpolano tra posizioni: per confrontare rapporti di prova occorre conoscere la convenzione.
| Traccia | Media ms | p99 ms | p99.9 ms | Max osservato ms | Ritardi / 1000 |
|---|---|---|---|---|---|
| A | 8.0 | 8.0 | 8.0 | 8.0 | 0 |
| B | 8.0 | 7.8 | 27.8 | 27.8 | 10 |
B ha addirittura un p99 migliore di A, pur avendo dieci ritardi. A p99.9 si entra nella coda lenta e il valore sale a 27,8 ms. “P99 sotto 10 ms” può essere un requisito sensato se si ammette una quota di ritardi, ma non equivale a “tutte le risposte sotto 10 ms”. Nel nostro campione il massimo osservato è 27,8 ms; non è un limite dimostrato per qualunque input e stato futuro del dispositivo.
Nel pannello sinistro la curva di B resta all’1% tra 8 e 27,8 ms: alzare la soglia da 10 a 20 ms non risolve quei dieci casi. La discesa a zero avviene solo quando la soglia raggiunge 27,8 ms, perché contiamo L>D. A invece scende a zero a 8 ms. Osservare la curva intera aiuta a non concentrare tutta la decisione su un unico percentile. Il pannello destro sarà spiegato dopo aver distinto campione e popolazione.
Il dispositivo non è soltanto il modello
Aggiungiamo ora 1,5 ms costanti per acquisizione, preparazione e consegna del risultato, senza sovrapposizione tra fasi. È un’ipotesi didattica, non una misura. Il tempo totale è Ltot=Linf+1,5 ms. La media diventa 9,5 ms per entrambi; A resta sempre a 9,5 nella traccia, mentre B ha 990 risultati a 9,3 e dieci a 29,3. La quota in ritardo rimane l’1%, ma il margine dei casi normali è cambiato. Se misurassimo soltanto il kernel neurale, non vedremmo queste altre fasi.
La somma è semplice perché il costo aggiunto è costante. In generale non possiamo sommare i p99 di due fasi e chiamare il risultato p99 del sistema: la distribuzione della somma dipende anche da quali latenze si verificano insieme. Occorre misurare le fasi sulla stessa richiesta, mantenendo gli identificativi, oppure disporre di limiti validi per ogni fase. Pipeline sovrapposte e acceleratori asincroni richiedono inoltre di distinguere quando il lavoro viene inviato da quando il risultato è realmente pronto.
Zero ritardi non significa probabilità zero
Cambiamo livello: immaginiamo di aver fatto n prove reali indipendenti nelle stesse condizioni e di non aver osservato ritardi. Questa ipotesi statistica non trasforma le nostre tracce sintetiche in misure. Indichiamo con p la probabilità, sconosciuta ma costante, di ritardo per prova. La probabilità di non vedere un ritardo in una singola prova è 1−p; per n prove indipendenti le probabilità si moltiplicano. Ecco perché un evento raro può sfuggire a una campagna breve.
K è il numero di ritardi, n il numero di prove e α la soglia di probabilità scelta. Per un limite superiore unilaterale al 95% poniamo α=0,05. Cerchiamo il valore pU per cui zero ritardi sarebbe un evento con probabilità 5%. Con n=1000 otteniamo pU≈0,002991, cioè circa 0,299%. Zero su mille non giustifica quindi la frase “il tasso è inferiore a uno su mille con confidenza 95%”. Il limite ottenuto è ancora circa tre su mille.
La confidenza descrive la copertura della procedura in ripetute campagne sotto il modello statistico; non assegna una probabilità soggettiva al parametro fisso e non garantisce la prossima esecuzione. Il pannello destro mostra come il limite si abbassa aumentando n. La discesa richiede più osservazioni informative, non semplicemente più copie dello stesso caso. Se carico e temperatura generano ritardi a gruppi, l’indipendenza è discutibile e questa formula non è una scorciatoia valida.
Quante prove servirebbero per una soglia assegnata?
Possiamo invertire il calcolo prima di iniziare una campagna. Se vogliamo un limite superiore non maggiore di ε e accettiamo la regola “zero ritardi”, imponiamo (1−ε)ⁿ≤α. Prendendo i logaritmi e ricordando che log(1−ε) è negativo, otteniamo il numero minimo seguente. La disuguaglianza cambia verso quando dividiamo per un numero negativo: è un dettaglio piccolo ma decisivo per non progettare una prova troppo corta.
Servirebbero almeno 2995 prove indipendenti senza ritardi per quel particolare limite unilaterale. Se comparisse un ritardo, la formula “zero eventi” non sarebbe più applicabile e andrebbe usato il calcolo binomiale appropriato. Il numero non certifica un sistema embedded: descrive un esperimento statistico con condizioni precise. Inoltre, se p fosse davvero 1%, in cento richieste indipendenti la probabilità di almeno un ritardo sarebbe 1−0,99¹⁰⁰≈63,4%. Un evento raro per singola richiesta può diventare comune in una sequenza.
Dall’esempio al protocollo sul dispositivo
La prima decisione di una prova reale è fissare il confine temporale. Per una chiamata asincrona, fermare il cronometro subito dopo l’invio misura la sottomissione, non il completamento. Un contatore deve avere risoluzione adeguata, conversione corretta e gestione del ritorno a zero dopo il proprio intervallo massimo. Nella documentazione ufficiale Zephyr, le funzioni di timing leggono un contatore prima e dopo il blocco e convertono i cicli in tempo; il timer può dipendere da architettura, SoC o scheda. Non abbiamo eseguito quell’API su hardware.
Registrerei insieme a ogni serie scheda e revisione, processore, frequenze, sistema operativo o runtime con versione, compilatore e opzioni, modello e precisione numerica, forme degli input, memoria utilizzata e numero di campioni. Separerei avvio a freddo e regime, descrivendo preriscaldamento, concorrenza, interrupt e condizioni termiche. Non eliminerei automaticamente i casi lenti: prima capirei se sono errori di misura o eventi reali del servizio. Le unità in millisecondi non bastano a rendere confrontabili due campagne con protocolli diversi.
Pesi del modello e picco di RAM sono grandezze diverse; latenza, potenza ed energia per inferenza lo sono altrettanto. Non deduciamo consumi da questi tempi sintetici. Per requisiti temporali rigidi serve un’argomentazione sul caso peggiore nelle condizioni ammesse, includendo blocchi e interferenze, non solo un percentile. Per requisiti tolleranti ai ritardi, una distribuzione misurata e una politica esplicita di gestione dei risultati scaduti possono essere più adatte. La scelta dipende dalle conseguenze del ritardo, che il nostro esempio non quantifica.
Riprodurre il risultato e interpretare il codice
Il pacchetto contiene le due liste complete, il programma che le genera, i risultati JSON e il codice dei grafici. Non usa casualità: non serve un seed. La riga che confronta t con 10000 conta i ritardi in microsecondi, mentre la divisione per 1000 converte l’uscita in millisecondi. Il percentile usa l’ordinamento e il rango dichiarato. Per il limite di probabilità usiamo expm1 e log1p, funzioni che evitano perdita di precisione sottraendo numeri molto vicini a uno. Sono scelte numeriche, non nuovi modelli statistici.
I controlli eseguiti verificano media uguale a 8 ms, dieci ritardi per B, p99 pari a 7,8 ms e numero minimo 2995 per il limite scelto. Per verificare che il numero sia davvero minimo, il codice controlla che 2995 soddisfi la disuguaglianza e 2994 no. Non c’è un test delle prestazioni di Zephyr o di una rete neurale nascosto dietro questi risultati. Per passare ai dati reali andrebbero sostituite le liste con misure tracciabili e riesaminate indipendenza, distribuzione degli input e stabilità delle condizioni.
Risposta alla domanda iniziale
Otto millisecondi medi non bastano a dimostrare puntualità. Occorre definire gli eventi di inizio e fine, contare i ritardi rispetto alla scadenza, osservare la coda della distribuzione e distinguere ciò che è stato visto da ciò che è garantito. Nel nostro esempio B sembra migliore al p99 ma ha dieci ritardi su mille; anche zero ritardi in mille prove indipendenti lascerebbe un limite statistico vicino allo 0,3%. La conclusione utile è misurare il requisito che ci interessa, senza chiedere alla media di rispondere a una domanda che non contiene.
Fonti e limiti di attribuzione
La documentazione NIST sui limiti binomiali esatti fornisce il riferimento statistico; qui abbiamo svolto direttamente il caso particolare di zero eventi e limite unilaterale. Le pagine ufficiali Zephyr spiegano contatori, conversioni e confini di misura: consultate nella versione web disponibile il 28 settembre 2026, non costituiscono una versione firmware usata nel nostro esperimento. Il lavoro è una monografia didattica con calcoli riproducibili, non un benchmark hardware, una ricerca originale o la prova di un prodotto embedded EL-AI già disponibile.
NIST — Exact Binomial Confidence Limits.
Zephyr — Executing Time Functions.
from math import ceil, log, log1p, expm1
x = [7800]*990 + [27800]*10 # synthetic microseconds
q99 = sorted(x)[ceil(.99*len(x))-1]
print("mean ms:", sum(x)/len(x)/1000)
print("p99 ms:", q99/1000)
print("deadline misses:", sum(t > 10000 for t in x))
print("95% upper p after 1000 independent zero-miss trials:",
-expm1(log(.05)/1000))
print("zero-miss trials for upper p <= .001:",
ceil(log(.05)/log1p(-.001)))
# Constructed data; no hardware timing was performed.
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 28 settembre 2026.