摘要

  • CoreWeave 的网络栈涵盖纵向扩展（scale-up）、横向扩展（scale-out）、存储、租户、管理、骨干网和专线连接；它是一种运行架构，而非独立产品。
  • NVIDIA 的网络和 DPU 与 CoreWeave 的软件相结合，可以在专业云上调度加速器、隔离租户和移动数据。
  • CoreWeave 报告了 43 个数据中心、超过 850 兆瓦的活跃电力以及约 3.1 吉瓦的合同电力；微软贡献了 2025 年 67%的收入，彰显了规模与集中度。
  • 真正的考验是将合同电力和储备订单转化为可靠、多样化的服务，抢在财务成本、租金、硬件过时和运营复杂性累积之前完成。

物理基础设施的增长速度比普通云区域地图所暗示的要快

截至 2025 年 12 月 31 日，CoreWeave 报告了 43 个数据中心、超过 850 兆瓦的活跃电力以及约 3.1 吉瓦的合同电力。活跃电力指标描述的是按公司定义在该日期已投入运营的基础设施。合同电力描述的是未来部署的权利和承诺，不应被表述为已装机容量。

增长曲线非常陡峭：2023 年底，10 个数据中心和约 70 兆瓦活跃电力；2024 年底，32 个数据中心和超过 360 兆瓦；2025 年底，43 个数据中心和超过 850 兆瓦。到 2026 年第一季度，CoreWeave 报告了超过 1 吉瓦的活跃电力和超过 3.5 吉瓦的合同电力。这些数字表明一家公司试图以工业化的速度扩张设施和运营，同时也表明昨天的架构可能很快就在整个机群中居于少数。

电力是前提条件，不是成品。一兆瓦合同电力仍然需要并网接入、发电或电网供电、高密度配电、冷却、建筑就绪、网络路径、加速器交付和运营验收。任何层面的延迟都可能推迟收入，而某些义务在之前就可能开始产生。

数据中心模式是混合的。CoreWeave 拥有设备并控制大量部署，但使用租赁设施和第三方提供商。这可以加快地理扩张，避免公司自己建造每一栋建筑。但这也使业主绩效、施工进度、电力交付和合同条款成为平台可靠性的一部分。

一块 GPU 还不是一朵云

安装在通电机架中的加速器可以运行代码，但它本身并不能交付客户从云中购买的东西。训练团队需要许多加速器像一个整体分配那样工作。数据需要以所需速度从存储中输送出来。集合操作必须跨越 GPU 而不会让大部分作业等待通信。租户必须保持隔离。调度器必须知道哪些节点、链路和设备是健康的。检查点必须在故障后幸存。工程师需要一条入站路由，用户需要通往其他云、办公室和服务的出站路由。只有当这些路径变得可复现时，云产品才算开始存在。

因此，AI 云的网络不能被视为计算的一个附件。在传统企业架构中，网络通常被描述为连接服务器的系统。在分布式 AI 中，它直接参与有效计算。一个同步作业可能因为一个降级的光模块、一个慢速加速器、一条拥塞的通道或一条跟不上速度的存储路径而延迟。当作业在等待时，硬件闲置的成本仍在累加。网络设计不仅影响基准测试，还影响每一小时资助的 GPU 的经济性。

CoreWeave 的平台是一个好的研究对象，因为它使这种关系尤为可见。该公司专门从事加速器基础设施，而不是将 GPU 当作一个通用云中的小服务来提供。因此，其公开材料对机架内网络结构、数据处理单元、裸金属编排、托管超级计算机、专用连接和运行修复进行了描述，比一个简单的实例目录详细得多。这些描述体现了设计意图和产品架构，但并不是每处地点、每一代产品或每个客户部署的完整地图。

问题不在于 CoreWeave 在抽象意义上是否拥有一张快速网络。有用的问题是，在 AI 工作负载能作为可靠服务运行之前，有多少张不同的网络必须协同工作——以及每一张网络分别由谁控制。

“CoreWeave 网络栈”这个术语究竟指什么

该表述是一个编辑意义上的统称，不是法律实体，也不是单独出售的 SKU。法律和经济运营实体是 CoreWeave, Inc.，一家特拉华州公司，总部位于新泽西州利文斯顿，在纳斯达克上市，股票代码为 CRWV。网络栈属于更广泛的 CoreWeave 云平台的一部分，该平台还包括计算、存储、编排和托管服务。

不同的名称描述不同的层级。Nimbus 是 CoreWeave 基于 DPU 的虚拟网络架构。CoreWeave Kubernetes Service（CKS）提供托管的裸金属 Kubernetes。SUNK 将基础设施和运营集合成一个托管超级计算机服务。Mission Control 增加了监控、修复和生命周期支持。Direct Connect 提供客户专线连接。NVIDIA 的名称，如 NVLink、NVSwitch、Quantum、Spectrum-X 和 BlueField，指的是 CoreWeave 集成的供应商技术，而非其自有发明。

