Resumen

  • La pila de red de CoreWeave abarca escalado vertical, horizontal, almacenamiento, inquilinos, gestión, backbone y conexión privada; es una arquitectura operativa, no un producto separado.
  • Las redes y DPU de NVIDIA se combinan con software de CoreWeave para programar aceleradores, aislar inquilinos y mover datos por una nube especializada.
  • CoreWeave declaró 43 centros de datos, más de 850 MW activos y unos 3,1 GW contratados; Microsoft aportó el 67 % de los ingresos de 2025, mostrando escala y concentración.
  • La prueba es convertir potencia contratada y cartera en servicio fiable y diversificado antes de que se acumulen financiación, arrendamientos, obsolescencia y complejidad operativa.

La huella física creció más rápido de lo que sugiere un mapa de regiones convencional

A 31 de diciembre de 2025, CoreWeave declaró 43 centros de datos, más de 850 MW activos y aproximadamente 3,1 GW contratados. El dato activo describe infraestructura operativa bajo su definición en esa fecha; el contratado, derechos y compromisos futuros. No es capacidad ya instalada.

La progresión fue pronunciada: 10 centros y unos 70 MW al final de 2023; 32 y más de 360 MW al final de 2024; 43 y más de 850 MW al final de 2025. En el primer trimestre de 2026, más de 1 GW activo y más de 3,5 GW contratado. Las cifras muestran industrialización a gran velocidad y también cómo la arquitectura de ayer puede convertirse rápidamente en minoría.

La potencia es requisito, no producto terminado. Un megavatio contratado todavía necesita interconexión, generación o red, distribución eléctrica densa, refrigeración, edificio, red, entrega de aceleradores y aceptación operativa. Un retraso en cualquier capa puede aplazar ingresos mientras algunas obligaciones empiezan antes.

El modelo de centros de datos es mixto. CoreWeave posee equipos y controla despliegues importantes, pero utiliza instalaciones arrendadas y terceros. Eso acelera expansión y evita construir cada edificio, pero hace que rendimiento del arrendador, construcción, potencia y términos contractuales formen parte de la fiabilidad.

Una GPU todavía no es una nube

Un acelerador instalado en un rack con alimentación puede ejecutar código, pero por sí solo no ofrece lo que un cliente compra a una nube. Un equipo de entrenamiento necesita que muchos aceleradores se comporten como una única asignación. Los datos deben llegar desde el almacenamiento al ritmo adecuado. Las operaciones colectivas deben atravesar las GPU sin que el trabajo pase la mayor parte del tiempo esperando a la comunicación. Los inquilinos deben permanecer aislados. Los planificadores han de saber qué nodos, enlaces y dispositivos están sanos. Los checkpoints deben sobrevivir a fallos.

Los ingenieros necesitan una ruta hacia el entorno y los usuarios otra hacia nubes, oficinas y servicios externos. El producto de nube empieza cuando esos caminos se vuelven repetibles.

Por eso, la red de una nube de IA no puede tratarse como un accesorio del cómputo. En la arquitectura empresarial ordinaria, suele describirse la red como el sistema que conecta servidores. En la IA distribuida, participa directamente en el cálculo efectivo. Un trabajo síncrono puede quedar limitado por una sola óptica degradada, un acelerador lento, un rail congestionado o una ruta de almacenamiento incapaz de seguir el ritmo. La factura del hardware ocioso continúa mientras el trabajo espera. La red afecta así no solo al benchmark, sino a la economía de cada hora de GPU financiada.

La plataforma de CoreWeave es un buen objeto de estudio porque hace visible esta relación. La empresa se especializa en infraestructura de aceleradores, en vez de presentar las GPU como un servicio menor dentro de una nube generalista. Sus materiales públicos describen fabrics de rack, unidades de procesamiento de datos, orquestación bare metal, supercomputadores gestionados, conectividad privada y reparación operativa con más detalle que un simple catálogo de instancias. Esos documentos prueban intención de diseño y arquitectura de producto; no forman un mapa completo de cada instalación, generación o despliegue de cliente.

La pregunta no es si CoreWeave tiene «una red rápida» en abstracto. La pregunta útil es cuántas redes diferentes deben cooperar antes de que una carga de IA pueda funcionar como servicio fiable, y quién controla cada una.

Qué significa realmente «pila de red de CoreWeave»

La expresión es un paraguas editorial, no una entidad jurídica ni un SKU que se venda por separado. El operador legal y económico es CoreWeave, Inc., una sociedad de Delaware con sede en Livingston, Nueva Jersey, y cotizada en Nasdaq bajo el símbolo CRWV. La pila de red está dentro de CoreWeave Cloud Platform, que también incluye cómputo, almacenamiento, orquestación y servicios gestionados.

Diversos nombres describen capas distintas. Nimbus es la arquitectura de red virtual basada en DPU de CoreWeave. CoreWeave Kubernetes Service, o CKS, presta Kubernetes gestionado sobre bare metal. SUNK empaqueta infraestructura y operaciones como un servicio de supercomputador gestionado. Mission Control añade supervisión, reparación y gestión del ciclo de vida. Direct Connect aporta conectividad privada para clientes. NVLink, NVSwitch, Quantum, Spectrum-X y BlueField son tecnologías de NVIDIA integradas por CoreWeave, no inventos propios de la empresa.

