Resumen

  • La pila de red de CoreWeave abarca scale-up, scale-out, 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 el software de CoreWeave para programar aceleradores, aislar inquilinos y mover datos en una nube especializada.
  • CoreWeave declaró 43 centros de datos, más de 850 MW activos y aproximadamente 3,1 GW contratados; Microsoft representó el 67% de los ingresos de 2025, lo que muestra escala y concentración.
  • El reto es convertir la energía contratada y el backlog en un servicio fiable y diversificado antes de que los costes financieros, los arrendamientos, la obsolescencia y la complejidad operativa se acumulen.

El parque físico ha crecido más rápido de lo que sugiere un mapa común de regiones de nube

El 31 de diciembre de 2025, CoreWeave informó 43 centros de datos, más de 850 MW de potencia activa y aproximadamente 3,1 GW de potencia contratada. La medida activa describe la infraestructura en operación según la definición de la empresa en esa fecha. La contratada describe derechos y compromisos para implantación futura. No debe presentarse como capacidad instalada.

La progresión fue acentuada: diez centros de datos y cerca de 70 MW activos a finales de 2023; 32 centros de datos y más de 360 MW a finales de 2024; 43 centros de datos y más de 850 MW a finales de 2025. En el primer trimestre de 2026, CoreWeave informó más de 1 GW activo y más de 3,5 GW contratados. Las cifras muestran una empresa que intenta escalar instalaciones y operaciones a velocidad industrial. También muestran cuán rápido la arquitectura de ayer puede convertirse en minoría en la flota.

La energía es un prerrequisito, no un producto finalizado. Un megavatio contratado todavía necesita interconexión, generación o suministro de la red, distribución eléctrica de alta densidad, refrigeración, edificio preparado, caminos de red, entrega de aceleradores y aceptación operativa. Un retraso en cualquier capa puede posponer los ingresos mientras algunas obligaciones comienzan antes.

El modelo de centro de datos es mixto. CoreWeave posee equipos y controla implantaciones sustanciales, pero utiliza instalaciones alquiladas y proveedores externos. Esto puede acelerar la expansión geográfica y evitar que la empresa construya cada edificio. También convierte el desempeño del arrendador, los cronogramas de obra, la entrega de energía y los términos contractuales en parte de la fiabilidad de la plataforma.

Una GPU todavía no es una nube

Un acelerador instalado en un rack energizado puede ejecutar código, pero por sí solo no ofrece lo que un cliente compra de una nube. Un equipo de entrenamiento necesita que muchos aceleradores se comporten como una única asignación. Los datos deben llegar del almacenamiento a la velocidad necesaria. Las operaciones colectivas deben atravesar las GPU sin hacer que la mayor parte del trabajo espere por la comunicación. Los inquilinos deben permanecer separados. Los planificadores deben saber qué nodos, enlaces y dispositivos están sanos. Los puntos de control deben sobrevivir a fallos.

Los ingenieros necesitan una ruta de entrada y los usuarios necesitan rutas de salida hacia otras nubes, oficinas y servicios. Un producto de nube solo empieza a existir cuando estos caminos se vuelven repetibles.

Por eso, la red de una nube de IA no puede tratarse como un accesorio del cómputo. En arquitecturas corporativas convencionales, la red suele describirse como el sistema que conecta servidores. En la IA distribuida, participa directamente en el cálculo efectivo. Un trabajo síncrono puede retrasarse por un único transceptor óptico degradado, un acelerador lento, un rail congestionado o un camino de almacenamiento incapaz de seguir el ritmo. La factura del hardware inactivo sigue corriendo mientras el trabajo espera. El diseño de la red afecta 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 esta relación especialmente visible. La empresa se especializa en infraestructura de aceleradores, en lugar de presentar las GPU como un pequeño servicio dentro de una nube de uso general. Por eso, 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. Estas descripciones evidencian la intención de diseño y la arquitectura del producto.

No son un mapa completo de cada ubicación, generación o implantación de cliente.

La pregunta no es si CoreWeave posee, en abstracto, una red rápida. La pregunta útil es cuántas redes diferentes deben cooperar antes de que una carga de IA pueda operar como servicio fiable, y qué parte controla cada una.

Qué designa realmente el término «pila de red de CoreWeave»

La expresión es un paraguas editorial, no una entidad jurídica ni una SKU vendida por separado. La operadora legal y económica es CoreWeave, Inc., una empresa de Delaware con sede en Livingston, Nueva Jersey, y cotizada en Nasdaq bajo el ticker CRWV. La pila de red forma parte de la plataforma más amplia CoreWeave Cloud Platform, que también incluye cómputo, almacenamiento, orquestación y servicios gestionados.

Nombres diferentes describen capas diferentes. Nimbus es la arquitectura de red virtual basada en DPU de CoreWeave. El CoreWeave Kubernetes Service, o CKS, ofrece Kubernetes bare metal gestionado. SUNK reúne infraestructura y operaciones en un servicio de supercomputador gestionado. Mission Control añade monitorización, reparación y soporte al ciclo de vida. Direct Connect proporciona conectividad privada al cliente. Nombres de NVIDIA como NVLink, NVSwitch, Quantum, Spectrum-X y BlueField se refieren a tecnologías del proveedor integradas por CoreWeave, y no a invenciones propias.

Mantener estas capas separadas evita dos errores comunes. El primero es atribuir a la empresa cada protocolo o dispositivo de la plataforma. La contribución de CoreWeave está en la integración de sistemas, la cualificación, la operación y el software de nube alrededor de la tecnología de los proveedores. El segundo es imaginar un fabric uniforme que se extiende desde cada GPU hasta cada cliente.

Los enlaces locales de scale-up, los fabrics de entrenamiento entre racks, las redes de almacenamiento, los overlays de VPC, los caminos de gestión y un backbone transatlántico tienen finalidades, presupuestos de latencia y dominios de fallo distintos. No deben comprimirse en una única cifra de ancho de banda.