将这些层分开可以避免两个常见错误。第一个是将每一个协议或平台设备都归于公司。CoreWeave 的贡献在于围绕供应商技术进行系统集成、认证、运营和云软件的开发。第二个错误是想象一种从每一块 GPU 到每一位客户都一致的统一网络结构。节点内的纵向扩展链路、跨机架的训练网络结构、存储网络、VPC 叠加层、管理路径和跨大西洋骨干网拥有不同的用途、延迟预算和故障域，不应被压缩进一个单一的带宽数字。

同样的规则也适用于所有权。CoreWeave 安装并运营大量设备，但其文件也描述了租赁、第三方数据中心、电力承诺、光纤关系和设备融资。一个服务可以在运营上进行集成，但公司并不拥有建筑物、公用事业、长途路由或机架内的每一个组件。“垂直整合”只有在指代对企业多个层的协调控制时才有用，而不是意味着完全自给自足。

从 Atlantic Crypto 到专业计算

CoreWeave 始于 2017 年，当时名为 The Atlantic Crypto Corporation。最初的业务使用 GPU 资产进行加密货币工作负载，公司于 2018 年 9 月从 LLC 转为特拉华州公司。2019 年 12 月，其改用 CoreWeave 的名称，并转向专业云中的计算业务。

这段渊源有时被简单概括为加密货币挖矿和人工智能之间的奇特对比。更重要的连续性是运营上的。两项业务都要求所有者采购加速器、确保电力供应、保持高密度硬件运行，并将工作负载引导至闲置容量。这家早期公司在建立租户、网络、存储和支持等云系统之前，先学会了加速器机队的经济性。

这一区别很重要，因为需求的转变并不会自动创造出一个平台。挖矿工作负载可以相对重复，并容忍一个简单的资产管理模式。视觉效果、机器学习和高性能计算则需要不同的软件、数据移动、隔离和服务保证。CoreWeave 需要增加让外部客户能够信任他们并不拥有且无法实际检查的资源的那些层。

到 2020 年代初，公司开发了专业的计算、存储和 Kubernetes 服务。裸金属 Kubernetes 成为一个重要接口：客户可以直接在加速器服务器上调度容器化作业，而无需先经过一层传统的虚拟机。到 2023 年底，CoreWeave 报告了 10 个数据中心和约 70 兆瓦的活跃电力。到 2024 年底，拥有 32 个数据中心和超过 360 兆瓦。

扩张改变了网络问题的性质。拥有十处站点的运营商仍然可以非常依赖专家知识和本地特例。拥有三四十处站点的云则需要可复现的设计、软件驱动的策略、统一的认证、共享的监控，以及一种在硬件代际间迁移客户而不损失运营一致性的方式。规模将良好的工程决策转化为治理问题：谁可以批准变更，异常情况被发现的有多快，以及每一处新站点是否复现了预期的控制边界。

CoreWeave 于 2025 年 3 月完成了首次公开募股。上市不仅增加了股权资本，还产生了美国证券交易委员会（SEC）的招股说明书和证据，内容涵盖设施、客户集中度、债务、租赁、互联架构和风险。这些记录使得我们可以将网络栈同时作为技术系统和上市公司的承诺来研究。

工作负载决定架构

大模型训练将计算分布在多个加速器之间，并反复交换部分结果。精确的通信模式取决于模型架构、并行化方法和软件，但基础设施问题是恒定的：分配单元的有效速度既取决于集合通信，也同样取决于本地计算。一张在聚合带宽上看似很快的网络结构，如果因拥塞、拓扑结构或尾部延迟而拖慢了保持作业同步的那些同步点，仍然可能浪费容量。

该栈还必须处理行为不同于集合操作的流量。数据集进入环境。检查点从 GPU 内存中写出并到达存储。控制系统分发作业和策略。工程师获取日志。服务暴露推理端点。备份和副本可能跨区域传输。每一类流量对延迟和丢包的容忍度不同。将一切视为没有区分的单一网络，会使性能难以预测，故障难以隔离。

这催生了一种分层设计。纵向扩展链路在一个机架级系统内创建一个紧耦合域。横向扩展网络结构将多个系统跨机架连接起来。存储路径为负载提供输入并进行持久化。租户网络提供私有地址和策略。管理网络让运营者控制主机、DPU、交换机和修复流程。骨干网连接设施和外部生态系统。客户专线电路将云与其他管理域相连。

各层会交互，但不可互换。长距离光纤不能替代本地 GPU 结构，因为传播延迟本身就阻碍了在相距遥远的站点间进行严格同步的训练。一个 NVLink 域不能作为客户 VPC 来使用。叠加层可以隐藏地址差异，但不能修复底层有故障的光模块。Kubernetes 可以在不理解物理通道的情况下调度 Pod，除非平台提供了拓扑信息和设备集成。