Separar estas capas evita dos errores habituales. El primero es atribuir a la compañía cada protocolo o dispositivo de la plataforma. La aportación de CoreWeave es la integración de sistemas, la cualificación, la operación y el software de nube alrededor de tecnología de proveedores. El segundo es imaginar un fabric uniforme que se extiende desde cada GPU hasta cada cliente. Los enlaces locales de scale-up, fabrics de entrenamiento entre racks, redes de almacenamiento, overlays VPC, rutas de gestión y backbone transatlántico tienen objetivos, presupuestos de latencia y dominios de fallo distintos.

No pueden resumirse con un único número de ancho de banda.

La misma disciplina se aplica a la propiedad. CoreWeave despliega y opera equipos sustanciales, pero sus documentos también describen arrendamientos, centros de datos de terceros, compromisos de potencia, relaciones con proveedores de fibra y financiación de equipos. Un servicio puede estar operacionalmente integrado sin que la compañía sea dueña del edificio, la utilidad eléctrica, la ruta de larga distancia o cada componente del rack. «Integración vertical» solo resulta útil si significa control coordinado de muchas capas, no autosuficiencia total.

De Atlantic Crypto al cómputo especializado

CoreWeave se fundó en 2017 como The Atlantic Crypto Corporation. Su actividad inicial utilizaba GPU para cargas de criptomonedas, y en septiembre de 2018 pasó de LLC a sociedad de Delaware. Adoptó el nombre CoreWeave en diciembre de 2019 al orientarse hacia el cómputo especializado en la nube.

El origen se reduce a veces a un contraste llamativo entre minería de criptomonedas e inteligencia artificial. La continuidad más importante es operativa. Ambos negocios exigen comprar aceleradores, asegurar electricidad, mantener hardware denso y dirigir las cargas hacia capacidad infrautilizada. La empresa aprendió la economía de una flota de aceleradores antes de construir los sistemas de tenancy, red, almacenamiento y soporte de una nube.

La distinción importa porque un cambio de demanda no crea automáticamente una plataforma. Las cargas de minería pueden ser relativamente repetitivas y tolerar un modelo de activos sencillo. Los efectos visuales, el aprendizaje automático y la computación de alto rendimiento requieren software, movimiento de datos, aislamiento y garantías de servicio distintos. CoreWeave tuvo que añadir las capas que permiten a clientes externos confiar en recursos que no poseen y no pueden inspeccionar físicamente.

Durante los primeros años de la década de 2020, la empresa desarrolló servicios especializados de cómputo, almacenamiento y Kubernetes. Kubernetes sobre bare metal se convirtió en una interfaz principal: los clientes podían planificar cargas en contenedores directamente sobre servidores con aceleradores sin pasar antes por una capa convencional de máquinas virtuales. A finales de 2023, CoreWeave operaba 10 centros de datos y unos 70 MW activos. A finales de 2024, declaraba 32 centros y más de 360 MW.

La expansión cambió el carácter del problema de red. Un operador con diez instalaciones puede depender mucho del conocimiento experto y de excepciones locales. Una nube de treinta o cuarenta necesita diseños repetibles, políticas controladas por software, cualificación común, supervisión compartida y una forma de mover clientes entre generaciones de hardware sin perder coherencia operativa. La escala convierte las buenas decisiones de ingeniería en cuestiones de gobierno: quién aprueba cambios, con qué rapidez se detectan excepciones y si cada nueva instalación reproduce los límites de control previstos.

CoreWeave completó su oferta pública inicial en marzo de 2025. La cotización no solo añadió capital. También produjo un prospecto y documentos de la SEC con evidencia sobre instalaciones, concentración de clientes, deuda, arrendamientos, arquitectura de interconexión y riesgo. Ese registro permite estudiar la pila de red como sistema técnico y, al mismo tiempo, como compromiso de una compañía pública.

La carga de trabajo que determina la arquitectura

El entrenamiento de modelos grandes reparte el cálculo entre aceleradores e intercambia repetidamente resultados parciales. El patrón exacto depende de la arquitectura del modelo, el método de paralelización y el software, pero el problema de infraestructura es estable: la velocidad útil de la asignación depende de la comunicación colectiva tanto como del cálculo local. Un fabric que parece rápido en términos agregados puede desperdiciar capacidad si la congestión, la topología o la latencia de cola ralentizan los puntos de sincronización que mantienen unido el trabajo.

La pila también debe atender tráfico que no se comporta como una colectiva. Los datasets entran en el entorno. Los checkpoints salen de la memoria de la GPU y llegan al almacenamiento. Los sistemas de control distribuyen trabajos y políticas. Los ingenieros obtienen registros. Los servicios exponen endpoints de inferencia. Las copias y réplicas pueden cruzar regiones. Cada clase posee una tolerancia distinta al retraso y la pérdida. Tratarlo todo como una única red indiferenciada haría difícil predecir el rendimiento y aislar los fallos.

