基础设施选型：GPU服务器选型（NVIDIA A100/H100）、存储方案（对象存储、NAS）、网络架构（RDMA）
好，咱们进入第二章。这一章聊的是基础设施选型，说白了就是「买什么硬件、搭什么网络、存什么数据」。很多团队在AIGC项目上栽跟头，不是因为算法不行，而是基础设施没选对。我见过不少案例，GPU买回来发现网络带宽不够，训练时卡在数据传输上，GPU利用率不到30%。嗯，这钱花得冤枉。
GPU服务器选型：A100 vs H100
先聊GPU。目前企业级AIGC平台的主流选择就两个：NVIDIA A100和H100。怎么选？我个人的习惯是看三个维度：算力需求、显存容量、互联带宽。
| 对比项 | A100 (80GB) | H100 (80GB) |
|---|---|---|
| FP16算力 | 312 TFLOPS | 989 TFLOPS |
| 显存带宽 | 2 TB/s | 3.35 TB/s |
| NVLink带宽 | 600 GB/s | 900 GB/s |
| 典型功耗 | 400W | 700W |
| 适用场景 | 大模型推理、中等规模训练 | 千亿参数模型训练、MoE架构 |
为什么H100的FP16算力是A100的三倍？因为它引入了Transformer Engine和FP8精度支持。说白了，H100就是为Transformer架构量身定做的。我在项目中遇到过，用A100训练一个175B参数的模型，需要64卡并行，通信开销巨大。换成H100后，同样的模型只需要32卡，训练时间缩短了40%。
核心建议：
- 预算充足且模型规模在100B以上 → 直接上H100
- 模型规模在10B-100B之间 → A100性价比更高
- 推理场景为主 → A100完全够用，H100有点浪费
个人经验：别只看单卡性能。我建议你重点关注「集群扩展效率」。A100在8卡节点内表现不错，但跨节点通信时，H100的NVLink 4.0优势就体现出来了。如果你计划部署超过32卡，H100的投入是值得的。
存储方案：对象存储 vs NAS
存储这块，很多团队容易踩坑。AIGC场景下，数据量动不动就是PB级，而且读写模式很特殊：训练时是大量小文件随机读取，推理时是模型权重顺序加载。
我一般把存储分为两层：
- 热数据层：训练数据集、模型checkpoint，需要高吞吐、低延迟
- 冷数据层：历史数据、备份模型，容量大、访问频率低
对象存储（如MinIO、Ceph RGW）
对象存储适合冷数据层。它的优势是容量大、成本低、扩展性好。但有个坑：对象存储的延迟通常在10ms级别，不适合频繁读写。
我曾经遇到一个团队，把训练数据直接放在对象存储上，结果每次epoch加载数据要等半小时。后来改成NAS做缓存层，对象存储只做归档，问题就解决了。
避坑指南：对象存储的S3协议虽然通用，但元数据操作性能很差。如果你有大量小文件（比如图片数据集），建议先用tar打包成大文件再上传。我曾经因为没注意这个细节，上传100万张图片花了整整两天。
NAS（如NFS、Lustre）
NAS适合热数据层。它的延迟在微秒级别，支持POSIX语义，训练框架可以直接读写。但NAS的扩展性有限，单节点带宽容易成为瓶颈。
我个人的习惯是：
- 单机训练 → 本地SSD + NFS挂载
- 多机训练 → 并行文件系统（如Lustre、GPFS）
- 推理服务 → 本地NVMe + 对象存储做冷备
存储选型速查表：
| 场景 | 推荐方案 | 原因 |
|---|---|---|
| 训练数据加载 | NAS（Lustre） | 高吞吐、低延迟 |
| 模型checkpoint | 本地SSD + 异步同步到对象存储 | 避免训练中断 |
| 推理模型存储 | 对象存储 | 容量大、成本低 |
| 日志和监控数据 | 对象存储 | 写入频繁、无需高IOPS |
网络架构：RDMA与InfiniBand
网络这块，是AIGC基础设施里最容易被忽视的环节。你想想看，训练一个千亿参数模型，数据需要在几百张GPU之间来回传输。如果网络带宽不够，GPU就得干等着。
RDMA（Remote Direct Memory Access）就是解决这个问题的。它允许数据直接从一台机器的内存传输到另一台机器的内存，绕过CPU和操作系统。延迟从毫秒级降到微秒级。
三种主流方案
- InfiniBand：性能最强，延迟最低（1-2μs），但价格贵。适合HPC场景。
- RoCEv2：基于以太网的RDMA，成本低，兼容性好。延迟在5-10μs。
- NVLink：NVIDIA私有协议，只用于同一节点内的GPU互联。
我建议的架构是：
- 节点内：NVLink + NVSwitch，8卡全互联
- 节点间：InfiniBand（预算充足）或 RoCEv2（预算有限）
避坑指南：RoCEv2虽然便宜，但需要PFC（优先级流控制）和ECN（显式拥塞通知）配合。我曾经在一个项目里，因为交换机没开启PFC，导致RoCEv2丢包率高达5%，训练速度直接腰斩。如果你选RoCEv2，一定要确认网络设备支持无损以太网。
网络拓扑设计
常见的拓扑有两种：
- Fat-Tree：带宽均匀，扩展性好。适合大规模集群。
- Dragonfly：延迟更低，但布线复杂。适合超算场景。
我个人更推荐Fat-Tree。原因很简单：它好排查问题。我在项目中遇到过Dragonfly拓扑，某个链路故障时，排查起来非常痛苦。Fat-Tree的对称结构让故障定位容易得多。
网络带宽计算：
假设你有64张H100，每张卡的NVLink带宽是900GB/s。如果采用All-Reduce通信模式，理论上需要：
总通信量 = 模型参数大小 × 2（梯度+参数）
以175B模型为例，FP16精度：
总通信量 = 175GB × 2 = 350GB
单次All-Reduce时间 = 350GB / (64 × 900GB/s) ≈ 6ms但实际中，由于网络拓扑和通信库开销，这个时间会放大到20-30ms。嗯，这就是为什么网络优化如此重要。
总结一下
基础设施选型没有银弹。我见过用A100+RoCEv2跑出不错效果的团队，也见过H100+InfiniBand但利用率不到50%的案例。关键还是看你的业务场景和预算。
最后给个建议：别在基础设施上省钱，但也别盲目堆料。先做小规模验证，再逐步扩展。我见过太多团队一上来就买几百张H100，结果网络和存储跟不上，GPU利用率不到30%。这钱花得真不值。
下一章，咱们聊聊容器化部署和Kubernetes集群搭建。到时候我会分享一些我在生产环境中踩过的坑，保证实用。