文章标题：Weaver: 通过注意力卸载实现高效的多LLM服务
作者/机构：Shiwei Gao, Qing Wang, Shaoxun Zeng, Youyou Lu and Jiwu Shu∗, Tsinghua University

A1 主要贡献

本文旨在解决多大型语言模型（Multi-LLM）服务场景中存在的效率问题。在此类场景中，通常存在请求分布不均的现象：少数“热门”模型处理绝大多数请求，而大量“冷门”模型则很少被访问。

核心问题：
现有的LLM服务系统无法高效处理这种访问模式倾斜的工作负载。
1. 专用实例（Dedicated instances）：为热门和冷门模型分配独立的GPU实例，会导致冷门模型上的GPU内存利用率低下。
2. 多路复用（Multiplexing）：通过模型并行（Model Parallelism）在热门和冷门模型间共享GPU，虽然能提高GPU利用率，但会引入不可忽视的通信开销，影响整体性能。

研究目标：
本文提出一种名为“工作负载编织”（Workload Weaving）的机制，旨在充分利用冷门模型实例上未被充分利用的GPU内存，以提高热门模型的吞吐量，同时保持较低的通信成本。

创新点/主要贡献：
为实现高效的“工作负载编织”，本文设计并实现了多LLM服务系统WEAVER，其核心贡献在于提出了两种关键技术来克服注意力操作卸载到繁忙的冷门模型实例时遇到的行头阻塞（Head-of-Line Blocking）问题：
1. GPU驱动的动态控制流（GPU-driven dynamic control flow）：将卸载操作的控制逻辑从CPU转移到GPU。冷门实例的GPU通过轮询共享内存中的任务来发现并立即执行卸载的注意力算子，从而绕过GPU硬件队列中预先提交的其他内核（kernels），避免了因预提交内核导致的阻塞。
2. 算子拆分（Operator splitting）：将冷门模型中的大型、长时间运行的内核拆分成更小的内核。这样可以确保卸载的注意力算子能在有限时间内获得GPU执行机会，减轻了因长时间运行内核导致的阻塞。为了最小化内核拆分带来的碎片化开销，WEAVER采用了一种基于排队论分析的优先级算法来制定拆分计划。

通过这两项技术，WEAVER确保被卸载的注意力算子最多只需等待一个小的正在运行的内核完成，从而保证了卸载效率。实验评估表明，WEAVER能显著提升热门模型的吞吐量（高达77%），同时对冷门模型的性能影响很小（平均TPOT增加3-5ms）。

A3 背景知识与关键观察

2.1 LLM服务中的算子

LLM服务的算子构成。由于Transformer的独特架构，LLM服务主要涉及两种类型的算子：参数化的投影（Projection）算子和非参数化的注意力（Attention）算子。

投影算子（Projection operators）：这些算子包括全连接前馈网络（FFNs）和特定的线性变换，例如多头注意力机制中的查询（query）、键（key）、值（value）和输出投影。作为参数化组件，它们依赖一组固定的、学习好的参数来处理输入token或其中间表示。
注意力算子（Attention operators）：注意力算子动态地计算输入token之间的关系以捕捉上下文依赖。与投影算子不同，注意力机制是非参数化的。因此，注意力计算不需要模型参数，而是依赖于先前token的KV张量。这些KV张量通常以KV缓存的形式保存，以避免在未来token生成中重复计算。

2.2 多LLM服务

多LLM服务的兴起与特点。大型语言模型（LLM）已在各行业普及，推动了快速的创新和应用。因此，可用的LLM种类迅速增长，LLM服务平台现在通常托管数十到数百个LLM，呈现出向多LLM服务的范式转变。例如，模型即服务（MaaS）平台，如Hugging Face【5，Huggingface Serverless Inference API，2024，Website】、Together.ai【11，Together AI – The AI Acceleration Cloud，2024，Website】和OpenRouter【9，Openrouter: A unified interface for llms，2024，Website】，提供广泛的模型服务，满足用户不同的需求和用例。即使是单一模型提供商，如OpenAI【8，OpenAI API reference，2024，Website】和Gemini【3，Gemini API versions explained，2024，Website】，也托管了一系列具有不同能力、模型大小和发布版本的模型家族，使用户能够为其特定任务选择最合适的模型：仅OpenAI就为其聊天家族LLM的20多个变体提供了API【8，OpenAI API reference，2024，Website】。