El resultado es un diseño por capas. Los enlaces de scale-up crean un dominio estrechamente acoplado dentro de un sistema de escala de rack. Los fabrics de scale-out enlazan muchos sistemas entre racks. Las rutas de almacenamiento alimentan y conservan la carga. Una red de inquilino proporciona direcciones privadas y políticas. Una red de gestión da al operador control sobre hosts, DPU, switches y reparaciones. Un backbone conecta instalaciones y ecosistemas externos. Los circuitos privados del cliente enlazan la nube con otros dominios administrativos.

Las capas interactúan, pero no son intercambiables. La fibra de larga distancia no sustituye un fabric GPU local, porque la propagación dificulta el entrenamiento altamente sincronizado entre centros remotos. Un dominio NVLink no es un VPC de cliente. Un overlay puede ocultar diferencias de direccionamiento, pero no arregla una óptica rota en el underlay. Kubernetes puede planificar un pod sin entender cada rail, salvo que la plataforma le proporcione información topológica e integraciones de dispositivos.

La arquitectura es, por tanto, una cadena que traduce intención. El cliente pide un clúster, namespace, red o trabajo. Los sistemas de control de CoreWeave transforman la solicitud en servidores, fabric, almacenamiento y políticas disponibles. Nimbus traduce la intención del VPC en estado del DPU y del underlay. Kubernetes y los servicios relacionados con Slurm transforman la intención de trabajo en nodos y aceleradores. Mission Control convierte señales de salud en acciones de reparación. El cliente ve un servicio; la plataforma debe mantener coherentes todas las traducciones.

Red de scale-up dentro del dominio rack-scale

La red de scale-up conecta aceleradores dentro de un sistema estrechamente integrado. En los diseños rack-scale de NVIDIA, NVLink ofrece comunicación de gran ancho de banda entre GPU y NVSwitch proporciona conmutación dentro de ese dominio local. CoreWeave incorpora ambas tecnologías en sistemas y generaciones seleccionados.

La propiedad clave no es la marca, sino la proximidad. Un dominio de scale-up permite que particiones del modelo y operaciones colectivas intercambien datos sin atravesar la red ordinaria del centro de datos en cada paso. Así, un rack puede comportarse más como un gran sistema acelerador que como una colección de servidores independientes. También crea un dominio de fallo propio: un switch, cable, problema de refrigeración o componente defectuoso dentro del rack puede afectar a muchas GPU que el planificador esperaba utilizar juntas.

El prospecto de CoreWeave describió configuraciones seleccionadas con ancho de banda de interconexión GPU no bloqueante de hasta 3.200 gigabits por segundo. La expresión «configuraciones seleccionadas» es la parte decisiva. No establece un nivel de servicio universal ni describe todos los centros o generaciones. El ancho de banda efectivo para una carga depende además del software, topología, patrón de mensajes y estado completo de la ruta.

El scale-up reduce un cuello de botella mientras eleva la densidad en otras capas. Más aceleradores y más ancho de banda local aumentan potencia, refrigeración y requisitos de servicio del rack. Un sistema que concentra cómputo sin un diseño térmico y operativo equivalente puede ser más difícil de reparar o trasladar la limitación a scale-out y almacenamiento. La arquitectura debe leerse como un equilibrio, no como una sucesión de especificaciones máximas.

Fabrics de scale-out: conviven InfiniBand y Ethernet

Cuando un trabajo sale del dominio de scale-up, entra en el fabric de scale-out. Los documentos de CoreWeave describen NVIDIA Quantum-2 InfiniBand, Quantum-X800 XDR de 800 gigabits y Spectrum-X Ethernet con RoCE y RDMA. La presencia de InfiniBand y Ethernet es significativa: la plataforma no reduce su identidad a una única familia de protocolos.

InfiniBand para clústeres estrechamente acoplados

InfiniBand está construido para comunicación de baja latencia orientada a acceso remoto directo a memoria y tiene una larga historia en HPC. En un clúster de IA, puede mover datos entre hosts de aceleradores evitando parte del procesamiento normal de la CPU. Los sistemas Quantum de NVIDIA añaden conmutación y capacidades orientadas a operaciones colectivas. CoreWeave integra estos fabrics en ofertas de clúster, no vende InfiniBand como servicio de carrier separado.

La evidencia pública no revela todas las topologías, ratios de sobresuscripción, políticas de routing o límites de servicio. «No bloqueante» puede describir un diseño concreto, no toda la flota. Incluso un fabric bien diseñado puede sufrir ópticas degradadas, mala colocación, tráfico desigual o software que genera zonas calientes. Los compradores deben preguntar qué generación, topología y proceso de cualificación corresponden al clúster que reciben.

Spectrum-X y RoCE como ruta Ethernet

Spectrum-X es la plataforma de red Ethernet de NVIDIA para IA. RoCE transporta semántica RDMA sobre Ethernet, de modo que las aplicaciones utilizan acceso directo a memoria mientras el operador conserva un fabric Ethernet. El uso de Spectrum-X ofrece a CoreWeave una vía de scale-out alternativa para cargas y generaciones concebidas en ese ecosistema.

