Resumo

  • A pilha de rede da CoreWeave é uma arquitetura operacional que abrange scale-up, scale-out, armazenamento, tenants, gerenciamento, backbone e conexões dedicadas; não é um produto independente.
  • Combina o fabric e os DPUs da NVIDIA com o software da CoreWeave para alocar aceleradores, isolar tenants e mover dados dentro da nuvem dedicada.
  • A CoreWeave reporta 43 data centers, mais de 850 MW de potência operacional, cerca de 3,1 GW de potência contratada, com a Microsoft representando 67% da receita de 2025. Escala e concentração aparecem juntas.
  • O teste é se a empresa consegue converter potência contratada e backlog em serviços confiáveis e distribuídos antes que custos de financiamento, arrendamentos, obsolescência de equipamentos e complexidade operacional se acumulem.

A instalação física cresceu mais rápido do que mostram os diagramas comuns de regiões de nuvem

Em 31 de dezembro de 2025, a CoreWeave reportou 43 data centers, mais de 850 MW de capacidade operacional e cerca de 3,1 GW de potência contratada. O valor operacional reflete a infraestrutura que estava em funcionamento conforme definição da empresa nessa data. O valor contratado representa direitos e obrigações para implantações futuras e não deve ser expresso como capacidade instalada.

O avanço foi rápido. No final de 2023, eram 10 data centers e cerca de 70 MW; no final de 2024, 32 data centers e mais de 360 MW; e no final de 2025, 43 data centers e mais de 850 MW em operação. No primeiro trimestre de 2026, a CoreWeave relatou mais de 1 GW em operação e mais de 3,5 GW contratados. Os números revelam uma empresa que busca expandir instalações e operações em ritmo industrial. Ao mesmo tempo, mostram a rapidez com que a arquitetura de ontem se torna minoria na frota.

A energia é um pré-requisito, não um produto acabado. Cada MW contratado ainda exige conexão à rede, suprimento de geração ou rede, distribuição elétrica de alta densidade, resfriamento, preparação predial, rotas de rede, entrega de aceleradores e aceitação operacional. Um atraso em qualquer uma dessas camadas adia a receita, enquanto algumas obrigações podem começar antes.

O modelo de data center é misto. A CoreWeave é proprietária dos equipamentos e gerencia implantações em larga escala, mas também utiliza instalações alugadas e operadores terceirizados. Isso acelera a expansão geográfica e reduz a necessidade de construir todos os prédios, mas torna o desempenho do locador, os cronogramas de obras, o fornecimento de energia e os termos contratuais parte da confiabilidade da plataforma.

GPU ainda não é nuvem

Um acelerador em um rack energizado pode executar código. Mas, sozinho, não é o que os clientes compram de uma nuvem. Equipes de treinamento precisam operar muitos aceleradores como uma única alocação. Os dados precisam chegar do armazenamento na velocidade necessária, e a comunicação coletiva deve percorrer as GPUs sem transformar a maior parte do tempo de computação em espera. Os tenants devem ficar isolados entre si, o scheduler precisa saber quais nós, links e dispositivos estão íntegros, e os checkpoints devem resistir a falhas.

Os engenheiros precisam de caminho para acessar o ambiente, e os usuários, de rotas para outras nuvens, escritórios e serviços. Somente quando esses caminhos são fornecidos de forma repetível e consistente é que se obtém um produto de nuvem.

Por isso, a rede de uma nuvem de IA não pode ser tratada como mero acessório dos recursos de computação. Na arquitetura corporativa comum, a rede é frequentemente descrita como o mecanismo que interliga servidores. Na IA distribuída, a própria rede participa da computação efetiva. Jobs síncronos podem ser atrasados por um único módulo óptico degradado, um acelerador lento, uma via congestionada ou um caminho de armazenamento que não acompanha. Enquanto isso, o hardware ocioso continua sendo faturado. Portanto, o projeto de rede afeta não apenas o desempenho de benchmark, mas a economia do tempo de GPU financiado.

A plataforma da CoreWeave ilustra essa relação com clareza excepcional. Em vez de oferecer GPUs como um pequeno recurso dentro de uma nuvem genérica, a empresa é especializada em infraestrutura de aceleradores. Por isso, seu material público detalha mais a estrutura de rack, DPUs, orquestração bare-metal, supercomputadores gerenciados, conexões privadas e remediação operacional do que um simples catálogo de instâncias. Esses elementos são evidências da intenção de design e da arquitetura do produto, mas não constituem um mapa completo de todos os sites, gerações e implantações de clientes.

A pergunta correta não é se a CoreWeave possui, em abstrato, uma “rede rápida”. É quantos tipos de rede precisam cooperar para executar cargas de IA como serviço confiável, e quem controla cada uma delas.

O que realmente se entende por “pilha de rede da CoreWeave”

Essa expressão é um termo editorial abrangente, não um nome corporativo nem um SKU vendido separadamente. A entidade jurídica e econômica operacional é a CoreWeave, Inc., uma sociedade de Delaware com sede em Livingston, Nova Jersey, listada na Nasdaq sob o ticker CRWV. A pilha de rede faz parte da plataforma mais ampla CoreWeave Cloud Platform, que inclui computação, armazenamento, orquestração e serviços gerenciados.

Nomes diferentes representam camadas distintas. Nimbus é a arquitetura de rede virtual baseada em DPU da CoreWeave. O CoreWeave Kubernetes Service (CKS) oferece Kubernetes bare-metal gerenciado. O SUNK agrupa infraestrutura e operações como supercomputador gerenciado, enquanto o Mission Control acrescenta monitoramento, remediação e suporte ao ciclo de vida. O Direct Connect é a conexão privada para clientes. Nomes como NVLink, NVSwitch, Quantum, Spectrum-X e BlueField são tecnologias da NVIDIA que a CoreWeave integra, não cria nem possui.

Separar as camadas evita dois erros típicos. O primeiro é tratar todos os protocolos e equipamentos dentro da plataforma como invenção da empresa. A contribuição da CoreWeave está na integração de sistemas, qualificação, operação e software de nuvem em torno das tecnologias do fornecedor. O segundo é imaginar um único tecido uniforme que vai de cada GPU a cada cliente. As conexões locais de scale-up, os fabrics de treinamento entre racks, as redes de armazenamento, os overlays de VPC, os caminhos de gerenciamento e o backbone transatlântico têm propósitos, orçamentos de latência e domínios de falha distintos.

