NASP/argus-cluster
53
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
argus-cluster/doc/hl_design.md

13 KiB
Raw Permalink Blame History

AI Infra 训练平台建设方案

1. 愿景与目标

1.1 愿景

构建一套端到端的智能化AI训练平台，将分散的训练框架、资源调度、监控运维、数据管理能力整合为统一的标准化流水线，让大模型训练算法团队专注于模型创新而非基础设施运维，同时与现有运维智能体深度协同，实现训练任务的智能化运维闭环。

1.2 核心目标

目标维度 描述
效率提升 训练任务从准备到启动时间缩短 70%，故障恢复时间缩短 50%
标准化 建立统一的训练流程规范，消除"人人一套环境"的混乱局面
可观测性 全链路监控覆盖，训练状态、资源利用、异常事件一目了然
智能运维 与运维智能体对接，实现断训自动分析、故障智能诊断

2. 整体架构概览

┌─────────────────────────────────────────────────────────────────────┐
│                        用户交互层                                    │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐                  │
│  │  Web 前端   │  │   CLI 工具   │  │  API 接口   │                  │
│  │ (任务提交)   │  │ (高级用户)   │  │ (自动化集成) │                  │
│  └─────────────┘  └─────────────┘  └─────────────┘                  │
└─────────────────────────────────────────────────────────────────────┘
                                │
┌─────────────────────────────────────────────────────────────────────┐
│                        平台服务层                                    │
│  ┌───────────────┐  ┌───────────────┐  ┌───────────────┐            │
│  │   任务调度     │  │   数据管理     │  │   模型管理     │            │
│  │  (SkyPilot)   │  │(schema/dataset)│  │  (版本/产物)   │            │
│  └───────────────┘  └───────────────┘  └───────────────┘            │
│  ┌───────────────┐  ┌───────────────┐  ┌───────────────┐            │
│  │   镜像管理     │  │   指标追踪     │  │   日志中心     │            │
│  │(Local Registry)│ │   (W&B)       │  │  (集中采集)    │            │
│  └───────────────┘  └───────────────┘  └───────────────┘            │
└─────────────────────────────────────────────────────────────────────┘
                                │
┌─────────────────────────────────────────────────────────────────────┐
│                        智能运维层                                    │
│  ┌─────────────────────────────────────────────────────────────┐    │
│  │                    运维智能体对接                             │    │
│  │  • 断训自动分析    • 故障根因定位    • 资源利用率优化建议      │    │
│  └─────────────────────────────────────────────────────────────┘    │
└─────────────────────────────────────────────────────────────────────┘
                                │
┌─────────────────────────────────────────────────────────────────────┐
│                        基础设施层                                    │
│  ┌───────────────┐  ┌───────────────┐  ┌───────────────┐            │
│  │  Kubernetes   │  │   GPU 集群     │  │  分布式存储    │            │
│  │   (容器编排)   │  │ H20/A6000/H100│  │ (JuiceFS)     │            │
│  └───────────────┘  └───────────────┘  └───────────────┘            │
└─────────────────────────────────────────────────────────────────────┘

3. 用户故事

3.1 算法工程师视角

作为一名算法工程师，
我希望通过简单的界面配置就能提交一个多节点 RLHF 训练任务，
以便于我可以专注于模型和数据本身，而不是花大量时间在环境配置和资源协调上。

验收标准：

  • 在 Web 界面上选择数据集、模型、训练配置
  • 一键提交后，系统自动完成资源分配、镜像拉取、任务启动
  • 实时查看训练进度曲线和关键指标

作为一名算法工程师，
我希望训练中断时能快速定位问题原因，
以便于减少排查时间，尽快恢复训练。

验收标准：

  • 系统自动检测训练中断事件
  • 智能体自动分析中断原因（OOM、网络故障、硬件异常等）
  • 提供可操作的恢复建议

作为一名算法工程师，
我希望启动一个 Notebook 环境调试代码. 以便于小规模试跑训练，测试训练数据集、调整模型参数

验收标准：

  • Notebook容器启动速度
  • 开发容器内置依赖包完善度，按照新包

3.2 团队负责人视角

作为团队负责人，
我希望能够看到所有训练任务的整体资源利用情况，
以便于合理规划算力资源，识别资源浪费。

验收标准：

  • 仪表盘展示各集群 GPU 利用率趋势
  • 任务队列可视化，等待/运行/完成状态一目了然
  • 资源使用报表按项目/用户统计

3.3 运维工程师视角

作为运维工程师，
我希望训练任务的监控数据能自动接入现有运维系统，
以便于统一管理，减少割裂的监控工具。

验收标准：

  • 训练任务指标自动推送到运维智能体
  • 异常告警自动触发智能体分析流程
  • 与现有运维系统数据互通

4. 里程碑规划

里程碑总览

    M1                 M2                 M3                 M4
    │                  │                  │                  │
