⚡ electrical engineering

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

Este artigo apresenta um arcabouço analítico demonstrando que, embora os limites de comunicação e a latência de hardware atualmente restrinjam a condução autônoma baseada em nuvem, as futuras redes 6G e os recursos de GPU agrupados eventualmente tornarão o offloading de modelos de visão-linguagem-ação de nível de característica tanto tecnicamente viável quanto economicamente superior à implantação embarcada.

Autores originais: Pouya Parsa, Kawon Han, Seongjin Choi

Publicado 2026-07-13

📖 6 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Pouya Parsa, Kawon Han, Seongjin Choi

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine que você está tentando dirigir um carro que pensa por conta própria, mas em vez de ter um supercérebro dentro do painel, você quer enviar todo o seu pensamento para um cérebro gigante e compartilhado na nuvem. Parece um sonho de ficção científica: por que comprar um computador de US$ 10.000 para cada carro se você pode apenas alugar uma fatia de um supercomputador massivo?

Mas antes de começarmos a sonhar com carros movidos pela nuvem, temos que perguntar: A nuvem consegue realmente dirigir?

Uma equipe de pesquisadores decidiu fazer as contas, simulando um dia movimentado na cidade de Nova York para ver se essa ideia poderia algum dia funcionar. Eles não apenas adivinharam; eles construíram um modelo complexo que verifica três "portões" diferentes pelos quais um carro tem que passar para levar seu cérebro para a nuvem. Pense nisso como um videogame de três níveis onde você tem que vencer o primeiro nível para sequer ver o segundo.

Nível 1: A Rodovia de Dados (O Portão de Comunicação)

Primeiro, imagine que seu carro é um streamer de videogame. Para enviar seus "pensamentos" para a nuvem, ele tem que fazer o upload de um arquivo de vídeo enorme. Em uma cidade lotada, milhares de carros estão tentando fazer o upload ao mesmo tempo.

Os pesquisadores descobriram que, se você tentar enviar vídeo bruto das câmeras (Estratégia S1), a rodovia da internet fica congestionada quase instantaneamente. É como tentar despejar uma piscina de água através de uma mangueira de jardim; o cano simplesmente não consegue suportar. Em suas simulações, mesmo com as melhores redes 5G de hoje, uma cidade como Nova York sufocaria se muitos carros tentassem enviar vídeo bruto.

No entanto, existe um meio-termo. Se o carro fizer um pouco de pensamento primeiro — comprimindo o vídeo em "características" (Estratégia S2) — ele envia um pacote muito menor. O estudo sugere que, com o 5G-Advanced (uma versão um pouco mais nova do 5G) ou 6G, esses dados comprimidos poderiam caber no cano, mas apenas se a cidade não estiver absolutamente lotada de carros. Se você tentar enviar o vídeo bruto (S1) ou esperar pela próxima geração de internet (6G) para lidar com tudo, provavelmente ficará preso no trâns-ito. O artigo descarta explicitamente o offloading de vídeo bruto em cidades densas com a tecnologia atual.

Nível 2: A Velocidade de Pensamento (O Portão de Computação)

Digamos que você vença o Nível 1 e os dados cheguem à nuvem. Agora, a nuvem tem que pensar rápido o suficiente para dizer ao carro como dirigir.

Aqui está a reviravolta: a nuvem é rápida, mas não instantaneamente rápida. Os pesquisadores analisaram os modelos de IA mais novos e inteligentes (chamados de modelos VLA ou Visão-Linguagem-Ação). Esses modelos são como um gênio que precisa ler um livro inteiro antes de responder a uma pergunta.

O estudo encontrou uma barreira intransponível: largura de banda de memória. Mesmo que a nuvem tenha os chips de computador mais rápidos do mundo, os novos modelos VLA precisam "reler" sua memória para cada passo de seu pensamento. É como um chef que tem que caminhar até a despensa para pegar um tempero para cada pitada que adiciona à sopa.

Em suas simulações, esse "caminhar até a despensa" leva cerca de 114 milissegundos apenas para a parte do pensamento. Adicione o tempo para enviar os dados de ida e volta, e o tempo total é superior a 100 milissegundos.

