Resumen

  • La pila de red de CoreWeave abarca capas de scale-up, scale-out, almacenamiento, inquilinos, gestión, troncal y conectividad privada; es una arquitectura operativa, no un producto independiente.
  • Las redes y DPU de NVIDIA se combinan con el software de CoreWeave para programar aceleradores, aislar inquilinos y mover datos en una nube especializada.
  • CoreWeave declara 43 centros de datos, más de 850 MW en operación y unos 3,1 GW contratados; Microsoft aporta el 67 % de los ingresos de 2025, mostrando escala y concentración.
  • La prueba clave es si la energía contratada y la cartera de pedidos pueden convertirse en un servicio fiable y con clientes diversificados antes de que se acumulen los costes de financiación, los alquileres, la obsolescencia del hardware y la complejidad operativa.

La escala física crece más rápido de lo que los mapas de regiones cloud convencionales pueden representar

A 31 de diciembre de 2025, CoreWeave declaró 43 centros de datos, más de 850 MW de energía en operación y aproximadamente 3,1 GW de capacidad contratada. La cifra de energía en operación representa la infraestructura que la empresa consideraba en servicio en ese momento según su propia definición; la cifra contratada refleja derechos y compromisos futuros de despliegue, y no debe describirse como capacidad instalada.

El crecimiento es muy pronunciado: a finales de 2023, contaba con 10 centros de datos y unos 70 MW; a finales de 2024, 32 y más de 360 MW; y a finales de 2025, 43 y más de 850 MW. En el primer trimestre de 2026, la empresa informó de más de 1 GW en operación y más de 3,5 GW contratados. Esto muestra la velocidad de una expansión industrializada, y también lo rápido que una arquitectura más antigua puede pasar a ser minoritaria.

La energía es solo un requisito previo, no el producto final. Los MW contratados aún necesitan acceso a la red eléctrica, generación o suministro, distribución de alta densidad, refrigeración, construcción, rutas de red, entrega de aceleradores y aceptación operativa. Cualquier retraso en alguno de estos niveles puede posponer los ingresos, mientras que ciertos costes y obligaciones ya han comenzado.

El modelo de centros de datos es híbrido. CoreWeave posee equipos y controla un gran número de despliegues, al mismo tiempo que utiliza instalaciones alquiladas y proveedores de servicios externos. Esto puede acelerar la expansión geográfica, pero también hace que el rendimiento de los propietarios, los plazos de construcción, la entrega de energía y las condiciones contractuales pasen a formar parte de la fiabilidad de la plataforma.

Una GPU no es todavía una nube

Un acelerador colocado en un rack con energía puede ejecutar código, pero no proporciona automáticamente lo que los clientes compran a un servicio cloud.

Los equipos de entrenamiento necesitan que muchos aceleradores funcionen como un conjunto unificado de recursos; los datos deben pasar del almacenamiento al cómputo con la velocidad suficiente; la comunicación colectiva no puede hacer que las tareas estén la mayor parte del tiempo esperando; los distintos inquilinos deben estar aislados entre sí; el planificador debe saber qué nodos, enlaces y dispositivos están en buen estado; los checkpoints deben conservarse tras un fallo; los ingenieros necesitan rutas hacia los entornos, y los usuarios también necesitan rutas hacia otras nubes, redes corporativas y servicios externos.

Solo cuando estas rutas pueden repetirse de forma estable, el producto cloud se hace realidad.

Por ello, la red en una nube de IA no puede considerarse un mero accesorio del cómputo. En la arquitectura empresarial tradicional, la red suele describirse como el sistema que conecta servidores; en la IA distribuida, la red participa directamente en el cálculo efectivo. Una tarea síncrona puede ralentizarse por un módulo óptico degradado, un acelerador con rendimiento anómalo, un carril congestionado o una ruta de almacenamiento que no sigue el ritmo. Mientras la tarea espera, los costes de financiación y uso del hardware costoso siguen acumulándose.

Por tanto, el diseño de la red influye tanto en los benchmarks como en si cada hora de GPU financiada genera valor.

CoreWeave merece ser estudiado porque muestra esta relación con especial claridad. La empresa se centra en la infraestructura de aceleradores, en lugar de tratar las GPU como un servicio más dentro de un catálogo cloud generalista, por lo que sus materiales públicos analizan con cierto detalle las redes de rack, las DPU, la orquestación bare-metal, los superordenadores gestionados, las conexiones dedicadas y la reparación de averías. Estos materiales evidencian la intención de diseño y la arquitectura del producto, pero no constituyen un mapa completo de cada instalación, cada generación de hardware y cada despliegue de cliente.

La pregunta realmente útil no es si CoreWeave tiene, en abstracto, «una red más rápida», sino cuántos tipos de red deben funcionar conjuntamente antes de que una carga de trabajo de IA se convierta en un servicio fiable, y quién controla cada capa.

¿Qué significa realmente la «pila de red de CoreWeave»?

Es un término editorial, no una entidad jurídica independiente ni un SKU que se venda por separado. La entidad legal y económica operativa es CoreWeave, Inc., sociedad de Delaware con sede en Livingston, Nueva Jersey, que cotiza en Nasdaq con el símbolo CRWV. La pila de red forma parte de la CoreWeave Cloud Platform, que también incluye servicios de cómputo, almacenamiento, orquestación y gestionados.

Los distintos nombres corresponden a diferentes capas. Nimbus es la arquitectura de red virtual basada en DPU de CoreWeave. CoreWeave Kubernetes Service (CKS) ofrece Kubernetes gestionado sobre bare-metal. SUNK empaqueta infraestructura y operaciones como servicio de supercomputación gestionada. Mission Control añade monitorización, reparación y gestión del ciclo de vida. Direct Connect proporciona conexiones de cliente dedicadas. NVLink, NVSwitch, Quantum, Spectrum-X y BlueField son tecnologías de NVIDIA integradas por CoreWeave, no protocolos o hardware inventados por la propia CoreWeave.

Separar estas capas evita dos errores comunes. El primero es atribuir a CoreWeave todos los protocolos y dispositivos de la plataforma; la contribución de la empresa reside principalmente en la integración de sistemas, la validación, las operaciones y la construcción de software cloud alrededor de las tecnologías de los proveedores. El segundo es imaginar una red unificada que se extiende desde cada GPU hasta cada cliente.

