⚡ electrical engineering

Can the Cloud Drive? Infrastructure Feasibility of Offloading Autonomous Driving Across 5G and 6G

Questo articolo presenta un quadro analitico che dimostra come, sebbene i limiti di comunicazione e la latenza dell'hardware attualmente limitino la guida autonoma basata su cloud, le future reti 6G e le risorse GPU condivise renderanno infine l'offloading a livello di feature di grandi modelli visione-linguaggio-azione sia tecnicamente fattibile che economicamente superiore al deployment a bordo.

Autori originali: Pouya Parsa, Kawon Han, Seongjin Choi

Pubblicato 2026-07-13

📖 6 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Pouya Parsa, Kawon Han, Seongjin Choi

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 cercare di guidare un'auto che pensa da sola, ma invece di avere un super-cervello all'interno del cruscotto, vuoi inviare tutto il suo pensiero a un cervello gigante e condiviso nel cloud. Sembra un sogno fantascientifico: perché comprare un computer da 10.000 dollari per ogni auto quando puoi semplicemente affittare una fetta di un supercomputer massiccio?

Ma prima di iniziare a sognare auto guidate dal cloud, dobbiamo chiederci: il cloud può davvero guidare?

Un team di ricercatori ha deciso di fare due conti, simulando una giornata frenetica a New York City per vedere se questa idea potesse mai funzionare. Non si sono limitati a tirare a indovinare; hanno costruito un modello complesso che controlla tre diversi "cancelli" che un'auto deve superare per far arrivare il proprio cervello nel cloud. Immaginalo come un videogioco a tre livelli dove devi superare il primo livello per poter nemmeno vedere il secondo.

Livello 1: L'autostrada dei dati (Il cancello della comunicazione)

Per prima cosa, immagina che la tua auto sia uno streamer di videogiochi. Per inviare i suoi "pensieri" al cloud, deve caricare un enorme file video. In una città affollata, migliaia di auto stanno cercando di caricare contemporaneamente.

I ricercatori hanno scoperto che se provi a inviare video grezzi dalle telecamere (Strategia S1), l'autostrada di internet si intasa quasi istantaneamente. È come cercare di versare una piscina intera attraverso un tubo da giardino; il tubo non può gestire un simile flusso. Nelle loro simulazioni, anche con le migliori reti 5G odierne, una città come New York soffocherebbe se troppe auto cercassero di inviare video grezzi.

Tuttavia, esiste una via di mezzo. Se l'auto fa un po' di pensiero prima — comprimendo il video in "caratteristiche" o "feature" (Strategia S2) — invia un pacchetto molto più piccolo. Lo studio suggerisce che con il 5G-Advanced (una versione leggermente più recente del 5G) o il 6G, questi dati compressi potrebbero passare attraverso il tubo, ma solo se la città non è assolutamente strapiena di auto. Se provi a inviare il video grezzo (S1) o aspetti che la prossima generazione di internet gestisca tutto, probabilmente rimarrai bloccato nel traffico. Il documento esclude esplicitamente l'offloading di video grezzi in città dense con la tecnologia attuale.

Livello 2: La velocità di pensiero (Il cancello del calcolo)

Supponiamo che tu abbia superato il Livello 1 e che i dati siano arrivati al cloud. Ora, il cloud deve pensare abbastanza velocemente da dire all'auto come sterzare.

Ecco il colpo di scena: il cloud è veloce, ma non istantaneamente veloce. I ricercatori hanno esaminato i modelli di IA più recenti e intelligenti (chiamati modelli VLA o Vision-Language-Action). Questi modelli sono come un genio che ha bisogno di leggere un intero libro prima di rispondere a una domanda.

Lo studio ha trovato un muro invalicabile: la larghezza di banda della memoria. Anche se il cloud possiede i chip di calcolo più veloci del mondo, i nuovi modelli VLA devono "rileggere" la propria memoria per ogni singolo passaggio del loro pensiero. È come uno chef che deve camminare fino alla dispensa per prendere un ingrediente per ogni singolo pizzico che aggiunge alla zuppa.

Nelle loro simulazioni, questo "camminare verso la dispensa" richiede circa 114 millisecondi solo per la parte del pensiero. Aggiungendo il tempo per inviare i dati avanti e indietro, il tempo totale supera i 100 millisecondi.

