为何大科技公司从CoreWeave购买GPU？| Corey Sanders

摘要

• CoreWeave声称自身存在的理由是：AI已经对业务至关重要且成本高昂，单靠“全套最佳”的云服务已无法满足需求。 Corey Sanders将其与约10年前分析浪潮中的Snowflake和Databricks相提并论：当某项工作负载足以改变业务时，客户可能会放弃熟悉的合同，转向同类最佳的性能。特别之处在于，Microsoft和Google本身也是CoreWeave的客户，并在某些情况下成为合作伙伴。

• 整个架构都围绕持续喂饱GPU——系统中最昂贵的资产——展开。 CoreWeave围绕AI工作负载优化对象存储、Lotta Cache、多GPU缓存、编排和可观测性，尤其针对训练任务在检查点之外相对有限的写出需求，而不是兼容所有类型的工作负载。Sanders最犀利的表述是：“我们不需要为电商网站设计。我们可以为自身擅长的东西设计，也就是AI。”

• 部分最新、最大型的GPU必须采用液冷，而液冷本身也是一项尚未完全验证价值的效率主张。 Sanders称，液冷可以降低HVAC和空调成本，希望这些节省最终能转化为长期成本优势。他明确保留判断：“这项价值的全部程度，结论仍未确定。”

• Corey认为，统一或商品化的API并不会让云服务变成商品。 运营、质量、性能和体验仍可形成差异化，而CoreWeave对AI的专门化假设也更难由广泛服务的公有云作出。竞争门槛还会继续上升：“我们今天交付的质量、性能、能力和体验，2年后将无法赢得工作负载。”因此CoreWeave必须持续改进。

• 推理可能让地域容量变得更灵活，因为请求耗时中有更多时间花在GPU内部，网络耗时占比则更低。 这可能让应用跨数据中心分散调用、承接流量峰值并提升可用性，运营者也不必“总是提心吊胆”某个特定区域是否有GPU。Sanders希望平台能理解“我有点想放在这里，也有点想放在那里”，并自行处理部署位置——但他也承认，随着工作负载演进，这一优势可能只是暂时的。

• 供应约束不是整个市场统一的一个数字，而取决于加速器代际和集群规模。 GB200、GB300、B200、H100和H200的容量各不相同，10、100、1,000或10,000颗加速器的需求也完全不同：“全世界没有多少地方能运行10,000颗GB200。”客户有时可以拆分工作负载、使用多个云，或接受另一代产品；按需和类似spot的用量也应会扩大。

• CoreWeave与客户的亲密程度可能与硬件栈同等重要，但Sanders将两者视为互补，而非替代关系。 可观测性、Mission Control、CKS以及CKS上的Slurm让任务更简单；客户成功团队，甚至CTO本人，也会直接进入客户渠道——Sanders称，超大规模云厂商可能只会把这种覆盖留给“头部9个客户，或者类似规模的客户”。同样的客户互动也推动产品形成：一些大客户为了尽可能喂饱GPU而陷入困境，最终促成了SUNK。

精读

上游暂未提供，后续同步将继续补齐。