当前位置：首页 > news >正文

OpenAI 如何将 Kubernetes 扩展到了 7500 个节点

news 2025/6/23 16:32:08

OpenAI 团队分享的关于他们如何将 Kubernetes (K8s) 集群规模扩展到 7500 个节点的经验和技术细节。核心目标是支撑像 GPT-3、DALL·E 这样的大型 AI 模型的训练和研究。

为什么需要这么大集群？OpenAI 的工作负载特点是什么？

训练巨型模型： 需要成百上千台机器同时协作，处理海量数据（文本、图像）。
“整台机器”干活： 每个训练任务（Pod）通常独占一台服务器上的所有资源（尤其是昂贵的 GPU），避免资源争抢。
“抱团”工作（MPI）： 所有参与训练的机器像一个紧密团队（MPI 通信器）。任何一台机器出问题，整个训练就得暂停重启（从上一个“存档点”恢复）。
数据靠“云盘”： 训练数据主要从类似网盘的“对象存储”（如 S3）读写，而不是依赖 K8s 的本地持久卷（太慢）。
研究性质： 实验变化快，代码迭代频繁，基础架构要足够灵活应对变化。

扩展过程中遇到的关键挑战和解决方案

网络：让机器之间高速互通

问题： 节点太多，早期用的网络方案（Flannel）扛不住流量。
解决： 改用云厂商（Azure）提供的原生高速网络方案（避免封装/隧道）。Pod 直接获得主机级别的网速。
监控流量： 用 iptables 打标记区分内网流量和访问外网流量，方便排查瓶颈（比如是下载数据慢了还是机器间通信慢了）。
安全隔离： 不同集群网络完全隔离，防止互相影响。

大脑（API 服务器 & etcd）：别被压垮

问题： 集群大了，API 服务器（K8s 的“指挥中心”）和存储它的数据的 etcd 压力剧增。
解决：
- 运行多个 API 服务器和 etcd 实例（比如 5 个），分摊压力。
- 分离事件存储： 把频繁变化的“事件”单独存到另一个 etcd 集群，减轻主 etcd 负担。
- 升级到 EndpointSlices：解决大量节点监控“服务”时的信息爆炸问题（性能提升巨大）。
- 避免集中请求： 提醒应用开发者（研究人员）不要搞那种需要每个节点都频繁问 API 服务器的程序。
- 平滑扩容： 新节点加入不要太猛太快，防止瞬间压垮 API。

监控（Prometheus & Grafana）：看得清才能管得好

问题： 节点和指标太多，监控工具 Prometheus 吃不消（内存爆炸、启动超慢）。
解决：
- 精简指标： 不是所有指标都有用，只收集关键的。
- 修复 Bug： 发现 Grafana 某些查询会让 Prometheus 崩溃，打了补丁强制超时。
- 优化启动速度： 限制 Prometheus 重启时使用的 CPU 核心数，避免争抢。
- 寻求新方案： 承认 Prometheus 内置存储引擎在超大规模下有局限，正在探索替代品（留了个悬念）。

健康检查：快速发现“病”机器

被动检查（实时监控）：
- 监控基础：网络通不通？磁盘满了没？GPU 有没有报错（特别是严重的 ECC 错误）？
- 用工具（如 dcgm-exporter）把 GPU 状态喂给监控系统。
- 发现问题的节点会被标记（“污点”），不让新任务调度上去。严重问题会尝试驱逐现有任务。
主动检查（“体检”）：
- “预检”系统： 新节点加入前，先独占 GPU 跑测试（确保硬件驱动没问题），通过后才开放使用。
- 定期“体检”： 运行定时任务抽查节点上的 GPU 性能，确保长期健康。

资源分配：公平又高效

“团队专属区” (Team Taints)：
- 有个服务根据配置，给节点打上不同团队的标签和“污点”。
- 你的任务只有带对应“通行证”（容忍度）才能调度到你团队的“专属区”。
- 灵活点：也可以设置允许借用别人空闲资源。
“占位气球” (Balloons)：
- 问题：集群自动缩容（为了省钱）有时太快，重新启动节点又慢。
- 解决：部署一堆低优先级、随时可牺牲的“占位”任务（Balloons）。
- 效果：让自动缩放器觉得节点不空闲（所以不移除），但当真实任务来时，这些“占位”任务会被立刻踢走腾地方。
“团购”调度 (Gang Scheduling/Coscheduling)：
- 问题：一个训练任务需要 100 台机器同时就位才能开始。默认 K8s 调度器可能只给每个任务分 50 台，结果都卡住。
- 解决：利用 K8s 1.18+ 的新功能（Coscheduling 插件），确保一个任务所需的所有机器要么都分配，要么都不分配，避免死锁。

