企业官网建设流程全解析

这次算力扩容动作有点大。AWS 在官方公告里把 2027 到 2028 年的 GPU 扩张计划直接拉到了“额外部署 200 万块 NVIDIA GPU”这个级别。对做 AI 应用、模型推理、批量训练的团队来说，这不能当普通新闻看，它直接影响后面几年云上 GPU 的供给节奏、实例选择和部署方式。

这篇文章不从投资视角去解读，而是站在技术部署的角度，拆四件事：公告本身释放了什么信号；云上 GPU 和本地 GPU 怎么选；在 AWS 上跑模型的常见部署路径是什么；以及未来 GPU 供给变大之后，工程上要注意哪些坑。

1. 公告核心信息速览

先把已知信息整理成表，方便后面分析。

这里要强调一句：公告里“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 "Name=instance-type,Values=g4dn.*,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-1

4.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 EC2

EKS 的方案类似，但需要配置 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 imageTag=latest \ --region us-east-1

如果这个命令返回了 image 信息，说明 IAM 用户至少具备 ECR 读权限；如果报AccessDeniedException，就要检查 IAM 策略。任务侧则需要重点看 execution role，而不是用户侧权限。

5. GPU 实例环境检查与资源占用观察

GPU 部署跑起来之后，不要只盯着模型输出，资源和性能观察同样关键。

5.1 GPU 可见性检查

进入容器后，先确认容器内能不能看到 GPU：

docker run --rm --gpus all nvidia/cuda:12.4.0-base-ubuntu22.04 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/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 docker

5.2 显存占用观察

在宿主机或容器内运行：

nvidia-smi

重点看两个指标：Memory-Usage和GPU-Util。推理服务空闲时，显存占用可能并不低，因为模型权重已经加载进显存；GPU-Util反而在空闲时接近 0。

更细致一点的观察可以在容器里安装nvtop：

apt-get install -y nvtop nvtop

5.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. 常见问题与排查方法

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 应用的人可以更早把架构往云上迁。