Prism: Unleashing GPU Sharing for Cost-Efficient Multi-LLM Serving

作者/机构: Shan Yu (UCLA), Jiarong Xing (UC Berkeley, Rice University), Yifan Qiao (UC Berkeley), Mingyuan Ma (Harvard University), Yangmin Li (Carnegie Mellon University), Yang Wang (Intel), Shuo Yang (UC Berkeley), Zhiqiang Xie (Stanford University), Shiyi Cao (UC Berkeley), Ke Bao (LMSYS), Ion Stoica (UC Berkeley), Harry Xu (UCLA), Ying Sheng (UCLA)

A1 主要贡献

核心问题: 服务大型语言模型（LLM）成本高昂，特别是对于托管成千上万个基础模型和用户微调模型的服务提供商而言。现有的GPU共享系统（如MIG、MuxServe、QLM）由于采用静态资源分配或固定的共享策略，无法在快速波动的负载下有效满足延迟服务水平目标（SLO），导致资源利用率低下和成本高昂。

研究目标: 本文旨在设计一个名为Prism的多LLM服务系统，以充分发挥GPU共享的潜力，从而在满足SLO的同时实现成本效益。核心挑战在于实现灵活且需求感知的跨模型内存协调，以适应动态工作负载。

创新点与主要贡献:
通过对四个生产环境追踪数据的深入分析，本文揭示了多LLM服务的四个关键工作负载特征：
* C1: 长尾模型流行度 (Long-tail model popularity): 少数热门模型占据了大部分请求，而大量模型处于长尾，请求量极少。
* C2: 频繁的空闲期 (Frequent idle periods): 模型经常出现没有请求的空闲时段。
* C3: 快速的工作负载波动 (Rapid workload fluctuations): 模型的工作负载在短时间内会发生剧烈变化，可能在几分钟内波动超过5倍。
* C4: 多样化的服务水平目标 (Diverse service-level objectives, SLOs): 不同模型根据客户需求有不同的延迟SLO。

图1：来自代表性服务提供商Hyperbolic [26]的多LLM服务的工作负载特征。

基于以上观察，本文提出了Prism系统，其核心贡献在于通过两个关键设计实现灵活和需求感知的跨模型内存协调：
1. 实现灵活的跨模型内存协调:
* 按需内存分配机制: Prism引入了一个名为kvcached的组件，通过动态映射物理到虚拟内存页，解耦了虚拟和物理GPU内存。这使得服务引擎只需在初始化时预留虚拟地址空间，物理内存则在运行时按需分配和映射。该设计允许在共享同一GPU的模型之间灵活地重新分配用于KV缓存和模型权重的内存。
* 快速模型激活: Prism通过使用带有可重用虚拟地址空间的预启动引擎池和并行加载模型权重来加速模型的激活过程。

实现需求感知的内存分配协调以最大化SLO达成率:
- 两级调度策略: Prism采用两级调度策略来协调模型放置和内存分配。
  - 全局调度器: 使用一个名为“KV压力比”（KV pressure ratio）的启发式方法，在GPU之间放置模型。该比率综合考虑了模型的请求率、SLO和GPU的可用内存，旨在最大化所有GPU中的最小KV压力比，从而实现最均衡的负载。
  - 本地调度器: 对于在同一GPU上共置的模型，Prism使用一个GPU级的共享请求队列和基于优先级的准入控制来调度请求。优先级根据每个请求的SLO导出，以防止无序的内存争用。

实验结果表明，与最先进的系统相比，Prism在相同的GPU数量下，实现了超过2倍的成本节省和3.3倍的SLO达成率。

表1：GPU共享系统的比较。S-Pa.：静态GPU分区；Muxs.：MuxServe。最后两行显示了8个模型达到99% SLO达成率所需的GPU数量，以及在限制为2个GPU时的SLO达成率。

A3 背景知识与关键观察

背景知识

LLM推理过程: LLM推理包括两个阶段：prefill（预填充）和decode（解码）。Prefill阶段处理请求输入（即prompt）并生成第一个输出token。随后是decode阶段，LLM自回归地生成输出token——每次迭代使用所有先前生成的token作为输入生成一个token。因此，输出长度通常是未知的。为了提高吞吐量，LLM服务系统通常将多个请求批处理在一起【58, Orca: A Distributed Serving System for Transformer-Based Generative Models, 2022, OSDI】。为了平衡批处理的吞吐量与延迟，chunked-prefill【2, Taming Throughput-Latency Tradeoff in LLM Inference with Sarathi-Serve, 2024, OSDI】将prompt分解为更小的块，并增量地送入推理批次，通过重叠prefill和正在进行的decode来减少延迟。

KV缓存: LLM推理会产生大量称为KV缓存的中间数据。在请求的整个推理期间，KV缓存必须保留在GPU内存中。其大小随请求的输入和输出长度线性增长，对于长序列很容易达到数十GB。因此，推理批次大小直接受限于可用于KV缓存的GPU内存。

PagedAttention: 为了更有效地使用GPU内存，PagedAttention【29, Efficient Memory Management for Large Language Model Serving with PagedAttention, 2023, SOSP】被引入来管理KV缓存。PagedAttention受到操作系统中经典虚拟内存和分页技术的启发——它将GPU内存分解为小的、固定大小的页，并用页表来管理它们。这种设计允许请求以页的粒度分配GPU内存，与之前为每个请求的最大解码长度保留连续内存块的系统【58, Orca: A Distributed Serving System for Transformer-Based Generative Models, 2022, OSDI】相比，显著提高了内存利用率。PagedAttention已被主流服务引擎（如SGLang【64, Efficiently Programming Large Language Models using SGLang, 2023】和vLLM【29, Efficient Memory Management for Large Language Model Serving with PagedAttention, 2023, SOSP】）广泛采用。

