2
ASPLOS 25
系统设计，运营分析
引入
学术机构中的共享GPU集群使用效率低下
高效的资源管理需要考虑管理框架、调度策略、网络协议、拓扑设计和其他系统配置，集群可用性、稳定性和性能需要提高
简单地提供shell访问权限会产生资源竞争、环境干扰、人工管理复杂的问题；k8s部署复杂且缺乏原生访问控制和共享资源任务队列
SING将ML任务处理简化为四个系统层级——任务配置文件层、适配器层、调度层与执行层，每层均采用低维护成本的软件栈，高效处理任务调度和用户隔离等操作，同时最大限度减轻运维负担。采用有效的资源分配策略以避免资源利用率低下并提升分配公平性。
贡献
高效运维设计
用户使用模式与作业特征分析；运维经验
背景
现有解决方案
Shell直连
步骤
手动登录GPU节点
手动配置环境
手动分配资源
手动执行任务并清理
分析
简便
配环境困难，缺乏隔离与管理可能影响系统，用户间资源使用冲突，公平性难以保障
传统HPC方案
步骤（Slurm为例）
从登录节点提交作业，并指定资源需求
作业列队与调度
用户在脚本中设置运行时环境
系统在分配的节点上运行作业，之后释放资源
分析
缺乏对ML任务所需复杂依赖的环境支持
必须在登录节点进行作业提交，但登录节点易发生单点故障
粒度过粗导致利用率低下
Slurm支持MPI技术，而ML任务常用NCCL等MPI，使Slurm具有拓展潜力
容器平台
步骤（K8s为例）
用户通过编写特定格式的描述文件（Dockerfile），将程序和任务依赖封装进容器中
用户提交镜像并指定资源需求
K8s管理并调度pod到节点上
K8s创建容器并运行ML任务，完成后释放
分析
对于ML，K8s的某些功能冗余
原生缺乏用户级访问控制、作业队列，需要额外工具支持
部署与运维复杂
Dockerfile需要学习成本
集群调度器与计算框架
ML集群调度器
Sia、Pollux、Gavel等可以融合进Slurm、K8s、SING
计算框架
分布式计算框架Ray、Spark等可作为作业组成部分提交到集群管理器
动机和需求
动机
研究机构需要一个简单、稳定、高效的共享ML集群管理方案
需求
减小运维复杂度，减小管理员操作负担
提升用户易用性，交互简单
公平高效的资源分配，同时保障响应时间
设计
四层结构
任务描述层
提供自包含的描述语法，供用户定义任务和环境需求
资源组、节点数、每节点GPU数、job格式
脚本或容器入口命令
job配置，运行时库、依赖等
适配器层
用户与集群交互接口，负责任务提交与状态监控
本地命令行界面+集群服务端
服务端解析作业配置传输给调度器，提供作业监控功能
作业编译
对脚本作业，识别依赖（CUDA+Python（Conda））并注入环境，通过MD5映射避免重复Conda环境
对容器作业，调用容器运行时使用用户配置构建容器
交互式作业监控
通过端口转发使用jupyter/tensorboard远程调试
远程ssh访问主机或容器
流式传输日志文件
调度层（基于Slurm）
资源分配与任务调度，包含优化的FCFS与回填算法
从用户角度考虑公平性且非侵入的调度算法
FCFS+binpack，若头部任务资源不足，通过回填机制临时跳过该任务
设置回填阈值，限制回填任务占资源总数
资源请求包含节点数和每节点GPU数，GPU数仅提供1/2/4/8
通过SR-IOV划分8GPU节点划分为独立网络环境的1/2/4-GPU节点，为小型任务服务
使用LRU在节点本地缓存Conda环境和镜像
执行层（基于Slurm）
在节点上运行ML任务，配置网络文件系统与可定制的后端
每个节点运行Slurm代理
GlusterFS网络文件系统，用户目录（稳定）+运行时目录（速度）
资源分组，CPU、消费级GPU、数据中心GPU
略
运营与分析
系统可用性与维护
资源瓶颈
高效存储
公共数据集
文件过期策略
GPU利用率监控
邮件提醒低利用率用户
高峰期限制任务运行时间
检查点续算
故障处理
网络文件系统延迟与不一致
RDMA
NIC升级导致系统配置丢失
重装SING系统
局限
资源隔离
连接安全性
端口转发安全性
节点故障无法自动恢复，作业全部丢失
评论区