🤖 AI

Transferable Latency Prediction for Fast LLM Screening on Heterogeneous Edge Devices

Questo articolo propone un framework di predizione della latenza consapevole del runtime che fonde adattivamente descrittori statici del modello con telemetria hardware dinamica per abilitare uno screening di deployment di LLM accurato e trasferibile attraverso dispositivi edge eterogenei con una calibrazione minima.

Autori originali: Xiaolong Tu, Vinod K. Mishra, Venkat R. Dasari, Anu G. Bourgeois, Haoxin Wang

Pubblicato 2026-07-27

📖 8 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Xiaolong Tu, Vinod K. Mishra, Venkat R. Dasari, Anu G. Bourgeois, Haoxin Wang

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immagina di dover scegliere il videogioco perfetto da giocare su una console portatile. Hai una libreria enorme di giochi, dai minuscoli avventure puzzle ai massicci e vasti epici di ruolo. Ma ecco il problema: la tua console è un po' capricciosa. Si scalda se giochi troppo a lungo, la batteria si scarica velocemente e gestisce i diversi giochi in modi strani a seconda di come la impugni o del momento della giornata. Se provassi a scaricare e testare ogni singolo gioco per vedere quale gira fluidamente, passeresti l'intera giornata ad aspettare i download, solo per scoprire che metà di essi crasha o va in lag. Hai bisogno di un modo per indovinare, semplicemente guardando la descrizione del gioco e l'umore attuale della tua console, quale funzionerà davvero. Questo è esattamente il problema che il mondo dell'Intelligenza Artificiale sta affrontando sui nostri telefoni e sui piccoli gadget.

Gli scienziati stanno cercando di eseguire i "Large Language Models" (LLM) — cervelli IA super intelligenti che possono scrivere storie, rispondere a domande e risolvere problemi — direttamente sui nostri dispositivi invece di inviare i dati a enormi server nel cloud. Questo è ottimo per la privacy e la velocità, ma è un incubo da prevedere. Un modello IA potrebbe girare perfettamente su un telefono ma bloccarsi su un altro, anche se i telefoni sembrano simili. Perché? Perché la velocità dell'IA dipende da un mix caotico di cose: quanto è lunga la domanda, quanto si sta scaldando il telefono, quanta batteria rimane e persino il software specifico utilizzato per eseguire l'IA. Se non riusciamo a prevedere quanto velocemente girerà un'IA prima di provarla effettivamente, sprechiamo enormi quantità di tempo ed energia testando modelli che potrebbero fallire. È qui che entra in gioco la storia di "prevedere il futuro".

La Palla di Cristallo per la Velocità dell'IA

In questo articolo, un team di ricercatori della Georgia State University e dell'Army Research Laboratory ha costruito una "palla di cristallo" per la velocità dell'IA. Lo chiamano un framework di previsione della latenza consapevole del runtime (runtime-aware latency prediction framework). Analizziamo questa definizione. "Latenza" è solo un termine elegante per dire quanto tempo ci vuole perché qualcosa accada. "Consapevole del runtime" significa che il sistema presta attenzione a ciò che accade mentre l'IA sta lavorando, non solo a come l'IA appare sulla carta. E "trasferibile" significa che questa palla di cristallo funziona anche se ci si sposta da un tipo di dispositivo a un altro.

I ricercatori hanno capito che cercare di testare ogni modello IA su ogni singolo dispositivo è come cercare di assaggiare ogni gusto di gelato al mondo per trovare il proprio preferito. È troppo lento e costoso. Inveve, volevano un sistema che potesse guardare un nuovo dispositivo e un nuovo modello IA e dire: "Ehi, questa combinazione richiederà probabilmente circa 10 secondi per rispondere".

Come Funziona la Palla di Cristallo

