云计算

云计算

云计算（cloud computing）为 ML 工作负载提供按需的基础设施，让你不必自己拥有硬件。本文件覆盖服务模型、主流云厂商、容器与 Kubernetes、存储、云网络、serverless 计算、成本管理以及基础设施即代码

• 训练一个前沿模型需要上千张 GPU 跑上几个月。没有哪家创业公司会自己买这些硬件。云计算让你按小时租用，训练时扩容、推理时缩容，只为实际使用付费。对任何想造出超出笔记本规模的 ML 系统的人来说，理解云基础设施都是基本功。

云服务模型

• 云服务按"厂商替你管多少"来分层：

• 对 ML 而言：多数团队会用混合方案。用 IaaS 做定制训练（完全掌控 GPU 实例），用 PaaS 做托管式训练和服务（SageMaker、Vertex AI 负责编排），用 SaaS 用工具（W&B 做实验跟踪、OpenAI API 做基线对比）。

主流厂商

AWS（Amazon Web Services）

• 最大的云厂商（约 32% 市场份额）。关键 ML 服务：
  • EC2：虚拟机。GPU 实例：p4d（A100）、p5（H100）、g5（A10G，用于推理）。
  • S3：对象存储。存放数据集和模型权重的事实标准。容量近乎无限，约 $0.023/GB/月。
  • SageMaker：托管式 ML 平台。处理训练、超参调优、部署和监控。
  • EKS：托管 Kubernetes。
  • Lambda：serverless 函数。不适合 GPU 工作负载，但适合预处理和编排。

GCP（Google Cloud Platform）

• Google 的云（约 11% 市场份额）。关键 ML 服务：
  • Compute Engine：虚拟机。带 A100、H100 的 GPU 实例。还有 TPU VM 用于访问 TPU。
  • GCS：对象存储（类似 S3）。
  • Vertex AI：托管式 ML 平台。原生支持 JAX/TPU。
  • GKE：托管 Kubernetes（最成熟的 K8s 产品，毕竟 Kubernetes 是 Google 创造的）。
  • Cloud TPU：GCP 独有。v5e 和 v5p 用于大规模训练。

Azure（Microsoft）

• 微软的云（约 23% 市场份额）。关键 ML 服务：
  • Azure VM：带 A100、H100 的 GPU 实例。
  • Azure Blob Storage：对象存储。
  • Azure ML：托管式 ML 平台。
  • AKS：托管 Kubernetes。
  • OpenAI Service：通过 Azure API 独家访问 OpenAI 模型。

容器与 Kubernetes

• 我们在第 13 章（操作系统）里概念性地介绍过容器（Docker）和 Kubernetes，并在第 15 章（部署）里讲过实操。这里聚焦云特有的模式：

Kubernetes 在 ML 中的应用

• Kubernetes（K8s） 在大规模下编排容器。关键概念：

  • Pod（容器组）：最小的可部署单元。包含一个或多个共享网络和存储的容器。一个模型服务 pod 里可能装着：模型服务器容器 + 一个用于收集指标的 sidecar 容器。

  • Deployment（部署）：管理一组相同的 pod。指定期望的副本数。某个 pod 崩溃时，K8s 会自动创建替代品。

  • Service（服务）：为一组 pod 提供稳定的网络端点。客户端连到 service，K8s 把流量路由到健康的 pod。类型有：ClusterIP（集群内部）、NodePort（通过节点端口对外）、LoadBalancer（通过云厂商的负载均衡器对外）。

  • StatefulSet：类似 Deployment，但面向有状态工作负载。每个 pod 都有持久身份和稳定存储。用于数据库和分布式训练（每个 worker 需要稳定身份才能互相通信）。

  • DaemonSet：在每个节点上跑一个 pod。用于：监控 agent（Prometheus node exporter）、日志收集器（Fluentd）、GPU 设备插件（NVIDIA device plugin）。

