⚡ electrical engineering

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

Dit artikel presenteert een analytisch kader dat aantoont dat hoewel communicatielimieten en hardwarelatentie cloudgebaseerd autonoom rijden momenteel beperken, toekomstige 6G-netwerken en gepoolde GPU-bronnen feature-level offloading van grote vision-language-action modellen uiteindelijk zowel technisch haalbaar als economisch superieur zullen maken aan on-board implementatie.

Oorspronkelijke auteurs: Pouya Parsa, Kawon Han, Seongjin Choi

Gepubliceerd 2026-07-13

📖 6 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Pouya Parsa, Kawon Han, Seongjin Choi

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een auto probeert te besturen die voor zichzelf denkt, maar in plaats van een superbrein in het dashboard te hebben, wil je al het denken naar een gigantische, gedeelde hersenpan in de cloud sturen. Het klinkt als een sciencefiction-droom: waarom zou je voor elke auto een computer van $10.000 kopen als je ook gewoon een stukje van een enorme supercomputer kunt huren?

Maar voordat we gaan dromen over door de cloud gestuurde auto's, moeten we ons de vraag stellen: Kan de cloud daadwerkelijk rijden?

Een team onderzoekers besloot de cijfers te analyseren door een drukke dag in New York City te simuleren om te zien of dit idee ooit zou kunnen werken. Ze gokten niet zomaar wat; ze bouwden een complex model dat drie verschillende "poorten" controleert waar een auto doorheen moet om zijn brein in de cloud te krijgen. Denk aan een videogame met drie levels waarbij je eerst het eerste level moet verslaan voordat je het tweede zelfs maar kunt zien.

Level 1: De Data-snelweg (De Communicatiepoort)

Stel je eerst voor dat je auto een video-streamer is. Om zijn "gedachten" naar de cloud te sturen, moet hij een enorme videobestanden uploaden. In een drukke stad proberen duizenden auto's tegelijkertijd te uploaden.

De onderzoekers ontdekten dat als je ruwe video van de camera's probeert te sturen (Strategie S1), de internetsnelweg bijna direct verstopt raakt. Het is alsof je een zwembad aan water door een tuinslang probeert te gieten; de pijp kan het simpelweg niet aan. In hun simulaties zou een stad als New York zouden stikken als er te veel auto's tegelijk ruwe video zouden proberen te sturen, zelfs met de beste 5G-netwerken van vandaag.

Er is echter een middenweg. Als de auto eerst een beetje zelf nadenkt — door de video te comprimeren tot "features" (Strategie S2) — stuurt hij een veel kleiner pakketje. De studie suggereert dat met 5G-Advanced (een iets nieuwere versie van 5G) of 6G, deze gecomprimeerde data misschien wel door de pijp past, maar alleen als de stad niet absoluut overvol staat met auto's. Als je de ruwe video probeert te sturen (S1) of wacht op de volgende generatie internet (6G) om alles te kunnen verwerken, sta je waarschijnlijk in de file. Het artikel sluit het offloaden van ruwe video in dichtbevolkte steden met de huidige technologie expliciet uit.

Level 2: De Denksnelheid (De Compute-poort)

Stel dat je Level 1 hebt verslagen en de data de cloud heeft bereikt. Nu moet de cloud snel genoeg nadenken om de auto te vertellen hoe hij moet sturen.

Hier komt de twist: de cloud is snel, maar niet instantaan snel. De onderzoekers keken naar de nieuwste, slimste AI-modellen (genoemd VLA of Vision-Language-Action modellen). Deze modellen zijn als een genie dat een heel boek moet lezen voordat het een vraag kan beantwoorden.

De studie vond een harde grens: geheugenbandbreedte. Zelfs als de cloud over de snelste computerchips ter wereld beschikt, moeten deze nieuwe VLA-modellen hun geheugen voor elke stap van hun denkproces opnieuw "lezen". Het is als een chef-kok die naar de voorraadkast moet lopen om een specerij te pakken voor elke enkel snuf die hij aan de soep toevoegt.

In hun simulaties duurt dit "naar de voorraadkast lopen" ongeveer 114 milliseconden alleen al voor het denkgedeelte. Tel daar de tijd bij op om de data heen en weer te sturen, en de totale tijd is meer dan 100 milliseconden.