La misma disciplina vale para la propiedad. CoreWeave instala y opera equipos sustanciales, pero sus documentos también describen arrendamientos, centros de datos de terceros, compromisos de energía, relaciones con fibra y financiación de equipos. Un servicio puede estar operativamente integrado sin que la empresa sea dueña del edificio, de la compañía eléctrica, de la ruta de larga distancia o de cada componente del rack. «Integración vertical» solo es útil cuando significa control coordinado sobre varias capas, no autosuficiencia completa.

De Atlantic Crypto al cómputo especializado

CoreWeave comenzó en 2017 como The Atlantic Crypto Corporation. El negocio inicial utilizaba activos de GPU para cargas de criptomonedas, y la compañía se convirtió de LLC a corporation de Delaware en septiembre de 2018. En diciembre de 2019, adoptó el nombre CoreWeave mientras migraba hacia el cómputo especializado en la nube.

El origen a veces se reduce al curioso contraste entre la minería de criptomonedas y la inteligencia artificial. La continuidad más importante es operativa. Ambos negocios exigen que un propietario adquiera aceleradores, asegure energía, mantenga hardware denso funcionando y dirija las cargas hacia la capacidad ociosa. La empresa inicial aprendió la economía de una flota de aceleradores antes de construir los sistemas de tenencia, red, almacenamiento y soporte propios de una nube.

Esa 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 simple de activos. Los efectos visuales, el aprendizaje automático y la computación de alto rendimiento exigen software, movimiento de datos, aislamiento y garantías de servicio diferentes. CoreWeave necesitó añadir las capas que permiten a clientes externos confiar en recursos que no poseen y no pueden inspeccionar físicamente.

A principios de la década de 2020, la empresa desarrolló servicios especializados de cómputo, almacenamiento y Kubernetes. Kubernetes bare metal se convirtió en una interfaz importante: los clientes podían programar trabajo contenerizado directamente en servidores de aceleradores sin pasar primero por una capa convencional de máquinas virtuales. A finales de 2023, CoreWeave informó diez centros de datos y cerca de 70 MW de potencia activa. A finales de 2024, eran 32 centros de datos y más de 360 MW.

La expansión cambió la naturaleza del problema de red. Una operadora con diez ubicaciones aún puede depender mucho del conocimiento especializado y las excepciones locales. Una nube con treinta o cuarenta ubicaciones necesita diseños repetibles, políticas controladas por software, cualificación común, monitorización compartida y una forma de mover clientes entre generaciones de hardware sin perder coherencia operativa.

La escala transforma las buenas decisiones de ingeniería en cuestiones de gobernanza: quién puede aprobar cambios, con qué rapidez se detectan las excepciones y si cada nueva ubicación reproduce los límites de control previstos.

CoreWeave completó su oferta pública inicial en marzo de 2025. La cotización hizo más que añadir capital propio. Produjo un folleto y evidencias ante la SEC sobre instalaciones, concentración de clientes, deuda, arrendamientos, arquitectura de interconexión y riesgos. Ese registro permite estudiar la pila de red como sistema técnico y como compromiso de una empresa cotizada.

La carga de trabajo determina la arquitectura

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

La pila también debe atender tráfico que no se comporta como una operación colectiva. Los conjuntos de datos entran en el entorno. Los puntos de control salen de la memoria de la GPU y llegan al almacenamiento. Los sistemas de control distribuyen trabajos y políticas. Los ingenieros recogen registros. Los servicios exponen endpoints de inferencia. Las copias de seguridad y las réplicas pueden atravesar regiones. Cada clase tiene una tolerancia diferente al retraso y a la pérdida. Tratar todo como una única red indiferenciada haría el rendimiento difícil de predecir y los fallos difíciles de aislar.

Esto produce un diseño en capas. Los enlaces de scale-up crean un dominio fuertemente acoplado dentro de un sistema a escala de rack. Los fabrics de scale-out conectan varios sistemas entre racks. Los caminos de almacenamiento alimentan y persisten 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 flujos de reparación. Un backbone conecta instalaciones y ecosistemas externos. Los circuitos privados de clientes conectan la nube a otros dominios administrativos.

Las capas interactúan, pero no son intercambiables. La fibra de larga distancia no sustituye a un fabric local de GPU, porque la propia latencia de propagación dificulta el entrenamiento fuertemente sincronizado entre ubicaciones distantes. Un dominio NVLink no funciona como VPC de cliente. Un overlay puede ocultar diferencias de direccionamiento, pero no reparar un transceptor defectuoso en el underlay. Kubernetes puede programar un pod sin comprender cada rail físico, a menos que la plataforma proporcione información de topología e integraciones de dispositivo.

La arquitectura es, por tanto, una cadena de intenciones traducidas. El cliente solicita un clúster, un espacio de nombres, una red o un trabajo. Los sistemas de control de CoreWeave mapean la solicitud a servidores, fabric, almacenamiento y políticas disponibles. Nimbus traduce la intención de VPC en estado de DPU y underlay. Los servicios relacionados con Kubernetes y Slurm traducen la intención de carga en nodos y aceleradores. Mission Control traduce las señales de salud en acciones de reparación. El cliente ve un servicio; la plataforma debe mantener las traducciones coherentes.

Red de scale-up dentro del dominio a escala de rack

La red de scale-up conecta aceleradores dentro de un sistema fuertemente integrado. En los diseños a escala de rack de NVIDIA, NVLink proporciona comunicación GPU a GPU de alto ancho de banda, y NVSwitch realiza la conmutación dentro de ese dominio local. CoreWeave incorpora estas tecnologías en sistemas y generaciones seleccionados.