因此，架构是一个被层层翻译的意图链。客户请求集群、命名空间、网络或作业。CoreWeave 的控制系统将请求映射到可用的服务器、网络结构、存储和策略。Nimbus 将 VPC 意图翻译为 DPU 状态和底层。与 Kubernetes 和 Slurm 相关的服务将工作负载意图翻译为节点和加速器。Mission Control 将健康信号翻译为修复动作。客户看到的是一个服务；平台则需要保持这些翻译的一致性。

机架域内的纵向扩展网络

纵向扩展网络在一个紧密集成的系统内连接加速器。在 NVIDIA 的机架级设计中，NVLink 提供 GPU 到 GPU 的高带宽通信，而 NVSwitch 在该局部域内执行交换。CoreWeave 在选定的系统和代次中采用了这些技术。

重要的所有权不在于品牌名称，而在于邻近性。纵向扩展域允许模型分区和集合操作交换数据，而无需每一步都穿越数据中心公共网络。这可以使一个机架更像一个大型加速器系统，而不是一组独立服务器。它也创建了一个独特的故障域：机架内的交换机、线缆、散热问题或组件缺陷可能影响到调度器预期共同使用的许多 GPU。

CoreWeave 的招股说明书描述了某些集群配置，其 GPU 互联带宽最高可达每秒 3200 吉比特的非阻塞配置。“某些集群配置”这一表述承载了大部分证据权重。它并没有确立一个通用的服务水平，也没有描述每一处站点或每一代加速器。工作负载可用的有效带宽还取决于软件、拓扑、消息模式以及整条路径的健康状况。

纵向扩展设计在减少一个瓶颈的同时，也提高了另一个瓶颈处的密度。更多的加速器和更大的本地带宽提升了每个机架的功率、散热和维护要求。一个集中计算能力却没有相匹配的热设计与运行设计的系统，可能更难维修，或者将瓶颈转移到横向扩展链路和存储上。架构必须被解读为组件之间的平衡，而不是一组最大规格的罗列。

横向扩展结构：InfiniBand 和 Ethernet 并存

当作业越过纵向扩展边界时，就进入横向扩展网络结构。CoreWeave 的公开文件和技术材料描述了 NVIDIA Quantum-2 InfiniBand、800 吉比特的 Quantum-X800 XDR 结构，以及支持 RoCE 和 RDMA 的 Spectrum-X Ethernet。InfiniBand 和 Ethernet 的同时存在意义重大：公司并没有将平台身份绑定到单一的协议家族上。

InfiniBand 用于紧耦合集群

InfiniBand 专为低延迟、远程直接内存访问（RDMA）的通信而设计，在高性能计算领域拥有悠久历史。在 AI 集群中，它可以在加速器主机之间移动数据，同时避免部分常规主机处理。NVIDIA 的 Quantum 系统增加了面向集合操作的交换和功能，适用于大型同步负载。CoreWeave 将这些结构集成到集群产品中，而不是把 InfiniBand 作为独立的运营商服务出售。

公开证据并未揭示完整的拓扑细节、超额订阅率、路由策略或服务限制。“非阻塞”可能描述的是某一特定设计，而非整个机群。即使设计良好的结构也可能因降级的光模块、糟糕的分配、不均衡的流量或制造热点的软件行为而受损。买家应询问其获得集群的硬件代次、拓扑和质量认证。

Spectrum-X 和 RoCE 作为 Ethernet 路径

Spectrum-X 是 NVIDIA 面向 AI 的 Ethernet 网络平台。RoCE 在 Ethernet 上承载 RDMA 语义，允许直接内存访问，同时运营商可以维持一个基于 Ethernet 的网络结构。CoreWeave 采用 Spectrum-X，为围绕该生态系统设计的工作负载和系统代次提供了一种替代性的横向扩展路径。

熟悉 Ethernet 并不意味着可以毫不费力地运行。RoCE 的性能取决于拥塞控制、队列设计、丢包行为、遥测和端到端配置。一张网络可以使用熟悉的 Ethernet 帧，但仍需要专业工程以避免队头阻塞、incast 或不稳定的集合性能。集成云的价值在于提供商承担了其中大部分的调优工作。相应的风险是客户对底层选择的直接可见性更低。

面向通道的拓扑与分配优化

多通道系统将网络接口和对应的加速器分组，使集合流量沿多条平行的规整路径传输。面向通道的优化设计可以减少不必要的交叉，并使带宽更加可预测。这也要求调度器理解拓扑：将作业分配到错误的节点组合上，可能会完全抵消物理设计。

通道也可能集中故障。如果某条通道发生降级，所有使用该路径的节点即使在其他接口仍然健康时也可能成为拖慢者。操作系统需要区分一台有缺陷的服务器和一次共享性的网络降级。正因如此，拓扑感知的遥测、质量认证和修复才与端口原始速率同等重要。

Nimbus 将云边界推向 DPU