• K8s 中的 GPU 调度：NVIDIA device plugin 把 GPU 暴露为一种 K8s 资源。Pod 来申请 GPU：

resources:
  limits:
    nvidia.com/gpu: 2  # 这个 pod 需要 2 张 GPU
​

• K8s 把这个 pod 调度到有 2 张可用 GPU 的节点上。云上的 ML 平台就是这样为训练和推理分配 GPU 的。

自动扩缩容

• 水平 Pod 自动扩缩器（Horizontal Pod Autoscaler，HPA）：根据指标（CPU 使用率、请求速率，或自定义指标如 GPU 利用率、队列深度）扩缩 pod 数量。

• 集群自动扩缩器（Cluster Autoscaler）：扩缩节点数量。当 pod 因为节点不够而无法调度时，集群自动扩缩器会从云厂商处申请新的虚拟机。节点利用率低时，它会先排空再终止。

• KEDA（Kubernetes Event-Driven Autoscaling，基于事件的自动扩缩）：根据外部事件源（Kafka 队列深度、HTTP 请求速率）扩缩。特别适合推理：请求队列变长就扩容模型服务器，队列空了就缩容。

存储

• 对 ML 训练而言：数据集存在对象存储（S3/GCS）。训练脚本从对象存储把数据读进内存。要快速随机访问（打乱的数据加载），可以：(1) 训练前先把数据集下到本地 SSD；(2) 用高吞吐文件系统（Lustre、FSx）；(3) 用一个能高效流式读取并缓存的数据加载库（WebDataset、FFCV）。

• 模型权重：带版本控制地存在对象存储里。一个 FP16 的 70B 模型约 140 GB。以 1 GB/s 从 S3 加载约需 2.5 分钟。缓存到本地 SSD 能显著减少推理的冷启动时间。

云网络

• VPC（虚拟私有云，Virtual Private Cloud）：云中一个隔离的网络。你的虚拟机、数据库和服务都在 VPC 内部互相通信。外部流量通过负载均衡器或网关进入。

• 子网（subnet）：把 VPC 划分成几段。公有子网能访问互联网（给 API 服务器用）；私有子网不能（给数据库、GPU worker 用）。这是安全"最小权限原则"在网络层的对应物。

• 安全组（security groups，AWS） / 防火墙规则（firewall rules，GCP）：控制哪些流量被允许。"允许任意来源的 80 端口入站 HTTP。仅允许我的 IP 的 22 端口入站 SSH。其余全部拒绝。"配置错误的安全组是云安全事件的头号原因。

• 服务网格（service mesh）（Istio、Envoy）：管理 K8s 内部的服务间通信。提供：mTLS 加密（每次服务间调用都加密）、流量路由（A/B 测试：把 10% 流量导到新模型）、重试、超时、熔断，以及可观测性（哪个服务调了哪个服务、花了多久）。

Serverless

• Serverless（AWS Lambda、GCP Cloud Functions）：你上传一个函数，云厂商在触发时运行它。无需管理服务器，无需配置扩缩容。按调用次数付费（通常 $0.20/百万次调用 + 计算时间）。

• 冷启动（cold starts）：一段不活跃期之后的第一次调用会更慢（厂商需要分配容器并加载你的代码）。冷启动在 0.5-5 秒，所以 serverless 不适合延迟敏感的 ML 推理。

• 对 ML 而言：serverless 适合：预处理（送进模型前调整图片大小）、后处理（格式化模型输出、发通知）、编排（新数据到了就触发训练流水线），以及轻量推理（小模型、能容忍冷启动的场景）。

• Serverless 不适合：GPU 推理（大多数 serverless 平台不支持 GPU）、长时间训练任务（Lambda 有 15 分钟超时），或需要保存状态的服务（调用之间没有持久状态）。

成本管理

• 云成本是 ML 团队的头号运营顾虑。单张 H100 实例约 $8/小时。一次 64 张 GPU 的训练约 $500/小时。跑一个月的训练约 $360,000。成本优化是工程问题，不是会计问题。