Não devem ser resumidos em um único número de largura de banda.

A mesma disciplina se aplica à propriedade. Embora a CoreWeave implante e opere uma quantidade significativa de equipamentos, seus registros regulatórios mencionam arrendamentos, data centers de terceiros, compromissos de energia, relacionamentos de fibra óptica e financiamento de equipamentos. É possível integrar operacionalmente um serviço sem ser proprietário de cada prédio, concessionária, rota de longa distância ou componente do rack. O termo “integração vertical” só é útil quando significa controle coordenado sobre várias camadas, não autossuficiência completa.

De Atlantic Crypto para computação especializada

A CoreWeave começou em 2017 como The Atlantic Crypto Corporation. O negócio inicial usava ativos de GPU para cargas de mineração de criptoativos. Em setembro de 2018, converteu-se de LLC para sociedade de Delaware. Ao migrar para computação em nuvem especializada, mudou o nome para CoreWeave em dezembro de 2019.

Essa origem às vezes é simplificada como uma curiosa justaposição entre mineração de criptoativos e inteligência artificial. Mas a continuidade mais importante está na operação. Ambos os negócios exigem uma entidade que adquira aceleradores, garanta energia, opere hardware de alta densidade e aloque cargas de trabalho à capacidade ociosa. A empresa inicial aprendeu a economia de frotas de aceleradores antes de construir os sistemas de tenancy, rede, armazenamento e suporte necessários para a nuvem.

Essa distinção é importante porque a mudança de demanda não gera automaticamente uma plataforma. A mineração é relativamente repetitiva e tolera modelos de ativos simples. Já VFX, aprendizado de máquina e computação de alto desempenho exigem software, movimentação de dados, isolamento e garantias de serviço diferentes. A CoreWeave precisou adicionar camadas que tornassem os recursos confiáveis para clientes externos que não os possuíam nem podiam inspecionar fisicamente.

No início da década de 2020, a empresa desenvolveu serviços especializados de computação, armazenamento e Kubernetes. O Kubernetes bare-metal tornou-se a principal interface, permitindo que os clientes implantem cargas conteinerizadas diretamente em servidores com aceleradores, sem a camada prévia de máquinas virtuais tradicionais. Ao final de 2023, a CoreWeave reportava 10 data centers e cerca de 70 MW operacionais; ao final de 2024, 32 data centers e mais de 360 MW.

A escala mudou a natureza do problema de rede. Um operador com 10 sites ainda pode depender bastante do conhecimento tácito de especialistas e de exceções regionais. Uma nuvem com 30 a 40 sites exige projeto repetível, políticas controladas por software, qualificação comum, monitoramento compartilhado e mecanismos para migrar clientes entre gerações de hardware sem perder consistência operacional. A escala transforma boas decisões técnicas em questão de governança: quem pode aprovar alterações, com que rapidez as exceções são detectadas e se novos sites conseguem reproduzir a fronteira de controle pretendida.

A CoreWeave concluiu seu IPO em março de 2025. A abertura de capital não acrescentou apenas capital acionário. Por meio do prospecto e dos registros na SEC, tornaram-se públicas evidências sobre instalações, concentração de clientes, dívida, arrendamentos, arquitetura de interconexão e riscos. Esse registro permite analisar a pilha de rede tanto como sistema técnico quanto como compromisso de uma empresa de capital aberto.

A carga de trabalho determina a arquitetura

O treinamento de modelos em larga escala divide a computação entre vários aceleradores e troca resultados parciais repetidamente. Os padrões exatos de comunicação variam conforme a arquitetura do modelo, a estratégia de paralelismo e o software, mas o problema subjacente é comum. A velocidade efetiva de toda a alocação depende não apenas da computação local, mas da comunicação coletiva. Mesmo um fabric que pareça rápido em termos agregados pode desperdiçar capacidade se congestionamento, topologia ou latência de cauda atrasarem os pontos de sincronização que definem a conclusão do job.

A pilha também precisa lidar com tráfego de naturezas distintas. Os conjuntos de dados entram no ambiente, os checkpoints são transferidos da memória da GPU para o armazenamento. Os sistemas de controle distribuem jobs e políticas, os engenheiros coletam logs, e os serviços expõem endpoints de inferência. Backups e réplicas podem cruzar regiões. Cada classe tem uma tolerância diferente a latência e perda. Tratar tudo como uma única rede indiferenciada dificulta tanto a previsão de desempenho quanto o isolamento de falhas.

Daí a necessidade de um design em camadas. As conexões de scale-up criam domínios fortemente acoplados dentro de sistemas em escala de rack. Os fabrics de scale-out interligam muitos sistemas entre racks. Os caminhos de armazenamento alimentam dados para as cargas de trabalho e persistem o estado. As redes de tenant oferecem endereços e políticas privadas aos clientes, enquanto as redes de gerenciamento dão aos operadores controle sobre hosts, DPUs, switches e fluxos de remediação. O backbone conecta instalações e ecossistemas externos, e circuitos dedicados ligam a nuvem a outros domínios administrativos.

Essas camadas interagem, mas não são intercambiáveis. Fibras ópticas de longa distância não substituem um fabric local de GPU, porque a latência de propagação, sozinha, dificulta o treinamento síncrono denso entre sites remotos. Um domínio NVLink não funciona como VPC de cliente. Um overlay pode esconder diferenças de endereço, mas não conserta um módulo óptico com falha no underlay. O Kubernetes pode programar pods sem entender as vias físicas, a menos que a plataforma forneça informações topológicas e integração de dispositivos.

Portanto, essa arquitetura é um mecanismo de tradução encadeada de intenções. O cliente solicita clusters, namespaces, redes e jobs. O sistema de controle da CoreWeave mapeia essa solicitação para servidores, fabrics, armazenamento e políticas disponíveis. O Nimbus traduz a intenção de VPC para estado de DPU e underlay; serviços relacionados ao Kubernetes ou Slurm traduzem intenção de carga de trabalho para nós e aceleradores; o Mission Control traduz sinais de integridade em ações de remediação. O cliente vê o serviço, mas a plataforma precisa manter todas as traduções alinhadas.