访问模式的倾斜性。多LLM服务系统具有倾斜的访问模式【17，MuxServe: Flexible Spatial-Temporal Multiplexing for Multiple LLM Serving，2024，Forty-first International Conference on Machine Learning】。我们分析了一个流行的MaaS平台OpenRouter【9，Openrouter: A unified interface for llms，2024，Website】为期一周的多LLM服务统计数据，其中包括209个模型和超过2000亿个token。图1显示了请求token的累积分布函数（CDF）：排名前5%的模型消耗了74.8%的token，呈现出倾斜分布。换言之，在多LLM服务中，一小部分热门模型（例如Llama-3或OpenAI的最新版本）接收了大部分流量，但许多模型是冷门的，使用稀疏；它们在大多数时间接收到低但持续的请求率。

2.3 现有方法及其局限性

现有方法无法高效处理混合工作负载。通过分析和实验，我们发现现有方法无法高效处理混合了热门和冷门模型的工作负载，这是多LLM服务的一个显著特征（§2.2）。

使用专用实例：该方法为热门和冷门模型分别使用专用的实例。例如，服务提供商可以在专用GPU上部署热门模型【10，Together AI – Dedicated models，2024，Website】，同时为冷门模型动态分配GPU（例如，利用无服务器计算）。然而，在处理冷门模型的请求时，相关GPU的内存利用率很低。我们进行了一个实验，一个热门模型（15 QPS，Llama-3-8B）和一个冷门模型（1 QPS，Llama-3-8B）各自运行在一块A100-40GB GPU上，并测量它们的GPU内存利用率。虽然热门模型已经利用了所有GPU内存，但冷门模型的GPU内存利用率仍保持在43%。
多路复用：另一种方法是为冷门和热门模型复用GPU。AlpaServe【22，AlpaServe: Statistical multiplexing with model parallelism for deep learning serving，2023，17th USENIX Symposium on Operating Systems Design and Implementation (OSDI 23)】使用模型并行性来为多个模型统计复用GPU。MuxServe【17，MuxServe: Flexible Spatial-Temporal Multiplexing for Multiple LLM Serving，2024，Forty-first International Conference on Machine Learning】通过结合NVIDIA MPS【7，Nvidia Multi-Process Service，2024，Website】进一步改进，从而实现了灵活的时空共享。微批处理（Micro-batching）会导致冗余的LLM权重访问【14，Kunserve: Efficient parameter-centric memory management for llm serving，2025】，使得流水线并行对于可以容纳在单个多GPU节点上的模型效率较低且不常用。MuxServe和我们的工作都主要关注张量并行作为主要的模型并行策略。虽然张量并行提高了GPU利用率，但它也引入了由通信和更小（因此效率更低）的算子引起的开销。在表1中，我们评估了Llama-3-8B模型在2个A100-40GB GPU（通过NVLink连接）上使用2个独立实例和张量并行度为2的设置下的token生成吞吐量。结果显示，即使在具有高互连带宽的平台上，简单地使用张量并行也会引入高达26%的开销。

表1：张量并行开销。结果在两块通过NVLink连接的A100-40GB上测试，模型为Llama-3-8B，输入1024，输出128。

A2 方法细节

3 方法与挑战

机遇：注意力卸载。注意力卸载是一种将注意力算子委托给专用的辅助计算设备【13, Efficient and Economic Large Language Model Inference with Attention Offloading, 2024】【19, FastDecode: HighThroughput GPU-Efficient LLM Serving using Heterogeneous Pipelines, 2024】【20, NEO: Saving GPU Memory Crisis with CPU Offloading for Online LLM Inference, 2024】【23, InstInfer: In-Storage Attention Offloading for Cost-Effective Long-Context LLM Inference, 2024】【24, AttAcc! Unleashing the Power of PIM for Batched Transformer-based Generative Model Inference, 2024, ASPLOS ’24】的技术，例如GPU、CPU、PIM或CSD。主设备（例如GPU）执行投影算子，并将序列的KV缓存存储在辅助设备上。注意力卸载提供了一种以低通信和内存开销卸载LLM推理的部分计算和存储使用的方法，这是因为：1) 对于每次注意力计算，只需要将最新token的QKV张量传输到辅助设备；2) 辅助设备不需要存储模型参数（回顾§2.1，注意力算子是非参数化的）。