Het slechte nieuws: Voor een auto om direct te reageren (zoals uitwijken voor een voetganger), is een beslissing nodig binnen 100 milliseconden. Het artikel suggereert dat voor deze super slimme VLA-modellen de cloud er op dit moment simpelweg te langzaam voor is, ongeacht hoe snel je internet is. Ze zullen pas rond 2027 of 2028 in staat zijn om reactief te rijden, wanneer het computergeheugen sneller wordt.
De uitzondering: Als de auto een "reservebrein" aan boord heeft dat noodsituaties in 100 ms afhandelt, kan de cloud de controle overnemen voor langzamere, "overpeinzende" taken (zoals het plannen van een route) met een budget van 300 milliseconden. Maar de cloud kan niet het enige brein zijn voor directe veiligheid.

Level 3: Het Prijskaartje (De Kostenpoort)

Stel nu dat we de snelheid en het internet oplossen. Is het goedkoper om een cloudbrein te huren dan om er een voor elke auto te kopen?

Dit is waar de magie gebeurt. De onderzoekers ontdekten dat voor de duurste, meest complexe AI-modellen (VLA), de cloud een enorme geldbesparing oplevert. Waarom? Omdat een auto 95% van de dag geparkeerd staat. Als je voor elke auto een computer van $8.500 koopt, staat die computer het grootste deel van de tijd stil. Maar in de cloud kan één supercomputer duizenden auto's bedienen die op dat moment daadwerkelijk rijden.

De studie suggereert dat, zodra de snelheid en internetproblemen zijn opgelost, feature-level offloading (Strategie S2) het ideale punt is. Dit is de enige strategie die genoeg geld bespaart om de kosten van het kopen van hardware voor elke auto te verslaan. Als je ruwe video probeert te sturen (S1), eten de internetkosten de besparingen op. Als je te veel rekenkracht in de auto houdt (S3), bespaar je niet genoeg geld.

De Grote Lijn

Dus, kan de cloud rijden? Het antwoord is geen simpel "ja" of "nee".

Het is geen magische schakelaar: Je kunt een auto vandaag niet zomaar op de cloud aansluiten. Het internet in een drukke stad zou breken, en de cloud is momenteel te traag voor directe reacties.
Het is een wachten op de juiste tijd: Het artikel suggereert dat we moeten wachten op 6G (of zeer geavanceerde 5G) voor het internet, en op sneller computergeheugen voor de snelheid.
Het is een slimme verdeling: Het beste plan is niet om alles naar de cloud te sturen. De auto moet de "ogen" en de "reflexen" lokaal houden, en alleen het "denken" en het "plannen" naar de cloud sturen. Dit middenpad (Strategie S2) is waar de besparingen plaatsvinden.

Kortom, de cloud zal uiteindelijk misschien onze auto's besturen, maar alleen als we betere wegen voor data bouwen, wachten op snellere geheugenchips en een reservebrein in de auto houden voor het geval dat nodig is. Tot die tijd is het eigen brein van de auto nog steeds de veiligste keuze.

Technische Samenvatting: Kan de Cloud Besturen? Infrastructuur-haalbaarheid van het Offloaden van Autonoom Rijden via 5G en 6G

1. Probleemstelling

Het artikel behandelt de groeiende computationele eisen van voorontwikkelde autonome rijmodellen (AD), specifiek Vision-Language-Action (VLA) architecturen, die een forward pass vereisen die de ~60 TFLOPs nadert. Hoewel huidige automotive System-on-Chip (SoC) hardware marginaal de eerdere End-to-End (E2E) of Vision-Language Model (VLM) workloads kan ondersteunen, is het implementeren van grotere VLA's aan boord economisch inefficiënt. Persoonlijke voertuigen staan ongeveer 95% van de tijd geparkeerd, wat betekent dat de piek-hardware het grootste deel van de dag ongebruikt blijft.

De centrale vraag is of cloud-inferentie de hardware aan boord kan vervangen door dure GPU's te delen over actieve voertuigen. Dit is echter niet louter een computervraagstuk; het is een gekoppeld systeemprobleem dat drie verschillende beperkingen omvat die zelden samen worden geanalyseerd:

Driving Model Split: Bepalen welke pijplijnfasen (sensing, perceptie, planning, decoding) aan boord blijven versus worden geoffload.
Voertuigcommunicatie: De capaciteit van de uplink om continue datastromen met een hoge snelheid van actieve voertuigen naar de cloud te onderhouden binnen een closed-loop deadline.
Cloud GPU Service: Het vermogen van gedeelde GPU's om bursty verzoeken te bedienen binnen strikte latentiebudgetten (reactief versus deliberatief) terwijl wachtrij-tails worden beheerd.