Rede de scale-up dentro do domínio da escala de rack

A rede de scale-up conecta aceleradores dentro de sistemas fortemente integrados. No design em escala de rack da NVIDIA, o NVLink oferece comunicação de alta largura de banda entre GPUs, e o NVSwitch comuta esse domínio local. A CoreWeave incorpora essas tecnologias em determinados sistemas e gerações.

O importante não é o nome da marca, mas a proximidade. No domínio de scale-up, a divisão de modelos e as operações coletivas podem trocar dados sem passar pelo fabric comum do data center a cada iteração. Isso permite que o rack funcione mais como um enorme sistema acelerador do que como uma coleção de servidores independentes. Por outro lado, também cria domínios de falha específicos. Uma falha em switch, cabo, sistema de resfriamento ou componente dentro do rack pode afetar múltiplas GPUs das quais o scheduler espera comportamento coordenado.

O prospecto da CoreWeave descreveu que, em algumas configurações de cluster, a largura de banda de interconexão de GPU sem bloqueio pode chegar a 3.200 Gbps. A evidência mais relevante está justamente na ressalva “algumas configurações de cluster”. Isso não indica um nível de serviço universal, nem pode ser usado como número representativo de todos os sites ou gerações de aceleradores. A largura de banda que uma carga de trabalho realmente obtém também depende de software, topologia, padrão de mensagens e da integridade de todo o caminho.

O design de scale-up reduz um gargalo, mas aumenta a densidade em outro lugar. Mais aceleradores e largura de banda local elevam as exigências de potência, resfriamento e manutenibilidade do rack. Concentrar computação sem equilibrar o design térmico e operacional pode tornar os reparos mais difíceis ou deslocar o gargalo para as conexões de scale-out ou armazenamento. A arquitetura deve ser lida como um equilíbrio entre componentes, não como uma lista de especificações máximas.

O fabric de scale-out inclui InfiniBand e Ethernet

Quando o job ultrapassa o domínio de scale-up, ele entra no fabric de scale-out. Os registros públicos e a documentação técnica da CoreWeave mencionam o NVIDIA Quantum-2 InfiniBand, o Quantum-X800 XDR de 800 gigabits e o Spectrum-X Ethernet com RoCE e RDMA. A coexistência de InfiniBand e Ethernet é significativa: a empresa não amarra a identidade da plataforma a um único conjunto de protocolos.

InfiniBand para clusters fortemente acoplados

O InfiniBand baseia-se em comunicação de baixa latência com ênfase em acesso remoto direto à memória, sendo usado há muito tempo em computação de alto desempenho. Em clusters de IA, ele pode mover dados entre hosts aceleradores evitando parte da sobrecarga habitual de processamento do host. Os sistemas Quantum da NVIDIA acrescentam funcionalidades de switching e comunicação coletiva adequadas a cargas síncronas de grande escala. A CoreWeave integra o InfiniBand à oferta de clusters, em vez de vendê-lo como serviço de rede independente.

As informações públicas não revelam todas as topologias, taxas de sobreassinatura, políticas de roteamento e fronteiras de serviço. “Sem bloqueio” pode descrever um design específico, não necessariamente uma propriedade de toda a frota. Mesmo um fabric bem projetado pode ser afetado por componentes ópticos degradados, posicionamento inadequado, tráfego desbalanceado ou comportamento de software que gere pontos de congestionamento. Os compradores devem verificar quais gerações de hardware, topologias e qualificações se aplicam ao cluster que lhes for alocado.

Spectrum-X e RoCE como caminhos Ethernet

O Spectrum-X é a plataforma de rede para IA baseada em Ethernet da NVIDIA. O RoCE transporta a semântica de RDMA sobre Ethernet, permitindo que as aplicações usem comunicação direta de memória enquanto o operador mantém um fabric Ethernet. A adoção do Spectrum-X pela CoreWeave oferece um caminho alternativo de scale-out para cargas de trabalho e gerações de sistemas projetadas para esse ecossistema.

Estar familiarizado com Ethernet não equivale a operá-la com facilidade. O desempenho do RoCE depende de controle de congestionamento, projeto de filas, comportamento de perda, telemetria e configuração ponta a ponta. Mesmo usando quadros Ethernet familiares, evitar bloqueios head-of-line, incast e desempenho instável de comunicação coletiva exige engenharia especializada. O valor de uma nuvem integrada está no provedor assumir grande parte desses ajustes. Em contrapartida, o cliente perde visibilidade sobre os detalhes da escolha.

Topologia otimizada por via e posicionamento

Sistemas com múltiplas vias alinham as interfaces de rede correspondentes com os aceleradores, fazendo o tráfego coletivo percorrer caminhos paralelos regulares. Projetos otimizados por via podem reduzir cruzamentos desnecessários e tornar a largura de banda mais previsível. No entanto, o scheduler precisa entender a topologia. Se o job for alocado a uma combinação errada de nós, perdem-se as vantagens do design físico.

As vias também podem concentrar falhas. Se uma via se degradar, todos os nós que a utilizam podem se tornar stragglers, mesmo que as outras interfaces estejam íntegras. O sistema operacional precisa distinguir entre falhas de servidor único e falhas de rede compartilhada. É por isso que telemetria, qualificação e remediação com consciência topológica são tão importantes quanto a velocidade da porta.

Nimbus desloca a fronteira da nuvem para o DPU

Um fabric de cluster de alto desempenho, sozinho, não forma uma nuvem multi-tenant. Os clientes precisam de endereçamento privado, controle de rota, conectividade com a internet e isolamento de outros clientes. A resposta da CoreWeave é o Nimbus, uma arquitetura de rede virtual que descarrega funções de VPC no DPU. A documentação pública especifica o NVIDIA BlueField-3 DPU e descreve VRF, VXLAN e rotas EVPN Tipo 5 na arquitetura de segurança.

