亚马逊 AWS 宣布 2027~2028 年将额外部署 200 万块 NVIDIA GPU。这个数字放在 AI 基础设施行业里是一个很明确的信号：云厂商不仅愿意持续采购加速卡，也在为更大规模的训练和推理集群做准备。对一线开发者和运维工程师来说，真正有价值的不是在新闻里看热闹，而是提前把云上 GPU 的使用方式、驱动管理、容器化、监控排错和成本控制这些基本功补齐。
我按这条链路来梳理：先明确新闻对工程实践意味着什么，再完成 GPU 实例选型，接着创建实例、安装驱动、用容器跑通一次 PyTorch 的 GPU 推理，然后处理监控和成本，最后把高频报错的排查路径整理成清单。整套流程可以在你自己的 AWS 账号里跑通一个最小闭环。这套思路同样适用于未来规模更大的 GPU 集群。
开始之前要先把预期拉平：已经明确的信息是部署总量为 200 万块，时间范围是 2027 到 2028 年。具体型号、区域分布和上线节奏，要以官方后续公告为准。文章里涉及 AWS 和 NVIDIA 产品能力的地方，只讨论通用用法和工程经验，落地前要看对应时间点的官方文档。
1. 200 万块 GPU 的新闻背后，云上 AI 工程到底发生了什么变化
1.1 这笔投资规模对开发者意味着什么
200 万块 GPU 不是一次性上线，而是放在 2027 到 2028 年这两年周期里部署。时间跨度长，意味着这更像一次基础设施扩容计划，而不是短期促销。对使用 AWS 的团队来说，核心影响是未来几年里，按需获取大规模 GPU 算力会比现在更容易，实例种类和区域覆盖也可能更广。
但这里需要区分“新闻”和“当前可用能力”。现在你打开 AWS 控制台，能够创建的是当前已经开放的 GPU 实例类型和区域组合。配额和容量仍然受账号状态影响。等到新集群真正上线后，实际开放的规格和区域，要以官方公告为准。
对开发者个人而言，这笔投资带来的最大变化并不在“能买到多少卡”，而在于整个 AI 应用栈会进一步标准化：
- 镜像、驱动、CUDA 版本会像软件制品一样被管理和追踪。
- 容器运行时和调度器会成为 GPU 使用的默认入口。
- 监控、配额、成本和回收会成为上云后的必修课。
这些能力不是买卡自动获得的，需要在日常项目里逐项练习。
1.2 自建 GPU 集群与云上 GPU 实例的差异
自建 AI 集群的传统路径是：采购服务器，安装 GPU 卡，配置机房承重和散热，再部署驱动和调度平台。这条路径更适合规模稳定、利用率高、对数据主权有严格要求的团队。一旦出现 GPU 型号迭代、突发扩容或业务波动，自建方案的调整周期会很长。
云上 GPU 实例则把硬件变成 API 化的资源。创建一台实例等价于申请 CPU、内存、GPU、磁盘和网络的组合，用完可以释放，不需要考虑物理设备生命周期。不过“云上”并不等于“免运维”，实例拿到手之后，驱动、容器运行时、镜像、监控仍然需要你来负责。
| 维度 | 自建 GPU 集群 | AWS GPU 实例 |
|---|---|---|
| 获取速度 | 采购、上架、调测周期长 | 分钟级创建 |
| 扩容方式 | 需要提前备货 | 按需创建，受配额限制 |
| 运维范围 | 硬件、固件、散热、机房全包 | 实例内操作系统和软件栈归你 |
| 成本结构 | 固定资本支出 | 按小时或秒计费 |
| 失败恢复 | 需要自建冗余 | 可重新创建实例，但数据要规划 |
| 适合场景 | 长期稳定、高利用率 | 弹性负载、多团队共享、实验验证 |
这个对比决定了后面的操作方式：在 AWS 上，你不需要关心物理服务器，但必须关心实例规格、AMI、驱动、存储和网络配置。
1.3 云上 GPU 使用的基本链路
云上运行一个 GPU 负载，完整链路是这样的：
- 选择实例类型和镜像。
- 创建实例并配置安全组。
- 在实例内安装或确认 NVIDIA 驱动。
- 安装容器运行时，让容器可以访问 GPU。
- 启动训练或推理容器。
- 通过 nvidia-smi、监控面板和日志确认程序运行情况。
- 用完释放实例，避免持续计费。
后面的章节就按这条链路展开。实际操作前，先解决选型问题。
2. 选 GPU 实例前先分清训练、推理和显存约束
2.1 AWS GPU 实例的基本构成
在 AWS 控制台里看到的 GPU 实例，本质是一个由 CPU、内存、本地磁盘、GPU 卡和网络带宽组成的组合。实例类型通常用几个字母加数字表示，首字母代表用途，数字代表代际和规格。例如常见的 GPU 实例族一般以 G、P 开头，G 系列多面向图形和普通 GPU 计算，P 系列多面向高性能计算和深度学习训练。具体型号会随时间更新，选型时要以官网“实例类型”页面为准。
除了通用 GPU 实例，AWS 还提供面向 AI 推理优化的实例，这类实例可能集成专用加速芯片，也可能使用特定 NVIDIA GPU。另外还有托管服务，例如 SageMaker 可以把底层 GPU 实例包装成训练和推理作业入口；ECS 和 EKS 也可以把 GPU 实例纳入容器集群。选择哪一层，取决于你希望自己管理多少底层细节。
2.2 训练负载与推理负载的选型差异
训练和推理对硬件的要求并不一样。训练的特点是：数据量大、迭代时间长、显存占用高、允许分批处理。推理的特点是：延迟敏感、并发波动大、对单卡吞吐和批处理能力要求高。
| 对比维度 | 训练任务 | 推理任务 |
|---|---|---|
| 核心指标 | 吞吐量、训练时长 | 延迟、QPS、单次请求耗时 |
| GPU 重点 | 显存容量、计算吞吐 | 低延迟、批次推理能力 |
| 实例数量 | 稳定长跑，适合预留 | 随流量波动，适合自动扩缩容 |
| 容错要求 | 需要 checkpoint，容错重跑 | 需要多副本和负载均衡 |
| 成本策略 | 可用 Spot + 中断恢复 | 需要稳定容量，避免冷启动失败 |
| 存储需求 | 大规模数据集和日志 | 模型文件和缓存 |
选错类型的典型后果是：训练任务放在低显存实例上，OOM 频繁；推理服务放在训练型大卡上，成本居高不下。所以选型第一步不是看哪个实例 GPU 多，而是把负载类型写清楚。
2.3 选型前先列一张检查清单
在创建任何 GPU 实例之前，先回答下面这些问题：
- 工作负载是训练、推理还是实验调试？
- 模型参数规模多大，单卡显存是否放得下？
- 是单机训练还是多机分布式训练，需要多大网络带宽？
- 数据放在 EBS、S3 还是实例存储，IO 是否满足需求？
- 是否有 GPU 配额，目标区域是否提供该实例类型？
- 预算上限是多少，能否接受 Spot 实例？
把答案写进一个表格或 Wiki 页面，然后才开始创建资源。很多“实例创建好了但跑不动”的问题，根源都出在选型阶段没有确认显存和数据规模。
3. 在 AWS 上从零创建一台 NVIDIA GPU 实例
3.1 创建前的前提条件
三个前提条件必须提前确认。
第一，IAM 权限。创建实例至少需要 EC2 相关权限，比如 ec2:RunInstances、ec2:DescribeInstances、ec2:TerminateInstances。生产环境不要用管理员权限跑日常操作，可以把权限收敛到一个专用角色。
第二，配额。AWS 对每个区域的 vCPU 和 GPU 实例数量有限制。在 Service Quotas 控制台搜索 EC2，查看目标实例类型的 vCPU 配额。如果配额为 0，需要先提交提高配额申请。
第三，密钥和网络。准备一个密钥对用于 SSH 登录，创建 VPC、子网和安全组。安全组至少要放行 SSH（22 端口），进入生产环境再按最小原则放行其他端口。
3.2 使用控制台或 AWS CLI 创建实例
学习阶段推荐先在控制台操作一遍，熟悉界面里的参数。控制台选项包括 AMI、实例类型、密钥对、网络设置、存储大小，以及高级设置里的用户数据脚本。如果习惯命令行，可以用 AWS CLI。下面是一个最小示例，实际执行前把 ami、子网、安全组和密钥换成你自己账号里的资源 ID：
aws ec2 run-instances \ --image-id ami-0000000000000000 \ --instance-type g4dn.xlarge \ --key-name my-key \ --security-group-ids sg-0000000000000000 \ --subnet-id subnet-0000000000000000 \ --block-device-mappings '[{"DeviceName":"/dev/sda1","Ebs":{"VolumeSize":100,"VolumeType":"gp3"}}]'命令参数含义：
- image-id：AMI 的 ID，决定了操作系统和预装软件。
- instance-type：实例规格，选型阶段确认好的类型。
- key-name：SSH 密钥对名称。
- security-group-ids：安全组 ID。
- subnet-id：子网 ID。
- block-device-mappings：根磁盘大小和类型。
创建完成后，用 describe-instances 查看实例状态：
aws ec2 describe-instances \ --instance-ids i-0000000000000000 \ --query 'Reservations[0].Instances[0].State.Name'正常情况下返回值是 running。随后通过 SSH 登录：
ssh -i my-key.pem ubuntu@<公网IP>这里有一个常见误区：很多初学者创建实例后，先用控制台的浏览器终端连接，发现没有密码。EC2 默认不设置 SSH 密码，登录依赖密钥对。如果创建时没有选择密钥对，后续只能重建实例。
3.3 安装 NVIDIA 驱动与 CUDA
登录实例后，先用下面的命令确认系统里是否能识别到 NVIDIA 设备：
lspci | grep -i nvidia如果输出为空，说明当前 AMI 的虚拟化环境下没有正确暴露 GPU，需要检查实例类型是否为 GPU 实例。如果能看到设备，接着检查驱动：
nvidia-smi如果提示 command not found，说明驱动未安装。AWS 官方 Deep Learning AMI 通常会预装 NVIDIA 驱动和 CUDA，适合希望快速开始的人。如果使用 Ubuntu 官方镜像，则需要手动安装驱动和 CUDA Toolkit。
下面是在 Ubuntu 上安装 CUDA 的示例。示例使用 CUDA 12.4.1，实际安装前先到 NVIDIA 官方页面确认最新版本和操作系统匹配信息：
sudo apt update sudo apt install -y build-essential wget https://developer.download.nvidia.com/compute/cuda/12.4.1/local_installers/cuda_12.4.1_550.54.15_linux.run sudo sh cuda_12.4.1_550.54.15_linux.run --toolkit --silent安装结束后，把 CUDA 的 bin 和 lib 目录加入 PATH 和 LD_LIBRARY_PATH：
export PATH=/usr/local/cuda/bin:$PATH export LD_LIBRARY_PATH=/usr/local/cuda/lib64:$LD_LIBRARY_PATH推荐把这两行写入 ~/.bashrc，避免每次登录都要重新设置。
注意：不要为了追求“最新”而盲目安装最高版本 CUDA。先确认你的深度学习框架版本支持哪些 CUDA 版本，再决定安装哪个驱动。驱动和 CUDA 的兼容关系以 NVIDIA 官方兼容矩阵为准。
3.4 验证 GPU 是否被系统识别
安装完成后，运行：
nvidia-smi理想输出类似下面这样：
+-----------------------------------------------------------------------------+ | NVIDIA-SMI 550.54.15 Driver Version: 550.54.15 CUDA Version: 12.4 | |-------------------------------+----------------------+----------------------+ | GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. | |===============================+======================+======================| | 0 Tesla T4 Off | 00000000:00:1E.0 Off | 0 | | 0% 45C P0 35W / 70W | 1356MiB / 15360MiB | 0% Default | +-------------------------------+----------------------+----------------------+需要弄明白 nvidia-smi 输出里几个字段的含义：
- Driver Version：宿主机驱动的版本。
- CUDA Version：当前驱动支持的最高 CUDA 版本，不代表你已经安装了对应 CUDA Toolkit。
- Memory-Usage：GPU 显存占用，单位 MiB。
- GPU-Util：GPU 计算单元利用率，不代表程序一定在最优状态。
如果输出正常，说明驱动和设备节点都可用。下一步再讨论容器化。
4. 容器里跑 GPU 工作负载：NVIDIA Container Toolkit
4.1 为什么推荐用容器管理 GPU 环境
直接在宿主机上安装 CUDA、cuDNN、PyTorch 等依赖，对一个实验项目来说可行，但在多团队或多项目场景下很容易出问题。项目 A 需要 CUDA 11，项目 B 需要 CUDA 12，如果都在同一台服务器上，版本冲突很难避免。
容器把整个运行环境打包成镜像，里面包含 CUDA 运行时、Python 依赖和业务代码。宿主机只需要安装 GPU 驱动，容器内部则使用驱动通过 CUDA 暴露的接口。这样不同项目可以跑不同 CUDA 版本，互不干扰。
NVIDIA Container Toolkit 是连接二者的关键组件。它会把宿主机的 GPU 设备、驱动库和特权能力注入容器，让容器内的 nvidia-smi 和 CUDA 程序可以直接访问 GPU。
4.2 安装 NVIDIA Container Toolkit
在 Ubuntu 实例上安装的典型命令如下：
curl -s -L https://nvidia.github.io/libnvidia-container/gpgkey | sudo apt-key add - distribution=$(. /etc/os-release;echo $ID$VERSION_ID) curl -s -L https://nvidia.github.io/libnvidia-container/$distribution/libnvidia-container.list | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list sudo apt-get update sudo apt-get install -y nvidia-container-toolkit安装完成后，把 runtime 配置到 Docker：
sudo nvidia-ctk runtime configure --runtime=docker sudo systemctl restart dockernvidia-ctk 会在 Docker daemon 配置里增加 nvidia runtime。重启 Docker 后，检查 runtime 是否出现：
docker info | grep -i runtime如果看到类似 Runtimes: nvidia 的字段，表示配置成功。
4.3 用 PyTorch 容器验证 GPU 可用性
先用一个基础镜像验证容器是否能访问 GPU：
docker run --rm --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi如果命令输出 GPU 信息，说明容器运行时和驱动都正常。
接着看深度学习环境。这里推荐使用带 CUDA 的 PyTorch 官方镜像，注意镜像标签要和你安装的 CUDA 版本匹配。运行下面的命令，验证 PyTorch 能否在 GPU 上工作：
docker run --rm --gpus all -v $(pwd):/workspace \ pytorch/pytorch:2.2.0-cuda12.1-cudnn8-runtime \ python -c "import torch; print(torch.cuda.is_available(), torch.cuda.device_count(), torch.cuda.get_device_name(0))"预期输出是 True、1 和 GPU 型号名，例如：
True 1 Tesla T4如果输出 False，说明容器没有拿到 GPU 或 CUDA 版本不匹配。
进一步验证 GPU 上的张量计算：
import torch x = torch.rand(1024, 1024, device="cuda") y = torch.mm(x, x) print(y.shape) print(torch.cuda.memory_allocated() / 1024 / 1024, "MiB")这段代码在 GPU 上生成两个 1024 乘 1024 的随机矩阵并做矩阵乘法。输出维度是 torch.Size([1024, 1024])，memory_allocated 会显示当前分配的显存大小，说明 CUDA 上下文已经建立并使用了显存。
4.4 容器化场景里的一个高频坑
在容器里运行程序时，最常遇到的问题是“宿主机能用 GPU，容器里不能用”。原因通常是：
- 没有安装 nvidia-container-toolkit。
- Docker daemon 没有重启，runtime 配置未生效。
- docker run 命令缺少 --gpus all。
- 镜像里没有 CUDA 运行库，只在宿主机装了 CUDA。
排查顺序是先跑 nvidia/cuda 基础镜像
