三亩地 三亩地SAN MU DI · CODE DIARY
交流投稿
ARTICLE DETAIL

日记详情

真实记录编程学习的某一天，欢迎挑你感兴趣的翻一翻。

首页/学习日记/日记详情

CoreWeave崛起背后：AI原生基础设施如何重塑GPU云服务与Kubernetes实践

发布时间：2026/8/15 13:23:01 三亩地 编程学习日记
CoreWeave崛起背后：AI原生基础设施如何重塑GPU云服务与Kubernetes实践

如果你关注AI算力市场，最近可能被一条消息刷屏了：一家名为CoreWeave的GPU云服务商，在2026财年第二季度实现了25.75亿美元的营收，同比增长高达112.46%。

这个数字意味着什么？简单对比一下：全球公有云市场的领导者AWS，其2025年第四季度（自然年）营收约为1000亿美元，同比增长约13%。CoreWeave的增速是其近9倍。更关键的是，这并非一家初创公司的早期爆发，而是在一个技术壁垒极高、资本密集、巨头环伺的赛道里，实现了连续多个季度的三位数增长。

很多开发者第一反应可能是：“这和我有什么关系？不就是又一家烧钱的云厂商吗？” 这种想法恰恰错过了关键点。CoreWeave的崛起，远不止是商业新闻，它标志着一个根本性的转变：AI原生基础设施的时代已经到来，并且正在重塑整个技术栈的构建和消费方式。

过去，我们习惯于在通用云计算（CPU+少量GPU）上“适配”AI工作负载。而CoreWeave代表的是一种“为AI而生”的架构：全栈GPU、极致网络、专有软件层。这种模式不仅解决了大模型训练和推理的痛点，更在悄然改变着从模型开发、微调到应用部署的每一个环节。

本文将为你深入拆解CoreWeave现象背后的技术逻辑。我们不会停留在财报数字的表面，而是会探讨：

  1. 它到底解决了什么通用云解决不了的“硬核”问题？（不仅仅是“有GPU”那么简单）
  2. 作为开发者或技术决策者，它的技术栈（如Kubernetes on GPU, 网络架构）带来了哪些新的可能性和挑战？
  3. 我们该如何看待和评估这类AI原生基础设施？是短期炒作，还是长期趋势？
  4. 如果你正在构建AI应用，从技术选型角度，需要考虑哪些新的维度？

理解CoreWeave，就是理解下一代AI基础设施的竞赛规则。这不仅仅是关于选择哪家云供应商，而是关于如何为即将到来的AI原生应用浪潮，构建更高效、更经济、更可靠的技术底座。

1. CoreWeave高速增长背后的真实痛点：为什么通用云“不够用”了？

要理解CoreWeave为什么能异军突起，首先要明白当前AI开发，尤其是大模型相关开发，在通用云计算平台上遇到了哪些天花板。

痛点一：GPU资源的“稀缺性”与“碎片化”在AWS、GCP、Azure上获取大量高性能GPU（如H100、B200）并非易事。你常常需要申请配额提升，等待资源释放，甚至无法在同一区域获得足够数量、互联性好的卡。对于需要数百甚至数千张卡并行训练一个大模型的团队来说，这种不确定性是致命的。CoreWeave从创立之初就All in GPU，其核心商业模式就是大规模采购和高效运营最先进的GPU，确保客户能够“按需、大规模、稳定地”获得算力。

痛点二：GPU间通信的“网络瓶颈”大模型训练不是把一堆GPU简单堆砌起来。GPU之间需要高速、低延迟地交换梯度等数据。通用云的网络架构最初是为Web服务设计的，其网络带宽和延迟往往成为分布式训练的瓶颈。CoreWeave投入巨资构建了基于NVIDIA Quantum-2 InfiniBand或Spectrum-X以太网技术的超低延迟、高带宽网络，将数千张GPU连接成一个高效的“超级计算机”，这是其性能优势的关键。

痛点三：软件栈与硬件的“深度耦合”在通用云上，你需要自己处理GPU驱动、CUDA版本、容器运行时、Kubernetes调度与GPU的兼容性问题。CoreWeave提供了高度优化的软件栈，其核心是基于Kubernetes的GPU虚拟化与管理平台。它通过自定义的Kubernetes设备插件、调度器和容器运行时，实现了对GPU资源的细粒度管理和高效共享（如MIG，多实例GPU），让开发者可以像使用CPU Pod一样声明式地使用GPU资源，极大降低了运维复杂度。