Los enlaces scale-up dentro del rack, la red de entrenamiento entre racks, la red de almacenamiento, la superposición de VPC, las rutas de gestión y la red troncal transatlántica cumplen funciones distintas, con diferentes objetivos de latencia y dominios de fallo, y no pueden resumirse en una única cifra de ancho de banda.

La misma distinción se aplica a la propiedad de los activos. CoreWeave despliega y opera una gran cantidad de equipos, pero los documentos de la empresa también describen alquileres, centros de datos de terceros, compromisos de energía, colaboraciones de fibra y financiación de equipos. Un servicio puede estar altamente integrado desde el punto de vista operativo sin que ello signifique que CoreWeave sea propietaria de los edificios, los servicios públicos, cada línea de larga distancia o cada componente del rack. La «integración vertical» solo tiene sentido cuando denota coordinación entre capas, y no equivale a la autosuficiencia total.

De Atlantic Crypto a una nube de cómputo especializada

CoreWeave se fundó en 2017 con el nombre de The Atlantic Crypto Corporation, y en sus inicios utilizaba GPU para ejecutar cargas de trabajo de criptomonedas. La empresa pasó de ser una LLC a una corporación de Delaware en septiembre de 2018, y en diciembre de 2019 cambió su nombre a CoreWeave, orientándose hacia el cómputo cloud especializado.

Esta historia se resume a veces como un relato de contraste de «minería a IA», pero la continuidad más importante es la capacidad operativa. Ambos tipos de negocio exigen a las empresas adquirir aceleradores, obtener energía, mantener hardware de alta densidad y dirigir las tareas hacia recursos infrautilizados. CoreWeave aprendió la economía de adquisición y utilización de carteras de aceleradores antes de construir una plataforma cloud completa.

Esta distinción es crucial, porque los cambios en la demanda no generan automáticamente una plataforma cloud. Las cargas de minería suelen ser relativamente repetitivas y toleran una planificación de activos simple; los efectos visuales, el aprendizaje automático y la HPC requieren software, movimiento de datos, aislamiento y garantías de servicio diferentes. CoreWeave tuvo que añadir todo un plano de control para que los clientes externos pudieran confiar en recursos que no les pertenecían y que no podían inspeccionar directamente.

A principios de la década de 2020, la empresa creó servicios de cómputo especializado, almacenamiento y Kubernetes. El Kubernetes bare-metal se convirtió en una de las interfaces principales: los clientes podían programar contenedores directamente en los servidores aceleradores, sin pasar primero por una capa de máquinas virtuales tradicional. A finales de 2023, CoreWeave declaró operar 10 centros de datos y unos 70 MW de energía en servicio; a finales de 2024, la cifra había aumentado a 32 centros de datos y más de 360 MW.

La expansión cambió la naturaleza del problema de red. Un operador con diez centros aún puede depender en gran medida de la experiencia de expertos y excepciones locales; una nube con treinta o cuarenta centros necesita diseños replicables, políticas controladas por software, validación unificada, monitorización compartida y la capacidad de migrar clientes entre generaciones de hardware sin romper la coherencia operativa.

La escala transforma las decisiones de ingeniería en cuestiones de gobernanza: quién puede aprobar cambios, cuánto tardan en detectarse las excepciones y si cada nuevo centro replica realmente el perímetro de control previsto.

CoreWeave completó su OPV en marzo de 2025. La salida a bolsa no solo aportó capital social, sino también el folleto de emisión y los documentos presentados ante la SEC, lo que ha permitido al público conocer las instalaciones, la concentración de clientes, la deuda, los alquileres, la arquitectura de interconexión y los riesgos. La pila de red puede analizarse, por tanto, como sistema técnico y como conjunto de compromisos de capital de una empresa cotizada.

La carga de trabajo determina la arquitectura

El entrenamiento de modelos grandes distribuye el cómputo entre múltiples aceleradores e intercambia resultados parciales de forma continua. Los patrones de comunicación concretos dependen de la arquitectura del modelo, el tipo de paralelismo y el software, pero el problema de infraestructura es relativamente estable: la velocidad efectiva del conjunto de recursos depende tanto del cómputo local como de la comunicación colectiva. Aunque una red tenga un alto rendimiento agregado, si la congestión, la topología o la latencia de cola ralentizan los puntos de sincronización, se desperdiciará costosa capacidad de cálculo.

La plataforma también debe transportar tráfico que no presenta las características de la comunicación colectiva. Los conjuntos de datos entran en el entorno, los checkpoints se escriben desde la memoria de las GPU al almacenamiento, los sistemas de control distribuyen tareas y políticas, los ingenieros extraen logs, los servicios de inferencia exponen endpoints al exterior, y las copias de seguridad y réplicas pueden moverse entre regiones. Estos distintos tipos de tráfico toleran la latencia y la pérdida de paquetes de manera diferente.

Si se tratan como una red indiferenciada, el rendimiento se vuelve impredecible y los fallos difíciles de aislar.

De ahí surge un diseño por capas: los enlaces scale-up crean dominios estrechamente acoplados dentro de los sistemas a nivel de rack; la red scale-out conecta diferentes racks; las rutas de almacenamiento suministran datos a las cargas de trabajo y guardan el estado; la red de inquilinos proporciona direccionamiento privado y políticas; la red de gestión permite al operador controlar hosts, DPU, conmutadores y procesos de reparación; la red troncal conecta los centros con el ecosistema externo; y las líneas de cliente dedicadas unen CoreWeave con otros dominios administrativos.

Estas capas interactúan, pero no pueden sustituirse entre sí. La fibra de larga distancia no puede reemplazar la red local de GPU, porque el retardo de propagación ya limita el entrenamiento fuertemente sincronizado entre centros distantes; un dominio NVLink no es una VPC de cliente; una superposición (overlay) puede ocultar diferencias de direccionamiento, pero no puede reparar un módulo óptico dañado en la infraestructura subyacente; y sin plugins de dispositivo e información de topología, Kubernetes no comprenderá automáticamente cada carril y cada ruta de conmutación.