O DPU ocupa uma posição privilegiada entre a computação controlada pelo cliente e a infraestrutura controlada pelo provedor. Ele processa o tráfego da rede virtual, impõe segmentação e pode preservar a CPU do host para a carga de trabalho. Também é capaz de manter a fronteira de tenancy fora do sistema operacional que o cliente eventualmente controla. Esse isolamento é tanto uma decisão de segurança quanto de desempenho.

Como o overlay de VPC é montado

VRF isola um domínio de roteamento de outro. VXLAN transporta segmentos de tenant sobre um underlay físico compartilhado. EVPN distribui alcançabilidade, e as rotas Tipo 5 podem anunciar prefixos IP, não apenas endereços MAC individuais. Combinando esses mecanismos, a CoreWeave consegue apresentar redes privadas enquanto compartilha a infraestrutura física subjacente.

O overlay não elimina a dependência do underlay. Se a alcançabilidade física for perdida, a rede virtual também se perde. Se a distribuição de rotas for incorreta, o isolamento ou a alcançabilidade podem ser quebrados em larga escala. Se houver falha na imagem do DPU ou no sistema de políticas, o mesmo estado incorreto pode ser distribuído rapidamente a muitos hosts. A abstração da nuvem reduz a carga do cliente ao transferir a complexidade do cliente para a infraestrutura do provedor, mas não elimina a complexidade em si.

O DPU torna-se parte da base de confiança

O Nimbus separa as funções de rede do provedor do host do cliente, mas, ao mesmo tempo, aumenta a importância do firmware do DPU, do boot seguro, das chaves, da distribuição de políticas, dos logs e da recuperação. O dispositivo que impõe o isolamento precisa ser observável e passível de correção, sem se tornar um caminho descontrolado para o ambiente do tenant.

Essa fronteira de controle também influencia a resposta a incidentes. A causa de uma falha de conectividade pode estar na carga de trabalho do cliente, na política do Kubernetes, na configuração da VPC, no software do DPU, no plano de controle EVPN ou no fabric físico. As equipes de suporte precisam de evidências que atravessem essas camadas sem expor informações de um tenant a outro. A documentação pública descreve a arquitetura pretendida, mas não divulga registros independentes de toda a frota sobre falhas de isolamento ou tempos de remediação.

Kubernetes bare-metal como superfície de controle do cliente

O CoreWeave Kubernetes Service oferece Kubernetes gerenciado sobre infraestrutura bare-metal. Não há a camada de máquina virtual tradicional entre a base de contêineres e os servidores GPU. Cada cluster recebe uma VPC própria e integra rede de alto desempenho e armazenamento para cargas distribuídas.

O bare-metal elimina uma camada de abstração, mas não simplifica o sistema. O Kubernetes precisa descobrir GPUs, expor dispositivos, impor cotas, programar pods e trabalhar com plugins de rede e armazenamento. A plataforma precisa alinhar imagens de nó, drivers, firmware, runtime de contêineres e atualizações de cluster com as gerações de hardware subjacentes. O cliente obtém uma API familiar; a CoreWeave assume uma matriz de compatibilidade exigente.

O que o Kubernetes pode decidir e o que não pode

O Kubernetes pode decidir onde executar um pod com base nas informações e políticas fornecidas ao scheduler. No entanto, ele não sabe automaticamente todas as vias, componentes ópticos, caminhos de switch e condições de desempenho de comunicação coletiva. A CoreWeave precisa adicionar plugins de dispositivo, operadores, informações topológicas e controles operacionais para que as decisões lógicas de escalonamento correspondam a alocações físicas viáveis.

As políticas de rede também têm alcance limitado. As políticas do Kubernetes podem restringir a comunicação permitida entre cargas de trabalho, enquanto a VPC e os controles do DPU fornecem fronteiras mais amplas de tenancy e roteamento. A mera existência de um objeto de política não comprova que o caminho dos pacotes esteja realmente aplicando as regras pretendidas. Configuração, implementação e observação precisam coincidir.

SUNK transforma clusters em supercomputadores gerenciados

O SUNK é posicionado como supercomputador gerenciado em produção. Para clientes que precisam de ambientes dedicados de larga escala, mas não desejam construir sozinhos toda a instalação e a equipe operacional, ele agrupa infraestrutura, fabric de alto desempenho, orquestração de cargas e as operações da CoreWeave.

Esse serviço altera a divisão de responsabilidades. O cliente continua proprietário da arquitetura do modelo, do código, dos dados e da estratégia de jobs, mas grande parte do ciclo de vida do hardware, da qualificação do cluster e da resposta a incidentes passa para a CoreWeave. O resultado se aproxima mais de uma instalação de HPC gerenciada, oferecida com contrato e software típicos da era da nuvem, do que de um pool comum de instâncias intercambiáveis.

Mission Control torna as operações parte do produto

O Mission Control acrescenta monitoramento, manutenção, reparo e suporte ao ciclo de vida. Sua importância fica mais clara quanto maior for o job. Trocar uma peça com defeito em um pequeno pool de servidores pode ter impacto limitado, mas conseguir diagnosticar um link degradado dentro de uma alocação densamente sincronizada determina se milhares de horas de acelerador serão produtivas ou desperdiçadas.

O material de serviço da CoreWeave descreve monitoramento preventivo e intervenção operacional. Isso é evidência do modelo pretendido, não uma verificação independente de disponibilidade ou uma distribuição pública de tempos médios de reparo. A ausência de estatísticas completas de incidentes é relevante, porque a confiabilidade é um dos principais motivos pelos quais os clientes pagam a um provedor em vez de montar seus próprios clusters.

O armazenamento faz parte da computação em rede

Dados de treinamento, checkpoints e artefatos de modelo passam pelos caminhos de armazenamento, e esses caminhos podem restringir toda a carga de trabalho. Mesmo um cluster com largura de banda entre GPUs muito alta ficará parado se não conseguir ler entradas com rapidez suficiente, escrever checkpoints ou recuperar o estado rapidamente. A plataforma da CoreWeave inclui armazenamento de objetos e de arquivos, descrevendo a movimentação de dados de alto desempenho como parte do serviço.

O tráfego de checkpoint tem um padrão operacional peculiar. Muitos workers precisam persistir o estado em intervalos coordenados, o que pode gerar rajadas em momentos diferentes da comunicação coletiva. Se o tráfego de armazenamento compartilhar recursos físicos com o fabric de treinamento, será necessário planejamento de isolamento ou capacidade. Mesmo que use uma rede separada, a plataforma precisa coordenar falhas e recuperações que atravessam ambos os caminhos.

