亚马逊 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、子网和安全组。安全组至少要放行 SSH22 端口进入生产环境再按最小原则放行其他端口。3.2 使用控制台或 AWS CLI 创建实例学习阶段推荐先在控制台操作一遍熟悉界面里的参数。控制台选项包括 AMI、实例类型、密钥对、网络设置、存储大小以及高级设置里的用户数据脚本。如果习惯命令行可以用 AWS CLI。下面是一个最小示例实际执行前把 ami、子网、安全组和密钥换成你自己账号里的资源 IDaws 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-idAMI 的 ID决定了操作系统和预装软件。instance-type实例规格选型阶段确认好的类型。key-nameSSH 密钥对名称。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_PATHexport 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-UsageGPU 显存占用单位 MiB。GPU-UtilGPU 计算单元利用率不代表程序一定在最优状态。如果输出正常说明驱动和设备节点都可用。下一步再讨论容器化。4. 容器里跑 GPU 工作负载NVIDIA Container Toolkit4.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 配置到 Dockersudo nvidia-ctk runtime configure --runtimedocker sudo systemctl restart dockernvidia-ctk 会在 Docker daemon 配置里增加 nvidia runtime。重启 Docker 后检查 runtime 是否出现docker info | grep -i runtime如果看到类似 Runtimes: nvidia 的字段表示配置成功。4.3 用 PyTorch 容器验证 GPU 可用性先用一个基础镜像验证容器是否能访问 GPUdocker 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, devicecuda) 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 基础镜像