A velocidade de uma IA não depende apenas de escolher entre CPU e GPU. Em muitos fluxos, a pergunta decisiva é outra: quantos metros os dados precisam percorrer antes de voltar com uma resposta? A latência da rede impõe um limite físico, enquanto a memória dentro do chip define outro. Quando esses atrasos se somam, um processador local, mesmo menos especializado, pode vencer um acelerador muito mais potente instalado longe dali.

Isso já acontece como princípio de engenharia consolidado. Dados atravessam cabos, roteadores, comutadores e memórias. Cada etapa acrescenta espera. A nuvem não elimina a distância. Ela apenas esconde a distância atrás de uma interface simples.

O primeiro gargalo está dentro do processador

A inferência de um modelo de linguagem parece uma tarefa de cálculo, mas grande parte do trabalho é movimentar parâmetros. Para produzir o próximo token, o sistema precisa consultar enormes blocos de memória e aplicar operações matemáticas em sequência. O resultado volta a ser usado para gerar o token seguinte.

Esse padrão é diferente de um processamento com lotes grandes e independentes. Cada usuário espera sua própria resposta, e a geração acontece passo a passo. Por isso, o problema não é somente ter mais unidades de cálculo. É manter dados disponíveis no lugar certo, no momento certo.

A hierarquia de memória existe para resolver esse problema. Registradores e caches ficam muito perto da lógica de processamento. Memórias maiores ficam mais distantes. A memória principal fica mais longe ainda. Cada camada oferece um compromisso entre capacidade, custo e tempo de acesso.

Uma conta simples mostra o efeito da repetição. Suponha que uma aplicação faça oito rodadas de inferência e que cada rodada leve 2 segundos. Só essa parte soma 16 segundos. Se cada rodada ainda fizer uma chamada de rede de 300 milissegundos, o tráfego acrescenta 2,4 segundos. O usuário espera cerca de 18,4 segundos antes de considerar o fluxo concluído. A rede não ficou mais lenta. Ela apenas foi chamada muitas vezes.

Resultados publicados para uma arquitetura específica indicam 1,25 milissegundo por token em um modelo OPT de 1,3 bilhão de parâmetros e 20,9 milissegundos por token em um modelo OPT de 66 bilhões, em configurações específicas. Esses números demonstram uma direção técnica, não uma promessa geral para qualquer modelo ou aplicação.

O segundo gargalo está no mapa

Mesmo que a inferência seja eficiente, o sistema ainda precisa conversar com o mundo. Um pedido pode começar em um dispositivo, passar por uma rede, chegar a um centro de dados, consultar uma base de dados e retornar por outro caminho. A resposta final sofre com a soma de todas essas esperas.

A velocidade da luz não é infinita. Em uma fibra óptica, o sinal percorre a infraestrutura a uma velocidade menor que a do vácuo. Rotas reais também não são linhas retas. Há curvas, equipamentos intermediários e filas. Assim, reduzir a distância costuma ser mais eficaz do que simplesmente contratar uma conexão com maior capacidade.

Considere duas redes com 100 megabits por segundo. Se uma tiver tempo de ida e volta de 50 milissegundos e outra de 20 milissegundos, a segunda confirma dados mais rapidamente. Isso reduz a espera entre blocos enviados e recebidos e permite aproveitar melhor a capacidade disponível. Largura de banda é o tamanho da estrada. Latência é o tempo até uma resposta voltar. A estrada maior não resolve uma viagem longa.

O efeito cresce em sistemas distribuídos. Uma aplicação pode parecer rápida na primeira chamada, mas ficar lenta quando encadeia recuperação de documentos, autorização, consulta a dados e múltiplas inferências. Cada dependência acrescenta um novo trecho ao percurso.

Quando a CPU local ganha da GPU distante

A comparação correta não é entre uma CPU fraca e uma GPU forte. É entre dois caminhos completos.

Como hipótese de engenharia, uma CPU local pode processar um fluxo localmente. No segundo caminho, uma GPU remota oferece mais capacidade de cálculo, mas exige enviar o contexto pela rede, aguardar a inferência e receber o resultado. A GPU remota pode compensar a latência quando o ganho de processamento superar o custo da comunicação. Em tarefas pequenas e encadeadas, a comunicação pode se tornar dominante.

Imagine um agente que lê um evento, consulta uma política, verifica um registro e decide o próximo passo. Se cada decisão depende da anterior, não há como esconder toda a latência com paralelismo. Suponha quatro chamadas de rede de 300 milissegundos e cinco rodadas de inferência de 1 segundo. O fluxo acumula 1,2 segundo de rede e 5 segundos de inferência, totalizando 6,2 segundos, antes de contar serialização, filas e processamento local. Uma máquina local que reduza as chamadas remotas pode vencer mesmo entregando menos operações por segundo.

Isso já é especialmente relevante para operações remotas habilitadas por vídeo, aplicações baseadas em sensores e aplicações interativas. Nesses casos, redes de baixa latência são cruciais para evitar atrasos que comprometem o funcionamento do sistema.

A nuvem continua sendo o caminho mais provável para tarefas que precisam de modelos enormes, treinamento centralizado ou muita capacidade compartilhada. Como hipótese, a computação local pode ser vantajosa quando o fluxo é sensível ao tempo ou quando os dados precisam permanecer no ambiente de origem.

Uma possibilidade é o avanço de arquiteturas híbridas

Uma hipótese de projeto é dividir o trabalho entre nuvem e borda, em vez de concentrá-lo em um único local.

Uma arquitetura local poderia filtrar eventos e responder a casos simples; funções de continuidade durante falhas exigem validação específica. O sistema remoto poderia cuidar de análises pesadas, atualização de modelos e tarefas que toleram espera. O desafio passa a ser decidir o que merece viajar.

Essa escolha também muda o desenho dos produtos. Em vez de perguntar qual modelo tem a melhor resposta, será necessário medir o tempo até o primeiro resultado, o tempo entre tokens, a quantidade de chamadas e a distância entre componentes. O modelo mais inteligente pode ser a pior opção se o fluxo o convoca repetidamente através de uma rede lenta.

Aqui há uma hipótese em teste: mais etapas por tarefa podem aumentar a importância da topologia física da infraestrutura. Não é uma previsão com data marcada. É uma consequência possível da aritmética: mais etapas significam mais oportunidades para a latência aparecer.

Especulação: produtos poderiam escolher automaticamente entre processamento local e remoto a cada etapa, considerando urgência, tamanho do contexto, custo e privacidade. Isso sugeriria tratar o modelo como parte de uma geografia computacional.

O teste que evita decisões ruins

Antes de escolher hardware ou arquitetura, desenhe o caminho de uma requisição. Marque onde o dado nasce, onde cada inferência acontece, quantas vezes os componentes conversam e quanto contexto atravessa a rede. Depois, some os tempos com premissas explícitas.

Se a maior parte do atraso está no acesso à memória, aproximar dados e processamento ajuda. Se está nas chamadas entre locais distantes, trocar uma CPU por uma GPU pode não mudar o resultado. Se o fluxo contém muitas etapas pequenas, reduzir viagens costuma valer mais do que aumentar a potência de uma máquina remota.

A abstração de nuvem pode ocultar parte da localização física para quem desenvolve aplicações. A física não desapareceu. Ela apenas ficou escondida até o momento em que a aplicação precisa responder rápido.