Por tanto, esta arquitectura es en esencia una «cadena de traducción de intenciones». El cliente solicita un clúster, un espacio de nombres, una red o una tarea; el sistema de control de CoreWeave asigna la solicitud a servidores, redes, almacenamiento y políticas disponibles; Nimbus traduce la intención de la VPC al estado de la DPU y la infraestructura subyacente; los servicios relacionados con Kubernetes y Slurm traducen la intención de la carga de trabajo a asignaciones de nodos y aceleradores; y Mission Control transforma las señales de salud en acciones de reparación.

El cliente ve un servicio, y la plataforma debe mantener la coherencia de todas esas traducciones.

Redes scale-up dentro del dominio a nivel de rack

Las redes scale-up conectan aceleradores dentro de un sistema altamente integrado. En los diseños a escala de rack de NVIDIA, NVLink proporciona comunicación de alto ancho de banda entre GPU, y NVSwitch actúa como conmutador en el dominio local. CoreWeave integra estas tecnologías en determinados sistemas y generaciones.

Lo clave no es solo la marca, sino la proximidad física. El dominio scale-up permite que el particionado de modelos y la comunicación colectiva no tengan que atravesar la red de centro de datos convencional en cada paso, haciendo que un rack se asemeje más a un gran sistema acelerador que a un conjunto de servidores independientes. Al mismo tiempo, también crea un dominio de fallo autónomo: un problema en un conmutador, cable, sistema de refrigeración o componente dentro del rack puede afectar simultáneamente a varias GPU que el planificador consideraba que debían trabajar juntas.

El folleto de emisión de CoreWeave describía que algunas configuraciones de clúster pueden ofrecer hasta 3200 Gbps de ancho de banda de interconexión de GPU sin bloqueo. «Algunas configuraciones de clúster» es la salvedad más importante. Esta cifra no es un ANS general ni describe todos los centros o generaciones. El ancho de banda real que obtiene una carga de trabajo depende también del software, la topología, el patrón de mensajes y el estado de salud de la ruta completa.

El scale-up alivia un cuello de botella, pero también aumenta la densidad en otros lugares. Más aceleradores y mayor ancho de banda local incrementan los requisitos de potencia, refrigeración y mantenimiento del rack. Si la densidad de cómputo aumenta sin que el diseño térmico y operativo avance al mismo ritmo, el sistema puede volverse más difícil de reparar y puede trasladar el cuello de botella a la red scale-out y al almacenamiento. La arquitectura debe entenderse como un equilibrio entre componentes, no como una lista de especificaciones máximas.

Red scale-out: InfiniBand y Ethernet coexisten

Cuando una tarea sale del dominio scale-up, entra en la red scale-out. Los documentos y materiales técnicos de CoreWeave mencionan NVIDIA Quantum-2 InfiniBand, la red Quantum-X800 XDR de 800G, y Spectrum-X Ethernet con RoCE y RDMA. La coexistencia de InfiniBand y Ethernet es relevante: CoreWeave no ha bloqueado la plataforma a una única familia de protocolos.

InfiniBand para clústeres fuertemente acoplados

InfiniBand está orientado a comunicaciones de baja latencia y acceso directo a memoria remota, y tiene un largo recorrido en HPC. En los clústeres de IA, puede reducir la sobrecarga de procesamiento del host y mover datos entre hosts aceleradores. Los sistemas NVIDIA Quantum proporcionan además capacidades de conmutación y comunicación colectiva. CoreWeave integra estas redes en sus servicios de clúster, en lugar de vender InfiniBand como un servicio de telecomunicaciones independiente.

Los materiales públicos no revelan todas las topologías, las ratios de sobresuscripción, las políticas de enrutamiento adaptativo ni los límites del servicio al cliente. El término «sin bloqueo» puede aplicarse solo a un diseño concreto, no a toda la flota. Incluso una red bien diseñada puede degradarse por módulos ópticos envejecidos, colocación inadecuada de tareas, desequilibrios de tráfico o puntos calientes de software. El comprador debe preguntar qué generación de hardware, qué topología y qué proceso de validación se aplican al clúster que va a utilizar.

Spectrum-X y RoCE: la ruta Ethernet

Spectrum-X es la plataforma de red Ethernet de NVIDIA orientada a IA. RoCE transporta semántica RDMA sobre Ethernet, permitiendo que las aplicaciones realicen comunicación directa de memoria mientras el operador conserva una red Ethernet. CoreWeave utiliza Spectrum-X para ofrecer otra ruta scale-out para cargas de trabajo y generaciones de hardware diseñadas en torno a ese ecosistema.

Conocer Ethernet no equivale a tener una operación sencilla. El rendimiento de RoCE depende del control de congestión, el diseño de colas, el comportamiento ante pérdidas, la telemetría y la optimización extremo a extremo. La red puede utilizar tramas Ethernet familiares, pero sigue necesitando ingeniería especializada para evitar bloqueos de cabecera de cola, incast o inestabilidad en la comunicación colectiva. El valor de la nube integrada es transferir al proveedor gran parte de la responsabilidad de optimización; el riesgo correspondiente es que el cliente carezca de visibilidad directa sobre esas decisiones.

Topologías optimizadas por carriles y colocación de tareas

Los sistemas de múltiples carriles agrupan las NIC y los aceleradores correspondientes para que el tráfico colectivo circule por rutas paralelas relativamente regulares. La optimización por carriles puede reducir el tráfico cruzado innecesario y hacer el ancho de banda más predecible, pero exige que el planificador comprenda la topología física; una combinación incorrecta de nodos anula las ventajas del diseño.

Los carriles también concentran los fallos. Si un carril se degrada, todos los nodos que lo utilizan pueden convertirse en rezagados, incluso si las demás interfaces siguen estando en buen estado. El sistema operativo debe distinguir entre el fallo de un único servidor y un fallo de red compartido. Por eso la telemetría de topología, la validación y la reparación son tan importantes como la velocidad de los puertos.

Nimbus desplaza el límite de la nube a la DPU

Una red de clúster de alto rendimiento no crea automáticamente una nube multiinquilino. Los clientes también necesitan direccionamiento privado, control de enrutamiento, acceso a Internet y aislamiento. La respuesta de CoreWeave es Nimbus: una arquitectura de red virtual que descarga las funciones de VPC en la DPU. La documentación pública menciona las DPU NVIDIA BlueField-3 y describe VRF, VXLAN y enrutamiento EVPN Tipo 5 en la arquitectura de seguridad.