La familiaridad de Ethernet no significa operación sencilla. El rendimiento de RoCE depende de control de congestión, diseño de colas, comportamiento ante pérdidas, telemetría y configuración extremo a extremo. Una red puede emplear tramas Ethernet conocidas y requerir ingeniería especializada para evitar bloqueo de cabecera, incast o inestabilidad en colectivas. Una nube integrada asume buena parte de ese ajuste, pero el cliente pierde visibilidad directa sobre las decisiones.

Topología optimizada por rails y colocación

Los sistemas multirrail agrupan NIC y aceleradores correspondientes para que el tráfico colectivo atraviese rutas paralelas previsibles. Un diseño optimizado por rails puede reducir cruces innecesarios y regularizar el ancho de banda. También exige que el planificador entienda la topología: distribuir el trabajo sobre la combinación incorrecta de nodos puede anular el diseño físico.

Los rails pueden concentrar fallos. Si uno se degrada, cada nodo que utiliza esa ruta puede convertirse en rezagado aunque otras interfaces sigan sanas. El sistema operativo debe distinguir entre un servidor defectuoso y un problema de red compartido. Por eso telemetría topológica, cualificación y reparación importan tanto como la velocidad nominal del puerto.

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

Un fabric de alto rendimiento no crea por sí solo una nube multiinquilino. Los clientes necesitan direcciones privadas, control de rutas, acceso a internet y aislamiento. CoreWeave responde con Nimbus, una arquitectura de red virtual que descarga funciones VPC en unidades de procesamiento de datos. La documentación identifica DPU NVIDIA BlueField-3 y describe VRF, VXLAN y rutas EVPN Type 5.

La DPU ocupa una posición privilegiada entre el cómputo controlado por el cliente y la infraestructura controlada por el proveedor. Puede procesar tráfico virtual, aplicar segmentación y reservar recursos de CPU para la carga. También puede mantener un límite de tenancy fuera del sistema operativo que el cliente controla. La separación es una decisión de rendimiento y de seguridad.

Cómo se construye el overlay de VPC

Una instancia VRF separa un dominio de routing de otro. VXLAN transporta segmentos de inquilinos sobre un underlay físico compartido. EVPN distribuye alcanzabilidad y las rutas Type 5 pueden anunciar prefijos IP, no solo direcciones MAC. Juntos, los mecanismos permiten a CoreWeave presentar una red privada sobre infraestructura común.

El overlay no elimina la dependencia del underlay. Si falla la conectividad física, también falla la red virtual. Si la distribución de rutas es incorrecta, el aislamiento o la alcanzabilidad pueden romperse a escala. Si una imagen DPU o el sistema de políticas contiene un error, muchos hosts pueden recibir rápidamente el mismo estado equivocado. La abstracción reduce complejidad para el cliente al trasladarla al proveedor; no la borra.

La DPU entra en la base de confianza

Nimbus reduce la exposición de funciones de red del proveedor al host del cliente, pero aumenta la importancia de firmware, arranque seguro, claves, distribución de políticas, logs y recuperación de la DPU. Un dispositivo que impone aislamiento debe ser observable y actualizable sin convertirse en una ruta descontrolada hacia el entorno del inquilino.

El límite de control también afecta a la respuesta a incidentes. Un fallo de conectividad puede originarse en la carga, una política Kubernetes, la configuración VPC, el software DPU, el control EVPN o el fabric físico. Los equipos de soporte necesitan pruebas que crucen capas sin revelar un inquilino a otro. La documentación explica la arquitectura prevista, pero no publica un historial independiente de fallos de aislamiento o tiempos de reparación de toda la flota.

Kubernetes bare metal como superficie de control del cliente

CoreWeave Kubernetes Service presta Kubernetes gestionado sobre infraestructura bare metal. El diseño evita una capa convencional basada primero en máquinas virtuales entre contenedores y servidores GPU. Cada clúster recibe su propio VPC e integra redes de alto rendimiento y almacenamiento para cargas distribuidas.

Bare metal elimina una capa, pero no simplifica por completo el sistema. Kubernetes debe descubrir GPU, exponer dispositivos, aplicar cuotas, colocar pods e interactuar con plugins de red y almacenamiento. La plataforma coordina imágenes, drivers, firmware, runtime de contenedores y actualizaciones del clúster con la generación de hardware. El cliente obtiene una API conocida y CoreWeave hereda una matriz de compatibilidad exigente.

Lo que Kubernetes puede decidir y lo que no

Kubernetes puede decidir dónde ejecutar un pod conforme a la información y las políticas que posee el planificador. No comprende automáticamente cada rail, óptica, ruta de switch o condición colectiva. CoreWeave debe añadir plugins, operadores, información topológica y controles para que una decisión lógica corresponda a una asignación física viable.

La política de red también está delimitada. Las políticas Kubernetes restringen tráfico entre cargas, mientras VPC y DPU ofrecen límites más amplios de tenancy y routing. Un objeto de política no demuestra que el paquete recorra un camino que aplica la intención. Configuración, implementación y observación deben coincidir.

SUNK convierte el clúster en supercomputador gestionado