痛点四：成本模型的“不匹配”通用云的计费模式复杂，包含计算、存储、网络出口等多项费用。对于需要持续数周、消耗数万GPU时的训练任务，总成本难以精确预估且可能非常高昂。CoreWeave等AI原生厂商通常提供更简单、更具竞争力的按GPU时计费模式，并且由于其架构专为AI优化，在同等任务下往往能实现更短的训练时间（时间也是成本），从而带来真实的总体拥有成本（TCO）优势。

简单来说，CoreWeave的快速增长，是因为它精准地击中了AI时代算力需求的“芯脏”：不再是“有计算能力”，而是“有极致、可预测、大规模、高效率的AI计算能力”。它的客户名单（包括众多顶级AI实验室和大型企业）证明了市场对这种专业化服务的强烈需求。

2. 技术架构深度解析：不只是“云”，而是“AI超级计算机即服务”

CoreWeave将自己定位为“AI超级计算机云”，这个定位直接体现在其技术架构的每一个层面。我们来拆解其核心组件。

2.1 硬件层：全栈GPU与极致网络

  • 计算：几乎全部采用NVIDIA最新的数据中心GPU，如H100、H200、B200等。它不仅是早期大批量采购者，还通过与NVIDIA的紧密合作，确保供应和获得深度优化支持。
  • 网络：这是与通用云拉开差距的核心。采用NVIDIA InfiniBand或Spectrum-X以太网网络架构。InfiniBand提供了超低的延迟和极高的吞吐量，特别适合All-Reduce等集体通信操作。Spectrum-X则提供了基于以太网的、无损的、可预测的网络性能。两者都通过NVIDIA的SHARP技术实现了网络内计算，进一步加速通信。
  • 存储：提供与GPU计算性能相匹配的高性能存储解决方案，如基于NVMe的本地存储或高速网络存储，确保不会在数据加载环节成为瓶颈。

2.2 软件层：Kubernetes原生的GPU云

这是开发者最能直接感知的一层。CoreWeave的整个控制平面和数据平面都构建在Kubernetes之上。

  • 核心概念：在CoreWeave上，一切皆Pod。一个GPU资源被抽象为一个或多个可通过Kubernetes调度的设备。
  • 关键组件：
    • GPU Operator：自动化管理节点上所有GPU软件栈（驱动、容器运行时、设备插件、监控等）的部署与生命周期。
    • 自定义调度器：扩展Kubernetes调度器，使其理解GPU拓扑（如NVLink连接）、MIG分区策略，并能进行亲和性/反亲和性调度，将需要紧密通信的Pod调度到物理位置更近的GPU上。
    • 设备插件：向Kubelet报告节点上的GPU资源（数量、内存、算力类型），并负责GPU设备的生命周期管理。
    • 容器运行时：使用nvidia-container-runtime等，确保容器内的应用可以安全、高效地访问宿主机的GPU。

2.3 开发者体验：从基础设施代码到模型服务

对于开发者，与CoreWeave交互的方式非常“云原生”。

  1. 资源定义：使用熟悉的Kubernetes Manifest文件来定义你的工作负载。关键点在于resources.limits中指定对nvidia.com/gpu的需求。

    # 示例：一个请求1个GPU的推理服务Pod apiVersion: v1 kind: Pod metadata: name: gpu-inference-pod spec: containers: - name: llama-inference image: my-llm-inference-image:latest resources: limits: nvidia.com/gpu: 1 # 申请1个GPU memory: "16Gi" cpu: "4" ports: - containerPort: 8080

  2. 部署与扩展：通过kubectl或GitOps工具（如ArgoCD）部署你的Deployment、StatefulSet或Job。你可以利用Horizontal Pod Autoscaler (HPA)基于自定义指标（如GPU利用率、请求延迟）进行自动扩缩容。

  3. 存储与数据：通过Persistent Volume Claim (PVC)挂载高性能存储卷，用于存放模型权重、数据集或日志。

  4. 服务暴露：使用Kubernetes Service和Ingress将你的AI服务（如模型API）暴露给内部或外部用户。