La DPU se sitúa entre el cómputo controlado por el cliente y la infraestructura controlada por el proveedor, una posición muy delicada. Puede gestionar el tráfico de red virtual, aplicar la segmentación y liberar la CPU del host para las cargas de trabajo; también puede situar el límite de aislamiento de los inquilinos fuera del sistema operativo que el cliente podría controlar. De ahí que sea tanto una decisión de rendimiento como de seguridad.

Cómo se compone la superposición de VPC

Los VRF separan un dominio de enrutamiento de otro; VXLAN transporta los segmentos de red de los inquilinos sobre una infraestructura física compartida; EVPN distribuye la alcanzabilidad, y las rutas Tipo 5 permiten anunciar prefijos IP, no solo direcciones MAC. La combinación de estos mecanismos permite a CoreWeave ofrecer redes privadas sobre una infraestructura física compartida.

La superposición no elimina la dependencia de la infraestructura subyacente. Cuando falla la alcanzabilidad física, la red virtual también falla; los errores de distribución de rutas pueden destruir el aislamiento o la conectividad a gran escala; un fallo en la imagen de la DPU o en el sistema de políticas puede propagar estados incorrectos rápidamente a un gran número de hosts. La abstracción cloud traslada la complejidad del lado del cliente al lado del proveedor, pero no la hace desaparecer.

La DPU como parte de la raíz de confianza

Nimbus separa mejor las funciones de red del proveedor del host del cliente, pero también eleva la importancia del firmware de la DPU, el arranque seguro, las claves, la distribución de políticas, los registros y la recuperación. Un dispositivo que aplica el aislamiento debe ser observable y reparable, y al mismo tiempo no debe convertirse en una vía descontrolada hacia los entornos de los inquilinos.

Este límite de control también afecta a la resolución de incidencias. Un problema de conectividad puede originarse en la carga del cliente, las políticas de Kubernetes, la configuración de VPC, el software de la DPU, el plano de control EVPN o la red física. El equipo de soporte necesita pruebas entre capas sin permitir que un inquilino vea los datos de otro. Los materiales públicos explican el diseño previsto, pero no ofrecen registros de fallos de aislamiento ni tiempos de reparación verificados de forma independiente en toda la flota.

Kubernetes bare-metal es el plano de control del cliente

CoreWeave Kubernetes Service ofrece Kubernetes gestionado sobre infraestructura bare-metal, evitando la capa de máquinas virtuales tradicional entre la plataforma de contenedores y los servidores GPU. Cada clúster recibe su propia VPC e integra redes de alto rendimiento y almacenamiento para cargas de trabajo distribuidas.

El bare-metal elimina un nivel de abstracción, pero no equivale a simplicidad. Kubernetes sigue necesitando descubrir las GPU, exponer dispositivos, aplicar cuotas, ubicar pods y colaborar con los plugins de red y almacenamiento. La plataforma debe coordinar las imágenes de nodo, los controladores, el firmware, el runtime de contenedores y las actualizaciones del clúster con las generaciones de hardware subyacentes. El cliente obtiene una API familiar, mientras que CoreWeave asume una matriz de compatibilidad más compleja.

Lo que Kubernetes puede decidir y lo que no

Kubernetes puede decidir dónde colocar los pods basándose en la información y las políticas que maneja el planificador, pero no entiende automáticamente cada carril, módulo óptico, ruta de conmutación o estado de la comunicación colectiva. CoreWeave necesita añadir plugins de dispositivo, operadores, información de topología y controles operativos para que la planificación lógica coincida con los recursos físicos viables.

Las políticas de red también tienen su alcance. Las políticas de Kubernetes pueden restringir el tráfico entre cargas de trabajo, mientras que la VPC y la DPU proporcionan límites más amplios de inquilino y enrutamiento. La existencia de un objeto de política no garantiza que la ruta real de los paquetes aplique las reglas previstas; la configuración, la implementación y la observabilidad deben ser coherentes.

SUNK convierte los clústeres en supercomputadoras gestionadas

SUNK se presenta como un servicio de supercomputación gestionada de grado de producción, que combina infraestructura, redes de alto rendimiento, orquestación de cargas de trabajo y las operaciones de CoreWeave para clientes que desean entornos dedicados a gran escala sin tener que construir sus propias instalaciones y equipos de operaciones completos.

Esto modifica el reparto de responsabilidades. El cliente sigue siendo responsable de la arquitectura del modelo, el código, los datos y la estrategia de tareas, mientras que una mayor parte del ciclo de vida del hardware, la validación del clúster y la gestión de fallos se transfiere a CoreWeave. Se asemeja más a una instalación de HPC gestionada, entregada mediante contratos y software de la era cloud, que a un conjunto de instancias completamente intercambiables.

Mission Control convierte las operaciones en producto

Mission Control añade monitorización, mantenimiento, reparación y soporte del ciclo de vida. Cuanto mayor es la tarea, más relevante se vuelve: sustituir un componente en un conjunto pequeño de servidores tiene un impacto limitado; diagnosticar un enlace degradado en un conjunto de recursos altamente sincronizado puede determinar si miles de horas de acelerador generan valor.

Los materiales de CoreWeave describen monitorización proactiva e intervenciones operativas, lo que demuestra una intención, pero no constituye una verificación independiente del tiempo de actividad ni ofrece una distribución pública de los tiempos medios de reparación. Dado que la fiabilidad es un motivo importante para que los clientes elijan un proveedor en lugar de construir sus propios clústeres, la falta de un historial completo de incidentes es en sí misma un límite informativo relevante.

El almacenamiento es parte del cómputo en red

Los datos de entrenamiento, los checkpoints y los artefactos del modelo pasan por rutas de almacenamiento que pueden limitar toda la carga de trabajo. Incluso si el ancho de banda entre GPU es muy alto, si la lectura de entrada, la escritura de checkpoints o la recuperación del estado no son lo suficientemente rápidas, el clúster se detendrá. La plataforma de CoreWeave incluye almacenamiento de objetos y archivos, y describe el movimiento de datos de alto rendimiento como parte del servicio.

