转型AI运维工程师·Day 1：一片空白的 AWS 和“嗷嗷待哺”的算法博士
心情：肾上腺素飙升，但也伴随着对巨额成本的敬畏任务：搭建高性能 AI 训练集群 (HPC Cluster)关键词：AWS P4d, EFA, Placement Group, Self-Referencing SG, Quota
今天是我加入这家创业公司的第一天。 公司决定从传统 SaaS 转型做垂直领域的行业大模型。作为唯一的资深运维（背着 AWS SAP 证书），我看着那个只跑着几个 Java 微服务的 AWS 账号，心里清楚：今天将是推倒重来的一天。
上午 10:00，首席科学家李博士推门进来，没有寒暄，直接抛出了需求：“YY，为了跑通那个 70B（700亿参数）的大模型，我需要32 张 A100。我知道这很难，但投资人在看进度，最好今天能把环境给我。”
32 张 A100。我快速在脑海里换算了一下：
硬件对应：这是 4 台 AWS 的
p4d.24xlarge实例（每台 8 卡）。成本估算：每台机器每小时 32.7 美金。4 台机器跑一天，就是3,000 多美金。
架构难点：这不是开 4 台独立的 Web 服务器，这 4 台机器必须像“连体婴儿”一样工作，显卡之间通信延迟必须极低，否则钱都在烧在等待网络传输上。
我深吸一口气：“博士，给我 8 小时。今晚让您跑上代码。”
第一步：地基规划 —— 拒绝与旧业务混用
我不打算把这些昂贵的 GPU 放在公司现有的 VPC 里。AI 训练流量巨大，且对 IP 规划有特殊要求。
创建 VPC (
vpc-ai-training-prod)：CIDR 给大一点
10.100.0.0/16。
子网规划与 AZ 选择：
我查了 AWS 文档，P4d 这种顶级实例不是每个可用区都有的。我特意选了us-east-1 (N. Virginia)的核心可用区
us-east-1a。创建了一个Private Subnet(
10.100.1.0/24)。关键架构决策：我坚决不给 GPU 机器分配公网 IP。它们通过NAT Gateway访问 Hugging Face 下载模型，通过堡垒机（Bastion Host）进行 SSH 登录。这是 SAP 架构师的安全底线。
第二步：物理层“连体” —— Placement Group
为了满足李博士“分布式训练”的需求，这 4 台机器在物理数据中心里必须挨得足够近。如果一台在楼上，一台在楼下，光缆传输的微秒级延迟就会拖累训练速度。
操作记录：
进入EC2 Console->Placement Groups。
点击Create。
Name:
pg-ai-cluster-01。Strategy:选择Cluster（集群模式）。
原理：这会强制 AWS 把随后启动的实例调度到同一个机架（Rack）或相邻机架，实现Full Bisection Bandwidth（全双分带宽）。
第三步：打通“光纤” —— EFA 与安全组的坑
这是最容易翻车的地方。为了启用EFA (Elastic Fabric Adapter)，也就是 AWS 版的 RDMA（绕过内核直接通信），安全组必须特殊配置。
操作记录：
创建 Security Group：命名为
sg-ai-cluster-communication。配置 Inbound Rules（入站规则）：
误区：新手通常只开 22 (SSH) 或 80 (HTTP)。
正解：我添加了一条特殊的规则。
Type:
All TrafficProtocol:
AllSource:
sg-ai-cluster-communication(选择这个安全组的 ID，比如sg-0abcd...)
解释：这就是Self-Referencing。EFA 通信协议底层极其复杂，必须允许该组内的机器互相信任，端口全开。如果不配这条，几万美金的网卡就会降级成普通网卡。
第四步：最艰难的卡点 —— Quota 申请
下午 2:00，地基打好，我尝试启动一台试试。报错：InstanceLimitExceeded。 果然，AWS 默认给 P4d 这种核武器级别的实例配额是0。
运维摇人环节：我没有在 Support Center 傻等。我直接拨通了 AWS 客户经理（AM）的电话：“老哥，我们公司转型 AI 了，李博士的项目，今晚必须见到机器。帮我加急批 4 台 P4d 的额度，一共 384 vCPU。” AM 也很给力，拿着我们刚签的承诺消费单去后台推流程。下午 5 点，Quota 邮件到了：Approved。
第五步：启动实例 —— 见证金钱燃烧
万事俱备，开始 Launch Instances。
配置清单：
AMI：搜索
Deep Learning AMI GPU PyTorch 2.0.1 (Ubuntu 20.04)。理由：我不想花一下午时间去解决 NVIDIA 驱动和 Linux 内核的冲突。这个 AMI 预装了 EFA 驱动、CUDA、NCCL 和 PyTorch。
Instance Type:
p4d.24xlarge(8 x A100 40GB)。Network:
VPC:
vpc-ai-training-prodSubnet:
private-subnet-1a(私有子网)Security Group: 选中
sg-ai-cluster-communication。关键操作：点击 Advanced network configuration，在 Network interface 1 处，将Interface type显式改为EFA。如果不改，系统只会把它当普通网卡用。
Advanced Details:
Placement Group:选中
pg-ai-cluster-01。
Count:
4。
点击Launch。 几秒钟后，控制台显示 4 行绿色的Running。那一刻，我仿佛听到了计费系统疯狂转动的声音。
第六步：最终验证
我通过公网 SSH 登录到堡垒机，然后再次 SSH 跳转到其中一台内网 IP 为10.100.1.10的 P4d 机器上（全程 Linux 命令行，走 Port 22）。
1. 查显卡：输入命令：nvidia-smi屏幕上弹出了那张著名的表格：8 x NVIDIA A100-SXM4-40GB。 4 台机器，总共 32 张卡，状态全部正常。
2. 查网络 (EFA)：输入命令：fi_info -p efa终端输出了一长串关于efaprovider 的底层信息。这意味着 OS Bypass 功能已激活。
下班前的邮件：
To:Dr. LiSubject:32卡 A100 集群已就绪
博士， 训练集群已交付。
规模：4 x p4d.24xlarge (共 32 x A100)
网络：EFA 已启用，机器位于同一 Placement Group，物理延迟已优化至最低。
环境：PyTorch 2.0 & CUDA 预装。
访问：请通过堡垒机 SSH 连接
10.100.1.10~13。祝训练顺利。
YY
关上电脑，我长舒一口气。Day 1 完美通关。 但我也知道，只要机器开着，问题就会来。明天李博士肯定会抱怨命令行不好用，或者监控数据看不全。
（Day 1 结束）