Il segreto della loro efficacia è che non guarda solo i fatti statici. Immaginate di cercare di indovinare quanto velocemente andrà un'auto. Un tentativo di previsione "statico" guarderebbe solo la dimensione del motore e il peso dell'auto. Ma un tentativo "consapevole del runtime" controllerebbe anche il meteo, il traffico e se il conducente è assonnato.

Il sistema dei ricercatori fa due cose contemporaneamente:

Il Percorso Statico: Guarda la "carta d'identità" della configurazione. Questo include la dimensione del modello, il tipo di telefono o gadget e le impostazioni.
Il Percorso Dinamico: Osserva il "battito cardiaco" del dispositivo mentre è in funzione. Monitora cose come quanto si scalda il chip, quanto velocemente gira il processore e quanta memoria viene utilizzata.

Il sistema divide il lavoro dell'IA in due fasi, come una gara in due parti:

La Fase di Prefill: Questa è la fase in cui l'IA legge la tua domanda e organizza i suoi pensieri. È solitamente uno scatto rapido e impulsivo.
La Fase di Decode: Questa è la fase in cui l'IA scrive la risposta, parola per parola. È una corsa più lunga e costante.

Trattando queste due fasi separatamente e mescolando le informazioni della "carta d'identità" con i dati del "battito cardiaco", il sistema costruisce una previsione molto più intelligente. Hanno utilizzato un meccanismo speciale di "fusione a porta logica" (gated fusion), che è come un semaforo intelligente che decide se ascoltare di più i fatti statici o le condizioni del traffico in tempo reale a seconda della situazione.

La Magia della Calibrazione

Ecco il trucco più importante: il sistema non è perfetto appena uscito dalla scatola. Se lo addestri su un telefono Pixel 8 e provi a usarlo su un Pixel 8 Pro, potrebbe sbagliare i numeri perché i due telefoni sono leggermente diversi.

Per risolvere questo problema, i ricercatori utilizzano un set di calibrazione. Consideratelo come una rapida "prova su strada". Eseguite l'IA sul nuovo dispositivo solo alcune volte (forse da 6 a 20 volte) per vedere come si comporta effettivamente. Il sistema utilizza poi questi pochi risultati reali per regolare la sua palla di cristallo, allineando le sue previsioni con la realtà del nuovo dispositivo.

I risultati di questa calibrazione sono drammatici. Senza di essa, le previsioni del sistema su quanto tempo impiegasse l'IA per "decodificare" (scrivere la risposta) su un Pixel 8 Pro erano completamente errate, con un punteggio (chiamato $R^2$ ) di -1.085. Questo è un punteggio terribile, il che significa che la previsione era peggiore di un semplice tirare a indovinare casualmente. Ma dopo una minima calibrazione, quel punteggio è balzato a 0.927, che è quasi perfetto. È come prendere una foto sfocata e renderla improvvisamente nitida con solo pochi aggiustamenti.

Testare il Sistema

Il team ha testato la loro idea su una varietà di gadget per assicurarsi che non fosse solo un caso fortuito per un telefono specifico. Hanno utilizzato:

Pixel 8 e Pixel 8 Pro: I protagonisti dello spettacolo, che rappresentano i moderni telefoni cellulari.
Jetson Nano: Un piccolo computer spesso usato per robot e droni.
Orange Pi 5 Pro: Un piccolo computer a scheda singola.
RTX 3090: Una potente scheda grafica solitamente presente nei PC da gioco di fascia alta.

Hanno scoperto che lo stesso modello IA poteva essere incredibilmente veloce sulla grande scheda da gioco (64.38 token al secondo) ma dolorosamente lento sull'Orange Pi (8.42 token al secondo). Questo dimostra che non si può semplicemente indovinare la velocità basandosi solo sul modello; bisogna conoscere il dispositivo.

Perché Questo è Importante: Il Processo di Screening