SUNK se posiciona como servicio de supercomputador gestionado para producción. Combina infraestructura, fabric de alto rendimiento, orquestación de cargas y operaciones de CoreWeave para clientes que quieren un gran entorno dedicado sin construir instalaciones y equipo operativo completos.

El servicio cambia el reparto de responsabilidad. El cliente conserva arquitectura del modelo, código, datos y estrategia de trabajo; CoreWeave asume más ciclo de vida de hardware, cualificación e incidencias. El resultado se parece a una instalación HPC gestionada entregada mediante contratos y software de nube, no a una reserva de instancias intercambiables.

Mission Control convierte operaciones en producto

Mission Control añade supervisión, mantenimiento, reparación y ciclo de vida. Su importancia se ve cuando el trabajo es grande. Sustituir un componente en un pequeño pool puede tener impacto limitado; diagnosticar un enlace degradado dentro de una asignación sincronizada decide si miles de horas de acelerador son productivas o se pierden.

El material de servicio describe monitorización proactiva e intervención. Eso establece el modelo previsto, no uptime verificado de forma independiente ni una distribución pública del tiempo de reparación. La ausencia de un censo completo de incidentes importa porque la fiabilidad es una razón principal para pagar a un proveedor en vez de construir el clúster.

El almacenamiento forma parte del cálculo conectado

Datos de entrenamiento, checkpoints y artefactos viajan por rutas de almacenamiento que pueden limitar toda la carga. Un clúster con ancho de banda GPU excepcional puede detenerse si no lee entradas, escribe checkpoints o recupera estado con rapidez. La plataforma incluye almacenamiento de objetos y archivos y describe el movimiento de datos de alto rendimiento como parte del servicio.

El tráfico de checkpoints crea un patrón específico. Muchos workers pueden persistir estado de forma coordinada, generando ráfagas distintas a las colectivas. Si el almacenamiento comparte recursos físicos con el fabric de entrenamiento, el diseño necesita aislamiento o capacidad. Si usa otra red, la plataforma sigue debiendo coordinar fallo y recuperación entre ambos caminos.

El almacenamiento también influye en portabilidad. Llevar un modelo a CoreWeave puede exigir grandes transferencias desde otra nube o entorno privado. Sacarlo puede generar coste, tiempo y fricción contractual. «Zero Egress Migration» es un mecanismo comercial para reducir ciertos costes de migración hacia CoreWeave; no es una garantía técnica, egress gratuito universal ni prueba de que mover datos carezca de coste operativo.

El cliente debe pedir evidencia extremo a extremo. Los benchmarks de acelerador o fabric son útiles, pero la producción incluye preparación de datos, checkpoint, registros de modelos, logs y recuperación. Una prueba que aísla una capa no responde cuánto tarda ni cuánto cuesta completar el trabajo real.

El backbone conecta regiones, no un único supercomputador síncrono

CoreWeave describe un backbone de clase carrier que enlaza centros de datos de Norteamérica y Europa por fibra terrestre y submarina, peering directo y servicios privados. El filing enumera Direct Connect a 10, 100 y 400 Gbps, sujeto a ubicación y disponibilidad.

El backbone tiene una función distinta del fabric local de scale-out. Mueve datasets, réplicas, checkpoints, control e inferencia entre regiones; conecta usuarios y otras nubes; apoya recuperación y distribución. La latencia de larga distancia impide que convierta centros remotos en un solo fabric de entrenamiento de baja latencia para trabajos acoplados.

La conectividad privada reduce un tipo de incertidumbre

Un circuito dedicado evita parte de la variabilidad de internet público y ofrece límites más claros de capacidad y soporte. No crea un mundo completamente privado de extremo a extremo. El acceso puede depender de un carrier, un cross-connect y el operador del centro. Los on-ramps de nube tienen sus propias validaciones. No se revela para cada ubicación la propiedad física o la diversidad de ruta.

Por ello, CoreWeave no debe describirse como carrier Tier 1. Opera un backbone y hace peering, pero la evidencia no demuestra alcance global sin liquidación ni propiedad de toda la fibra. Su ventaja es el acceso integrado a su propia capacidad de cómputo, no sustituir al ecosistema mundial de telecomunicaciones.

El diseño regional crea decisiones de disponibilidad

CoreWeave declaró instalaciones en seis países al final de 2025. El recuento no significa que cada generación, fabric, servicio o velocidad privada esté disponible en cada país. Las regiones se abren por fases porque potencia, refrigeración, red, hardware y preparación operativa no llegan a la vez.

La geografía afecta a más que latencia: gobierno de datos, proximidad a otras nubes, personal, origen eléctrico, correlación de fallos y quién controla el camino local. Para CoreWeave, cada país añade coordinación legal, de utilities y de suministro además de capacidad. La expansión es un modelo operativo, no un mapa de cajas idénticas.

La fiabilidad convierte capital en tiempo útil

El hardware permanece financiado tanto si el trabajo progresa como si espera. Por eso, la fiabilidad es una variable financiera. Un fallo de fabric, GPU degradada, bloqueo de almacenamiento o error del planificador reduce producción útil y facturable mientras continúan intereses, arrendamientos y electricidad.

Los rezagados importan más que los fallos completos