推理延迟指标: LLM服务中有多种延迟指标【54, Revisiting SLO and Goodput Metrics in LLM Serving, 2024】。本文使用两个常用指标：首token时间（Time-To-First-Token, TTFT），衡量生成第一个输出token的时间；以及每输出token时间（Time-Per-Output-Token, TPOT），捕捉生成一个token的平均时间。TTFT反映了用户在接收初始响应时的感知延迟，而TPOT则捕捉了逐个token生成输出时的用户体验。

动机

多LLM服务工作负载对GPU共享的影响

生产环境追踪数据分析: 为了理解多LLM服务的工作负载，我们详细分析了四个生产环境的追踪数据。这些数据来自代表性的服务提供商，如表2所示。前两个追踪数据来自Hyperbolic【26, Hyperbolic: The Open Access AI Cloud. Hyperbolic Provides Affordable GPU Access and Inference Services for Those at the Edges of AI., 2024】和Novita AI【4, Novita AI homepage., 2025】，它们是两个流行的LLM推理服务提供商。后两个追踪数据来自广泛使用的开源LLM评估平台Chatbot Arena【14, Chatbot Arena: An Open Platform for Evaluating LLMs by Human Preference, 2024】。分析揭示了四个独特的工作负载特性，为多LLM服务中的GPU共享带来了机遇和挑战。

(1) 长尾模型流行度: 图2a展示了每个模型接收请求的分布情况。我们发现所有追踪数据都表现出长尾模型流行度——大约60%的模型仅贡献了所有请求的25%。这种趋势是由于当今可用的LLM种类繁多。大多数用户选择最新发布的基础模型，而其他模型仅用于特定领域或不常见的场景。因此，处于流行度尾部的模型由于请求率低，往往无法充分利用其专用GPU。例如，在Hyperbolic【26】追踪数据中，Llama-3.2-3B模型在H100 GPU上的平均计算利用率仅为2.3%，内存利用率仅为10.2%。
* 启示#1: 多个低需求模型可以空间共享GPU以提高资源利用率。

(2) 频繁的空闲期: 模型经常经历没有请求到达的空闲期。图2b显示了每个追踪数据中所有模型的中间空闲时长。在所有追踪数据中，许多模型的中间空闲时长超过30秒。Chatbot Arena的追踪数据甚至显示出更长的空闲时长，超过50%的模型的中间空闲时间大于80秒。图2c进一步报告了每小时发生的空闲间隔（>10秒）的平均数量。如图所示，空闲期频繁发生——在Hyperbolic和Novita追踪数据中，约50%的模型每小时经历超过40次这样的间隔。一些模型甚至表现出超过100个间隔，这意味着它们至少有27%的时间处于空闲状态（假设每个间隔持续10秒）。
* 启示#2: 频繁的长空闲期允许通过将空闲模型从GPU中驱逐，并在新请求到达时重新加载来实现时间共享。

(3) 快速的工作负载波动: 图1b展示了来自Hyperbolic追踪数据的三个模型的工作负载波动。这里我们对所有追踪数据进行更详细的定量分析。图2d显示了每个模型每分钟请求数的变异系数（CV）的分布。CV（计算为标准差除以均值，$\sigma/\mu$）量化了请求率的相对变异性——值越高表示工作负载越具突发性。Hyperbolic和Novita的追踪数据中都包含许多CV大于1.0的模型，表明工作负载波动显著。Chatbot Arena的追踪数据请求率较低，导致整体CV较小，但许多模型仍然表现出大于0.5的CV。
* 启示#3: 没有任何固定的共享策略能很好地适用于工作负载变化引起的所有场景。策略，例如哪些模型共置以及如何为它们分配资源，必须根据实时工作负载进行调整。

(4) 多样化的延迟SLO: 模型具有不同的延迟SLO（约1-10+秒），这由它们的具体用例和用户需求决定【40, Queue Management for SLO-Oriented Large Language Model Serving, 2024】【43, Mooncake: Trading More Storage for Less Computation—A KVCache-Centric Architecture for Serving LLM Chatbot, 2025】。例如，编码助手【53, OpenHands: An Open Platform for AI Software Developers as Generalist Agents, 2024】需要低响应延迟以跟上程序员的编码流程，而文档摘要【10, Anthropic Legal Summarization Guide., 2025】则可以容忍相对较高的延迟。Novita追踪数据显示，端到端延迟SLO从5秒到25秒不等。
* 启示#4: 延迟SLO反映了模型需要多快地访问其所需资源。GPU共享应明确考虑SLO的多样性，以优先分配资源并最大化整体SLO达成率。

总结: 尾部模型的低资源需求和频繁的长空闲时间为GPU空间和时间共享以提高利用率提供了机会。挑战在于处理快速的工作负载波动，这需要根据实时工作负载和SLO需求动态调整共享策略和资源分配。

图2：四个生产多LLM服务追踪数据的详细分析。这些图表显示，所有追踪数据中都存在长尾模型流行度(a)，许多模型有频繁的空闲期(b)+(c)，并且请求率可以快速波动(d)。

现有方法的局限性

静态分配与固定共享策略的不足: 现有系统静态分配内存或使用固定的共享策略，缺乏在运行时适应工作负载波动的灵活性。因此，它们无法最大化内存使用效率以满足延迟目标。为了说明这一点，我们使用一个工作负载（图3）来评估它们的性能，该工作负载反映了图1b中Model1和Model2在10:00-10:30（T1）和13:30-14:00（T2）期间的请求率模式。在T1期间，两个模型都有波动的负载，Model1处理的请求量更高。在T2期间，Model2的需求激增，而Model1变为空闲。

