Helios: Adaptive Model and Early-Exit Selection for Efficient LLM Inference Serving

作者/机构: Avinash Kumar 1, Shashank Nag 1, Jason Clemons 2, Lizy John 1, Poulami Das 1

A1 主要贡献

大型语言模型（LLMs）面临着严峻的吞吐量问题，尤其是在采用更大、更复杂的模型以产生更准确、更精细的响应时。提高推理吞吐量的方法包括减少令牌生成延迟和增加批处理大小。早退（Early-Exit）LLM（EE-LLM）是一类允许令牌在中间层根据置信度阈值提前退出的模型，通过为简单令牌跳过一些层来减少生成延迟，从而提高吞吐量。

当前EE-LLM服务的局限性：
现有的EE-LLM框架依赖于单一模型，导致那些未达到置信度阈值、必须遍历额外层的令牌限制了延迟的节省。此外，EE-LLM无法有效增加批处理大小，原因有二：
1. 缺乏内存节省：由于早退决策依赖于具体请求且在运行时才确定，并非所有令牌都会早退。因此，EE-LLM必须在GPU上加载所有层的权重并计算其键值（KV）向量，以应对最坏情况。如图1所示，存储模型权重所需的内存（即使在最先进的NVIDIA B100上，两个Llama模型也占用了高达68%的HBM）与普通的自回归解码相同，这限制了批处理大小的增加。
2. 批处理同步问题：在批处理中，通常会为批次中的每个请求生成一个令牌，然后才继续生成下一个令牌。EE-LLM必须等待批次中耗时最长的令牌，或者将批处理大小设为1。由于前者的同步开销较大，现有框架（如【4，Ee-llm: Large-scale training and inference of early-exit large language models with 3d parallelism, 2024, The Forty-first International Conference on Machine Learning】和【28，Ee-tuning: An economical yet scalable solution for tuning early-exit large language models, 2024, arXiv】）默认采用后者。

本文提出的HELIOS框架：
本文提出了HELIOS，一个旨在通过改善令牌生成延迟和批处理大小来提高EE-LLM吞吐量的框架。HELIOS利用了两个关键洞察：
1. 模型的早退特性具有互补性：在一个LLM上无法早退的令牌，通常可以在另一个LLM上早退。例如，研究表明，使用24层的OPT-1.3B模型处理标准基准测试的混合提示时，74%的令牌在前6层即可处理，但剩余26%需要所有层。然而，这剩余令牌中的57%仅需使用32层的OPT-6.7B模型的前9层即可处理。HELIOS通过高效地使用多个LLM来最大化早退令牌的数量，从而大幅降低平均令牌生成延迟。
2. 低置信度令牌的稳定性：即使在早退点未达到置信度阈值，预测的令牌在经过额外层之后通常也保持不变。例如，研究发现，在OPT-6.7B模型中，因置信度得分（0.2）过低而未能在第9层退出的令牌，在遍历所有32层后，有92.1%的概率最终成为输出令牌。HELIOS利用此洞察，仅加载最可能被使用的层的权重，并将那些未达到置信度阈值的令牌贪婪地提前退出。这带来了内存节省，可用于增加批处理大小，并消除了批处理中的同步开销。

为了应对动态性和准确性挑战，HELIOS采用实时分析来识别早退分布，并通过实时追踪令牌来适应性地切换模型，以最小化贪婪加载和退出带来的性能下降。

主要贡献：
1. 揭示了EE-LLM吞吐量受限的原因：单一LLM限制了计算节省，而缺乏内存节省则限制了批处理大小的扩展。
2. 提出了HELIOS框架，该框架使用多个模型并动态切换，以共同最大化早退令牌数量，从而降低令牌生成延迟并提高吞吐量。
3. HELIOS利用了低置信度令牌在经过额外层后通常保持不变的观察，引导更多令牌早退，进一步提高吞吐量。
4. HELIOS通过实时分析早退分布，贪婪地仅加载最可能使用的层的权重，节省的内存被用于支持更大的批处理大小。

评估表明，与现有EE-LLM框架相比，HELIOS实现了1.48倍的吞吐量提升和15.14倍的批处理大小增加，而对准确性的影响可以忽略不计。


图 1. (a) 存储模型权重所需的内存和 (b) CodeLlama-34B 和 Llama2-70B 模型在 ShareGPT（sha, 2023）上的吞吐量对比，涵盖了普通自回归解码、EE-LLM 和 HELIOS。HELIOS 通过使用多个 LLM 最大化跨模型的早退，并贪婪地加载最可能使用的层的权重，从而同时减少了令牌生成延迟和内存占用。内存节省带来了更高的批处理大小，HELIOS 整体吞吐量提升了 45%，而 EE-LLM 相对于普通解码仅提升了 16%。


图 2. (a) 当前的 EE-LLM 选择一个模型（如 M1），加载其所有层的权重，并使用批处理大小为 1 以避免令牌间的同步。(b) HELIOS 使用多个 LLM（此处为 M1 和 M2），并根据实时的早退配置文件，仅加载最可能被使用的层的权重。HELIOS 通过增加可用内存容量和减少同步开销来提高批处理大小。HELIOS 还实时监控性能，并在 LLM 之间切换或加载当前模型的额外层，以防止准确性下降。

A3 背景知识与关键洞察

2.1 早退大型语言模型

早退LLM的定义。早退LLM（EE-LLM）是一类语言模型，它们通过允许令牌在正向传播过程中，若其概率满足预定义的置信度阈值，便在特定的中间层退出，从而实现高吞吐量推理。对于简单的令牌，EE-LLM通过跳过模型后期层的计算来减少平均令牌生成延迟，进而在不降低准确性的前提下提高吞吐量。EE-LLM带来的计算和延迟节省与跳过的层数成正比，最终转化为更高的吞吐量。因此，EE-LLM已在工业界和学术界的各种深度学习架构中被广泛采用（如【10，Layerskip: Enabling early exit inference and self-speculative decoding, 2024, arXiv】, 【37，Early-exit with class exclusion for efficient inference of neural networks, 2024, IEEE 6th International Conference on AI Circuits and Systems (AICAS)】 和 【41，Lgvit: Dynamic early exiting for accelerating vision transformer, 2023, Proceedings of the 31st ACM International Conference on Multimedia】）。

2.2 现有EE-LLM服务的局限性

现有框架的吞吐量瓶颈。现有的EE-LLM框架由于两个关键限制，其吞吐量增益有限。首先，它们带来的延迟节省有限，因为它们依赖于单一模型，导致在该模型上未能早退的令牌必须遍历额外的层，直到满足置信度阈值为止。因此，平均令牌生成延迟和吞吐量受限于那些不能早退的令牌数量。

内存限制导致批处理大小受限。其次，EE-LLM不提供内存节省，这限制了批处理大小。由于早退决策仅在运行时才可知，无法预先预测，当前的EE-LLM会将所有模型层的权重加载到GPU上，即使在令牌早退时后期层并未被使用。值得注意的是，尽管最近在量化（如【50，Atom: Low-bit quantization for efficient and accurate llm serving, 2024, Proceedings of Machine Learning and Systems】）和压缩（如【52，A survey on model compression for large language models, 2024, Transactions of the Association for Computational Linguistics】）方面取得了进展，模型权重仍然是GPU内存占用的主要部分。例如，即使在一个配备八个最先进的NVIDIA B100 GPU的节点上，Llama3.1 405B模型也消耗了约52%的可用HBM来存储模型权重。此外，当前的EE-LLM框架还会为所有跳过的层计算并缓存键值（KV）向量，以应对最坏的退出深度情况，因为任何未来的非早退令牌都必须关注所有之前的令牌。因此，EE-LLM的整体内存占用与普通的自回归解码相同，这限制了批处理的大小。

2.3 目标：最大化早退令牌和批处理大小

优化目标。由于令牌生成延迟取决于遍历的层数，理想情况下，我们希望最大化早退的令牌数量以最大化吞吐量。为了进一步提高吞吐量，我们必须通过提高内存效率来扩展到更大的批处理大小，即减少未使用内存的占用，并将节省的内存重新用于并行支持额外的请求。本文提出的HELIOS旨在实现这些目标。

3.1 关键洞察

洞察一：早退具有互补性。我们的实验表明，早退决策取决于所使用的EE-LLM，并且在不同模型之间通常是互补的。对于需要在一个模型中进行额外层遍历或遍历所有层（即没有早退）的令牌，通常可以使用另一个模型通过早退来准确预测。例如，图3显示，在24层的OPT-1.3B模型上需要超过十二层的提示，在OPT-6.7B模型上以相似的准确度只需要更少的层。我们对32层的OPT-6.7B模型上需要超过九层的提示也观察到了类似现象。HELIOS利用这一特性，采用多个模型并动态地在它们之间切换，使得两个模型共同最大化早退令牌的数量，从而减少平均令牌生成延迟并提高吞吐量。


图 3. 使用 OPT 1.3B 和 6.7B 模型为包含混合提示的典型工作负载提供服务时的退出层。

洞察二：有时未满足置信度是可接受的。我们的研究揭示，即使在早退点未达到置信度阈值，预测的令牌在经过额外的模型层遍历后也常常保持不变。图5(a)展示了在32层OPT 6.7B模型中，从第一个早退点（第9层）开始，随着概率的变化，即使遍历了额外的模型层，保持不变的令牌比例。例如，如果置信度阈值为1，没有令牌会早退。然而，我们观察到，即使我们将阈值设为低至0，第9层预测的令牌与最终退出层（第32层）预测的令牌在85%的情况下是相同的；遍历后续层仅提高了置信度。先前的一项工作（【51，Bert loses patience: Fast and robust inference with early exit, 2020, https://arxiv.org/abs/2006.04152】）也得出了类似的观察 。

跨模型和尺寸的一致性。此外，即使在不同的模型尺寸和家族中，早退也能持续产生准确的输出令牌。例如，图5(b)显示，对于Codellama-34B模型，在CNN-Dailymail数据集（【26，Abstractive text summarization using sequence-to-sequence RNNs and beyond, 2016, Proceedings of the 20th SIGNLL Conference on Computational Natural Language Learning】）上，由第16层（模型深度的三分之一）产生的90%的令牌保持不变（更多数据见附录C）。HELIOS利用这一洞察，贪婪地只加载所选模型中最可能被使用的层，并频繁地允许令牌在未达到置信度阈值时退出，从而节省内存以支持更大的批处理大小。需要注意的是，这对准确性的影响可以忽略不计，因为(1) HELIOS通过采用具有互补早退特性的多个模型，已经大幅减少了需要额外层遍历的令牌百分比；(2) 未满足置信度阈值并不意味着预测的令牌是错误的。HELIOS还在设计中引入了额外的步骤来最小化准确性损失，具体将在下文讨论。


图 4. HELIOS的设计。


图 5. (a) 在OPT-6.7B模型上，四个数据集中从第1个退出层(9)到最终层(32)保持不变的令牌比例。我们观察到，预测令牌保持不变的概率始终大于85%。(b) 对于Codellama-34B模型，在六个数据集中，在一个退出层生成的令牌即使在遍历整个模型后仍然保持不变的比例。

A2 方法细节

3.2 设计概览

HELIOS工作流程。图4展示了HELIOS的概览。1 HELIOS选择一组候选模型，并 2 实时评估它们的性能。3 然后，根据评估步骤得到的早退历史，仅加载所选模型的部分层用于生成后续令牌。4 如果当前模型加载的层数不足，系统会请求加载更多层。HELIOS会比较两种选择的开销：(1) 为当前模型加载更多层，或 (2) 切换到候选池中的另一个模型，并根据开销大小做出决策。5 HELIOS还会定期重新评估所选模型的性能，并在需要时切换到另一个候选模型，以适应请求流不断变化的特性。

3.3 设计实现

HELIOS的具体实现。接下来，我们将讨论HELIOS的实现细节。

3.3.1 步骤一：选择候选模型

模型选择过程。通常，服务提供商会维护一个模型库（Model Repository, MR），其中包含关键性能指标，如在不同标准基准测试下的吞吐量和准确性。HELIOS利用这些遥测数据，根据用户指定的服务等级目标（SLOs）和可用硬件，选择TopK个候选模型。我们在图4中用M1、M2和M3作为候选模型来说明这一点。默认情况下，HELIOS最多选择三个模型，以最小化评估步骤所花费的时间，从而快速确定适合当前请求流的候选模型。

3.3.2 步骤二：评估候选模型

实时性能评估。接下来，HELIOS实时评估所选候选模型的性能，以获得更准确的遥测数据并收集早退分布配置文件，因为这些信息通常不在模型库中。这个配置文件之所以有效，是因为连续的查询通常具有重叠的上下文并表现出局部性。默认情况下，HELIOS为每个候选模型评估五个请求。图4对此进行了说明，其中模型M1、M2和M3为五个请求生成输出令牌。这不会影响性能（例如首个令牌生成时间或TTFT），因为生成的输出令牌不会被丢弃，这是因为之前的候选模型选择过程是高度选择性的，确保只有合适的模型被入围。需要注意的是，候选模型评估也可以并行进行，但在我们的默认设计中，由于硬件限制（GPU数量不足），我们避免了这样做。

评估方法。我们使用分析工具来获取吞吐量和早退分布。评估准确性并非易事，因为传入的请求缺乏可供比较的基准真相。因此，我们使用困惑度（perplexity），因为它是一种无参考、高效且适合实时推理的指标（详见附录A）。表1显示了两个模型在评估前后的困惑度，突显了我们方法的有效性。如果仅根据模型库数据选择模型，我们会选择OPT-6.7B模型。然而，我们选择了OPT-1.3B模型，因为评估后的数据表明它对当前提示更有效。

性能历史表。每个模型的特定于请求的性能数据（吞吐量、准确性）和早退配置文件保存在一个名为性能历史表（Performance History Table, PHT）的表格中。PHT将在HELIOS的后续阶段中使用，具体将在下文讨论。

Table 1. 选择阶段从MR中预定值与评估后阶段的困惑度比较。

3.3.3 步骤三：使用最佳模型生成令牌

令牌生成。在评估阶段确定的最佳候选模型被用来为传入的请求生成令牌。

贪婪加载至选定的退出层。HELIOS基于模型的早退配置文件，贪婪地加载最可能被使用的层的权重。这带来了内存节省，可用于增加批处理大小（洞察-#2）。例如，图6(a)显示了使用OPT-1.3B模型处理一个混合提示时的退出情况，其中74%的请求仅需要模型的前六层。我们将这些称为低退出令牌（Low-Exit Tokens, LTs）。在这种情况下，HELIOS贪婪地只加载到第六层（在图4中表示为M'1）。如果大多数待处理请求都是不需要额外层的LTs，这种贪婪方法可以在不牺牲准确性的前提下，实现显著的内存节省。

加载更多层还是切换到另一个候选模型？ 尽管部分加载的模型能提供显著的内存节省并提高批处理大小，但我们仍会遇到未达到置信度阈值的令牌。例如，在图6(a)中，26%的请求使用了超过六层。我们将这些称为高退出令牌（High-Exit Tokens, HTs）。在这种情况下，HELIOS有两个选择：(1) 要么加载当前LLM（本例中为OPT-1.3B）的剩余层，(2) 要么切换到另一个可以用更少层数服务该请求流的模型。第一个选项确保当前模型是完整的，并保证置信度阈值会被满足。相比之下，第二个选项旨在找到一个更高效的替代方案，并最大化总的早退次数（洞察-#1）。图6(b)显示了当使用另一个候选模型OPT-6.7B时，HTs的退出分布。我们观察到57%的HTs仅需使用OPT-6.7B模型的前九层即可服务。请注意，退出历史信息已在PHT中从步骤-2获得。只有当加载当前模型更多层的总资源使用量低于第二个选项（加载另一个候选模型的部分层，例如本例中的OPT-6.7B的前九层）时，该选项才是有利的。一旦评估了两个选项的开销，就会选择开销最小的选项并采取相应行动。

使用CBC分摊加载开销。无论选择哪个选项，加载额外层和模型切换都会产生开销。为了最小化这些开销，HELIOS仅在一个窗口内一定数量的令牌未能满足置信度阈值后，才考虑这两个选项。这利用了我们的观察：并非每个在早退点未能满足置信度阈值的令牌，在经过后续层后实际上都会改变（洞察#2）。HELIOS使用一个置信度违规计数器（Confidence Breach Counter, CBC），每当输出令牌不满足置信度阈值时，该计数器就会增加。如果CBC超过了预定的最大允许限制（CBCmax），HELIOS会重新评估是应该加载更多层还是切换到另一个模型来服务传入的请求流。默认情况下，HELIOS在一个包含100个连续令牌的窗口内，最多容忍50次置信度阈值违规（CBCmax = 50）。

使用重新评估间隔（RI）。理想情况下，我们应该为每个请求在所有候选模型中重新评估早退配置文件，以最大化当前请求流的早退次数。然而，频繁的分析会引入大量开销。相反，不频繁地捕获早退配置文件也不可取，因为尽管输入请求表现出时间局部性，但它们的特性通常会随着时间的推移而演变。因此，HELIOS当前使用的PHT中捕获的早退配置文件可能会变得过时和次优。HELIOS通过使用重新评估间隔（Re-assessment Interval, RI）超参数在这个权衡空间中找到了一个平衡点，并在服务了RI个请求后定期调用分析阶段（步骤-2）。默认情况下，HELIOS每服务150个请求（RI=150）后收集一次早退配置文件，但理想情况下，服务提供商必须微调此超参数以匹配其请求流的变化。我们的默认实现不会重新选择候选模型，因为我们的评估显示，某些模型通常在各种任务中表现更佳。例如，图7显示Llama3-8B和Llama2-13B始终表现良好，而GPT2-124M则始终表现不佳。尽管如此，如果用户指定的SLO或硬件约束发生变化，HELIOS也可以查询模型库以选择新的候选模型。


图 6. (a) 使用OPT-1.3B模型处理一个提示混合的令牌的退出层分布。74%的请求仅需要最多6层。(b) 当剩余的26%由OPT-6.7B模型服务时，其退出层的分布。


图 7. 多个模型在不同数据集上的准确性（相对于最佳模型）。我们观察到，一些模型（如Llama3-8B, Llama2-13B）始终表现良好，而另一些模型（如GPT2-124M）则始终表现不佳。HELIOS利用这一观察结果，消除了频繁的候选模型选择，仅在SLO或硬件约束发生变化时才执行此步骤。

3.4 HELIOS 算法

HELIOS 算法描述。算法1描述了HELIOS的算法。

算法 1 使用HELIOS的自适应EE-LLM服务

输入：模型库(MR)，服务等级目标(SLO)
输出：动态模型选择
参数：M: 完整模型; M': 低退出模型;
      CBC: 置信度违规计数器; CBCmax: 阈值;
      RI: 重新评估间隔;
步骤-1: Candidates ← Topk(MR(SLO, HW constraints))
while 提示在请求中 do
    CBC, ServicedPrompts ← 0
    步骤-2: PHT[M, M'] ← Evaluate(Candidates)
    Chosen ← BestModel(PHT[M'])
    repeat
        步骤-3: Serve(prompt, Chosen)
        if 置信度未满足 then
            CBC ← CBC + 1
            if CBC > CBCmax then
                if PHT[M(Chosen)] < PHT[M'(Others)] then
                    Chosen ← M[Chosen]
                else
                    Chosen ← M'[NextBestModel(PHT)]
                end if
                CBC ← 0
            end if
        end if
    until ServicedPrompts < RI (步骤-4)
end while

A4 实验环境

4.1 模型

Table 2. 候选模型配置概览

4.2 实验设置

4.3 数据集

4.4 评估指标

Table 3. 使用的指标摘要

A4 实验结果

默认情况下，我们认为用户的SLO是最大化推理吞吐量。

5.1 吞吐量

此项评估将HELIOS的批处理大小限制为1，以专门评估通过最大化早退带来的吞吐量增益，并使用了标准基准的混合提示来评估其普适性。吞吐量与遍历的层数和每层耗时成反比。因此，如果更多令牌 (1) 采取早退，并且 (2) 我们使用较小的模型进行早退（因为在较大模型上遍历一层耗时更长），吞吐量就会增加。

结果分析：如图8所示，与单独使用OPT-1.3B和OPT-6.7B模型的EE-LLM相比，HELIOS的平均吞吐量分别提高了1.48倍和2.13倍。图8(c)中的LD表示加载当前模型更多层的场景，SW表示HELIOS切换到另一个模型的场景，这突显了HELIOS的自适应性。

早退分布：表4比较了单独使用OPT EE-LLM与使用HELIOS时的令牌退出分布。在HELIOS中，约91%的令牌通过两个模型最早的退出点（OPT-1.3B的第6层和OPT-6.7B的第9层）组合处理，而单独使用模型时仅为约73%。其中，很大一部分（约70%）由较小的OPT-1.3B模型的最早退出点处理。需要遍历两个模型所有层的请求百分比仅为7.39%，比单独使用任一EE-LLM低3倍。这证明了HELIOS在最大化早退令牌数量方面的有效性，并确保了对准确性的影响最小，因为需要额外层的令牌没有被牺牲。


图 8. (a) 仅使用 OPT-1.3B (EE-LLM)、(b) 仅使用 OPT-6.7B (EE-LLM) 和 (c) 使用 HELIOS 时的吞吐量比较（越高越好）。(c) 中的垂直虚线表示候选模型重新评估的步骤。

Table 4. 不同模型选择方法的各退出层处理的令牌百分比比较。

5.2 准确性

与现有的EE-LLM相比，HELIOS对准确性的影响可以忽略不计。实验表明，HELIOS在混合提示下的困惑度仅比OPT-1.3B模型高0.01。在此特定场景中，OPT-1.3B模型比OPT-6.7B模型更准确，因此被用作比较基准。

5.3 响应时间和延迟

表5比较了HELIOS与每个单独EE-LLM的首个令牌生成时间（TTFT）和每个输出令牌的时间（TPOT）。我们观察到，HELIOS的TTFT显著更低，因为它默认使用带有早退功能的小模型服务大多数请求。同样，令牌生成延迟或TPOT降低了高达46.6%，因为HELIOS最大化了早退令牌的总数。

Table 5. 单独的EE-LLM模型和HELIOS的响应时间和延迟比较。

5.4 批处理大小

HELIOS通过以下两种方式支持更大的批处理大小：(1) 消除同步开销，以及 (2) 将通过贪婪加载最常用层权重所节省的GPU内存重新利用。在HELIOS中，任何给定时间步的所有令牌都必须从同一个早退层退出（即所选模型加载到的层），从而完全消除了同步需求。处理请求需要内存来存储 (1) 模型权重和 (2) 每层模型的键值（KV）缓存。虽然模型权重可以共享，但每个请求必须维护自己的KV缓存。仅加载部分层会带来巨大的内存节省，因为模型权重和KV缓存的内存占用都与未加载的层数成比例减少。HELIOS将这些节省的内存用于为额外请求分配KV缓存空间，从而支持更大的批处理大小。

结果分析：图9比较了HELIOS与当前EE-LLM框架的批处理大小。HELIOS将批处理大小提高了多达15.14倍，显示了其有效性。表6比较了HELIOS与每个独立EE-LLM的内存占用。HELIOS实现了显著的内存节省（高达67.4%）。值得注意的是，对于使用CodeLlama-34B和Llama2-70B的场景，HELIOS根本不需要加载整个模型。

通常，HELIOS对于包含更多早退点的大型模型能带来更大的内存节省。这是因为大型模型的权重占用了大量GPU内存。例如，在我们的160GB内存配置中，Llama2-70B模型占用了81.6%的可用内存。此外，大型模型为早退提供了更大的灵活性。例如，在Llama2-70B模型中均匀微调早退点可以提供九个早退路径，而Llama2-7B模型只有三个。

正交性：HELIOS的内存节省方法与其他内存优化技术（如权重内存量化（【50，Atom: Low-bit quantization for efficient and accurate llm serving, 2024, Proceedings of Machine Learning and Systems】;【23，Spinquant: Llm quantization with learned rotations, 2024, arXiv】）和KV缓存优化（【20，Snapkv: Llm knows what you are looking for before generation, 2024, Advances in Neural Information Processing Systems】;【14，Dialogue without limits: Constant-sized kv caches for extended responses in llms, 2025, arXiv】;【45，H2o: ´ Heavy-hitter oracle for efficient generative inference of large language models, 2023, Advances in Neural Information Processing Systems】;【39，Efficient streaming language models with attention sinks, 2023, arXiv】））是正交的，可以与这些方法结合使用，以实现更大的内存节省和更高的吞吐量增益。


图 9. HELIOS与当前EE-LLM框架的归一化批处理大小比较。贪婪地只加载最可能被使用的层，减少了权重和键值（KV）缓存的占用空间，从而节省了大量内存，这些内存被重新用于并行支持其他请求，从而增加了批处理大小。

Table 6. 单独模型和HELIOS在ShareGPT数据集上于Nvidia A100 GPU上的内存占用。

5.5 跨置信度阈值的可扩展性

预定义的早退置信度阈值（TH）是决定EE-LLM和HELIOS性能的关键参数。在现有的EE-LLM服务框架中，提高置信度阈值会减少采取早退的令牌数量，因为满足退出标准的难度加大。因此，更多令牌会遍历额外层，最终导致有效吞吐量下降。这与我们在图10中的观察一致，该图显示了提高置信度阈值对两种不同EE-LLM（OPT-1.3B和OPT-6.7B）吞吐量的影响。

相比之下，HELIOS的吞吐量增益保持稳定。这有两个原因。首先，通过采用多个模型，HELIOS会遇到更多自然满足置信度阈值并退出的令牌。其次，通过贪婪地只加载最可能被使用的层的权重，并强制令牌违反置信度阈值，HELIOS中提高置信度阈值对吞吐量的影响被最小化了。


图 10. 提高T H对吞吐量的影响。

5.6 重新评估的影响

重新评估间隔（RI）超参数影响HELIOS的性能——RI值过低会频繁触发早退配置文件的重新评估，产生开销；而RI值过大则意味着HELIOS可能正在使用过时的退出配置文件服务请求。图11显示了随着RI值增加的吞吐量。现有的EE-LLM框架没有RI的概念，因此其吞吐量不受影响。对于HELIOS，当RI=50时吞吐量最高，并在RI增加到250时有所下降。此外，虽然更高的RI值能带来更高的吞D吐量，但也有很大可能影响准确性，因为在两次重新评估阶段之间，传入提示的性质可能会发生变化。如果HELIOS在此期间从未超过置信度违规计数器，这些变化可能不会被检测到。我们的默认实现使用RI为150，因为HELIOS还因置信度违规计数器超过其最大容忍限度而在重新评估间隔之间进行额外的模型切换。因此，选择一个略高于50的RI值，使我们能够在不显著影响吞吐量和准确性的情况下，最小化重新评估的开销。


图 11. 增加RI对吞吐量的影响。

5.7 对其他SLO的泛化能力

本节目前为止呈现的结果都考虑用户默认SLO为最大化吞吐量。然而，HELIOS是通用的，能够有效适应广泛的SLO目标。为了评估这一点，我们还考虑了其他SLO，如响应时间、准确性和能效。我们在附录E中提供了我们结果的全面分析。

A7 补充细节

先前的软硬件工作探索了LLM性能指标之间的权衡，我们在下面进行比较和对比：

与推测解码的比较。推测解码（【19，Fast inference from transformers via speculative decoding, 2018, International Conference on Machine Learning】; 【18，Speculative decoding with big little decoder, 2023, Advances in Neural Information Processing Systems】; 【32，Blockwise parallel decoding for deep autoregressive models, 2018, Advances in Neural Information Processing Systems】）是一种推理时技术，它协调一个较小的草稿模型和一个较大的目标模型。草稿模型逐个生成输出令牌，而目标模型则并行地定期验证和纠正它们。然而，与推测解码不同，早退通过跳过同一模型的后续层显著降低了能耗，并消除了计算密集的验证阶段。我们的实验表明，在CNN Daily Mail数据集（【26，Abstractive text summarization using sequence-to-sequence RNNs and beyond, 2016, Proceedings of the 20th SIGNLL Conference on Computational Natural Language Learning】）上，一个由OPT-125M和OPT-6.7B组成的推测系统比带有两个早退出口的OPT-6.7B多消耗1.49倍的能量。LayerSkip（【10，Layerskip: Enabling early exit inference and self-speculative decoding, 2024, arXiv】）将早退机制融入其推测解码框架以获得更多好处。此外，LayerSkip中选定的草稿层在整个执行过程中保持静态，不随请求流中输入性质的变化而变化。HELIOS则自适应地在EE-LLM模型之间切换或加载更多层，以共同最大化早退。如果所服务的模型在达到贪婪加载的EE-LLM深度之前至少包含一个中间出口，HELIOS仍然可以采用基于单退出层的推测解码。

硬件-软件协同设计。BERT Loses Patience（【51，Bert loses patience: Fast and robust inference with early exit, 2020, https://arxiv.org/abs/2006.04152】）提出了一种通过引入基于耐心的早退来实现快速鲁棒推理的技术。在该方法中，辅助分类器附加到中间的Transformer层，如果预测的类别在预定义数量的连续层中保持不变，则动态终止前向传播。这种方法利用多个中间层来终止低置信度令牌的前向传播。相比之下，HELIOS实时利用早退分布，贪婪地仅将最可能使用的层加载到GPU内存中。这使得HELIOS不仅能改善令牌生成延迟，还能因其贪婪方法带来的内存节省而支持更大的批处理大小。先前的工 作 Edge-BERT（【33，Edgebert: Sentence-level energy optimizations for latency-aware multi-task nlp inference, 2021, Proceedings of the 54th Annual IEEE/ACM International Symposium on Microarchitecture】）提出利用GPU功耗管理（DVFS）根据预测的早退自适应地管理GPU时钟频率。这使得Edge-BERT在令牌经过很少的Transformer层就退出时能节省大量功耗。HELIOS是一个通用框架，能够适应任何用户定义的SLO，而不仅仅局限于能效，后者是Edge-BERT的主要关注点。

模型服务优化。此外，还有一些关于云端LLM推理服务的工作。INFaaS（【30，{INFaaS}: Automated model-less inference serving, 2021, 2021 USENIX Annual Technical Conference (USENIX ATC 21)】）选择一个满足任务SLO的模型并用其进行推理，而Clipper（【8，Clipper: A {Low-Latency} online prediction serving system, 2017, 14th USENIX Symposium on Networked Systems Design and Implementation (NSDI 17)】）则结合了并发托管的多个模型的预测。相比之下，HELIOS动态选择一个模型，一次从单个模型获取预测，同时确保整体困惑度保持相似。像流水线并行（【27，Pipedream: Generalized pipeline parallelism for dnn training, 2019, Proceedings of the 27th ACM symposium on operating systems principles】）和模型并行（如AlpaServe【21，Alpaserve: Statistical multiplexing with model parallelism for deep learning serving, 2023, https://arxiv.org/abs/2302.11665】中使用）等技术与HELIOS是互补的，可以结合使用以扩展我们的设计，从而在GPU上容纳更大的模型。同样，将预填充和令牌生成阶段在多个GPU上拆分的技术Splitwise（【29 ，Splitwise: Efficient generative llm inference using phase splitting, 2024, 2024 ACM/IEEE 51st Annual International Symposium on Computer Architecture (ISCA)】）也与HELIOS的设计互补。

动态神经网络。多项工作开发了根据特定部署和提示场景具有不同计算图的神经网络（【15，Dynamic Neural Networks: A Survey, 2022, IEEE Transactions on Pattern Analysis & Machine Intelligence】;【36，Convolutional networks with adaptive computation graphs, 2017, CoRR】）。然而，与HELIOS不同，这些框架只考虑单个模型及其内部配置。

A5 结论

早退LLM（EE-LLM）是一类有前途的LLM变体，它们通过允许令牌在正向传播过程中，如果其概率满足预定义的置信度阈值，便在特定的中间层退出，从而实现高吞吐量推理。这使得它们很有吸引力，因为它们在不牺牲准确性的前提下提高了吞吐量。现有的EE-LLM框架依赖于单一模型，因此，它们的令牌生成延迟主要受限于那些没有早退的令牌。为了适应最坏情况的退出深度，当前的EE-LLM服务框架会加载所有模型层的权重，即使在令牌早退时，对应于后期层的内存仍未被使用。有限的延迟节省和糟糕的内存管理严重限制了我们在这些框架中获得大的吞吐量收益。

在本文中，我们提出了HELIOS，一个自适应的EE-LLM服务框架，它通过最大化早退令牌的总数来减少令牌生成延迟；并提高了内存效率，使我们能够扩展批处理大小。HELIOS协调多个模型，并在它们之间动态切换，以共同最大化给定输入提示集的早退次数。此外，它利用了低置信度令牌即使在经过额外层遍历后也常常保持不变的洞察。因此，HELIOS贪婪地只将最可能被使用的层的权重加载到GPU内存中，从而节省内存，然后将这些内存重新用于支持更大的批处理大小。我们的研究表明，与现有框架相比，HELIOS在满足SLO的同时，实现了1.48倍的吞吐量和高达15.14倍的更高批处理大小，且对准确性的影响可以忽略不计。

A6 附录

A 使用困惑度评估准确性

推理时准确性评估的需求。HELIOS在推理时进行准确性评估，以决定何时选择性地加载更多层或切换到不同的模型。准确性评估方法可分为三大类：

HELIOS的选择。由于HELIOS是一种推理时技术，并且服务器无法获得传入请求的基准真相，因此它只能采用无参考的方法进行准确性评估。虽然基于LLM的指标可以提供对输出质量的详细评估，但它们的使用不切实际，因为它们需要在内存中加载一个比被评估模型大得多的独立LLM。

为什么选择困惑度。我们使用困惑度来实时评估准确性。与BLANC等衡量输出文本如何帮助语言模型重构源文档的指标不同，困惑度捕捉了模型自身对其输出分布的置信度。BLANC涉及重复的掩码和重新编码操作，使其不适合实时推理。相比之下，困惑度直接从令牌概率计算得出，提供了一种可以在推理过程中高效计算的、内在的、无参考的输出质量度量。此外，我们的评估通过将模型库限制为具有相同分词器和词汇表的模型，确保了模型之间的困惑度比较是公平的，从而保持了分词和似然归一化的一致性。

B 用于评估的基准测试

评估任务的多样性。我们在一系列广泛的LLM任务上评估HELIOS，包括对话、摘要、数学推理、代码生成和句子补全。以下部分详细描述了我们评估中使用的基准测试：

数据集的挑战性。图12比较了这些数据集的令牌级熵。较高的熵表示较低的可预测性和较大的词汇多样性，而较低的熵对应于较高的可预测性和更重复的结构。这些数据集表现出持续的高熵，表明准确预测输出令牌并非易事。总体而言，使用这些数据集确保了我们的评估保持了一致的预测挑战水平。


图 12. 数据集熵的比较。较高的熵表示较低的可预测性和较大的词汇结构多样性。

C 低置信度令牌保持不变

Transformer层的作用。基于Transformer的LLM由多个解码器层组成。每个层处理前一层的输出，以逐步优化输出令牌。EE-LLM引入了机制，使得输出令牌在满足预定义的置信度标准时，可以在中间层退出。然而，我们观察到，通常情况下，未能早退的低置信度令牌，在经过额外的模型遍历后仍然保持不变。例如，图13显示了由一个退出层产生并且在遍历整个模型后仍然保持不变的令牌比例。我们观察到，在Llama2-7B（【34，Llama 2: Open foundation and finetuned chat models, 2023, arXiv】）模型的情况下，第八层（模型深度的四分之一）就能为CNN-Dailymail（【26，Abstractive text summarization using sequence-to-sequence RNNs and beyond, 2016, Proceedings of the 20th SIGNLL Conference on Computational Natural Language Learning】）数据集准确地产生高达90%的令牌。此外，这一趋势在Llama家族（【34】;【9，The llama 3 herd of models, 2024, arXiv】;【31，Code llama: Open foundation models for code, 2023, arXiv】）不同大小的模型中保持一致，这表明早退层具有很强的预测能力，与模型规模无关。HELIOS利用这一洞察，贪婪地只加载最可能被使用的层，从而节省内存。这些节省的内存随后被重新用于支持更大的批处理大小。


图 13. 由一个退出层产生的、即使在额外的模型遍历后仍然保持不变的令牌比例。我们观察到，对于Llama2-7B模型，预测令牌保持不变的概率在第8层（即模型深度的四分之一）就已达到90%。此外，这一趋势在Llama家族的各种尺寸模型中保持一致。

D 评估过的模型

模型分类。我们使用预训练和后训练修改的EE-LLM来评估HELIOS。预训练模型在模型原始训练过程中就直接被训练为允许中间退出，而后训练修改模型指的是标准的现有LLM，这些LLM后来通过微调被增强了早退功能。本节的其余部分提供了每个类别的具体细节：

预训练模型。Layerskip（【10，Layerskip: Enabling early exit inference and self-speculative decoding, 2024, arXiv】）已在HuggingFace（【1，hugging face, 2016】）上公开发布了多个预训练的早退模型，涵盖了Llama2（【34，Llama 2: Open foundation and finetuned chat models, 2023, arXiv】）、Llama3（【9，The llama 3 herd of models, 2024, arXiv】）和CodeLlama（【31，Code llama: Open foundation models for code, 2023, arXiv】）系列。这些模型被训练为允许令牌在任意层后退出，为HELIOS贪婪地只加载最可能被使用的模型层提供了更大的灵活性。与它们的标准对应模型相比，Layerskip变体在支持早退的同时，实现了相当的性能。

后训练修改模型。我们通过在选定的中间层深度插入早退机制（辅助头），扩展了OPT家族的两个基础模型。然后，这些模型被微调，其中主干参数保持冻结，每次迭代中只更新辅助头的参数。先前的工作（【40，Berxit: Early exiting for bert with better fine-tuning and extension to regression, 2021, Proceedings of the 16th conference of the European chapter of the association for computational linguistics: Main Volume】;【28，Ee-tuning: An economical yet scalable solution for tuning early-exit large language models, 2024, arXiv】）已经观察到，这种选择性微调保留了主干模型的输出生成能力，同时通过辅助头实现了高效的早退。总损失是通过将每个退出层的损失相加计算的，权重为1.0。为了进行微调，我们使用了RedPajama（【7，Redpajama: an open dataset for training large language models, 2023】）和Pile（【13，The pile: An 800gb dataset of diverse text for language modeling, 2020】）数据集，共进行了5万次迭代。表7总结了我们评估中使用的模型：

Table 7. 用于评估HELIOS的模型概览。预训练模型允许令牌在任意层退出，而后训练修改模型将退出限制在特定层。

E 额外结果

HELIOS的灵活性。HELIOS是一个统一且灵活的框架，能够为任何用户定义的SLO进行优化。在本节中，我们展示了HELIOS在三个SLO上的有效性：响应时间、准确性和能效。

E.1 响应时间

SLO：最小化响应时间。当用户的目标是最小化响应时间时，我们评估首个令牌生成时间或TTFT（越低越好），如图14所示。TTFT受限于处理请求中所有输入令牌所需的时间。在此期间，不产生任何输出令牌。

结果分析。正如预期的那样，像OPT-6.7B这样的大型模型，其TTFT（69毫秒）比小型的OPT-1.3B模型（43毫秒）要高。相比之下，HELIOS相较于OPT-1.3B和OPT-6.7B，分别实现了1.39倍和2.23倍的TTFT降低。这是可以预料的，因为HELIOS贪婪地只加载最可能被使用的层。在HELIOS中，请求中的每个输入令牌遍历的层数更少，显著减少了处理输入令牌的时间。此外，HELIOS最大化了使用两个模型组合的早退来服务的请求总数。这在图14中对于请求272到542尤为明显，这些请求对应于包含长输入令牌的CNN-Dailymail数据集。对于其中一些请求，由于层遍历减少，HELIOS的性能比OPT-6.7B模型高出多达30倍。


图 14. 使用(a)仅OPT-1.3B、(b)仅OPT-6.7B和(c)HELIOS时的首个令牌生成时间（TTFT）比较（越低越好）。在(c)中，垂直线表示启动候选模型重新评估的时间戳。

E.2 SLO：准确性优化

SLO：最大化准确性。接下来，我们研究当用户的目标是最大化准确性时的场景。图15显示了三种模型选择情况下的困惑度（越低越好）。

结果分析。较大模型（OPT-6.7B）的困惑度比小型模型（OPT-1.3B）低（0.97倍）。这是预期的，因为大型模型通常有更多的参数，使它们能更好地捕捉令牌之间的细微关系并产生更精细的输出。特别是对于长上下文基准测试，当生成大量输出令牌时，众所周知，更大、更复杂的模型（【3，Gpt-4 technical report, 2023, arXiv】;【17，Scaling laws for neural language models, 2020, arXiv】）会优于小型模型。因此，对于对应于CNN Daily Mail（【26，Abstractive text summarization using sequence-to-sequence RNNs and beyond, 2016, Proceedings of the 20th SIGNLL Conference on Computational Natural Language Learning】）的提示集（包含相对较长的上下文输入），HELIOS会实时切换到使用OPT-6.7B，如图15(c)中的1所示，以满足用户的目标SLO。这突显了HELIOS适应各种SLO要求的能力。另一方面，HELIOS后来又恢复使用OPT-1.3B，如图15(c)中的2所示，因为HELIOS评估认为它能以更节能的方式（用更少的层和减少的计算足迹）提供与OPT-6.7B相当的准确性。


图 15. 使用(a)仅OPT-1.3B、(b)仅OPT-6.7B和(c)HELIOS时的困惑度（准确性）比较（越低越好）。垂直线表示启动候选模型重新评估的时间步。

E.3 SLO：能效优化

SLO：最大化能效。我们简要讨论当用户希望最大化能效或最小化每个提示的能耗时的场景。

结果分析。仅使用OPT-6.7B模型，每个提示消耗1.01瓦时（Wh）的能量，这符合预期，因为它是一个比OPT-1.3B（每个提示消耗0.50 Wh）更大的模型。相比之下，HELIOS每个提示消耗0.45 Wh的能量，这意味着在可比的困惑度下，实现了10%的节能。在HELIOS中，58.3%的提示是使用部分加载的模型服务的，这带来了所观察到的节能效果。需要注意的是，节省的能量会随着处理的提示总数而增加。在实践中，数据中心的生产服务器每天处理数千万个提示（【38，A survey on chatgpt: Ai-generated contents, challenges, and solutions, 2023, IEEE Open Journal of the Computer Society】），这凸显了HELIOS的影响。我们还观察到，与切换相关的能量开销很小，仅占所实现的总节能（10%）的0.05倍。