Esta semana em cloud (14–20/set): a GPU já não é o gargalo — o caminho até ela é

TL;DR — A Equinix argumentou duas vezes que a internet pública deixou de sustentar IA em produção e que modernizar rede paga até 190% de ROI. A Oracle publicou o desenho de um caminho privado hub-and-spoke para mover dados entre nuvens. O BigQuery ganhou cache entre nuvens em preview. E o Cilium 1.20 transformou o CNI em camada de tráfego. Quatro organizações, um mesmo recado: a rota virou parte da arquitetura.

A semana passada foi sobre o tempo que se leva para voltar. Esta foi sobre o tempo que se leva para chegar.

Não houve um grande anúncio de rede. Houve seis textos, de quatro organizações, que chegaram por caminhos independentes à mesma conclusão: a conversa sobre desempenho de IA e de dados saiu do acelerador e foi parar no caminho até ele. A Equinix publicou duas peças, uma sobre o roteamento da internet pública degradando inferência em produção e outra sobre o retorno difícil de medir da modernização de rede. A Oracle documentou um desenho de conectividade privada para migrar grandes volumes entre nuvens. O Google colocou em preview um cache do BigQuery para dados que moram na AWS e no Azure. E o Cilium 1.20 saiu ampliando o Gateway API e fechando uma lacuna de IPv6 aberta havia quatro anos.

Quem opera infraestrutura conhece o sintoma: o modelo responde rápido no teste e devagar em produção, e ninguém consegue provar de quem é a culpa.

Por que a internet pública deixou de servir para IA em produção?

Porque ela nunca prometeu nada — e essa promessa vazia bastava enquanto IA era protótipo.

O argumento de Ted Kawka, no blog da Equinix, é mecânico e vale para além de IA: o roteamento da internet pública é dinâmico e best-effort, sem garantia de latência nem de perda de pacotes. O detalhe que muda a escala do problema é que, numa arquitetura moderna de inferência, uma única requisição do usuário costuma disparar dezenas de chamadas internas — busca vetorial, cache, banco operacional, APIs de ferramentas. Cada uma dessas chamadas herda a variabilidade do caminho, e a soma não é a média: é a cauda. Um p50 saudável convive com um p99 catastrófico quando o tráfego atravessa rotas que você não escolhe.

Há um segundo efeito, menos discutido, que é de custo. Retransmissão, reprocessamento e timeout com retry não aparecem como "problema de rede" na fatura — aparecem como mais instância, mais worker, mais tentativa. É a forma mais cara de comprar latência.

A peça seguinte, de Arun Dev, ataca o outro lado do mesmo problema: por que é tão difícil aprovar o investimento que resolveria isso. A tese é que o ROI de rede não mora numa linha de despesa. Ele está diluído em downtime evitado, latência que não aconteceu, egress que não foi cobrado e horas de engenharia que não foram gastas caçando um fantasma. O texto cita até 190% de ROI em modernização de rede — número da própria Equinix, e como todo número de fornecedor ele serve de ordem de grandeza, não de projeção. O que dá para levar do texto sem depender do fornecedor é o método: antes de desenhar a arquitetura nova, meça a atual — taxas de egress, latência média entre serviços, tempo de indisponibilidade e gargalos de pico.

A frase que resume as duas peças é dura e honesta: a internet pública foi suficiente para experimentar IA, não para operá-la.

O que a Oracle mostrou sobre desenhar o caminho privado?

Mostrou que "conexão dedicada" não é um produto que se compra — é um projeto de roteamento que se documenta.

O desenho publicado por Ejaz Akram e Ricardo Anda descreve a malha para migrar um grande volume de dados até o Oracle AI Database@AWS, usando regiões de exemplo em Londres e na Irlanda. A topologia empilha quatro peças: FastConnect como borda privada entre o data center e a nuvem, um hub VCN por região, DRGs transportando as rotas, uma Remote Peering Connection carregando o tráfego entre as duas regiões OCI e um Local Peering Gateway alcançando a rede da workload no destino.

O valor do padrão hub-and-spoke aqui é o de sempre, mas com uma consequência concreta: manter o trânsito entre regiões na camada de DRG evita criar dependência direta entre a borda on-premises e cada VCN de workload. Quando chegar a próxima migração — inclusive para outra nuvem —, ela se pendura no hub de destino sem redesenhar o FastConnect lá na ponta.

