⚡ electrical engineering

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

This paper presents an analytical framework demonstrating that while communication limits and hardware latency currently restrict cloud-based autonomous driving, future 6G networks and pooled GPU resources will eventually make feature-level offloading of large vision-language-action models both technically feasible and economically superior to onboard deployment.

Original authors: Pouya Parsa, Kawon Han, Seongjin Choi

Published 2026-07-13

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Pouya Parsa, Kawon Han, Seongjin Choi

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you're trying to drive a car that thinks for itself, but instead of having a super-brain inside the dashboard, you want to send all its thinking to a giant, shared brain in the cloud. It sounds like a sci-fi dream: why buy a $10,000 computer for every car when you can just rent a slice of a massive supercomputer?

But before we start dreaming about cloud-driven cars, we have to ask: Can the cloud actually drive?

A team of researchers decided to run the numbers, simulating a busy day in New York City to see if this idea could ever work. They didn't just guess; they built a complex model that checks three different "gates" a car has to pass through to get its brain in the cloud. Think of it like a three-level video game where you have to beat the first level to even see the second.

Level 1: The Data Highway (The Communication Gate)

First, imagine your car is a video game streamer. To send its "thoughts" to the cloud, it has to upload a huge video file. In a crowded city, thousands of cars are trying to upload at once.

The researchers found that if you try to send raw video from the cameras (Strategy S1), the internet highway gets jammed almost instantly. It's like trying to pour a swimming pool of water through a garden hose; the pipe just can't handle it. In their simulations, even with today's best 5G networks, a city like New York would choke if too many cars tried to send raw video.

However, there's a middle ground. If the car does a little bit of thinking first—compressing the video into "features" (Strategy S2)—it sends a much smaller package. The study suggests that with 5G-Advanced (a slightly newer version of 5G) or 6G, this compressed data might fit through the pipe, but only if the city isn't absolutely packed with cars. If you try to send the raw video (S1) or wait for the next generation of internet (6G) to handle everything, you're likely stuck in traffic. The paper explicitly rules out raw video offloading in dense cities with current tech.

Level 2: The Thinking Speed (The Compute Gate)

Let's say you beat Level 1 and the data got to the cloud. Now, the cloud has to think fast enough to tell the car how to steer.

Here's the twist: The cloud is fast, but not instantly fast. The researchers looked at the newest, smartest AI models (called VLA or Vision-Language-Action models). These models are like a genius who needs to read a whole book before answering a question.

The study found a hard wall: Memory bandwidth. Even if the cloud has the fastest computer chips in the world, the new VLA models have to "re-read" their memory for every single step of their thinking. It's like a chef who has to walk to the pantry to grab a spice for every single pinch they add to the soup.

In their simulations, this "walking to the pantry" takes about 114 milliseconds just for the thinking part. Add in the time to send the data back and forth, and the total time is over 100 milliseconds.

The Bad News: For a car to react instantly (like swerving to avoid a pedestrian), it needs a decision in 100 milliseconds. The paper suggests that for these super-smart VLA models, the cloud is simply too slow right now, no matter how fast your internet is. They won't be able to drive reactively until around 2027 or 2028, when computer memory gets faster.
The Loophole: If the car has a "backup brain" on board that handles emergencies in 100ms, the cloud can take over for slower, "deliberative" thinking (like planning a route) with a 300-millisecond budget. But the cloud can't be the only brain for immediate safety.

Level 3: The Price Tag (The Cost Gate)

Finally, let's say we fix the speed and the internet. Is it cheaper to rent the cloud brain than to buy one for every car?

This is where the magic happens. The researchers found that for the most expensive, complex AI models (VLA), the cloud is a huge money-saver. Why? Because a car sits parked 95% of the day. If you buy a $8,500 computer for every car, that computer sits idle most of the time. But in the cloud, one super-computer can serve thousands of cars that are actually driving at the same time.

The study suggests that once the speed and internet issues are solved, feature-level offloading (Strategy S2) is the sweet spot. It's the only strategy that saves enough money to beat the cost of buying hardware for every single car. If you try to send raw video (S1), the internet costs eat up the savings. If you keep too much computing in the car (S3), you don't save enough money.

The Big Picture

So, can the cloud drive? The answer isn't a simple "yes" or "no."

