这次算力扩容动作有点大。AWS 在官方公告里把 2027 到 2028 年的 GPU 扩张计划直接拉到了“额外部署 200 万块 NVIDIA GPU”这个级别。对做 AI 应用、模型推理、批量训练的团队来说这不能当普通新闻看它直接影响后面几年云上 GPU 的供给节奏、实例选择和部署方式。这篇文章不从投资视角去解读而是站在技术部署的角度拆四件事公告本身释放了什么信号云上 GPU 和本地 GPU 怎么选在 AWS 上跑模型的常见部署路径是什么以及未来 GPU 供给变大之后工程上要注意哪些坑。1. 公告核心信息速览先把已知信息整理成表方便后面分析。能力项说明项目来源AWS 官方对外公告NVIDIA GPU 扩容计划时间范围2027 至 2028 年部署规模额外部署约 200 万块 NVIDIA GPU目标场景大规模 AI 训练、推理、云计算算力扩容典型使用姿势EC2 GPU 实例、容器化部署、托管训练平台、批量推理在 AWS 上部署模型的方式EC2 / ECS / EKS / SageMaker / AWS Batch是否需要本地显卡不需要资源在云端是否支持批量任务通过 AWS Batch、SageMaker Batch Transform 或自建任务队列实现是否提供 API 服务可自建部署 vLLM 或 TGI 后提供 OpenAI 兼容接口适合读者后端开发、算法工程师、AI 平台运维、模型部署技术负责人这里要强调一句公告里“200 万块”是一个总量级表述具体对应什么型号、什么实例类型官方公告和后续发布会有更细的说明。从趋势看Blackwell 以及后续架构是增量主力但型号细节以 AWS 官方实例列表为准。2. 200 万块 GPU 到底意味着什么把 200 万块 GPU 放进技术语境里看这个数字非常大。一个大型 AI 训练集群通常以“万卡”为单位。200 万块 GPU 意味着即使按单个集群几万卡来算也是几十个超大规模集群的体量。这个供给量不只是给头部大模型公司用的它会直接改变云上 GPU 的供给弹性和价格预期。一个直接的影响是过去很多团队不敢上云跑 GPU 任务因为实例难抢、配额少、价格贵。如果 2027 到 2028 年新增 200 万块 GPU 的规划落地GPU 实例的可用性会明显改善尤其是短时突发的大规模推理任务不再需要提前很久去抢配额。第二个影响是在应用层。现在很多团队已经在用 vLLM、TGI、Ollama 这类工具跑开源模型GPU 供给变多之后从“本地起一个服务测试”转向“云端大规模并行推理”会更容易。推理服务可以做得更弹性按请求量伸缩。第三个影响是在基础设施层。AWS 要做这么大规模的 GPU 部署必须同步解决电力、散热、网络互连、调度效率这些问题。对使用方来说这其实是好事网络和调度层面的改进最终会体现在任务排队时间、断点恢复和多机训练稳定性上。不过也要冷静看。公告说的是计划不代表 2027 年之前没有 GPU 可用。现在的 GPU 实例仍然是按配额管理的小团队做测试、做生产推理更多还是看实例类型、区域库存和费用模型。3. 本地部署与云上 GPU什么时候该选哪边最近社区里关于“本地部署大模型”“ComfyUI 本地部署”“Ollama 本地部署”的讨论非常多很多人会问既然本地能跑为什么还要上云本地部署有一个天然优势数据不出内网网络延迟可控模型文件放在自己的机器上调用简单。如果只是开发测试、个人学习或者数据敏感度很高本地是合理的。一台 24G 显存的显卡加上 Ollama 或 vLLM就能跑不少 7B 到 14B 的模型。但本地部署有几个硬边界。第一是扩展性单机显存上限决定了模型规模上限。第二是并发能力本地单卡跑一个高并发 API 服务吞吐量很快见顶。第三是运维成本显卡驱动、CUDA 版本、容器运行时、模型版本都要自己维护。云上 GPU 解决的是这三个问题。以 AWS 为例你可以按需启动一台带 GPU 的 EC2 实例用完释放可以用 ECS 或 EKS 跑容器化推理服务可以用 SageMaker 托管训练和部署也可以用 AWS Batch 跑批量任务。所以选型判断标准很简单单机测试、数据敏感、迭代调试优先本地部署。需要高并发推理、分布式训练、批量任务、按量付费优先云端 GPU。混合也可以本地跑开发云端跑生产。这是未来几年会越来越常见的分工模式。AWS 这 200 万块 GPU 的规划本质上是在把“云端跑生产 GPU 任务”的容量天花板抬高。4. AWS 上用容器部署 AI 模型的核心流程不管公告里是 200 万块还是 20 万块落到工程上在 AWS 上部署 AI 模型的路径是相对固定的。下面按实际项目最常用的方式走一遍。4.1 准备 GPU 实例先准备一台带 NVIDIA GPU 的 EC2 实例。实例类型可能因区域而异以控制台实际可选型号为准。# 查看实例信息 aws ec2 describe-instances \ --filters Nameinstance-type,Valuesg4dn.*,g5.*,p4d.*,p5.* \ --query Reservations[].Instances[].InstanceType \ --output text启动实例后先确认 GPU 驱动是否可用nvidia-smi如果 nvidia-smi 不可用需要在实例上装 NVIDIA 驱动和 CUDA。也可以用 Amazon Linux 2023 预装驱动的方式启动具体以当前 AMI 特性为准。4.2 用容器跑模型推理服务GPU 实例准备好之后不推荐直接在系统 Python 环境里装依赖建议用 Docker 隔离环境。构建一个模型推理镜像推到 ECR再用 ECS 或 EKS 运行。Dockerfile 示例适用于常见推理框架FROM nvidia/cuda:12.4.0-base-ubuntu22.04 RUN apt-get update apt-get install -y python3 python3-pip COPY requirements.txt /opt/app/requirements.txt RUN pip3 install --no-cache-dir -r /opt/app/requirements.txt COPY app.py /opt/app/app.py WORKDIR /opt/app EXPOSE 8000 CMD [python3, app.py]这里强调使用nvidia/cuda基础镜像因为 GPU 容器需要 CUDA 运行时环境。仅用python:3.11-slim在 GPU 容器里经常会遇到 CUDA 库缺失的问题。4.3 推送镜像到 ECR登录 ECR 并推送镜像aws ecr get-login-password --region us-east-1 \ | docker login --username AWS --password-stdin 123456789012.dkr.ecr.us-east-1.amazonaws.com docker tag my-model-image:latest 123456789012.dkr.ecr.us-east-1.amazonaws.com/my-model-repo:latest docker push 123456789012.dkr.ecr.us-east-1.amazonaws.com/my-model-repo:latest这些命令里需要把账号 ID、区域、仓库名替换成自己的。ECR 仓库需要先创建aws ecr create-repository --repository-name my-model-repo --region us-east-14.4 通过 ECS 运行 GPU 任务在 ECS 任务定义里需要声明 GPU 资源。ECS 使用resourceRequirements字段来分配 GPU{ family: gpu-inference-task, containerDefinitions: [ { name: model-inference, image: 123456789012.dkr.ecr.us-east-1.amazonaws.com/my-model-repo:latest, memory: 16384, cpu: 4096, portMappings: [ { containerPort: 8000, hostPort: 8000, protocol: tcp } ], resourceRequirements: [ { type: GPU, value: 1 } ], logConfiguration: { logDriver: awslogs, options: { awslogs-group: /ecs/gpu-inference, awslogs-region: us-east-1, awslogs-stream-prefix: ecs } } } ], requiresCompatibilities: [ EC2 ], executionRoleArn: arn:aws:iam::123456789012:role/ecsTaskExecutionRole }然后注册任务定义并运行服务aws ecs register-task-definition --cli-input-json file://task-definition.json aws ecs run-task \ --cluster my-gpu-cluster \ --task-definition gpu-inference-task \ --count 1 \ --launch-type EC2EKS 的方案类似但需要配置 nvidia-device-plugin 让 Kubernetes 能识别节点上的 GPU 资源。两者原理一致让容器拿到宿主机的 GPU 并通过 NVIDIA 容器运行时访问。4.5 ECR 权限检查ECS 拉不到镜像怎么办这是 ECS ECR 部署时最高频的问题之一任务一启动就报CannotPullContainerError或者一直卡在 PENDING。原因多半是执行角色没有 ECR 拉取权限。ECS 拉取镜像不是靠实例上默认的 Docker 权限而是靠任务定义里的executionRoleArn。这个角色至少需要有 ECR 的只读权限。检查方式如下。第一步确认当前执行角色是哪一个aws ecs describe-task-definition \ --task-definition gpu-inference-task \ --query taskDefinition.executionRoleArn \ --output text第二步给执行角色附加AmazonEC2ContainerRegistryReadOnly策略aws iam attach-role-policy \ --role-name ecsTaskExecutionRole \ --policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly这里建议使用最小权限策略而不是直接附加AdministratorAccess。如果要确认用户侧有没有拉取权限还可以用aws ecr batch-get-image \ --repository-name my-model-repo \ --image-ids imageTaglatest \ --region us-east-1如果这个命令返回了 image 信息说明 IAM 用户至少具备 ECR 读权限如果报AccessDeniedException就要检查 IAM 策略。任务侧则需要重点看 execution role而不是用户侧权限。5. GPU 实例环境检查与资源占用观察GPU 部署跑起来之后不要只盯着模型输出资源和性能观察同样关键。5.1 GPU 可见性检查进入容器后先确认容器内能不能看到 GPUdocker run --rm --gpus all nvidia/cuda:12.4.0-base-ubuntu22.04 nvidia-smi如果看不到先检查宿主机驱动再用以下命令重新安装 NVIDIA Container Toolkitdistribution$(. /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/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 sudo systemctl restart docker5.2 显存占用观察在宿主机或容器内运行nvidia-smi重点看两个指标Memory-Usage和GPU-Util。推理服务空闲时显存占用可能并不低因为模型权重已经加载进显存GPU-Util反而在空闲时接近 0。更细致一点的观察可以在容器里安装nvtopapt-get install -y nvtop nvtop5.3 性能与批次大小关系GPU 推理的吞吐量不是简单的线性关系。批量请求越大单次推理的吞吐会更高但显存占用和单请求延迟也会上升。实践中的做法是先跑单请求测试确认显存占用。再逐步提高 batch size观察显存上限。最后看GPU-Util是否稳定在高位。如果显存接近满载但 GPU 利用率只有 10%说明瓶颈可能在 CPU、数据加载或网络请求处理上而不是 GPU 本身。6. 批量推理任务与 API 服务接入如果只是偶尔跑一次推理手动调用没有问题。但生产环境经常会遇到两种需求对外提供 API或者定时处理一大批文件。这两种场景分别对应 API 服务和批量任务。6.1 用 vLLM 起一个 OpenAI 兼容 API在 GPU 实例上跑 vLLM 是目前很常见的做法。安装依赖后直接启动服务pip3 install vllm python3 -m vllm.entrypoints.openai.api_server \ --model meta-llama/Llama-3.1-8B-Instruct \ --tensor-parallel-size 1 \ --host 0.0.0.0 \ --port 8000启动后用 curl 验证curl -X POST http://127.0.0.1:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: meta-llama/Llama-3.1-8B-Instruct, messages: [{role: user, content: hello}], max_tokens: 128 }返回 JSON 里如果包含choices字段说明 API 服务已经正常。这类接口可以直接接到自己的业务系统里替代外部大模型 API。6.2 用 AWS Batch 跑批量任务批量处理场景比如离线跑一批文档摘要、图片批量生成、音频批量转写适合用 AWS Batch。它可以根据任务队列容量自动申请 GPU 实例跑完自动释放。提交一个 GPU 批量任务aws batch submit-job \ --job-name my-batch-job \ --job-queue gpu-job-queue \ --job-definition gpu-batch-job:1 \ --container-overrides {resourceRequirements:[{type:GPU,value:1}],command:[python3,run_batch.py,--input,s3://my-bucket/input]}批量任务的核心是日志和失败重试。建议在run_batch.py里给每一条输入写一个独立的处理状态失败后记录到 S3 或数据库再通过--retry-strategy做有限重试。不要试图在一个进程里吃掉所有任务这样会导致任务中断后全部重来。6.3 API 服务的访问控制API 服务跑在 EC2 上时安全组要限制来源 IP不能直接对 0.0.0.0/0 开放。尤其是一个没有鉴权的推理服务。# 在 EC2 安全组中只放行办公网或 VPC 内网 IP aws ec2 authorize-security-group-ingress \ --group-id sg-xxx \ --protocol tcp \ --port 8000 \ --cidr 203.0.113.0/24更稳妥的做法是把服务放到私有子网通过 ALB 或 NLB 对外提供在应用层再加一层 API Key 鉴权。7. 大规模 GPU 调度要解决的工程问题AWS 这 200 万块 GPU 的部署计划除了供应量本身还涉及一个真实工程问题几万块 GPU 放在一个集群里怎么调度、怎么保证任务不互相干扰、怎么快速恢复故障。这和使用方是相关的。如果你在 AWS 上跑过大规模分布式训练会遇到下面这些限制区域可用区配额每个账号的 GPU 实例配额是独立的不是集群有多少你就能用多少。多租户噪音共享基础设施上相邻任务可能影响网络抖动。任务中断恢复Spot 实例成本低但可能被回收长任务要支持 checkpoint 续跑。网络带宽分布式训练对节点间带宽要求高EC2 上要选支持 EFA 或高带宽网络的实例类型。所以做大规模 GPU 任务时要提前设计好三件事第一容量规划。启动实例前先检查 Service Quotas确认目标区域的目标实例类型配额够用。aws service-quotas get-service-quota \ --service-code ec2 \ --quota-code L-3819A6DF如果配额不够提前开工单申请。第二任务可恢复性。训练任务定期保存 checkpoint推理任务把每条请求都做成幂等。第三成本控制。云上 GPU 很贵用完即释放是常识。给 GPU 实例打上Auto-Stop标签或用 Instance Scheduler 做定时关机能减少“忘关实例导致费用飙升”的尴尬。8. 常见问题与排查方法问题现象可能原因排查方式解决方案ECS 任务报CannotPullContainerError执行角色缺少 ECR 拉取权限检查 executionRoleArn 和 IAM 策略给执行角色附加AmazonEC2ContainerRegistryReadOnly容器内看不到 GPU宿主未安装 NVIDIA 驱动或缺少 nvidia-container-toolkit宿主机执行nvidia-smi安装驱动和 NVIDIA Container ToolkitAPI 服务启动后外部访问超时安全组未放行端口查看安全组入站规则只放行必要的来源 IP推理请求很慢但显存没用满输入数据预处理慢或并发设置太低观察 CPU 占用和请求日志优化数据管线提高并发数GPU 实例启动失败配额不足或区域无库存查看 AWS 控制台错误信息换区域或申请提高配额批量任务中途失败全部重跑没有做任务级断点记录查看任务日志和输出目录每条输入独立记录状态设置最大重试次数模型权重加载很慢模型文件在 S3冷启动需要下载观察启动日志时间用 EFS 或挂载缓存目录保存模型权重服务响应不稳定偶尔 504API 网关或 ALB 超时时间过短检查负载均衡日志调长超时时间或在应用层做异步处理9. 最佳实践与合规提醒结合云上 GPU 的部署特点整理几条工程建议。第一从最小配置开始。第一次跑推理服务先用单卡、小模型验证全链路再扩展到大模型和多卡。哪怕是 AWS 官方说要部署 200 万块 GPU你自己账号的配额也是慢慢涨的。第二镜像分层管理。模型文件不要打进 Docker 镜像把模型文件放到 EFS 或 S3镜像只装运行环境。这样模型更新时不需要重新构建镜像。第三日志和监控必不可少。GPU 服务必须把请求量、延迟、显存占用、GPU 利用率导到 CloudWatch这样才能知道扩容时机和成本归属。第四安全边界按最小化设置。ECR 仓库没有特殊需求就不要公开推理服务不要暴露公网API Key 放在 Secrets Manager 里不要写进镜像或环境变量。第五版权与数据合规。用 GPU 跑 TTS、图片生成、视频生成、数字人、声音克隆等能力时训练数据、参考音频、人脸素材、版权素材都要确认授权。本地处理和云上处理在合规要求上没有本质区别云上更容易留痕也更需要注意数据边界。第六批量任务要做幂等。云上资源随时可能被回收任务设计要考虑“跑了一半重启”的场景。10. 总结与下一步AWS 宣布在 2027 到 2028 年额外部署 200 万块 NVIDIA GPU这个信号对做模型部署的人有实质意义。GPU 资源的供给弹性会变大云上跑大模型推理和批量训练不再是少数大厂的专属玩法。对普通团队最值得做的是先验证自己的推理链路是否能完整地跑在 AWS 上。可以按这套流程走一遍启动一台 GPU 实例确认 nvidia-smi 正常用 Docker 把模型服务跑起来推到 ECR再通过 ECS 或 EKS 运行最后暴露一个 API 给业务系统调用。最容易踩的坑在 ECR 权限和 GPU 容器运行时这两块。前者表现为任务拉不到镜像后者表现为容器里看不到显卡。这两类问题在排查清单里已经写了建议收藏备用。后续可以继续优化三件事用 AWS Batch 把离线批量任务自动化用 vLLM 这类框架把单机推理服务化以及把模型权重缓存和实例生命周期管理做好降低 GPU 长跑成本。等 AWS 的 GPU 扩容真正落地之后云上推理的价格和可用性大概率会继续改善做 AI 应用的人可以更早把架构往云上迁。