El tráfico de checkpoints presenta un patrón especial. Muchos workers pueden guardar estado al mismo tiempo, generando ráfagas distintas a la comunicación colectiva. Si el almacenamiento comparte recursos físicos con la red de entrenamiento, se necesitan mecanismos de aislamiento o planificación de capacidad; si utiliza una red independiente, la plataforma aún debe coordinar los fallos y la recuperación en ambas rutas.

El almacenamiento también afecta a la migrabilidad. Migrar un modelo a CoreWeave puede requerir transferir grandes volúmenes de datos desde otras nubes o entornos privados; la salida puede generar costes, tiempo y fricciones contractuales. «Zero Egress Migration» es un mecanismo comercial que CoreWeave utiliza para reducir ciertos costes de entrada, no una garantía de rendimiento técnico, y no implica que todo el tráfico de salida sea gratuito ni que el movimiento de datos no tenga costes operativos.

Por tanto, los clientes deben exigir evidencia de extremo a extremo. Los resultados máximos de acelerador o red son valiosos, pero las tareas de producción también incluyen preparación de datos, checkpoints, registro de modelos, registros y recuperación. Un benchmark que solo pruebe una capa no puede responder cuándo se completa la tarea completa ni cuál es el coste total.

La red troncal conecta regiones, no es una supercomputadora síncrona

CoreWeave describe una red troncal de calidad de operador que conecta centros de datos en Norteamérica y Europa mediante fibra terrestre y submarina, y ofrece peering directo y conexiones dedicadas. Los documentos de la empresa mencionan Direct Connect de 10, 100 y 400 Gbps, según el centro y la disponibilidad.

La red troncal cumple una función distinta a la red scale-out local. Puede transportar conjuntos de datos, réplicas, checkpoints, tráfico de control e inferencia, conectar usuarios y otras nubes, y facilitar la recuperación y la distribución. El retardo de propagación de larga distancia determina que no pueda convertir centros remotos en una red de clúster de baja latencia para entrenamiento fuertemente sincronizado.

Las conexiones dedicadas reducen un tipo de incertidumbre

Los circuitos dedicados pueden reducir las fluctuaciones de enrutamiento de la Internet pública y ofrecer límites más claros de capacidad y soporte, pero no crean un mundo completamente privado de extremo a extremo. El acceso del cliente puede depender de operadores, cross-connects y operadores de centros de datos; las conexiones a la nube tienen sus propios procesos de aprobación y configuración; y no se ha revelado completamente la diversidad de enrutamiento ni la propiedad de los activos en cada ubicación.

Por tanto, no se puede calificar a CoreWeave como un operador Tier 1. La empresa opera una red troncal y participa en peering, pero la evidencia disponible no permite afirmar que tenga alcance global libre de liquidación ni que sea propietaria de todas las rutas de fibra. Su ventaja es la conexión profunda con sus propios recursos de cómputo, no la sustitución del ecosistema mundial de telecomunicaciones.

El diseño regional crea disponibilidades diferentes

A finales de 2025, CoreWeave tenía instalaciones en seis países. Esta cifra no implica que cada generación de aceleradores, red, servicio o velocidad de línea dedicada esté disponible en todos los países. Las regiones se activan por fases, ya que la energía, la refrigeración, la red, el hardware y la aceptación operativa no se completan simultáneamente.

La geografía no solo afecta a la latencia, sino también a la gobernanza de datos, la proximidad a otras nubes, el personal, las fuentes de energía, la correlación de fallos y quién controla las rutas locales. Para CoreWeave, cada nuevo país añade coordinación legal, de servicios públicos y de cadena de suministro. La expansión de la red es un modelo operativo, no un mapa de cajas homogéneas.

La fiabilidad convierte el capital en tiempo efectivo

Tanto si las tareas se ejecutan como si esperan, los costes de financiación del hardware de CoreWeave siguen acumulándose. Por eso, la fiabilidad es una variable financiera. Los fallos en la red, la degradación de las GPU, las interrupciones del almacenamiento o los errores de planificación reducen la producción facturable y efectiva, mientras que los intereses, los alquileres y las obligaciones de energía no se detienen.

Los rezagados son más difíciles de gestionar que los fallos totales

Un nodo completamente caído es fácil de detectar, pero un rezagado puede permanecer marcado como en línea mientras ralentiza cada punto de sincronización. Las tareas grandes necesitan telemetría que detecte la degradación del rendimiento, no solo un estado de salud binario. Los planificadores y los equipos de operaciones deben decidir si vaciar, sustituir o seguir utilizando el componente.

La información pública no revela completamente las tasas de fallo de las tareas, la latencia de cola ni la distribución de rezagados. Esto no demuestra que la fiabilidad sea mala, pero limita las comparaciones independientes. Los clientes deben basarse en los contratos, las pruebas de carga y su propia evidencia operativa, y no deducir conclusiones directamente de los diagramas de arquitectura.

La validación es una prueba del sistema

Antes de abrir un clúster a los clientes, CoreWeave debe validar conjuntamente servidores, conmutadores, módulos ópticos, cables, firmware, controladores, almacenamiento y orquestación. Que arranque no es suficiente; la prueba significativa es si la topología completa puede soportar de manera sostenida las cargas de trabajo previstas, recuperarse tras un fallo y hacerlo sin que las reparaciones generen nuevas incoherencias.

La validación también cambia con el tiempo. Una combinación de software y firmware que pasa las pruebas no garantiza que siga siendo idéntica tras una actualización. La rápida llegada de nuevas generaciones de NVIDIA obliga a CoreWeave a soportar más combinaciones mientras sigue prestando servicio a los entornos de los contratos antiguos. La madurez operativa consiste en mantener la coherencia en medio de esa superposición, no en convertir cada centro en un caso especial.

La financiación también es una capa de la arquitectura

Los ingresos de CoreWeave en 2025 fueron de 5100 millones de dólares, con una pérdida neta de 1200 millones, un gasto de caja en compra de activos fijos de 10 300 millones durante el año y obligaciones de desempeño pendientes por 60 700 millones al cierre del ejercicio. El mismo documento revelaba también importantes operaciones de financiación de equipos, deuda, alquileres y compromisos de infraestructura.