不同共享策略的内存使用情况: 图3（底部）显示了随时间变化的总KV缓存大小。尽管MuxServe【16, MuxServe: Flexible Multiplexing for Efficient Multiple LLM Serving, 2024】和静态分区都允许GPU空间共享，但MuxServe通过在模型之间灵活共享内存在T1期间实现了更高的KV缓存使用率。相比之下，静态分区阻止Model1利用Model2未使用的内存。QLM【40, Queue Management for SLO-Oriented Large Language Model Serving, 2024】通过模型交换来时间共享GPU，其KV缓存使用率周期性地降至零，反映了其交换操作带来的巨大开销。在T2期间，当Model1变为空闲时，QLM将整个GPU专用于Model2，产生了最高的KV缓存使用率。与此同时，MuxServe的使用率低于QLM，因为它无法驱逐空闲模型，导致Model1的权重不必要地占据GPU内存。

KV缓存大小对性能的影响: KV缓存大小直接决定了批次大小并影响推理性能。如图4所示，将KV缓存池从5GB扩大到15GB，可以带来超过2倍的吞吐量提升。

跨模型内存协调的重要性: 这个例子凸显了跨模型内存协调在释放GPU共享潜力以实现经济高效的多LLM服务方面的重要性。内存必须被灵活分配以适应工作负载变化，并被明智地使用以满足性能目标。在这个例子中，在T1期间，两个模型应该共置并灵活共享GPU内存；在T2期间，应该通过驱逐空闲的Model1，将GPU专用于Model2。

A2 方法细节

系统概览

Prism系统架构: Prism是一个多LLM服务系统，旨在通过充分发挥GPU共享的潜力来提高成本效益，同时满足延迟SLO。图5展示了其系统架构和设计概览。Prism在其前端接收推理请求，并将其路由到相应的LLM进行处理。为了提高成本效益，Prism通过灵活组合空间和时间共享的方式来服务LLM。例如，高请求率的模型可以独占GPU，而多个低请求率的模型可以共置在单个GPU或GPU组上。空闲模型被临时驱逐到CPU DRAM中，并在新请求到达时重新激活。Prism根据运行时工作负载持续调整其共享策略，以最大化整体SLO达成率。

Prism的核心设计: Prism通过两个关键设计实现了这一点，从而实现了灵活和需求感知的跨模型内存协调。首先，它引入了一种按需内存分配机制（§5.1），使模型能根据实际需求获取内存。这种灵活的机制使Prism能够快速适应工作负载变化和策略变更，同时也促进了快速模型激活（§5.2）。其次，Prism通过需求感知的跨模型内存协调来优化整体资源分配。它采用两级调度策略来协调模型放置和内存分配。在全局层面，Prism根据模型的内存需求在GPU之间放置模型（§6.2）。在GPU层面，它使用一个共享的请求队列结合基于优先级的准入控制来管理共置模型间的内存共享（§6.3）。

启用灵活的GPU共享

本节描述了Prism如何实现模型间的灵活内存协调（§5.1），并利用它来实现快速的模型激活（§5.2），这为根据运行时工作负载变化调整共享策略奠定了基础。

跨模型内存协调

现有推理引擎内存管理的局限性: 当今的推理引擎内存管理主要为单模型服务设计。它在初始化时预分配一大块GPU内存，包括虚拟和物理内存，并采用固定的1:1映射。这块内存被静态地保留给该模型，并在其整个生命周期内保持不变。尽管PagedAttention【29, Efficient Memory Management for Large Language Model Serving with PagedAttention, 2023, SOSP】被广泛用于根据请求需求动态分配KV缓存内存，但它是在应用层面管理内存，仍然在单个模型的静态预留内存区域内操作。这种按模型的静态分配方式阻碍了模型间的灵活内存再分配，限制了在运行时调整GPU共享策略的能力。如§3.2所示，这种不灵活性会导致推理性能受限。

实现按需内存分配的挑战: 为了解决这个问题，我们需要引擎能够按需动态获取内存，而不是静态预留。然而，在当前引擎中实现这一点需要侵入性的修改，因为它们的系统堆栈是围绕静态内存分配设计的。例如，大多数CUDA核在开发时都假定虚拟地址是连续的，而动态内存分配可能导致非连续的地址空间，这就需要修改核实现及其调用栈。

kvcached：一个用于按需跨模型内存分配的垫片层: Prism通过设计kvcached作为一个垫片层，实现了按需内存分配，同时保持了与当前引擎的兼容性。它利用最近引入的CUDA虚拟内存管理API【36, CUDA Toolkit Documentation: Virtual Memory Management., 2025】解耦了虚拟内存和物理内存的分配。如图6所示，在Prism中，引擎只需在初始化时预留虚拟内存，这是一个由固定大小内存页（例如2MB）组成的大块连续地址空间。这给引擎造成了一种所有内存都已准备就绪的错觉，而实际上，物理内存只有在需要时才会被分配并映射到一个虚拟页。

kvcached的实现与API: kvcached被实现为一个运行时库，只需修改约20行代码即可与当前的推理引擎集成。表3总结了其提供的API。引擎可以使用alloc_kvcache或free_kvcache API来创建或销毁一个KV缓存内存池。在内部，kvcached会分配或释放相应的虚拟空间。引擎的KV管理器可以通过alloc_kv和free_kv动态地为一个请求分配或释放KV缓存。kvcached维护KV缓存页的使用状态。当调用alloc_kv时，它会检查相应的虚拟页是否已被映射；如果没有，它会分配一个物理页并进行映射。同样，如果一个页在调用free_kv后变为空，其物理内存将被取消映射并释放。

模型无关的内存分配与同步: Prism通过允许每个引擎链接到自己的kvcached实例，实现了模型无关的内存分配。这一点很重要，因为CUDA以固定大小的页（即2MB）管理GPU内存，而不同的模型可能使用不同的token大小（例如16KB vs 48KB）。在同一个页上存储不同大小的token会破坏PagedAttention，因为它依赖于基于索引的查找来高效访问token，这要求token大小一致。此外，Prism在kvcached实例之间引入了共享的系统变量来跟踪全局内存使用情况。结合适当的锁定机制，它协调了跨引擎的内存分配，并有助于防止由竞争条件引起的内存不足错误。