仅靠高性能集群结构并不能单独创建多云租户的云。客户需要私有地址、路由控制、互联网访问和相互隔离。CoreWeave 的答案是 Nimbus，一种虚拟网络架构，它将 VPC 功能转移到了数据处理单元（DPU）上。公开文档标明使用了 NVIDIA BlueField-3 DPU，并描述了安全架构中的 VRF、VXLAN 和 EVPN Type 5 路由。

DPU 处在客户控制的计算和提供商控制的基础设施之间的特权位置。它可以处理虚拟网络流量、执行分段，并为主机 CPU 节省出资源用于工作负载。它还可以在客户可能控制的操作系统之外维护租户边界。这种分离既是性能决策，也是安全决策。

VPC 叠加层是如何构建的

虚拟路由转发（VRF）实例将一个路由域与另一个分隔开。VXLAN 在共享的物理底层之上传输租户分段。EVPN 分发可达性信息，而 Type 5 路由可以宣告 IP 前缀，而非仅仅单个 MAC 地址。这些机制结合后，使 CoreWeave 能够使用共同的物理基础设施来呈现一个私有网络。

叠加层并不能消除对底层的依赖。如果物理可达性发生故障，虚拟网络也会随之失效。如果路由分发出错，隔离或可达性可能在大规模范围出现崩溃。如果 DPU 镜像或策略系统包含错误，大量主机可能迅速获得相同的错误状态。云的抽象通过将复杂性转移给提供商降低了客户的难度，但并没有消除复杂性。

DPU 成为信任基的一部分

Nimbus 减少了提供商网络功能暴露给客户主机的程度，但提高了 DPU 固件、安全启动、密钥、策略分发、日志和恢复的重要性。一个强制隔离的设备需要具备可观测性并能够更新，同时不能成为通往租户环境的不可控路径。

这一控制边界也影响事件响应。一次连通性故障可能源自客户的工作负载、Kubernetes 策略、VPC 配置、DPU 软件、EVPN 控制平面或物理网络结构。支持团队需要能够横跨这些层获取证据，同时不给一个租户查看另一个租户的可见性。公开文档解释了预期的架构，但并未对跨整个机群的隔离故障或修复时间发布一份独立记录。

裸金属 Kubernetes 作为客户控制面

CoreWeave Kubernetes Service 在裸金属基础设施上提供托管 Kubernetes。该设计避免了在容器平台和 GPU 服务器之间先有一层传统的以虚拟机为中心的中间层。每个集群获得自己的 VPC，该服务为分布式负载集成了高性能网络和存储。

裸金属移除了一个抽象层，但并不会让系统变得简单。Kubernetes 需要发现 GPU、暴露设备、执行配额、调度 Pod，并与网络和存储插件交互。平台必须协调节点镜像、驱动、固件、容器运行时和集群升级，同时与脚下的硬件代次保持同步。客户获得了一个熟悉的 API；CoreWeave 则承担了一个要求严苛的兼容性矩阵。

Kubernetes 能决定什么——以及不能决定什么

Kubernetes 可以根据调度器可用的信息和策略来决定一个 Pod 应该在何处运行。它并不会自动了解每一通道、光模块、交换机路径或集合性能状况。CoreWeave 需要增加设备插件、Operator、拓扑信息以及运营控制，以使逻辑调度决策对应到一项可行的物理分配。

网络策略的作用范围也有限。Kubernetes 策略可以限制工作负载之间允许的流量，而 VPC 和 DPU 控制则提供更广泛的租户和路由边界。一个策略对象并不能证明数据包路径真正执行了预期的规则。配置、实现和观测必须一致。

SUNK 将集群转变为托管超级计算机

SUNK 被定位为一种面向生产的托管超级计算机产品。它将基础设施、高性能网络结构、工作负载编排和 CoreWeave 的运营结合起来，面向那些希望拥有大型专用环境，但不想自己建造整个设施并组建运营团队的客户。

该服务改变了责任划分。客户仍对模型架构、代码、数据和作业策略负责，但硬件生命周期、集群质量认证和事件响应的更大部分转由 CoreWeave 承担。其结果更像一座托管的 HPC 设施，通过云时代的合同和软件交付，而不是一套彼此可互换的通用实例。

Mission Control 使运营成为产品的一部分

Mission Control 增加了监控、维护、修复和生命周期支持。当作业规模很大时，其重要性更容易察觉。在一个小型服务器池中替换一个有缺陷的组件可能后果有限；而在一个紧同步的分配中诊断一个降级链路，则可能决定数千个加速器小时是被有效利用还是被浪费。

CoreWeave 的服务材料描述了主动监控和运营干预。这确立了预期的模型，而非独立验证的可用性或公开的平均修复时间分布。缺少完整的事件普查是有影响的，因为可靠性正是客户向提供商付费，而不是自己建造集群的关键原因之一。

存储是网络计算的一部分

训练数据、检查点和模型工件经过的存储路径能够限制整体负载。一个 GPU 间带宽出众的集群，如果无法足够快地读取输入、写入检查点或恢复状态，仍然可能停滞。CoreWeave 平台包含对象存储和文件存储，并将高性能数据移动作为服务的一部分进行描述。