Estas cifras tienen significados distintos. Los ingresos son servicios ya reconocidos; el flujo de caja por compra de activos fijos es inversión, no una valoración de toda la flota; la pérdida neta indica que el alto crecimiento aún no ha generado beneficios consolidados; y las obligaciones de desempeño pendientes representan compromisos contractuales futuros según las normas contables, no efectivo en el banco ni servicios ya prestados.

El primer trimestre de 2026 muestra a la vez demanda y costes de tenencia

En el trimestre finalizado el 31 de marzo de 2026, CoreWeave declaró ingresos de 2078 millones de dólares, una pérdida neta de 740 millones y un gasto por intereses de 536 millones, y comunicó una cartera de pedidos (backlog) de 99 400 millones según su propia definición. La visibilidad de la demanda y los elevados costes de financiación se dieron simultáneamente en el mismo trimestre.

La cartera de pedidos y las obligaciones de desempeño pendientes de fin de año no son directamente intercambiables, ya que difieren en definición y momento de referencia. Ambos apuntan a demanda contractual futura, pero para convertirla en ingresos, CoreWeave debe poner primero en marcha instalaciones, energía, hardware y red, y luego ejecutar los contratos. Cuanto mayor es la cartera, mayores son las obligaciones de entrega asociadas.

La financiación con garantía de GPU vincula activos y contratos

CoreWeave utiliza préstamos garantizados, financiación de equipos y estructuras respaldadas por clientes para expandirse. En junio de 2026, la empresa anunció una operación de financiación de 8500 millones de dólares, calificando la transacción como respaldada por GPU y con calificación de grado de inversión. Esto amplía la capacidad de despliegue, pero no es ingreso ni significa que toda la deuda de la empresa tenga calificación de grado de inversión.

La financiación de activos puede alinear deuda, hardware y flujos de caja contractuales, pero también restringe la garantía, el despliegue y el uso de los fondos. Los aceleradores, conmutadores y módulos ópticos se deprecian más rápido que los activos de infraestructura tradicionales. El modelo es más robusto solo cuando la utilización es alta y los contratos con los clientes cubren el período de mayor valor económico del equipo.

Por tanto, el diseño de la red influye en la calidad crediticia. Una topología que mejore la utilización aumentará la producción de los activos financiados; los retrasos en los centros, los problemas crónicos de rezagados o los fallos en las migraciones reducirán esa producción. Para CoreWeave, la ingeniería de sistemas y la ingeniería del balance son el mismo problema.

La concentración de clientes también es una dependencia de infraestructura

Microsoft representó el 67 % de los ingresos de CoreWeave en 2025. Un cliente ancla puede validar la demanda, respaldar la financiación y permitir al proveedor aprovisionarse por adelantado, pero también refuerza el poder de negociación del cliente y hace que la utilización sea muy sensible a una única relación comercial.

CoreWeave también ha revelado o anunciado relaciones con clientes como Meta y Anthropic. Flow Traders eligió CoreWeave en julio de 2026 para entrenar modelos fundacionales; Leidos anunció una colaboración para proporcionar IA para misiones de defensa, seguridad nacional e inteligencia. Las fuentes pertinentes acreditan los contratos, elecciones o colaboraciones descritos, pero no demuestran que la concentración haya desaparecido ni que toda la capacidad anunciada esté ya en producción.

Los contratos de tipo take-or-pay transfieren el riesgo, pero no lo eliminan

Los contratos plurianuales de tipo take-or-pay mejoran la visibilidad de la demanda y pueden respaldar la financiación. Transfieren parte del riesgo de utilización al cliente, ya que los pagos no dependen enteramente del consumo a corto plazo; sin embargo, los riesgos de construcción, energía, entrega, rendimiento, crédito y renegociación persisten.

Para el cliente, este tipo de contrato invierte parte de la promesa de la nube. La nube pública tradicional hace hincapié en la elasticidad y el bajo compromiso; los clústeres de IA dedicados pueden exigir relaciones a más largo plazo, similares a las de un proyecto de infraestructura, porque el proveedor ha construido o reservado capacidad específica para el cliente. La interfaz se parece al software de la nube, pero la economía subyacente se asemeja más a la financiación de proyectos.

Las cargas de defensa y reguladas elevan el listón de la garantía

La colaboración con Leidos, anunciada el 30 de julio de 2026, lleva la plataforma hacia misiones de defensa e inteligencia. La colaboración en sí no demuestra que se hayan obtenido todas las autorizaciones, certificaciones y aprobaciones de despliegue, pero indica que el control de la cadena de suministro, las auditorías, la seguridad de la información y la continuidad operativa pueden convertirse en componentes aún más importantes del producto.

Las VPC forzadas por DPU, las conexiones dedicadas y las operaciones gestionadas pueden respaldar diseños de alta garantía, pero no sustituyen los controles específicos del proyecto, los requisitos de personal, las normas de tratamiento de datos ni las aprobaciones gubernamentales. Cuanto más se acerque a cargas sensibles para la misión, más transparentes deben ser los límites de responsabilidad.

Las adquisiciones de software se extienden hacia arriba, mientras que la fusión fallida apunta a las instalaciones físicas

En 2025, CoreWeave adquirió Weights & Biases, OpenPipe, marimo y Monolith AI. Weights & Biases añade herramientas de desarrollo y observabilidad de modelos; las otras operaciones amplían las capacidades de inferencia, notebooks e IA industrial. Esto extiende a la empresa desde la infraestructura hacia los niveles superiores del ciclo de vida del desarrollo.

La lógica estratégica es clara: un proveedor que comprenda mejor los flujos de trabajo de los modelos puede predecir mejor la demanda, reducir la dificultad de uso de la infraestructura y retener a los clientes en más etapas. Los riesgos de integración son igualmente claros: los ciclos de lanzamiento, la estructura de márgenes y la cultura del negocio del software difieren de los de los centros de datos intensivos en capital. Si CoreWeave intenta poseer herramientas que los clientes antes obtenían de proveedores independientes, pueden surgir solapamientos de productos y conflictos con socios.

La adquisición propuesta de Core Scientific apuntaba a la capa física. CoreWeave anunció un acuerdo de fusión en julio de 2025 con la intención de reforzar el control sobre la capacidad de los centros de datos y la economía de los alquileres. Core Scientific dio por terminado el acuerdo el 30 de octubre de 2025 tras la votación de sus accionistas. CoreWeave no adquirió Core Scientific.