La propiedad importante no es el nombre de la marca, sino la proximidad. Un dominio de scale-up permite que las particiones de modelo y las operaciones colectivas intercambien datos sin atravesar la red común del centro de datos en cada paso. Esto puede hacer que un rack se comporte más como un gran sistema acelerador que como una colección de servidores independientes. También crea un dominio de fallo distinto: un switch, un cable, un problema de refrigeración o un defecto de componente dentro del rack puede afectar a muchas GPU que el planificador esperaba usar conjuntamente.

El folleto de CoreWeave describió configuraciones seleccionadas de clúster con un ancho de banda no bloqueante de interconexión de GPU de hasta 3.200 gigabits por segundo. La expresión «configuraciones seleccionadas de clúster» soporta la mayor parte del peso probatorio. No establece un nivel de servicio universal ni describe cada ubicación o generación de acelerador. El ancho efectivo disponible para una carga también depende del software, la topología, el patrón de mensajes y la salud del camino completo.

El diseño de scale-up reduce un cuello de botella al tiempo que aumenta la densidad en otro punto. Más aceleradores y más ancho de banda local elevan las exigencias de potencia, refrigeración y mantenimiento por rack. Un sistema que concentra cómputo sin un diseño térmico y operativo correspondiente puede ser más difícil de reparar o desplazar el cuello de botella hacia los enlaces de scale-out y el almacenamiento. La arquitectura debe leerse como equilibrio entre componentes, no como una secuencia de especificaciones máximas.

Fabrics de scale-out: InfiniBand y Ethernet están presentes

Cuando un trabajo cruza el límite del scale-up, entra en un fabric de scale-out. Los documentos públicos y los materiales técnicos de CoreWeave describen NVIDIA Quantum-2 InfiniBand, fabric Quantum-X800 XDR de 800 gigabits y Spectrum-X Ethernet con RoCE y RDMA. La presencia de InfiniBand y Ethernet es significativa: la empresa no reduce la identidad de la plataforma a una única familia de protocolos.

InfiniBand para clústeres fuertemente acoplados

InfiniBand fue creado para comunicación de baja latencia orientada al acceso remoto directo a memoria y tiene una larga historia en computación de alto rendimiento. En un clúster de IA, puede mover datos entre hosts de aceleradores evitando parte del procesamiento común del host. Los sistemas Quantum de NVIDIA añaden conmutación y características orientadas a operaciones colectivas, adecuadas para grandes cargas síncronas. CoreWeave integra estos fabrics en ofertas de clúster, en lugar de vender InfiniBand como un servicio de operadora separado.

Las evidencias públicas no revelan toda la topología, la tasa de sobresuscripción, la política de enrutamiento o el límite del servicio. «No bloqueante» puede describir un diseño específico, no toda la flota. Incluso un fabric bien diseñado puede sufrir con ópticas degradadas, mala asignación, tráfico desigual o comportamientos del software que crean puntos calientes. Los compradores deben preguntar qué generación de hardware, topología y cualificación se aplican al clúster que recibirán.

Spectrum-X y RoCE como camino Ethernet

Spectrum-X es la plataforma de red para IA orientada a Ethernet de NVIDIA. RoCE transporta semántica de RDMA sobre Ethernet, permitiendo comunicación directa con la memoria mientras la operadora mantiene un fabric basado en Ethernet. El uso de Spectrum-X por CoreWeave ofrece un camino alternativo de scale-out para cargas y generaciones de sistemas diseñadas en torno a ese ecosistema.

La familiaridad con Ethernet no significa operación sin esfuerzo. 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 configuración de extremo a extremo. Una red puede usar tramas Ethernet conocidas y aún así requerir ingeniería especializada para evitar bloqueos head-of-line, incast o un rendimiento colectivo inestable. El valor de una nube integrada es que el proveedor asuma buena parte de ese ajuste. El riesgo correspondiente es que el cliente tenga menos visibilidad directa de las elecciones.

Topología y asignación optimizadas por rails

Los sistemas multi-rail agrupan interfaces de red y aceleradores correspondientes para que el tráfico colectivo siga caminos paralelos regulares. Un diseño optimizado por rail puede reducir cruces innecesarios y hacer el ancho de banda más predecible. También exige que el planificador comprenda la topología: asignar un trabajo a la combinación equivocada de nodos puede anular el diseño físico.

Los rails pueden concentrar fallos. Si uno de ellos se degrada, todos los nodos que usan ese camino pueden convertirse en stragglers incluso cuando otras interfaces continúan sanas. El sistema operativo debe diferenciar un servidor defectuoso de una degradación compartida de la red. Por eso, la telemetría consciente de la topología, la cualificación y la reparación son tan importantes como la velocidad bruta de los puertos.

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

Un fabric de clúster de alto rendimiento no crea por sí solo una nube multi-inquilino. Los clientes necesitan direcciones privadas, control de rutas, acceso a internet y aislamiento entre ellos. La respuesta de CoreWeave es Nimbus, una arquitectura de red virtual que transfiere funciones de VPC a unidades de procesamiento de datos. La documentación pública identifica DPU NVIDIA BlueField-3 y describe VRF, VXLAN y rutas EVPN Type 5 en la arquitectura de seguridad.

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 de red virtual, imponer segmentación y preservar los recursos de la CPU del host para la carga. También puede mantener un límite de tenencia fuera del sistema operativo que el cliente quizás controle. La separación es una decisión de rendimiento y de seguridad.

Cómo se monta el overlay de VPC

Una instancia virtual de enrutamiento y reenvío separa un dominio de enrutamiento de otro. VXLAN transporta segmentos de inquilino sobre un underlay físico compartido. EVPN distribuye la alcanzabilidad, y las rutas Type 5 pueden anunciar prefijos IP en lugar de solo direcciones MAC individuales. Juntos, estos mecanismos permiten que CoreWeave presente una red privada utilizando infraestructura física común por debajo.

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