Bestaande literatuur behandelt deze systemen vaak geïsoleerd. Dit artikel betoogt dat een verenigd kader vereist is om te bepalen of cloud-rijden technisch haalbaar en economisch rendabel is.

2. Methodologie

De auteurs stellen een verenigd analytisch kader voor dat wordt toegepast op een casestudy van een dichtbevolkt stedelijk gebied (New York City). Het kader integreert drie systemen in een sequentiële evaluatiepijplijn:

2.1. Analytische Pijplijn

De pijplijn evalueert scenario's via drie geneste "binding regimes":

Communicatiepoort: Bepaalt of het toegangsnetwerk het vereiste aantal actieve voertuigen kan toelaten, gegeven de uplink-vraag van een specifieke offloading-strategie.
Latentiepoort: Evalueert of de totale end-to-end latentie (deterministisch + stochastisch) binnen het control-loop budget past (100 ms reactief of 300 ms deliberatief).
Kostenpoort: Vergelijkt voor haalbare takken de Total Cost of Ownership (TCO) van cloud-offloading met de baseline van volledige hardware aan boord.

2.2. Belangrijke Modelleermodules

Offloading Strategieën: Drie strategieën zijn gedefinieerd op basis van het splitpunt in de pijplijn:
- S1 (Raw Sensor): Offload ruwe sensordata (hoge uplink, lage onboard compute).
- S2 (Feature-Level): Offload gecomprimeerde features na de vision backbone (gemiddelde uplink, gemiddelde onboard compute).
- S3 (Query-Level): Offload compacte scene queries na de transformer encoder (lage uplink, hoge onboard compute).
Communicatiemodel: Gebruikt een interferentie-bewust OFDMA uplink-model. Het berekent de spectrale efficiëntie per gebruiker op basis van celbelasting en multi-user interferentie om het maximale aantal actieve voertuigen ( $N_{max}$ ) te bepalen dat een cel kan ondersteunen voor een gegeven strategie en generatie (5G, 5G-Advanced, 6G).
GPU Service Model:
- Roofline Inferentie: Modelleert VLA-inferentietijd als een som van compute-bound (encoder/prefill) en memory-bandwidth-bound (autoregressieve decode) componenten.
- Wachtrij: Gebruikt een M/D/ $c$ wachtrij met Erlang-C tail bounds om te garanderen dat zeldzame langverwachtingsgebeurtenissen binnen het latentiebudget blijven.
- Hardware Evolutie: Projecteert GPU-prestaties (A100 $\to$ B300 $\to$ toekomstig) met een decellerende groeimodellering voor zowel compute throughput als HBM-bandbreedte.
Latentie Decompositie: Scheidt de control loop in deterministische componenten (sensing, encoding, inference, actuation) en stochastische componenten (netwerk scheduling, transmissie, routing, queueing). Haalbaarheid vereist dat de stochastische som binnen het resterende budget past met een tail probability $\le 10^{-5}$ .

2.3. Casestudy Parameters

Locatie: New York City (~2,2 miljoen geregistreerde voertuigen, ~10.000 zendmasten).
Variabelen: 3 communicatiegeneraties (5G, 5G-Adv, 6G), 3 modelklassen (E2E, VLM, VLA), 3 strategieën (S1, S2, S3), 8 penetratiegraden en 6 benuttingsniveaus.
Budgetten: 100 ms (reactieve controle) en 300 ms (deliberatieve planning, uitgaande van onboard fallback).

3. Belangrijkste Resultaten

3.1. Regime 1: Communicatie-beperkt (Dense Cells)

In dichtbevolkte stedelijke omgevingen is de uplink-capaciteit de primaire beperkende factor.

S1 (Raw Sensor): Vereist ~100 Mbps per voertuig. Zelfs met 6G is S1 onhaalbaar voor hoge penetratie/benutting in dichte cellen. 5G faalt vrijwel direct.
S2 (Feature-Level): Vereist ~25 Mbps. 5G ondersteunt slechts ~2% penetratie bij matige benutting. 5G-Advanced is de praktische drempel voor S2 in dichte corridors, waarbij tot ~30% penetratie wordt ondersteund. 6G biedt de noodzakelijke marge voor bredere uitrol.
S3 (Query-Level): Vereist ~3 Mbps. Wordt gemakkelijk ondersteund door 5G, maar laat aanzienlijke compute aan boord over, wat het economische voordeel van offloading vermindert.

3.2. Regime 2: Compute-beperkt (Reactieve Latentie)

Zelfs met voldoende bandbreedte worden nabije VLA-modellen geconfronteerd met een latentievloer door geheugenbandbreedte-beperkingen.