性能优化: 动态分配和映射内存页会产生额外的延迟。Prism通过两个优化来减少这种开销。首先，它优先使用部分填充的页，并将新的token放置在最能满足内存需求且利用率最高的页中。这提高了页的利用率并减少了新分配的频率。其次，Prism维护一个预分配和预映射的内存页缓冲区。当引擎需要新页时，它直接从这个缓冲区获取。该缓冲区是异步管理的，其开销完全与推理计算重叠。这些优化确保了kvcached对推理计算的开销可以忽略不计。

快速模型激活

模型交换速度的重要性: 模型交换的速度直接影响GPU共享的灵活性。高延迟会阻碍具有严格SLO的模型的及时交换，从而限制策略的适应性。虽然停用模型很简单，即终止引擎并释放所有内存，但重新激活则更为复杂，涉及：(1) 初始化一个新的服务引擎并为KV缓存池预留一个新的虚拟地址空间；(2) 从CPU DRAM加载模型权重。如果天真地执行此过程，可能需要数十秒，远超在线LLM推理通常仅为几秒或更短的TTFT SLO。

可重用引擎池: 问题(1)的根本原因在于引擎与其所服务模型之间的紧密耦合。在当前系统中，引擎与其模型共享相同的生命周期——当模型被驱逐时，其引擎及其虚拟地址空间也会被终止。因此，每次模型激活都会产生完整的引擎初始化成本。Prism通过解耦引擎和模型的生命周期来消除这种开销。具体来说，它在每个GPU上维护一个引擎池，池中的引擎预先初始化了虚拟地址空间和分布式上下文。在模型激活时，Prism从池中选择一个可用的引擎并直接开始加载模型。当模型被驱逐时，其物理内存被释放，但其带有虚拟地址空间的引擎被返回到引擎池以供将来重用。

动态虚拟内存布局调整: 然而，一个引擎不能直接重用先前预留的虚拟内存空间来服务一个新模型。这是因为当前的推理引擎执行基于索引的token访问，这依赖于一个与模型相关的内存布局，该布局与不同架构（例如，不同层数或token大小）的模型不兼容。为了解决这个问题，Prism引入了一个KV缓存虚拟内存管理器来管理引擎池中预留的虚拟内存空间。当加载新模型时，管理器会动态地对齐预留的虚拟空间以匹配新模型所需的内存布局（一次性工作），然后基于对齐后的内存空间创建一个新的kvcached。这个kvcached随后可以在推理期间正确且高效地定位每个token所在的虚拟内存页。

并行模型权重加载: 问题(2)的模型权重加载时间在很大程度上受到CPU-GPU互连带宽利用率的影响。我们发现，通过cudaMemcpyAsync API天真地将模型加载到GPU无法饱和互连带宽，即使从多个线程调用也是如此。这可能是因为所有针对同一GPU的cudaMemcpyAsync操作都是串行执行的，受限于CUDA驱动和硬件。Prism通过将模型权重分块成更小的段，在同一节点上的多个GPU之间并行加载它们，然后通过高速NVLink互连将它们聚合到目标GPU来克服这个瓶颈。这种并行化策略显著加速了模型加载。为了最小化对GPU上正在运行的工作负载的干扰，Prism以单个权重张量为粒度对模型权重进行分区，并以流式方式加载它们。因此，每个GPU只需要维护一个小的缓冲区（例如30MB），从而最小化了可能的内存争用。

优化效果: 通过这些优化，如我们的评估（图9）所示，Prism可以在0.7秒内激活一个8B模型，在1.5秒内激活一个70B模型——比天真方法快4.8到7.1倍。

两级需求感知调度

§5中提出的技术为多LLM服务中的灵活GPU共享奠定了基础。然而，要充分发挥其优势，我们需要从实时工作负载中推导出有效的共享策略，以最大化共享效益。本节首先描述调度问题，然后介绍我们的两级需求感知调度算法。

调度问题

内存争用与性能: 共享GPU的模型在资源受限时不可避免地会争夺内存，因此必须高效地使用GPU内存以确保性能。这就提出了一个关键问题：给定固定数量的GPU、一组模型及其实时工作负载，我们应该如何协调模型间的内存分配，以尽可能满足它们的需求？

优化目标: 我们优先优化首token时间（TTFT），因为它取决于在请求提交时已知的prompt长度。相比之下，每输出token时间（TPOT）受到输出长度的影响，由于LLM解码的自回归特性，输出长度是预先未知的。尽管如此，我们的系统也能使TPOT受益，因为它尽可能满足每个模型的资源需求。这减少了因内存不足导致请求被抢占的可能性，否则会降低TPOT。

两级调度策略: Prism使用两级调度来协调模型间的内存分配：(1) 全局调度（§6.2）根据模型的资源需求决定其在GPU间的放置，旨在平衡负载并避免资源瓶颈；(2) GPU本地调度（§6.3）根据优先级管理共置在同一GPU上的模型的请求，实现高效的KV缓存内存共享。

全局模型放置调度

全局调度器的功能: Prism的全局调度器根据模型的资源需求智能地将它们放置在可用的GPU上，目标是平衡负载以最小化资源争用。它执行三个关键操作：(1) 决定模型到GPU的放置，(2) 驱逐空闲模型，以及 (3) 在请求到达时激活非活动模型。

模型到GPU放置的挑战与方法: 为了最大化内存使用效率，调度器必须同时考虑模型的请求负载和SLO。请求负载决定了模型服务所需的总内存，而SLO反映了模型为满足其延迟目标而获取这些资源的紧迫性。这项任务在实践中面临两个困难。首先，搜索空间巨大（即$N^M$，假设有N个GPU和M个模型）。其次，准确估计模型的内存需求很困难，因为它取决于预先未知的输出长度。