A Má Notícia: Para um carro reagir instantaneamente (como desviar de um pedestre), ele precisa de uma decisão em 100 milissegundos. O artigo sugere que, para esses modelos VLA superinteligentes, a nuvem é simplesmente lenta demais no momento, não importa quão rápida seja sua internet. Eles não serão capazes de dirigir de forma reativa até por volta de 2027 ou 2028, quando a memória do computador se tornar mais rápida.
A Brecha: Se o carro tiver um "cérebro de reserva" a bordo que lida com emergências em 100ms, a nuvem pode assumir o controle para pensamentos mais lentos e "deliberativos" (como planejar uma rota) com um orçamento de 300 milissegundos. Mas a nuvem não pode ser o único cérebro para segurança imediata.

Nível 3: O Preço (O Portão de Custo)

Finalmente, digamos que resolvamos a velocidade e a internet. É mais barato alugar o cérebro da nuvem do que comprar um para cada carro?

É aqui que a mágica acontece. Os pesquisadores descobriram que, para os modelos de IA mais caros e complexos (VLA), a nuvem é uma grande economia de dinheiro. Por quê? Porque um carro fica estacionado 95% do dia. Se você comprar um computador de US$ 8.500 para cada carro, esse computador ficará ocioso na maior parte do tempo. Mas na nuvem, um supercomputador pode atender a milhares de carros que estão dirigindo ao mesmo tempo.

O estudo sugere que, uma vez resolvidos os problemas de velocidade e internet, o offloading de nível de características (Estratégia S2) é o ponto ideal. É a única estratégia que economiza dinheiro o suficiente para superar o custo de comprar hardware para cada carro. Se você tentar enviar vídeo bruto (S1), os custos de internet consumirão as economias. Se você mantiver muita computação no carro (S3), não economizará o suficiente.

O Panorama Geral

Então, a nuvem consegue dirigir? A resposta não é um simples "sim" ou "não".

Não é um interruptor mágico: Você não pode simplesmente conectar um carro à nuvem hoje. A internet em uma cidade lotada quebraria, e a nuvem é lenta demais para reações de emergência no momento.
É um jogo de espera: O artigo sugere que precisamos esperar pelo 6G (ou um 5G muito avançado) para a internet, e por memórias de computador mais rápidas para a velocidade.
É uma divisão inteligente: O melhor plano não é enviar tudo para a nuvem. O carro deve manter os "olhos" e os "reflexos" locais, e apenas enviar o "pensamento" e o "planejamento" para a nuvem. Este caminho do meio (Estratégia S2) é onde ocorrem as economias.

Em resumo, a nuvem pode eventualmente dirigir nossos carros, mas apenas se construirmos melhores estradas para dados, esperarmos por chips de memória mais rápidos e mantivermos um cérebro de reserva no carro, por precaução. Até lá, o próprio céreio do carro ainda é a opção mais segura.

Resumo Técnico: A Nuvem Pode Dirigir? Viabilidade de Infraestrutura para o Descarregamento de Direção Autônoma via 5G e 6G

1. Definição do Problema

O artigo aborda as crescentes demandas computacionais dos modelos de fronteira da direção autônoma (AD), especificamente as arquitetções de Visão-Linguagem-Ação (VLA), que exigem passagens de forward aproximando-se de ~60 TFLOPs. Embora o hardware atual de System-on-Chip (SoC) automotivo possa suportar marginalmente cargas de trabalho anteriores de End-to-End (E2E) ou Modelos de Linguagem-Visão (VLM), a implantação de VLAs maiores a bordo é economicamente ineficiente. Veículos particulares ficam estacionados ~95% do tempo, o que significa que o hardware de pico permanece ocioso a maior parte do dia.

A questão central é se a inferência na nuvem pode substituir o hardware embarcado ao compartilhar GPUs caras entre veículos ativos. No entanto, este não é apenas um problema de computação; é um desafio de sistema acoplado que envolve três restrições distintas que raramente são analisadas em conjunto:

Divisão do Modelo de Direção: Determinar quais estágios do pipeline (sensoriamento, percepção, planejamento, decodificação) permanecem a bordo versus os que são descarregados (offloaded).
Comunicação Veicular: A capacidade do uplink para sustentar fluxos de dados contínuos de alta taxa de veículos ativos para a nuvem dentro de um prazo de ciclo fechado.
Serviço de GPU na Nuvem: A capacidade de GPUs compartilhadas servirem requisições intermitentes (bursty) dentro de orçamentos estritos de latência (reativos vs. deliberativos) enquanto gerenciam caudas de enfileiramento.