• 竞价实例/可抢占实例（spot/preemptible instances）：云厂商把闲置容量以 60-90% 折扣出售。厂商可以在 30 秒到 2 分钟通知后收回。适合：容错训练（频繁 checkpoint，换台实例续训）、批量推理、数据预处理。不适合：延迟敏感的服务（被中断 = 宕机）。

• 预留实例（reserved instances）：承诺用 1-3 年，换 30-60% 折扣。适合：负载基线稳定的推理服务。

• 自动扩缩容：高峰期扩容，夜间/周末缩容。一个峰值要 10 张 GPU、夜间只要 2 张的模型服务器，靠自动扩缩容比 7×24 小时跑 10 张 GPU 能省约 60%。

• 合理选型（right-sizing）：别拿 H100 跑一个在 A10G 上就跑得很好的 7B 模型。把 GPU 和工作负载匹配起来。用 profiling（第 16 章）来确定哪种 GPU 最合适。

• 存储成本：对象存储很便宜（S3 Standard 约 $0.023/GB/月），但会累积。一个团队如果保留每个训练 checkpoint（每个 10 GB、每次实验 100 个、共 50 次实验），就会攒出 50 TB = $1,150/月。设置生命周期策略，自动删除旧 checkpoint。

多区域部署

• 对面向全球用户的 ML 系统来说，只部署在一个区域意味着：远端用户延迟高（东京的用户访问美国服务器，单程网络往返就多约 150ms），以及单一故障点（该区域宕机，整个服务下线）。

• 多区域模式：

  • 主-备（active-passive）：一个主区域处理全部流量。一个备用区域保持热备（数据已复制、随时可以接管）。主区域故障时，DNS 切换到备用区域。故障转移期间的停机时间：30 秒到几分钟。

  • 双活（active-active）：两个区域同时处理流量。用户被路由到最近的区域。两个区域都持有最新数据（异步或同步复制）。单区域故障时不停机——流量被自动重新路由。

• 数据复制：这才是难点。模型权重复制很容易（每个区域都拷贝到 S3）。特征存储的数据必须在可接受的陈旧度内复制。用户数据可能有数据驻留要求（GDPR：欧洲用户的数据必须留在欧洲）。

• GPU 云价格对比（约数，2026 年）：

• 竞价/可抢占价格通常比上表低 60-70%。价格随区域和供需波动。

基础设施即代码

• 基础设施即代码（Infrastructure as Code，IaC） 把基础设施（虚拟机、网络、数据库、K8s 集群）定义在带版本控制的配置文件里。与其在 AWS 控制台里点按钮，你不如写代码描述你要什么，然后让工具去创建。

• Terraform（HashiCorp）：标准的 IaC 工具。支持所有主流云厂商。声明式：你描述期望状态，Terraform 自己算出要创建/修改/删除什么才能达到它。

# main.tf — 创建一台用于推理的 GPU 虚拟机
resource "aws_instance" "model_server" {
  ami           = "ami-0abcdef1234567890"  # Deep Learning AMI
  instance_type = "g5.xlarge"               # A10G GPU

  tags = {
    Name = "model-server-prod"
  }
}

resource "aws_s3_bucket" "model_weights" {
  bucket = "my-model-weights-prod"

  versioning {
    enabled = true
  }
}
​

terraform init      # 下载 provider 插件
terraform plan      # 显示将会发生什么变化
terraform apply     # 创建基础设施
terraform destroy   # 把它全部拆掉
​

• 为什么 IaC 重要：可复现（用代码就能重建整套基础设施）、可审计（git 历史显示谁改了什么）、灾难恢复（用同一份配置在另一个区域重建）、环境一致性（开发、预发布、生产用同一套模板、不同参数）。

• Pulumi：类似 Terraform，但用真正的编程语言（Python、TypeScript、Go）而非 HCL。当你的基础设施逻辑复杂（条件、循环、动态配置）时很有用。