La DPU pasa a integrar la base de confianza

Nimbus reduce la exposición de las funciones de red del proveedor al host del cliente, pero aumenta 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 impone aislamiento debe ser observable y actualizable sin convertirse en un camino descontrolado hacia el entorno del inquilino.

Ese límite de control también afecta a la respuesta a incidentes. Un fallo de conectividad puede originarse en la carga del cliente, en una política de Kubernetes, en la configuración de la VPC, en el software de la DPU, en el plano de control EVPN o en el fabric físico. Los equipos de soporte necesitan evidencias que atraviesen esas capas sin dar a un inquilino visibilidad sobre otro. La documentación pública explica la arquitectura prevista, pero no publica un registro independiente para toda la flota de fallos de aislamiento o tiempos de reparación.

Kubernetes bare metal como superficie de control del cliente

El CoreWeave Kubernetes Service ofrece Kubernetes gestionado sobre infraestructura bare metal. El diseño evita una capa convencional centrada primero en máquinas virtuales entre la plataforma de contenedores y los servidores de GPU. Cada clúster recibe su propia VPC, y el servicio integra red y almacenamiento de alto rendimiento para cargas distribuidas.

El bare metal elimina una capa de abstracción, pero no hace el sistema simple. Kubernetes necesita descubrir GPU, exponer dispositivos, imponer cuotas, asignar pods e interactuar con plugins de red y almacenamiento. La plataforma debe coordinar imágenes de nodo, controladores, firmware, entornos de ejecución de contenedores y actualizaciones de clúster con la generación de hardware subyacente. El cliente gana una API conocida; CoreWeave asume una matriz de compatibilidad exigente.

Lo que Kubernetes puede decidir — y lo que no

Kubernetes puede decidir dónde debe ejecutarse un pod según la información y las políticas disponibles para el planificador. No conoce automáticamente cada rail, transceptor óptico, camino de switch o condición de rendimiento colectivo. CoreWeave necesita añadir plugins de dispositivo, operadores, información de topología y controles operativos para que una decisión lógica de planificación se corresponda con una asignación física viable.

La política de red también tiene un alcance limitado. Las políticas de Kubernetes pueden restringir el tráfico permitido entre cargas de trabajo, mientras que los controles de VPC y DPU ofrecen límites más amplios de tenencia y enrutamiento. Un objeto de política no prueba que el camino del paquete aplique la regla prevista. La configuración, la implementación y la observación deben coincidir.

SUNK transforma un clúster en supercomputador gestionado

SUNK se presenta como una oferta de supercomputador gestionado para producción. Combina infraestructura, fabric de alto rendimiento, orquestación de cargas de trabajo y operaciones de CoreWeave para clientes que quieren un gran entorno dedicado sin construir toda la instalación y el equipo operativo por su cuenta.

El servicio altera la división de responsabilidades. El cliente sigue siendo responsable de la arquitectura del modelo, el código, los datos y la estrategia de los trabajos, pero una parte mayor del ciclo de vida del hardware, de la cualificación del clúster y de la respuesta a incidentes pasa a CoreWeave. El resultado se parece a una instalación de HPC gestionada, entregada mediante contratos y software de la era de la nube, y no a un conjunto común de instancias intercambiables.

Mission Control convierte la operación en parte del producto

Mission Control añade monitorización, mantenimiento, reparación y soporte al ciclo de vida. Su importancia es más fácil de percibir cuando el trabajo es grande. Sustituir un componente defectuoso en un pequeño grupo de servidores puede tener una consecuencia limitada; diagnosticar un enlace degradado en una asignación fuertemente sincronizada puede decidir si miles de horas de acelerador serán útiles o se desperdiciarán.

El material de servicio de CoreWeave describe monitorización proactiva e intervención operativa. Esto establece el modelo previsto, no una disponibilidad verificada de forma independiente ni una distribución pública del tiempo medio de reparación. La ausencia de un censo completo de incidentes es relevante porque la fiabilidad es una de las principales razones por las que los clientes pagan a un proveedor en lugar de construir el clúster.

El almacenamiento forma parte del cálculo en red

Los datos de entrenamiento, los puntos de control y los artefactos del modelo recorren caminos de almacenamiento capaces de limitar toda la carga. Un clúster con un ancho de banda excepcional entre GPU puede detenerse si no puede leer entradas, escribir puntos de control o recuperar el estado con suficiente rapidez. 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 puntos de control crea un patrón operativo específico. Muchos workers pueden necesitar persistir el estado en intervalos coordinados. Esto puede generar ráfagas cuyo momento difiere de la comunicación colectiva. Si el tráfico de almacenamiento comparte recursos físicos con el fabric de entrenamiento, el diseño necesita aislamiento o planificación de capacidad. Si utiliza una red separada, la plataforma aún tendrá que coordinar el fallo y la recuperación en ambos caminos.

El almacenamiento también afecta a la portabilidad. Llevar un modelo a CoreWeave puede exigir grandes transferencias de entrada desde otra nube o entorno privado. Retirarlo puede generar coste, demora y fricción contractual. «Zero Egress Migration» es el mecanismo comercial de CoreWeave para reducir ciertos costes de migración hacia la plataforma; no debe confundirse con una garantía técnica, una salida universalmente gratuita o la prueba de que mover datos no tiene coste operativo.

Por eso, un cliente que evalúa la pila debe pedir evidencias de extremo a extremo. Los resultados pico del acelerador y del fabric son útiles, pero la carga de producción incluye la preparación de conjuntos de datos, los puntos de control, la actividad en el registro de modelos, los logs y la recuperación. Un benchmark que aísla una capa no responde a la cuestión económica de cuánto tarda en terminar el trabajo completo.

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