Un nodo muerto es visible. Un straggler puede seguir vivo mientras ralentiza cada sincronización. Los trabajos grandes necesitan telemetría que detecte degradación, no solo salud binaria. El planificador y operaciones deben decidir si drenar, sustituir o continuar utilizando el componente.

La información pública no ofrece una distribución completa de fallos de trabajos, latencia de cola o incidencia de stragglers. No demuestra mala fiabilidad, pero limita la comparación independiente. Los clientes deben apoyarse en contrato, pruebas de carga y evidencia propia, no extrapolar desde diagramas.

La cualificación es una prueba del sistema

Antes de exponer un clúster, CoreWeave debe cualificar servidores, switches, ópticas, cables, firmware, drivers, almacenamiento y orquestación en conjunto. Un boot correcto no basta. La prueba útil comprueba si la topología sostiene la carga, sobrevive a fallos y se repara sin generar incoherencia.

La cualificación cambia con el tiempo. Un diseño probado con un conjunto de software puede comportarse de forma distinta tras una actualización. La rápida llegada de generaciones NVIDIA multiplica combinaciones mientras los entornos antiguos siguen contratados. La madurez consiste en gestionar el solapamiento sin convertir cada instalación en excepción única.

Las finanzas son una capa de la arquitectura

CoreWeave declaró 5.100 millones de dólares de ingresos en 2025 y una pérdida neta de 1.200 millones. Pagó 10.300 millones en efectivo por propiedades y equipos. Al cierre, las obligaciones de rendimiento restantes ascendían a 60.700 millones. El filing también describió financiación de equipos, deuda, arrendamientos y compromisos de infraestructura muy elevados.

Las cifras significan cosas distintas. Los ingresos son servicio reconocido. El efectivo pagado por activos es una salida de inversión, no valoración de toda la flota. La pérdida muestra que el crecimiento no produjo rentabilidad consolidada. Las obligaciones restantes son desempeño futuro contratado bajo normas contables, no efectivo disponible ni servicio entregado.

El primer trimestre de 2026 mostró demanda y coste de arrastre

Para el trimestre cerrado el 31 de marzo de 2026, CoreWeave declaró 2.078 millones de dólares de ingresos, 740 millones de pérdida y 536 millones de intereses. También comunicó 99.400 millones de backlog bajo su definición. Los datos muestran a la vez demanda visible y una pesada carga de financiación.

El backlog no es intercambiable directamente con las obligaciones de fin de año; difieren definición y fecha. Ambos indican demanda futura, pero convertirlos exige poner centros, potencia, hardware y red en servicio y después cumplir los contratos. Cuanto más convincente es la cartera, mayor es la obligación de entrega que lleva asociada.

La financiación respaldada por GPU alinea activos y contratos

CoreWeave ha utilizado préstamos garantizados, financiación de equipos y estructuras respaldadas por clientes. En junio de 2026 anunció una facilidad de 8.500 millones descrita como respaldada por GPU y con calificación investment grade para esa operación. Aumenta capacidad de despliegue; no es ingreso ni significa que toda deuda corporativa tenga esa calificación.

La financiación de activos puede alinear deuda, hardware y flujos contratados. También restringe colateral, despliegue y uso del efectivo. Aceleradores, switches y ópticas envejecen rápido frente a infraestructuras tradicionales. El modelo funciona si la utilización se mantiene alta y los contratos cubren el periodo de mayor valor económico del equipo.

El diseño de red afecta así a la calidad crediticia. Una topología que aumenta utilización mejora la producción del activo financiado. Un centro retrasado, stragglers persistentes o una migración fallida la reducen. En CoreWeave, ingeniería de sistemas e ingeniería de balance son la misma historia.

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

Microsoft representó el 67 % de los ingresos de 2025. Un cliente ancla puede justificar capacidad, apoyar la financiación y dar confianza para comprar antes. La misma concentración le da poder de negociación y hace que la utilización dependa de una relación.

CoreWeave ha anunciado o declarado relaciones con Meta y Anthropic; Flow Traders la seleccionó para entrenar modelos fundacionales en julio de 2026 y Leidos anunció colaboración para IA de defensa, seguridad nacional e inteligencia. Los anuncios prueban contratos, selección o colaboración en el nivel descrito. No demuestran que la concentración haya desaparecido ni que toda capacidad esté activa.

Los contratos take-or-pay transfieren riesgo, no lo eliminan

Los contratos plurianuales take-or-pay aportan visibilidad y pueden respaldar financiación. Trasladan parte del riesgo de utilización al cliente porque los pagos comprometidos no dependen solo del consumo inmediato. No eliminan riesgo de construcción, potencia, entrega, rendimiento, crédito o renegociación.

Para el cliente, el contrato invierte parte de la promesa de nube. La nube pública tradicional destaca elasticidad y poco compromiso. Un clúster dedicado puede requerir una relación más larga porque el proveedor construye o reserva capacidad específica. La interfaz parece software cloud y la estructura inferior se parece a project finance.

Defensa y regulación elevan el umbral de aseguramiento