Los dos tipos de operaciones muestran una integración bidireccional: hacia arriba, hacia el software para desarrolladores, y hacia abajo, hacia el control de la capacidad física. La fusión fallida también ilustra que el control de la infraestructura no siempre puede comprarse al ritmo que desearía una plataforma tecnológica; los accionistas, la regulación, la financiación y las estructuras contractuales pueden bloquear la integración vertical.

Lo que CoreWeave puede controlar y lo que no

CoreWeave controla la plataforma del cliente, muchas decisiones de diseño, la validación de equipos, la orquestación y los procesos operativos. Puede decidir cómo Nimbus mapea las VPC, cómo se presentan los clústeres, qué servicios son gestionados por la empresa y cómo se tratan los incidentes; también puede aprovisionar hardware por adelantado y organizar las instalaciones en torno a la densidad de aceleradores.

NVIDIA controla las hojas de ruta clave de las GPU, NVLink, InfiniBand, Spectrum-X y BlueField. Las empresas de servicios públicos y los socios de centros de datos controlan parte del suministro de energía y la ejecución de las instalaciones; los operadores de fibra, los puntos de intercambio y las nubes controlan la conectividad externa; los prestamistas y las entidades de financiación de equipos condicionan el capital; y los grandes clientes influyen en la planificación de capacidad a través de los contratos.

No es un defecto exclusivo de CoreWeave; todas las nubes dependen de la cadena de suministro. La razón por la que es especialmente relevante es que la diferenciación de CoreWeave está estrechamente ligada al rápido despliegue de los nuevos sistemas de NVIDIA, y los compromisos de capital son muy elevados en relación con la historia operativa de la empresa. Un retraso o un cambio en la hoja de ruta de un proveedor puede repercutir en las entregas a los clientes y en la financiación.

La ventaja de la plataforma es coordinar estos límites; el riesgo es la dependencia correlacionada: una misma generación de productos de proveedor, un mismo diseño de centro o un mismo plan de cliente pueden afectar a múltiples capas simultáneamente. La integración reduce el número de contratos que el cliente debe gestionar, pero puede amplificar el impacto de un fallo a nivel de proveedor.

Posición competitiva: la nube especializada como elección de asignación de responsabilidades

CoreWeave compite con las nubes a hiperescala, otras nubes especializadas en GPU, los clústeres propios de los clientes y las combinaciones de colocation, hospedaje e integración. La comparación no puede limitarse al número de GPU o a un único benchmark; los compradores comparan generaciones de hardware, redes, almacenamiento, planificación, líneas dedicadas, soporte, duración de los contratos, geografía y coste total del movimiento de datos.

Comparación con las nubes a hiperescala

AWS, Microsoft Azure, Google Cloud y Oracle ofrecen una gama más amplia de servicios, un ecosistema global y balances más grandes, y pueden combinar la infraestructura de IA con bases de datos, seguridad, analítica y compras empresariales. La respuesta de CoreWeave es la especialización: introducir más rápidamente determinadas generaciones de NVIDIA, utilizar orquestación bare-metal y diseñar la plataforma en torno a cargas de aceleradores de alta densidad.

La especialización puede reducir las abstracciones y acelerar la validación, pero también genera un perfil de proveedor y de fallo más estrecho. El cliente obtiene un proveedor más enfocado, pero acepta una menor amplitud de servicios y una estructura de capital más joven. La comparación correcta debe hacerse en función de cargas de trabajo concretas, no de etiquetas sectoriales.

Comparación con otras nubes especializadas

Proveedores como Lambda, Nebius o Crusoe se solapan en aceleradores, clústeres y servicios gestionados, pero difieren en geografía, estrategia energética, cartera de software, propiedad, financiación y control de las instalaciones. «Neocloud» es solo una etiqueta de mercado y no representa una arquitectura común.

Los documentos de empresa cotizada hacen que la escala y los riesgos de CoreWeave sean más transparentes que los de muchos competidores, pero eso no demuestra automáticamente superioridad técnica o económica. Un competidor con menor divulgación puede ser más pequeño, más eficiente o simplemente más opaco. La transparencia no debe convertirse en una clasificación de rendimiento.

Comparación con los clústeres privados propios

Los clústeres propios otorgan al cliente un control directo sobre el hardware, los datos y las operaciones, pero también exigen adquisiciones, energía, instalaciones, red, almacenamiento, seguridad, firmware, repuestos y personal especializado. CoreWeave vende la transferencia de la mayor parte de esa responsabilidad al proveedor.

La transferencia no es completa. El cliente sigue teniendo que diseñar las cargas de trabajo, gestionar los datos, establecer políticas y evaluar el riesgo del proveedor; los compromisos a largo plazo reducen la flexibilidad de migración. El riesgo del clúster propio es la infrautilización interna; el riesgo del contrato cloud es la dependencia del proveedor. La decisión económica es qué parte está mejor capacitada para absorber la volatilidad y mantener productivos unos sistemas costosos.

Los conmutadores refrigerados por líquido muestran hacia dónde puede desplazarse el siguiente cuello de botella

En julio de 2026, CoreWeave presentó una arquitectura de conmutación refrigerada por líquido, afirmando que podía aumentar la densidad de ancho de banda de red por rack. La cifra procede de diseños y cálculos propios de la empresa, no de un benchmark independiente de toda la flota, pero el mecanismo es relevante: a medida que aumenta la densidad de aceleradores, el consumo y el calor de los conmutadores y los módulos ópticos pueden convertirse en el factor limitante del rack.

Refrigerar los conmutadores con líquido permite alojar más capacidad de red dentro de la potencia y el espacio limitados del rack, y puede acortar el cableado; al mismo tiempo, el mantenimiento de la red queda más estrechamente acoplado al sistema de refrigeración líquida. Las fugas, los fallos de las bombas o los procedimientos de reparación pueden afectar a componentes de red que antes se trataban como equipos ordinarios refrigerados por aire.