我们的方法：工作负载编织。受注意力卸载的启发，我们提出了工作负载编织（workload weaving）来处理多LLM服务工作负载并克服现有方法的局限性（§2.3）。工作负载编织通过将一部分注意力算子卸载到正在运行冷门模型的GPU上，从而利用其未被使用的GPU内存。图2a展示了其工作流程。在推理过程中，发送方（即运行热门模型的GPU）将卸载序列的新token的QKV张量传输到接收方（即运行冷门模型的GPU）。发送方为未卸载部分执行注意力算子，而接收方处理卸载部分，然后将结果返回给发送方进行最终合并。接收方还维护卸载部分的KV缓存。工作负载编织为多LLM服务提供了两个优势。首先，它可以通过利用冷门模型的未使用GPU内存来提高热门模型的吞吐量，从而实现更大的批处理大小。其次，与多路复用方法中使用的模型并行相比，它实现了更低的通信开销。

图2：工作负载编织与挑战。(a) 理想情况。(b) 被预先提交的内核阻塞。(c) 被长时间运行的内核阻塞。

3.1 挑战

实现工作负载编织的挑战。在工作负载编织的理想情况下，冷门实例（即接收方）可以立即执行来自热门实例（即发送方）的注意力算子，如图2a所示。然而，实现这一点是具有挑战性的，因为冷门实例也负责为其自身模型提供服务，这使得卸载的注意力算子会遭受来自两方面的行头阻塞：1) 预先提交的内核和 2) 长时间运行的内核。

被预先提交的内核阻塞。在现有的LLM服务系统中，CPU执行控制流逻辑，主要包括向GPU提交内核。它们通常会向GPU预先提交许多内核（例如，在vLLM中，Llama3-8B每次迭代有387个内核），每个内核代表一个算子。当这些内核进入GPU硬件队列时，GPU硬件将按顺序执行它们。因此，当接收方CPU启动一个卸载的注意力算子时，无法保证它将是下一个被执行的内核。例如，在图2b中，卸载的算子被FC2和QKV Proj这两个未执行但已提交的内核阻塞。

被长时间运行的内核阻塞。即使我们能保证卸载的注意力算子是下一个要执行的内核，它仍然可能被长时间阻塞。这是因为接收方GPU可能正在执行一个长时间运行的内核，如图2c所示。长时间运行的内核在LLM服务中很常见：例如，Llama-3-8B的LM head在A100 GPU上最多需要961µs。

4 设计与实现

WEAVER系统设计。我们提出了WEAVER，一个多LLM服务系统，它实现了高效的工作负载编织，同时克服了相关的挑战（§3.1）。WEAVER包含两项关键技术：GPU驱动的动态控制流（§4.1）和算子拆分（§4.2）。前者将注意力卸载的控制逻辑委托给GPU，使得卸载的注意力算子可以绕过GPU硬件队列中预先提交的内核。后者使用基于排队论的优先级算法将大算子拆分为小算子，避免了长时间运行内核的行头阻塞。结合这两种技术，WEAVER可以保证卸载的注意力最多等待一个正在运行的小内核完成。

4.1 GPU驱动的动态控制流

避免预提交内核阻塞的初步方案及其缺陷。为了避免卸载的注意力算子被预先提交的内核阻塞，一种简单的（strawman）方法是以阻塞方式提交内核：只有当一个内核完成后，接收方CPU才会提交下一个内核（如果存在卸载的注意力算子，则优先提交它）。然而，这种方法会严重影响接收方GPU的计算吞吐量。

