A IA não é mais apenas um problema de GPU: a nova fronteira é a infraestrutura
De Kubernetes e GPU Scheduling a redes de 1,6 Tbps: por que DevOps, SRE e Networking estão convergindo na era da AI Infrastructure.
De Kubernetes e GPU Scheduling a redes de 1,6 Tbps: por que DevOps, SRE e Networking estão convergindo na era da AI Infrastructure
Durante os últimos anos, uma parcela significativa da discussão sobre infraestrutura para Inteligência Artificial (IA) concentrou-se na capacidade computacional dos aceleradores: maior quantidade de GPUs, mais memória disponível e arquiteturas capazes de executar modelos progressivamente maiores. Embora esses recursos permaneçam fundamentais, a evolução dos workloads de treinamento e inferência evidencia que o desempenho de uma plataforma de IA não pode ser analisado exclusivamente a partir da capacidade individual de seus aceleradores.
À medida que a IA avança da experimentação para ambientes distribuídos e serviços em produção, o desafio passa a envolver uma questão sistêmica: como manter recursos computacionais de alto custo ocupados, conectados, observáveis e disponíveis de forma eficiente? Nesse contexto, computação, redes, armazenamento, scheduling e observabilidade deixam de constituir domínios estritamente independentes e passam a integrar uma mesma arquitetura operacional.
AI INFRASTRUCTURE
|
+--------------+--------------+
| | |
COMPUTAÇÃO REDES OPERAÇÕES
GPU / DRA 800G/1.6T SRE / DevOps
Scheduling Rede óptica Observabilidade
| | |
+--------------+--------------+
|
Treinamento + Inferência
Kubernetes e a evolução do GPU Scheduling
O Kubernetes 1.37 constitui um exemplo relevante dessa transformação. O Dynamic Resource Allocation (DRA) continua evoluindo para oferecer mecanismos mais estruturados de descoberta, solicitação e alocação de GPUs e outros dispositivos especializados. Recursos como ResourceClaims, associados à evolução do scheduling orientado a workloads, ampliam a capacidade da plataforma de representar requisitos que ultrapassam o modelo tradicional baseado predominantemente em CPU e memória.
Para workloads de AI/ML distribuídos, essa mudança é particularmente relevante. A disponibilidade isolada de uma GPU nem sempre é suficiente para iniciar ou executar uma carga de trabalho de maneira eficiente. Dependendo da aplicação, torna-se necessário considerar a quantidade de aceleradores, sua localização na infraestrutura, as características dos dispositivos e a possibilidade de coordenar a execução de múltiplos componentes do workload.
Em termos simplificados, o processo deixa de responder apenas à pergunta:
"Existe uma GPU disponível?"
e passa a considerar uma cadeia mais ampla de requisitos:
GPU disponível?
|
Recursos adequados ao workload?
|
Topologia compatível?
|
Demais workers disponíveis?
|
Recursos podem ser coordenados?
|
A rede suporta a comunicação?
Nesse cenário, conceitos como workload-aware scheduling, gang scheduling e decisões sensíveis à topologia tornam-se relevantes para a execução de workloads distribuídos. O problema deixa de se limitar à alocação de capacidade computacional e passa a exigir a orquestração coordenada de recursos computacionais distribuídos.
Essa evolução também amplia a função operacional do Kubernetes. A plataforma deixa de atuar apenas como mecanismo de implantação e gerenciamento de containers e passa a participar diretamente da administração de recursos especializados que exercem impacto significativo sobre o desempenho, a disponibilidade e o custo da infraestrutura.
A rede como componente do sistema computacional
A expansão da capacidade computacional introduz outro requisito fundamental: a transferência eficiente de dados entre aceleradores, servidores, racks e clusters. Em arquiteturas distribuídas de IA, a comunicação entre esses elementos pode representar uma parcela significativa do tempo total de execução. Consequentemente, aumentar a capacidade de processamento sem ampliar proporcionalmente a capacidade da infraestrutura de comunicação pode apenas deslocar o gargalo, em vez de eliminá-lo.
Essa relação explica a crescente presença de tecnologias 400G, 800G e 1.6T Ethernet, bem como de novas soluções de redes ópticas, no desenvolvimento dos AI Data Centers. A Ethernet Alliance, por exemplo, anunciou para a ECOC 2026 demonstrações multi-vendor envolvendo 400G, 800G e 1.6T Ethernet, enquanto o desenvolvimento do IEEE P802.3dj contempla especificações relacionadas à Ethernet de 1.6 Tb/s.
De forma simplificada, a arquitetura pode ser representada como um sistema no qual os recursos computacionais e de rede são interdependentes:
GPU <======> REDE <======> GPU
| |
+------ Computação -------+
Distribuída
A rede, portanto, deixa de representar apenas o meio de transporte do tráfego entre servidores. Largura de banda, latência, congestionamento, topologia e capacidade das interconexões passam a influenciar diretamente a eficiência da computação distribuída.
Essa característica é especialmente relevante para workloads que exigem comunicação frequente entre diferentes aceleradores. Nesses casos, o desempenho observado pelo sistema resulta não apenas da capacidade de processamento individual de cada GPU, mas também da eficiência com que os dados são transferidos entre os elementos que participam da execução.
Sob essa perspectiva, a infraestrutura de rede passa a integrar diretamente a análise de desempenho da plataforma computacional.
Da capacidade de treinamento à inferência distribuída
Outra transformação relevante ocorre à medida que a IA deixa de estar concentrada predominantemente em treinamento e experimentação e passa a sustentar inferência em produção. Embora treinamento e inferência compartilhem parte da infraestrutura, seus requisitos operacionais podem apresentar diferenças significativas.
Ambientes de inferência precisam responder não apenas à demanda por capacidade computacional, mas também a requisitos relacionados a latência, disponibilidade, escalabilidade, isolamento, custo e proximidade entre recursos computacionais, aplicações e dados.
A CNCF tem destacado que a adoção de IA em produção aproxima esses workloads de problemas já conhecidos no ecossistema cloud native, incluindo scheduling, isolamento, redes, observabilidade e confiabilidade de sistemas distribuídos. Paralelamente, arquiteturas de inferência distribuída de IA procuram aproximar a execução dos modelos dos locais onde usuários, aplicações e dados estão presentes.
Essa mudança amplia a quantidade de variáveis que precisam ser observadas durante a operação:
IA em produção
|
+-------------+-------------+
| | |
Latência Custo Disponibilidade
| | |
+-------------+-------------+
|
Observabilidade
Nesse ambiente, não é suficiente determinar se o modelo está simplesmente respondendo às requisições. Torna-se necessário compreender quanto tempo a inferência levou, quais recursos foram utilizados, onde o workload foi executado, como a infraestrutura se comportou durante o processamento e qual foi o custo associado à entrega do serviço.
Essa necessidade amplia o papel da observabilidade. Métricas tradicionais de aplicações e infraestrutura continuam relevantes, porém precisam ser correlacionadas com informações relacionadas à utilização dos aceleradores, às filas de execução, ao comportamento do scheduler, à comunicação entre componentes e à eficiência global do workload.
Assim, AI Observability não representa necessariamente a substituição das práticas tradicionais de observabilidade, mas sua extensão para uma infraestrutura na qual recursos especializados, modelos e sistemas distribuídos precisam ser analisados de forma correlacionada.
Exemplo prático: arquitetura de uma plataforma de inferência distribuída
Considere uma organização que precisa disponibilizar um modelo de IA generativa para múltiplas aplicações corporativas. O requisito não consiste apenas em executar o modelo, mas em oferecer inferência com baixa latência, níveis de disponibilidade definidos por SLOs e utilização eficiente das GPUs.
Uma arquitetura conceitual poderia ser organizada da seguinte forma:
USUÁRIOS / APLICAÇÕES
|
API Gateway / LB
|
+---------+---------+
| |
Kubernetes Cluster Observability
| Metrics / Logs
Inference Gateway Traces / SLOs
|
+------+------+
| |
GPU Node GPU Node
+--------+ +--------+
| GPU 0 | | GPU 0 |
| GPU 1 | | GPU 1 |
| GPU 2 | | GPU 2 |
| GPU 3 | | GPU 3 |
+---+----+ +---+----+
| |
+------++------+
||
High-Speed Fabric
400G / 800G / 1.6T
||
+-------++-------+
| |
Model Storage Data Services
Object Storage Vector DB / Cache
Quando uma requisição chega ao API Gateway, ela é encaminhada à camada responsável pelo serviço de inferência. O Kubernetes precisa determinar onde o workload será executado, considerando a disponibilidade e as características dos recursos necessários. Em um cenário que utiliza dispositivos especializados, mecanismos associados ao DRA podem participar da seleção e da alocação desses recursos.
Entretanto, a decisão não termina na GPU. Se a execução exigir múltiplos aceleradores ou comunicação entre diferentes nodes, a topologia e a capacidade da rede passam a influenciar diretamente o desempenho. Um conjunto de GPUs disponível, porém conectado por caminhos congestionados ou inadequados ao padrão de comunicação do workload, pode apresentar eficiência inferior à esperada.
A camada de high-speed fabric passa, portanto, a integrar o caminho crítico da aplicação. Dependendo da escala e dos requisitos do ambiente, conexões 400G e 800G — e, progressivamente, implementações baseadas em 1.6T — podem compor a infraestrutura física utilizada para suportar o tráfego east-west entre os sistemas de computação.
Paralelamente, a plataforma de observabilidade precisa correlacionar diferentes níveis de telemetria:
Application
|
Inference latency / errors
|
Scheduler / queue time
|
GPU utilization / memory
|
Network latency / congestion
|
Infrastructure capacity
Essa correlação permite identificar situações nas quais o serviço permanece tecnicamente disponível, mas apresenta baixa eficiência operacional. Uma GPU com utilização reduzida, por exemplo, não indica necessariamente falta de demanda. A causa pode estar no scheduler, na espera por outros recursos, no acesso ao armazenamento, na comunicação entre nodes ou em limitações da rede.
O exemplo evidencia uma das principais características da AI Infrastructure: o desempenho percebido pela aplicação resulta do comportamento conjunto das diferentes camadas da infraestrutura. Otimizar isoladamente uma GPU, um switch ou um componente do Kubernetes não garante a otimização do sistema como um todo.
A convergência entre DevOps, SRE e Networking
A evolução descrita conduz a uma consequência importante para a engenharia de infraestrutura: áreas historicamente tratadas como especializações distintas passam a compartilhar um número crescente de dependências técnicas.
DevOps contribui com práticas de automação, Infrastructure as Code (IaC), CI/CD e gerenciamento de containers. SRE acrescenta disciplinas relacionadas à confiabilidade, observabilidade, planejamento de capacidade, gerenciamento de incidentes e Service Level Objectives (SLOs). Networking fornece os fundamentos necessários para compreender largura de banda, latência, topologia, congestionamento e conectividade óptica. O Kubernetes, por sua vez, atua como uma camada de orquestração que conecta parte dessas disciplinas por meio do gerenciamento de workloads e recursos.
DevOps ────────┐
|
SRE ───────────┼────> AI Infrastructure
|
Networking ────┤
|
Kubernetes ────┘
Essa convergência não implica que profissionais de DevOps, SRE ou Networking precisem necessariamente tornar-se especialistas no desenvolvimento de modelos de IA. O efeito mais relevante ocorre no domínio da infraestrutura: operar IA em escala exige compreender as interdependências entre computação, orquestração, redes e observabilidade.
Consequentemente, problemas que antes poderiam ser analisados de maneira relativamente isolada passam a exigir uma visão sistêmica. A baixa utilização de uma GPU, por exemplo, pode estar relacionada ao scheduling, à indisponibilidade de outros recursos, à topologia, à movimentação de dados ou a limitações da rede. Da mesma forma, uma degradação no desempenho da inferência pode exigir a correlação entre métricas da aplicação, comportamento do cluster, utilização dos aceleradores e condições da infraestrutura de comunicação.
A nova fronteira da AI Infrastructure
A GPU continuará ocupando uma posição central na computação acelerada. Entretanto, seu desempenho técnico, econômico e operacional dependerá cada vez mais da infraestrutura capaz de utilizá-la de maneira eficiente.
A próxima fronteira da IA, portanto, não consiste apenas no desenvolvimento de aceleradores mais rápidos. Ela envolve a construção de sistemas capazes de orquestrar recursos especializados, transportar dados em alta velocidade, observar o comportamento de workloads distribuídos e manter serviços confiáveis em produção.
É nessa interseção que DevOps, SRE, Cloud, Kubernetes e Networking passam a compor um domínio tecnológico cada vez mais relevante: AI Infrastructure.
Sob essa perspectiva, a evolução recente do Kubernetes, o avanço das redes Ethernet de 800G e 1.6T, o desenvolvimento das redes ópticas e a expansão da inferência distribuída não representam fenômenos independentes. São componentes de uma mesma transformação arquitetural: a IA está evoluindo de um problema predominantemente associado à capacidade computacional para um problema de engenharia de sistemas distribuídos em escala.
Referências
[1] Kubernetes Project. Kubernetes v1.37: Advancing Workload-Aware Scheduling. 8 set. 2026.
https://kubernetes.io/blog/2026/09/08/kubernetes-v1-37-advancing-workload-aware-scheduling/
[2] Kubernetes Project. Kubernetes v1.37: DRA Updates. 3 set. 2026.
https://kubernetes.io/blog/2026/09/03/kubernetes-v1-37-dra-updates/
[3] Kubernetes Project. Kubernetes v1.37: Garhwal. 26 ago. 2026.
https://kubernetes.io/blog/2026/08/26/kubernetes-v1-37-release/
[4] Ethernet Alliance. 1.6T Ethernet Moves Closer to Reality in Ethernet Alliance's ECOC 2026 Demo. 9 set. 2026.
https://ethernetalliance.org/blog/2026/09/09/1-6t-ethernet-moves-closer-to-reality-in-ethernet-alliances-ecoc-2026-demo/
[5] Ethernet Alliance. 2026 Ethernet Roadmap.
https://ethernetalliance.org/technology/ethernet-roadmap/
[6] Cloud Native Computing Foundation (CNCF) / SlashData. Cloud Native Momentum as AI Moves to Inference. 8 set. 2026.
https://www.cncf.io/announcements/2026/09/07/cncf-and-slashdata-report-highlights-chinas-cloud-native-momentum-as-ai-moves-to-inference/
[7] Equinix. Equinix Accelerates AI Inference for Enterprises with NVIDIA and Together AI. 2 set. 2026.
https://newsroom.equinix.com/2026-09-02-Equinix-Accelerates-AI-Inference-for-Enterprises-with-NVIDIA-and-Together-AI
#AIInfrastructure #Kubernetes #DevOps #SRE #Networking #CloudComputing #Observability #ArtificialIntelligence