Esto ilustra cómo se desplazan los cuellos de botella en la infraestructura de IA. Unas GPU más rápidas exigen mayor ancho de banda scale-up; un mayor ancho de banda de rack requiere conmutación scale-out más densa; una conmutación más densa conlleva mayores demandas de energía y refrigeración; y las nuevas instalaciones deben adoptar diseños electromecánicos diferentes. Una actualización de producto puede convertirse en un rediseño completo del centro de datos.

Vera Rubin es una transición futura, no una descripción de la flota ya instalada

Los materiales de CoreWeave de julio de 2026 describen la preparación para NVIDIA Vera Rubin NVL72 y ofrecen mediciones de tokens por megavatio en comparación con Blackwell, así como afirmaciones prospectivas. Estas afirmaciones deben atribuirse a CoreWeave y a configuraciones específicas, y no pueden considerarse como la disponibilidad de toda la flota en el momento del estudio.

Una nueva generación modifica simultáneamente aceleradores, scale-up, scale-out, potencia del rack, refrigeración, firmware, controladores, orquestación y validación. Puede mejorar la producción por MW, pero también puede dejar instalaciones antiguas inadecuadas o menos competitivas. La rápida introducción de nuevo hardware por parte de CoreWeave solo es una ventaja si puede gestionar la migración, la utilización y la depreciación de los activos antiguos.

Esto también profundiza la dependencia de NVIDIA. El acceso temprano puede atraer clientes y contratos de alto valor, pero expone a CoreWeave a las decisiones del proveedor en materia de calendarios, precios y arquitectura. La diversificación en la capa de clientes o de software no conlleva automáticamente la diversificación de la pila física.

Implicaciones para la infraestructura digital en general

La expansión de CoreWeave afecta mucho más que al alquiler de GPU. Los compromisos a escala de gigavatios aumentan la demanda de generación eléctrica, acceso a la red, transformadores, refrigeración, terrenos y construcción; las redes de alta radix incrementan la demanda de conmutadores, módulos ópticos y fibra; las líneas dedicadas aumentan la demanda de operadores, puntos de intercambio y conexiones a la nube; y la financiación exige a los prestamistas evaluar activos tecnológicos que se deprecian rápidamente con contratos a largo plazo.

La plataforma también modifica dónde aparece el tráfico de Internet. El entrenamiento fuertemente acoplado permanece principalmente dentro de la red local, pero los conjuntos de datos, los checkpoints, los artefactos de los modelos, las peticiones de inferencia y los flujos de desarrollo se mueven continuamente entre nubes, centros de datos y usuarios. El impacto visible en Internet puede no ser una gran corriente de entrenamiento, sino más bien los movimientos de datos a largo plazo alrededor de los entornos de entrenamiento.

Para las comunidades y las redes eléctricas que albergan las instalaciones, esto supone una decisión sobre energía y suelo. Los materiales de investigación carecen de datos a nivel de centro para respaldar conclusiones ambientales a escala de toda la empresa, pero sí demuestran que la energía en operación y la contratada son indicadores centrales de crecimiento, y que los retrasos en la energía y las instalaciones constituyen un riesgo de negocio.

Para los ingenieros de red, esta arquitectura muestra que la infraestructura de IA se está convirtiendo en una especialidad propia. Los conocimientos de enrutamiento y conmutación siguen siendo necesarios, pero ahora se entrecruzan con las bibliotecas de comunicación colectiva, la topología de aceleradores, la refrigeración líquida, la planificación y la financiación de proyectos. Quien ajusta la congestión está protegiendo también las tasas de finalización de tareas y la capacidad de servicio de la deuda.

Lo que la evidencia pública no muestra

CoreWeave publica documentación de producto, blogs técnicos y documentos financieros, pero la pila de red sigue siendo parcialmente opaca. Los materiales disponibles no incluyen una topología completa en tiempo real, un inventario de la red por centro, tablas de sobresuscripción, un mapa de propiedad de fibra, un historial completo de incidentes ni un archivo de benchmarks independientes por carga de trabajo.

Este límite debe condicionar la forma de escribir. Los documentos de arquitectura pueden acreditar mecanismos; los documentos presentados a la SEC pueden acreditar finanzas y riesgos consolidados; las noticias de clientes pueden acreditar elecciones o colaboraciones. Pero ninguno de ellos puede demostrar resultados universales de carga de trabajo, un tiempo de actividad de toda la flota o que todos los compradores disfruten de un coste total más bajo.

Con la escala hay que tener la misma prudencia: la energía en operación no es la contratada; la cartera de pedidos no es ingreso; una conferencia de resultados programada no es un resultado financiero; un acuerdo de cliente anunciado no equivale a uso; una adquisición propuesta no es propiedad; y el hardware futuro no es la flota actual.

Estas distinciones no debilitan el artículo, sino que definen las lagunas de información que un lector profesional debe gestionar. CoreWeave pide a clientes e inversores que confíen en un sistema altamente integrado, pero cuyos detalles clave son necesariamente privados. La respuesta racional no es dar por sentada la excelencia o el fracaso, sino exigir evidencia a nivel de contrato, clúster y centro concreto.

Juicio central

El producto de CoreWeave suele describirse como capacidad de cómputo, pero en realidad su producto más profundo es la coordinación: entre las hojas de ruta de los proveedores y la construcción de centros de datos, entre scale-up y scale-out, entre las políticas de DPU y las intenciones de los inquilinos, entre la planificación de Kubernetes y la topología física, entre el almacenamiento y los checkpoints, entre la red troncal y el acceso del cliente, entre la financiación a largo plazo y los ciclos cortos del hardware.

Esta coordinación puede generar una ventaja real. Un proveedor especializado puede tomar decisiones en torno a la carga de trabajo completa, sin exigir al cliente que integre por su cuenta a múltiples proveedores; puede validar sistemas, reparar fallos e introducir nuevas generaciones más rápido que muchas empresas. El rápido crecimiento indica que los grandes clientes realmente valoran esta transferencia de responsabilidad.

La misma integración también concentra las consecuencias. Un diseño de red, un retraso de un proveedor, un error de política, una restricción de financiación o un cambio en el cliente ancla pueden afectar a una gran parte del sistema. El futuro de CoreWeave no depende de una cifra de ancho de banda llamativa, sino de que todas las capas sean capaces de convertir de forma sostenida la capacidad financiada en trabajo fiable para los clientes.