CoreWeave describe un backbone de nivel carrier que une centros de datos en América del Norte y Europa mediante fibra terrestre y submarina, con peering directo y servicios de conexión privada. El documento de la empresa enumera opciones de Direct Connect de 10, 100 y 400 Gbps, sujetas a ubicación y disponibilidad.

El backbone cumple una función diferente a la del fabric local de scale-out. Puede mover conjuntos de datos, réplicas, puntos de control, tráfico de control e inferencia entre regiones. Puede conectar usuarios y otras nubes. Puede apoyar la recuperación y la distribución. La latencia de propagación de larga distancia impide que convierta instalaciones remotas en un único fabric de entrenamiento de baja latencia para trabajos fuertemente acoplados.

La conectividad privada reduce un tipo de incertidumbre

Un circuito dedicado puede evitar parte de la variabilidad de enrutamiento de la internet pública y ofrecer un límite más claro de capacidad y soporte. No crea un mundo totalmente privado de extremo a extremo. El acceso del cliente puede depender de la operadora, del cross-connect y de la empresa del centro de datos. Los on-ramps de nube tienen sus propios procesos de aceptación y configuración. La diversidad de rutas y la propiedad física no se divulgan plenamente en cada ubicación.

Por tanto, CoreWeave no debe describirse como un operador Tier 1. Opera un backbone y hace peering, pero las evidencias proporcionadas no establecen una alcanzabilidad global sin pago de tránsito ni la propiedad de todo el camino de fibra. Su ventaja es el acceso integrado a su propio parque de cómputo, no sustituir el ecosistema mundial de operadoras.

El diseño regional crea elecciones de disponibilidad

CoreWeave informó instalaciones en seis países a finales de 2025. Un recuento de instalaciones no significa que cada generación de acelerador, fabric, servicio o velocidad de conexión privada esté disponible en cada país. Las regiones se abren en etapas porque la energía, la refrigeración, la red, el hardware y la preparación operativa no llegan al mismo tiempo.

Para los clientes, la geografía afecta a más que la latencia. Afecta a la gobernanza de datos, la proximidad de nubes, los equipos, la fuente de energía, la correlación de fallos y qué socio controla el camino local. Para CoreWeave, cada nuevo país añade coordinación jurídica, de suministro eléctrico y de cadena de suministro, además de capacidad. La expansión geográfica de la red es un modelo operativo, no un mapa de cajas idénticas.

La fiabilidad convierte el capital en tiempo útil

El hardware de CoreWeave sigue financiado mientras un trabajo progresa o espera. La fiabilidad, por tanto, es una variable financiera. Un fallo del fabric, una GPU degradada, un bloqueo del almacenamiento o un error del planificador pueden reducir la producción facturable y útil mientras los intereses, los arrendamientos y los compromisos de energía continúan.

Los stragglers importan más que los fallos completos

Un nodo con fallo es visible. Un straggler puede permanecer técnicamente activo y aún así retrasar todo punto de sincronización. Los trabajos grandes necesitan telemetría capaz de detectar la degradación del rendimiento, no solo la salud binaria. El planificador y el equipo de operaciones deben decidir si drenan, reemplazan o continúan usando el componente.

El registro público no proporciona una distribución completa de fallos de trabajos, latencia de cola o incidencia de stragglers. Esa ausencia no prueba una baja fiabilidad, pero limita las comparaciones independientes. Los clientes necesitan apoyarse en contratos, pruebas de carga y evidencia operativa propia, en lugar de extrapolar diagramas de arquitectura.

La cualificación es una prueba del sistema

Antes de exponer un clúster, CoreWeave debe cualificar conjuntamente servidores, switches, ópticas, cables, firmware, controladores, almacenamiento y orquestación. Pasar una prueba de arranque no basta. La prueba útil es si la topología completa soporta la carga prevista, sobrevive a fallos y puede repararse sin crear nuevas inconsistencias.

La cualificación también tiene una dimensión temporal. Un diseño que funcionó con un determinado conjunto de software y firmware puede comportarse de otra forma tras una actualización. La introducción rápida de nuevas generaciones de NVIDIA aumenta el número de combinaciones que CoreWeave debe soportar mientras los entornos más antiguos bajo contrato continúan en servicio. La madurez operativa consiste en administrar ese solapamiento sin convertir cada ubicación en una excepción única.

Las finanzas son una capa de la arquitectura

CoreWeave informó unos ingresos de 5,1 mil millones de dólares en 2025 y una pérdida neta de 1,2 mil millones. Pagó 10,3 mil millones en efectivo por propiedades y equipos durante el año. Al cierre del período, las obligaciones de desempeño restantes eran de 60,7 mil millones de dólares. El mismo documento describió grandes compromisos de financiación de equipos, deuda, arrendamiento e infraestructura.

Esas cifras describen cosas diferentes. Los ingresos son rentas por servicios reconocidas. El efectivo pagado por propiedades y equipos es una salida de inversión, no una valoración de la flota instalada completa. La pérdida neta muestra que el crecimiento aún no ha producido rentabilidad consolidada. Las obligaciones de desempeño restantes representan una prestación futura contratada según las normas contables, no dinero en el banco ni servicio ya entregado.

El primer trimestre de 2026 mostró demanda y coste de mantenimiento juntos

En el trimestre finalizado el 31 de marzo de 2026, CoreWeave informó 2.078 millones de dólares en ingresos, una pérdida neta de 740 millones y un gasto por intereses de 536 millones. También informó un backlog de 99,4 mil millones según su definición. Los resultados demuestran una fuerte visibilidad de la demanda y una pesada carga financiera en el mismo período.

El backlog no es directamente intercambiable con las obligaciones de desempeño restantes de finales de 2025. Las definiciones y los momentos son diferentes. Ambos indican una demanda futura contratada, pero la conversión depende de que CoreWeave ponga en servicio instalaciones, energía, hardware y capacidad de red y cumpla los contratos. Cuanto más convincente sea el backlog, mayor será la obligación de entrega vinculada a él.