La brutta notizia: Per far sì che un'auto reagisca istantaneamente (come sterzare per evitare un pedone), ha bisogno di una decisione in 100 millisecondi. Il documento suggerisce che per questi super-intelligenti modelli VLA, il cloud è semplicemente troppo lento al momento, indipendentemente da quanto sia veloce la tua connessione internet. Non saranno in grado di guidare in modo reattivo fino a circa il 2027 o il 2028, quando la memoria dei computer diventerà più veloce.
Il colpo di scena: Se l'auto ha un "cervello di riserva" a bordo che gestisce le emergenze in 100 ms, il cloud può occuparsi del pensiero più lento e "deliberativo" (come pianificare un percorso) con un budget di 300 millisecondi. Ma il cloud non può essere l'unico cervello per la sicurezza immediata.

Livello 3: Il cartellino del prezzo (Il cancello del costo)

Infine, supponiamo che risolviamo i problemi di velocità e di internet. È più economico affittare il cervello nel cloud piuttosto che comprarne uno per ogni auto?

È qui che avviene la magia. I ricercatori hanno scoperto che per i modelli di IA più costosi e complessi (VLA), il cloud è un enorme risparmio. Perché? Perché un'auto resta parcheggiata per il 95% della giornata. Se compri un computer da 8.500 dollari per ogni auto, quel computer rimarrà inattivo la maggior parte del tempo. Ma nel cloud, un unico supercomputer può servire migliaia di auto che stanno effettivamente guidando nello stesso momento.

Lo studio suggerisce che, una volta risolti i problemi di velocità e internet, l'offloading a livello di caratteristiche (Strategia S2) è la scelta ideale. È l'unica strategia che permette di risparmiare abbastanza denaro da battere il costo dell'acquisto dell'hardware per ogni singola auto. Se provi a inviare video grezzi (S1), i costi di internet mangiano i risparmi. Se mantieni troppo calcolo all'interno dell'auto (S3), non risparmi abbastanza.

Il quadro generale

Quindi, può il cloud guidare? La risposta non è un semplice "sì" o "no".

Non è un interruttore magico: Non puoi semplicemente collegare un'auto al cloud oggi stesso. L'internet in una città affollata si romperebbe e il cloud è troppo lento per le reazioni di emergenza in questo momento.
È una questione di attesa: Il documento suggerisce che abbiamo bisogno del 6G (o di un 5G molto avanzato) per l'internet, e di una memoria computer più veloce per la velocità.
È una divisione intelligente: Il piano migliore non è inviare tutto al cloud. L'auto dovrebbe mantenere gli "occhi" e i "riflessi" localmente, e inviare solo il "pensiero" e la "pianificazione" al cloud. Questa via di mezzo (Strategia S2) è dove avvengono i risparmi.

In breve, il cloud potrebbe eventualmente guidare le nostre auto, ma solo se costruiremo migliori strade per i dati, aspetteremo chip di memoria più veloci e terremo un cervello di riserva nell'auto per ogni evenienza. Fino ad allora, il cervello dell'auto rimane la scommessa più sicura.

Sintesi Tecnica: Il Cloud può Guidare? Fattibilità Infrastrutturale dell'Offloading della Guida Autonoma tramite 5G e 6G

1. Definizione del Problema

Il documento affronta le crescenti richieste computazionali dei modelli di guida autonoma (AD) all'avanguardia, specificamente le architetture Vision-Language-Action (VLA), che richiedono passaggi in avanti (forward passes) prossimi a ~60 TFLOPs. Sebbene l'attuale hardware System-on-Chip (SoC) automobilistico possa supportare marginalmente i carichi di lavoro precedenti di tipo End-to-End (E2E) o Vision-Language Model (VLM), l'implementazione di VLA più grandi a bordo è economicamente inefficiente. I veicoli privati sono parcheggiati circa il 95% del tempo, il che significa che l'hardware di punta rimane inattivo per la maggior parte della giornata.

La domanda centrale è se l'inferenza in cloud possa sostituire l'hardware a bordo condividendo GPU costose tra i veicoli attivi. Tuttavia, questo non è solo un problema di calcolo; è una sfida di sistema accoppiata che coinvolge tre distinti vincoli, raramente analizzati insieme:

Suddivisione del Modello di Guida (Driving Model Split): Determinare quali stadi della pipeline (sensing, percezione, pianificazione, decoding) rimangano a bordo rispetto a quelli delegati (offloaded).
Comunicazione Veicolare: La capacità dell'uplink di sostenere flussi di dati continui ad alto tasso da veicoli attivi verso il cloud entro un tempo limite a ciclo chiuso (closed-loop).
Servizio GPU in Cloud: La capacità delle GPU condivise di servire richieste burst (improvvise) entro budget di latenza rigorosi (reattivi vs. deliberativi) gestendo al contempo le code (queueing tails).

