Executive summary
Elaborare dati direttamente dove vengono generati, su un sensore, un macchinario o un dispositivo locale, anziché inviarli a un centro di calcolo remoto, è un'esigenza crescente in molti settori industriali. Ridurre il tempo di risposta, contenere i costi di trasmissione e proteggere informazioni sensibili sono le motivazioni principali. Questo articolo analizza le tecnologie che rendono possibile eseguire modelli di intelligenza artificiale su dispositivi con risorse limitate, dalle tecniche per ridurre la dimensione dei modelli ai software che ne gestiscono l'esecuzione su hardware eterogeneo. Dall'analisi emerge che non esiste un'unica soluzione: la scelta dipende dal tipo di dispositivo, dal consumo energetico ammissibile e dalla complessità del compito da svolgere, e richiede una progettazione attenta dell'intera catena, dal modello al dispositivo fisico.
Background
Il paradigma del cloud computing centralizzato incontra limiti strutturali quando i dati vengono generati in volumi elevati, in posizioni geograficamente distribuite o con requisiti di latenza incompatibili con un round-trip verso un data center remoto. Satyanarayanan [1] ha formalizzato per primo la necessità di avvicinare il calcolo alla sorgente dei dati, introducendo il concetto di cloudlet come strato intermedio tra dispositivo e cloud. La successiva evoluzione verso il Multi-access Edge Computing (MEC), standardizzato da ETSI [2], ha esteso questo paradigma alle infrastrutture di rete mobile, collocando risorse di calcolo direttamente ai margini della rete 5G.
Zhou et al. [3] hanno proposto una tassonomia di Edge Intelligence su sei livelli, dal modello addestrato in cloud e deployato su edge (Level 1) fino all'apprendimento completamente autonomo sul dispositivo (Level 6). La ricerca più recente [4] indica che la maggior parte dei deployment commerciali si colloca ai livelli 3-4: modelli addestrati in cloud, ottimizzati per il target hardware, con inferenza eseguita interamente on-edge. Il Level 6 resta largamente accademico, con eccezioni limitate al federated learning su dispositivi mobili (tastiere predittive, personalizzazione on-device) [5].
Il mercato riflette questa maturazione: IDC stima una spesa globale in edge computing di $232 miliardi nel 2025, con un CAGR del 25% per il segmento specifico edge AI [6]. Gartner colloca Edge AI al picco delle aspettative inflazionate nel proprio Hype Cycle 2024, con un orizzonte di 2-5 anni per l'adozione mainstream, osservando che la tecnologia AI avanza più rapidamente della prontezza infrastrutturale [7].
Architettura a tre livelli: MCU, edge accelerato, edge server
Il termine "edge" copre un continuum di dispositivi con caratteristiche radicalmente diverse. È utile distinguere tre livelli architetturali, ciascuno con vincoli e workload specifici.
Livello 1: Microcontrollore (TinyML)
Al livello più basso della gerarchia si collocano i microcontrollori (MCU) con pochi kilobyte di SRAM e consumi nell'ordine dei milliwatt. Il framework MCUNet [8] ha dimostrato che è possibile eseguire classificazione ImageNet con accuratezza del 70,7% su un MCU STM32F746 (Cortex-M7) con 320KB di SRAM e 1MB di Flash, ottenendo un footprint di memoria 4,8x inferiore e velocità di inferenza 3,5x superiore rispetto all'approccio MobileNetV2 + TFLite Micro. Piattaforme come ESP32-S3 eseguono keyword spotting (riconoscimento di parole chiave) nell'ordine dei 15ms con consumi di decine di milliwatt, mentre MCU a basso consumo come il Nordic nRF5340 raggiungono prestazioni analoghe nell'ordine dei milliwatt grazie al duty cycling (ciclo di attivazione-sospensione del processore) [9].
La recente introduzione di NPU integrate nei MCU rappresenta un salto qualitativo: l'STM32N6 di STMicroelectronics, che integra un core Cortex-M55 con NPU dedicata, collocandosi al confine tra MCU e MPU, raggiunge fino a 600 GOPS a meno di 1W secondo le specifiche del produttore [10], un salto significativo in latenza rispetto alla generazione precedente (STM32H7) per task di person detection. Il parametro critico a questo livello non è il throughput grezzo ma l'energia per inferenza, che varia da microjoule (keyword spotting) a millijoule (visione), consentendo deployment alimentati a batteria per anni.
Livello 2: Edge accelerato
Il livello intermedio comprende dispositivi con acceleratori hardware dedicati: Google Coral Edge TPU (4 TOPS INT8, ~2W), Raspberry Pi 5 con Hailo-8L (13 TOPS INT8, ~8-12W sistema), e i SoC mobile come Snapdragon 8 Gen 3 (45 TOPS INT8, 3-5W) [11, 12]. Questi dispositivi gestiscono workload di computer vision in tempo reale (YOLOv8n a ~10ms su Hailo-8L, MobileNet V2 a ~3ms su Coral Edge TPU) ma con vincoli precisi.
Il Coral Edge TPU, ad esempio, supporta esclusivamente modelli INT8 che rientrano in 8MB di SRAM on-chip; modelli più grandi subiscono penalità severe per l'accesso a memoria off-chip [12]. Questa limitazione definisce un confine architetturale netto: i workload CNN-based di piccola-media dimensione rientrano nel dominio dell'edge accelerato, mentre i modelli di dimensione maggiore (transformer, LLM) richiedono il livello superiore.
Livello 3: Edge server (GPU edge)
Al vertice della gerarchia si collocano dispositivi con GPU o NPU ad alte prestazioni, capaci di eseguire inferenza su modelli di dimensioni significative. La famiglia NVIDIA Jetson Orin domina questo segmento: l'AGX Orin raggiunge 275 TOPS INT8 a 15-60W con un rapporto prestazioni/watt di ~4,5 TOPS/W, ed è in grado di eseguire LLM da 7B parametri quantizzati INT4 con throughput nell'ordine di 15-30 token/secondo a seconda del framework di inferenza [13, 14]. L'inclusione di workload LLM (GPT-J) nel benchmark MLPerf Inference Edge v4.1 [14] segnala il riconoscimento formale che l'inferenza generativa si sta spostando verso l'edge.
L'esecuzione di LLM su edge server introduce tuttavia vincoli specifici. Un modello da 7B parametri a FP16 richiede 14GB di DRAM; la quantizzazione INT4 riduce il requisito a ~3,5GB, rendendo il deployment fattibile su Jetson e smartphone flagship ma non su MCU o Coral. Il thermal throttling rappresenta un limite sottovalutato: l'inferenza LLM sostenuta su SoC mobile causa un degrado misurabile delle prestazioni entro pochi minuti per effetto dei limiti termici, una discrepanza significativa tra le prestazioni di benchmark (burst) e quelle reali (sustained). Apple ha affrontato il problema con quantizzazione aggressiva (2-bit/4-bit mista) e un motore di inferenza custom per il Neural Engine [32].
Tecniche di ottimizzazione: quantizzazione, pruning e distillazione
Le tecniche di ottimizzazione sono ciò che consente ai modelli di attraversare i confini tra i livelli architetturali: un modello che richiederebbe un edge server GPU può, dopo quantizzazione e pruning, essere eseguibile su un acceleratore a basso consumo; un modello per edge accelerato può, dopo distillazione e NAS, raggiungere un MCU. Il deployment su edge richiede dunque la riduzione della dimensione computazionale e di memoria dei modelli addestrati in cloud, attraverso un insieme di tecniche complementari [16, 17].
Quantizzazione
La quantizzazione riduce la precisione numerica dei pesi e delle attivazioni del modello. La transizione da FP32 a INT8 tipicamente preserva oltre il 99% dell'accuratezza su task di classificazione immagini, riducendo la dimensione del modello di 4x [4]. Per i LLM, la quantizzazione INT4 è il fattore abilitante critico per il deployment edge: AWQ (Activation-aware Weight Quantization) [17] ha dimostrato che proteggendo l'1% dei canali dei pesi più rilevanti (determinati dalle magnitudini delle attivazioni) è possibile quantizzare a INT4 con perdita di perplexity nell'ordine di 0,1-0,5 punti rispetto a FP16 su benchmark linguistici standard, un degrado generalmente accettabile per applicazioni industriali, sebbene la sensibilità vari per modello e task. Su Jetson Orin, modelli AWQ-quantizzati raggiungono speedup di 3-4x rispetto a FP16, ed AWQ è oggi integrato nelle toolchain di produzione (TensorRT-LLM, llama.cpp, vLLM).
La quantizzazione mixed-precision (INT4/INT8/FP16 nello stesso modello, con precisione diversa per layer diversi) rappresenta lo stato dell'arte per bilanciare accuratezza e efficienza. Qualcomm AI Hub [18] offre versioni pre-ottimizzate in mixed-precision di oltre 100 modelli validati su piattaforme Snapdragon, inclusi Whisper, Stable Diffusion e Llama 2 7B INT4, tutti eseguibili interamente on-device.
Pruning
Il pruning elimina pesi o strutture (filtri, attention heads, layer) il cui contributo all'output è trascurabile. Il pruning non strutturato può raggiungere il 90%+ di sparsità su ResNet-50 con meno del 2% di perdita di accuratezza top-1 [16], ma richiede supporto hardware specifico per tradurre la sparsità in speedup reale. Le GPU NVIDIA con architettura Ampere e successive (incluso Jetson Orin) supportano nativamente lo schema di sparsità strutturata 2:4, in cui 2 pesi su ogni blocco di 4 vengono azzerati, ottenendo uno speedup teorico di 2x sui tensor core senza penalità significative di accuratezza. Il pruning strutturato completo rimuove intere unità computazionali (filtri convoluzionali, attention heads, layer) producendo modelli direttamente più piccoli e veloci su qualsiasi hardware, con trade-off di accuratezza generalmente più marcati. Per i LLM, tecniche come SparseGPT e Wanda consentono di raggiungere sparsità del 50-60% con degradi contenuti di perplexity, e l'applicazione combinata di pruning e quantizzazione (es. pruning 2:4 + INT8) moltiplica i benefici delle singole tecniche.
Knowledge distillation
La distillazione trasferisce la conoscenza di un modello grande (teacher) a uno piccolo (student) durante il training. Gemma 2 2B [19] ne è un esempio paradigmatico: distillato dai modelli Gemini di Google, eguaglia o supera Llama 2 7B (3,5x più grande) su diversi benchmark, ed esegue on-device a ~30 token/secondo su Pixel 8 Pro. L'evidenza suggerisce che la distillazione top-down (da modelli grandi a piccoli) produce risultati superiori all'addestramento diretto di modelli piccoli, rendendola il percorso più efficace verso LLM edge-deployable. Analogamente, Phi-3-mini di Microsoft (3,8B parametri) raggiunge prestazioni a livello GPT-3.5 in meno di 2GB (INT4), con ~20 token/secondo su Snapdragon 8 Gen 3 [20].
Neural Architecture Search per edge
L'approccio Once-for-All [21] ha ridotto il costo della Neural Architecture Search (NAS) per dispositivi eterogenei: una singola rete viene addestrata una volta, e sotto-reti ottimizzate per target hardware specifici (telefoni, Raspberry Pi, Jetson Nano) vengono estratte senza ri-addestramento, azzerando il costo di NAS per dispositivo (da oltre 200 GPU-ore a zero).
Runtime e toolchain per l'inferenza edge
L'esecuzione efficiente di modelli ottimizzati su hardware edge richiede runtime specializzati che sfruttino le istruzioni specifiche di ciascun processore.
ONNX Runtime [22] è il runtime cross-platform di riferimento, con execution provider dedicati per CPU ARM, GPU mobile, NPU e dispositivi embedded. Il formato ONNX funge da lingua franca tra framework di training (PyTorch, TensorFlow) e target di deployment. LiteRT (ex TensorFlow Lite) [23] è il runtime on-device più diffuso al mondo, con supporto per delegazione hardware a GPU e NPU e un nuovo CompiledModel API per massimizzare l'accelerazione. TensorFlow Lite for Microcontrollers (TFLM) [24] estende il paradigma ai MCU con pochi kilobyte di memoria, con porting su ESP32, Arduino, Zephyr RTOS e decine di piattaforme embedded.
Per dispositivi NVIDIA, TensorRT [25] ottimizza i modelli attraverso fusione di layer, calibrazione di precisione e auto-tuning dei kernel, ed è il runtime standard per tutta la famiglia Jetson. OpenVINO [26] di Intel svolge un ruolo analogo per hardware Intel (CPU, GPU, NPU), con supporto per modelli da PyTorch, TensorFlow, ONNX e JAX. Apache TVM [27] adotta un approccio diverso: è un compilatore ML che genera codice ottimizzato per qualsiasi backend hardware, inclusi MCU bare-metal tramite microTVM, attraverso ottimizzazioni automatiche a livello di tensore (TensorIR) e di grafo (Relax).
La scelta del runtime è guidata da tre criteri: portabilità cross-platform, prestazioni massime su hardware specifico, e vincoli di memoria. Per la portabilità, ONNX Runtime e Apache TVM coprono il più ampio spettro di target da un singolo modello sorgente. Per le prestazioni massime su hardware specifico, TensorRT (NVIDIA) e OpenVINO (Intel) offrono ottimizzazioni vendor-specific che i runtime generici non raggiungono, al costo di un lock-in hardware. Per i target MCU, TFLM e microTVM sono le uniche opzioni praticabili, con TFLM che offre il supporto più ampio di piattaforme e microTVM che consente ottimizzazioni compilate più aggressive. In molti deployment industriali, la pipeline prevede training in cloud (PyTorch), esportazione ONNX, ottimizzazione con il runtime specifico del target, e deployment del modello ottimizzato sul dispositivo edge.
Edge-cloud orchestration e federated learning
Il deployment edge non è un'isola: richiede orchestrazione con il cloud per la gestione del ciclo di vita dei modelli, il monitoraggio, l'aggiornamento e il ri-addestramento.
KubeEdge [28], progetto CNCF a livello Graduated, estende Kubernetes ai nodi edge con un agente leggero (EdgeCore) che supporta operazione autonoma offline e messaggistica affidabile cloud-edge. Azure IoT Edge [29] offre un runtime containerizzato per workload Linux su dispositivi edge, integrato con Azure ML e ONNX Runtime per pipeline di inferenza. La convergenza con le reti 5G aggiunge un ulteriore livello: ETSI MEC [2] definisce API standardizzate per la gestione del ciclo di vita delle applicazioni edge, il service discovery e il routing del traffico ai margini della rete mobile, con supporto esplicito per l'orchestrazione di workload AI.
Per scenari in cui i dati non possono lasciare il dispositivo (privacy, regolamentazione, vincoli di banda), il federated learning [5] consente di addestrare modelli distribuiti senza centralizzare i dati. L'algoritmo FedAvg [5] riduce le comunicazioni necessarie di 10-100x rispetto a SGD distribuito naïve, e la survey di Kairouz et al. [30], con oltre 600 riferimenti, identifica comunicazione, eterogeneità dei dispositivi e dati non-IID come le tre sfide principali. In produzione, il federated learning resta limitato a scenari ristretti (tastiere predittive, personalizzazione on-device), con l'addestramento completamente autonomo sul dispositivo (Level 6 della tassonomia di Zhou et al. [3]) ancora un traguardo prevalentemente accademico.
Limiti e problemi aperti
L'edge computing per l'AI è una tecnologia in fase di maturazione rapida ma con limiti concreti che influenzano la progettazione di soluzioni reali.
Il partizionamento device-edge-cloud resta un problema di ottimizzazione non banale. Neurosurgeon [31] ha dimostrato che la scelta del layer ottimale in cui dividere l'inferenza tra dispositivo ed edge server dipende dalle condizioni di rete, dal carico computazionale e dalle caratteristiche del modello, con guadagni fino a 3,1x in latenza e 40% in consumo energetico rispetto a un'esecuzione cloud-only. Tuttavia, le condizioni di rete variano dinamicamente, e nessun framework di produzione gestisce questa ottimizzazione in modo completamente automatico.
Il thermal throttling è il vincolo più sottovalutato per l'inferenza LLM sostenuta su dispositivi mobili e edge. I benchmark MLPerf misurano prestazioni di burst; in condizioni di esecuzione continua, il surriscaldamento dei SoC mobili può ridurre significativamente il throughput effettivo rispetto ai valori nominali, vanificando i margini di latenza su cui si basa il business case. Apple ha affrontato il problema con quantizzazione aggressiva (2-bit/4-bit mista) e un motore di inferenza custom per il Neural Engine [32], un approccio che richiede co-design hardware-software non replicabile su piattaforme generiche.
La frammentazione dell'ecosistema hardware rende complesso costruire soluzioni portabili. Ogni famiglia di dispositivi (NVIDIA, Qualcomm, Intel, ARM, RISC-V, MCU-specifici) richiede toolchain di ottimizzazione diverse, e un modello ottimizzato per TensorRT non è direttamente eseguibile su OpenVINO o Edge TPU. ONNX e Apache TVM mitigano parzialmente questo problema fornendo formati e compilatori cross-platform, ma il tuning fine per massimizzare le prestazioni resta hardware-specific.
Infine, il monitoraggio e aggiornamento dei modelli in produzione su dispositivi distribuiti presenta sfide operative significative. A differenza del cloud, dove un modello è centralizzato e aggiornabile in secondi, un deployment su migliaia di dispositivi edge richiede meccanismi di OTA (over-the-air) update robusti, rollback in caso di regressione, e monitoraggio del model drift senza connettività costante, un'area in cui le soluzioni esistenti (KubeEdge, Azure IoT Edge) forniscono primitive utili ma non pipeline complete.
Riferimenti
[1] M. Satyanarayanan, "The Emergence of Edge Computing," IEEE Computer, 2017. https://doi.org/10.1109/MC.2017.9
[2] ETSI, "Multi-access Edge Computing (MEC) Standards," GS MEC 003 v3.1, 2024. https://www.etsi.org/technologies/multi-access-edge-computing
[3] Z. Zhou et al., "Edge Intelligence: Paving the Last Mile of Artificial Intelligence with Edge Computing," Proc. IEEE, 2019. https://doi.org/10.1109/JPROC.2019.2918951
[4] M. G. S. Murshed et al., "Machine Learning at the Network Edge: A Survey," ACM Computing Surveys, 2022. https://doi.org/10.1145/3469029
[5] B. McMahan et al., "Communication-Efficient Learning of Deep Networks from Decentralized Data," Proc. AISTATS, 2017. https://arxiv.org/abs/1602.05629
[6] IDC, "Worldwide Edge Spending Forecast," 2025.
[7] Gartner, "Hype Cycle for Edge Computing," 2024.
[8] J. Lin et al., "MCUNet: Tiny Deep Learning on IoT Devices," Proc. NeurIPS, 2020. https://arxiv.org/abs/2007.10319
[9] MLCommons, "MLPerf Tiny Inference Benchmark v1.2 Results," 2024. https://mlcommons.org/benchmarks/inference-tiny/
[10] STMicroelectronics, "STM32 Model Zoo and STM32Cube.AI," 2025. https://stm32ai.st.com/
[11] Raspberry Pi Foundation, "Raspberry Pi AI Kit (Hailo-8L)," 2024. https://www.raspberrypi.com/products/ai-kit/
[12] Google Coral, "Edge TPU Performance Benchmarks," 2024. https://coral.ai/docs/edgetpu/benchmarks/
[13] NVIDIA, "Jetson Orin Technical Specifications," 2024. https://developer.nvidia.com/embedded/jetson-orin
[14] MLCommons, "MLPerf Inference v4.1 Results," 2024. https://mlcommons.org/benchmarks/inference-edge/
[15] G. Menghani, "Efficient Deep Learning: A Survey on Making Deep Learning Models Smaller, Faster, and Better," ACM Computing Surveys, 2023. https://arxiv.org/abs/2106.08962
[16] R. Mishra, H. P. Gupta, T. Dutta, "A Survey on Deep Neural Network Compression: Challenges, Overview, and Solutions," IEEE Trans. Neural Networks and Learning Systems, 2023. https://doi.org/10.1109/TNNLS.2023.3253680
[17] J. Lin et al., "AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration," Proc. MLSys, 2024. https://arxiv.org/abs/2306.00978
[18] Qualcomm, "Qualcomm AI Hub — Optimized Model Library," 2024. https://aihub.qualcomm.com/
[19] Google DeepMind, "Gemma 2: Improving Open Language Models at a Practical Size," 2024. https://arxiv.org/abs/2408.00118
[20] M. Abdin et al., "Phi-3 Technical Report: A Highly Capable Language Model Locally on Your Phone," Microsoft Research, 2024. https://arxiv.org/abs/2404.14219
[21] H. Cai et al., "Once-for-All: Train One Network and Specialize it for Efficient Deployment," Proc. ICLR, 2020. https://arxiv.org/abs/1908.09791
[22] Microsoft, "ONNX Runtime," 2024. https://onnxruntime.ai/
[23] Google AI Edge, "LiteRT (formerly TensorFlow Lite)," 2026. https://ai.google.dev/edge/litert
[24] TensorFlow, "TensorFlow Lite for Microcontrollers," 2024. https://github.com/tensorflow/tflite-micro
[25] NVIDIA, "TensorRT," 2024. https://developer.nvidia.com/tensorrt
[26] Intel, "OpenVINO Toolkit," 2026. https://docs.openvino.ai/
[27] Apache Software Foundation, "Apache TVM," 2024. https://tvm.apache.org/
[28] CNCF, "KubeEdge," 2024. https://kubeedge.io/
[29] Microsoft, "Azure IoT Edge," 2024. https://learn.microsoft.com/en-us/azure/iot-edge/
[30] P. Kairouz, H. B. McMahan et al., "Advances and Open Problems in Federated Learning," Foundations and Trends in Machine Learning, 2021. https://arxiv.org/abs/1912.04977
[31] Y. Kang et al., "Neurosurgeon: Collaborative Intelligence Between the Cloud and Mobile Edge," Proc. ACM ASPLOS, 2017. https://doi.org/10.1145/3037697.3037698
[32] Apple Machine Learning Research, "Apple Intelligence Foundation Language Models," 2024. https://machinelearning.apple.com/research/apple-intelligence-foundation-language-models