O armazenamento também afeta a portabilidade. Migrar um modelo para a CoreWeave exige receber grandes volumes de dados de outras nuvens ou ambientes privados. A saída pode implicar custos, tempo e atrito contratual. O “Zero Egress Migration” é um mecanismo comercial que reduz determinados custos associados à migração para a CoreWeave, não uma garantia técnica, nem uma prova de egress gratuito universal, ou de que a movimentação de dados não tenha custo operacional.

Portanto, o cliente que avalia a pilha deve buscar evidências ponta a ponta. Os valores de pico de aceleradores e fabrics são úteis, mas as cargas de produção incluem preparação de datasets, checkpoints, registro de modelos, logs e recuperação. Benchmarks que isolam uma única camada não respondem à pergunta econômica: em quanto tempo o job inteiro termina?

O backbone conecta regiões, mas não as transforma em um único supercomputador síncrono

A CoreWeave descreve um backbone de nível de operadora que interliga seus data centers na América do Norte e na Europa por fibra óptica terrestre e submarina, com peering direto e serviços de conexão privada. Os registros indicam que o Direct Connect é oferecido a 10, 100 e 400 Gbps, dependendo da localidade e da disponibilidade.

O papel do backbone é diferente do fabric local de scale-out. Ele transporta datasets, réplicas, checkpoints, tráfego de controle e de inferência entre regiões; conecta usuários e outras nuvens; e auxilia na recuperação e na distribuição. No entanto, a latência de propagação de longa distância impede que instalações remotas sejam transformadas em um único fabric de treinamento de baixa latência para jobs fortemente acoplados.

Conexões privadas reduzem um tipo de incerteza

Circuitos dedicados podem evitar parte da variação de rota da internet pública e estabelecer fronteiras mais nítidas de capacidade e suporte. Contudo, não criam um mundo totalmente privado de ponta a ponta. O acesso do cliente pode depender de operadoras, cross-connects e operadores de data center. Os on-ramps de nuvem possuem procedimentos de aceitação e configurações próprios. A diversidade de rotas e a propriedade física não são totalmente divulgadas para todos os sites.

Portanto, não se deve caracterizar a CoreWeave como uma operadora Tier 1. A empresa opera backbone e faz peering, mas seu material público não comprova alcance global com interconexão gratuita, nem propriedade de todas as rotas de fibra óptica. A vantagem está no acesso integrado aos seus próprios ativos de computação, não em substituir o ecossistema global de telecomunicações.

O design regional gera escolhas de disponibilidade

No final de 2025, a CoreWeave reportou operar instalações em seis países. O número de instalações não significa que todas as gerações de aceleradores, todos os fabrics, todos os serviços e todas as velocidades de conexão privada estejam disponíveis em cada país. Energia, resfriamento, rede, hardware e prontidão operacional não amadurecem simultaneamente; as regiões entram em operação por fases.

Para os clientes, a geografia afeta não apenas a latência, mas também a governança de dados, a proximidade com outras nuvens, a disponibilidade de pessoal, as fontes de energia, as falhas correlacionadas e os parceiros que controlam as rotas locais. Para a CoreWeave, cada novo país acrescenta não só capacidade, mas também ajustes legais, de concessionárias e de cadeia de suprimentos. A expansão geográfica da rede, portanto, é um modelo operacional, não um mapa onde se replicam as mesmas caixas.

Confiabilidade é transformar capital em tempo útil

O hardware da CoreWeave tem custo financeiro, seja o job avançando ou parado. Por isso, a confiabilidade é uma variável financeira. Falhas de fabric, GPUs degradadas, interrupções de armazenamento ou defeitos no scheduler reduzem a produção faturável e útil, enquanto juros, arrendamentos e obrigações de energia continuam correndo.

Stragglers importam mais do que falhas completas

Um nó com falha é fácil de encontrar. Um straggler, tecnicamente ainda operacional, atrasa todos os pontos de sincronização. Jobs grandes exigem telemetria capaz de detectar degradação de desempenho, não apenas estado binário de funcionamento. O scheduler e a equipe operacional precisam decidir se removem, substituem ou continuam usando o componente.

Não há, nos registros públicos, distribuições completas de falhas de jobs, latências de cauda ou taxas de ocorrência de stragglers. Isso não prova baixa confiabilidade, mas limita comparações independentes. Os clientes devem basear-se em contratos, testes de carga e suas próprias evidências operacionais, em vez de inferir a partir de diagramas de arquitetura.

Qualificação é o teste do sistema

Antes de entregar um cluster, a CoreWeave precisa qualificar servidores, switches, componentes ópticos, cabos, firmware, drivers, armazenamento e orquestração como um todo integrado. Passar em um teste de inicialização não basta. O teste útil é se a topologia completa consegue sustentar as cargas de trabalho previstas, resistir a falhas e ser reparada sem gerar novas inconsistências.

A qualificação também tem uma dimensão temporal. Um design que funcionou com determinada combinação de software e firmware pode não funcionar da mesma forma após atualizações. A rápida introdução de novas gerações da NVIDIA aumenta as combinações que a CoreWeave precisa suportar, enquanto os ambientes contratados de gerações anteriores continuam operando. Maturidade operacional é a capacidade de gerenciar esses períodos de sobreposição sem que cada site se torne uma exceção única.

As finanças são uma camada da arquitetura

Em 2025, a CoreWeave reportou US$ 5,1 bilhões de receita e US$ 1,2 bilhão de prejuízo líquido, com desembolsos anuais de caixa de US$ 10,3 bilhões em ativos fixos tangíveis. As obrigações de desempenho remanescentes no final do ano eram de US$ 60,7 bilhões. Os mesmos registros mencionam financiamento de equipamentos em larga escala, dívida, arrendamentos e compromissos de infraestrutura.

São conceitos distintos. Receita é a receita de serviços reconhecida. Desembolsos em ativos fixos tangíveis são saídas de caixa de investimento, não o valor total da frota instalada. O prejuízo líquido indica que o crescimento ainda não gera lucro consolidado. As obrigações de desempenho remanescentes são compromissos contratuais futuros contábeis, não dinheiro em conta bancária nem serviços já prestados.