检查点流量创造了一种特定的运行模式。许多 Worker 可能需要在协调一致的间隔内持久化状态。这会产生与集合通信在时间上不同的突发流量。如果存储流量与训练结构共享物理资源，设计就需要隔离或容量规划。如果使用一张单独的网络，平台仍需协调两条路径上的故障和恢复。

存储还影响可移植性。将模型迁移到 CoreWeave 可能涉及从其他云或私有环境进行大规模数据转入。将模型迁出可能产生成本、延迟和合同摩擦。“零出口迁移”（Zero Egress Migration）是 CoreWeave 为降低迁入平台的某些迁移成本而提供的商业机制；不应将其与一项技术保障、普遍免费的出口或没有运营成本的数据移动证明相混淆。

因此，评估该栈的客户应当要求端到端的证据。加速器和网络结构的峰值成绩很有用，但生产负载还包括数据集准备、检查点执行、模型注册活动、日志和恢复。仅隔离某一层的基准测试，无法回答完成整个作业需要多长时间这一经济问题。

骨干网连接区域，而非单个同步超级计算机

CoreWeave 描述了一张运营商级别的骨干网，通过陆地和海底光缆连接北美与欧洲的数据中心，并提供直接对等互联和专用连接服务。公司文档列出了 10、100 和 400 Gbps 的 Direct Connect 选项，具体受限于可用地点和可用性。

骨干网的功能与本地横向扩展结构不同。它可以跨区域移动数据集、副本、检查点、控制流量和推理流量。它可以连接用户和其他云。它可以支持恢复和分发。长距离传播延迟阻止了它将远程设施转化为一个用于紧耦合作业的低延迟统一训练结构。

专用连接减少了一类不确定性

一条专用电路可以避免部分公共互联网路面的路由波动，并提供一个更清晰的容量和支持边界。它并不能创造一个端到端完全私有的世界。客户访问可能依赖于运营商、交叉连接和数据中心公司。云入口有自己的受理和配置流程。路由多样性和物理所有权并未在每一处站点都得到充分披露。

因此，CoreWeave 不该被描述为一级运营商。它运营骨干网并进行对等互联，但所提供证据并未确立无需支付转接费的全球可达性，也未确立对每条光纤路径的所有权。它的优势在于对其自有计算集群的集成访问，而不是取代全球运营商生态系统。

区域设计创造了可用性选择

CoreWeave 报告截至 2025 年底在六个国家拥有设施。设施的数目并不意味着每一代加速器、网络结构、服务或专线连接速度在每一个国家都可用。区域是分阶段开放的，因为电力、冷却、网络、硬件和运营就绪条件并不会同时达到。

对客户而言，地理位置影响的远不止延迟。它影响数据治理、与云和团队的邻近性、电力来源、故障相关性，以及哪家合作伙伴控制本地路径。对 CoreWeave 而言，每新增一个国家，就增加了法律、公用事业和供应链的协调复杂度，而不仅仅是容量。网络的地理扩张是一种运营模式，而不是一张相同方盒子的地图。

可靠性将资本转化为有用时间

当作业在推进或等待时，CoreWeave 的硬件始终处于融资状态。因此，可靠性是一个金融变量。一次网络结构故障、一块降级的 GPU、一次存储卡顿，或者调度器错误，都可能在利息、租金和电力承诺持续产生的同时，减少可计费和可用的产出。

拖慢者（Stragglers）比完全故障更重要

一个故障节点是可见的。一个拖慢者可能在技术上仍然活动，却拖慢每一个同步点。大型作业需要能检测性能降级的遥测，而不仅仅是二值健康状态。调度器和运营团队必须决定是否腾空、替换或继续使用该组件。

公开记录并未提供完整的作业故障分布、尾部延迟或拖慢者出现频率。这一缺失并不能证明可靠性低下，但限制了独立比较。客户需要依赖合同、工作负载测试和自身的运营证据，而不是从架构图进行外推。

质量认证是一项系统测试

在将一个集群暴露给外部之前，CoreWeave 必须将服务器、交换机、光模块、线缆、固件、驱动、存储和编排作为一个整体进行质量认证。通过一次启动测试是不够的。有用的测试是看完整拓扑是否支撑预期负载、在故障下幸存，并能在不引入新的不一致性下进行修复。

质量认证还有时间维度。一个在特定软件和固件组合下有效运行的设计，在更新后可能表现不同。NVIDIA 快速引入的新代次增加了 CoreWeave 需要支持的组合数量，同时更早签约的老旧环境仍在服役。运营成熟度在于管理这种重叠，而不将每一处站点变成独特的例外。

财务是架构的一个层

CoreWeave 报告了 2025 年 51 亿美元的营收和 12 亿美元的净亏损。当年为不动产和设备支付的现金为 103 亿美元。截至年底，剩余履约义务为 607 亿美元。同一份文件还描述了巨额设备融资、债务、租赁和基础设施承诺。

