AWS部署200万块NVIDIA GPU，云上GPU环境搭建与容器化实战指南

最近不少关注 AI 基础设施和云原生技术的同学应该都看到了这条消息AWS 宣布将在 2027 到 2028 年间额外部署 200 万块 NVIDIA GPU。放在整个云服务市场来看这是一个相当有信号意义的动作因为它不仅关系到 AWS 自身的算力储备也直接影响后面几年企业在云上做大模型训练、微调和推理的选型路径。我最初看到这条新闻时第一反应并不是“AWS 又买了很多卡”而是“这笔基础设施投入最终会以什么样的方式传导到普通开发者和技术团队手中”。毕竟 GPU 实例的价格、可用区域、实例规格、配额限制都和后端算力池的规模直接相关。这篇文章我想从几个层面展开先拆解事件本身和它背后的技术含义再落到 AWS 上实际使用 NVIDIA GPU 的完整流程包括环境搭建、容器化配置、镜像权限排查和成本优化。无论你是做 AI 应用开发还是负责云上基础设施都可以把这篇文章当成一份可落地的上手指南来用。1. 事件背景与核心概念1.1 AWS、NVIDIA、GPU 三者是什么关系先补充一下基础概念。AWS 是亚马逊旗下的云计算服务商提供从计算、存储、网络到数据库、机器学习平台等一系列云产品。NVIDIA 是当前 AI 算力领域最主要的 GPU 芯片设计厂商其 GPU 被广泛用于深度学习训练、推理、图形渲染和科学计算。GPU 全称是 Graphics Processing Unit最初为图形处理设计但因为具备大量并行计算核心后来被引入通用计算领域成为深度学习时代的核心硬件。在云上使用 GPU并不是让你自己买一块显卡插进服务器而是通过云厂商提供的高性能实例来使用。AWS 提供多种 GPU 实例类型例如 P4、P5、G4、G5 等这些实例底层挂载的就是 NVIDIA 的 GPU。AWS 宣布额外部署 200 万块 NVIDIA GPU本质上是在未来一到两年内大幅扩充云端 GPU 容量让用户更容易申请到高性能计算资源。1.2 “额外部署 200 万块 GPU”是什么量级200 万这个数字单独看可能不够直观。我们可以做一个粗略对比一个标准的 AI 训练集群如果使用单机 8 卡的配置200 万块 GPU 相当于 25 万台 8 卡服务器。即使不是所有 GPU 都用于大模型训练而是分散到推理、渲染、科学计算和云游戏等场景这个规模也足以对全球 AI 算力供给格局产生明显影响。从 AWS 的角度看这些年大模型训练和推理的需求增长非常快。一个千亿参数模型的预训练往往需要数千张 GPU 连续运行数周甚至数月而推理阶段的并发需求更是难以预测。对于云厂商来说提前锁定未来两年的 GPU 供应不只是为了满足当前客户更是为了在下一轮 AI 应用爆发时保有足够的资源弹性。1.3 这对开发者意味着什么对普通开发者和中小团队来说最大的影响可能体现在三个方面。第一GPU 实例的可申请性会提升。过去在热门区域申请高端 GPU 实例经常遇到容量不足的问题。随着 AWS 大规模扩充 GPU 池这种资源短缺的体验可能会逐步缓解。第二实例规格会更加丰富。除了面向训练的 H100/H200 级别实例推理场景用的 L4、L40S 等 GPU 实例也会有更多选择。不同业务阶段可以选择不同性价比的卡。第三工具链会继续完善。GPU 硬件扩容只是基础真正让开发者用起来的是配套的容器服务、镜像管理、集群编排和监控工具。AWS 的 ECS、EKS、Batch、SageMaker 等服务都会围绕这些 GPU 资源做更深度的集成。2. 云上 GPU 实例选型与 NVIDIA GPU 生态2.1 常见 NVIDIA GPU 型号及适用场景在了解 AWS GPU 实例之前先梳理一下当前常见的 NVIDIA GPU 型号和它们对应的场景。需要注意GPU 选型通常是训练和推理场景的分水岭。GPU 型号主要定位典型场景关键特性A10G推理与中等规模训练在线推理、Stable Diffusion、小型模型微调24GB 显存性价比高L4推理和边缘计算视频推理、语音识别、轻量级 AI 服务24GB 显存能效比好L40S图形与 AI 双场景渲染、微调、推理48GB 显存支持多场景A100大规模训练与推理预训练、微调、高性能推理40GB/80GB 显存NVLink 支持H100大模型训练和推理GPT 级别模型预训练、大规模推理集群80GB HBM3性能大幅提升H200下一代大模型训练更大显存容量的训练和推理141GB HBM3e适合超大模型这里要提醒一下NVIDIA 的产品迭代速度很快实际可用的 GPU 型号会随时变化。关键不是记住型号而是学会根据“显存容量、算力级别、互联带宽、成本”这四个维度来选型。2.2 AWS GPU 实例与 NVIDIA GPU 的对应关系AWS 的 GPU 实例通常以 P 系列和 G 系列命名。P 系列偏重于高性能计算和训练G 系列偏重于图形处理、推理和轻量级 AI 负载。常见的对应关系如下g4dn系列使用 NVIDIA T4 GPU适合轻量级推理、视频转码、虚拟桌面。g5系列使用 NVIDIA A10G GPU适合中小规模训练、Stable Diffusion、在线推理。p4d系列使用 NVIDIA A100 GPU适合大模型训练、科学计算。p5系列使用 NVIDIA H100 GPU适合大规模预训练和高性能推理。g6系列使用 NVIDIA L4 GPU适合主流推理和 AI 应用。选实例类型时可以先从两个问题入手。你的模型有多大你的服务并发有多高。如果只是跑 7B 参数的模型推理选 24GB 显存的 A10G 或 L4 通常就够了如果要微调 70B 级别模型至少需要 A100 80GB 或 H100 级别的实例如果是千万级 DAU 的推理服务则需要考虑多卡横向扩展和自动扩缩容。2.3 为什么 GPU 互联和显存容量很关键除了 GPU 型号本身还有一个容易被忽略的点GPU 之间的互联方式。训练大模型时模型并行和数据并行都会产生大量 GPU 间通信。NVIDIA 的 NVLink 和 NVSwitch 技术可以显著提升多卡通信带宽减少训练等待时间。AWS 的 P4 和 P5 实例在底层就是通过高速网络和 NVLink 把多张 GPU 连接在一起。如果你只是做单卡推理那么 GPU 互联的影响不大但如果要做多卡训练就不能只看单卡算力还要看实例内部 GPU 拓扑和网络带宽。这也是为什么很多团队在本地测试时用几张 RTX 4090 可以跑通代码但上了大规模 GPU 集群后性能反而上不去原因往往就出在通信瓶颈上。3. 在 AWS 上搭建 GPU 深度学习环境这部分是实操重点。我们以一个完整的流程为例从创建 GPU 实例开始到安装 NVIDIA 驱动再到容器化跑起一个 PyTorch 程序。为了确保可复制性我会尽量使用命令行和配置文件来完成操作。3.1 创建 AWS EC2 GPU 实例首先登录 AWS 控制台进入 EC2 服务页面点击“启动实例”。在配置过程中有几个关键点需要特别注意。第一个是 AMI 的选择。建议选择包含 NVIDIA 驱动和 CUDA 的 Deep Learning AMI这样可以省去不少手动安装驱动的麻烦。你也可以选择普通的 Ubuntu AMI然后自己安装驱动但需要格外注意内核版本和驱动版本的匹配。第二个是实例类型。这里我们以g5.xlarge为例它带一张 NVIDIA A10G GPU适合做推理和中等规模训练演示。如果是生产环境的大模型训练可以换成p4d.24xlarge或p5.48xlarge。第三个是存储和密钥对。建议系统盘选择至少 100GB 的 SSD因为 AI 镜像和模型文件都比较占空间。密钥对一定要下载并保存好这是 SSH 登录实例的唯一凭证。创建实例时可以不在网页上点击而是用 AWS CLI 来操作。下面的命令展示了如何通过 CLI 创建 GPU 实例aws ec2 run-instances \ --image-id ami-0abcdef1234567890 \ --instance-type g5.xlarge \ --key-name your-key-pair \ --security-group-ids sg-0123456789abcdef0 \ --subnet-id subnet-0123456789abcdef0 \ --block-device-mappings [{DeviceName:/dev/sda1,Ebs:{VolumeSize:100,VolumeType:gp3}}] \ --tag-specifications ResourceTypeinstance,Tags[{KeyName,Valueai-gpu-demo}]需要提醒的是image-id和subnet-id会因区域不同而变化。你可以通过aws ec2 describe-images和aws ec2 describe-subnets查询当前区域下的可用值。生产环境中不建议在命令行明文传递敏感配置应使用环境变量或 AWS Vault 等方式管理。3.2 安装与验证 NVIDIA 驱动如果选择了 Deep Learning AMI驱动通常已经预装。可以通过nvidia-smi命令验证 GPU 是否被系统正确识别。nvidia-smi正常输出类似下面这样----------------------------------------------------------------------------- | NVIDIA-SMI 545.23.08 Driver Version: 545.23.08 CUDA Version: 12.3 | |--------------------------------------------------------------------------- | GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Max Power | || | 0 A10G Off | 00000000:00:1E.0 Off | 0% | | N/A 42C P0 36W / 300W | 0MiB / 23034MiB | 0% Default | ---------------------------------------------------------------------------如果系统提示找不到nvidia-smi命令说明驱动没有安装或者尚未加载。此时需要手动安装驱动。以 Ubuntu 为例可以按下面的顺序操作。sudo apt update sudo apt install -y build-essential然后从 NVIDIA 官网下载与实例 GPU 型号匹配的驱动安装包。这里不建议使用默认系统源里的过老驱动容易出现不兼容问题。安装驱动后重启实例再执行nvidia-smi验证。3.3 安装 CUDA 与 NVIDIA Container Toolkit驱动安装好之后如果要在容器里使用 GPU还需要安装 NVIDIA Container Toolkit。它的作用是把宿主机的 GPU 设备映射到 Docker 容器中让容器内的程序可以直接调用 GPU。安装 NVIDIA Container Toolkit 的常用步骤# 添加官方仓库 curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey \ | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list \ | sed s#deb https://#deb [signed-by/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g \ | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list # 安装 sudo apt update sudo apt install -y nvidia-container-toolkit安装完成后需要配置 Docker 使用 NVIDIA Container Runtimesudo nvidia-ctk runtime configure --runtimedocker sudo systemctl restart docker之后运行带 GPU 的容器时需要加上--gpus参数。例如docker run --rm --gpus all nvidia/cuda:12.3.1-base-ubuntu22.04 nvidia-smi如果容器内能正确输出 GPU 信息说明整套环境已经打通。3.4 跑一个 PyTorch GPU 示例接下来我们用一个简单的 PyTorch 示例验证 GPU 是否可以被深度学习框架调用。创建一个测试文件gpu_test.pyimport torch # 检查 CUDA 是否可用 print(CUDA available:, torch.cuda.is_available()) # 获取当前 GPU 名称 if torch.cuda.is_available(): print(GPU name:, torch.cuda.get_device_name(0)) # 在 GPU 上创建一个随机张量并执行矩阵乘法 a torch.randn(1024, 1024, devicecuda) b torch.randn(1024, 1024, devicecuda) c torch.matmul(a, b) print(Matrix multiplication result shape:, c.shape)运行方式有两种。第一种是直接在宿主机上运行前提是已经安装了 PyTorch 的 GPU 版本。pip install torch torchvision python gpu_test.py第二种是使用 Docker 镜像运行这样可以避免污染宿主机环境。这里推荐使用 PyTorch 官方镜像启动容器时挂载当前目录docker run --rm --gpus all \ -v $(pwd):/workspace \ -w /workspace \ pytorch/pytorch:2.1.0-cuda12.1-cudnn8-runtime \ python gpu_test.py如果一切正常会看到类似下面的输出CUDA available: True GPU name: NVIDIA A10G Matrix multiplication result shape: torch.Size([1024, 1024])到这里一个最小可用的云上 GPU 深度学习环境就搭建完成了。4. 在 ECS 和 EKS 中使用 GPU 算力单台 EC2 GPU 实例适合开发调试和中小规模任务但生产环境的 AI 服务通常需要容器编排。这里补充介绍 ECS 和 EKS 中使用 GPU 的关键点也顺便回应一个很常见的疑问ECS 怎么确认任务有权限从 ECR 拉取镜像。4.1 ECS 中配置 GPU 任务ECS 是 AWS 的容器编排服务使用起来相对简单。要让 ECS 任务使用 GPU需要在任务定义中声明 GPU 资源。下面是一个 ECS 任务定义的片段假设我们使用的是 EC2 启动类型{ family: gpu-inference-task, taskRoleArn: arn:aws:iam::123456789012:role/ecsTaskRole, executionRoleArn: arn:aws:iam::123456789012:role/ecsExecutionRole, containerDefinitions: [ { name: triton-server, image: 123456789012.dkr.ecr.us-east-1.amazonaws.com/my-ai-app:latest, memory: 8192, cpu: 4096, hardwareRequirements: [ { type: GPU, value: 1 } ], portMappings: [ { containerPort: 8000, hostPort: 8000 } ] } ], requiresCompatibilities: [EC2], cpu: 4096, memory: 8192 }在旧版本的控制台里GPU 参数可能叫resourceRequirements写法略有不同。核心思路都一样告诉调度器这个任务需要几张 GPU调度器会把它放到带有 GPU 的容器实例上。如果使用 Fargate 启动类型需要选择支持 GPU 的 Fargate 平台版本并且镜像和任务角色都需要按 Fargate 的要求配置。目前并不是所有区域都支持 Fargate GPU使用前需要核对区域可用性。4.2 排查 ECS 拉取 ECR 镜像的权限问题生产环境中经常遇到这样的报错ECS 任务启动失败事件里提示CannotPullContainerError原因通常是拉取 ECR 镜像时没有权限。ECR 是 AWS 的容器镜像仓库服务。当执行任务的角色没有ecr:GetAuthorizationToken和ecr:BatchGetImage权限时ECS 在拉取镜像阶段就会失败。排查思路可以按下面的步骤来。第一步确认任务使用的执行角色。在任务定义中executionRoleArn指向的 IAM 角色负责拉取镜像和获取日志。第二步检查这个执行角色是否附加了AmazonEC2ContainerRegistryReadOnly策略。如果没有可以手动添加以下最小权限策略。{ Version: 2012-10-17, Statement: [ { Effect: Allow, Action: [ ecr:GetAuthorizationToken, ecr:BatchCheckLayerAvailability, ecr:GetDownloadUrlForLayer, ecr:BatchGetImage, logs:CreateLogStream, logs:PutLogEvents ], Resource: * } ] }第三步在本地使用 AWS CLI 验证权限是否生效。aws ecr get-authorization-token --region us-east-1如果返回AuthorizationToken说明账号级凭证没有问题。接着再尝试拉取镜像aws ecr describe-images \ --repository-name my-ai-app \ --region us-east-1这一步可以验证 ECR 仓库是否存在以及镜像标签是否正确。实际项目中经常出现开发环境可以拉取、生产环境不能拉取的情况这个差异通常就是因为生产环境的 ECS 任务执行角色和开发环境不同没有继承对应的 IAM 策略。4.3 EKS 中使用 GPU 的注意事项如果团队已经上了 Kubernetes用 EKS 管理 GPU 工作负载是更灵活的选择。在 EKS 中要让 Pod 使用 GPU需要节点上预先安装 NVIDIA 驱动并且在集群里部署 NVIDIA Device Plugin让 kubelet 可以感知节点上的 GPU 资源。部署 Device Plugin 的通用做法是kubectl create -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/main/nvidia-device-plugin.yml部署完成后可以通过节点状态查看 GPU 资源kubectl describe node your-gpu-node | grep nvidia.com/gpu如果看到nvidia.com/gpu: 1或nvidia.com/gpu: 8说明 GPU 已经成功暴露给 Kubernetes 调度器。之后在 Pod 的resources.limits里声明nvidia.com/gpu: 1即可。也有不少团队使用 NVIDIA GPU Operator 来统一管理驱动、运行时和监控组件。GPU Operator 的好处是免去手动在每个节点上装驱动的步骤但部署复杂度略高适合节点规模较大的生产集群。5. 常见问题与排查思路在云上使用 GPU 的过程中有几个问题属于“高频踩坑点”。这里整理成表格并提供详细排查思路。问题现象常见原因解决思路nvidia-smi提示 command not foundNVIDIA 驱动未安装或 PATH 未配置检查驱动安装包重启实例重新安装驱动容器内无法访问 GPU未安装 NVIDIA Container Toolkit或 Docker 未配置 runtime安装 toolkit执行nvidia-ctk runtime configure --runtimedocker创建 GPU 实例提示容量不足当前可用区 GPU 实例库存不够切换可用区或改用不同实例类型ECS 任务启动失败报 CannotPullContainerError执行角色没有 ECR 拉取权限检查 executionRoleArn 的 IAM 策略PyTorch 检测不到 CUDAPyTorch 版本与 CUDA 版本不匹配重新安装对应 CUDA 版本的 PyTorchWSL 中运行 Docker 时 GPU 访问被阻止未安装 Windows 版 NVIDIA 驱动或 WSL 配置不正确在 Windows 侧安装 NVIDIA 驱动确认 WSL 版本为 WSL 2GPU 利用率低但任务运行慢数据加载或 CPU 预处理成为瓶颈使用 DataLoader 多线程、AIO 或预处理流水线优化实例运行成本过高实例规格选择过大或长期运行使用竞价实例、节省计划或自动伸缩5.1 WSL 中的 GPU 访问被阻止虽然主题是云上 GPU但很多开发者会在本地用 WSL 调试代码然后发现 GPU 访问被操作系统拦截报错类似于failed to initialize nvml: gpu access blocked by the operating system。这个问题通常出现在 Windows 侧没有安装与 GPU 匹配的显卡驱动或者 WSL 版本不是 WSL 2。排查顺序建议如下在 Windows 运行winver确认系统版本。执行wsl --version确认 WSL 版本。安装 Windows 厂商提供的 NVIDIA 驱动而不是在 WSL 内安装 Linux 驱动。在 WSL 内执行nvidia-smi如果能输出信息说明 GPU 已经透传成功。之所以单独提这个是因为本地开发和云上部署很容易出现两套环境行为不一致的问题。先在本地把 GPU 环境调通再迁移到 AWS 实例能减少很多不必要的调试时间。5.2 GPU 实例创建过程中的安全组配置创建 GPU 实例时安全组如果配置得太开放会带来安全风险。建议只放行必要的端口。例如 SSH 端口只允许公司出口 IP 访问推理服务端口只对应用负载均衡器的安全组开放。AWS 安全组是实例级别的虚拟防火墙不支持“默认拒绝所有规则”之外的复杂动作但支持按来源 IP 和来源安全组进行控制。建议参考下面的最小放行策略22 端口仅对堡垒机或办公网段开放8000 端口仅对上游负载均衡器安全组开放其余端口默认拒绝这样可以尽量避免 GPU 实例因为端口暴露而被恶意攻击。6. 成本控制与工程最佳实践6.1 如何降低成本GPU 实例是云上成本的大头尤其是长期运行的大模型服务。成本控制可以从以下几个方面入手。第一按业务类型选择实例。训练任务可以使用按需实例保证稳定性推理任务可以结合自动扩缩容在流量低谷时缩容到零。如果业务有明确的峰谷周期可以提前做好容量规划。第二关注竞价实例。AWS 竞价实例的价格通常远低于按需实例适合无状态、可中断的任务例如模型评估、批量推理、夜间训练。但需要注意竞价实例可能被回收所以任务需要支持 checkpoint 恢复。第三使用节省计划或预留实例。如果确定未来一年内 GPU 使用量稳定可以通过 Savings Plans 降低成本。这种方式的灵活性比传统预留实例更好因为它可以覆盖不同实例类型。第四选择合适的区域。不同区域的 GPU 实例价格差异明显但生产环境需要考虑数据合规和网络延迟不能只看价格。6.2 监控与日志GPU 监控在 AI 服务中非常关键。除了常规的 CPU、内存、网络监控还需要关注 GPU 利用率、显存占用、GPU 温度和功耗。AWS 自带的 CloudWatch 可以采集一部分指标但更细粒度的 GPU 指标通常需要借助 NVIDIA DCGMData Center GPU Manager来采集。DCGM 支持 Prometheus 格式的指标导出再配合 Grafana 做可视化已经成为比较主流的方案。建议至少关注以下指标GPU 利用率反映算力是否被打满显存使用率反映模型和批处理大小是否合适GPU 温度温度过高可能导致降频GPU 功耗用来判断是否存在资源浪费PCIe 或 NVLink 带宽用于发现多卡通信瓶颈6.3 IAM 权限与安全管理在 AWS 上使用 GPU 资源权限管理不能忽视。良好的 IAM 策略应该遵循最小权限原则。例如给数据科学家分配权限时不需要授予管理员权限而是只允许创建和运行指定类型的 EC2 实例并限制在某个 VPC 子网内。给 CI/CD 角色分配权限时只需要允许更新 ECS 服务或 EKS 工作负载而不需要开放所有 AWS 权限。下面是一个限制用户创建 GPU 实例的 IAM 策略示例{ Version: 2012-10-17, Statement: [ { Effect: Allow, Action: [ ec2:RunInstances, ec2:DescribeInstances, ec2:DescribeInstanceTypes ], Resource: *, Condition: { StringEquals: { ec2:InstanceType: [ g5.xlarge, g5.2xlarge, p4d.24xlarge ] } } }, { Effect: Deny, Action: [ ec2:RunInstances ], Resource: *, Condition: { StringNotEquals: { ec2:InstanceType: [ g5.xlarge, g5.2xlarge, p4d.24xlarge ] } } } ] }不过要注意ec2:InstanceType在 RunInstances 的 condition key 支持情况和版本有关生产环境建议先在测试账号验证策略再应用到生产账号。另外所有涉及生产环境的变更都应该走审批流程并在变更前做好自动化和回滚预案。比如 ECS 服务更新时先观察滚动更新状态确认新任务健康后再继续。6.4 模型训练与推理的工程建议最后补充一些 AI 工程侧的实践经验这些经验在单机调试时不容易暴露但在生产环境非常关键。训练任务建议开启 checkpoint 自动保存并且把 checkpoint 保存到 Amazon S3。这样即使实例被回收或训练中断也能从最近的 checkpoint 继续不用从头开始。推理服务优先使用 Triton Inference Server 或 vLLM 这类高性能推理框架。它们支持动态批处理、连续批处理和 PagedAttention 等优化技术可以把 GPU 利用率提升到更高的水平。镜像管理方面建议把模型文件和代码分开。代码打成一个轻量镜像模型文件放在 S3 或者 EFS 上容器启动时再加载。这样可以避免频繁更新几百 GB 的镜像也能减少 ECR 拉取时间。7. 总结与后续学习方向AWS 宣布未来两年额外部署 200 万块 NVIDIA GPU这件事本身透露出的信号是 AI 算力需求仍然在快速增长而且云厂商愿意为此提前几年锁定产能。对我们普通开发者和技术团队来说更实际的意义在于接下来会有更多机会以合理成本使用高性能 GPU也需要更熟练地掌握云上 GPU 环境搭建、容器编排、权限管理和成本优化这些基本功。这篇文章里我们从事件背景聊到了核心概念再从 EC2 环境搭建一路走到 ECS/EKS 容器化使用最后整理了常见问题和工程建议。你可以把文章里的命令和配置当作一份起步模板先在一个测试账号里跑通端到端流程再逐渐扩展到生产环境。下一步如果想继续深入建议优先关注几个方向一是深度学习推理框架的选型和调优比如 vLLM、Triton、TensorRT-LLM这些工具决定了 GPU 利用率的上限二是 Kubernetes 环境下的 GPU 资源调度和自动扩缩容特别是 GPU 共享和 MIG 技术的使用三是 FinOps 思路下的云成本治理真正把每一块 GPU 的花费用在刀刃上。如果你最近刚好在 AWS 上部署过 GPU 服务欢迎在评论区分享你的实例选型和成本控制经验。遇到具体报错也可以把错误信息和场景发出来大家一起排查。