英伟达+斯坦福推出Strata：解决LLM长上下文性能瓶颈，提升效率3.75倍!-CSDN博客

简介

Strata是由英伟达联合多所高校提出的分层上下文缓存框架，用于解决大模型长上下文处理的性能瓶颈。该框架通过GPU辅助I/O机制和缓存感知调度策略，实现了计算与I/O平衡，能够高效处理长上下文。实验表明，Strata在长上下文场景下比vLLM-LMCache的TTFT快5倍，比TensorRT-LLM速度提升3.75倍，且不影响短上下文性能，为长上下文LLM服务提供了高效解决方案。

随着上下文窗口的不断扩大，大型语言模型（LLM）面临着显著的性能瓶颈。尽管键值（KV）缓存对于避免重复计算至关重要，但长上下文缓存的存储开销会迅速超出GPU内存容量，迫使生产系统在多级内存结构中采用分层缓存策略。然而，将大量缓存的上下文重新加载回GPU会引发严重的性能瓶颈：由于分页布局导致数据碎片化，I/O操作无法充分利用带宽；现有调度器未能考虑缓存加载延迟，导致系统受限于加载而非计算能力。

针对上述挑战，**英伟达联合斯坦福大学、上海交通大学等高校的研究者们提出分层上下文缓存框架Strata，高效服务长上下文的大语言模型。**该框架引入GPU辅助的 I/O 机制，以应对KV缓存碎片化。将 GPU 与 CPU 的内存布局解耦，并采用感知缓存的请求调度策略，以平衡计算与 I/O 延迟，同时利用互补任务掩盖不可避免的等待时间。Strata 基于 SGLang 构建，并已在生产环境中部署。在长上下文基准测试中，与vLLM-LMCache相比，Strata 生成第一个token所需的时间（Time-To-First-Token, TTFT）最多快5倍；与 NVIDIA TensorRT-LLM 相比，速度提升达3.75 倍，且不会降低短上下文场景下的性能。

论文标题：

Strata: Hierarchical Context Caching for Long Context Language Model Serving
论文链接：

https://arxiv.org/pdf/2508.18572

一、方法

图4展示了Strata架构。当提交一个请求时，它会进入一个请求等待队列。在当前批次（batch）执行期间，调度器（Scheduler）会持续估算系统可用资源和队列中请求的资源需求，并选择其中的一个子集来组成下一个批次。随后，调度器将该批次发送到GPU执行器，并向缓存控制器发起KV缓存加载请求。在预填充（prefill）批次执行期间，GPU执行器会与缓存控制器同步，确保在执行前特定层的KV缓存已准备就绪。预填充完成后，这些已完成预填充的请求会通过连续批次合并成统一的解码批次。Strata采用预填充与解码（P-D co-location）共存的设计，在同一GPU上交替执行预填充和解码批次，并借鉴SGLang，优先执行预填充批次以缩短首token响应时间，同时构建更大的解码批次以提高吞吐量。最终，缓存控制器能够异步管理KV缓存页备份或移到更低层级的存储中。

（1）高效的 KV 缓存 I/O

Strata采用 GPU 辅助I/O技术，在 CPU 和 GPU 内存之间传输 KV 缓存页，以实现对小规模、碎片化数据的低延迟 I/O。

由碎片化内存布局引起的数据传输效率低下问题也延伸到了其他存储介质。除了小页面外，LLM服务系统在GPU内存池中也倾向于采用层优先（layer-first）的内存布局（如图 6 所示），因为这种布局与 LLM 逐层计算的特性相匹配。然而，这种布局进一步加剧了数据碎片化，不利于批量数据的高效传输。另一种更适合 I/O 的传输友好型布局是将一个页面内的各层连续排列，即页优先（page-first），这对 I/O 更为理想，但会为计算引入一层间接寻址，从而增加内核实现的复杂性。

Strata 利用 GPU 辅助 I/O解决了上述挑战，实现了计算友好型和传输友好型布局之间的近乎零开销的实时转换。为执行布局转换，一个线程只需对其分配的偏移量（offset）应用一个额外的算术运算，以计算正确的目标地址，该操作开销极低。如图 6 所示，此能力解耦内存布局：GPU 可维持其计算友好的层优先布局，而其他介质（如主机内存和外部存储）则可采用页优先布局，以通过更大、连续的数据块最大化传输效率。

GPU 辅助 I/O 的一个挑战是与其它内核并发运行时出现干扰。若没有专用硬件来处理细粒度 I/O 任务，GPU 线程将消耗宝贵的资源（如寄存器文件和执行周期），并可能导致缓存污染。此外，GPU 硬件调度器通常难以有效管理这种资源竞争，可能降低 I/O 操作和并发计算内核的性能。