L'obiettivo finale non è solo prevedere la velocità; è risparmiare tempo. Immaginate di avere 100 diversi modelli IA e di dover scegliere il migliore per il vostro specifico telefono. Senza questo sistema, dovreste scaricare e testare tutti i 100 modelli. Con questo sistema, potete prevedere la velocità di tutti i 100 istantaneamente.

I ricercatori utilizzano quindi una strategia chiamata ottimizzazione di Pareto. Questo è un modo elegante per dire che cercano il "punto di equilibrio". Vogliono un modello che sia veloce e intelligente. Se il Modello A è più lento del Modello B ma non è più intelligente, il Modello A è inutile. Il sistema filtra le opzioni scadenti e vi lascia una breve lista dei migliori candidati da testare realmente.

Nei loro test, questo processo di screening ha mantenuto con successo i migliori modelli in corsa. Ad esempio, passando da un Pixel 8 Pro a un Pixel 8, il sistema ha filtrato la metà dei candidati ma ha assicurato che il migliore assoluto fosse ancora presente.

Cosa Hanno Trovato (e Cosa Non Hanno Trovato)

L'articolo suggerisce che questo metodo è uno strumento potente per rendere l'implementazione dell'IA più veloce e meno costosa. Hanno scoperto che:

Le previsioni statiche non bastano: Sapere solo la dimensione del modello non dice quanto velocemente girerà su un telefono specifico.
La calibrazione è fondamentale: Non si può semplicemente copiare e incollare una previsione da un dispositivo all'altro; serve un minimo di dati reali per correggere la previsione.
La fase conta: Trattare la parte di "lettura" e la parte di "scrittura" dell'IA in modo diverso rende la previsione molto più accurata.

Tuttavia, gli autori tengono presente che questo è solo un punto di partenza. I loro migliori risultati sono arrivati con i telefoni Pixel e, sebbene abbiano dimostrato che il sistema può funzionare anche su altri dispositivi come il Jetson e l'Orange Pi, non hanno ancora effettuato un addestramento profondo e completo su questi ultimi. Hanno anche notato che, a volte, su computer potenti, i modelli più piccoli non sono sempre più veloci di quelli grandi, un'insolita particolarità che il loro sistema aiuta a spiegare.

In breve, questo articolo offre un modo intelligente e flessibile per indovinare quanto velocemente girerà un'IA sul vostro gadget senza dover aspettare ore per scoprirlo. Trasforma un gioco di ipotesi caotico in una decisione calcolata e basata sui dati, aiutandoci a ottenere le migliori esperienze di IA sui nostri dispositivi senza esaurire tempo o batteria.

Sintesi Tecnica: Predizione della Latenza Trasferibile per lo Screening Rapido di LLM su Dispositivi Edge Eterogenei

Definizione del Problema

Il deployment di Large Language Models (LLM) su dispositivi edge eterogenei (ad esempio, telefoni cellulari, single-board computer, GPU integrate) è sempre più critico per applicazioni a bassa latenza, sensibili alla privacy e con connettività limitata. Tuttavia, determinare quale modello sia adatto per un dispositivo specifico sotto specifici requisiti di deployment rimane un significativo collo di bottiglia sistemistico.

La sfida principale è che la latenza di inferenza degli LLM non è determinata unicamente dall'architettura statica del modello o dalle capacità hardware. Al contrario, è una funzione complessa di:

Fattori Statici: Architettura del modello, scala dei parametri, formato di quantizzazione e specifiche hardware.
Fattori Dinamici: Lunghezza del prompt, comportamento dei token generati, Dynamic Voltage and Frequency Scaling (DVFS), utilizzo dell'hardware, pressione della memoria e thermal throttling.
Fasi di Esecuzione: L'inferenza degli LLM consiste in fasi distinte di prefill (elaborazione del prompt e costruzione della KV cache) e decode (generazione autoregressiva dei token), che esibiscono caratteristiche di latenza e comportamenti hardware differenti.