A literatura existente frequentemente trata esses sistemas isoladamente. Este artigo argumenta que um framework unificado é necessário para determinar se a direção via nuvem é tecnicamente viável e economicamente sustentável.

2. Metodologia

Os autores propõem um framework analítico unificado aplicado a um estudo de caso de área urbana densa (Cidade de Nova York). O framework integra três sistemas em um pipeline de avaliação sequencial:

2.1. Pipeline Analítico

O pipeline avalia cenários através de três "regimes de vinculação" aninhados:

Portão de Comunicação: Determina se a rede de acesso pode admitir o número necessário de veículos ativos dado o comando de uplink de uma estratégia de descarregamento específica.
Portão de Latência: Avalia se a latência total de ponta a ponta (determinística + estocástica) cabe no orçamento do ciclo de controle (100 ms reativo ou 300 ms deliberativo).
Portão de Custo: Para ramos viáveis, compara o Custo Total de Propriedade (TCO) do descarregamento na nuvem contra a linha de base do hardware totalmente embarcado.

2.2. Componentes de Modelagem Principais

Estratégias de Descarregamento: Três estratégias são definidas com base no ponto de divisão do pipeline:
- S1 (Sensor Bruto): Descarrega dados brutos de sensores (alto uplink, baixa computação a bordo).
- S2 (Nível de Características): Descarrega características comprimidas após o backbone de visão (moderado uplink, moderada computação a bordo).
- S3 (Nível de Query): Descarrega consultas de cena compactas após o codificador de transformer (baixo uplink, alta computação a bordo).
Modelo de Comunicação: Utiliza um modelo de uplink OFDMA consciente de interferência. Calcula a eficiência espectral por usuário com base no carregamento da célula e interferência multiusuário para determinar o número máximo de veículos ativos ( $N_{max}$ ) que uma célula pode suportar para uma determinada estratégia e geração (5G, 5G-Advanced, 6G).
Modelo de Serviço de GPU:
- Inferência Roofline: Modela o tempo de inferência VLA como uma soma de componentes limitados por computação (encoder/prefill) e limitados por largura de banda de memória (decodificação autorregressiva).
- Enfileiramento: Utiliza uma fila M/D/ $c$ com limites de cauda Erlang-C para garantir que eventos de espera longa e raros permaneçam dentro do orçamento de latência.
- Evolução de Hardware: Projeta o desempenho da GPU (A100 $\to$ B300 $\to$ futuro) usando um modelo de crescimento desacelerado tanto para o throughput de computação quanto para a largura de banda de HBM.
Decomposição de Latência: Separa o ciclo de controle em componentes determinísticos (sensoriamento, codificação, inferência, atuação) e componentes estocásticos (escalonamento de rede, transmissão, roteamento, enfileiramento). A viabilidade exige que a soma estocástica caiba dentro do orçamento restante com uma probabilidade de cauda $\le 10^{-5}$ .

2.3. Parâmetros do Estudo de Caso

Localização: Cidade de Nova York (~2,2 milhões de veículos registrados, ~10.000 sites de células).
Variáveis: 3 gerações de comunicação (5G, 5G-Adv, 6G), 3 classes de modelos (E2E, VLM, VLA), 3 estratégias (S1, S2, S3), 8 níveis de penetração e 6 níveis de utilização.
Orçamentos: 100 ms (controle reativo) e 300 ms (planejamento deliberativo, assumindo fallback embarcado).

3. Principais Resultados

3.1. Regime 1: Limitado pela Comunicação (Células Densas)

Em ambientes urbanos densos, a capacidade de uplink é a principal restrição limitante.

S1 (Sensor Bruto): Requer ~100 Mbps por veículo. Mesmo com 6G, o S1 é inviável para alta penetração/utilização em células densas. O 5G falha quase imediatamente.
S2 (Nível de Características): Requer ~25 Mbps. O 5G suporta apenas ~2% de penetração em utilização moderada. O 5G-Advanced é o limiar prático para o S2 em corredores densos, suportando até ~30% de penetração. O 6G fornece a folga necessária para uma implantação mais ampla.
S3 (Nível de Query): Requer ~3 Mbps. Facilmente suportado pelo 5G, mas deixa muita computação a bordo, reduzindo o benefício econômico do descarregamento.

3.2. Regime 2: Limitado pela Computação (Latência Reativa)