La financiación garantizada por GPU alinea activos y contratos

CoreWeave ha utilizado préstamos garantizados, financiación de equipos y estructuras respaldadas por clientes para financiar la expansión. En junio de 2026, anunció una línea de 8,5 mil millones de dólares descrita como garantizada por GPU y con calificación de grado de inversión para la transacción específica. La línea amplía la capacidad de implantación; no es ingreso ni establece el grado de inversión para toda la obligación corporativa.

La financiación garantizada por activos puede alinear la deuda con el hardware y los flujos de caja contratados. También puede crear restricciones en torno a las garantías, la implantación y el uso del efectivo. Los aceleradores, los switches y las ópticas envejecen rápidamente en comparación con muchos activos tradicionales de infraestructura. El modelo funciona mejor cuando la utilización se mantiene alta y los contratos duran más allá del período en que el equipo tiene mayor valor económico.

El diseño de la red, por tanto, afecta a la calidad crediticia. Una topología que ofrece una mayor utilización eleva la producción de los activos financiados. Una ubicación retrasada, un problema persistente de stragglers o una migración fallida puede reducirla. En el modelo de CoreWeave, la ingeniería de sistemas y la ingeniería del balance cuentan la misma historia.

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

Microsoft representó el 67% de los ingresos de CoreWeave en 2025. Un gran cliente ancla puede justificar capacidad, apoyar la financiación y dar al proveedor confianza para comprar equipos con antelación. La misma concentración otorga poder de negociación al cliente y hace que la utilización sea sensible a una única relación comercial.

CoreWeave anunció o informó relaciones con otros clientes, incluidos Meta y Anthropic. Flow Traders eligió a la empresa para el entrenamiento de modelos fundacionales en julio de 2026, y Leidos anunció una colaboración en IA para defensa, seguridad nacional e inteligencia. Estas declaraciones establecen contratos, elecciones o colaboración al nivel descrito por las fuentes. No prueban que la concentración haya desaparecido ni que toda la capacidad anunciada esté ya implantada.

Los contratos take-or-pay transfieren el riesgo sin eliminarlo

Los contratos plurianuales take-or-pay pueden dar a CoreWeave visibilidad de la demanda y apoyar la financiación. Transfieren parte del riesgo de utilización del proveedor al cliente porque los pagos comprometidos no dependen solo del consumo a corto plazo. No eliminan los riesgos de construcción, energía, entrega, rendimiento, crédito o renegociación.

Para los clientes, el contrato invierte parte de la promesa de la nube. La nube pública tradicional enfatiza el consumo elástico y el poco compromiso. Un clúster dedicado de IA puede exigir una relación más larga, similar a la de infraestructura, porque el proveedor ha construido o reservado capacidad específica. El servicio puede parecer software de nube en la interfaz y comportarse como financiación de proyectos por debajo.

Defensa y trabajo regulado elevan el nivel de garantía

La colaboración con Leidos, anunciada el 30 de julio de 2026, extiende la plataforma a misiones de defensa e inteligencia. Esta colaboración no establece todas las autorizaciones, certificaciones o implantaciones necesarias para el trabajo regulado. Indica, no obstante, que la seguridad, el control de la cadena de suministro, la auditabilidad y la continuidad operativa pueden convertirse en partes más importantes del producto de CoreWeave.

Una VPC impuesta por DPU, la conectividad privada y las operaciones gestionadas pueden apoyar un proyecto de alta garantía. No sustituyen los controles específicos del programa, los requisitos de personal, el tratamiento de datos y la aprobación gubernamental. Cuanto más se acerque la empresa a cargas sensibles a la misión, más transparentes deben ser sus límites de responsabilidad.

Las adquisiciones mueven la pila hacia arriba, mientras que la fusión fallida apuntaba hacia abajo

En 2025, CoreWeave adquirió Weights & Biases, OpenPipe, marimo y Monolith AI. Weights & Biases añadió herramientas de desarrollo y observabilidad de modelos; las demás adquisiciones ampliaron las capacidades de inferencia, notebooks e IA industrial. Las transacciones llevan a CoreWeave por encima de la infraestructura bruta hacia una porción mayor del ciclo de desarrollo.

La lógica estratégica es clara. Un proveedor que comprende los flujos de trabajo de los modelos puede mejorar la predicción de la demanda, facilitar el consumo de la infraestructura y retener a los clientes en más etapas del desarrollo. El riesgo de integración es igualmente claro. Las empresas de software tienen ciclos de lanzamiento, márgenes y culturas diferentes a las operaciones financiadas de centros de datos. La superposición de productos y el conflicto con los socios pueden surgir si CoreWeave intenta poseer herramientas que los clientes antes obtenían de proveedores independientes.

La propuesta de adquisición de Core Scientific apuntaba en la dirección opuesta. CoreWeave anunció un acuerdo de fusión en julio de 2025 que habría ampliado el control sobre la capacidad de centros de datos y la economía de los arrendamientos. Core Scientific puso fin al acuerdo el 30 de octubre de 2025 tras la votación de sus accionistas. CoreWeave no adquirió la empresa.

En conjunto, las transacciones revelan una estrategia de integración en dos direcciones: subir hacia el software de desarrollador y bajar hacia la capacidad física. La fusión fallida también muestra que el control de la infraestructura no siempre puede comprarse en el calendario deseado por la plataforma. Los accionistas, los reguladores, la financiación y la estructura contractual pueden bloquear la lógica técnica de la integración vertical.

Lo que CoreWeave controla — y lo que permanece fuera de sus límites

CoreWeave controla la plataforma del cliente, muchas decisiones de diseño, la cualificación de los equipos, la orquestación y los procesos operativos. Puede elegir cómo Nimbus mapea las VPC, cómo se presentan los clústeres, qué servicios se gestionan y cómo se tratan los incidentes. Puede comprar hardware con antelación y organizar las instalaciones en torno a la densidad de aceleradores.

