AWS加购英伟达GPU：云上实例选型与CUDA环境实战指南

最近“亚马逊将英伟达芯片订单增至三倍新增 200 万颗 GPU”这条消息在开发者圈子里讨论度很高。很多朋友关注的不只是新闻本身更关心这波算力扩张对整个 AI 基础设施、云上 GPU 开发、以及日常训练部署会产生什么影响。这篇文章不打算只复述新闻而是顺着这条消息把背后涉及的 GPU 类型、AWS 实例选型、CUDA 环境搭建、常见驱动问题、集群调度和成本优化串起来给出一份能落地参考的实战笔记。无论你是刚接触 GPU 开发的新手还是在做模型训练/推理落地的工程师都能从里面找到有用的内容。1. 事件背景订单翻倍背后的 AI 算力逻辑1.1 从“卖算力”到“囤算力”的云厂商AWS 这次大幅追加英伟达芯片订单本质上是云厂商对 AI 算力需求的一次“提前下注”。过去云厂商采购 GPU 是为了给企业提供按需租用的计算资源逻辑更像“基础设施采购”。但当大模型训练和推理成为常态GPU 已经变成决定业务上线速度的稀缺资源。谁手里有更多高端芯片谁就能承接更大规模的训练任务也就能更快交付生成式 AI 服务。消息里提到AWS 向英伟达采购的订单规模提升到了原来的三倍新增部分包含大量 Blackwell 架构 GPU。熟悉 AI 算力的朋友应该能感受到这不是简单加几张卡而是一次数据中心级的扩容。增量部分往往对应着某几个大型数据中心项目的整体建设而不是零散补充。1.2 Project Rainier 与 GB200 NVL72 的关系与这条新闻强相关的背景之一是 AWS 在 re:Invent 大会上公布的 Project Rainier 数据中心项目。这个项目计划使用英伟达 Grace Blackwell Ultra 芯片也就是 GB200 NVL72 这类整机柜方案。GB200 NVL72 并不是一块普通显卡而是一个包含 72 颗 Blackwell GPU 和 36 颗 Grace CPU 的整机柜系统内部通过 NVLink 高速互联。这个架构和传统服务器插几张 A100/H100 差别很大。它把 GPU、CPU、内存、NVLink 交换、液冷散热整合在一个机柜里可以用更少的数据中心空间提供更强的算力但也意味着功耗、散热和机房改造复杂度都上了一个台阶。AWS 大量采购这类系统说明它不是在试水而是在把 AI 算力当作规模化基础设施来建设。1.3 为什么同时布局英伟达 GPU 和自研芯片另外还有一个不能忽略的线索AWS 自研的 Trainium2 芯片同样在大规模扩产。官方曾在 2024 年表示计划到 2025 年底前采购约 130 万颗 Trainium2 芯片。这次又追加英伟达 Blackwell GPU两种路线并行推进并不矛盾。自研芯片的优势在于成本可控、能针对自家云平台做深度优化英伟达 GPU 的优势在于生态成熟、PyTorch/DeepSpeed/vLLM 等框架支持最完善。对 AWS 来说对客户提供完整选择很重要用英伟达 GPU 服务“开箱即用”的客户用 Trainium 服务追求成本的客户。两条腿走路才是更稳妥的算力策略。2. 从 CPU 到 GPU、TPU、NPUAI 芯片核心概念扫盲2.1 CPU 和 GPU 的分工到底差在哪很多新手容易混淆 CPU 和 GPU 的用途。CPU 的核心数通常只有几个到几十个但每个核心的运算能力很强擅长处理复杂分支逻辑、操作系统调度、数据库事务这类任务。GPU 则相反它拥有几千个甚至上万个精简计算核心非常适合做大规模并行计算。举个直观的例子如果让 CPU 给 1000 张图片做滤镜它是一次一次排队处理如果让 GPU 来做它可以同时分给几千个核心处理虽然单个核心处理速度不一定比 CPU 快但整体吞吐量高得多。矩阵乘法、卷积操作这种深度学习里的基础运算天然适合 GPU 的并行架构。2.2 为什么 AI 训练离不开 GPU大模型训练本质上是在海量参数上反复做矩阵乘法和梯度更新。比如一个 70B 参数的模型权重矩阵动辄几万乘几万一次前向传播就需要亿万次浮点运算。CPU 不是不能算而是算得太慢慢到一次训练迭代可能需要几周甚至几个月。GPU 引入后训练时间被压缩到原来的几十分之一甚至更少。再加上英伟达的 CUDA 生态已经让 PyTorch、TensorFlow、JAX 等主流框架都能通过一行代码把张量运算放到 GPU 上执行开发者不需要重写整个网络结构。这也是为什么谈到 AI 算力大家首先想到 GPU。2.3 TPU、NPU 与 GPU 的定位差异除了 GPU还有谷歌提出的 TPU以及各种手机/边缘设备中的 NPU。TPU 是谷歌为深度学习定制的专用芯片它在矩阵运算上效率很高但灵活性不如 GPU生态也相对封闭。NPU 更多出现在手机 SoC 或边缘设备里专门加速神经网络推理功耗极低但难以承担大规模训练任务。英伟达 GPU 的优势在于通用性既能做训练也能做推理还能跑 CUDA 生态里丰富的加速库比如 cuBLAS、cuDNN、TensorRT、NCCL。AWS 这次加单的核心考量之一就是英伟达 GPU 可以同时满足训练和推理场景而这种灵活性和生态成熟度恰恰是自研芯片短期内很难完全取代的。3. AWS GPU 实例选型从开发者到企业该怎么选3.1 AWS 主流 GPU 实例类型AWS 的 GPU 实例主要分为几大系列分别面向不同场景。简单来说P 系列主打高性能计算和训练例如 p4d、p5 系列搭载 A100、H100 等旗舰 GPU。G 系列主打图形处理和推理例如 g5、g6 系列通常搭配 A10G、L4 等 GPU。Trn 系列搭载 AWS 自研 Trainium 芯片专为训练场景优化价格相对更低。Inf 系列搭载自研 Inferentia 芯片专为推理场景优化。DL 系列面向深度学习负载的专用实例部分基于 GPU部分基于自研芯片。对大多数开发者来说初期做模型测试和推理验证G 系列性价比更高做大规模训练优先看 P 系列如果只是跑稳定推理服务可以研究 Trn/Inf 自研芯片实例。3.2 实例规格与显存的关系选 GPU 实例时最核心的参数不是“显卡数量”而是单卡显存总量和显存带宽。比如一个 70B 参数的模型即使使用 FP16 精度仅模型权重就需要约 140GB 显存。单张 80GB 显存的 H100 根本放不下必须用多卡并行或把部分层放到 CPU/内存。AWS 实例通常在规格上直接标出 GPU 数量和类型例如p5.48xlarge对应 8 张 H100每张 80GB 显存。你可以根据模型参数量、批次大小、量化方式先估算需要的总显存再反推实例规格。如果拿不准可以先开一个小规格实例做基准测试。3.3 云上 GPU 和本地 GPU 的差异本地 GPU 的优势是数据不需要上传、延迟低、一次性硬件投入后边际成本低。但本地集群也有明显短板扩容周期长从采购到上架可能要几周甚至几个月遇到高峰期算力不够也只能排队等还要自己维护驱动、机房散热和电力。云上 GPU 的价值在于弹性。你可以用几分钟创建一台带 8 卡 GPU 的实例训练完直接释放也可以使用 Spot 实例以很低价格拿到闲置算力。AWS 这次加单后短时间内高端 GPU 实例的供应可能会更充足这对中小团队来说是个好消息。但要注意云上 GPU 不是“开了就能用”驱动、CUDA、容器环境仍然需要自己配置。4. 在 AWS GPU 实例上搭建可用的 AI 开发环境4.1 从创建实例到连接服务器创建 AWS GPU 实例建议使用官方深度学习 AMIAmazon Machine Image它预装了很多常用工具和驱动可以节省不少时间。如果你是第一次操作最好选择带 NVIDIA 驱动的 Deep Learning AMI比如Deep Learning AMI (Ubuntu 22.04)。创建完成后通过 SSH 登录。登录后先确认 GPU 是否被系统正确识别nvidia-smi如果看到类似下面的输出说明驱动已就绪--------------------------------------------------------------------------------------- | NVIDIA-SMI 535.104.05 Driver Version: 535.104.05 CUDA Version: 12.2 | |------------------------------------------------------------------------------------- | GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. | | 0 NVIDIA H100 80GB HBM3 On | 00000000:00:1E.0 Off | 0 | | 1 NVIDIA H100 80GB HBM3 On | 00000000:00:20.0 Off | 0 | -------------------------------------------------------------------------------------4.2 安装 CUDA 与 cuDNN如果使用的是官方 AMICUDA 通常已经安装。但如果你需要切换 CUDA 版本建议不要直接覆盖系统目录而是通过 Conda 或 NVIDIA 官方 runfile 安装到自定义路径。比如安装 CUDA 12.1 到/usr/local/cuda-12.1然后设置环境变量export PATH/usr/local/cuda-12.1/bin:$PATH export LD_LIBRARY_PATH/usr/local/cuda-12.1/lib64:$LD_LIBRARY_PATHcuDNN 一般配合深度学习框架使用可以通过 apt 安装也可以从 NVIDIA 官网下载后解压到 CUDA 目录。安装时要注意 cuDNN 版本与 CUDA 版本匹配否则运行时会报库冲突。4.3 用 PyTorch 验证 GPU 可用性环境配置完成后推荐先用一个简单脚本验证 GPU 是否真正可用。创建一个check_gpu.pyimport torch print(PyTorch 版本:, torch.__version__) print(CUDA 是否可用:, torch.cuda.is_available()) print(GPU 数量:, torch.cuda.device_count()) if torch.cuda.is_available(): for i in range(torch.cuda.device_count()): print(fGPU {i}: {torch.cuda.get_device_name(i)})运行python check_gpu.py预期输出示例PyTorch 版本: 2.4.0cu121 CUDA 是否可用: True GPU 数量: 8 GPU 0: NVIDIA H100 80GB HBM3 GPU 1: NVIDIA H100 80GB HBM3如果torch.cuda.is_available()返回False通常说明 PyTorch 安装的版本与 CUDA 版本不匹配需要重装对应 CUDA 版本的 PyTorch。4.4 用矩阵乘法验证 GPU 计算能力下面这行代码可以直观感受到 GPU 与 CPU 的差距import torch import time n 4096 a torch.randn(n, n, devicecuda) b torch.randn(n, n, devicecuda) # 预热 _ torch.mm(a, b) torch.cuda.synchronize() start time.time() for _ in range(10): c torch.mm(a, b) torch.cuda.synchronize() print(GPU 矩阵乘法平均耗时: {:.4f} 秒.format((time.time() - start) / 10))这里关键一步是torch.cuda.synchronize()因为 GPU 运算是异步提交的如果没有这行代码计时可能在 GPU 还没算完时就结束了。很多新手在测试 GPU 性能时数据波动很大往往就是没做同步。5. 工程实战用 Ollama 快速验证 GPU 推理能力5.1 为什么推荐 Ollama 做 GPU 验证日常开发中如果你想快速验证一台 GPU 机器能不能跑模型推理不一定非要写完整的 PyTorch 推理脚本。Ollama 是一个轻量级的大模型部署工具安装简单命令少还能自动利用 GPU 加速。对于刚拿到实例、想快速确认 GPU 状态的开发者来说它非常方便。Ollama 支持 CPU 和 GPU 两种运行模式。默认情况下如果检测到可用的 NVIDIA GPU它会优先使用 GPU 进行推理如果 GPU 不可用则退回 CPU。这种“自动降级”机制对新手友好但也带来一个问题你可能以为模型跑在 GPU 上实际上它悄悄跑在 CPU 上。5.2 安装并运行 Ollama在 Linux 实例上安装 Ollama只需执行curl -fsSL https://ollama.com/install.sh | sh启动服务systemctl start ollama拉取一个小模型并运行ollama pull llama3.2:1b ollama run llama3.2:1b 你好请用一句话介绍 GPU5.3 如何确认模型真的跑在 GPU 上这是 Ollama 最常见的一个坑。模型确实能输出结果但你无法确定它用没用 GPU。这时需要同时观察 CPU 占用率和nvidia-smi。先打开一个终端持续查看 GPU 状态watch -n 1 nvidia-smi再在另一个终端运行模型推理。如果nvidia-smi里的进程列表能看到ollama进程并且显存占用明显上升说明模型确实跑在 GPU 上。如果 GPU 显存没有变化CPU 占用率却很高说明 Ollama 走了 CPU 模式。如果你想强制 Ollama 使用 GPU可以在环境变量中指定 GPU 设备编号。例如只使用编号为 0 的 GPUexport CUDA_VISIBLE_DEVICES0这行命令对所有 CUDA 程序都有效如果你有多张卡可以通过它控制 PyTorch、Ollama 或自定义 CUDA 程序使用的 GPU 编号。6. 高频 GPU 故障排查驱动、NVML、WSL 与容器6.1 nvidia-smi 报错 failed to initialize NVML这个报错在 GPU 开发中非常常见尤其是在 WSL、虚拟机或驱动升级后。Failed to initialize NVML: GPU access blocked by the operating system出现这个问题的可能原因主要有三种一是 NVIDIA 驱动没有正确安装二是当前环境处于虚拟机/容器中GPU 没有直通三是驱动与内核版本不匹配。排查流程建议按顺序执行# 1. 检查内核模块是否加载 lsmod | grep nvidia # 2. 查看已安装的驱动版本 dpkg -l | grep nvidia # 3. 查看当前内核版本 uname -r如果是物理机但lsmod里没有 nvidia 模块重新安装驱动即可。如果是 WSL需要先在 Windows 宿主机安装 NVIDIA Windows 驱动WSL 内部不需要再安装 Linux 驱动。如果在 VMware Workstation Pro 虚拟机里遇到类似报错需要给虚拟机开启“GPU 直通”或安装 VMware 的 3D 加速驱动。6.2 Ubuntu 下安装 NVIDIA 驱动后花屏或无法进入桌面这个问题多见于笔记本或双显卡环境。安装驱动后花屏通常是因为默认使用的显卡没有切换到 NVIDIA或者驱动版本与当前内核不兼容。推荐做法是使用 Ubuntu 官方驱动仓库而不是手动从官网下载 runfile 安装sudo ubuntu-drivers devices sudo apt install nvidia-driver-535 sudo reboot如果已经花屏可以进入 recovery mode先卸载当前驱动再用官方仓库方式重新安装。6.3 容器内无法使用 GPU用 Docker 运行 GPU 容器时如果nvidia-smi报错大概率是因为缺少 NVIDIA Container Toolkit。在宿主机上执行distribution$(. /etc/os-release;echo $ID$VERSION_ID) curl -s -L https://nvidia.github.io/libnvidia-container/gpgkey | sudo apt-key add - curl -s -L https://nvidia.github.io/libnvidia-container/$distribution/nvidia-container-toolkit.list | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list sudo apt-get update sudo apt-get install -y nvidia-container-toolkit sudo nvidia-ctk runtime configure --runtimedocker sudo systemctl restart docker之后运行容器时加--gpus alldocker run --rm --gpus all nvidia/cuda:12.2.0-base-ubuntu22.04 nvidia-smi6.4 常见 GPU 问题排查清单问题现象常见原因解决思路nvidia-smi 找不到命令驱动未安装安装 NVIDIA 驱动Failed to initialize NVML驱动模块未加载或环境受限检查 lsmod、虚拟机直通PyTorch 报 CUDA 不可用PyTorch 版本与 CUDA 不匹配重新安装对应 cu 版本的 PyTorch显存不足 OOM模型太大或批次太大降低 batch size、开启梯度检查点、使用量化推理时 CPU 占用高 GPU 闲置程序未指定 GPU 设备设置 CUDA_VISIBLE_DEVICES7. 数据中心级 GPU 部署从单卡到大规模集群7.1 多卡并行的基本策略AWS 加单的一个关键背景是训练超大模型必须使用多卡并行。目前主流的多卡并行策略有 Data Parallelism、Tensor Parallelism 和 Pipeline Parallelism 三种。数据并行最简单每张卡保存完整模型副本分别处理不同批次数据最后同步梯度。张量并行把一个层的矩阵运算切分到多张卡上适合超大模型单层放不下的场景。流水线并行则把模型按层切分成多个阶段每张卡负责其中一段。实际项目中往往不是只用一种策略。DeepSpeed 的 ZeRO 阶段、Megatron-LM 的张量并行、以及 FSDP 的混合分片策略都会组合多种并行方式。开发者初期不用把所有策略都实现一遍理解“单卡放不下就多卡分担通信瓶颈要避免”这个核心思路就够。7.2 Kubernetes GPU Operator 与资源调度当 GPU 数量达到几十上百张时手动给每个任务分配 GPU 已经不可行需要引入 Kubernetes 进行统一调度。这里重点提一下 NVIDIA GPU Operator。GPU Operator 可以在 Kubernetes 集群中自动完成驱动安装、容器运行时配置、监控指标采集等工作让 GPU 对 Kubernetes 节点表现为可调度的资源。部署后你可以像申请普通内存一样申请 GPUresources: limits: nvidia.com/gpu: 1有了 GPU Operator集群节点扩容时不需要手动装驱动极大的降低了运维成本。这也是数据中心大规模部署 GPU 时的标准方案。7.3 机柜级液冷与功耗设计GB200 NVL72 这类机柜级方案让硬件密度大幅提升但散热压力也成倍增加。单机柜功耗可能超过 100kW传统风冷根本无法解决。所以 AWS 在部署大量 Blackwell GPU 时必然需要配套液冷基础设施。对于普通开发者或中小企业如果你的机房也想部署高端 GPU 服务器建议提前评估三点单机柜供电是否足够、液冷还是风冷、楼板承重是否满足设备重量。很多团队忽略散热问题结果买回来的 GPU 服务器因为温度过高只能降频运行实际算力远低于标称值。8. 成本优化与工程最佳实践8.1 不要盲目追求“卡越多越好”很多团队一开始就想着申请 8 卡甚至更多 GPU但实际任务根本吃不满。运行一个小模型或推理服务时单张消费级 GPU 或一张 A10G 就够。先跑通再评估瓶颈比一开始就追求大规格实例更省钱。如果训练时发现 GPU 利用率不足 50%先检查是不是数据加载太慢、CPU 预处理成为瓶颈。增加 DataLoader 的num_workers、开启pin_memory往往比加卡更有效。8.2 训练和推理使用不同的资源策略训练任务通常是短时高峰适合用按需实例或 Spot 实例推理任务需要稳定在线适合用长期运行的标准实例。AWS 的 Spot 实例价格通常是按需实例的 10% 到 30%但实例可能被回收不适合无状态推理服务。反过来训练任务通常可以断点续训用 Spot 实例降低成本很合适。8.3 建立 GPU 监控与自动化告警GPU 资源不是“用起来就行”需要持续监控。推荐收集以下指标GPU 利用率、显存使用量、GPU 温度、功耗、NVLink 通信带宽、PCIe 带宽。当 GPU 利用率长期偏低时应该分析代码是否存在等待、同步瓶颈当显存接近峰值时应该提前规划降级或扩容。在 Kubernetes 环境中结合 Prometheus 和 DCGM Exporter 可以很方便地采集这些指标。在 AWS 云环境中也可以使用 CloudWatch Agent 或自定义脚本上报指标。8.4 给开发者的安全与操作建议在 GPU 服务器上进行任何操作前建议遵循最小权限原则。不要直接以 root 身份长期运行开发服务安装驱动时尽量通过官方渠道对生产推理服务建议使用非 root 用户运行并限制网络访问。涉及 GPU 直通、驱动升级这类高危操作时先在测试机验证再上生产环境。此外对于 CUDA 开发或者训练任务建议为每个项目建立独立的 Python 虚拟环境或容器镜像避免出现“上次项目改的依赖把当前环境弄坏”的情况。9. 总结AI 算力扩张对开发者的实际影响AWS 大幅加单英伟达 GPU不只是云计算厂商之间的竞争也在悄悄改变开发者可获得的算力水平。短期内云上高端 GPU 实例的供给会更加充足排队等待的时间可能缩短算力价格也有望因为供给增加而更加合理。对于中小团队和个人开发者来说这是一个值得关注的信号大规模算力不再是少数巨头的特权以更低的门槛做模型训练、微调和推理部署正在变成现实。从技术角度看理解 GPU 的工作方式、掌握驱动和 CUDA 环境的搭建、学会用nvidia-smi定位问题、了解多卡训练和容器调度的基本思路这些能力比追逐最新芯片型号更重要。因为无论 AWS 采购的是 A100、H100 还是 GB200底层开发模式没有本质变化仍然是“配置环境—编写代码—监控资源—优化成本”这条闭环链路。如果你正准备开始 GPU 开发建议不要等所谓“完美环境”。直接在云上开通一台 GPU 实例从nvidia-smi开始跑通一个 PyTorch 脚本再用 Ollama 部署一个小模型逐步积累经验。等遇到具体问题再回来翻这篇文章的排查清单会比从头啃文档高效得多。