这种模式带来的根本性转变是：AI基础设施的管理从“服务器/虚拟机思维”彻底转向了“声明式、可编程、可扩展的容器化应用思维”。运维团队和AI研发团队的协作界面变得清晰——Kubernetes API。

3. 环境准备与核心概念：在CoreWeave上启动第一个工作负载

假设你已有一个CoreWeave账户并完成了初始配置（创建项目、配置CLI、设置Kubeconfig）。我们来看如何运行一个实际任务。

3.1 前置条件

  • 账号与权限：拥有CoreWeave账户，并已生成API Token用于身份验证。
  • 本地工具：
    • kubectl：命令行Kubernetes工具。
    • coreweaveCLI（可选）：CoreWeave提供的便捷命令行工具。
    • 配置好KUBECONFIG，使其指向你的CoreWeave Kubernetes集群。
  • 基础镜像知识：了解如何构建包含CUDA和所需AI框架（如PyTorch, TensorFlow）的Docker镜像，并推送到容器镜像仓库（CoreWeave提供私有仓库或使用公共仓库如Docker Hub）。

3.2 核心概念澄清

  • 租户与命名空间：在CoreWeave中，一个“租户”对应一个计费账户，其下可以创建多个Kubernetes命名空间，用于隔离不同项目或环境。
  • GPU类型：在请求资源时，可以指定具体的GPU类型，如nvidia.com/gpu.h100: 1。如果不指定，调度器会分配任何可用类型。
  • 存储类：CoreWeave提供多种存储类，例如：
    • block-nvme：高性能本地NVMe存储，低延迟，但生命周期与Pod绑定。
    • block-nvme-ord1：高性能网络块存储，数据持久化。
    • shared-hdd：成本更低的网络共享存储。
  • 虚拟服务器（VPC）：虽然核心是Kubernetes，但CoreWeave也提供虚拟私有云（VPC）和虚拟机服务，用于运行非容器化的传统工作负载或作为管理节点。

4. 实战演练：部署一个文本生成模型推理服务

我们将以部署一个流行的开源大模型（如Llama 3）的推理API为例，展示完整流程。

4.1 步骤一：准备模型推理镜像

我们使用一个集成了vLLM（一个高性能推理引擎）的镜像。你可以自己构建，或使用社区镜像。

# Dockerfile 示例 FROM nvidia/cuda:12.1.0-runtime-ubuntu22.04 RUN apt-get update && apt-get install -y python3-pip WORKDIR /app COPY requirements.txt . RUN pip3 install --no-cache-dir -r requirements.txt COPY app.py . CMD ["python3", "app.py"]
# requirements.txt vllm fastapi uvicorn
# app.py - 一个简单的FastAPI服务 from fastapi import FastAPI from vllm import SamplingParams from vllm import LLM import os app = FastAPI() # 从环境变量获取模型路径 model_path = os.getenv("MODEL_PATH", "meta-llama/Meta-Llama-3-8B-Instruct") # 初始化LLM引擎（在GPU上） llm = LLM(model=model_path) @app.post("/generate") async def generate_text(prompt: str, max_tokens: int = 100): sampling_params = SamplingParams(temperature=0.8, top_p=0.95, max_tokens=max_tokens) outputs = llm.generate([prompt], sampling_params) generated_text = outputs[0].outputs[0].text return {"generated_text": generated_text} @app.get("/health") async def health(): return {"status": "healthy"}

构建并推送镜像到你的镜像仓库。

4.2 步骤二：创建Kubernetes部署清单

创建一个名为llama-inference-deployment.yaml的文件。

# llama-inference-deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: llama-3-8b-inference namespace: your-namespace # 替换为你的命名空间 spec: replicas: 1 # 初始副本数，可根据HPA调整 selector: matchLabels: app: llama-inference template: metadata: labels: app: llama-inference spec: nodeSelector: # 可选：指定GPU节点类型，如需要H100 gpu.nvidia.com/class: H100 containers: - name: inference-server image: your-registry/llama-vllm-inference:latest # 替换为你的镜像 resources: limits: nvidia.com/gpu: 1 # 申请1个GPU memory: 20Gi cpu: "2" requests: nvidia.com/gpu: 1 memory: 20Gi cpu: "2" env: - name: MODEL_PATH value: "meta-llama/Meta-Llama-3-8B-Instruct" ports: - containerPort: 8000 # FastAPI默认端口 livenessProbe: httpGet: path: /health port: 8000 initialDelaySeconds: 30 periodSeconds: 10 readinessProbe: httpGet: path: /health port: 8000 initialDelaySeconds: 5 periodSeconds: 5 --- apiVersion: v1 kind: Service metadata: name: llama-inference-service namespace: your-namespace spec: selector: app: llama-inference ports: - port: 80 targetPort: 8000 type: ClusterIP # 内部服务，后续可通过Ingress暴露