O primeiro trimestre de 2026 apresentou demanda e custo de carregamento simultaneamente

No trimestre encerrado em 31 de março de 2026, a CoreWeave reportou receita de US$ 2,078 bilhões, prejuízo líquido de US$ 740 milhões e despesas com juros de US$ 536 milhões. Também reportou um backlog de US$ 99,4 bilhões, conforme definição própria. O período exibe forte visibilidade de demanda e, ao mesmo tempo, pesados encargos financeiros.

O backlog não substitui diretamente as obrigações de desempenho remanescentes do fim do ano; as definições e os momentos são diferentes. Ambos indicam demanda contratada futura, mas sua conversão exige que a CoreWeave coloque em operação instalações, energia, hardware e capacidade de rede, e cumpra os contratos. Quanto mais atrativo o backlog parecer, maiores serão as obrigações de fornecimento que o acompanham.

O financiamento com garantia de GPU vincula ativos e contratos

A CoreWeave utilizou empréstimos com garantia, financiamento de equipamentos e estruturas apoiadas por clientes para financiar a expansão. Em junho de 2026, anunciou uma linha de financiamento de US$ 8,5 bilhões descrita como com garantia de GPU e grau de investimento para as transações elegíveis. Essa linha amplia a capacidade de implantação, mas não é receita, nem significa que todas as dívidas da empresa tenham grau de investimento.

O financiamento com garantia de ativos permite casar a dívida com o hardware e o fluxo de caixa dos contratos. Por outro lado, pode impor restrições sobre a garantia, a implantação e o uso do caixa. Aceleradores, switches e componentes ópticos se tornam obsoletos mais rapidamente do que muitos ativos de infraestrutura tradicionais. Esse modelo financeiro funciona melhor quando a utilização é alta e os contratos de cliente perduram além do pico de valor econômico do equipamento.

Portanto, o projeto de rede afeta a capacidade de crédito. Topologias que viabilizam alta utilização aumentam a produção produtiva dos ativos financiados. Atrasos em sites, problemas persistentes de stragglers e falhas de migração a reduzem. No modelo da CoreWeave, engenharia de sistemas e engenharia de balanço não são histórias separadas.

Concentração de clientes também é dependência de infraestrutura

A Microsoft representou 67% da receita da CoreWeave em 2025. Um grande cliente âncora justifica a capacidade, sustenta o financiamento e dá ao provedor confiança para adquirir equipamentos antecipadamente. A mesma concentração aumenta o poder de negociação do cliente e torna a utilização sensível a uma única relação comercial.

A CoreWeave anunciou ou reportou relacionamentos com clientes adicionais, como Meta, Anthropic e outros. Em julho de 2026, a Flow Traders selecionou a empresa para treinamento de modelos fundamentais, e a Leidos anunciou colaboração em IA para os setores de defesa, segurança nacional e inteligência. Esses comunicados respaldam contratação, seleção ou colaboração, nos limites do que cada fonte registra. Não provam, contudo, que a concentração foi eliminada, nem que toda a capacidade anunciada já esteja implantada.

Contratos take-or-pay transferem risco, mas não o eliminam

Contratos plurianuais do tipo take-or-pay conferem à CoreWeave visibilidade de demanda e podem sustentar o financiamento. Transferem parte do risco de utilização do provedor para o cliente, pois o pagamento prometido não depende apenas do consumo de curto prazo. No entanto, permanecem os riscos de construção, energia, entrega, desempenho, crédito e renegociação.

Do ponto de vista do cliente, esse contrato inverte parcialmente a promessa da nuvem. A nuvem pública tradicional enfatiza uso elástico e compromisso limitado. Clusters de IA dedicados podem exigir relações mais longas e próximas da infraestrutura, porque o provedor precisa construir ou reservar capacidade específica. A interface parece software de nuvem, mas por baixo funciona como financiamento de projeto.

Operações de defesa e reguladas elevam o nível de garantia

A colaboração com a Leidos, em 30 de julho de 2026, expande a plataforma para missões de defesa e inteligência. Essa colaboração, por si só, não estabelece todas as autorizações, certificações e implantações exigidas para operações reguladas. Mas indica que segurança, gestão da cadeia de suprimentos, auditabilidade e continuidade operacional podem se tornar elementos ainda mais críticos da oferta da CoreWeave.

VPCs aplicadas por DPU, conexões privadas e operações gerenciadas podem apoiar projetos de alta garantia. No entanto, não substituem controles específicos de programa, requisitos de pessoal, tratamento de dados e aprovações governamentais. Quanto mais a empresa se aproxima de cargas de missão crítica, mais transparente precisará ser sobre as fronteiras de responsabilidade.

Aquisições expandem a pilha para cima; a fusão fracassada apontava para baixo

Em 2025, a CoreWeave adquiriu Weights & Biases, OpenPipe, marimo e Monolith AI. A Weights & Biases acrescentou ferramentas de desenvolvimento de modelos e observabilidade; as demais aquisições ampliaram capacidades de inferência, notebooks e IA industrial. Com essas transações, a CoreWeave avança além da infraestrutura bruta, passando a cobrir mais etapas do ciclo de vida de desenvolvimento.

A lógica estratégica é clara: um provedor que entende o fluxo de trabalho do modelo pode melhorar a previsão de demanda, tornar a infraestrutura mais acessível e reter clientes ao longo de várias fases do desenvolvimento. Os riscos de integração são igualmente claros. Negócios de software têm ciclos de lançamento, margens e culturas diferentes das operações de data center financiadas. Se a CoreWeave passar a controlar ferramentas que os clientes obtinham de fornecedores independentes, podem surgir sobreposições de produto e competição com parceiros.

A proposta de aquisição da Core Scientific apontava na direção oposta. Em julho de 2025, a CoreWeave anunciou um acordo de fusão para reforçar o controle sobre a capacidade de data centers e a economia de arrendamentos. Contudo, a Core Scientific rescindiu o acordo em 30 de outubro de 2025, após votação dos acionistas. A CoreWeave não adquiriu a empresa.