La colaboración con Leidos del 30 de julio de 2026 lleva la plataforma hacia misiones de defensa e inteligencia. No acredita todas las autorizaciones, certificaciones o implementaciones necesarias. Sí indica que seguridad, cadena de suministro, auditabilidad y continuidad pueden adquirir más peso en el producto.

Un VPC aplicado por DPU, conectividad privada y operaciones gestionadas apoyan diseños de alta seguridad. No sustituyen controles del programa, requisitos de personal, tratamiento de datos ni aprobación gubernamental. Cuanto más sensible sea la carga, más transparentes deberán ser los límites de responsabilidad.

Las adquisiciones suben por la pila y la fusión fallida apuntaba hacia abajo

Durante 2025, CoreWeave adquirió Weights & Biases, OpenPipe, marimo y Monolith AI. Weights & Biases añadió desarrollo y observabilidad de modelos; las demás ampliaron inferencia, notebooks e IA industrial. Las operaciones elevan a CoreWeave desde infraestructura bruta hacia más etapas del ciclo de desarrollo.

La lógica es clara. Un proveedor que comprende workflows de modelos puede prever demanda, simplificar consumo y retener clientes. El riesgo también: el software tiene ciclos, márgenes y culturas distintos a los centros de datos financiados. Pueden aparecer solapamientos y conflictos con socios si CoreWeave intenta poseer herramientas antes independientes.

La propuesta de adquirir Core Scientific iba en sentido descendente. CoreWeave anunció un acuerdo en julio de 2025 que habría aumentado su control sobre capacidad de centros de datos y arrendamientos. Core Scientific lo rescindió el 30 de octubre de 2025 tras la votación de accionistas. CoreWeave no adquirió la empresa.

En conjunto, las transacciones revelan integración por arriba hacia software y por abajo hacia capacidad física. La fusión fallida demuestra que el control de infraestructura no siempre se compra al ritmo que desea la plataforma. Accionistas, regulación, financiación y contrato pueden bloquear la lógica técnica de la integración vertical.

Qué controla CoreWeave y qué queda fuera

CoreWeave controla la plataforma del cliente, muchas decisiones de diseño, cualificación, orquestación y operaciones. Decide cómo Nimbus representa VPC, cómo presenta clústeres, qué gestiona y cómo responde a incidentes. Puede comprar hardware pronto y diseñar instalaciones alrededor de la densidad.

NVIDIA controla hojas de ruta críticas de GPU, NVLink, InfiniBand, Spectrum-X y BlueField. Utilities y socios de centros de datos controlan parte de potencia y entrega. Carriers, exchanges y nubes controlan parte de la conectividad externa. Prestamistas limitan capital. Clientes grandes influyen mediante contratos.

No es un defecto exclusivo: toda nube depende de proveedores. La concentración es material porque la diferenciación de CoreWeave está muy ligada al despliegue temprano de NVIDIA y sus compromisos son enormes frente a su historia operativa. Un retraso o cambio de roadmap puede propagarse a clientes y financiación.

La fortaleza es coordinar los límites. El riesgo es la dependencia correlacionada: una generación, diseño de centro o programa de cliente puede afectar varias capas. La integración reduce contratos para el cliente, pero aumenta el impacto de un fallo del proveedor.

Posición competitiva: una nube especializada reparte responsabilidades

CoreWeave compite con hyperscalers, otras nubes GPU, clústeres privados y combinaciones de colocation, hosting e integración. No basta contar GPU o mirar un benchmark. Los compradores comparan generación, fabric, almacenamiento, planificación, conectividad privada, soporte, contrato, geografía y coste de mover datos.

Frente a hyperscalers

AWS, Microsoft Azure, Google Cloud y Oracle ofrecen amplitud, ecosistemas mundiales y balances grandes. Combinan IA con bases de datos, seguridad, analítica y compras ya implantadas. CoreWeave responde con especialización: integración rápida de generaciones NVIDIA seleccionadas, bare metal y diseño para alta densidad.

La especialización reduce abstracción y acelera cualificación, pero crea un perfil más estrecho de proveedor y fallo. El cliente gana un proveedor concentrado en la carga, aceptando menos amplitud y una estructura de capital más joven. La comparación correcta es específica de cada workload.

Frente a otras nubes especializadas

Lambda, Nebius, Crusoe y otros proveedores se solapan en aceleradores, clústeres y gestión. Difieren en geografía, energía, software, propiedad, capital y control de centros. «Neocloud» es una etiqueta, no una arquitectura.

Los filings públicos de CoreWeave aportan evidencia inusual de escala y riesgo, pero no demuestran superioridad técnica o económica. Un rival con menos información puede ser menor, más eficiente o simplemente opaco. La transparencia no debe convertirse en ranking.

Frente a construir un clúster propio

Un clúster privado ofrece control directo de hardware, datos y operaciones, pero requiere compras, potencia, instalaciones, red, almacenamiento, seguridad, firmware, repuestos y especialistas. CoreWeave vende la transferencia de buena parte de esa carga.

La transferencia no es completa. El cliente diseña cargas, gestiona datos, fija políticas y evalúa riesgo. Los compromisos largos reducen movilidad. Un clúster propio arriesga infrautilización; un contrato cloud, dependencia. La decisión económica es quién absorbe mejor la variabilidad y mantiene productivo el sistema caro.