这些数字描述的是不同的事物。营收是确认的服务收入。为不动产和设备支付的现金是投资流出，而不是完整装机机群的估值。净亏损表明增长尚未产生产生合并盈利。剩余履约义务根据会计准则代表未来合同交付，而不是银行里的现金或已经交付的服务。

2026 年第一季度同时显示了需求和持有成本

在截至 2026 年 3 月 31 日的季度中，CoreWeave 报告了 20.78 亿美元营收、7.4 亿美元净亏损，以及 5.36 亿美元的利息支出。它同时报告了根据其定义达到 994 亿美元的储备订单。业绩显示出强劲的需求可见性，同时在同一个时期也背负着沉重的融资负担。

储备订单不能与 2025 年底的剩余履约义务直接互换。定义和时间点都不同。两者均表明已签订合同的未来需求，但转化取决于 CoreWeave 能否将设施、电力、硬件和网络容量投入服务并履行合同。储备订单越有说服力，与其相关的交付义务就越重。

由 GPU 担保的融资将资产与合同对齐

CoreWeave 使用了担保贷款、设备融资和客户支持的架构来为扩张提供资金。2026 年 6 月，其宣布了一项 85 亿美元的信贷额度，被描述为由 GPU 担保，且该笔特定交易被评为了投资级评级。这项额度扩大了部署能力；但它本身并不是收入，也不能确立公司所有义务的投资级地位。

资产担保融资可以将债务与硬件及合同现金流对齐。它也可能围绕抵押品、部署和现金使用产生限制。加速器、交换机和光模块的老化速度远快于许多传统基础设施资产。当利用率保持高位且合同的存续期超过设备最具经济价值的期间时，这种模式效果最好。

因此，网络设计影响信用质量。一个能交付更高利用率的拓扑会提升融资资产的生产力。一处延迟的站点、一个持续的拖慢者问题，或一次不成功的迁移则可能降低利用率。在 CoreWeave 的模式中，系统工程和资产负债表工程是同一回事。

客户集中度也意味着基础设施依赖

微软占 CoreWeave 2025 年营收的 67%。一个重要的锚定客户可以为容量提供理由、支持融资，并让提供商有底气提前采购设备。同样的集中度也赋予客户谈判能力，并使利用率对单一的商业关系变得敏感。

CoreWeave 宣布或报告了与其他客户的关系，包括 Meta 和 Anthropic。Flow Traders 在 2026 年 7 月选择其用于基础模型训练，Leidos 宣布在国防、国家安全和情报领域的 AI 合作。这些声明确立了在信源所描述的层级上存在合同、选择或合作，但并不能证明集中度已消失，或所有宣布的容量业已部署。

照付不议合同转移了风险，但没有消除风险

多年期照付不议合同能为 CoreWeave 提供需求可见性，并支持融资。它们将部分利用率风险从提供商转移给客户，因为承诺付款并不只取决于短期用量。但它们并不能消除建设、电力、交付、性能、信用或重新谈判的风险。

对客户而言，该合同颠覆了云的部分承诺。传统公有云强调弹性消费和低承诺。一个专用的 AI 集群可能需要一种更长、更像基础设施的关系，因为提供商已经建造或预留了特定的容量。该服务可能在界面上像云软件，而在底层表现得像项目融资。

防务和受监管工作提高了保障要求

2026 年 7 月 30 日宣布的与 Leidos 的合作将平台扩展到国防和情报任务。这一合作并未确立所有必需的许可、认证或适用于受监管工作的部署。但它表明，安全性、供应链控制、可审计性和运营连续性可能成为 CoreWeave 产品中更重要的部分。

由 DPU 强制执行的 VPC、专用连接和托管运营可以支撑一项高保障项目，但它们并不能取代特定于项目级的控制、人员要求、数据处理和政府批准。公司越靠近任务关键型负载，其责任边界就需要越透明。

上移的收购与指向下方的失败并购

2025 年，CoreWeave 收购了 Weights & Biases、OpenPipe、marimo 和 Monolith AI。Weights & Biases 增加了模型开发和可观测性工具；其他收购扩展了推理、笔记本和工业 AI 方面的能力。这些交易将 CoreWeave 从基础架构推向了更接近开发周期的环节。

战略逻辑很清晰。一个理解模型工作流的提供商可以更好地预测需求、降低基础设施使用门槛，并在更多开发阶段留住客户。整合风险同样清晰。软件公司拥有与以融资驱动的数据中心运营截然不同的发布周期、利润率和文化。如果 CoreWeave 试图拥有此前客户从独立供应商获取的工具，则可能出现产品重叠以及与合作伙伴的冲突。