A sequência de transações revela uma estratégia de integração em duas direções: para cima, rumo ao software para desenvolvedores; para baixo, em direção à capacidade física. O fracasso da fusão também mostrou que a plataforma nem sempre consegue comprar o controle da infraestrutura no cronograma desejado. Acionistas, reguladores, financiamento e estruturas contratuais podem interromper a lógica técnica da integração vertical.

O que a CoreWeave controla e o que permanece fora de sua fronteira

A CoreWeave controla a plataforma do cliente, muitas decisões de design, a qualificação de equipamentos, a orquestração e os processos operacionais. Pode escolher como o Nimbus mapeia as VPCs, como os clusters são apresentados, quais serviços são gerenciados e como os incidentes são tratados. Pode adquirir hardware antecipadamente e configurar as instalações em torno da densidade de aceleradores.

A NVIDIA controla o roadmap crítico de GPUs, NVLink, InfiniBand, Spectrum-X e BlueField. Concessionárias de energia e parceiros de data center controlam parte do fornecimento de energia e de instalações; operadoras de fibra, pontos de troca de tráfego e provedores de nuvem controlam parte da conectividade externa. Credores e financiadores de equipamentos restringem o uso do capital, e grandes clientes influenciam o planejamento de capacidade por meio dos contratos.

Isso não é uma fragilidade exclusiva da CoreWeave. Toda nuvem depende de fornecedores e instalações. Mas a diferenciação da CoreWeave está fortemente atrelada à rápida adoção dos sistemas NVIDIA, e seus compromissos de capital são extremamente grandes em relação ao histórico operacional. Por isso, a concentração é relevante: um atraso ou mudança de roadmap de um único fornecedor pode repercutir na entrega aos clientes e no financiamento.

O ponto forte da plataforma está na coordenação através das fronteiras. O risco está na dependência correlacionada, em que a mesma geração de fornecedor, o mesmo design de site ou o mesmo programa de cliente podem afetar várias camadas simultaneamente. A integração reduz o número de contratos que o cliente precisa gerenciar, mas pode amplificar o impacto de falhas de classe de provedor.

Posição competitiva: nuvem especializada é escolher onde colocar a responsabilidade

A CoreWeave compete com nuvens hyperscale, outras nuvens especializadas em GPU, clusters próprios de clientes e combinações de colocation, hospedagem e integração gerenciada. A comparação não pode ser reduzida à contagem de GPUs ou a um único benchmark. Os compradores comparam gerações de hardware disponíveis, fabrics, armazenamento, escalonamento, conexão privada, suporte, prazos contratuais, geografia e custo total de movimentação de dados.

Comparação com nuvens hyperscale

AWS, Microsoft Azure, Google Cloud e Oracle possuem amplos portfólios de serviços, ecossistemas globais e balanços robustos. Conseguem combinar infraestrutura de IA com bancos de dados, segurança, análises e compras corporativas que os clientes já utilizam. A aposta da CoreWeave é a especialização: rápida integração de gerações selecionadas da NVIDIA, orquestração bare-metal e design voltado para cargas de trabalho de aceleradores de alta densidade.

A especialização pode reduzir abstrações e encurtar a qualificação. Por outro lado, também pode estreitar o leque de falhas e de fornecedores. O cliente que escolhe a CoreWeave ganha um provedor focado na carga de trabalho, mas pode aceitar uma amplitude de serviços menor e uma estrutura de capital mais jovem. A comparação correta deve ser feita por carga de trabalho, não por categoria.

Comparação com outras nuvens especializadas

Operadores de infraestrutura de IA como Lambda, Nebius e Crusoe se sobrepõem em oferta de aceleradores, clusters e serviços gerenciados. As diferenças estão na geografia, na estratégia energética, no portfólio de software, na propriedade, na estrutura de capital e no grau de controle sobre as instalações. “Neocloud” é um rótulo de mercado, não uma arquitetura comum.

Os registros de empresa aberta da CoreWeave fornecem evidências excepcionalmente detalhadas sobre escala e riscos. Mas isso, sozinho, não prova superioridade técnica ou econômica. Concorrentes com menos divulgação podem ser menores, mais eficientes ou apenas menos transparentes. Não se deve converter transparência em ranking de desempenho.

Comparação com a construção de clusters privados

Clusters próprios dão ao comprador controle direto sobre hardware, dados e operações. Em contrapartida, exigem aquisição, energia, instalações, rede, armazenamento, segurança, firmware, peças de reposição e pessoal especializado. O que a CoreWeave vende é a transferência de grande parte desse fardo.

A transferência não é completa. O cliente ainda precisa projetar a carga de trabalho, gerenciar os dados, definir políticas e avaliar os riscos do provedor. Compromissos de longo prazo podem reduzir a flexibilidade de migração. Um cluster privado pode ter baixa utilização dentro da empresa; um contrato de nuvem traz dependência do provedor. A escolha econômica é sobre qual modelo absorve melhor a variabilidade e mantém sistemas caros produtivos.

O switching refrigerado a líquido indica para onde o próximo gargalo se desloca

Em julho de 2026, a CoreWeave divulgou material sobre switching refrigerado a líquido para aumentar a densidade de largura de banda de rede por rack. A afirmação não é um benchmark independente de toda a frota, mas se baseia na arquitetura e nos cálculos da própria empresa. Ainda assim, o mecanismo é relevante. À medida que a densidade de aceleradores aumenta, o consumo de energia e o calor gerado por switches e componentes ópticos entram na equação de resfriamento do rack.

Resfriar switches com líquido permite colocar mais capacidade de rede dentro de um rack restrito, reduzindo a necessidade de posicionar switches mais distantes. Caminhos mais curtos podem simplificar o cabeamento e manter a densidade. Por outro lado, vincula a manutenção da rede ao sistema de refrigeração líquida. Vazamentos, falhas de bomba e procedimentos de manutenção podem afetar componentes que antes eram gerenciados como equipamentos de rede resfriados a ar.