────●──────────────────●──────────────────●──────────────────●────────▶
    │                  │                  │                  │
 基础设施就绪        训练流水线上线      监控运维闭环        智能化运维

M1: 基础设施就绪

目标： 完成底层平台搭建，具备运行训练任务的基础能力

交付物 说明
K8S 集群 H20 集群上部署 Kubernetes，支持 GPU 调度
本地 Registry 内网镜像仓库，解决镜像拉取问题
JuiceFS/MinIO 分布式存储，数据集和模型 checkpoint 持久化
基础镜像 veRL 训练镜像，预置常用依赖

关键验证点：

  • 能够手动在 K8S 上启动单节点训练任务
  • 数据从 JuiceFS 正常读写
  • 镜像从本地 Registry 正常拉取
  • 引入 Volcano 或 Kueue，并配置 Gang Scheduling 策略，实现All-or-Nothing 的资源分配
  • 确认JuiceFS 的本地 SSD 缓存策略，在其中一台机器部署MiniIO单节点，另外两台机器上部署JuiceFS client
  • 网络通信支持 RoCE/InfiniBand
  • Notebook 交互式开发环境

M2: 训练流水线上线

目标： 用户可通过前端提交和管理训练任务

交付物 说明
SkyPilot 集成 任务调度与资源编排
W&B 本地服务 训练指标追踪与可视化
任务管理前端 数据上传、任务提交、进度查看、日志查看
数据管理模块 支持从 HuggingFace 链接或 FTP 导入数据集

关键验证点：

  • 端到端完成一次多节点 SFT 训练
  • 通过前端提交任务，查看 W&B 训练曲线
  • 训练日志完整保存并可查询
  • 多租户、项目制配额管理功能

M3: 监控运维闭环

目标： 实现任务全生命周期监控，与运维智能体初步对接

交付物 说明
资源监控 GPU 利用率、显存、网络带宽实时采集
日志采集 训练日志集中存储，支持检索
智能体对接 断训事件自动推送，触发智能体分析
告警机制 异常状态（OOM、任务卡死等）自动告警

关键验证点：

  • 训练任务异常时，5 分钟内收到告警
  • 断训事件自动生成分析报告
  • Grafana 仪表盘展示集群整体健康状态
  • sidecar方式部署 DCGM Exporter 来获取细粒度指标，自动采集到Prometheus
  • 断训时“保留现场”机制，供人工/智能体排查介入

M4: 智能化运维

目标： 深度整合运维智能体，实现智能调度与自愈

交付物 说明
故障自愈 常见故障自动处理（如重新调度到健康节点）
智能调度 基于历史数据优化任务资源分配
根因分析 复杂故障场景的深度分析能力
容量预测 基于任务趋势预测算力需求

5. 约束与风险

5.1 已知约束

约束项 影响 应对策略
内网环境 无法直接访问HF/Dockerhub/Github资源（模型、数据集） 本地 Registry + 数据导入工具
算力平台限制 现有平台调度能力有限 引入 SkyPilot 作为上层调度
数据持久化 需要可靠的分布式存储 JuiceFS + MinIO 方案

5.2 潜在风险

风险 可能性 影响 缓解措施
K8S 与现有系统集成复杂 中 高 先在 H20 集群小范围验证
智能体接口适配工作量大 中 中 早期明确接口规范，持续对齐
用户习惯迁移阻力 低 中 渐进式推广，保留手动模式

6. 资源与依赖

6.1 硬件资源

集群 配置 用途
H20 集群 2 节点 × 8 卡 = 16 卡 主力训练集群，首期部署目标
A6000 集群 2 节点 × 4 卡 = 8 卡 开发测试、小规模实验
H100 集群 多节点 目前仅提供容器方式，不确定能否提供KubeConfig接入，大规模训练

6.2 外部依赖

依赖项 状态 负责方
yd运维智能体接口 已有基础
argus运维系统 已有 运维团队

7. 成功标准

阶段一完成标准（M1 + M2）

  • 算法工程师可通过 Web 界面完成 SFT/RLHF 训练全流程
  • 任务提交到开始训练时间 < 10 分钟
  • 训练指标实时可视化，延迟 < 1 分钟
  • 至少完成 3 个实际项目的验证使用

阶段二完成标准（M3 + M4）

  • 断训事件 100% 自动检测并推送智能体
  • 常见故障（OOM、节点失联）自动生成分析报告
  • GPU 整体利用率提升 20%（通过更好的调度）
  • 平均故障恢复时间（MTTR）缩短 50%

附录：关键技术选型

领域 选型 选型理由
容器编排 Kubernetes 业界标准，生态成熟
任务调度 SkyPilot 专为 ML 场景设计，支持多集群
分布式存储 JuiceFS + MinIO 兼容 POSIX，适合训练场景
实验追踪 W&B (自部署) 功能完善，团队已有使用经验
镜像仓库 Harbor / Registry 内网环境必需
训练框架 veRL / Megatron 支持 RLHF，与现有工作对齐