WEAVER的解决方案：GPU驱动的动态控制流。WEAVER提出了GPU驱动的动态控制流来避免预提交内核的阻塞问题，同时最小化对GPU性能的影响。它将提交卸载的注意力算子的控制逻辑委托给接收方GPU，并利用跨GPU共享内存能力【2, CUDA Interprocess Communication, 2024, Website】【4, hipipcgetmemhandle interface reference, 2024, Website】进行同步。

具体工作流程。通过GPU驱动的动态控制流，卸载注意力算子的过程如图3所示。当发送方需要卸载一个注意力算子时，它使用单边写入（one-sided writes）将最新token的QKV张量写入共享内存（➊），并原子地增加一个任务计数器（➋）。接收方GPU轮询该任务计数器（➌）。一旦检测到增量，表明有新任务，接收方GPU就执行注意力算子，然后将结果张量写入共享内存（➍），最后增加一个完成计数器（➎）。一旦发送方意识到完成计数器已改变（➏），它就从共享内存中获取结果张量，然后继续后续计算。

轮询内核机制。接收方GPU的所有上述操作，包括轮询、计数器更新、数据传输和注意力执行，都被封装在一个我们称之为轮询内核（polling kernel）的GPU内核中。接收方CPU像今天的LLM服务系统一样预先提交许多内核以饱和GPU硬件队列，但每个内核后面都跟着一个轮询内核。通过这种方式，卸载的注意力将只会被正在执行的内核阻塞，而不会被其他预先提交的内核阻塞。

元数据更新。值得注意的是，注意力元数据（例如，序列页表）的更新由于其复杂性仍在CPU上执行。这些更新不频繁（即每次迭代只有一次），因此不会造成性能瓶颈。

4.2 算子拆分

引入算子拆分以避免长内核阻塞。为了避免由长时间运行的内核导致的行头阻塞，WEAVER引入了算子拆分。其关键思想是将大算子的内核拆分成较小的内核，以便卸载的注意力可以在有限的时间内在GPU上执行。然而，生成一个好的拆分计划并非易事，考虑到1) LLM服务中的算子执行时间各不相同，2) 算子拆分导致的过度碎片化会引入性能开销。为此，我们首先使用排队论来建模发送方的等待时间，然后采用基于优先级的算法来生成拆分计划。

排队论建模。我们将接收方建模为一个具有两个逻辑队列的轮询系统【28，Queuing analysis of polling models，1988，ACM Comput. Surv.】。第一个队列容纳从发送方卸载的注意力算子，它们以$M_i$时间单位的间隔到达，每个需要$N_i$的服务时间。第二个队列容纳接收方的LLM算子，假设有无限的积压（backlog），每个算子需要$T_i$的服务时间。对于注意力的未卸载部分，在发送方的处理时间为$K_i$。我们的目标是最小化第一个队列中卸载的注意力算子所经历的条件期望等待时间（即$W_i$）。具体来说：

这里的条件$K_i < W_i + N_i$意味着：如果未卸载注意力的执行时间小于接收方侧等待时间与卸载注意力执行时间之和，发送方将被阻塞。

模型简化与等待时间计算。为了简化问题，我们假设$K_i$和$N_i$保持不变（记为$K$和$N$），这可以通过定期分析（profiling）获得。根据统计分析，每个卸载算子的完成位置可以被视为一个在$[0, T_i]$上均匀分布的随机变量。在此假设下，由每个算子引起的等待时间为：

总体优化目标。一个算子位于队列头的概率与其在系统中的时间密度成正比。因此，总体目标变为：

基于优先级的算子拆分算法。上述公式表明，大算子对接收方的期望等待时间有二次方的贡献。据此，我们提出了一个基于优先级的算子拆分算法，如算法1所述。我们维护一个包含接收方所有算子的优先队列，并迭代地将执行时间最长的算子拆分为两半。如果拆分后的算子仍然超过$(K-N)$，则将其重新插入队列。此过程持续进行，直到等待时间减少到预定义的阈值$WT_{threshold}$以下（我们将其设置为发送方平均迭代时间的5%）。通过此算法，我们可以在不生成大量小内核的情况下减轻行头阻塞。