NVIDIA controla las hojas de ruta críticas de las GPU, NVLink, InfiniBand, Spectrum-X y BlueField. Las compañías eléctricas y los socios de centros de datos controlan partes de la entrega de energía y las instalaciones. Las operadoras de fibra, los puntos de intercambio y los proveedores de nube controlan partes de la conectividad externa. Los acreedores y los financiadores de equipos limitan el uso del capital. Los grandes clientes influyen en la planificación de la capacidad mediante contratos.

Esto no es un defecto exclusivo de CoreWeave. Toda nube depende de proveedores e instalaciones. La concentración es relevante porque la diferenciación de CoreWeave está estrechamente ligada al despliegue rápido de sistemas NVIDIA y porque sus compromisos de capital son inusualmente grandes frente a su historial operativo. Un retraso o un cambio en la hoja de ruta de un proveedor puede propagarse a través de la entrega al cliente y de la financiación.

La fortaleza de la plataforma es coordinar esos límites. Su riesgo es la dependencia correlacionada: la misma generación de proveedor, el diseño de ubicación o el programa de cliente pueden afectar a varias capas al mismo tiempo. La integración reduce el número de contratos que el cliente necesita administrar, pero puede aumentar el impacto de un fallo a nivel del proveedor.

Posición competitiva: una nube especializada es una elección sobre la responsabilidad

CoreWeave compite con nubes a hiperescala, otras nubes especializadas en GPU, clústeres propios de clientes y combinaciones de colocation, hosting e integración gestionada. La comparación no puede reducirse al recuento de GPU o a un benchmark. Los compradores comparan la generación del hardware disponible, el fabric, el almacenamiento, la planificación, la conectividad privada, el soporte, la duración del contrato, la geografía y el coste total del movimiento de datos.

Frente a las nubes a hiperescala

AWS, Microsoft Azure, Google Cloud y Oracle ofrecen carteras amplias, ecosistemas globales y grandes balances. Pueden combinar infraestructura de IA con bases de datos, seguridad, analítica y procesos de compra corporativa que los clientes ya utilizan. La respuesta de CoreWeave es la especialización: integración más rápida de generaciones seleccionadas de NVIDIA, orquestación bare metal y una plataforma creada para cargas densas de aceleradores.

La especialización puede reducir la abstracción y acortar la cualificación. También puede crear un perfil más estrecho de fallos y proveedores. Un cliente que elige CoreWeave puede ganar un proveedor concentrado en la carga y aceptar una menor amplitud de servicios y una estructura de capital más joven. La comparación correcta es específica para la carga, no categórica.

Frente a otras nubes especializadas

Lambda, Nebius, Crusoe y otros proveedores de infraestructura de IA se superponen en la oferta de aceleradores, clústeres y servicios gestionados. Las diferencias incluyen la geografía, la estrategia energética, la cartera de software, la propiedad, la estructura de capital y el grado de control de las instalaciones. «Neocloud» es una etiqueta de mercado, no una arquitectura común.

Los documentos de empresa cotizada de CoreWeave ofrecen evidencias inusualmente detalladas sobre escala y riesgo. No establecen por sí solos una tecnología o economía superiores. Un competidor con menos divulgación puede ser más pequeño, más eficiente o simplemente más opaco. El análisis no debe transformar la transparencia en un ranking de rendimiento.

Frente a la construcción de un clúster privado

Un clúster propio del cliente da al comprador control directo del hardware, los datos y las operaciones. También exige adquisición, energía, instalaciones, red, almacenamiento, seguridad, firmware, piezas de repuesto y personal especializado. CoreWeave vende la transferencia de gran parte de esa carga.

La transferencia es incompleta. Los clientes aún diseñan las cargas, administran los datos, definen las políticas y evalúan el riesgo del proveedor. Los compromisos largos pueden reducir la flexibilidad para cambiar. Un clúster privado corre el riesgo de subutilización dentro del cliente; un contrato de nube, de dependencia del proveedor. La elección económica es qué parte está más preparada para absorber la variabilidad y mantener productivo el sistema caro.

La conmutación con refrigeración líquida muestra hacia dónde puede migrar el próximo cuello de botella

En julio de 2026, CoreWeave publicó material sobre conmutación con refrigeración líquida diseñada para aumentar la densidad de ancho de banda por rack. La afirmación está vinculada a la arquitectura y los cálculos de la empresa, no a un benchmark independiente de toda la flota. El mecanismo, sin embargo, es importante: a medida que aumenta la densidad de aceleradores, los switches y las ópticas consumen energía y producen suficiente calor como para integrar el problema de refrigeración del rack.

Refrigerar un switch con líquido puede permitir más capacidad de red dentro de un envolvente limitado del rack y reducir la necesidad de situar la conmutación más lejos. Los caminos más cortos pueden simplificar los cables y preservar la densidad. El diseño también conecta el mantenimiento de la red al sistema de refrigeración líquida. Una fuga, un fallo de bomba o un procedimiento de servicio pueden afectar a componentes antes tratados como equipos de red refrigerados por aire.

El cambio ilustra un patrón más amplio. Los cuellos de botella de la infraestructura de IA migran. Las GPU más rápidas crean demanda de más ancho de banda de scale-up. Más ancho de banda en el rack exige una conmutación de scale-out más densa. Una conmutación más densa aumenta los requisitos de potencia y refrigeración. Las nuevas instalaciones pasan a necesitar diseños mecánicos y eléctricos diferentes. Una generación de producto, por tanto, no es solo una actualización de servidor; puede ser un rediseño del centro de datos.

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