Strata 并非反复调用标准的 cudaMemcpyAsync API 进行小数据量传输，而是通过启动一个 CUDA 内核来执行 GPU 辅助 I/O 任务。该内核会生成数千个线程，每个线程负责从源端（可以是 GPU 全局内存或 CPU 注册的固定内存）加载一小块数据到其本地寄存器文件，然后将该数据流式传输到目标端（同样可以是 GPU 全局内存或 CPU 注册的固定内存）。为了减少 I/O 任务对并发计算负载的干扰，Strata 采用了一种资源隔离策略：启动少量大型 CUDA 块，以激励 GPU 硬件调度器将这些 I/O 内核限制在少数流式多处理器(Streaming Multiprocessors,SMs)上，最少可至 1 个 SM。这种定向分配，结合绕过缓存的底层指令以减轻缓存污染。此外，在 ROCm 后端，这些内核实现也兼容 AMD GPU。

（2）缓存感知调度

调度器的目标是通过避免延迟命中（delay hit）和加载停顿（loading stall），最大化缓存带来的性能收益。为此，调度器通过三个阶段实现这一目标。

1）避免延迟命中产生的影响

延迟命中会在两种情况下导致冗余计算：

(i) 当多个共享相同缓存未命中的请求被安排进同一个批次时；

(ii) 当请求的异步执行准备过程未能感知到相应上下文缓存仍在计算时。

为了跟踪潜在的延迟命中，研究团队在HiRadixTree中引入了临时节点（transient nodes）。与标准节点类似，它们使用token ID作为遍历键，但不指向内存索引，而是携带以下两种标记之一：“in-queue”（表示当前请求正在引用新上下文）；“in-flight”（表示对应token的缓存正处于计算状态）。

在遍历请求队列时，Strata会根据需要插入标记为“in-queue”的临时节点。如果一个请求匹配到已存在的临时节点，则该请求将被推迟到下一轮调度周期但会被置于等待队列的前端，以便利用缓存同时最小化对TTFT的影响。

当一个请求进入执行阶段时，其关联的临时节点被标记为“in-flight”。执行完成后，这些节点被转换为标准节点，其索引指向内存中已就绪的上下文缓存。

为防止不必要的推迟，Strata采用了一个可配置的阈值：仅当请求在临时节点上的token匹配数量超过此阈值时，才会被推迟。实践中，设置默认阈值为100个活跃token匹配已被证明是有效的。

图7. Strata的调度策略，其中橙色块表示经历缓存未命中的预填充批次，绿色表示设备上的缓存命中（Cache Hit ），紫色表示主机内存上的缓存命中，蓝色表示数据传输，而正在解码的批次则用灰色表示。

2）均衡批次构建

移除了易受延迟命中影响的候选请求后，调度器选择剩余请求以形成下一个预填充批次。在大多数LLM服务引擎中，批次的形成默认遵循FIFO策略，即按请求到达顺序依次选取，直到批次满载（达到预设的token限制或耗尽GPU内存）。为了应对加载受限问题，Strata引入了一种新的批次构建机制，旨在平衡数据加载与足够的计算量。

如图7所示，包含请求C和D0的批次需要加载两个上下文，这会导致加载停顿。相比之下，形成不同的批次（C, F）则可以重叠C的加载过程。另一个新批次（D0, D1）：由于它们共享相同的上下文，将它们组合成一个批次不仅能够平衡加载与计算，还能减少GPU内存使用和设备的带宽压力，进一步提升效率。将这种情况称为捆绑命中（bundle hit），与延迟命中相反。

详细过程如算法1所示。在每次形成批次之前，调度器使用HiRadixTree获取每个请求的加载和计算需求。在批次形成过程中，调度器遍历请求队列，检查添加某个请求是否会达到加载受限的界限（第10行），该界限定义为总加载量与总计算量的比率。当该比率超过某一阈值时，该批次被视为加载受限。该阈值取决于硬件和模型，因此可以单独进行性能分析。实践中，Strata使用默认比率为100。

如果添加某个请求不会使该批次加载受限，则将其加入该批次，然后调度器会遍历其余所有请求，优先添加那些能与当前请求发生捆绑命中的请求。否则，该请求将被移至一个降级列表。如果遍历完队列后批次仍未填满，调度器将用降级列表中的请求补充（第16行）。为防止请求饥饿，降级列表中的请求保持原有顺序，且每次批次形成都从队列中的第一个请求开始。

3）通过气泡填充隐藏加载延迟

即使在均衡批次构建的情况下，部分批次仍可能受限于加载延迟。调度器的最终策略是采用气泡填充（bubble filling），将加载延迟与有效计算重叠执行。如图7所示：当请求G需要加载长上下文时，调度器暂缓已就绪的预填充批次计算，转而向模型执行器发送解码批次，使其与上下文加载过程并行执行。该策略补充了SGLang默认的预填充优先策略，通过在预填充与解码间灵活选择来提升整体利用率。