KV压力比（KVPR）启发式: Prism使用我们称之为KV压力比（KVPR）的启发式方法解决了这个问题，该方法量化了GPU上的KV缓存压力程度。其计算公式为 $w\_req\_rate / shared\_kv$，其中 $w\_req\_rate = req\_rate / SLO$ 是模型的SLO加权请求率，表示其单位时间的内存需求，而 $shared\_kv$ 是GPU上可用于KV缓存的内存。较高的KVPR表示较高的内存压力和更拥挤的GPU。

模型放置算法: 利用这个启发式方法，Prism通过一个定制的多机调度算法来确定最佳的模型到GPU放置，如算法1所示。它首先按加权请求率降序对模型进行排序，并初始化GPU状态（第1-3行）。接下来，对于每个模型，Prism选择使KVPR最小化的GPU（第5-8行）。如果选择的GPU与模型当前的GPU不同，Prism会将模型迁移到新的GPU。然而，这种迁移会产生引擎切换和模型权重加载的开销。为了避免收益微乎其微的不必要迁移，Prism会比较最佳GPU和当前GPU的KVPR，只有当改进超过一个阈值 $\tau$ 时才进行迁移（第8行）。最后，Prism将模型分配给其选择的GPU，并更新相应的GPU状态（第9-12行）。

算法1 全局模型放置调度

要求：GPU数量N，GPU内存容量C，迁移阈值τ，以及M个模型。每个模型m_j有：请求率r_j，权重w_j，当前设备索引g_j，以及延迟SLO s_j。
确保：将每个模型分配给一个GPU，以平衡资源需求和剩余内存容量。
1: 按r_j/s_j降序对模型排序。将排序后的序列表示为m_1, m_2, ..., m_M。
2: for i = 1 to N do
3:   shared_kv_i ← C; w_req_rate_i ← 0
4: for k = 1 to M do
5:   /* 找到最小化KVPR的GPU best_idx */
6:   best_r, best_idx ← (min, argmin) w_req_rate_i / shared_kv_i
7:   current_r ← w_req_rate_{g_k} / shared_kv_{g_k}
8:   best_gpu ← best_idx, if current_r - best_r > τ
9:            else g_k
10:  将模型m_k分配给best_gpu
11:  /* 更新状态 */
12:  w_req_rate_{best_gpu} ← w_req_rate_{best_gpu} + r_k/s_k
13:  shared_kv_{best_gpu} ← shared_kv_{best_gpu} - w_k

算法分析: 全局模型放置算法确保了所有GPU中的最大KVPR受限于最优放置中的最大KVPR。该算法还支持使用张量并行（TP）的模型，方法是将每个TP分区视为一个独立的模型，并强制将它们放置在不同的GPU上。更详细的分析见附录A.1。

模型驱逐与激活: 全局调度器会在模型空闲时间超过一个经验阈值时驱逐该模型，该阈值可以通过分析空闲间隔分布来确定。Prism仅在GPU资源受限时驱逐模型，并优先驱逐SLO较大的模型。当被驱逐的模型接收到新请求时，Prism会立即通过选择KV压力比最低的GPU来为其服务，从而重新激活它。

GPU本地请求调度

本地调度的挑战: 分配到同一GPU的模型在总内存有限时可能会竞争KV缓存内存。如果没有适当的协调，这种争用可能导致内存使用效率低下和SLO达成率下降。例如，一个请求率高但SLO宽松的模型可能会消耗大部分内存，从而阻止具有更严格SLO的模型获得足够的内存使用。

现有解决方案的不足: 一个简单的解决方案是限制每个模型可以使用的内存。然而，由于动态的请求模式和不同的SLO，确定适当的限制是具有挑战性的。保守的限制可能会不必要地限制模型的吞吐量，而过于宽松的限制则会减少其他模型可用的内存，因为总分配必须保持在GPU的容量之内。一个改进是根据运行时工作负载动态调整这些限制。然而，这种调整不能立即生效，因为内存必须先由一个模型释放，然后才能被重新分配给其他模型。这需要等待模型完成其一些正在进行的请求——这个过程可能需要几秒到几分钟，具体取决于请求的长度和负载。

Prism的解决方案：共享队列与优先级准入控制: 这种内存协调挑战源于每个引擎都维护自己的请求队列，并在内存可用时贪婪地调度请求。为了解决这个问题，Prism引入了一个共享的GPU级请求队列，并结合了基于优先级的准入控制机制来协调模型间的内存使用。来自共享一个GPU的所有模型的传入请求首先被放入GPU级请求队列。然后，Prism根据请求的优先级将它们出队，并分派给相应的引擎。Prism贪婪地分派请求，直到它们可以立即执行而不会在引擎的本地等待队列中造成排队。这种方法在实现高内存利用率和严格准入控制之间取得了平衡。

请求出队顺序算法: Prism根据Moore-Hodgson算法【32, An N Job, One Machine Sequencing Algorithm for Minimizing the Number of Late Jobs, 1968】确定请求的出队顺序，该算法旨在最小化错过截止日期的数量。如算法2所示，给定一组请求R，Prism首先按其prefill完成截止日期（即每个请求$r_i$的$a_i + s_i$，其中$a_i$是其到达时间，$s_i$是TTFT SLO）的升序对它们进行排序。然后，对于排序列表中的每个请求，Prism将其附加到调度列表S中，并检查它是否能在其TTFT SLO内完成。具体来说，它检查 $current\_time + e_r \le a_r + s_r$，其中$e_r$表示请求r的prefill时间。$e_r$可以计算为$e_r = p_r/c_r$，其中$p_r$是prompt长度，$c_r$是由模型的块大小配置决定的chunked prefill速度。如果最新添加的请求无法满足其截止日期，Prism会从S中驱逐执行时间最长的请求（第9-11行）。然后它移动到下一个请求并继续这个过程，直到评估完所有请求。最后，Prism按照它们在调度列表中的顺序分派S中接受的请求。

