PGStudy-CharacterizationofLargeLanguageModelDevelopmentintheDatacenter

发表于 更新于 分类于 ， 阅读次数： Waline： 本文字数： 7.8k 阅读时长 ≈ 28 分钟

Characterization of Large Language Model Development in the Datacenter

期刊: (发表日期: 2024-04-03) 作者: Qinghao Hu; Zhisheng Ye; Zerui Wang; Guoteng Wang; Meng Zhang; Qiaoling Chen; Peng Sun; Dahua Lin; Xiaolin Wang; Yingwei Luo; Yonggang Wen; Tianwei Zhang
摘要翻译: 大语言模型在革命性任务中展现出了令人印象深刻得表现，但在大规模集群资源中有效的低成本管理系统并不是一件容易的事，一些常见的困难如下：
频繁的硬件故障
复杂的并行化策略
不平衡的资源利用
在本文中，利用从Acme中手机的为期六个月的LLM开发工作负载跟踪进行了深入的表征研究。调查了LLM与特定任务DL在工作负载上的差异，对资源的利用模式以及作业失败的影响进行性了研究，最总总结了在资源管理方面所遇到的困难并提出了低成本管理系统的潜在机会。在此之外，作者还提出了他们所做的工作，如：
容错预训练，通过LLM参与的故障诊断与自动恢复来增强容错能力
用于评价的解耦调度，通过试探分解和调度优化实现及时的性能反馈
期刊分区: nsdi顶会-usenix
Local Link: Hu 等 - 2024 - Characterization of Large Language Model Development in the Datacenter.pdf
LLM-Data

提问式阅读

  1. 文章是哪个领域的？研究什么具体问题？

    该文章是LLM领域的，研究LLM模型训练过程中的特征与优化LLM的运行过程

  2. 作者对已有方法的问题或当前挑战的分析？

    提出了LLM训练数字中心训练的数字特征，对工作负载，包括与训练工作负载与评估阶段的工作负载做出深一层的profile。

  3. 文中提出解决问题的方法或主要贡献或创新？

    提出对Failture的analysis以及recovery方式，提出使用llm构建Fault-rolerant Pretrain。解耦评估阶段的任务以提高evalution的效率。

  4. 效果如何？

    效果显著，对Fault recovery实现了3.6~18x的提升，对eval过程效率提升了1.3-1.8x

  5. 优缺点和未来工作？

    缺点是增加系统复杂度，并仅对llm-pretrain过程进行了研究，未来工作是进一步优化系统，并探究其他方面的问题。

场外信息

源码

  • 作者源码地址:
  • InternLM Links Project: https://github.com/InternLM
  • Trace: https://github.com/InternLM/AcmeTrace
  • System: https://github.com/InternLM/InternEvo
  • Model: https://huggingface.co/internlm
  • 作者源码描述：
  • InternLM: LLM Model Project 用于大规模模型预训练和微调的轻量级框架
  • Trace：来自六个月的收集LLM数据
  • InternEvo 是一个开源的轻量级训练框架，旨在支持模型预训练，而无需广泛的依赖项。
  • Model 是该lab的团队地址

Introduce （介绍）

LLM与DL之间由于目标功能不同，所实现的功能也存在很大差异，在集群负载均衡方面，导致LLM与DL存在不小差异的LLM特性如下：

  1. 范式转变：由于LLM遵循一种新的范式，对广泛数据进行自我监督训练以生成基础模型，这与DL在特定领域数据上训练模型解决特定任务的模式不同，其意味着在模型开发管道中的重大分期与与DL负载不同的负载特征
  2. 专制的软件栈：由于LLM的据大规模，一系列系统实施了技术来优化LLM的执行，这些技术的实施对LLM的负载特征与资源调度与DL相差较大。
  3. 统一架构：在DL中，不同类型的模型被用作不同的任务，但在LLM中，许多知名的模型都使用的是Transformer模型

在六个月对Seren与Kalos集群的数据研究中，作者的主要发现如下：

  1. 更短的工作持续时间与不公平的工作延迟

    这说明对不不同的任务类型，工作延迟是极不相衬的

  2. 不平衡的资源使用

    1. 预训练任务仅占总任务的3.2%，但却消耗量图形处理器94%的时间，相反，评估工作栈所有工作的92.9%，但仅用了0.8%的资源。
    2. 对整体资源存在严重的木桶效应，对cpu，主机内存，网络并未充分利用，但gpu，gpu内存却得到了充分利用。这说明LLM是典型的资源密集型应用，同时说明GPU共享技术可能并不适合LLM

  3. 在评估负载中图形处理器的空闲时间长

    在评估负载中，图形处理器的使用率几乎只有一半

  4. 更频繁的任务失败

    在LLM工作负载开始时各种错误发生导致作业快速终止