还没完全搞定的难题

监控存储引擎： Prometheus 自带的存储在大规模下压缩慢、重启慢、查询容易出错。正在找更好的方案。
限制“上网”带宽： 集群整体访问外网（如下载数据集）的带宽需求巨大。需要更好控制每个 Pod 的“网速”，避免个别人把出口带宽占满影响别人。

OpenAI 的核心经验

了解你的负载： OpenAI 的工作负载（大规模 ML 训练）很特殊，解法不能照搬通用集群。
网络是命脉： 大规模下必须用高性能网络方案。
保护“大脑”： API Server 和 etcd 是瓶颈点，要重点防护和优化（多实例、拆分、EndpointSlices）。
监控要精简高效： 海量指标下必须做取舍和优化。
自动化健康管理： 快速发现并隔离问题节点至关重要。
公平且高效调度： 结合“专属区”、“占位符”、“团购”等策略管理多团队资源。
拥抱 K8s 新特性： 如 EndpointSlices, Coscheduling 插件是解决规模问题的关键。
持续优化： 7500 节点不是终点，监控存储和带宽整形仍是挑战。

OpenAI 证明了 Kubernetes 能扩展到支撑世界最大 AI 模型训练所需的上千台机器集群。但这需要深刻理解自身需求，精心选择和配置网络、存储、监控、调度等核心组件，并不断解决规模带来的新挑战。他们的经验为其他需要超大 K8s 集群的团队提供了宝贵参考。

DPU（ Data Processing Unit，数据处理单元 ）是一种专门设计用于 卸载、加速和隔离数据中心基础设施任务 的专用处理器。它的核心目标是 释放CPU和GPU的算力 ，让它们专注于核心业务计算（如AI训练、数据分析等），同时高效处理网络、存储、安全等底层任务。

DPU的核心作用：解决传统架构瓶颈

DPU要解决的核心问题：

GPU算力浪费
- 传统CPU需处理网络协议栈、存储驱动、虚拟化等任务，消耗25%-30%算力，导致GPU“饥饿”。
- DPU解决方案：通过硬件卸载网络协议（如TCP/IP、RDMA）、存储管理、安全加密等任务，将CPU/GPU解放出来。
大规模训练通信延迟
- 千卡集群中网络拥塞导致通信延迟飙升，拖慢万亿参数模型训练。
- DPU解决方案：提供超低延迟网络加速（如NVIDIA BlueField的SHARP技术），减少GPU间通信耗时。
安全与性能矛盾
- 传统加密卸载牺牲实时性，多租户资源争抢引发性能波动。
- DPU解决方案：硬件级隔离多租户资源，并行处理加密/解密，实现安全零性能损耗。

DPU的三大能力

网络加速
- 卸载网络协议栈，支持高速RDMA、智能路由、拥塞控制，提升分布式计算效率。
- 示例：BlueField-3 DPU可将千亿模型训练通信延迟降低13%。
存储虚拟化
- 硬件加速存储访问（如NVMe over Fabrics），卸载文件系统、数据压缩等任务。
- 示例：SNAP技术实现50GB/s加密存储读写，CPU开销降低70%。
安全与隔离
- 硬件级加密引擎（如AES-GCM），零信任安全架构，物理隔离多租户资源。
- 示例：多租户环境下保障99.9% SLA，吞吐量提升4倍。

NVIDIA DPU的实战价值（以BlueField-3为例）

NVIDIA BlueField-3 DPU 结合 DOCA软件框架，实现了：

训练效率飙升
GPU利用率跃升至92%，通信延迟降低13%。
推理实时保障
硬件隔离确保99.9% SLA，吞吐量提升4倍。
秒级运维响应
Telemetry高频采样10倍加速故障定位，系统稳定性达99.999%。
存储安全兼得
SNAP硬件加密加速50GB/s读写，CPU开销骤降70%。

DPU vs. CPU/GPU 定位差异

处理器类型	核心任务	典型场景
CPU	通用计算、逻辑控制	操作系统、应用逻辑
GPU	大规模并行计算	AI训练/推理、图形渲染
DPU	基础设施任务卸载与加速	网络、存储、安全、虚拟化