虽然解码批次同样受I/O限制，但其主要占用HBM带宽，而加载任务主要占用PCIe带宽。这种差异使得两种操作能以最小资源竞争实现重叠执行。若系统存在可用资源，也可以插入预填充批次来填充气泡，这种方法在预填充-解码解耦架构中将更具适用性。

二、评估

图8展示了在Llama-3.1-8B-Instruct、Qwen2.5-14B-Instruct-1M、Llama-3.1-70B-Instruct三种模型和LooGLE、NarrativeQA、ReviewMT 、ShareGPT四个数据集上，不同请求速率下各系统实现的token吞吐量以及相应的平均TTFT。

分层缓存对于高性能的长上下文服务至关重要。在所有三个模型上，非分层缓存方案在LooGLE数据集上的表现都很差。如果没有分层缓存，长上下文工作负载会迅速耗尽GPU内存容量，导致预填充阶段频繁出现缓存未命中。这反过来又触发了重复计算，造成吞吐量低下和延迟升高。相比之下，配备了分层缓存的系统实现了更高的吞吐量和更低的延迟，并通过利用CPU内存，持续达到了约95%的缓存命中率。

Strata 在现有分层缓存方案的基础上实现了显著提升。在LooGLE数据集任务上的Llama-8B模型，与SGLang-HiCache、vLLM-LMCache和TensorRT-HiCache相比，Strata在相同TTFT下分别实现了3.2倍、2.6倍和1.9倍的吞吐量提升；使用Qwen-14B时，Strata最高实现了3.9倍、2.1倍和1.9倍的提升；在Llama-70B上，增益分别达到5倍、5倍和3.75倍。

在ReviewMT数据集上也能观察到一致的趋势。尽管更长的解码过程降低了预填充时间的主导地位，但使用Llama-8B时，Strata仍比vLLM-LMCache和TensorRT-HiCache快2.3倍，比SGLang-HiCache快1.7倍。这些性能提升源于Strata增强的I/O效率和调度机制。

NarrativeQA 数据集的平均上下文长度更长，导致预填充阶段非常耗时，使得非分层缓存方案变得不切实际。由于该场景带来的内存压力最大，研究团队对该实验进行了扩展，以更好地理解缓存层次结构被填满后的状态。在此设置中，首先通过对评估集中所有上下文预先计算 KV 缓存来预热 CPU 内存，然后清空 GPU 内存中的 KV 缓存，以设定初始状态。

图8的第二行报告了在预热完成后重启工作负载所得到的吞吐量-延迟曲线，TensorRT-HiCache 不支持预热功能。可以看出，Strata 相比 vLLM-LMCache，在 Llama-8B、Qwen-14B 和 Llama-70B 模型上的吞吐量分别最高提升了 2.3 倍、2.6 倍和 2.5 倍。

Strata 是专为长上下文工作负载设计的系统。为评估其在短上下文负载下的表现，图8最后一行展示了 ShareGPT 数据集上三个模型下各基线系统的平均首token生成时间。由于内核实现的差异， SGLang底层引擎在 Llama-8B 和 Llama-70B 模型上的性能略逊于 vLLM 和 TensorRT-LLM 的基础引擎。考虑上述差异后，Strata 在短上下文工作负载下的表现与SOTA系统相当。

三、AI大模型从0到精通全套学习大礼包

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

只要你是真心想学AI大模型，我这份资料就可以无偿共享给你学习。大模型行业确实也需要更多的有志之士加入进来，我也真心希望帮助大家学好这门技术，如果日后有什么学习上的问题，欢迎找我交流，有技术上面的问题，我是很愿意去帮助大家的！

如果你也想通过学大模型技术去帮助就业和转行，可以扫描下方链接👇👇
大模型重磅福利：入门进阶全套104G学习资源包免费分享！
在这里插入图片描述

01.从入门到精通的全套视频教程

包含提示词工程、RAG、Agent等技术点
在这里插入图片描述

02.AI大模型学习路线图（还有视频解说）

全过程AI大模型学习路线

在这里插入图片描述

03.学习电子书籍和技术文档

市面上的大模型书籍确实太多了，这些是我精选出来的

在这里插入图片描述

04.大模型面试题目详解

在这里插入图片描述

05.这些资料真的有用吗?

这份资料由我和鲁为民博士共同整理，鲁为民博士先后获得了北京清华大学学士和美国加州理工学院博士学位，在包括IEEE Transactions等学术期刊和诸多国际会议上发表了超过50篇学术论文、取得了多项美国和中国发明专利，同时还斩获了吴文俊人工智能科学技术奖。目前我正在和鲁博士共同进行人工智能的研究。

所有的视频由智泊AI老师录制，且资料与智泊AI共享，相互补充。这份学习大礼包应该算是现在最全面的大模型学习资料了。

资料内容涵盖了从入门到进阶的各类视频教程和实战项目，无论你是小白还是有些技术基础的，这份资料都绝对能帮助你提升薪资待遇，转行大模型岗位。

在这里插入图片描述