4.3 步骤三：部署到CoreWeave集群

使用kubectl应用这个清单。

# 应用部署 kubectl apply -f llama-inference-deployment.yaml # 查看部署状态 kubectl get deployments -n your-namespace kubectl get pods -n your-namespace # 查看Pod日志，确认服务启动成功 kubectl logs -f deployment/llama-3-8b-inference -n your-namespace

4.4 步骤四：暴露服务并测试

为了从外部访问，创建一个Ingress资源。CoreWeave通常支持标准的Kubernetes Ingress或提供负载均衡器服务。

# llama-inference-ingress.yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: llama-inference-ingress namespace: your-namespace annotations: # CoreWeave特定的注解，用于配置负载均衡器、TLS等，请参考官方文档 kubernetes.io/ingress.class: "nginx" spec: rules: - host: llama-api.your-domain.com # 替换为你的域名 http: paths: - path: / pathType: Prefix backend: service: name: llama-inference-service port: number: 80

应用Ingress后，你就可以通过指定的域名访问推理API了。

# 测试API curl -X POST https://llama-api.your-domain.com/generate \ -H "Content-Type: application/json" \ -d '{"prompt": "请用中文解释什么是机器学习", "max_tokens": 150}'

5. 运行效果验证与性能观测

部署成功后，你需要验证服务是否正常工作并监控其性能。

  1. 基础健康检查：使用kubectl get pods查看Pod状态是否为Running。检查日志无报错。
  2. 服务连通性：在集群内创建一个临时Pod，使用curl测试Service的/health和/generate端点。
  3. 性能监控：CoreWeave控制台通常提供集成的监控仪表盘，可以查看：
    • GPU利用率：是否达到预期（推理服务可能不是100%持续利用）。
    • 内存使用：确保没有内存泄漏。
    • 请求延迟（P50, P99）：评估推理性能。
    • 网络I/O：观察数据传输情况。
  4. 成本仪表盘：在CoreWeave控制台中，密切关注当前命名空间或部署的GPU时消耗和预估费用。

6. 常见问题与排查思路

在CoreWeave上运行工作负载，可能会遇到一些典型问题。

问题现象可能原因排查方式解决方案
Pod 处于 Pending 状态1. 资源不足（无可用GPU）。
2. NodeSelector 不匹配。
3. PVC 绑定失败。		kubectl describe pod <pod-name>查看事件。1. 检查集群GPU资源余量，或选择其他GPU类型。
2. 检查nodeSelector标签是否正确。
3. 检查StorageClass和PVC配置。
Pod 启动失败或 CrashLoopBackOff1. 镜像拉取失败。
2. 容器内进程启动错误（如CUDA版本不兼容）。
3. 资源限制（如内存）过小。		kubectl logs <pod-name> --previous查看上次运行的日志。1. 检查镜像地址和拉取密钥。
2. 检查容器日志，确认CUDA、驱动、依赖库版本匹配。
3. 适当增加resources.limits中的内存或CPU。
GPU 无法被容器识别1. NVIDIA设备插件未正常运行。
2. 容器运行时未正确配置。		kubectl describe node <node-name>查看Capacity和Allocatable中是否有nvidia.com/gpu。
在Pod内运行nvidia-smi。		1. 联系CoreWeave支持，检查节点GPU状态。
2. 确保使用官方或兼容的CUDA基础镜像。
推理服务延迟过高1. 模型首次加载时间长。
2. GPU型号性能不足。
3. 请求队列阻塞。
4. 网络延迟。		查看应用日志和监控指标。使用性能剖析工具。1. 使用vLLM的持续批处理等功能优化。
2. 考虑升级到更高性能GPU。
3. 调整副本数或使用HPA。
4. 确保客户端与集群区域接近。
费用超出预期1. Pod配置了GPU但未充分利用。
2. 有“僵尸”Pod或资源泄漏。
3. 存储卷持续计费。		定期检查CoreWeave控制台的费用报告和资源使用情况。1. 设置自动缩容（HPA到0）。
2. 清理未使用的部署、PVC。
3. 对开发环境使用按需或抢占式实例。