算法 1 基于优先级的算子拆分
1: 输入: 优先队列 Q，包含所有算子，按 Ti 降序排列；等待时间阈值 WT_threshold。
2: 输出: 拆分后的算子队列。
3: while 估计等待时间 > WT_threshold do
4:     OP_max ← Q.front();
5:     if T_max > K − N then
6:         OP1, OP2 ← split(OP_max);
7:         Q.pop();
8:         Q.push(OP1, OP2);
9:     else
10:        break
11: return Q

拆分实现。WEAVER在接收方CPU上执行该算法。WEAVER在参数维度上拆分参数化算子，在序列维度上拆分非参数化算子。请注意，目前WEAVER固定了卸载注意力的比例。$K$和$N$通过工作负载分析定期更新。

4.3 实现细节

基础实现。我们基于vLLM v0.6.0【21，Efficient Memory Management for Large Language Model Serving with PagedAttention，2023，Proceedings of the 29th Symposium on Operating Systems Principles, SOSP ’23】实现了WEAVER。我们使用CUDA IPC进行跨GPU共享内存通信，并使用FlashAttention【15，FlashAttention-2: Faster Attention with Better Parallelism and Work Partitioning，2024，International Conference on Learning Representations (ICLR)】来执行卸载的注意力操作。

请求调度。热门实例使用固定的卸载比例，将处理输入序列的任务分配给自己和冷门实例。在完成预填充（prefill）阶段后，每个热门模型请求的KV缓存被随机分配给热门或冷门实例，并一直保留在那里直到请求完成。由于我们的工作重点是开发一种服务多个模型的有效机制，我们将集群级调度器的设计留作未来工作。例如，可以使用请求率指标动态调整卸载比例，当冷门模型的负载高时减少卸载比例，当负载低时增加卸载比例，以实现对冷门模型资源的动态利用。

KV缓存管理。在WEAVER中，冷门模型实例的GPU内存同时持有来自热门模型的卸载序列的KV缓存块和其自身序列的KV缓存块。遵循先前的工作【17，MuxServe: Flexible Spatial-Temporal Multiplexing for Multiple LLM Serving，2024，Forty-first International Conference on Machine Learning】，我们构建了一个统一的KV块分配器，支持具有不同层数和KV头数的模型。

A7 补充细节

4.4 讨论

模型大小的影响。对于较大的模型，GPU内存，特别是KV缓存，成为更显著的约束，通常限制了最大批处理大小。在这种情况下，WEAVER允许热门模型利用冷门模型GPU实例的内存资源。这使得热门模型能够实现更大的有效批处理大小，从而获得更高的最大吞吐量。对于小型语言模型，其好处可能不那么显著。

WEAVER的局限性。WEAVER无法加速模型的FFN部分。对于小型语言模型和较大的批处理大小，投影部分可能对端到端性能起主导作用。我们将FFN部分的工作负载卸载探索留作未来工作。

6 相关工作

多模型服务。在深度神经网络（DNN）时代，已经提出了许多支持多模型服务的方法，例如TGS【33，Transparent GPU Sharing in Container Clouds for Deep Learning Workloads，2023，20th USENIX Symposium on Networked Systems Design and Implementation (NSDI 23)】、PipeSearch【12，PipeSwitch: Fast Pipelined Context Switching for Deep Learning Applications，2020，14th USENIX Symposium on Operating Systems Design and Implementation (OSDI 20)】、AlpaServe【22，AlpaServe: Statistical multiplexing with model parallelism for deep learning serving，2023，17th USENIX Symposium on Operating Systems Design and Implementation (OSDI 23)】、MPS【7，Nvidia Multi-Process Service，2024，Website】和MIG【6，NVIDIA Multi-Instance GPU，2024，Website】等。它们专注于以最小的开销实现高效的模型切换和时空复用。这些方法大多将模型视为黑盒，忽略了利用模型结构来服务多个模型的机会。

多LLM服务。对于多LLM服务，一些研究已经探索了可扩展和高效的解决方案。Llumnix【27，Llumnix: Dynamic Scheduling for Large Language Model Serving，2024】通过迁移KV缓存来实现LLM服务系统中的负载均衡。与我们最相关的是MuxServe【17，MuxServe: Flexible Spatial-Temporal Multiplexing for Multiple LLM Serving，2024，Forty-first International Conference on Machine Learning】，它采用张量并行并利用时空复用来并发服务多个LLM请求。