La conmutación líquida muestra dónde puede moverse el siguiente cuello de botella

En julio de 2026, CoreWeave describió conmutación refrigerada por líquido para aumentar ancho de banda por rack. La cifra procede de su arquitectura y cálculos, no de una prueba independiente de toda la flota. El mecanismo importa: al crecer la densidad de aceleradores, switches y ópticas consumen energía y generan calor suficiente para limitar el rack.

Refrigerar el switch con líquido permite más capacidad dentro de una envolvente y quizá trayectos de cable más cortos. También acopla mantenimiento de red y sistema hidráulico. Una fuga, bomba o procedimiento de servicio puede afectar equipos antes tratados como red refrigerada por aire.

El cambio muestra cómo migran los cuellos de botella. GPU más rápidas exigen más scale-up; eso exige scale-out más denso; la densidad exige más potencia y refrigeración; las instalaciones necesitan otro diseño mecánico y eléctrico. Una generación de producto puede ser una remodelación del centro, no una actualización de servidor.

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

El material de julio de 2026 describe preparación para NVIDIA Vera Rubin NVL72 y hace afirmaciones medidas o prospectivas sobre tokens por megavatio frente a Blackwell. Deben atribuirse a CoreWeave y a esa configuración. No demuestran disponibilidad en toda la flota en el corte de investigación.

Una generación nueva cambia acelerador, scale-up, scale-out, potencia, refrigeración, firmware, drivers, orquestación y cualificación. Puede mejorar producción por MW y hacer instalaciones antiguas menos competitivas. Adoptar pronto solo es ventaja si CoreWeave gestiona migración, utilización y depreciación de activos previos contratados.

También profundiza la dependencia de NVIDIA. El acceso temprano atrae clientes y contratos, pero expone al calendario, precio y arquitectura del proveedor. Diversificar clientes o software no necesariamente diversifica la capa física.

El efecto sobre la infraestructura digital más amplia

La expansión afecta mucho más que el alquiler de GPU. Compromisos de gigavatios crean demanda de generación, red, transformadores, refrigeración, suelo y construcción. Fabrics densos demandan switches, óptica y fibra. La conexión privada demanda carriers, exchanges y on-ramps. La financiación exige prestamistas capaces de valorar tecnología de rápida obsolescencia frente a contratos largos.

La plataforma cambia dónde aparece el tráfico. El entrenamiento acoplado permanece en fabrics locales, mientras datasets, checkpoints, artefactos, inferencia y workflows circulan entre nubes, centros y usuarios. El impacto visible puede venir menos de un gigantesco flujo de entrenamiento que de movimientos persistentes alrededor de él.

Para comunidades y redes eléctricas, la pila es una decisión de potencia y suelo. El pack no permite una conclusión ambiental corporativa, pero establece que potencia activa y contratada son medidas centrales y que retrasos son riesgo.

Para ingenieros, la arquitectura muestra que la infraestructura de IA se vuelve disciplina propia. Routing y switching se cruzan con bibliotecas colectivas, topología de aceleradores, refrigeración líquida, planificación y project finance. Quien ajusta congestión protege el trabajo y el servicio de la deuda.

Lo que no muestra la evidencia pública

CoreWeave publica documentación, blogs y filings, pero la pila sigue opaca en parte. No hay topología completa, inventario de fabric por centro, tablas de sobresuscripción, mapa de propiedad de fibra, historial total de incidentes ni archivo independiente de benchmarks por workload en el material suministrado.

Ese límite debe orientar las afirmaciones. La documentación prueba mecanismos; la SEC, finanzas y riesgos; un comunicado, selección o colaboración. Ninguno prueba resultado universal, uptime de flota ni menor coste total para cada comprador.

La misma cautela vale para escala. Potencia activa no es contratada. Backlog no es ingresos. Una fecha programada no es resultado. Un acuerdo anunciado no es utilización activa. Una adquisición propuesta no es propiedad. Una generación futura no es la flota actual.

Las distinciones no debilitan el perfil: definen el vacío que debe gestionar un lector profesional. CoreWeave pide a clientes y capital que confíen en un sistema integrado cuyos detalles más valiosos son privados. La respuesta racional no es asumir excelencia o fracaso, sino exigir evidencia en el contrato, clúster y centro específicos.

El juicio central

El producto de CoreWeave suele llamarse capacidad de cómputo. El producto más profundo es coordinación: entre roadmap y construcción, scale-up y scale-out, DPU e intención del inquilino, Kubernetes y topología, almacenamiento y checkpoint, backbone y acceso, financiación larga y generaciones cortas.

La coordinación puede crear ventaja real. Un proveedor especializado decide sobre toda la carga en vez de pedir al cliente que ensamble partes. Puede cualificar, reparar e introducir generaciones más rápido que muchas empresas. El crecimiento sugiere que grandes clientes valoran esa transferencia.

La integración concentra consecuencias. Un diseño, retraso, error de política, restricción financiera o cambio de cliente puede afectar gran parte del sistema. El futuro no depende de una cifra de ancho de banda, sino de que todas las capas conviertan capacidad financiada en trabajo fiable.