确定了LLM开发过程中遇到的几个挑战

  1. 不稳定的训练进度
  2. 远程存储瓶颈
  3. 模型性能反馈延迟

为解决这些问题，作者整合了运营过程中获得的简介并构建了两个集成到LLM框架中的系统，其包含三个关键设计

  1. 通过同步checkpoint实现频繁的模型保存
  2. 通过启发式规则和LLM组合识别各种故障的根本原因
  3. 采用整体检测的工具包来确定故障节点并从正确保存的检查点自动重新启动训练

其次，作者开发了一个执行解耦评估调度的系统，用于提供模型质量的及时反馈。

  1. 解决了远程模型加载征用的问题
  2. 减少了GPU的空闲时间

Background （背景知识）

LLM Development Pippeline

LLM的新兴范式——对广泛的数据进行自我监督训练。对这样不同的开发管道，包含五个不同的阶段，将每个阶段的解释如下：

  1. Data数据预处理阶段：

    该阶段的数据分为两个阶段

    • pretrain data（预训练数据）：通过detoxification与deduplication流程的公共或私人获取数据
    • alignment data（对齐数据）：，包括一组较小的高质量标签库，用于将模型与特定任务对齐。

  2. Pretraining（预训练阶段）：

    它涉及对大规模策划数据的自我监督训练，需要整个开发工作流程中的大部分资源。大规模有效训练LLM需要各种系统创新，例如状态分片优化器、使用数据、管道和张量并行性的细致模型放置。

  3. Alignment（对齐阶段）

    这个阶段旨在根据用户意图调整LLM，以适应广泛的下游任务。通常使用两种主要的对齐范式

    1. 提示工程，指定提示（即，输入）而无需修改模型参数。
    2. 微调，更新特定任务数据集上的模型参数以提高特定领域的性能

  4. Evaluation（验证阶段）

    评价鉴于LLM的使用效能。

  5. Deployment（部署阶段）

    量化，蒸馏，CUDA内核优化，模型并行性和内存管理

Acme Overview

Acme是作者的私有图形处理器数据中心，LLM是该数据中心的一个模型，论文主要研究该模型中的两个工作负载Seren与Kalos。而与LLM无关的DL模型将被排除在论文研究对象外。

Seren与Kalos

上图中展示了Seren与Kalos集群的配置

硬件上的配置这里略过，软件上的设计包括：

  1. 大规模资源的调度器，在Seren和Kalos上构建基于Slurm与Kubernetes的调度器。在调度器上启用了资源隔离和配额保留的设置，进一步融入了 尽力二维的作业机制
  2. LLM workload，开发了一系列LLMs，参数范围从7B到超过123B的参数，这些LLM都基于transformer-based decoder-only的架构，类似于GPT和LLaMA
  3. 构建了系统InternEvo，继承了各种系统优化技术，容纳了模型微调与评估等额外任务。

Traces form Acme（来自Acme的数据）

  1. Jog Log 工作日志：从调度数据库中收集作业日志，其中包含每个作业的详细信息
  2. Hardware Monitor Data 硬件监控数据：这包括从各种来源获得的长期，多维数据
    1. Prometheus：收集CPU,memory,network usage data 等数据
    2. NVIDIA DCGM：收集GPU相关数据
    3. IPMI：收集电源相关数据
  3. Runtime Log运行时日志：作业执行期间从LLM框架捕获stdout与stderr日志。
  4. Profiling Data 剖面数据：对代表性作业的子集，通过DCGM等工具执行细粒度分析来进行更深入的研究。

Datacenter Characterization （数据中心数字特征）

LLMs 与 DL 负载的比较

LLM与DLModel

  1. 极端的GPU利用率分布

    在LLM的集群中显示出了更短的GPU作业持续时间，此外，完成的作业仅消耗了20~30%的图形处理器资源，这显示了对容错系统的迫切需求。

    CDF: Cumulative Distribution Function 累积分布函数，描述某个岁间变量小于或等于某个特定值的概率的函数，在文章中，他表示的是某一种情况，如GPU任务持续时间，GPU使用率等情况的出现频率的大小。

    Boxplot 箱型图：箱型图是一种用于显示数据分布情况的统计图标，它由：最小值、下四分位数（Q1）、中位数、上四分位数（Q3）和最大值的分布情况

    GPU的利用率在LLMs中两级分化，相比于其他的该值中位数48%与4%，LLM中该值为97%。该特征值体现了LLM的计算密集型模型的特点，也意味着GPU-shared-base的技术可能不适合于LLMs

  2. 高度倾斜的负载分布

    按照作业数量看，所有的集群都呈现出了相似的模式，大多数任务都是单图形处理器的，而只有不到7%的任务用到了超过8个图形处理器

    按照图形处理时间看，大规模的作业（至少256个图形处理器）占据了96%以上的资源，这样的数据特征给集群调度器的设计带来了巨大的挑战。这样的负载可能会导致车头毒蛇冰岛hi非常严重的排队延迟问题。现有的DL集群调度器常取决于抢占机制，然而相当大的附会负担使它们不适用于LLM工作负载

Workload Categories （负载的特征）

Distributiion of different workload type
boxplot of distribution of GPU demand
image-20241029145315622

SFT： SuperVised Fine-Tuning for model alignment 在模型对齐阶段的参数监督微调

MLLM：Multimodal Large Language Model 多模态的大语言模型

  1. 作业数与资源使用率并不相关

    上图中占用分别为64.9%与92.9%的Evaluation任务分别仅在Seren与Kalos中仅占6.2%与0.8%。与之相对应的是Pretrain预训练任务

  2. 作业类型与图形处理器需求相关

    在图五中描述了各种工作负载类型之间的图形处理器需求分布，他体现出了Eval任务通常仅需要4个以下的处理器，而相对的Pretrain任务通常需要100个处理器（图形）以上。这解释了为什么在对GPU的占用时间上出现了Pretrain任务较少但占用时间却较长的情况。另一个值得注意的情况是，Debug任务占据了广泛的GPU占用数量区间，这与各类型任务都需要Debug相符

  3. 相似的时间分布

    1. 从工作持续时间来看，尽管预训练工作持续时间最长，但它们的中位数超过了其他工作量一个数量级，在两个集群中，持续时间超过1天的工作都不到5%。这可以归因于预训练期间频繁失败。
    2. 关于作业排队延迟，与之前建议大规模作业经历更长等待时间的报告相反，我们观察到，尽管评估作业具有最低的图形处理器需求和最短的作业持续时间，但其排队延迟最长。这种差异是由于大部分资源被保留给预培训作业，以最大限度地减少排队延迟。评估作业通常以较低优先级的批次同时提交，利用有限的备用资源。

Infrastructure 基础设施

Infrastructure utilization

SM Streaming Multiprocessor : 流式多处理器

TC Tensor Core：张量核心

IB : infiniBand 是一种高性能互联技术，用于在计算机集群与数据中心中实现高速数据传输和低延迟通信

  1. 更高的GPU利用率

    在LLMs集群中，DCGM手机细粒度的性能指标，与PRI相反，50%的图形处理器消耗量超过75%的图形处理器内存，且两个集群中SM活性的中位数约为40%，是PRI报道的20%的两倍

  2. 未充分利用的关联资源

    很明显，CPU内存利用率保持在50%以下。请注意，Kalos的内存容量(2TB)是Seren的两倍(表1)。这表明CPU内存的利用率严重不足。

    虽然GPU内存卸载技术[80，81]提高了CPU内存利用率并缓解了GPU内存限制，但由于PCIe带宽有限，它也阻碍了训练吞吐量。因此，作者不采用分流机制。此外，由于CPU与GPU的比率很高(每个GPU 16个CPU)，CPU通常未得到充分利用，如图7(C)所示。

    我们在Seren中测量了IB的网络发送和接收带宽。两条折线重叠，因为IB在LLM执行期间用于对称通信。作者观察到，网卡有超过60%的时间处于空闲状态，活动带宽很少超过IB提供的最大带宽的25%。

Environment Impact 环境影响

Power Image

TDP Thermal Design Power：热设计功率

  1. 图形处理器主导功耗消耗

    图8（a）描述了图形处理器功耗的分布，作者观察到大约30%的图形处理器处于空闲状态，仍然需要消耗60 W。此外，由于密集的计算需求，我们发现Seren和Kalos中分别有22.1%和12.5%的图形处理器耗电量超过400 W（DPP），有些甚至达到600 W。这可能会导致一些亚稳定问题的风险[41]。

    图8（b）中描述了所有CPU、GPU节点的功耗图，可以发现GPU节点的平均功耗是CPU的五倍

Workload Profiling 工作负载剖析

在该节中作者对代表性任务的资源利用率进行细粒度分析。重点关注pretrain与eval工作

Pretraining workload 预训练工作负载

GPU SM utilization
Memory footpoint

Hierarchical ZeRO 是一种优化技术，用于减少深度学习模型在分布式训练过程中的通信开销。Hierarchical ZeRO技术通过将模型参数划分为多个层次，并在每个层次上应用不同的优化策略，以实现更高效的模型并行训练。

  1. GPU SM 利用率

    与InternEvo V1相比，V2在global batch size 相同的情况下获得了大约16%的加速，3D并行的利用率相对较低主要是混合并行引入的通信对关键路径的影响，例如流水线并行中的bubbles。

  2. GPU memory数据

    对一个含有\(\psi\)参数的模型，参数，梯度传到与优化器占用量分别为\(2\psi,2\psi,12\psi\)。3D parallelism 与 ZeRO相比，对activations的要求要搞得多

  3. 激活规模的不平衡

    当应用pipeline parallelism时，每个队列需要容纳不同数量的激活，因为不同管道队列之间等待向后计算的微批数量不同。图12中说明了不同管道等加上的不平衡问题，这说明应该需要专门的分区机制来解决内存之间的使用不平衡的问题。

Evaluation Workload 评估阶段工作负载

image-20241029155952954

  1. 模型加载和数据预处理开销大

    在评估作业的启动阶段，必须为每个任务加载模型检查点。此外，数据预处理阶段，特别是对于标记化，构成了大量的时间消耗。这些因素导致分配的图形处理器资源在相对较长的一段时间内利用不足。

    为了解决预处理负担，一种有效的策略是缓存标记化数据。此外，评估作业是灵活的，允许将多个评估任务（数据集）合并到单个作业中。这种整合可以有效减少评估过程中模型加载阶段的相对时间成本。

  2. 对指标计算的负荷很高

    在评估阶段对复杂、时间开销大的指标计算期间，图形处理器保持空闲，浪费了接近20%的总GPU时间

Failure Analysis 失败分析

Failure Category 故障类型

  1. 基础设施故障

    基础设施相关的故障是由底层计算平台或远程存储中的问题引起的。这些失败主要发生在作业执行过程的中途，尤其是在预训练任务中。由于恢复过程费力且耗时，它们严重影响了培训进度。

  2. 框架故障

    几种类型的运行时错误（例如RuntimeMessage、ValueMessage和LocalMessage）可能与张量操作、形状、数据类型或意外行为关联。它们通常在作业的初始阶段被观察到，并且通常通过修复配置来解决。

  3. 脚本故障

    脚本错误通常源于编程错误或用户疏忽。它们构成了大多数失败，通常通过修改准则来解决

故障描述

Fault Description

  1. 基础设施的故障造成了最严重的影响

    由于基础设施问题而失败的作业通常使用大量的图形处理器（图形处理器需求），并且需要相当大的努力才能重新启动（重新启动时间）。它们占用了82%的图形处理器资源（图形处理器时间），而只有11%的失败作业数量。

  2. 由于高温引起的故障

    高度优化的通信成本，导致图形处理器空闲率异常低，在异常天气的影响下很容易出现高温故障

  3. 辅助服务引发的故障

    辅助服务很容易受到网络不稳定的影响，可能会导致超时或故障，从而减慢或中断培训过程。

  4. 评估工作很少遇到错误

    仅仅只有6.7%的评估工作会遇到错误，而且没有记录到任何GPUorNVlink的错误。潜在原因可能是对其对GPU或NVlink的时间需求短且压力轻。

故障恢复

训练进度

在三种情况下重新启动作业

  1. 作业发生错误是
  2. 当出现异常时，取决于训练指标，例如损失激增
  3. 当训练过程陷入困境时。

“损失峰值”是指之前正常减少的损失突然增加，并且在一定时期内不会恢复。重新启动后，作业将恢复到最后一个检查点，导致培训进度损失。由于现有的LLM框架缺乏自动恢复支持，开发人员通常手动重新启动中断的培训作业。开发人员通常需要轮流待命，以确保及时完成预训练模型。图14中标注的为夜间的“损失峰值”