对 Core Scientific 的拟议收购指向了相反的方向。2025 年 7 月，CoreWeave 宣布了一项合并协议，本应扩大其数据中心的容量和租赁经济性的控制力。Core Scientific 在其股东投票后于 2025 年 10 月 30 日终止了该协议。CoreWeave 并未收购这家公司。

综合来看，这些交易揭示了一个双向的整合战略：向开发者软件方向向上移动，同时也向物理容量方向向下移动。失败的合并也表明，对基础设施的控制并不总能在平台所期望的时间表上通过购买实现。股东、监管机构、融资和合同架构可以阻止垂直整合的技术逻辑。

CoreWeave 控制什么——什么仍在其边界之外

CoreWeave 控制着客户平台、许多设计决策、设备质量认证、编排和运营流程。它可以决定 Nimbus 如何映射 VPC、集群如何呈现、哪些服务由自己管理以及如何处理事件。它可以提前采购硬件，并围绕加速器密度来组织设施。

NVIDIA 控制着关键的 GPU、NVLink、InfiniBand、Spectrum-X 和 BlueField 产品路线图。公用事业和数据中心合作伙伴控制着电力交付和设施的一部分。光纤运营商、交换中心和云提供商控制着外部连接的某些部分。债权人和设备融资方限制着资本的使用。大客户通过合同影响容量规划。

这并非 CoreWeave 独有的缺陷。每一朵云都依赖供应商和设施。这种集中之所以重要，是因为 CoreWeave 的差异化与其快速部署 NVIDIA 系统紧密相连，并且相较其运营历史，其资本承诺异常庞大。供应商的延迟或路线图变更可能传导至客户交付和融资。

平台的优势在于协调这些边界。其风险在于关联性的依赖：同一代供应商、同一设施设计或同一个客户计划可能同时波及多个层。整合减少了客户需要管理的合同数量，但可能放大一次提供商级故障的影响。

竞争定位：一朵专业云是一种关于责任的选择

CoreWeave 与超大规模云、其他专业 GPU 云、客户自建集群以及多种结合托管、主机托管和集成管理的组合展开竞争。这种比较不能被简化为 GPU 数量或一个基准测试。买家比较的是可用的硬件代次、网络结构、存储、调度、专用连接、支持、合同期限、地理位置和数据移动的总成本。

相对于超大规模云

Amazon Web Services、Microsoft Azure、Google Cloud 和 Oracle 提供广泛的产品组合、全球生态系统和庞大的资产负债表。它们可以将 AI 基础设施与数据库、安全、分析以及客户已使用的企业采购流程捆绑在一起。CoreWeave 的回应是专业化：更快集成选定的 NVIDIA 代次、裸金属编排，以及一个为高密度加速器负载打造的底层平台。

专业化可以减少抽象层并缩短质量认证周期。它也可能产生一个更窄的故障和供应商组合。选择 CoreWeave 的客户可能获得一个更专注于特定负载的提供商，但也要接受更窄的服务范围和更年轻的资本结构。正确的比较是基于负载的，而非基于类别的。

相对于其他专业云

Lambda、Nebius、Crusoe 和其他 AI 基础设施提供商在加速器、集群和托管服务产品方面有所重叠。差异包括地理位置、能源策略、软件组合、所有权、资本结构以及对设施的控制程度。“Neocloud”是一个市场标签，而非一种共同的架构。

CoreWeave 作为上市公司提交的文件提供了关于规模和风险的不寻常的详细证据。这些证据本身并不能确立技术或经济上的优越性。一个披露较少的竞争对手可能规模更小、更高效，或仅仅是更不透明。分析不应将透明度转化为性能排名。

相对于自建私有集群

客户自己的集群使买家能够直接控制硬件、数据和运营。但这也要求采购、电力、设施、网络、存储、安全、固件、备件和专业人员。CoreWeave 出售的是将其中大部分负担转移出去的服务。

这种转移是不完全的。客户仍然要设计负载、管理数据、定义策略和评估提供商风险。长期承诺可能降低切换的灵活性。一个私有集群在客户内部面临利用率低的风险；而一份云合同则面临提供商依赖的风险。经济上的选择在于哪一方更具备吸收波动并保持昂贵系统持续运转的能力。

液冷交换展示了下一个瓶颈可能迁移到哪里

2026 年 7 月，CoreWeave 发布了关于液冷交换的材料，旨在提高每个机架的带宽密度。这一声明与该公司的架构和计算相关，而非对整个机群的独立基准测试。但其机制很重要：随着加速器密度增加，交换机和光模块也会消耗足够多的电力并产生足够多的热量，从而使其本身也成为机架冷却问题的一部分。

对交换机进行液冷处理可以在有限的机架空间内实现更大的网络容量，并减少将交换设备放置在更远处的需求。更短的路径可以简化线缆并保持密度。该设计还将网络维护与液体冷却系统相连。泄漏、泵故障或服务操作可能会影响那些以前被当作风冷网络设备处理的组件。