注意力卸载。先前的工作【13, Efficient and Economic Large Language Model Inference with Attention Offloading, 2024】【19, FastDecode: HighThroughput GPU-Efficient LLM Serving using Heterogeneous Pipelines, 2024】【20, NEO: Saving GPU Memory Crisis with CPU Offloading for Online LLM Inference, 2024】【23, InstInfer: In-Storage Attention Offloading for Cost-Effective Long-Context LLM Inference, 2024】【24, AttAcc! Unleashing the Power of PIM for Batched Transformer-based Generative Model Inference, 2024, ASPLOS ’24】已经探索了将LLM中的注意力算子卸载到不同的计算设备，包括CPU、GPU和PIM。LoongServe【32，LoongServe: Efficiently Serving Long-Context Large Language Models with Elastic Sequence Parallelism，2024，Proceedings of the ACM SIGOPS 30th Symposium on Operating Systems Principles, SOSP ’24】通过在多个服务器之间拆分注意力算子来加速长序列的推理。我们的工作与这些方法不同：我们不是使用专用硬件，而是将注意力卸载到正在运行冷门模型的GPU上。这种独特的方法需要精心设计，以减轻由正在进行的冷门模型服务引起的阻塞。

A4 实验环境与结果

实验环境

工作负载与数据集：使用了两个广泛使用的LLM工作负载轨迹：BurstGPT【31, BurstGPT: A Real-world Workload Dataset to Optimize LLM Serving Systems, 2024】 (ChatGPT-4 split) 和 Azure-Conv【25, Splitwise: Efficient generative llm inference using phase splitting, 2024】。过滤掉了超过2048个token的序列。BurstGPT代表均衡型工作负载，平均输入575 token，输出340 token。Azure-Conv代表输入密集型工作负载，平均输入749 token，输出232 token。请求到达时间遵循泊松分布。
模型：默认使用Llama-3-8B模型。
硬件配置：
1. 平台一：4块A100-40GB GPU，通过NVLink互连。
2. 平台二：一个云服务器，包含4块L40S GPU，通过PCIe互连。
  每个模型（热门和冷门）均采用1个进程1个设备的（1p1d）设置，工作负载仅在解码GPU之间进行复用。
软件配置与基线系统：
- WEAVER实现：基于vLLM v0.6.0，未使用CUDA Graph以与基线公平比较。
- 基线1 (Dedicated Serving)：使用专用的GPU分别服务冷门和热门模型，均运行未经修改的vLLM。
- 基线2 (MuxServe)【17，MuxServe: Flexible Spatial-Temporal Multiplexing for Multiple LLM Serving，2024，Forty-first International Conference on Machine Learning】：支持两种模式：1) 启用NVIDIA MPS的时空复用；2) 仅时间复用 (Mux-Temporal)。为了公平比较，MuxServe的注意力内核被替换为与WEAVER相同的FlashAttention。在L40S平台上，由于权限限制无法启用MPS，因此只评估了时间复用模式。
评估指标：主要报告每个模型的TPOT (Time Per Output Token)，即每个输出token的时间，它对用户体验至关重要。TTFT（Time To First Token）在消融研究中进行了评估。

实验结果

5.1 总体性能

通过改变热门模型的请求率，评估了WEAVER与基线系统的总体性能。
* 热门模型性能 (图4a-d)：
* 与专用服务相比，WEAVER将最大吞吐量提高了高达60%。这是因为它利用了冷门模型GPU上的可用内存，从而允许更大的批处理大小。在低请求率下，WEAVER因通信开销导致TPOT略高，但在高请求率下，TPOT最多可降低39%。
* 与多路复用服务（MuxServe）相比，在A100上，WEAVER使热门模型的最大吞吐量提高了高达22%。在互连带宽较低的L40S上，提升更为显著，最大吞吐量提高了高达77%，因为多路复用方法中的张量并行在此类平台上开销更大。
* 冷门模型性能 (图4e-h)：
* WEAVER在提升热门模型吞吐量的同时，对冷门模型性能的影响是可接受的。
* 在热门模型低负载时，冷门模型的TPOT比专用服务高1.04倍。
* 在热门模型高负载时，WEAVER引入了适度的开销，平均TPOT增加3-5ms。
* MuxServe的TPOT略低于WEAVER，但这是以牺牲热门模型吞吐量为代价的。由于卸载的注意力算子很小，对冷门模型执行的干扰不大，P99 TPOT也未受显著影响。