Mesmo com largura de banda suficiente, modelos VLA de curto prazo enfrentam um piso de latência devido às restrições de largura de banda de memória.

Decodificação Limitada por Memória: A decodificação autorregressiva de VLA é dominada pela largura de banda de HBM (leitura de pesos para cada token), não pelo throughput aritmético. Em hardware de 2025 (B300), o piso determinístico de inferência para VLA é de ~132–164 ms, excedendo o orçamento reativo de 100 ms.
Linha do Tempo: O piso determinístico do VLA ultrapassa o orçamento de 100 ms por volta de 2027.
- Orçamento Reativo (100 ms): O VLA é latência-inviável em 2026, independentemente da largura de banda. Até 2028, o 6G admite o VLA de nível de características (S2) em corredores densos; o 5G-Advanced apenas admite sob carga leve.
- Orçamento Deliberativo (300 ms): O VLA é viável a partir de 2026, mas este nível só é admissível se existir um fallback reativo embarcado.

3.3. Regime 3: Limitado pelo Custo (Economia)

Uma vez estabelecida a viabilidade técnica, a utilização impulsiona o cruzamento econômico.

Efeito da Utilização: As GPUs na nuvem são provisionadas para a demanda ativa, enquanto o hardware embarcado é pago por cada veículo. Frotas de baixa a moderada utilização ganham mais com o descarregamento.
Sensibilidade da Classe de Modelo:
- E2E: O hardware embarcado é barato (~$400/ano); o descarregamento na nuvem oferece pouco benefício de custo.
- VLA: O hardware embarcado é caro (~$8.500/ano) e ocioso. O descarregamento na nuvem torna-se significativamente mais barato uma vez que as restrições de latência são atendidas.
Estratégia Ótima: O Descarregamento de Nível de Características (S2) concentra o cruzamento de custo do VLA. Ele equilibra a demanda de uplink (viável em 5G-Advanced/6G) com a computação residual a bordo (baixa o suficiente para tornar o descarregamento economicamente vantajoso). O S1 é pesado demais para largura de banda; o S3 retém muito hardware embarcado.

4. Significância e Alegações

O artigo alega que a resposta para "A nuvem pode dirigir?" é condicional e sequencial, dependendo da classe de modelo, do ano da GPU e do orçamento de latência.

Três Regimes Aninhados: A viabilidade não é binária. Ela é determinada por uma sequência de restrições limitantes:
- A Comunicação limita primeiro em células densas (eliminando o S1 e exigindo 5G-Advanced/6G para o S2).
- A Computação (Largura de Banda de Memória) limita em seguida para o VLA sob orçamentos reativos (tornando o VLA de curto prazo inviável, independentemente da velocidade da rede).
- O Custo limita por último, onde a utilização determina se a opção viável na nuvem é economicamente superior ao hardware embarcado.
O Papel do S2: O descarregamento de nível de características é identificado como o "meio termo" robusto. É a única estratégia que satisfaz simultaneamente as restrições de comunicação em células densas e preserva economia de hardware suficiente para tornar o descarregamento na nuvem economicamente viável para modelos VLA caros.
Implicações de Política:
- Espectro: A alocação de espectro pesada em uplink é crítica para corredores de AV, revertendo o padrão típico de consumo focado em downlink.
- Infraestrutura: Infraestrutura de borda compartilhada (co-investimento) é necessária para amortizar os custos de GPU.
- Segurança: A certificação deve exigir fallbacks reativos embarcados (ex: S3 ou inferência total local) para qualquer arquitetura que dependa de planejamento deliberativo na nuvem, garantindo a degradação suave durante interrupções de rede.
Limitações: Os autores observam que os resultados são conservadores, assumindo decodificação autorregressiva FP16. Mudanças arquiteturais futuras (ex: decodificadores de difusão, decodificação especulativa, FP8) poderiam acelerar a viabilidade do VLA. Adicionalmente, os parâmetros do 6G são alvos aspiracionais.

Em conclusão, o artigo demonstra que a direção via nuvem não é um substituto universal para a computação embarcada, mas uma alternativa viável e econômica para classes de modelos específicas (VLA) e perfis de utilização, desde que a infraestrutura de comunicação (5G-Advanced/6G) e a evolução da largura de banda de memória estejam alinhadas com os rigorosos requisitos de latência para o controle reativo.