说明：本文主要基于以下开源信息进行整理和分析，其中部分实现细节在公开版本中并未完整披露，仅限于从已有信息中进行推测和总结。

hai-platform官方文档
hai-platform GitHub仓库

0. 前言

幻方投研平台（hai-platform）作为量化行业的代表性分布式训练平台，其设计理念在于提供高效、灵活且可扩展的多用户训练环境。其中，“分时运行”是一个非常值得研究的功能点——在资源紧张时，平台会主动挂起低优先级任务，以便高优先级任务抢占资源，随后在资源充足时再恢复被挂起的任务。

在对其开源代码的阅读和测试中，我们发现某些关键实现并未完全公开，但整体原理仍可从已有信息中推断出来。本文将结合源码与文档，对“分时运行”的核心思路、实现过程和关键技术组件作进一步的探讨。

1. 分时运行

整体架构示意图如下

1.1 定义

分时运行指在资源紧张时，hai-platform会挂起(打断)正在运行的低优任务，让高优任务得以运行，被打断的任务在资源充足时可以恢复运行。这本质上是一种抢占式调度策略，其主要亮点是用户被打断后所付出的成本很低，避免长耗时训练任务在被迫中断时付出极大代价或完全重头来过。
另外hai-platform有一些动态优先级调整策略，例如文档中所提到的优先级为AboveNormal的Task运行达到30分钟后优先级会下调为Normal，遗憾的是这部分代码没有开源，但这并不妨碍我们学习理念。

1.2 任务生命周期

整体架构示意图中，scheduler、managers、taskN(podsN)是与分时运行最紧密相关的部分。
launcher(负责将manager部署到集群中)，redis(负责各模块间的消息传输)，mysql(管理集群和用户meta)有参与但作用有限，不展开分析。
在任务类型上，开源版只实现了TrainingTask一种，这是一种分布式训练任务实现，后面我们会看到manager的挂起信号只会发给TrainingTask的master节点，普通节点不参与信号处理。

2. 分时运行核心流程解析

2.1 任务创建

• 由Launcher负责创建Manager
• Manager的形式是StatefulSet，这一部分是出于网络需求，其内部包含初始化容器和主容器两部分
  • 初始化容器负责创建所有计算Pods
  • 主容器运行守护进程，业务逻辑以守护进程的插件形式运行

2.2 调度阶段

• Scheduler的Assign阶段
  • 将所有运行中的任务标记为可挂起状态。
  • 按优先级排序任务，并模拟资源分配，分配到资源的任务标记为CAN_RUN，未分配到资源的任务将进入挂起流程。
• Scheduler的Match阶段
  • 检测非CAN_RUN状态的任务，将其状态置为SUSPEND，并向redis发布挂起信号

2.3 挂起与恢复

• 挂起信号处理：
  • Manager订阅redis中的挂起信号，并通过ZMQ将挂起信号发送到TrainingTask的Master节点
  • Master节点收到挂起信号后，自行Checkpoint保存
  • Manager等待2个5秒后，执行挂起动作，即删除所有计算Pods
  • 在计算节点全部回收后，Manager进入restart_exp逻辑，fork自身创建一个新Task，成功后销毁自身
• 任务恢复
  • 新Task重新回到调度队列中，重启循环，这样当Task被再次运行起来时，由于会先加载分布式存储上的checkpoint，因此效果上相当于恢复

3. 守护进程与信号管理

Manager的主容器运行着基于supervisord的守护进程，业务相关的控制逻辑以插件形式集成在https://github.com/HFAiLab/hai-platform/tree/main/experiment_manager/manager目录下。主要包含以下功能

• 接收外部指令信号、订阅/发送redis信号、发送信号给TrainingPods
• 健康检查，异常时会发控制信号给redis
  通过这种插拔式的插件体系，hai-platform可在不改动守护进程核心框架的前提下，灵活接入新的业务逻辑或定制化功能。
  

4. 效果分析

根据上述分析，结合https://hfailab.github.io/hai-platform/guide/schedule.html中的说明，可以得知分时运行解决的是资源分配率的问题。资源按Node粒度分配，因此不存在资源碎片的问题，只要Task足够，分配率很容易达到100%。利用率则由用户自行发挥，平台提供的是：

• 分布式文件存储。读带宽为7TB/s，每Node(共1500+Node)平均读带宽为4.7GB/s，Node平均读带宽为scratch巅峰时的8-10倍
• 数据集文件格式。将小文件合并成大文件，支持随机读(有点像HayStack的设计)，解决海量小文件组成的数据集读取效率差的问题
• Dataset和Dataloader。这里是个很容易被忽略的痛点，金融数据噪声大，在训练时往往需要设置很大的BatchSize来获得更好的随机性，但BatchSize大意味着__getitem__函数被执行的次数会非常多，成为性能瓶颈。幻方的对Dataset和DataLoader的封装主要为降低读取成本
  
• 用户Quota管理。目的是让资源尽可能集中在能产生业务价值的用户手中，同时让普通用户有节约资源的概念

5. 小结

综上可以看出hai-platform的顶层假设是一个分布式训练平台，一切设计和优化均面向分布式训练场景。
分时运行本质是一种抢占的实现，hai-platform能达到很高的平均资源利用率是底层存储、数据格式、数据集加载工作、调度策略共同作用的结果。