La letteratura esistente tratta spesso questi sistemi isolatamente. Questo documento sostiene che sia necessario un framework unificato per determinare se la guida in cloud sia tecnicamente fattibile ed economicamente vantaggiosa.

2. Metodologia

Gli autori propongono un framework analitico unificato applicato a un caso di studio urbano denso (New York City). Il framework integra tre sistemi in una pipeline di valutazione sequenziale:

2.1. Pipeline Analitica

La pipeline valuta gli scenari attraverso tre "regimi di vincolo" (binding regimes) annidati:

Gate di Comunicazione: Determina se la rete di accesso può ammettere il numero richiesto di veicoli attivi dato l'uplink richiesto da una specifica strategia di offloading.
Gate di Latenza: Valuta se la latenza totale end-to-end (deterministica + stocastica) rientra nel budget del ciclo di controllo (100 ms reattivo o 300 ms deliberativo).
Gate di Costo: Per i rami fattibili, confronta il Total Cost of Ownership (TCO) dell'offloading in cloud rispetto alla baseline dell'hardware completo a bordo.

2.2. Componenti Chiave della Modellazione

Strategie di Offloading: Sono definite tre strategie basate sul punto di divisione della pipeline:
- S1 (Raw Sensor): Offload dei dati grezzi dei sensori (uplink elevato, calcolo a bordo basso).
- S2 (Feature-Level): Offload di feature compresse dopo la backbone di visione (uplink moderato, calcolo a bordo moderato).
- S3 (Query-Level): Offload di query di scena compatte dopo il transformer encoder (uplink basso, calcolo a bordo elevato).
Modello di Comunicazione: Utilizza un modello di uplink OFDMA consapevole delle interferenze. Calcola l'efficienza spettrale per utente in base al carico della cella e all'interferenza multi-utente per determinare il numero massimo di veicoli attivi ( $N_{max}$ ) che una cella può supportare per una data strategia e generazione (5G, 5G-Advanced, 6G).
Modello di Servizio GPU:
- Roofline Inference: Modella il tempo di inferenza VLA come la somma di componenti limitate dal calcolo (encoder/prefill) e limitate dalla larghezza di banda della memoria (autoregressive decode).
- Code (Queueing): Utilizza una coda M/D/ $c$ con limiti della coda Erlang-C per garantire che eventi di attesa prolungata siano rari e rimangano entro il budget di latenza.
- Evoluzione dell'Hardware: Proietta le prestazioni della GPU (A100 $\to$ B300 $\to$ futuro) utilizzando un modello di crescita decelerata sia per il throughput di calcolo che per la larghezza di banda HBM.
Decomposizione della Latenza: Separa il ciclo di controllo in componenti deterministiche (sensing, encoding, inference, actuation) e componenti stocastiche (scheduling di rete, trasmissione, routing, queueing). La fattibilità richiede che la somma stocastica rientri nel budget rimanente con una probabilità di coda $\le 10^{-5}$ .

2.3. Parametri del Caso di Studio

Località: New York City (~2,2 milioni di veicoli registrati, ~10.000 siti cellulari).
Variabili: 3 generazioni di comunicazione (5G, 5G-Adv, 6G), 3 classi di modelli (E2E, VLM, VLA), 3 strategie (S1, S2, S3), 8 livelli di penetrazione e 6 livelli di utilizzo.
Budget: 100 ms (controllo reattivo) e 300 ms (pianificazione deliberativa, assumendo un fallback a bordo).

3. Risultati Chiave

3.1. Regime 1: Vincolato dalla Comunicazione (Celle Dense)

Negli ambienti urbani densi, la capacità di uplink è il principale vincolo limitante.

S1 (Raw Sensor): Richiede ~100 Mbps per veicolo. Anche con il 6G, S1 è impraticabile per un'alta penetrazione/utilizzo in celle dense. Il 5G fallisce quasi immediatamente.
S2 (Feature-Level): Richiede ~25 Mbps. Il 5G supporta solo ~2% di penetrazione con un utilizzo moderato. 5G-Advanced è la soglia pratica per S2 in corridoi densi, supportando fino a ~30% di penetrazione. Il 6G fornisce l'effettivo margine necessario per una diffusione più ampia.
S3 (Query-Level): Richiede ~3 Mbps. È facilmente supportato dal 5G, ma lascia un calcolo significativo a bordo, riducendo il beneficio economico dell'offloading.

3.2. Regime 2: Vincolato dal Calcolo (Latenza Reattiva)