这一变化表明了一种更广泛的模式。AI 基础设施的瓶颈会转移。更快的 GPU 创造出对更大纵向扩展带宽的需求。机架内更大的带宽要求更密集的横向扩展交换。更密集的交换推高了电力和冷却要求。新设施因此需要不同的机械与电气设计。因此，一代产品不仅仅是服务器的升级；它可能意味着数据中心的重新设计。

Vera Rubin 是未来的过渡，而非对现有机群的描述

CoreWeave 在 2026 年 7 月的材料中描述了对 NVIDIA Vera Rubin NVL72 系统的准备，并提出了公司自身或前瞻性的声明，与 Blackwell 相比在每兆瓦令牌数方面的提升。这些声明应归属于 CoreWeave 和所命名的配置。它们并未确立在本研究截止时该产品在全机群中的可用性。

新一代会同时改变多个层：加速器、纵向扩展结构、横向扩展带宽、每机架功率、冷却、固件、驱动、编排和质量认证。它可以提高每兆瓦的生产力，也可能使既有设施变得不再适用或竞争力下降。CoreWeave 快速采纳新硬件的能力只有在其能够管理迁移、保持利用率并处理好更早签约资产的折旧时，才构成一项战略优势。

这一过渡也加深了对 NVIDIA 的依赖。早期接入可以吸引客户并支撑溢价合同。但也可能让公司暴露在一家自己无法控制的供应商的交付时间表、定价和架构决策之下。在客户或软件层的多样化，未必能够在物理栈上实现多样化。

该栈对数字基础设施更广泛的影响

CoreWeave 的扩张影响到了远不止出租 GPU 的市场。吉瓦级的承诺产生对发电、电网互联、变压器、冷却、土地和施工的需求。高端口数网络结构需要交换机、光模块和光纤。专用连接创造了对运营商容量、交换中心存在和云入口的需求。融资架构则要求贷款方能够评估相对于长期合同而言技术快速过时的风险。

该平台也改变了互联网流量出现的位置。紧耦合的训练流量主要留在本地网络结构内，但数据集、检查点、模型工件、推理请求和开发者工作流则在云、数据中心和用户之间流动。因此，对互联网的可见影响可能并非来自一条庞大的训练流，而更多来自围绕训练环境产生的持续数据移动。

对于接纳设施的社区和电网而言，该网络栈是一项电力和土地使用决策。本研究报告未提供足够的本地证据来得出关于整个公司的环境结论。它确立了活跃电力和合同电力是衡量增长的重要指标，并确立了电力或设施的延迟交付构成业务风险。

对于网络工程师而言，该架构表明 AI 基础设施正在成为一门独立的学科。路由、交换的知识仍然必要，但现在它遇到了集合通信库、加速器拓扑、液冷、工作负载调度和项目融资。一个正在调整拥塞控制的人，可能同时也在保护作业的完成，以及债务的偿还。

公开证据无法显示的部分

CoreWeave 公开发布了产品文档、技术博客和财务报表，但该栈仍然存在部分不透明。所提供的材料不包括完整的当前拓扑、按站点的网络结构库存、超额订阅表、光纤所有权地图、事件历史记录或按工作负载的独立基准测试档案。

这一限制应改变相关声明的措辞。架构文档可以确立机制。SEC 披露可以确立合并的财务事实与风险。与具名客户的沟通可以确立选择或合作。这些来源中没有任何一项能证明普遍的工作负载成果、全机群的正常运行时间，或者对每一买家更低的总体拥有成本。

同样的谨慎也适用于规模。活跃电力不是合同电力。储备订单不是营收。一场未来的财报电话会议日期不是业绩。宣布的客户协议不等于活跃使用。拟议的收购不是所有权。未来一代硬件不是当前机群。

这些区别并未削弱公司的形象。它们指出了专业读者需要管理的真实信息缺口。CoreWeave 要求客户和资本提供方信任一个集成系统，而该系统最有价值的部分细节必然是不公开的。理性的回应不是假设卓越或失败，而是要求在其所考虑的合同、集群和站点层面提供证据。

核心判断

CoreWeave 的产品最常被描述为计算容量。更深层次的产品则是协调。公司必须协调供应商路线图与数据中心建设，纵向扩展链路与横向扩展网络结构，DPU 策略与租户意图，Kubernetes 调度与物理拓扑，存储与检查点行为，骨干网连接与客户接入，以及长期融资与短暂的硬件代际。

这种协调可以创造真实的优势。一个专业提供商可以做出覆盖整体负载的决策，而不是让客户自己去整合分散的供应商。它可以为系统做质量认证、修复故障，并比许多企业独自行动更快地引入新代次。平台的快速扩张表明，大型客户看重这种责任的转移。

同样的整合也集中了后果。一项网络结构设计、一次供应商延迟、一个策略错误、一项融资限制或一次锚定客户的变动，都可能影响系统的很大一部分。公司的未来并不依赖于某个耀眼的带宽数字，而是取决于所有层能否持续将融资建设的容量转化为对客户可靠的工作。