Memory-Bound Decode: Autoregressieve VLA-decoding wordt gedomineerd door HBM-bandbreedte (het lezen van gewichten voor elk token), niet door rekenkundige throughput. Op 2025-hardware (B300) is de deterministische inferentievloer voor VLA ~132–164 ms, wat het 100 ms reactieve budget overschrijdt.
Tijdlijn: De VLA deterministische vloer overschrijdt het 100 ms budget rond 2027.
- Reactief Budget (100 ms): VLA is latentie-onhaalbaar in 2026, ongeacht de bandbreedte. Tegen 2028 staat 6G feature-level VLA (S2) toe in dichte corridors; 5G-Advanced staat dit alleen toe onder lichte belasting.
- Deliberatief Budget (300 ms): VLA is haalbaar vanaf 2026, maar deze laag is alleen toelaatbaar als er een onboard reactieve fallback bestaat.

3.3. Regime 3: Kosten-beperkt (Economie)

Zodra de technische haalbaarheid is vastgesteld, bepaalt de benutting de economische omslag.

Benuttingseffect: Cloud-GPU's worden geprovisioneerd voor de actieve vraag, terwijl onboard hardware wordt betaald voor elk voertuig. Vloten met een lage-tot-matige benutting profiteren het meest van offloading.
Modelklasse Gevoeligheid:
- E2E: Onboard hardware is goedkoop (~$400/jaar); cloud-offloading biedt weinig kostenvoordeel.
- VLA: Onboard hardware is duur (~$8.500/jaar) en staat stil. Cloud-offloading wordt aanzienlijk goedkoper zodien de latentie-eisen zijn behaald.
Optimale Strategie: Feature-Level Offloading (S2) concentreert de VLA-kostenomslag. Het balanceert de uplink-vraag (haalbaar op 5G-Advanced/6G) met de resterende onboard compute (laag genoeg om offloading economisch rendabel te maken). S1 is te bandbreedte-intensief; S3 behoudt te veel onboard hardware.

4. Betekenis en Claims

Het artikel claimt dat het antwoord op de vraag "Kan de cloud besturen?" conditioneel en sequentieel is, afhankelijk van de modelklasse, het GPU-jaar en het latentiebudget.

Drie Geneste Regimes: Haalbaarheid is niet binair. Het wordt bepaald door een sequentie van beperkende factoren:
- Communicatie bindt eerst in dichte cellen (elimineert S1 en vereist 5G-Advanced/6G voor S2).
- Compute (Geheugenbandbreedte) bindt vervolgens voor VLA onder reactieve budgetten (maakt nabije VLA onhaalbaar ongeacht de netwerksnelheid).
- Kosten bindt als laatste, waarbij benutting bepaalt of de haalbare cloud-optie economisch superieur is aan de hardware aan boord.
De Rol van S2: Feature-level offloading wordt geïdentificeerd als het robuuste "middenpad". Het is de enige strategie die tegelijkertijd voldoet aan de communicatiebeperkingen in dichte cellen en voldoende hardwarebesparing behoudt om cloud-offloading economisch rendabel te maken voor dure VLA-modellen.
Beleidsimplicaties:
- Spectrum: Upstream-zware spectrumallocatie is cruciaal voor AV-corridors, wat het typische downlink-zware consumentenpatroon omkeert.
- Infrastructuur: Gedeelde edge-infrastructuur (co-investering) is noodzakelijk om de kosten van GPU's te amortiseren.
- Veiligheid: Certificering moet een onboard reactieve fallback verplichten (bijv. S3 of volledige lokale inferentie) voor elke architectuur die vertrouwt op cloud-deliberatieve planning, om een veilige degradatie tijdens netwerkstoringen te garanderen.
Beperkingen: De auteurs merken op dat de resultaten conservatief zijn, uitgaande van autoregressieve FP16-decoding. Toekomstige architecturale verschuivingen (bijv. diffusion decoders, speculative decoding, FP8) zouden de haalbaarheid van VLA kunnen versnellen. Daarnaast zijn 6G-parameters aspiratieve doelstellingen.

Concluderend toont het artikel aan dat cloud-rijden geen universele vervanging is voor compute aan boord, maar een levensvatbaar, kosteneffectief alternatief voor specifieke modelklassen (VLA) en benuttingsprofielen, mits de communicatie-infrastructuur (5G-Advanced/6G) en de evolutie van geheugenbandbreedte aansluiten bij de strikte latentie-eisen van reactieve controle.