It's not a magic switch: You can't just plug a car into the cloud today. The internet in a crowded city would break, and the cloud is too slow for emergency reactions right now.
It's a waiting game: The paper suggests we need to wait for 6G (or very advanced 5G) for the internet, and faster computer memory for the speed.
It's a smart split: The best plan isn't to send everything to the cloud. The car should keep the "eyes" and "reflexes" local, and only send the "thinking" and "planning" to the cloud. This middle path (Strategy S2) is where the savings happen.

In short, the cloud might eventually drive our cars, but only if we build better roads for data, wait for faster memory chips, and keep a backup brain in the car just in case. Until then, the car's own brain is still the safest bet.

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

1. Problem Statement

The paper addresses the growing computational demands of frontier autonomous driving (AD) models, specifically Vision-Language-Action (VLA) architectures, which require forward passes approaching ~60 TFLOPs. While current automotive System-on-Chip (SoC) hardware can marginally support earlier End-to-End (E2E) or Vision-Language Model (VLM) workloads, deploying larger VLAs onboard is economically inefficient. Personal vehicles are parked ~95% of the time, meaning peak hardware sits idle most of the day.

The central question is whether cloud inference can replace onboard hardware by sharing expensive GPUs across active vehicles. However, this is not solely a compute problem; it is a coupled system challenge involving three distinct constraints that are rarely analyzed together:

Driving Model Split: Determining which pipeline stages (sensing, perception, planning, decoding) remain onboard versus offloaded.
Vehicular Communication: The capacity of the uplink to sustain continuous high-rate data streams from active vehicles to the cloud within a closed-loop deadline.
Cloud GPU Service: The ability of shared GPUs to serve bursty requests within strict latency budgets (reactive vs. deliberative) while managing queueing tails.

Existing literature often treats these systems in isolation. This paper argues that a unified framework is required to determine if cloud driving is technically feasible and economically viable.

2. Methodology

The authors propose a unified analytical framework applied to a dense urban case study (New York City). The framework integrates three systems into a sequential evaluation pipeline:

2.1. Analytical Pipeline

The pipeline evaluates scenarios through three nested "binding regimes":

Communication Gate: Determines if the access network can admit the required number of active vehicles given the uplink demand of a specific offloading strategy.
Latency Gate: Evaluates if the total end-to-end latency (deterministic + stochastic) fits within the control-loop budget (100 ms reactive or 300 ms deliberative).
Cost Gate: For feasible branches, compares the Total Cost of Ownership (TCO) of cloud offloading against the baseline of full onboard hardware.

2.2. Key Modeling Components

Offloading Strategies: Three strategies are defined based on the pipeline split point:
- S1 (Raw Sensor): Offloads raw sensor data (high uplink, low onboard compute).
- S2 (Feature-Level): Offloads compressed features after the vision backbone (moderate uplink, moderate onboard compute).
- S3 (Query-Level): Offloads compact scene queries after the transformer encoder (low uplink, high onboard compute).
Communication Model: Uses an interference-aware OFDMA uplink model. It calculates per-user spectral efficiency based on cell loading and multi-user interference to determine the maximum number of active vehicles ( $N_{max}$ ) a cell can support for a given strategy and generation (5G, 5G-Advanced, 6G).
GPU Service Model:
- Roofline Inference: Models VLA inference time as a sum of compute-bound (encoder/prefill) and memory-bandwidth-bound (autoregressive decode) components.
- Queueing: Uses an M/D/ $c$ queue with Erlang-C tail bounds to ensure rare long-wait events stay within the latency budget.
- Hardware Evolution: Projects GPU performance (A100 $\to$ B300 $\to$ future) using a decelerating growth model for both compute throughput and HBM bandwidth.
Latency Decomposition: Separates the control loop into deterministic components (sensing, encoding, inference, actuation) and stochastic components (network scheduling, transmission, routing, queueing). Feasibility requires the stochastic sum to fit within the remaining budget with a tail probability $\le 10^{-5}$ .

2.3. Case Study Parameters

Location: New York City (~2.2M registered vehicles, ~10,000 cell sites).
Variables: 3 communication generations (5G, 5G-Adv, 6G), 3 model classes (E2E, VLM, VLA), 3 strategies (S1, S2, S3), 8 penetration levels, and 6 utilization levels.
Budgets: 100 ms (reactive control) and 300 ms (deliberative planning, assuming onboard fallback).

3. Key Results

3.1. Regime 1: Communication-Bound (Dense Cells)

In dense urban environments, uplink capacity is the primary binding constraint.

S1 (Raw Sensor): Requires ~100 Mbps per vehicle. Even with 6G, S1 is infeasible for high penetration/utilization in dense cells. 5G fails almost immediately.
S2 (Feature-Level): Requires ~25 Mbps. 5G supports only ~2% penetration at moderate utilization. 5G-Advanced is the practical threshold for S2 in dense corridors, supporting up to ~30% penetration. 6G provides necessary headroom for broader deployment.
S3 (Query-Level): Requires ~3 Mbps. Easily supported by 5G, but leaves significant compute onboard, reducing the economic benefit of offloading.

3.2. Regime 2: Compute-Bound (Reactive Latency)

Even with sufficient bandwidth, near-term VLA models face a latency floor due to memory bandwidth constraints.

Memory-Bound Decode: Autoregressive VLA decoding is dominated by HBM bandwidth (reading weights for each token), not arithmetic throughput. On 2025 hardware (B300), the deterministic inference floor for VLA is ~132–164 ms, exceeding the 100 ms reactive budget.
Timeline: The VLA deterministic floor clears the 100 ms budget around 2027.
- Reactive Budget (100 ms): VLA is latency-infeasible in 2026 regardless of bandwidth. By 2028, 6G admits feature-level VLA (S2) in dense corridors; 5G-Advanced only admits it under light loading.
- Deliberative Budget (300 ms): VLA is feasible from 2026, but this tier is only admissible if an onboard reactive fallback exists.

3.3. Regime 3: Cost-Bound (Economics)

Once technical feasibility is established, utilization drives the economic crossover.

Utilization Effect: Cloud GPUs are provisioned for active demand, while onboard hardware is paid for every vehicle. Low-to-moderate utilization fleets gain the most from offloading.
Model Class Sensitivity:
- E2E: Onboard hardware is cheap (~$400/yr); cloud offloading offers little cost advantage.
- VLA: Onboard hardware is expensive (~$8,500/yr) and idle. Cloud offloading becomes significantly cheaper once latency constraints are met.
Optimal Strategy: Feature-Level Offloading (S2) concentrates the VLA cost crossover. It balances uplink demand (feasible on 5G-Advanced/6G) with residual onboard compute (low enough to make offloading worthwhile). S1 is too bandwidth-heavy; S3 retains too much onboard hardware.

4. Significance and Claims

The paper claims that the answer to "Can the cloud drive?" is conditional and sequential, depending on the model class, GPU year, and latency budget.

Three Nested Regimes: Feasibility is not binary. It is determined by a sequence of binding constraints:
- Communication binds first in dense cells (eliminating S1 and requiring 5G-Advanced/6G for S2).
- Compute (Memory Bandwidth) binds next for VLA under reactive budgets (making near-term VLA infeasible regardless of network speed).
- Cost binds last, where utilization determines if the feasible cloud option is economically superior to onboard hardware.
The Role of S2: Feature-level offloading is identified as the robust "middle ground." It is the only strategy that simultaneously satisfies communication constraints in dense cells and preserves sufficient hardware savings to make cloud offloading economically viable for expensive VLA models.
Policy Implications:
- Spectrum: Upstream-heavy spectrum allocation is critical for AV corridors, reversing the typical downlink-heavy consumer pattern.
- Infrastructure: Shared edge infrastructure (co-investment) is necessary to amortize GPU costs.
- Safety: Certification must mandate onboard reactive fallbacks (e.g., S3 or full local inference) for any architecture relying on cloud deliberative planning, ensuring graceful degradation during network outages.
Limitations: The authors note that the results are conservative, assuming autoregressive FP16 decoding. Future architectural shifts (e.g., diffusion decoders, speculative decoding, FP8) could accelerate VLA feasibility. Additionally, 6G parameters are aspirational targets.

In conclusion, the paper demonstrates that cloud driving is not a universal replacement for onboard compute but a viable, cost-effective alternative for specific model classes (VLA) and utilization profiles, provided that communication infrastructure (5G-Advanced/6G) and memory bandwidth evolution align with the strict latency requirements of reactive control.