A parte mais reaproveitável do texto, no entanto, é a lista de regras de roteamento, que é basicamente princípio do menor privilégio aplicado a BGP:

Anuncie apenas os prefixos necessários para a migração e suas operações de apoio; nada de liberar faixas RFC1918 inteiras por padrão.
Separe o roteamento de migração, backup e administração — são janelas, riscos e donos diferentes.
Valide cada caminho de retorno. Não confie em roteamento transitivo presumido.
Retenha flow logs e logs de firewall durante todo o período da migração.

E há uma separação conceitual que merece virar regra de runbook: transporte e transferência são problemas distintos. A rede precisa sustentar a janela acordada; a ferramenta de cópia precisa ter checkpointing, verificação de integridade, retry, throttling e retomada. Nas palavras do próprio texto, "um circuito saudável não prova que uma cópia de dados foi concluída". É o mesmo raciocínio que, na semana passada, separava backup de restauração: infraestrutura verde não é evidência do resultado.

E quando o dado mora na nuvem do concorrente?

Aí a rede deixa de ser latência e vira fatura.

O Google colocou em preview o cross-cloud caching do BigQuery, junto com conexões cross-cloud para acessar dados abertos no Amazon S3 e no Azure Storage. O mecanismo é simples: na primeira consulta, o BigQuery busca o dado na nuvem de origem, responde e guarda uma cópia local; as consultas seguintes batem no cache. Para relatório diário, pipeline de BI e painel que roda no mesmo recorte todo dia, isso derruba latência e transferência ao mesmo tempo.

O movimento é estratégico e merece ser lido como tal: durante anos, a premissa foi centralizar o dado para poder analisá-lo. A proposta aqui é a inversa — deixar o dado onde ele está e mover só a computação e o cache. Para quem adota multi-cloud por redução de risco, e não por gosto, é um obstáculo econômico a menos.

Três ressalvas, que a própria análise do anúncio registra e que a experiência confirma:

Cache miss continua pagando. Consulta exploratória, que toca dado diferente toda vez, tem taxa de acerto baixa e economia proporcional.
Acesso entre nuvens não dispensa IAM. Criar cache em outro domínio de identidade é criar mais um lugar onde o dado sensível pode aparecer sem que a política tenha acompanhado.
Você acabou de adicionar uma dependência de rede entre concorrentes. Jitter e indisponibilidade do lado de lá passam a ser risco do seu relatório.

E, como o recurso está em preview, ele entra em prova de conceito — não em contrato com SLA.

Onde a rede apareceu nesta semana

Vale organizar os quatro movimentos por camada, porque eles não competem entre si: empilham.

Camada	O que a semana trouxe	De quem é a decisão	O que medir antes
Dentro do cluster	Cilium 1.20: Gateway API v1.6, ExternalAuth, CORS, TCPRoute/UDPRoute, netkit automático	Time de plataforma	Paridade de rotas, TLS e headers com o controller atual
Do data center até a nuvem	FastConnect com hubs DRG e RPC entre regiões (Oracle)	Rede e infraestrutura	Throughput sustentado na janela e cada caminho de retorno
Entre nuvens	Cross-cloud caching do BigQuery (preview)	Dados e FinOps	Taxa de acerto de cache e egress no miss
Até o usuário e a inferência	Interconexão privada versus internet pública (Equinix)	Arquitetura e negócio	Latência p95/p99 e jitter fim a fim, não a média

O Cilium 1.20 é o item mais concreto da tabela, e o mais fácil de adotar, porque para muita gente o CNI já está lá. O release salta do Gateway API v1.4 para o v1.6 e acrescenta ExternalAuth, filtros CORS, ListenerSets e as rotas TCPRoute e UDPRoute para tráfego que não é HTTP — ou seja, autenticação e autorização aplicadas antes de a requisição chegar à aplicação, pela mesma API que já governa o resto do tráfego norte-sul. Quem ainda depende do ingress-nginx arquivado ganhou mais um destino viável, assunto que destrinchamos no guia de migração para o Gateway API.

Três outras novidades do mesmo release importam para quem opera:

ENI IPAM com IPv6 na AWS entrou em beta, fechando uma lacuna cuja solicitação estava aberta havia quatro anos. O operator delega um prefixo /80 por ENI de nó, e os pods sobem dual-stack com IPv6 roteável na VPC. O suporte foi construído pelo pessoal da Datadog.
bpf.datapathMode=auto resolve um incômodo operacional real: cada agent sonda o próprio host no boot, usa netkit quando o kernel suporta e cai para veth quando não suporta. Frota com kernels misturados deixa de exigir pools separados de nós. Vale lembrar a escala do netkit: a Meta o implantou em milhões de containers e a ByteDance reportou cerca de 10% de ganho de desempenho nos próprios testes.
Datapath plugins (beta, construídos pelo Google) permitem que terceiros estendam o datapath eBPF sem fork e sem esperar release do Cilium, rodando em processo separado — uma falha no plugin não derruba o agent.

O fio que liga os três é o mesmo que o texto do release admite: o Cilium está deixando de ser um appliance de rede e virando um sistema operacional de rede, com um núcleo estável e extensões de terceiros por cima.

Não sabe se o seu p99 é modelo ou rota? A Nuvem Online mede o caminho fim a fim e desenha a conectividade antes de você comprar circuito.

O que isso significa para quem opera infra no Brasil?

Três consequências práticas, em ordem de urgência.

1. Meça antes de comprar — o número do fornecedor não é o seu. Os 190% de ROI são da Equinix, calculados sobre o portfólio de clientes dela. O seu número sai de quatro medições que já estão ao seu alcance: a fatura de egress aberta por serviço, a latência p95 e p99 entre os serviços que mais conversam, o jitter nos horários de pico e quantas horas de indisponibilidade do último ano tiveram causa de rede. Sem essa linha de base, qualquer proposta de interconexão é um diagrama bonito — e qualquer ganho depois da troca vira discussão de opinião. Uma stack de observabilidade própria resolve a coleta sem virar mais uma fatura, como mostramos no guia de observabilidade self-hosted com LGTM.

2. Para o Brasil, distância é arquitetura, não detalhe. A maior parte das empresas daqui consome inferência hospedada no hemisfério norte, e cada salto de ida e volta custa dezenas de milissegundos que nenhuma otimização de prompt recupera. A decisão prática não é "trocar de provedor", é escolher o que precisa estar perto: o cache semântico, o banco vetorial e o dado operacional podem ficar na região brasileira mesmo quando o modelo não pode. Vale a mesma lógica de soberania que a Equinix levantou em outra peça da semana — o dado que sai do país por uma rota pública sai igual, com ou sem discussão de jurisdição, e alguém vai perguntar por onde ele passou.

3. Menor privilégio vale para roteamento, e o IP de origem precisa sobreviver ao caminho. A lista da Oracle — anunciar só o prefixo necessário, separar migração de administração, validar cada retorno — é aplicável a qualquer nuvem e a qualquer VPN site-to-site. E há um detalhe que só aparece quando a rota é redesenhada: proxy empilhado sobre proxy na mesma camada destrói o endereço de origem. Quem está substituindo um ingress descontinuado descobre isso no pior momento, quando a regra de bloqueio por IP, o rate limit e o log de auditoria passam a enxergar o endereço do balanceador em vez do cliente. Terminar em balanceador L4, com o proxy fazendo o L7 uma única vez, resolve — e essa decisão precisa ser tomada no desenho, não no incidente. É o mesmo tipo de controle que se ganha ao operar a própria plataforma, como no caso de Kubernetes on-premises sem lock-in.

O que mais aconteceu na semana

Fora do fio da rede, cinco movimentos merecem nota:

O agente virou workload de infraestrutura, com números. O Google liberou o Agent Substrate como runtime open-source rodando em qualquer cluster Kubernetes e otimizado para GKE: densidade 10x maior que containers convencionais, retomada em menos de 500ms, mais de 500 ativações de suspensão/retomada por segundo, isolamento em microVM Cloud Hypervisor ou gVisor e proxies de egress que injetam credenciais fora do alcance do próprio agente. Do outro lado, a Oracle publicou um benchmark de 1.000 agentes persistentes no OKE com File Storage: 6.000 requisições sem nenhum retry, throughput de 18,4 requisições por segundo com 500 simultâneas e p99 de latência perto de 10 segundos na faixa de 50 a 100 simultâneas. A conclusão dos dois textos é a mesma — o gargalo do swarm é ciclo de vida de cluster e workspace persistente, não quantidade de GPU.
Segredo parou de virar cópia dentro do cluster. A Oracle documentou entrega de credenciais no OKE com workload identity, IAM e o Secrets Store CSI Driver: o valor é montado como arquivo read-only no pod, sem nunca virar um Kubernetes Secret, com política restrita por cluster, namespace, service account e objeto do vault. A letra miúda é a rotação — aplicação que não relê o arquivo não enxerga a nova versão. Na trilha open source, a CNCF publicou a receita de OpenBao com CloudNativePG: três instâncias PostgreSQL com replicação síncrona por quórum, autenticação por certificado via DatabaseRole e nenhuma senha na conexão.
Sessão virou política programável. O Google Cloud concluiu o rollout da duração padrão de 16 horas e promoveu os controles de sessão a recurso granular do Context-Aware Access, configurável por Terraform, gcloud e API, com segmentação por grupo e por aplicação. É reautenticação apertada onde o risco está, sem punir o time inteiro.
Segurança entrou no pre-submit com agente. O Google descreveu como escaneia cada mudança de código com agentes sobre o framework multiagente open-source Mantis, usando modelos de ameaça alimentados por metadados vivos do codebase e grafo de chamadas. O agente de triagem valida o caminho vulnerável com parsing de AST antes de incomodar alguém: mais de 92% de precisão em menos de um minuto, falso positivo em 3% dos casos, centenas de vulnerabilidades barradas por mês.
Compute e plataforma renderam. A AWS lançou as instâncias EC2 T8i, burstable com até 30% de melhor preço/desempenho que a geração T3, e reconstruiu o Elastic Beanstalk com um Cluster Mode sobre EKS, que roda várias aplicações num mesmo cluster gerenciado — barato à medida que o portfólio cresce, caro se forem duas aplicações pequenas pagando control plane. O Google levou a GA a família M4N, com o maior IOPS e throughput por core para workloads memory-bound, e ativou BM25 nativo no AlloyDB e no Cloud SQL para PostgreSQL 17+, dispensando um mecanismo externo de busca textual ao lado do vetorial.

Perguntas Frequentes

Interconexão privada faz sentido para uma empresa brasileira de porte médio, ou é só para quem tem escala global?
Faz sentido quando existe tráfego recorrente e previsível entre dois pontos que você controla — on-premises e nuvem, duas nuvens, ou colocation e provedor. O teste não é o tamanho da empresa, é o padrão do tráfego: transferência repetitiva e volumosa, ou latência que afeta receita. Antes de contratar circuito, levante quatro números do seu ambiente: a fatura de egress por serviço, a latência p95 e p99 entre os serviços que conversam mais, o jitter nos horários de pico e quantas horas de indisponibilidade no último ano tiveram causa de rede. Com egress baixo e tráfego eventual, otimizar arquitetura e cache resolve mais barato.

Como eu descubro se a rede é mesmo o gargalo da minha aplicação de IA?
Separando o tempo de inferência do tempo de trânsito. Instrumente a chamada fim a fim e compare o tempo que o modelo levou para responder com o tempo total que o usuário esperou; a diferença é rede, fila e serialização. O ponto que a Equinix levanta é que uma única requisição de inferência costuma disparar dezenas de chamadas internas — para banco vetorial, cache, APIs de ferramentas —, e cada uma herda a variabilidade do caminho. Se a média está boa e o p99 está péssimo, o suspeito é o caminho, não a GPU.

O cross-cloud caching do BigQuery acaba com o custo de egress entre nuvens?
Não. Ele reduz o custo nas consultas repetitivas, porque o dado já lido fica em cache local e não é buscado de novo na nuvem de origem. Mas todo cache miss continua atravessando a rede e continua sendo cobrado — inclusive na primeira execução de cada dataset novo. O recurso está em preview, então vale tratá-lo como otimização de padrão de acesso conhecido, não como eliminação de custo: se as suas consultas são exploratórias e tocam dados sempre diferentes, a taxa de acerto do cache será baixa e a economia também.

Se o Cilium agora faz Gateway API, ainda preciso planejar a saída do ingress-nginx?
Precisa, e o Cilium 1.20 é justamente um dos caminhos que ficaram mais fáceis. O release salta do Gateway API v1.4 para o v1.6 e acrescenta ExternalAuth, filtros CORS, ListenerSets e TCPRoute/UDPRoute para tráfego que não é HTTP. Isso significa que o CNI que já está no cluster passa a cobrir boa parte do que você resolvia com um controller de ingress separado, com autenticação aplicada antes de a requisição chegar à aplicação. A migração continua sendo um projeto com teste de paridade de rotas, TLS e headers — mas o destino agora tem mais recursos do que tinha há seis meses.

Fontes: