INFERCEPT: Efficient Intercept Support for Augmented Large Language Model Inference

发表时间: 2024-02 · ICML 2024 · arXiv:2402.01869 (UC San Diego)

原文: https://arxiv.org/abs/2402.01869

Reyna Abhyankar * 1 Zijian He * 1 Vikranth Srivatsa 1 Hao Zhang 1 Yiying Zhang 1

A1 主要贡献

大语言模型（LLMs）正越来越多地与外部环境、工具和代理（如ChatGPT插件）集成，以将其能力扩展到以语言为中心的任务之外。然而，当前的LLM推理系统是为独立的LLM设计的。它们将每次外部交互视为LLM生成的结束，并在交互完成时形成一个新的请求，这导致了对已计算上下文的不必要重计算，该重计算占用了总模型前向传播时间的$37\%-40\%$。

为了解决这一问题，本文提出了INFERCEPT，这是第一个针对增强型LLM并支持高效拦截LLM生成的推理框架。INFERCEPT的核心目标是最小化由LLM拦截引起的GPU资源浪费，并将节省的内存专用于服务更多请求。通过其独特的设计，与最先进的LLM推理系统相比，INFERCEPT将整体服务吞吐量提高了$1.6\times-2\times$，并且每秒完成的请求数增加了$2\times$。

A3 背景知识/关键Observation/设计原则

增强型LLM框架。为了扩展LLM处理更多类型任务的能力，目前提出了不同的方法将LLM与各种外部实体进行增强【Mialon 等人，Augmented language models: a survey，2023，TMLR，URL: https://openreview.net/forum?id=jh7wH2AzKK】。第一种增强类型涉及在LLM解码阶段调用的非LLM工具，通常旨在扩展LLM可以处理的任务类型。这些工具范围从计算器【Wolfram ，Chatgpt gets its ‘wolfram superpowers’!，2023】和日历等简单工具，到信息检索【Baeza-Yates 等人，Modern Information Retrieval，1999，ACM】和餐厅预订【OpenTable，New: Chatgpt restaurant recs, powered by opentable，2023】等现实世界的交互。工具增强也可以是另一个机器学习模型，例如翻译【Costa-jussa 等人，No language left behind: Scaling human-centered machine translation，2022，arXiv】和问答（QA）【Izacard 等人，Atlas: Few-shot learning with retrieval augmented language models，2022】。先前的研究【Parisi 等人，Talm: Tool augmented language models，2022，arXiv】、【Hao 等人，Toolkengpt: Augmenting frozen language models with massive tools via tool embeddings，2023，NeurIPS】、【Schick 等人，Toolformer: Language models can teach themselves to use tools，2023，NeurIPS】表明，微调LLM以在解码阶段自动生成适当的工具调用是有效的。除了微调之外，另一种方法是指导LLM为用户任务选择工具或模型【Shen 等人，HuggingGPT: Solving AI tasks with chatGPT and its friends in hugging face，2023，NeurIPS】、【Lu 等人，Chameleon: Plug-and-play compositional reasoning with large language models，2023，NeurIPS】。

多轮调用增强。第二种类型通过对同一个LLM进行一系列调用来增强LLM的单次触发。例如，为了持续与人类交互，聊天机器人可以在每一步调用LLM并维护聊天历史记录来进行多轮来回对话【Greyling，When using the chatgpt api, users will have to manage the context，2023】。另一个流行的用例是将复杂任务分解为多个步骤。例如，思维链（Chain-of-Thought）【Wei 等人，Chain-of-thought prompting elicits reasoning in large language models，2023，NeurIPS】、【Zhang 等人，Automatic chain of thought prompting in large language models，2023，ICLR】将一个请求分解为一系列“思考”步骤，每一步都是对LLM的新提示，以延续思考的历史。类似地，ReAct【Yao 等人，React: Synergizing reasoning and acting in language models，2023，ICLR】使用一系列推理和行动步骤来完成复杂的任务。

复杂组合增强。第三种类型允许LLM、其他模型和工具进行更复杂的组合。像LangChain【Chase，LangChain，2022】、DSpy【Khattab 等人，DSPy: Compiling declarative language model calls into state-of-the-art pipelines，2024，ICLR，URL: https://openreview.net/forum?id=sY5N0zY5Od】、Gorilla 【Patil 等人，Gorilla: Large language model connected with massive apis，2023，arXiv】、SGLang【Zheng 等人，Efficiently programming large language models using sglang，2023，arXiv】和AgentGraph【Chen 等人，Agentgraph: Towards universal dialogue management with structured deep reinforcement learning，2019，arXiv】等框架为用户提供了编程模型，以编写他们自己的增强型LLM流程。其他研究工作则使LLM能够生成增强型LLM的组合【Suris 等人，Vipergpt: Visual inference via python execution for reasoning，2023，ICCV，URL: https://doi.ieeecomputersociety.org/10.1109/ICCV51070.2023.01092】、 【Qian 等人，CREATOR: Tool creation for disentangling abstract and concrete reasoning of large language models，2023，EMNLP，URL: https://aclanthology.org/2023.findings-emnlp.462】 。

Table 1: 拦截属性。每个单元格显示该增强方式的(均值, 方差)。* 估计行为。† 部分估计。

Type	Int Time (sec)	Num Interceptions	Context Len
Math	(9e-5, 6e-5)	(3.75, 1.3)	(1422, 738)
QA	(0.69, 0.17)	(2.52, 1.73)	(1846, 428)
VE	(0.09, 0.014)	(28.18, 15.2)	(2185, 115)
Chatbot	(28.6,15.6)*	(4.45,1.96)	(753, 703)
Image	(20.03, 7.8)†	(6.91,3.93)*	(1247,792)
TTS	(17.24,7.6)†	(6.91,3.93)*	(1251,792)

算术（Math）拦截属性。为了解决复杂的数学问题，LLM可以被增强以解构问题并逐步调用计算器工具。我们使用GSM8K-XL【Hao 等人，Toolkengpt: Augmenting frozen language models with massive tools via tool embeddings，2023，NeurIPS】数据集评估此用例，该数据集包含$8.5\mathrm{K}$个高质量的小学数学问题。正如预期的那样，计算器的执行时间很短，平均为$0.2\ \mathrm{ms}$。由于我们必须通过逐步解决问题的演示来提示LLM，因此在调用计算器时它具有相当大的上下文长度。

基于知识的问答（QA）拦截属性。为了允许预训练的LLM访问更广泛的知识集，可以增强LLM以调用基于知识的QA工具，这些工具从丰富的数据集中检索信息。我们使用Multihop QA Wikipedia【Yang 等人，Hotpotqa: A dataset for diverse, explainable multi-hop question answering，2018，arXiv】数据集来评估此用例。虽然问题的上下文长度较长，但由于与Wikipedia的非确定性网络通信延迟，这些QA工具提供了相对较快但可变的执行时间。

虚拟环境（VE）拦截属性。LLM可以被增强以与虚拟环境交互，并通过执行渐进步骤来完成复杂任务【Gu 等人，Vision-and-language navigation: A survey of tasks, methods, and future directions，2022，ACL】、【Huang 等人，Language models as zero-shot planners: Extracting actionable knowledge for embodied agents，2022，ICML】、【Hu 等人，Look before you leap: Unveiling the power of gpt4v in robotic vision-language planning，2023，arXiv】。为了评估VE，我们使用ALFWorld数据集【Shridhar 等人，Alfworld: Aligning text and embodied environments for interactive learning，2021，ICLR】，这是一个交互式环境，将文本描述和命令与物理具身的机器人模拟对齐。由于是本地执行且具身的基于文本的环境，VE交互具有短暂且稳定的拦截时间。由于提示LLM理解VE动作序列所需的指令，上下文长度很长。

聊天机器人（Chatbot）拦截属性。LLM的一个流行任务是聊天机器人，它通过一系列聊天与人类互动。当人类收到LLM的聊天响应时，LLM生成序列本质上被拦截。当人类发送后续聊天消息时，LLM生成恢复。在此过程中，必须保留聊天历史记录作为整个聊天序列的上下文。我们使用ShareGPT数据集【Zheng 等人，Judging LLM-as-a-judge with MT-bench and chatbot arena，2023，NeurIPS】，该数据集包含众包的真实用户ChatGPT对话，以评估聊天机器人。我们将人类响应时间（即拦截时间）估计为人类扫描先前聊天响应的时间【Brysbaert，How many words do we read per minute? a review and meta-analysis of reading rate，2019，Journal of memory and language】和键入下一个提示的时间【Ma 等人，Haptic keyclick feedback improves typing speed and reduces typing errors on a flat keyboard，2015，WHC】的总和。由于人类提示的多样性，上下文长度差异很大。其拦截时间也具有很高的方差。

图像生成（Image generation）拦截属性。LLM可以被增强以生成图像或一系列图像，当人类通过多个提示逐步细化特征（例如，向面部描绘添加细节）时。这涉及两次拦截：一次用于触发图像生成模型，另一次用于接收用户的后续提示。为了理解这个用例，我们使用ChatGPT创建了一个数据集，通过生成一系列图像生成提示，每个提示都会触发对Stable Diffusion模型【Rombach 等人，High-resolution image synthesis with latent diffusion models，2021，arXiv】的调用。由于执行扩散模型的变化和人类响应时间的变化，该工作负载的拦截时间具有很高的变化。由于输入到扩散模型的提示较小，平均上下文长度短于聊天机器人拦截。

文本转语音（TTS）拦截属性。正如ChatGPT Whisper API支持【Brockman 等人，Introducing chatgpt and whisper apis，2023】所展示的那样，TTS可以与LLM集成以与人类交流。与我们的图像生成数据集类似，我们使用ChatGPT生成一系列提示，每个提示都会触发对Bark TTS模型【AI，Bark: Text-to-speech model，2023】的调用。与图像生成类似，我们估计人类响应时间，但测量实际的TTS执行时间。由于模型执行时间和用户响应时间的变化，TTS的行为在拦截时间上也具有很高的变化。

总结与见解。总体而言，我们发现LLM拦截时间高度依赖于增强类型，并且在短期运行（Math、QA、VE）和长期运行（Chatbot、Image、TTS）之间表现出明显的差异。短期运行的增强是完全自动化的，没有人工干预。大多数还表现出较小的变化（除了与网络交互的QA）。涉及人类交互和/或调用另一个大型模型的增强是长期运行的，具有很高的变化。短期/长期的拦截时间及其变化意味着没有单一的LLM拦截策略普遍适用，但推理系统可以利用增强类型作为拦截时间的提示。所有增强的上下文长度都很大，这意味着潜在的GPU内存浪费很高。上下文长度也存在很大的变化，这使在运行时处理它们变得复杂。

LLM推理系统的调度策略。近年涌现了专门为LLM设计的推理系统。与INFERCEPT不同，现有的推理系统都不是为处理拦截而设计的，并且都面临性能未优化的问题。一些工作旨在通过更好的调度策略来提高整体推理吞吐量。例如，Orca【Yu 等人，Orca: A Distributed Serving System for TransformerBased Generative Models，2022，OSDI】提出了迭代级调度，其中在每次模型前向传递结束时，调用Orca的调度程序以形成下一次前向传递的新批次。这种迭代级调度策略提高了GPU利用率，从而提高了推理吞吐量。INFERCEPT也采用了迭代级调度，但采用了一种独特且新颖的调度策略——在每次迭代中，INFERCEPT根据请求的拦截属性做出决定，以最小化在该迭代中被拦截或恢复的请求的GPU内存浪费。除了Orca等人使用的FCFS（先到先得）之外，还提出了其他请求调度策略，例如FastServe【Wu 等人，Fast distributed inference serving for large language models，2023，arXiv】中的多级反馈队列。我们将这些调度策略的比较留给未来的工作。

GPU内存优化系统。另一个优化目标是GPU内存使用。vLLM【Kwon 等人，Efficient memory management for large language model serving with pagedattention，2023，SOSP】提出了分页注意力的概念，其中KV缓存被视为可以映射到非连续物理GPU内存的虚拟内存。由于虚拟内存的灵活性，vLLM实现了更好的GPU内存利用率，从而提高了整体推理性能。INFERCEPT也利用分页注意力来有效使用GPU物理内存。与对拦截不可知的vLLM不同，INFERCEPT自适应地保留、丢弃或交换被拦截请求的KV缓存，以最小化内存浪费。其他内存效率技术，如SGLang【Zheng 等人，Efficiently programming large language models using sglang，2023，arXiv】和Preble【Srivatsa 等人，Preble: Efficient distributed prompt scheduling for llm serving，2024，UCSD CSE Technical Reports】中的前缀共享是正交的，可以添加到INFERCEPT中。

Prefill与Decoding阶段优化系统。还有一组LLM推理系统专注于预填充（prefill）和解码（decoding）阶段之间不平衡的计算需求。Sarathi【Agrawal 等人，Sarathi: Efficient llm inference by piggybacking decodes with chunked prefills，2023，arXiv】是一个提出分块预填充技术的系统，该技术将提示标记分成块，每个块与其他解码请求合并以形成一个迭代的批次。INFERCEPT的分块将序列拆分以进行重计算和交换，从而充分利用GPU和GPU-CPU链路资源，同时最大限度地减少内存浪费。其他关于预填充解码优化的提案，如DistServe【Zhong 等人，Distllm: Disaggregating prefill and decoding for goodput-optimized large language model serving，2024，OSDI】是正交的，并且有可能被添加到INFERCEPT中。

基于丢弃（Discard）的方法局限性。当今的LLM推理系统并非为增强型LLM设计。为了服务带有增强的LLM，这样的系统需要将拦截视为请求的结束，并在拦截完成时重新发起请求。由于当今的推理系统使用FCFS调度策略，它们将这些重新发起的请求安排在等待队列的末尾，并使恢复的请求挨饿。解决这个调度问题的一个简单方法是在将被拦截的请求重新插入等待队列时使用其原始到达时间（我们将此方案称为ImprovedDiscard）。

丢弃策略的内存浪费计算。Discard和ImprovedDiscard都需要重新计算所有上下文标记，并从两个来源产生GPU内存浪费。首先，重计算消耗的内存不用于产生任何新标记。假设请求$i$在发生拦截$j$时的上下文有$C_i^j$个标记，每个标记的KV缓存占用$M$的内存，重计算需要$T_{fwd}(C_i^j)$时间，其中$T_{fwd}$是从批处理中调度的标记数量到该迭代执行时间的映射。用于重计算的内存浪费为$T_{fwd}(C_i^j) \times C_i^j \times M$。其次，重新计算上下文增加了迭代时间，因为迭代现在需要在其他正在运行的请求的模型前向传播旁边完成所有重计算。其他正在运行的请求所占用的内存在额外的迭代时间$T_{fwd}(C_i^j)$期间被浪费。因此，由于这个原因造成的内存浪费为$T_{fwd}(C_i^j) \times C_{other} \times M$，其中$C_{other}$是其他请求上下文的总和。Discard和ImprovedDiscard的总内存浪费为：

$$\begin{aligned} \begin{array} { l } { { \mathrm { WasteDiscard } _ { i } ^ { j } = T _ { fwd } ( C _ { i } ^ { j } ) \times C _ { i } ^ { j } \times M } } \\ { { \qquad + T _ { fwd } ( C _ { i } ^ { j } ) \times C _ { other } \times M } } \end{array} \end{aligned}$$

在实践中，我们的评估表明，Discard会导致$27\%$的GPU资源浪费（$\mathrm{GB*min}$），并且在包含所有六种增强的混合工作负载中，$37\%-40\%$的总模型前向传递时间花在了重计算上。

基于保留（Preserve）的方法局限性。可以不丢弃，而是在发生拦截时保留请求的上下文。这种Preserve策略避免了重计算成本，并且可以在拦截完成时立即恢复请求。然而，当请求保持暂停时，保留的上下文会浪费GPU内存。请求$i$在发生拦截$j$时的保留浪费是该拦截的持续时间$T_{INT}^j$乘以请求上下文所持有的GPU内存量。

$$ \mathrm { WastePreserve } _ { i } ^ { j } = T _ { INT } ^ { j } \times C _ { i } \times M $$

我们在真实拦截中测量的GPU内存浪费高得惊人：超过$60\%$的时间里，近一半的GPU内存被中断的请求占用。

基于交换（Swap）的方法局限性。为了避免Discard中的重计算开销和Preserve中的内存浪费，一种潜在的技术是在发生拦截时将所有上下文数据从GPU交换到CPU内存，并在拦截结束时将其交换回GPU。Swap的直接实现以同步方式执行交换，通过启动CUDA内核移出/移入数据并让计算利用相关的内存空间。由于要移动的数据量和要启动的内核，具有巨大上下文的交换可能需要极长的时间。详细说明后者，需要启动多个内核，每个内核对应一个不连续的物理内存区域。使用PagedAttention【Kwon 等人，Efficient memory management for large language model serving with pagedattention，2023，SOSP】，被拦截请求的上下文可以分散在许多物理内存区域中，导致高昂的内核启动开销。

交换策略的内存浪费计算。像Discard一样，Swap从两个来源产生内存浪费。首先，被交换的内存空间在交换期间被浪费，占$T_{swap}(C_i^j) \times C_i^j \times M$，其中$T_{swap}$是从要交换的标记数量到相应交换延迟的映射。其次，Swap可能会增加迭代时间，导致所有正在运行的请求等待交换完成而什么都不做。这种浪费是$T_{swap}(C_i^j) \times C_{other} \times M$。考虑到换入和换出，总浪费翻倍：

$$ \mathrm { WasteSwap } _ { i } ^ { j } = 2 \times T _ { swap } ( C _ { i } ^ { j } ) \times C _ { batch } \times M $$

我们的评估表明，Swap浪费了$26\%$的GPU资源，超过$25\%$的总工作负载时间花在了等待混合工作负载的交换上。

A2 方法细节

交换流水线与重叠（Swap pipelining and overlapping）。Swap以串行方式执行交换，并在整个交换时间内阻塞前台计算。为了缓解这个问题，我们提出以流水线方式和在后台执行交换。具体来说，INFERCEPT将每个模型层的交换视为一个流水线阶段，并将内核启动、数据移动和前台模型前向传递进行流水线化。例如，当我们为第$i + 2$层启动交换内核时，我们移动第$i + 1$层的上下文，并且第$i$层的上下文已被释放并用于正常前向传播。

交换分块（Swap chunking）。为了进一步减少内存浪费，我们提出在多个迭代中对换出和换入进行分块，以便在每次迭代中，交换延迟可以通过与模型前向传递重叠来隐藏。我们通过离线分析获得$T_{fwd}$，并根据交换带宽和每个标记的内存需求$M$计算$T_{swap}$。在批大小为$B_i$的第$i$次迭代中，我们设置$T_{swap}(N_i) = T_{fwd}(B_i)$并计算$N_i$。$N_i$（我们称之为交换限制）表示可以免费交换（即隐藏在模型前向传递后面）的标记数。

确定换入和换出预算（Determining swap-in and swap-out budget）。在每次迭代中，都可能有等待换出和换入的标记。INFERCEPT通过最大化推理吞吐量（即可以添加到迭代处理中的标记数）来决定在每次迭代中给换出和换入分配多少带宽，同时保证以下标准：1）换入和换出标记的总量最多应为$N_i$；2）换出的内存量不应超过可用CPU内存加上换入内存的量；3）换入的内存量和新调度标记的内存量（即我们的最大化目标）不应超过换出的内存量和可用GPU内存的量。我们在决定请求拦截调度时使用获得的换入和换出预算。

解码与重计算的资源互补性。与Swap不同，Swap消耗GPU-CPU链路带宽，并且可以从前台GPU任务中隐藏，而被丢弃标记的重计算需要无法避免的GPU资源。然而，我们观察到解码和重计算具有互补的资源需求，对于相同数量的内存，解码所需的GPU核心资源（对于一个查询标记）比重计算（对整个上下文长度的查询）少。因此，一批解码请求通常在耗尽GPU内存之前无法填满所有GPU核心。混合解码和重计算请求可以在保持在其内存边界内的同时提高GPU核心利用率。主要的挑战是混合多少重计算和解码。

自适应重计算分块机制。Discard和ImprovedDiscard要求在一个迭代中重新计算整个请求。长上下文的重计算会增加超出GPU处理能力的计算负担，导致迭代时间显著增加。结果，较长的$T_{fwd}(C_i^j)$导致方程1中巨大的WasteDiscard。为了缓解这个问题，我们提出了一种自适应技术，将上下文序列的重计算分成多个块，每个块添加到一个迭代中，而不会超出GPU所能承受的范围。我们观察到，对于给定的模型架构，所有GPU核心可以并行处理的查询标记数量是有限且固定的。我们将此数字称为GPU饱和点$S$，表示为查询标记数。处理超过$S$的更多查询标记会增加迭代时间，而不会提高服务吞吐量。INFERCEPT从离线分析中获取$S$，并将块大小设置为$S$减去运行组大小。

分块重计算的内存浪费计算。我们的分块重计算机制的内存浪费可以分两部分计算，类似于方程1。对于重计算本身，我们在每次迭代中添加一块内存浪费，直到所有块都被重新计算完毕，这基本上将Discard的一次性全部重计算方案的浪费减少了一半，即$T_{fwd}(C_i^j) \times C_i^j \times M / 2$，如图1所示。浪费的第二部分来自重计算增加的迭代时间内其他请求占用的内存。这种浪费总计为$n \times T_{fwd}(\frac{C_i^j}{n}) \times C_{other} \times M$，其中$n$是完成重新计算请求的迭代次数，$T_{fwd}(\frac{C_i^j}{n})$是每个块增加的迭代时间。将这两部分相加，我们将分块重计算的总重计算内存浪费得出为：

$$\begin{aligned} \begin{array} { l } { { \mathrm { WasteChunkD } _ { i } ^ { j } = \displaystyle \frac { T _ { fwd } ( C _ { i } ^ { j } ) \times C _ { i } ^ { j } \times M } { 2 } } } \\ { { \displaystyle ~ + n \times T _ { fwd } ( \frac { C _ { i } ^ { j } } { n } ) \times C _ { other } \times M } } \end{array} \end{aligned}$$

分块重计算的优势。与方程1相比，左侧项（重计算本身）将Discard的相应项减少了一半，而右侧项（其他请求）不大于Discard的右侧项，因为$n \times T_{fwd}(\frac{C_i^j}{n}) \leq T_{fwd}(C_i^j)$。同时，INFERCEPT提高了GPU核心利用率，并进一步提高了整体服务吞吐量。

调度被拦截的请求。我们现在讨论INFERCEPT在综合考虑多个请求时，如何使用保留、我们改进的交换和我们改进的丢弃的混合方式来调度被拦截的请求。首先，对于遇到拦截$j$的每个请求$i$，我们计算其内存浪费为WastePreserve（方程2）和WasteChunkDiscard（方程4）中的最小值：

$$ \mathrm { Waste } _ { i } ^ { j } = \mathbf { min } ( \mathrm { WastePreserve } _ { i } ^ { j } , \mathrm { WasteChunkD } _ { i } ^ { j } ) $$

接下来，我们根据所有被拦截请求的内存浪费对它们进行降序排序。我们根据此顺序从这些请求中换出上下文，直到我们用尽换出预算。对于剩余的暂停请求，我们根据方程5的决定保留或丢弃它们剩余的上下文。

调度恢复的请求和其他等待的请求。在每次迭代开始时，INFERCEPT确定将哪些请求插入该迭代的批次中。为了促进此决策，INFERCEPT维护三个队列：一个运行队列，包含系统中当前正在运行的请求；一个交换队列，包含已恢复但之前在拦截期间被换出的请求；以及一个等待队列。等待队列包含已恢复的丢弃请求、INFERCEPT收到的从未被服务过的新请求，以及由于缺乏GPU资源而被驱逐的先前运行的请求。后两种类型与当今的推理系统相同。每个队列根据其请求的原始到达时间进行排序。

迭代调度执行逻辑。在每次迭代中，我们以FCFS（先到先得）顺序从等待队列中选择请求，直到达到GPU饱和点；FCFS确保公平并避免饥饿。选择的请求可以是上述三种等待类型中的任何一种。如果是被丢弃的请求，则该迭代将执行已调度数量标记的重计算。如果此请求仅被部分重新计算，它将与剩余标记一起留在等待队列中。在每次迭代中，我们还以FCFS顺序从交换队列中选择请求，直到达到换入预算。我们维护并调度一个单独的交换队列，因为换入预算是GPU资源的附加项，应始终在预算允许的范围内被恢复的请求尽可能多地利用。

动态估算拦截持续时间。计算保留上下文的内存浪费（方程2）需要拦截持续时间。对于持续时间高度可变或未进行离线分析的拦截，我们提出了一种动态估算方法，通过设置$\hat{T}_{INT} = t_{now} - t_{call}$，其中$t_{now}$是每次迭代更新的当前时间，$t_{call}$是上次启动拦截的时间。实际上，请求被拦截的时间越长，估计的拦截时间就越大。我们的评估表明，在混合工作负载中，使用此估算方法的INFERCEPT与使用提供精确拦截持续时间的oracle相比，实现了$93\%$的性能。

系统实现。INFERCEPT包含四个关键组件：调度策略、浪费计算、分块重计算和交换，以及多样化的增强支持。我们在vLLM【Kwon 等人，Efficient memory management for large language model serving with pagedattention，2023，SOSP】之上实现INFERCEPT，以利用其PagedAttention技术进行常规LLM内存管理。我们的大多数技术都是高度模块化的，并且与为非拦截LLM设计的优化正交。因此，INFERCEPT有可能集成到其他LLM服务系统中，如DeepSpeed【Aminabadi 等人，Deepspeed-inference: enabling efficient inference of transformer models at unprecedented scale，2022，SC22】、Orca【Yu 等人，Orca: A Distributed Serving System for TransformerBased Generative Models，2022，OSDI】和TensorRT-LLM【Vaidya 等人，Nvidia tensorrt-llm supercharges large language model inference on nvidia h100 gpus，2023】。

A4 实验环境

• 数据集与工作负载：使用混合工作负载，统一从六种增强（Math, QA, VE, Chatbot, Image, TTS）中采样请求。此外，针对QA和Chatbot评估了单增强工作负载。
• 模型架构关键参数：评估了6B参数的GPT-J模型、13B的Vicuna模型和70B的Llama3模型。

• 硬件配置：

  • GPT-J-6B：运行在单张 NVIDIA A100 GPU 上。
  • Vicuna-13B：运行在单张 A100 GPU 以及具有张量并行（tensor parallelism）的两张 A100 GPU 上。
  • Llama3-70B：通过张量并行分布在四张 A100 GPU 上。

• 软件配置：在vLLM基础上实现，对比基线包括原始vLLM（Discard）、ImprovedDiscard、Preserve和Swap。

A5 实验结果

端到端性能（混合工作负载）。我们首先比较了INFERCEPT和基线的端到端性能。指标包括归一化延迟（即每个请求的端到端延迟的中位数除以其输出长度）、吞吐量（每秒完成的请求数）以及到达首个生成标记的时间（TTFT）。从请求的端到端延迟中去除了拦截时间，因为它在所有系统中都是相同的。图2展示了在所有三个模型上的结果。
* 6B模型结果：INFERCEPT在所有指标上均优于基线。在相同的归一化延迟下，INFERCEPT比vLLM维持高出达$1.6\times$的请求到达率。在相同的请求率下，INFERCEPT的归一化延迟比vLLM低$1.9\times-5.7\times$。INFERCEPT以最小的TTFT服务比vLLM高$1.7\times$的请求到达率。INFERCEPT消除了超过$60\%$由重计算引起的GPU浪费和$96\%$的交换GPU浪费。原始vLLM遭受高昂的重计算浪费和调度恢复请求的延迟。ImprovedDiscard保持了请求的原始到达时间，但仍有重计算开销。Preserve在基线中表现最好，但由于INFERCEPT的动态最小浪费调度和改进的交换与重计算，仍不及INFERCEPT。Swap的整体结果与ImprovedDiscard相似。
* 13B模型结果：在单GPU上运行时，INFERCEPT在归一化延迟方面优于所有基线，但改进幅度小于6B模型，因为较大模型的权重占用了更多内存。尽管如此，我们可以在没有明显增加归一化延迟的情况下服务高出达$1.25\times$的请求率。在两张GPU分布式执行环境下，INFERCEPT比vLLM服务高出达$1.8\times$的请求到达率，归一化延迟改善了$1.6\times-10\times$。
* 70B模型结果：对于Llama3-70B，INFERCEPT在相同RPS下可维持$2\times$的请求到达率，并实现$1.3\times-12\times$的更低归一化延迟。在相同TTFT下，负载能力比vLLM高$2.4\times$。随着模型尺寸的增加，vLLM和ImprovedDiscard都经历了显著的重计算成本。相比之下，由于分组查询注意力（GQA）压缩了注意力KV，Preserve和Swap表现更好，但INFERCEPT通过特定请求的最佳抢占决策提供了更多好处。

单增强工作负载。除了混合工作负载外，我们在QA和Chatbot两个单一API工作负载上评估了INFERCEPT。在归一化延迟方面，INFERCEPT在QA和Chatbot上分别比vLLM高出达$2.3\times$和$1.9\times$。INFERCEPT在QA上的改进更大，因为大多数QA API调用很短，使用保留时的浪费小于丢弃。

性能深度剖析（消融实验）。为了进一步理解INFERCEPT的优势，我们通过将技术逐一添加到原始vLLM中来进行分解。使用混合工作负载，我们在图3中报告了6B模型在每秒2个请求的负载下的归一化延迟和GPU内存浪费。
首先，我们通过像ImprovedDiscard那样保持请求的原始到达时间来改进Discard（原始vLLM），这使归一化延迟减少了$24.5\%$。然后，我们添加了INFERCEPT的重计算分块，带来了额外的$7.8\%$改进。接下来，我们添加了INFERCEPT的预算交换，带来了$12.7\%$的附加改进。然后，我们添加了保留（Preserve）并使用简单的启发式方法：长运行拦截使用丢弃，短运行拦截使用保留。这一添加带来了$46.1\%$的改进。最后，添加基于最小浪费的自适应调度（即完整的INFERCEPT）带来了额外的$46.4\%$改进。完整的INFERCEPT仅有$0.69\%$的浪费，证明了最小浪费抢占原则的有效性。

A6 结论

我们引入了INFERCEPT，这是一个针对推理期间拦截进行优化的LLM推理框架。通过将最小化GPU内存浪费作为统一目标，与最先进的推理系统相比，INFERCEPT提供了$1.6\times-2\times$的更高请求到达率，并实现了$1.3\times-12\times$的更低归一化延迟。

A7 附录

API属性与数据集生成。我们分析了不同数据集的属性以评估我们推理系统的有效性。我们测量了API执行时间、API调用次数、API调用返回的标记数以及调用API时的上下文长度。图4和图5分别展示了短期运行API（Math, QA, VE）和长期运行API（Chatbot, Image, TTS）的详细CDF结果。
* QA：我们使用ReAct框架提示LLM调用维基百科端点，并对响应进行后处理以适应最大模型序列长度。
* VE：我们使用初始虚拟环境提示GPT-4 LLM，并使用ReAct事件循环与环境交互，进行截断以适应上下文长度。
* Image：我们提示GPT-4生成复杂的Stable Diffusion提示，每次提示触发API调用。调用总数模拟聊天数据集。我们将图像生成轮数估计为与Chatbot中的聊天轮数相同。由于没有标准方法返回标记，我们使用描述生成图像的简短定长句子作为返回标记。
* TTS：我们使用与图像生成类似的方法来理解TTS增强的LLM。

系统架构实施细节。我们在vLLM之上实现了INFERCEPT。如图6所示，INFERCEPT包括一个执行不同API调用的API执行器、一个形成等待请求和暂停请求批次的迭代级调度器、一个促进GPU/CPU内存交换的交换管理器、一个监视运行请求状态的运行状态监视器、一个计算GPU内存浪费的浪费估计器，以及一个收集基本系统指标的离线分析器。

每次迭代结束时的处理流程。在每次迭代结束时，调度器收集所有触发API调用的请求，将它们添加到暂停请求队列中，尽可能多地将暂停请求的上下文交换到CPU内存，根据浪费估计器计算的GPU内存浪费量决定是保留还是丢弃每个暂停请求的剩余上下文，并调用实际的API。当API调用完成时，INFERCEPT确定在下一次迭代中要换入或重新计算多少换出或丢弃的标记。它还确定在下一次迭代中调度多少等待请求（非API暂停请求）。当暂停请求的所有上下文都已恢复时，INFERCEPT将API调用返回的标记添加到恢复的请求中。