批处理大小与内存利用率分析：
- 以A100上的Azure-conv轨迹为例，专用服务在最大吞吐量15 QPS时，热门模型平均批大小为118，KV缓存利用率达88.9%。
- 在相同QPS下，WEAVER将热门GPU的KV缓存利用率降至46.9%，并利用了冷门GPU 36.7%的KV缓存。
- 当QPS提升至WEAVER支持的最高22时，热门模型的平均批大小增至231，批处理能力相比专用服务翻倍。

5.2 敏感性分析

热门与冷门请求率比例 (图5a)：在固定热门模型请求率为10 QPS的情况下，改变冷热请求比例。结果显示，在所有比例下，WEAVER对热门模型的TPOT始终比MuxServe低15%，比Mux-Temporal低20%-40%。
卸载序列比例 (图5b)：在固定热门模型请求率为15 QPS的情况下，改变卸载的注意力算子百分比。冷门模型的TPOT随卸载比例线性增加。在卸载比例为50%时，热门模型的TPOT降低了13%，而接收方（冷门模型）的处理时间增加了3.7ms的TPOT开销。实验表明，45%的卸载比例在测试负载下能为热门模型提供最优的TPOT。

图5：敏感性分析（I）。(a)：改变热门与冷门的请求率。(b)：改变卸载序列的百分比。
更长输出长度 (图6)：使用合成数据（输入512，输出1024）进行测试。WEAVER的最大吞吐量比MuxServe高出高达42%。这是因为对于长输出，批大小受KV缓存限制更为严重，WEAVER通过卸载注意力计算（此时占比较大），有效增加了总批处理能力。同时，由于卸载的工作负载更重，冷门模型的TPOT比专用服务增加了最多8ms。

图6：敏感性分析（II）。更长输出的结果。

5.3 消融研究

WEAVER中不同技术的消融 (图7a)：
- 基线 (仅CPU控制)：存在严重的预提交内核阻塞，导致热门模型TPOT高达175ms。
- +GPU控制：引入GPU驱动的动态控制流后，发送方（热门模型）TPOT降低了4.83倍，而冷门模型TPOT仅因轮询内核增加了1.8ms。
- +算子拆分：在GPU控制基础上增加算子拆分，进一步将热门模型TPOT降低了9.5%，而冷门模型TPOT仅增加0.7ms。
- 最终，这两项优化总共只给冷门模型的原始TPOT增加了2.5ms的开销（不到10%）。
不同服务框架的消融 (图7b)：
- 比较了WEAVER和MuxServe的TTFT（首token生成时间）。两者TTFT始终非常接近，WEAVER略高（最多5.7%），这表明性能比较是公平的，TTFT未受影响。
  
  图7：消融研究。(a)：WEAVER中不同技术的消融。(b)：不同服务框架的消融。

A5 结论

本文提出了WEAVER，一个专为多LLM服务设计的系统。WEAVER引入了“工作负载编织”（workload weaving）机制，通过将热门模型的注意力算子卸载到正在运行冷门模型的GPU上，从而有效利用了冷门模型实例上未被充分利用的GPU内存，同时保持了较低的通信开销。为了解决卸载过程中可能出现的行头阻塞问题，WEAVER设计了GPU驱动的动态控制流和算子拆分两项关键技术。实验结果表明，WEAVER能够显著提升热门模型的吞吐量，同时对冷门模型的性能影响控制在可接受的范围内，证明了其在处理倾斜访问模式下的多LLM服务工作负载方面的有效性。

Weaver: Efficient Multi-LLM Serving with Attention Offloading