GPU 部署最佳实践：万卡规模集群管理指南
更新于 2025 年 12 月 8 日
2025 年 12 月更新： 万卡 GPU 集群已成常态——超大规模云服务商正在运营超过 10 万张 GPU 的部署。液冷散热在大规模场景下已成必需，增加了部署复杂性。NVIDIA Base Command Platform 和 DGX Cloud 正在简化大规模集群管理。配合动态资源分配（DRA）的 Kubernetes 实现了 GPU 感知的编排调度。GPU 高昂的成本（每张 H100 售价 2.5-4 万美元）使得利用率优化至关重要——投资回报率的目标应达到 85% 以上。
管理 10,000 张 GPU 将基础设施运维从技术工作转变为工业制造，在这个领域，百分之一的改进就能节省数百万美元，而五分钟的宕机损失可能超过大多数公司的全年营收。¹ Meta 在其全球基础设施中运营着 60 万张 GPU，其部署自动化程度之高，新集群无需人工干预即可上线。² 这种规模打破了所有传统 IT 假设：能够处理数千台服务器的监控系统在每秒数百万指标面前崩溃，而适用于数百张 GPU 的手动流程在万卡规模下已不可能执行。
跨越万卡 GPU 门槛的组织会发现，成功需要的不仅仅是资金和硬件。特斯拉的 Dojo 集群让公司认识到，部署 10,000 张 GPU 需要三个月，但让它们高效运行需要一年。³ Google 通过惨痛经历了解到，GPU 故障遵循幂律分布——1% 的 GPU 导致 50% 的任务失败，这需要完全不同的冗余和调度方法。⁴ 每家超大规模云服务商都讲述同样的故事：万卡规模的挑战与千卡规模截然不同。
经济因素使得这些挑战对于认真做 AI 的玩家来说不可回避。训练单个大型语言模型需要 25,000 GPU 月，如果没有大规模并行，不可能在合理时间内完成。⁵ 为数百万用户提供推理服务需要数千张 GPU 持续运行。掌握大规模 GPU 部署的组织在模型开发速度、服务成本和能力扩展方面获得难以逾越的优势。而失败者则在未充分利用的硬件上浪费数亿美元，只能发挥其潜力的一小部分。
部署自动化消除人工瓶颈
手动部署流程每张 GPU 需要 30 分钟，部署 10,000 张 GPU 将需要 5,000 人时，这还是假设完美执行没有任何错误的情况。现实远比这糟糕：手动流程会引入配置漂移、文档缺失和人为错误，这些问题会累积成系统级故障。微软的 Azure 团队在计算出手动部署仅维持稳态运营就需要 200 名全职技术人员后，将整个 GPU 部署流水线实现了自动化。⁶
基础设施即代码在大规模场景下成为强制要求，而非可选的最佳实践。HashiCorp Terraform 通过 200 万行配置代码管理 Meta 的 GPU 基础设施，定义从 BIOS 设置到网络拓扑的所有内容。⁷ 每次 GPU 部署都遵循版本控制模板中编码的相同模式。变更经历与生产软件相同的代码审查流程。回滚只需几分钟而非几天。基础设施变得确定性强、可重复，而非手工艺式的独特存在。
基于镜像的部署将配置时间从数小时缩短到几分钟。NVIDIA 的 Base Command Platform 使用包含操作系统、驱动程序、库和配置的不可变镜像。⁸ 新 GPU 直接启动进入生产就绪状态，无需部署后配置。镜像更新通过蓝绿部署推出，新镜像逐步替换旧镜像。失败的部署自动回滚到之前的镜像。这种方法消除了导致部署数月后出现细微故障的配置漂移。
零接触配置将人工完全从关键路径中移除。BMC（基板管理控制器）自动化负责开机、配置 BIOS 设置、启动网络引导并开始操作系统安装，无需物理干预。⁹ Redfish API 支持从采购到退役的服务器全生命周期程序化控制。¹⁰ 亚马逊的数据中心实现了全自动部署，服务器以托盘形式到达，除了物理上架外无需人工接触即可投入生产。
验证自动化确保部署在进入生产环境前符合规格要求。NVIDIA 的 GPU Operator 运行全面的测试套件，验证计算性能、内存带宽、互联功能和热特性。¹¹ 测试在老化期间持续运行，在影响生产工作负载之前捕获早期失效故障。自动化验证消除了困扰手动部署的"在我机器上能跑"问题。
硬件生命周期管理超越部署本身
采购 10,000 张 GPU 需要 6-12 个月的交付周期和 3 亿美元的资本配置。组织必须在技术快速演进的同时准确预测需求。Meta 的容量规划模型根据模型规模预测和用户增长，提前 18 个月预测 GPU 需求。¹² 这些模型考虑了硬件更新周期、故障率和效率提升。采购团队与多家供应商签订主协议，以确保供应链韧性。
库存管理成为堪比汽车制造的物流挑战。追踪 10,000 张 GPU 需要复杂的资产管理系统，记录序列号、固件版本、物理位置、温度历史和错误率。Google 的 Borgmon 系统每 30 秒更新一次，跟踪每张 GPU 的 50 个属性。¹³ 这些数据馈入预测性维护模型，在影响生产之前识别可能失效的 GPU。备件库存计算需要在故障率和资本效率之间取得平衡。
固件管理经常被忽视，直到版本不匹配导致集群级故障。NVIDIA 每月发布 GPU 固件更新，每次更新都可能影响性能、稳定性或安全性。¹⁴ 向 10,000 张 GPU 推送固件需要分阶段部署并仔细监控。同一任务中 GPU 之间固件版本不兼容会导致神秘的故障。Anthropic 维护严格的固件版本控制，配合自动化推送系统防止版本漂移。¹⁵
更新换代周期比初始采购价格更能决定长期经济效益。GPU 通常在 3-4 年生命周期内提供最优 TCO，之后效率提升才足以证明更换的合理性。¹⁶ 然而，H100 到 B200 这样的突破性架构转换提供 3 倍性能提升，足以证明加速更新的合理性。组织必须对每美元性能进行建模，包括电力成本、维护开销和使用旧硬件的机会成本。级联策略将新 GPU 用于训练，而老一代处理推理工作负载。
退役流程对于数据安全和环境合规至关重要。GPU 在内存中保留的敏感数据会在断电后持续存在。安全擦除需要专用工具，覆盖所有内存，包括 HBM、缓存和寄存器。¹⁷ 对于高度敏感的部署，可能需要物理销毁。环境法规要求电子废物的妥善回收，GPU 板卡含有值得回收的贵金属。微软每吨退役 GPU 可回收价值 5 万美元的黄金和稀土元素。¹⁸
监控架构应对前所未有的遥测数据量
每张 GPU 每秒生成 10,000 多个指标，涵盖温度、功耗、利用率、内存带宽、错误率和性能计数器。¹⁹ 乘以 10,000 张 GPU，监控系统必须每秒摄取 1 亿个指标，每天 8.6 万亿个数据点。Nagios 或 Zabbix 等传统监控工具在这种负载下会崩溃。时序数据库成为必需，InfluxDB 或 Prometheus 在保持查询性能的同时处理摄取速率。
分层聚合在保持可见性的同时减少数据量。原始指标在机架级聚合，然后是机柜行，再然后是集群，每个层级维护统计摘要。详细指标保留数小时，小时摘要保留数天，日摘要保留数月。这种层次结构支持下钻调查，同时管理存储成本。Facebook 的 Gorilla 时序数据库通过专门编码将每个数据点从 16 字节压缩到 1.37 字节。²⁰
分布式追踪对于理解跨数千张 GPU 的任务性能至关重要。Google 的 Dapper 系统以最小开销追踪分布式系统中的请求。²¹ GPU 任务生成的追踪显示所有参与 GPU 之间的数据移动、同步点和计算阶段。这些追踪揭示了聚合指标中不可见的瓶颈。OpenTelemetry 提供了适用于不同 GPU 类型和软件栈的供应商中立追踪。
大规模异常检测需要机器学习而非静态阈值。为 1 亿个指标手动设置告警是不可能的。无监督学习算法识别正常行为模式，然后标记偏差。亚马逊的 Random Cut Forest 算法在有限内存使用下检测流数据中的异常。²² 系统学会在训练期间高温是正常的，但在空闲期间则值得关注。误报率必须保持在 0.01% 以下，以防止告警疲劳。
可视化系统必须以可理解的方式呈现 PB 级监控数据。显示 10,000 个单独 GPU 指标的 Grafana 仪表盘会变成难以阅读的图表墙。有效的可视化使用热图，每张 GPU 是一个按健康状态着色的像素。分层显示允许从集群概览下钻到单个 GPU 详情。动画显示时间模式，如热量波在机架间传播。挑战从收集数据转变为使数据可操作。
网络架构扩展超越传统极限
连接 10,000 张 GPU 需要堪比互联网服务提供商的网络基础设施。每张 GPU 需要 400Gbps 连接，总带宽达到 4 Pb/s。²³ 传统三层网络架构（接入层、汇聚层、核心层）会造成瓶颈并增加延迟。Clos 网络通过多条并行路径在任意两张 GPU 之间提供一致的带宽和延迟。该架构需要数千台交换机和数百万根光纤连接。
拓扑优化对分布式训练性能至关重要。频繁通信的 GPU 之间需要最少的网络跳数。环形拓扑最小化平均跳数但缺乏冗余。Torus 拓扑提供多条路径但增加复杂性。Dragonfly 拓扑为大规模部署平衡了连接性和成本。²⁴ Facebook 的网络结构使用针对其特定流量模式优化的自定义拓扑，将任务完成时间减少了 23%。²⁵
InfiniBand 与以太网的决策影响成本、性能和灵活性。InfiniBand 提供更低延迟和更好的拥塞控制，但成本是以太网的 2 倍。²⁶ 融合以太网 RDMA（RoCE）为以太网网络带来类似 InfiniBand 的性能，但需要仔细配置。NVIDIA 的 Spectrum-X 以太网平台声称在 AI 工作负载上具有与 InfiniBand 相当的性能。²⁷ 大多数超大规模云服务商在训练集群使用 InfiniBand，在推理场景使用以太网，以优化成本和性能。
流量工程防止破坏训练性能的拥塞。分布式训练期间的 All-reduce 操作会产生同步流量突发，使缓冲区溢出。自适应路由根据实时拥塞指标将流量分配到可用路径。
[内容已截断以便翻译]