7. 最佳实践与工程建议

将AI应用部署在CoreWeave这类平台上，需要遵循一些云原生和AI特有的最佳实践。

  1. 镜像优化：

    • 使用多阶段构建，减少镜像层数和最终大小。
    • 利用Docker BuildKit的缓存机制加速构建。
    • 基础镜像尽量选择与CoreWeave节点环境匹配的官方CUDA镜像。

  2. 资源管理与成本控制：

    • 精确请求资源：通过压测确定应用所需的GPU、CPU和内存的requests和limits，避免过度配置。
    • 使用自动伸缩：为推理服务配置HPA，基于QPS或GPU利用率进行伸缩，在空闲时节省成本。
    • 利用抢占式实例：对于非关键任务（如开发、测试、部分批处理训练），使用成本更低的抢占式GPU实例。
    • 设置预算告警：在CoreWeave控制台为项目或命名空间设置月度预算和告警。

  3. 高可用与容灾：

    • 对于关键服务，部署多个副本，并分散到不同的物理节点（利用Pod反亲和性）。
    • 将模型权重等关键数据存储在持久化网络存储（如block-nvme-ord1）中，而非本地存储。
    • 制定并测试灾难恢复计划，包括备份Kubernetes资源和持久化数据。

  4. 安全：

    • 遵循最小权限原则，为ServiceAccount配置精确的RBAC权限。
    • 镜像仓库使用私有仓库，并扫描镜像漏洞。
    • 使用Secrets管理API密钥、模型访问令牌等敏感信息，切勿硬编码在镜像或代码中。
    • 通过NetworkPolicy限制Pod间的网络流量。

  5. CI/CD与GitOps：

    • 将Kubernetes清单文件纳入版本控制（如Git）。
    • 使用ArgoCD或Flux等GitOps工具，实现部署的声明式管理和自动同步。
    • 在CI流水线中集成镜像构建、安全扫描和部署测试。

8. 总结与展望：AI原生基础设施的竞争才刚刚开始

CoreWeave的财报数据是一个强烈的信号，表明市场愿意为专业化、高性能、可预测的AI算力支付溢价。它的成功证明了“垂直化”和“深度优化”在AI基础设施领域的巨大价值。

对于开发者和技术团队来说，这意味着：

  • 技术选型多了一个重要维度：在选择云平台时，除了考虑生态、服务和价格，“AI算力能力”需要成为核心评估指标，包括GPU的规模、可获得性、互联性能和配套软件栈。
  • 技能栈需要更新：熟练掌握Kubernetes及其在GPU环境下的运维（Device Plugin, Operator, Scheduling），理解InfiniBand/RDMA等高速网络知识，变得比以往任何时候都重要。
  • 架构设计需要前瞻性：在设计AI应用时，从一开始就应考虑如何利用这类AI原生云的特性，例如设计支持弹性伸缩的微服务、实现计算与存储分离、优化数据流水线以减少GPU空闲时间。

未来，我们可能会看到：

  1. 竞争加剧：其他公有云厂商（AWS、Azure、GCP）必将大力投入，优化其AI产品线。同时，更多类似CoreWeave的垂直厂商会出现。
  2. 软硬件协同更深：随着NVIDIA、AMD、Intel乃至更多AI芯片厂商的竞争，云服务商与芯片厂商的绑定和深度优化会更紧密。
  3. 抽象层继续上移：可能会出现更上层的“AI计算平台”，进一步简化从模型训练到服务部署的全流程，但底层仍依赖于CoreWeave这类基础设施。

行动建议：无论你是否立即成为CoreWeave的用户，都值得花时间理解其技术架构和理念。尝试在其平台上部署一个简单的模型服务（许多厂商提供免费试用额度），亲身体验“GPU即代码”的工作流。这将帮助你建立对下一代AI基础设施的直观认知，为未来更复杂的AI项目做好技术储备。

最终，赢家不会是拥有最多数据中心的公司，而是能最有效将原始算力转化为AI创新生产力的平台。这场由CoreWeave等公司引领的竞赛，正在重新定义云计算的下一个十年。

编程学习 学习日记 实战经验
← 返回列表