算法2 GPU本地请求调度

要求：n个请求的集合R = {r_1, r_2, ..., r_n}。每个请求r_i有：prompt长度p_i，由其服务模型决定的chunked-prefill速度c_i，TTFT SLO s_i，以及到达时间a_i。
确保：一个请求子集S ⊆ R，可以按顺序执行以最大化TTFT SLO达成率。
1: 按截止日期d_i = a_i + s_i升序对R排序：r_1, r_2, ..., r_n，使得d_1 ≤ d_2 ≤ ... ≤ d_n。
2: 初始化S ← ∅, current_time ← Timer.time()
3: for k = 1 to n do
4:   令r ← r_k, e_r ← p_r/c_r
5:   将r追加到S
6:   更新current_time ← current_time + e_r
7:   if current_time > a_r + s_r then
8:     /* 弹出执行时间最长的请求 */
9:     令r_max ← arg max_{r' ∈ S} p_{r'}/c_{r'}
10:    从S中移除r_max
11:    更新current_time ← current_time - p_{r_max}/c_{r_max}

算法分析: 当chunked-prefill在每个推理步骤都运行prefill时，请求调度确保了最优的TTFT达成率。这是因为在这种情况下，请求r的prefill时间$e_r$可以估计为$e_r = p_r/c_r$，这使我们能够计算序列中任何请求$r_i$的prefill完成时间，公式为$d_{r_i} = a_{r_i} + \sum_{i=1}^{n} p_i/c_r$，其中n是等待处理的请求数量（包括$r_i$）。有了这些信息，我们可以遵循原始Moore-Hodgson算法【13, A Simple Proof of the Moore-Hodgson Algorithm for Minimizing the Number of Late Jobs, 2021】的证明来证明我们调度算法的最优性。prefill在每个推理步骤运行的假设在大多数情况下成立。然而，在极少数情况下，如果KV缓存不足以接纳新请求，prefill可能会暂时暂停，一些正在运行的请求将被抢占。我们的准入控制通过接纳适当数量的请求并为每个引擎预留一个内存缓冲区来缓解这个问题，以确保有足够的空间完成部分请求批次。

A4 实验评估

实现

实现细节: 我们用约10,400行Python代码和774行C++代码实现了一个Prism的原型。我们使用SGLang【64, Efficiently Programming Large Language Models using SGLang, 2023】作为服务后端，并用我们的kvcached库对其进行了扩展，以支持按需内存分配。kvcached使用CUDA VMM API【36, CUDA Toolkit Documentation: Virtual Memory Management., 2025】实现，并通过Python绑定提供了标准的KV缓存分配API（表3）。这些API被设计为与注意力机制和不同推理引擎的架构差异无关，从而实现了无缝集成——我们在SGLang中仅修改了22行代码。对于计算共享，我们将每个模型的MPS百分比配置为100%，允许模型在时间和空间上机会性地共享GPU计算资源。

系统组件: 在前端，我们使用Redis队列【45, Redis List documentation., 2025】来缓存所有客户端的传入请求。Prism的本地调度器根据算法2将这些请求分派给相应模型的服务引擎。对于张量并行模型，GPU本地调度器仅在第一个rank上运行，并将产生的调度决策广播给所有其他rank以确保一致性。Prism的全局调度器作为一个单独的Python进程运行，从每个引擎收集执行指标——如请求率和队列状态。它做出调度决策（如模型驱逐和激活），并使用ZeroMQ【59, ZeroMQ Website., 2025】将它们传达给引擎。

实验环境

硬件配置: 实验在一个由四台节点组成的集群上进行，每台节点配备八块通过600GB/s NVLink互连的NVIDIA H100-80G GPU。这些节点通过100Gbps以太网网络通信。每台节点配备两颗52核的Intel Xeon Platinum 8480+ CPU，1.7 TB的DRAM，以及一个PCIe Gen5 x16接口，为每个GPU连接提供高达64 GB/s的单向带宽。

软件配置: 所有节点运行Ubuntu 22.04和CUDA Toolkit 12.4。

基线系统: 我们将Prism与三个基线系统进行了比较：(1) 静态分区 (S-Partition)，(2) MuxServe++，以及 (3) QLM【40, Queue Management for SLO-Oriented Large Language Model Serving, 2024】。原始的MuxServe【16, MuxServe: Flexible Multiplexing for Efficient Multiple LLM Serving, 2024】基于vLLM构建，仅支持Llama-2模型。我们将其移植到SGLang，并用我们的按需内存分配机制对其进行了扩展，以支持更广泛的模型，称之为MuxServe++。我们仔细调整了MuxServe++，以确保其性能与原始版本相当或更好（校准数据见表5）。

数据集与模型: 我们使用了两个真实世界的追踪数据，即之前在§3.1中分析过的Hyperbolic【26】和Arena-Chat【48, Fairness in Serving Large Language Models, 2024, OSDI】。我们总共评估了58个LLM，详细信息如表4所示。

评估指标: 我们的主要性能指标是TTFT和TPOT的达成率。为了为每个模型建立SLO，我们首先在专用GPU上运行其工作负载，测量其P95的TTFT和TPOT延迟。这个过程产生的TTFT SLO范围从0.04秒到0.13秒，TPOT SLO范围从5.2毫秒到50.9毫秒。然后我们通过一个因子缩放这些基准值，以评估系统在不同延迟要求下的性能。我们还报告了聚合吞吐量，该吞吐量考虑了模型的实际服务时间（不包括空闲时间）。

实验结果

端到端性能

SLO达成率 vs. 请求率: 我们首先在两个共享GPU上服务八个模型，评估Prism在不同推理负载下的性能。如图7（第一行）所示，Prism通过维持显著更高的TTFT SLO达成率，持续优于基线系统。在Hyperbolic追踪数据上，Prism在实现99% SLO达成率的同时，支持的请求数分别比MuxServe++和静态分区多2.3倍和3.5倍。这得益于Prism能根据实时工作负载灵活调整共享策略的能力。QLM的TTFT SLO达成率一直很低，因为它强制所有模型通过交换进行时间共享，这会产生巨大开销并导致严重的SLO违规。

SLO达成率 vs. SLO要求: 图7的中间一行展示了在设置不同SLO目标时的达成率。随着SLO尺度的增大，Prism迅速达到了99%的TTFT和TPOT达成率。相比之下，即使在实验中最大的SLO尺度下，也没有一个基线系统达到99%的TTFT达成率。

SLO达成率 vs. 可用GPU数量: 最后，我们评估了在提供更多GPU时的性能。我们选择了18个模型，包括1B到8B的不同大小。如图7（最后一行）所示，Prism在两个追踪数据上分别仅用四个和五个GPU就达到了99%的TTFT和TPOT达成率，展示了其在提高成本效益同时保持性能方面的有效性。相比之下，所有基线系统即使有八个GPU也未能达到99%的TTFT达成率。

图7：在不同请求率、SLO和可用GPU数量尺度下的端到端性能比较。虚线垂直线标记了系统达到99% TTFT或TPOT达成率的位置。

性能分析

灵活的跨模型内存协调: 我们首先评估了灵活的跨模型内存协调的好处。如图8所示，Prism的按需内存分配使其能够使用更多的内存用于KV缓存，特别是在第20秒之后，当Model1需求低而Model2请求率激增时。更大的KV缓存内存使Prism能够实现更高的吞吐量。这表明Prism的按需内存分配显著提高了内存效率，从而增强了GPU共享的性能。

图8：跨模型内存协调的好处。第一张图显示了请求率。最后两张图显示了两个模型的总KV内存大小和吞吐量。

模型激活速度: 接着，我们测量了Prism激活模型的速度。如图9所示，每一项优化都显著减少了激活延迟。启用所有优化后，Prism可以在0.7秒内加载1B到8B的小模型，一个14B的中等大小模型仅需1.3秒，比基线快5.5倍。对于一个使用TP=8服务的70B模型，Prism可以在1.5秒内激活它。这些结果表明Prism可以在收到新请求时迅速激活被驱逐的模型，有助于减少SLO违规。

全局调度: 接下来，我们评估了全局调度器的好处。如图10a所示，启用全局调度器显著提高了TTFT和TPOT的达成率。从图10b可以看出，启用全局调度器后，负载在两个GPU之间更加均衡，平均每个请求可以访问更多的KV缓存内存。这证明了全局调度器在协调跨GPU资源需求、避免瓶颈并最终提高GPU共享性能方面的能力。

GPU本地调度: 我们还评估了GPU本地调度在协调共享同一GPU的模型之间内存的好处。如图11a所示，启用我们的GPU本地调度将Model2的SLO达成率提高了超过40%。从图11b的队列长度可以看出，当本地调度器启用时，系统优先处理Model2的请求，这些请求更短但有更严格的SLO要求。这显示了GPU本地调度在根据模型的SLO协调内存分配方面的有效性。

大规模部署

SLO达成率 vs. GPU数量: 我们评估了Prism在大规模部署中的成本削减效果，总共使用了32个GPU服务58个模型。如图12a所示，Prism持续优于所有基线系统，仅用16个GPU就达到了近99%的TTFT达成率，而MuxServe++需要32个GPU才能达到类似的性能。QLM的性能未能随GPU数量增加而提升，这与其次优的调度算法有关，该算法在GPU空闲时会触发不必要的模型交换，产生巨大的延迟开销。

成本节省: 图12b显示了每个系统在不同SLO尺度下达到99% SLO达成率所需的GPU数量。当TTFT SLO尺度为5，TPOT SLO尺度为2.0时，Prism仅用16个GPU就达到了99%的TTFT SLO达成率。MuxServe++在SLO尺度≥30时需要20个GPU才能达到99%的TTFT SLO达成率，而静态分区需要更多的GPU或更高的SLO尺度。这表明Prism能够实现超过2倍的成本节省。

图12：大规模部署下的SLO达成率和成本节省。 (b) 达到99% SLO达成率所需的GPU数量。

A7 补充细节

讨论

模型激活时间: 通过所提出的优化（§5.2），Prism可以在0.7秒内激活一个8B模型，在1.5秒内激活一个70B模型，这对于许多服务场景是可以接受的。对于有非常严格TTFT要求的场景，Prism可以选择性地禁用模型驱逐，以牺牲一些成本效益为代价。值得注意的是，下一代GPU硬件，如NVIDIA GH200【37, NVIDIA Grace Hopper Superchip, 2025】，提供了900 GB/s的CPU-GPU互连带宽，这将进一步减少模型激活时间。目前，我们将所有模型权重存储在CPU DRAM中。在需要从SSD磁盘加载模型的场景中，Prism可以应用流水线和并行权重加载等优化，正如最近的工作【19, Cost-Efficient Large Language Model Serving for Multi-Turn Conversations with CachedAttention, 2024, USENIX ATC 24】【60, Fast and Live Model Auto Scaling with O (1) Host Caching, 2024】所探讨的；我们将其留作未来工作。

GPU计算共享: 我们使用MPS，并将每个模型的SM利用率限制设置为100%，以启用GPU计算共享。在这种配置下，MPS允许模型在时间上共享GPU SM，并在空间上机会性地共享。鉴于计算利用率相对于内存争用较低，这种方法在实践中已经运行得很好。未来，我们计划通过动态调整SM限制，将更好的计算资源协调纳入我们的设计中，利用最近引入的技术，如green context【34, CUDA Toolkit Documentation— Green Contexts.】。

使用异构GPU降低服务成本: 一些工作提出通过利用异构GPU来降低LLM服务成本，例如使用低端GPU服务较小的模型【21, Mélange: Cost Efficient Large Language Model Serving by Exploiting GPU Heterogeneity, 2024】【28, Demystifying Cost-Efficiency in LLM Serving over Heterogeneous GPUs, 2025】【63, LLM-PQ: Serving LLM on Heterogeneous Clusters with Phase-Aware Partition and Adaptive Quantization, 2024】。我们认为这是一个正交的方向，并不能完全解决核心问题。首先，在异构GPU上服务LLM在实践中尚未得到广泛采用，因为它引入了新的挑战，如管理异构集群。其次，由于工作负载的可变性，系统仍然必须为峰值需求进行配置，导致与同构集群中相同的资源利用率不足问题。此外，Prism与异构GPU集群兼容，并且可以部署以提高在这种设置中的资源利用率。

A5 结论

大规模服务LLM成本高昂，特别是对于托管许多具有动态和突发性工作负载的模型的提供商。本文介绍了Prism，一个多LLM服务系统，它通过充分发挥GPU共享的能力，在保持SLO达成率的同时提高了成本效益。Prism通过首先实现灵活的跨模型内存协调来实现这一点，这使其能够根据运行时工作负载动态调整GPU共享策略。然后，它采用两级调度算法来有效利用GPU内存，以避免资源瓶颈并最大化延迟性能。在真实世界追踪数据上的评估表明，与最先进的系统相比，Prism实现了超过2倍的成本节省和3.3倍的SLO达成率提升。

A6 附录

算法1分析

KVPR边界分析

算法的KVPR边界保证: 全局模型放置算法确保所有GPU上的最大KV压力比（KVPR）受限于最优放置中的最大KVPR。我们给出以下分析。令$KVPR_{OPT}$为任何最优放置可实现的最小可能最大KVPR。令$KVPR_{max}$为算法1放置产生的最大KVPR。我们希望证明$KVPR_{max}$受限于$KVPR_{OPT}$。

瓶颈分析: 关注在算法1的放置下达到最高KVPR（$KVPR_{max}$）的GPU，记为$g_{max}$。令$m_k$为分配给该GPU $g_{max}$的最后一个模型。令$W_{before}$和$S_{before}$分别表示在分配模型$m_k$之前$g_{max}$上的总SLO加权请求率和共享KV内存。该GPU上的最终状态为$KVPR_{max} = (W_{before} + d_k) / (S_{before} - w_k)$，其中$d_k$是模型$m_k$的SLO加权请求率($r_k/s_k$)，$w_k$是其内存权重。类似于Graham【20, Bounds on Multiprocessing Timing Anomalies, 1969, SIAM Journal on Applied Mathematics】的证明，此证明旨在表明在添加$m_k$之前的状态和$m_k$的贡献都相对于$KVPR_{OPT}$是有界的。具体来说，它试图建立两个概念上的界限：
* 界限1（与添加$m_k$前的状态相关）: 由于算法的贪婪选择，在分配$m_k$之前，$g_{max}$上的KVPR $W_{before} / S_{before}$ 是当时所有GPU中最小的。这个最小的KVPR通常与整个系统的平均“压力”有关，而这个平均压力又被论证为不大于最优最大压力。这表明不等式：$W_{before} / S_{before} \le KVPR_{OPT}$。
* 界限2（与模型$m_k$相关）: 关键模型$m_k$施加的“压力”必须由最优解来处理。最优解的一个基本下界是任何单个模型如果单独放置在空GPU上所施加的最大压力，即$KVPR_{OPT} \ge d_k / (C - w_k)$。

最终边界: 最后一步是整合这些见解以界定$KVPR_{max} = (W_{before} + d_k) / (S_{before} - w_k)$。遵循Graham的证明【20】，我们将这些代入分子，得到$KVPR_{max} \le KVPR_{OPT} \cdot (1 + C / (S_{g_{max}} - w_k))$。

TP支持

TP模型的处理: 算法1中的模型放置算法无缝集成了使用张量并行（TP）的模型。我们将一个需要$tp\_size$个GPU的TP模型概念化为由$tp\_size$个不同的部分组成。为了调度，我们为此类模型在排序后的模型列表中创建$tp\_size$个条目，为每个条目分配原始权重和请求率的$1/tp\_size$。这种分解产生了一个有益的特性：由于这些条目具有相同的$r_k/s_k$值，它们在排序后保持相邻。这种邻接性增加了算法迭代时，由于KVPR上升，这些部分最初被分配到不同GPU的可能性。

确保TP部分的分散放置: 为确保分布，如果将一个TP部分分配给具有最小KVPR的GPU会导致其与同一原始模型的另一部分共置，我们则将其分配给表现出第二低KVPR的GPU。通过这种分解策略和修改后的分配规则，我们的算法有效地考虑和管理了TP模型与单GPU模型的放置。

MuxServe校准

性能对比: 我们使用三个Llama-3.1-8B模型，在不同的请求率（199 req/min, 262 req/min, 22 req/min）下，评估了MuxServe++和MuxServe在10分钟内的性能。所有实验都在相同且一致的条件下进行。结果如表5所示。可以看出，MuxServe++实现了相当甚至更好的性能。

PaperCache

Prism: Unleashing GPU Sharing for Cost-Efficient Multi-LLM Serving

Prism: Unleashing GPU Sharing for Cost-Efficient Multi-LLM Serving

A1 主要贡献

A3 背景知识与关键观察

背景知识