Una soluzione diretta — ovvero sottoporre ogni modello candidato a benchmark esaustivi su ogni dispositivo target — è proibitiva a causa dei costi di configurazione del runtime, conversione del modello, esecuzione e raccolta della telemetria. Gli esistenti predittori di latenza si affidano spesso solo a feature statiche, fallendo nel catturare i comportamenti di runtime specifici della piattaforma, gli effetti di scheduling e le differenze di esecuzione dipendenti dal backend. Di conseguenza, vi è la necessità di un framework di predizione consapevole del runtime (runtime-aware) e trasferibile che possa effettuare lo screening dei modelli candidati prima dell'esecuzione sul dispositivo target, che è costosa.

Metodologia

Il paper propone un framework di predizione della latenza consapevole del runtime progettato per il deployment di LLM attraverso ambienti eterogenei. Il sistema opera attraverso quattro fasi principali:

1. Rappresentazione della Configurazione

Ogni richiesta di inferenza è modellata come una tupla di configurazione $c = (m, d, r, p)$ , dove:

$m$ : Modello pre-addestrato (famiglia, dimensione, quantizzazione).
$d$ : Dispositivo (profilo hardware, capacità di telemetria).
$r$ : Backend di runtime e impostazioni della piattaforma (ad esempio, MLC-LLM, PyTorch, CPU/GPU/NPU).
$p$ : Configurazione del prompt/task (lunghezza dell'input, lunghezza massima di generazione).

2. Architettura del Predittore a Doppio Percorso

Il framework impiega un predittore trasferibile con due rami complementari fusi tramite un meccanismo di gating:

Percorso Statico: Codifica descrittori stabili (profilo del dispositivo, descrittore del modello, configurazione di deployment) in un embedding statico ( $S$ ). Questo cattura la compatibilità prevista prima dell'esecuzione.
Percorso Dinamico: Elabora le tracce di telemetria di runtime raccolte durante il profiling. Fondamentalmente, applica una modellazione consapevole delle fasi (phase-aware modeling):
- Le tracce di prefill sono allineate sotto un tempo di fase normalizzato per ricostruire stati hardware sparsi e intermittenti (bursty).
- Le tracce di decode preservano l'ordine temporale per catturare il comportamento autoregressivo.
- Un encoder temporale aggrega questi dati in un embedding dinamico ( $D$ ).
Gated Fusion: Una rete di gating leggera calcola pesi adattivi ( $w_s, w_d$ ) per fondere $S$ e $D$ . Ciò consente al modello di fare maggiore affidamento sulle informazioni statiche quando le configurazioni sono stabili e sui dati dinamici quando le variazioni di runtime predominano.
Testa di Regressione: Output della latenza di prefill predetta, della latenza di decode e della latenza totale.

3. Trasferimento e Calibrazione

Per gestire il deployment cross-device, il sistema utilizza un set di calibrazione. Un piccolo numero di esecuzioni sul dispositivo target viene misurato per correggere i bias specifici del dispositivo. Questo allinea il predittore addestrato sulla sorgente con la scala di latenza e il regime di runtime del dispositivo target senza richiedere un profiling esaustivo.

4. Screening basato su Pareto

La latenza predetta viene combinata con l'accuratezza del modello (o la qualità del task) per eseguire l'ottimizzazione di Pareto. Il sistema filtra i candidati dominati (quelli con latenza peggiore e qualità inferiore) per identificare un set compatto di modelli Pareto-ottimali, bilanciando reattività e qualità dell'output.

Contributi Chiave

Formulazione: Ha definito la predizione della latenza degli LLM come un problema di configurazione hardware-runtime-modello-prompt, consentendo la predizione tra diversi dispositivi, modelli, prompt e backend.
Architettura: Ha proposto un predittore trasferibile consapevole del runtime che integra descrittori statici con telemetria dinamica, separa i comportamenti di prefill/decode tramite modellazione consapevole delle fasi e utilizza la fusione gated per la combinazione adattiva degli embedding.
Workflow: Ha progettato un workflow di screening orientato al deployment che utilizza predizioni calibrate per filtrare i candidati prima dell'esecuzione sul dispositivo target, supportando l'analisi del trade-off latenza-qualità.
Validazione: Ha costruito e valutato una pipeline di profiling multi-piattaforma su dispositivi mobili Pixel, Jetson Nano, Orange Pi 5 Pro e una GPU di classe RTX 3090, validando sia la precisione della predizione mobile che la copertura del profiling eterogeneo.

Risultati Sperimentali

Il framework è stato valutato su dispositivi Pixel 8 e Pixel 8 Pro, con validazione del profiling su Jetson Nano, Orange Pi 5 Pro e hardware di classe RTX 3090.

Predizione Within-Device: Su Pixel 8, il predittore completo ha migliorato l' $R^2$ della latenza totale da 0.953 a 0.960 e l' $R^2$ della latenza di decode da 0.957 a 0.973 rispetto a un baseline basato solo su dati statici. Su Pixel 8 Pro, ha migliorato significativamente l' $R^2$ della latenza di prefill da -1.383 a 0.966.
Trasferimento Cross-Device: La calibrazione si è dimostrata essenziale. Senza di essa, i valori di $R^2$ di trasferimento erano spesso negativi (ad esempio, -0.974 per la latenza totale da Pixel 8 Pro $\to$ Pixel 8). Con la calibrazione, l' $R^2$ è migliorato a 0.940.
Profiling Eterogeneo: I risultati hanno confermato che la latenza è altamente dipendente dal dispositivo e dal runtime. Ad esempio, il modello SmolLM2-1.7B ha raggiunto 64.38 token/s su una GPU di classe RTX 3090 ma solo 8.42 token/s su un Orange Pi 5 Pro. Inoltre, su RTX 3090, i modelli più piccoli non erano sempre più veloci, indicando che l'overhead dei kernel e il comportamento della memoria possono dominare la scalabilità basata sul numero di parametri.
Studi di Ablazione: Hanno confermato che i soli descrittori statici sono insufficienti per il trasferimento cross-device e che la calibrazione è il fattore più critico per stabilizzare le predizioni. La modellazione consapevole delle fasi ha fornito chiari benefici per la predizione della latenza di prefill.
Efficienza dello Screening: Il predittore ha filtrato con successo il set di modelli candidati (rapporti di filtraggio di 0.333 e 0.500 negli scenari testati) preservando al contempo i migliori modelli fattibili.

Significato e Claim

Il paper sostiene che la predizione consapevole del runtime con calibrazione leggera può ridurre significativamente il costo del profiling e supportare il deployment di LLM consapevole della latenza su piattaforme edge eterogenee.

Impatto Pratico: Il framework affronta il "collo di bottiglia sistemistico" della selezione del modello sostituendo il benchmarking esaustivo con un processo di screening predittivo.
Necessità della Dinamicità: I risultati dimostrano che i modelli statici da soli non possono catturare l'interazione complessa di DVFS, thermal throttling e scheduling di runtime che determina le prestazioni dei dispositivi edge.
Trasferibilità: Il sistema dimostra che un predittore addestrato su dispositivi sorgente può generalizzare efficacemente ai dispositivi target, a patto che venga utilizzato un piccolo set di calibrazione per allineare le scale di latenza.
Ciclo di Deployment: Il lavoro inquadra la predizione della latenza non come un compito di regressione isolato, ma come componente di un sistema di deployment a ciclo chiuso che migliora iterativamente le decisioni con misurazioni limitate.

Gli autori segnalano limitazioni, tra cui il fatto che i risultati di predizione più completi si basano sul dataset mobile Pixel, mentre le altre piattaforme sono servite principalmente per la validazione del profiling. Il lavoro futuro è identificato nell'estensione del framework per considerare congiuntamente throughput, memoria ed energia oltre alla latenza.