Anche con larghezza di banda sufficiente, i modelli VLA di prossima generazione affrontano un limite minimo di latenza dovuto ai vincoli della larghezza di banda della memoria.

Decode Limitato dalla Memoria: Il decoding autoregressivo di VLA è dominato dalla larghezza di banda HBM (lettura dei pesi per ogni token), non dal throughput aritmetico. Su hardware del 2025 (B300), il limite deterministico di inferenza per VLA è di ~132–164 ms, superando il budget reattivo di 100 ms.
Timeline: Il limite deterministico di VLA supera il budget di 100 ms intorno al 2027.
- Budget Reattivo (100 ms): VLA è latenza-incompatibile nel 2026 indipendentemente dalla larghezza di banda. Entro il 2028, il 6G ammette il VLA a livello di feature (S2) in corridoi densi; il 5G-Advanced lo ammette solo sotto carichi leggeri.
- Budget Deliberativo (300 ms): VLA è fattibile dal 2026, ma questo livello è ammissibile solo se esiste un fallback reattivo a bordo.

3.3. Regime 3: Vincolato dal Costo (Economia)

Una volta stabilita la fattibilità tecnica, l'utilizzo guida la convergenza economica.

Effetto dell'Utilizzo: Le GPU in cloud sono allocate per la domanda attiva, mentre l'hardware a bordo viene pagato per ogni veicolo. Le flotte con utilizzo basso-moderato ottengono il massimo dall'offloading.
Sensibilità della Classe di Modello:
- E2E: L'hardware a bordo è economico (~$400/anno); l'offloading in cloud offre pochi vantaggi di costo.
- VLA: L'hardware a bordo è costoso (~$8.500/anno) e inattivo. L'offloading in cloud diventa significativamente più economico una volta soddisfatti i vincoli di latenza.
Strategia Ottimale: L'Offloading a Livello di Feature (S2) concentra il crossover dei costi di VLA. Bilancia la richiesta di uplink (fattibile su 5G-Advanced/6G) con il calcolo residuo a bordo (abbastanza basso da rendere l'offloading economicamente vantaggioso). S1 è troppo pesante in termini di banda; S3 mantiene troppo hardware a bordo.

4. Significato e Rivendicazioni

Il documento afferma che la risposta a "Il cloud può guidare?" è condizionale e sequenziale, a seconda della classe di modello, dell'anno della GPU e del budget di latenza.

Tre Regimi Annidati: La fattibilità non è binaria. È determinata da una sequenza di vincoli:
- La Comunicazione vincola per prima nelle celle dense (eliminando S1 e richiedendo 5G-Advanced/6G per S2).
- Il Calcolo (Larghezza di Banda della Memoria) vincola successivamente per VLA sotto budget reattivi (rendendo il VLA a breve termine incompatibile indipendentemente dalla velocità di rete).
- Il Costo vincola per ultimo, dove l'utilizzo determina se l'opzione cloud è economicamente superiore all'hardware a bordo.
Il Ruolo di S2: L'offloading a livello di feature è identificato come il "punto di equilibrio" robusto. È l'unica strategia che soddisfa simultaneamente i vincoli di comunicazione nelle celle dense e preserva sufficienti risparmi hardware per rendere l'offloading in cloud economicamente sostenibile per i modelli VLA costosi.
Implicazioni Politiche:
- Spettro: L'allocazione di uno spettro con forte enfasi sull'uplink è critica per i corridoi AV, invertendo il tipico schema consumer orientato al downlink.
- Infrastruttura: È necessaria un'infrastruttura edge condivisa (co-investimento) per ammortizzare i costi delle GPU.
- Sicurezza: La certificazione deve imporre fallback reattivi a bordo (es. S3 o inferenza completa locale) per qualsiasi architettura che si affidi alla pianificazione deliberativa in cloud, garantendo una degradazione aggraziata durante i guasti di rete.
Limitazioni: Gli autori notano che i risultati sono conservativi, assumendo un decoding autoregressivo FP16. Futuri cambiamenti architettonici (es. decoder di diffusione, speculative decoding, FP8) potrebbero accelerare la fattibilità di VLA. Inoltre, i parametri del 6G sono obiettivi aspirazionali.

In conclusione, il documento dimostra che la guida in cloud non è un sostituto universale del calcolo a bordo, ma un'alternativa fattibile e conveniente per specifiche classi di modelli (VLA) e profili di utilizzo, a condizione che l'infrastruttura di comunicazione (5G-Advanced/6G) e l'evoluzione della larghezza di banda della memoria si allineino ai rigorosi requisiti di latenza del controllo reattivo.