Essa mudança ilustra um padrão mais amplo. Os gargalos da infraestrutura de IA se deslocam. GPUs mais rápidas exigem maior largura de banda de scale-up; o aumento da largura de banda do rack demanda switches de scale-out mais densos. Switches mais densos elevam as exigências de potência e resfriamento, e novas instalações podem precisar de um projeto elétrico e mecânico diferente. Uma mudança de geração de produto pode se tornar não apenas uma atualização de servidores, mas um redesenho do data center.

Vera Rubin é uma transição futura, não uma descrição da frota instalada

O material de julho de 2026 da CoreWeave descreve a preparação para os sistemas NVIDIA Vera Rubin NVL72 e apresenta afirmações de medição própria ou projeções sobre tokens por megawatt, em comparação com a Blackwell. Esses dados devem ser atribuídos à CoreWeave e às configurações especificadas, e não indicam que estivessem disponíveis em toda a frota no momento da pesquisa.

Uma nova geração altera simultaneamente aceleradores, fabric de scale-up, largura de banda de scale-out, potência do rack, resfriamento, firmware, drivers, orquestração e qualificação. Embora possa melhorar a produção por megawatt, também pode tornar as instalações existentes inadequadas ou menos competitivas. A rápida adoção de novo hardware pela CoreWeave só se torna uma vantagem estratégica se a empresa conseguir gerenciar a transição, a utilização e a depreciação dos ativos contratados mais antigos.

A transição também aprofunda a dependência da NVIDIA. O acesso antecipado pode atrair clientes e sustentar contratos premium, mas expõe a empresa a cronogramas, preços e decisões arquitetônicas do fornecedor que ela não controla. Diversificar a base de clientes e as camadas de software não significa necessariamente diversificar a pilha física.

O impacto da pilha sobre a infraestrutura digital como um todo

A expansão da CoreWeave afeta mercados que vão muito além do aluguel de GPUs. Compromissos na casa dos gigawatts geram demanda por geração de energia, conexões à rede, transformadores, resfriamento, terrenos e construção. Fabrics de alto radix exigem switches, componentes ópticos e fibra; conexões privadas requerem capacidade de operadoras, pontos de troca de tráfego e on-ramps de nuvem. As estruturas financeiras demandam credores capazes de avaliar tecnologia de rápida obsolescência contra contratos de longo prazo.

A plataforma também altera onde o tráfego de internet aparece. O tráfego de treinamento densamente acoplado permanece, em sua maior parte, dentro do fabric local, mas datasets, checkpoints, artefatos de modelo, requisições de inferência e fluxos de trabalho de desenvolvedores transitam entre nuvens, data centers e usuários. O impacto visível na internet provavelmente decorre mais da movimentação contínua de dados ao redor dos ambientes de treinamento do que de um único fluxo de treinamento gigantesco.

Para as comunidades locais e as redes elétricas que recebem as instalações, a pilha é uma decisão de energia e uso do solo. O material analisado não contém evidências site a site suficientes para conclusões ambientais sobre toda a empresa. Por outro lado, é possível confirmar que potência operacional e potência contratada são métricas importantes para medir o crescimento, e que atrasos na entrega de energia ou de instalações representam riscos de negócio.

Para os engenheiros de rede, essa arquitetura mostra que a infraestrutura de IA está se transformando em uma especialidade própria. O conhecimento de roteamento e switching continua necessário, mas passa a se cruzar com bibliotecas de comunicação coletiva, topologia de aceleradores, refrigeração líquida, escalonamento de cargas de trabalho e financiamento de projetos. Quem ajusta o congestionamento pode estar protegendo não apenas a conclusão de um job, mas também o serviço da dívida.

O que as informações públicas não revelam

A CoreWeave publica documentação de produto, blogs técnicos e registros financeiros, mas parte da pilha permanece opaca. O material disponível não inclui topologias atuais completas, inventário de fabrics por site, tabelas de sobreassinatura, mapas de propriedade de fibra, histórico de incidentes ou conjuntos de benchmarks independentes por carga de trabalho.

Essa fronteira deve mudar a forma como as afirmações são redigidas. A documentação de arquitetura comprova o mecanismo; os registros na SEC, as finanças consolidadas e os fatos de risco; os comunicados com nomes de clientes, a seleção ou a colaboração. Nenhum deles, porém, prova resultados universais de carga de trabalho, disponibilidade de toda a frota ou baixo custo total para todos os compradores.

O mesmo cuidado se aplica à escala. Potência operacional não é potência contratada. Backlog não é receita. Datas previstas de divulgação de resultados não são resultados realizados. Contratos de cliente anunciados não são utilização efetiva. Aquisições propostas não são propriedade. Gerações futuras de hardware não são a frota atual.

Essas distinções não enfraquecem o artigo. Elas mostram as lacunas de informação reais que o leitor especializado precisa gerenciar. A CoreWeave tenta fazer com que clientes e provedores de capital confiem em um sistema integrado cujos detalhes mais valiosos são, inevitavelmente, não públicos. A resposta razoável não é presumir excelência nem fracasso, mas exigir evidências no nível do contrato, do cluster e do site que está sendo considerado.

Avaliação central

O produto da CoreWeave é frequentemente descrito como capacidade de computação. O produto mais profundo é a capacidade de coordenação. É preciso alinhar o roadmap do fornecedor com a construção de data centers; a conexão de scale-up com o fabric de scale-out; a política do DPU com a intenção do tenant; o escalonamento do Kubernetes com a topologia física; o armazenamento com o comportamento de checkpoint; a conectividade do backbone com o acesso do cliente; e o financiamento de longo prazo com gerações curtas de hardware.

Essa coordenação pode gerar uma vantagem genuína. Um provedor especializado consegue tomar decisões ao longo de toda a carga de trabalho, em vez de obrigar o cliente a montar fornecedores separados. Pode qualificar sistemas, reparar falhas e introduzir novas gerações mais rapidamente do que a maioria das empresas faria sozinha. O rápido crescimento da plataforma indica que grandes clientes valorizam essa transferência de responsabilidade.

A mesma integração também concentra os resultados. Um design de fabric, um atraso de fornecedor, um erro de política, uma restrição de capital ou uma mudança no cliente âncora podem afetar grandes porções do sistema. O futuro da empresa não depende de uma única manchete de largura de banda, mas da capacidade de todas as camadas continuarem convertendo capacidade financiada em trabalho confiável para o cliente.