Interactive research article

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

When can autonomous-driving inference move from every vehicle to shared edge-cloud infrastructure?

Pouya Parsa, Kawon Han, and Seongjin Choi

University of Minnesota Twin Cities

Preprint July 2026 arXiv:2607.09045

Paper ↗ Interactive simulator Portfolio
Flowchart linking communication, compute latency, joint feasibility, infrastructure optimization, and cost crossover.

The paper evaluates communication, compute latency, and cost in sequence before declaring an offloading branch viable.

3
feasibility gates
1,296
scenarios
10
official figures
5G–6G
5G through 6G
The short answer

Can the cloud run an autonomous-driving model?

Yes—but the system must pass three tests in order. First, the network must upload the vehicle’s data. Next, the cloud GPU must return a result within the driving deadline. Only then does it make sense to ask whether shared cloud hardware costs less than a computer in every vehicle.

The result in one sequence

Cloud driving must pass three tests.

The paper tests the network first, GPU response time second, and cost last. If a scenario fails one test, the later tests cannot rescue it.

Gate 01 Communication

Can the network upload the data?

Not always. Cloud driving sends data upstream from every active vehicle. Raw sensors need 100 Mbps per vehicle, compressed features need 25 Mbps, and compact queries need 3 Mbps.

At the dense NYC reference point, plain 5G cannot support feature-level offloading. 5G-Advanced is the practical threshold, and 6G adds room for more vehicles.

See the NYC network result →

Gate 02 Compute time

Can the GPU respond in time?

Not for near-term VLA under the 100 ms deadline. The decoder reads large model weights from GPU memory once for every generated step. That repeated reading takes longer than the arithmetic.

In 2025, the deterministic VLA floor is 132–164 ms before network or queueing delay. Faster 5G or 6G cannot remove this GPU memory delay.

See why VLA waits on memory →

Gate 03 Cost

Is the cloud cheaper?

For some VLA fleets—after the first two tests pass. A computer bought for every vehicle sits idle while the vehicle is parked. Shared cloud GPUs serve only the vehicles that are active.

The cloud advantage is strongest for expensive VLA hardware at low or moderate utilization. Feature-level offloading, or S2, is where most of the VLA savings appear.

See where cloud VLA costs less →

Why VLA compute is slow

VLA waits on memory, not just math.

The paper’s Roofline model separates the time a GPU spends doing arithmetic from the time it spends moving model weights through memory.

The memory reads dominate. A vision-language-action (VLA) model connects visual perception, language reasoning, and driving actions in one large model.

The encoder and prefill stages mainly use the GPU’s arithmetic units. The autoregressive decoder works differently: it produces reasoning and trajectory outputs one step at a time.

The VLA decoder generates an action one step at a time. At every step, the GPU must read the model weights from high-bandwidth memory again.

VLA latency by GPU year and a breakdown showing that autoregressive decoding is limited by GPU memory bandwidth. Figure 8: The left panel shows when each model fits the deadline. The right panel shows why VLA decoding improves with memory bandwidth, not just more arithmetic throughput.
39 ms
Do the mathEncoder and prefill in a compute-only estimate.
+114 ms
Read the weightsAutoregressive reasoning and trajectory decoding.
153 ms
Cloud inferenceThe memory-aware total before the rest of the driving loop.

Scope: This is the paper’s 2025 B300 raw-sensor offloading example for its calibrated FP16, dense, single-request autoregressive VLA stack. It is not a universal VLA benchmark.

Across S1–S3, the complete deterministic VLA floor is 132–164 ms in 2025. It first falls below 100 ms around 2027, but that floor is only a lower bound: network and queueing delays still have to fit. At the dense NYC reference point, 6G admits VLA-S2 around 2028; 5G-Advanced does not pass the same 100 ms case.

Interactive model

Test a cloud-driving scenario.

Choose values from the paper’s 1,296-branch scenario grid. Results are analytical estimates from arXiv:2607.09045v1—not production safety guidance.

Choose a published scenario

Start with a paper scenario

Feature-level VLA offloading is compute-bound in dense 5G-Advanced.

* The 300 ms deliberative tier requires an onboard controller that still closes the 100 ms reactive loop.

Reference scenario

Compute is the first binding gate.

VLA · S2 · 5G-Advanced · 10% penetration · 45% utilization · 2028

  1. 01

    Communication

    Pass 9.9 active vehicles/cell; 25 Mbps target uplink.
  2. 02

    Compute + tail latency

    Does not pass The deterministic floor clears 100 ms, but the loaded 5G-Advanced scheduling tail does not.
  3. 03

    Cost

    Not evaluated Cost is withheld until communication and latency both pass.

Analytical estimate based on the paper’s NYC fleet, cell-count, hardware-evolution, and cost assumptions.

Where should the pipeline split?

Choose where the model splits.

S1 Raw sensor

Upload the raw sensors

100 Mbps

Uploads camera, LiDAR, and radar streams. It leaves only encoding onboard, but dense cells reach the communication cliff early.

S2 Feature level

Upload compressed features

25 Mbps

Keeps the vision backbone local and offloads compressed features. This is where VLA feasibility and the cost crossover concentrate.

S3 Query level

Upload compact queries

3 Mbps

Uploads compact scene queries after the transformer encoder. It is easiest on the network but preserves much of the vehicle hardware cost.

Published strategy inputs by model class
Strategy Experimental uplink Residual TOPS: E2E / VLM / VLA Cloud TFLOPs: E2E / VLM / VLA
S1100 Mbps5 / 5 / 51.7 / 24.7 / 60.0
S225 Mbps16 / 226 / 5501.39 / 20.17 / 49.0
S33 Mbps82 / 1194 / 29000.06 / 0.82 / 2.0

The complete visual evidence

See the evidence from the paper.

Every chart and diagram below comes from the official arXiv source. Captions preserve the paper’s conditions; the added note explains the role each figure plays in the argument.

Showing all 10 figures.

Flowchart linking the communication gate, GPU service and latency models, joint feasibility, infrastructure optimization, and cost crossover.
Figure 1: Analytical pipeline. The Communication Requirements Model defines the communication-side limit, and the GPU Service Model defines the cloud-side service model used by the Stochastic Latency Model. Those results then feed the Feasibility Threshold; feasible branches proceed to edge infrastructure optimization and are finally compared through the Total Cost of Ownership and Crossover step.

Why it matters: Cost matters only after communication and latency pass.

Four pipeline rows show S1, S2, S3, and the onboard baseline, with progressively more processing kept inside the vehicle.
Figure 2: Offloading strategy spectrum.

Why it matters: Moving more work into the vehicle reduces uplink demand but requires more onboard hardware.

Log-scale chart where rising S1, S2, and S3 aggregate uplink demand intersects declining per-user capacity for 5G, 5G-Advanced, and 6G.
Figure 3: Bandwidth-capacity tradeoff. Colored lines show the required uplink demand for S1–S3 as vehicles per cell increase, while gray generation curves show the available uplink capacity under the interference-aware cell model. Intersections mark the maximum bandwidth-feasible vehicles per cell.

Why it matters: A cell has a hard vehicle limit because demand rises while shared capacity falls.

Vehicle, network, and cloud layers show deterministic sensing, encoding, inference, and actuation beside stochastic scheduling, routing, queueing, uplink, and downlink delay.
Figure 4: End-to-end control loop delay decomposition. Solid borders denote deterministic components; dashed borders denote stochastic components that consume the remaining latency slack.

Why it matters: GPU inference is only one part of the full driving loop.

Tail latency curves for S1, S2, and S3 stay low before rising sharply through the 100 millisecond and 300 millisecond budgets as vehicles per cell increase.
Figure 5: Tail latency under increasing cell utilization. Curves show the 99.999th-percentile end-to-end loop delay under 5G-Advanced (compact E2E workload) as vehicles per cell increase for S1–S3. Horizontal lines mark the reactive 100 ms and deliberative 300 ms budgets. The sharp rise at high loading is the capacity cliff discussed in the text: stochastic network scheduling consumes the remaining budget Δ, so points above a budget fail the latency side of the feasibility screen.

Why it matters: A scenario can pass on average and still fail during a rare delay spike.

Three panels compare maximum feasible New York City AV penetration by utilization for S1, S2, and S3 under 5G, 5G-Advanced, and 6G.
Figure 6: Case Study 1: NYC communication frontier. The y-axis gives the maximum citywide fleet penetration that remains bandwidth-feasible at each utilization. Reference points: 1% = 22K vehicles, 10% = 220K vehicles.

Why it matters: The number of active vehicles—not just the total fleet—sets network load.

Three colored grids show the minimum communication generation needed for each penetration and utilization combination under S1, S2, and S3.
Figure 7: Case Study 1: NYC communication sweep. Each cell shows the minimum communication generation required to keep a strategy bandwidth-feasible for the given AV penetration and utilization pair. The highlighted cell corresponds to the reference point of 10% penetration and u = 0.45.

Why it matters: S2 cuts network demand without keeping most of the expensive VLA model in the vehicle.

The left panel shows VLA deterministic latency dropping below 100 milliseconds after 2026; the right panel shows memory-bandwidth-bound decode dominating the VLA-S2 floor.
Figure 8: Regime 2 (compute-bound). (a) Deterministic latency floor versus GPU year for VLA (S1–S3), with VLM-S2 and E2E-S2 references; the reactive 100 ms and deliberative 300 ms budgets are marked. The VLA floor first drops below 100 ms in 2027, but this is a lower bound: once the access-scheduling tail is added, reactive admissibility is later and generation-dependent. (b) Decomposition of the VLA-S2 floor: the decode term is HBM-bandwidth-bound and dominates the wall, so it shrinks only with memory bandwidth, not arithmetic throughput.

Why it matters: Faster 6G cannot speed up repeated reads from GPU memory.

A nine-panel cost chart compares onboard and S1, S2, and S3 annual costs across E2E, VLM, VLA and three utilization levels, with infeasible segments dashed.
Figure 9: Regime 3 (cost-bound), reactive budget. NYC per-vehicle hybrid cost versus the in-vehicle baseline over time at 5G-Advanced. Rows: model classes. Columns: utilization. Solid curves are latency-feasible under the 100 ms budget; dashed segments are latency-infeasible. VLA cloud (S2) falls below the $8,500 baseline once it clears the compute regime.

Why it matters: Shared GPUs help most when expensive VLA hardware would otherwise sit idle.

Three cost-ratio heatmaps show the cheapest feasible strategy across penetration and utilization; green VLA cells are widespread and mostly labeled S2.
Figure 10: Regime 3 (cost-bound), deliberative tier in 2028, where VLA is latency-admissible. Cheapest feasible NYC cloud cost divided by the in-vehicle baseline; cell text gives the cheapest feasible strategy and gray cells are infeasible. Green marks cloud-cheaper cells. For VLA the cost-attractive region is large and dominated by S2.

Why it matters: S2 is often the lowest-cost VLA option after the latency tests pass.

What the figures add up to

Five takeaways.

  1. 01
    The tests happen in order.

    The network passes first, GPU response time passes second, and cost comes last.

  2. 02
    5G-Advanced is the first practical step for S2.

    Plain 5G runs out of feature-upload capacity at the dense NYC reference point.

  3. 03
    VLA waits on GPU memory.

    Autoregressive decoding repeatedly reads model weights from HBM and dominates the 2025 compute time.

  4. 04
    Low utilization makes sharing more valuable.

    Cloud pooling avoids buying peak VLA hardware for every parked vehicle.

  5. 05
    S2 is the middle ground.

    It needs less uplink than S1 and less onboard compute than S3.

Go to the source

Read and cite the paper.

The preprint contains the complete analytical framework, equations, parameter tables, literature review, and policy discussion.

Download the PDF ↗ Open the abstract ↗

BibTeX

@article{parsa2026cloud,
  title={Can the Cloud Drive? Infrastructure Feasibility of Offloading Autonomous Driving Across 5G and 6G},
  author={Parsa, Pouya and Han, Kawon and Choi, Seongjin},
  journal={arXiv preprint arXiv:2607.09045},
  year={2026}
}