El material de CoreWeave de julio de 2026 describe la preparación para los sistemas NVIDIA Vera Rubin NVL72 y realiza afirmaciones medidas por la empresa o prospectivas sobre tokens por megavatio en comparación con Blackwell. Las afirmaciones deben atribuirse a CoreWeave y a la configuración nombrada. No establecen la disponibilidad en toda la flota en el momento de la investigación.

Una nueva generación cambia varias capas al mismo tiempo: acelerador, fabric de scale-up, ancho de banda de scale-out, potencia por rack, refrigeración, firmware, controladores, orquestación y cualificación. Puede mejorar la producción por megavatio y hacer que las instalaciones existentes sean inadecuadas o menos competitivas. La capacidad de CoreWeave para adoptar hardware nuevo rápidamente solo es una fortaleza estratégica si la empresa consigue administrar la migración, la utilización y la depreciación de los activos contratados más antiguos.

La transición también profundiza la dependencia de NVIDIA. El acceso anticipado puede atraer clientes y sostener contratos premium. Puede exponer a la empresa a los plazos, los precios y las decisiones de arquitectura de un proveedor que no controla. La diversificación en la capa de clientes o de software no necesariamente diversifica la pila física.

El efecto más amplio de la pila sobre la infraestructura digital

La expansión de CoreWeave afecta a mercados que van mucho más allá del alquiler de GPU. Los compromisos en gigavatios crean demanda de generación, interconexión a la red eléctrica, transformadores, refrigeración, terrenos y construcción. Los fabrics de alta radix exigen switches, ópticas y fibra. La conectividad privada crea demanda de capacidad de operadoras, presencia en puntos de intercambio y on-ramps de nube. Las estructuras de financiación requieren acreedores capaces de evaluar tecnología que envejece rápidamente frente a contratos largos.

La plataforma también cambia dónde aparece el tráfico de internet. El tráfico de entrenamiento fuertemente acoplado permanece sobre todo en los fabrics locales, pero los conjuntos de datos, los puntos de control, los artefactos del modelo, las solicitudes de inferencia y los flujos de trabajo de los desarrolladores circulan entre nubes, centros de datos y usuarios. El impacto visible sobre internet puede, por tanto, provenir menos de un enorme flujo de entrenamiento y más del movimiento persistente alrededor del entorno de entrenamiento.

Para las comunidades y redes eléctricas que reciben instalaciones, la pila es una decisión de energía y uso del suelo. El paquete de investigación no ofrece evidencia local suficiente para una conclusión ambiental sobre toda la empresa. Establece que la potencia activa y contratada son medidas materiales del crecimiento y que los retrasos en la entrega de energía o instalaciones constituyen riesgos de negocio.

Para los ingenieros de red, la arquitectura muestra que la infraestructura de IA se está convirtiendo en una disciplina propia. El conocimiento de enrutamiento y conmutación sigue siendo necesario, pero ahora se encuentra con bibliotecas colectivas, topología de aceleradores, refrigeración líquida, planificación de cargas de trabajo y financiación de proyectos. La persona que ajusta la congestión puede estar protegiendo tanto la finalización del trabajo como el servicio de la deuda.

Lo que las evidencias públicas no pueden mostrar

CoreWeave publica documentación de producto, blogs técnicos y estados financieros, pero la pila permanece parcialmente opaca. El material proporcionado no contiene la topología actual completa, el inventario del fabric por ubicación, la tabla de sobresuscripción, el mapa de propiedad de la fibra, el historial de incidentes o un archivo independiente de benchmarks por carga de trabajo.

Ese límite debe cambiar la formulación de las afirmaciones. La documentación de arquitectura puede establecer mecanismos. Los registros de la SEC pueden establecer hechos financieros consolidados y riesgos. Los comunicados con clientes nombrados pueden establecer la selección o la colaboración. Ninguna de esas fuentes prueba un resultado universal de carga de trabajo, un tiempo de actividad para toda la flota o un coste total menor para todo comprador.

La misma cautela vale para la escala. La potencia activa no es potencia contratada. El backlog no es ingreso. Una teleconferencia de resultados futura programada no es un resultado. Un acuerdo anunciado con un cliente no equivale a una utilización activa. Una adquisición propuesta no es propiedad. Una futura generación de hardware no es la flota actual.

Estas distinciones no debilitan el perfil. Identifican la brecha real de información que el lector profesional necesita gestionar. CoreWeave pide a clientes y proveedores de capital que confíen en un sistema integrado cuyos detalles más valiosos son necesariamente privados. La respuesta racional no es presumir la excelencia ni el fracaso. Es exigir evidencia al nivel del contrato, del clúster y de la ubicación que se esté considerando.

El juicio central

El producto de CoreWeave suele describirse como capacidad de cómputo. El producto más profundo es la coordinación. La empresa debe coordinar las hojas de ruta de los proveedores con la construcción de centros de datos, los enlaces de scale-up con los fabrics de scale-out, la política de DPU con la intención del inquilino, la planificación de Kubernetes con la topología física, el almacenamiento con el comportamiento de los puntos de control, la conectividad de backbone con el acceso del cliente y la financiación a largo plazo con las generaciones cortas de hardware.

Esa coordinación puede crear una ventaja real. Un proveedor especializado puede tomar decisiones sobre toda la carga en lugar de pedir al cliente que reúna proveedores separados. Puede cualificar sistemas, reparar fallos e introducir nuevas generaciones más rápido de lo que muchas empresas podrían hacerlo solas. El crecimiento acelerado de la plataforma sugiere que los grandes clientes valoran esa transferencia de responsabilidad.

La misma integración concentra las consecuencias. Un diseño de fabric, un retraso del proveedor, un error de política, una restricción de financiación o un cambio en el cliente ancla pueden afectar a gran parte del sistema. El futuro de la empresa no depende de una cifra llamativa de ancho de banda. Depende de que todas las capas sigan convirtiendo la capacidad financiada en trabajo fiable para los clientes.