如图14所示，作者在早期阶段(3月到4月)选择了两个培训前工作，当其手动处理所有故障时。104B参数大小的大模型较早在3月运行，123B参数大小的大模型较晚，在四月运行。

其中123B模型的训练中，改进了框架，采用了更小的检查点保存间隔。此外，我们添加了一个功能来优雅地终止工作，允许在结束工作之前保留当前的培训结果。显然，123B模式的培训过程更稳定，因回滚而产生的损失更少。然而，这一进展是有代价的，因为在不同时间中断的作业必须迅速重新启动。

Depolyed LLM Systems 部署大模型系统

  1. 预训练：通过LLM涉及的故障诊断和自动恢复来增强故障容忍度。
  2. 评估：通过任务分解实现及时的绩效响应。

Fault-tolerant Pretraining 错误容忍预训练

Recovery

  1. Motivation 动机

    LLM预训练期间，由于涉及大量的图形处理器和长期的训练过程，失败是不可避免的，并且经常发生。

  2. System Design 系统设计

    作者设计的Fault-tolerant System无缝集成到了LLM预训练框架中，其包含以下三个基本模块

    1. Asynchronous Checkpointing，实现更频繁的模型保存，最大限度的减少训练损失

      由于LLM可以产生TB规模的模型状态（指所有图形处理器的总模型状态），因此保存检查点的过程本身可能会引入大量的费用，导致训练时间减慢高达43%。

      为了解决这个问题，我们采用了同步检查点策略[64，69]，该策略有效地将检查点过程与训练过程分开。我们的观察表明，中央处理器内存（参见图7（b））能够容纳多个检查点。通过利用这一点，我们可以将模型状态存储在内存中，并利用单独的线程定期将这些状态保存到远程持久存储中。这个简单的策略显着减少了检查点管理费用。

    2. Failure Diagnosis，使用启发式规则和LLM的组合来准确识别不通故障的根本原因

      为了自动恢复，确定故障是否可恢复至关重要。一种常见的方法是使用启发式规则的组合来过滤并对错误作业的日志进行正规表达匹配。

      然而，由于错误日志的广泛多样性和复杂性，这种方法通常被证明是不准确的。在许多情况下可能没有特定的错误陈述，但多个错误可能同时共存。

      为了应对这一挑战，作者利用LLM出色的文本理解能力和广泛的知识库来自动识别不同故障的根本原因。如图15所示，将LLM与基于规则的诊断结合起来，以实现高效、准确的故障诊断。主要包含以下两个步骤：

      1. Real-time Log Compression 实时日志压缩

        预训练作业生成的大量日志文件（主要由训练指标记录组成）的大小可达数百MB。为了加速诊断并满足LLM的上下文长度限制，首先进行日志压缩。

        系统不断更新一组被称为过滤规则的正规表达式。这些规则有效地删除常规日志输出，例如初始化信息、训练指标记录、框架输出和调试信息。该系统的重要组件是基于LLM的日志代理，负责分析实时生成的日志段并识别遵循固定模式的行。通过这样做，基于LLM的日志代理会动态写入正规表达式来更新过滤器规则，从而有效地最小化日志文件的大小。

        在此之外，作者采用self-consistency approach 自一致方法确保日志代理结果的健壮性并保证这些结果的格式。这涉及到

        • 多次处理每个日志段
        • 并使用另一个LLM对日志代理的多个结果进行投票

        并且系统还可以利用任务的元数据来识别重复或类似任务，使用现有过滤规则进行过滤，从而避免重复工作

      2. LLM-assisted Automated Diagnosis LLM辅助自动诊断

        日志代理有效地压缩运行时日志，隔离CUDAErrors或运行时异常等关键错误日志。尽管日志在到达此模块时已被压缩，但错误日志可能仍然很长。

        使用以下两步来进一步解决这个问题

        1. 将错误日志与不断更新的规则集进行比较，如果预定义的规则无法诊断问题，则通过嵌入模型对压缩的日志进行载体化，并存储在载体存储中，充当检索存储库。
        2. 失败代理介入。它利用查询引擎[55]来搜索载体存储。通过此搜索，失败代理可以识别反映作业中断根本原因的日志行，提取错误类型，并指示错误是否源于用户错误或基础设施故障，为恢复过程提供提示。此外，它还为用户或运营团队生成缓解建议。

        故障代理还有助于故障诊断系统的持续学习。对于每个新的故障，一旦诊断和解决，失败代理就会编写相应的规则表达并将其添加到基于规则的诊断模块中。这个过程是迭代的，并确保故障诊断系统不断发展，变得更加善于诊断和建议故障缓解方法。

      3. Fast Fault Detection and Recovery，采用整体检测工具保来确定故障节点并从正确的检查点自动重新启动训练

        根据故障诊断结果，如果属于一种基础设施故障，则进行相应的检测测试，以识别出问题节点。

        例如，为了迅速解决频繁的NVLinkError，我们采用了类似于DLRover[3]的两轮NCCL测试方法。首先，我们将所有节点划分为多个两节点世界，并执行每对中的所有聚集任务。如果服务器总数为奇数，则将一个世界大小保留为三个。如果一个世界中的所有收集任务失败，则该世界中的节点可能是故障节点。然后，在第二轮中，我们将潜在的故障节点与正常节点配对，以形成新的世界。每个世界中的节点都会继续执行allather任务，从而识别故障节点并将其隔离。

        如果故障归因于损失的突然增加(即由我们的预培训框架自动触发的“损失高峰”，选择更早的健康重启检查点，并绕过后续的数据批处理。这种方法有效地保持了模型的质量。

  3. System Performance 系统表现

    非严谨的评估下减少了\(3.6\)~\(58.7\times\)的检查点时间和管理开销百分比，并减少了90%的手动干预

Decoupled Scheduling for Evaluation 解耦计划的评估阶段

Eval

  1. Motivation 动机

    仅根据单一指标（e.g. loss）评估LLM的质量可能无法提供准确的评估。因此，纳入各种标准并评估一系列任务的绩效至关重要。我们的LLM框架在数据的预训练阶段对每个检查点进行定期评估

    如图6所示，由于资源有限且同时提交大量试验，评估作业经历了最长的排队延迟。尽管面临这些挑战

    作者找到了一些加快评估过程的潜在方法

  2. System Design 系统设计

    作者开发了一个试验协调器来协调集群调度器和LLM框架的操作。该设计结合了以下三项关键技术，旨在提高评估过程的效率。

    1. Decoupling Remote Model Loading 解耦远程模型加载

      图16(左)显示了SEREN内一系列并发评估试验(Concurrent Trials)的平均模型加载速度。由于作者存储网卡的带宽限制(25 GB/S)，在单节点上将单GPU试用次数从1次增加到8次时，加载速度会大幅下降。另一方面，当测试次数在8到256个GPU之间时，加载速度趋于稳定。这一观察结果启发采取特殊方法。并不将每个评估数据集作为单独的试验提交，而是将模型加载过程从评估过程中分离出来，如图16(右)所示。

      具体地讲，试验协调器最初从集群调度器检索可用节点列表，然后为每个节点生成一系列前身作业。这些作业将模型从远程存储加载到本地共享内存。然后协调器将评估作业提交给调度器，调度器通过高带宽PCIe加载模型。该方法有效地利用了空闲的主机内存。评估结束后，协调员将清理文件。

    2. Decoupling Metric Computation 解耦指标计算

      如图13所示，评估过程通常涉及复杂且耗时的指标计算。

      例如，必须对HumanEval [24]和MBPP [17]等编码数据集执行合成程序正确性测试。为了解决这个问题，我们将指标计算过程与评估试验脱钩。

      在图形处理器上执行模型推理后，其输出会迅速保存到文件中，从而终止推理工作量。鉴于输出通常基于文本，因此大小很小，因此该文件转储过程非常迅速。然后我们生成中央处理器作业来执行指标计算。这种方法有效地最大限度地减少了图形处理器的空闲时间并加速了评估。

    3. Prior-based Elastic Scheduling 基于先验的弹性调度

      作者注意到关于每个评估数据集的大致试验运行时间的先验知识相当稳健。并且这些数据集很灵活，使能够将多个集批处理到一次试验中以避免模型加载。还可以分解大型数据集并脱钩指标计算。提高GPU的利用率。

      并通过优先考虑作业队列中具有冗长的中央处理器指标计算的评估试验，以更好地重叠CPU、GPU计算。

  3. System Performance 系统表现

    在7B大小的LLM中进行代表性测试，涉及63个数据集的工作量，trial调度器可以将完成时间分别在单个节点（优先资源）和多个节点（相对充足资源）分别缩短\(1.3\times,1.8\times\)。

Appendix C

参考文献

  1. Characterization of Large Language Model Development in the Datacenter