ICDCS 2026 | RcLLM：突破前缀缓存限制，加速生成式推荐

该研究面向大语言模型驱动的生成式推荐，关注长输入带来的在线推理延迟：不同推荐请求往往包含重复的用户历史或候选商品信息，但这些内容在输入中的位置和组合会不断变化，现有 Prefix Caching 难以充分复用已有计算。为此，研究提出分布式推理系统 RcLLM，将 KV Cache 的复用范围从共同前缀扩展到非前缀内容，并结合分层缓存管理、缓存感知的请求调度与选择性重计算，在控制推荐质量变化的同时减少重复计算，缩短用户等待推荐结果的时间，为大模型推荐服务的高效部署提供系统层面的优化方案。

论文题目：
RcLLM: Accelerating Generative Recommendation via Beyond-Prefix KV Caching
论文链接：
https://arxiv.org/abs/2605.07443

摘要

大语言模型能够结合用户评论、历史行为和商品描述生成个性化推荐，但这些信息也使输入越来越长。现有 Prefix Caching 要求请求从开头共享相同内容，难以复用位于不同用户历史之后、顺序又经常变化的商品描述。结果是，同一段商品内容可能被反复计算，成为在线推荐的延迟来源。

RcLLM 通过 Beyond-Prefix KV Caching 将复用范围扩展到非前缀内容，并结合分层缓存、缓存感知调度与选择性重计算，在减少在线计算的同时控制推荐质量变化。在默认 40 实例配置的性能仿真中，RcLLM 相比 Prefix-Cache 在两种模型和三个数据集上的 P99 首 token 延迟获得 1.4–2.8 倍加速，为高效部署大模型推荐提供了新的系统设计思路。

一、背景与动机

在基于大语言模型的推荐场景中，系统会把任务指令、用户历史和候选商品一起组织成 Prompt，再由模型理解用户偏好并输出排序。例如，在图书推荐中，模型可以综合用户过去的评论与候选图书的内容介绍，判断哪些图书更符合当前需求。图 1 展示了这种输入结构。

图 1 : 生成式推荐的输入与输出。任务指令、用户历史和候选商品共同构成 Prompt，模型据此生成推荐排序。

这类任务通常需要读取数千个 token，最后只输出一份较短的商品列表。其主要开销集中在 Prefill 阶段：模型要先处理完整输入，为各个 token 建立 Key 和 Value 状态，才能开始生成结果。后续 Decode 阶段则复用这些 KV Cache，逐个生成输出。因此，首 token 延迟（Time-To-First-Token，TTFT）直接影响用户等待推荐结果的时间。图 2 给出了两个阶段的关系。

图 2 : 大语言模型的自回归推理流程。Prefill 处理输入并建立 KV Cache，Decode 利用已有状态继续生成。

问题在于，不同请求中存在大量重复内容，却未必满足前缀复用的条件。两位用户可能看到同一本书，但各自的历史记录不同，图书描述在 Prompt 中的位置也可能改变。传统 Prefix Caching 只能复用从开头连续匹配的部分，因而难以利用这些分散的重复内容。RcLLM 的出发点，是让复用围绕内容本身展开，减少由输入位置和排列变化引起的重复计算。

二、技术挑战

将这一思路用于推荐服务，需要同时解决缓存规模、执行效率和推荐质量三个相互关联的问题。

首先，缓存需要适应不同类型的数据。用户评论在文字上各不相同，却具有相似的语义表达；商品标题和描述相对稳定，可以提前处理，但整个商品库的 KV 状态可能达到 TB 级。如何同时利用语义相似性和商品重复性，并控制存储成本，是实现跨请求复用的基础。

其次，缓存分布在不同节点后，请求应发往哪里会直接影响收益。选择本地缓存较多的节点能够减少重计算，但热门节点可能出现排队；只选择最空闲的节点，又可能频繁遇到缓存缺失。调度必须同时考虑缓存位置与当前负载。

最后，复用后的状态需要适应当前上下文。一个商品出现在不同用户历史之后，其位置和需要关注的信息都会变化。直接拼接独立计算的 KV 块可能影响商品排序，因此系统还需要识别并更新关键内容，在计算量与推荐质量之间取得平衡。

三、RcLLM 的核心方法

针对上述挑战，RcLLM 将缓存准备放到离线阶段，在请求到达后完成缓存选择、请求调度和必要的状态更新。图 3 展示了整体架构：CPU 内存保存可复用的历史与商品 KV，Global Scheduler 选择执行节点，GPU 上的 Selective Attention 对关键位置进行重计算。

图 3 : RcLLM 整体架构。离线阶段准备两类缓存；在线阶段结合节点选择、缓存读取和 Selective Attention 完成推理。

3.1 分层缓存覆盖用户历史与候选商品

对用户历史，RcLLM 利用评论中反复出现的语义表达。图 4 左侧显示，不同评分的评论 token 呈现明显的语义聚类；右侧进一步表明，在所分析的 Amazon 数据中，超过 93% 的新评论 token 能在历史语义池中找到相似度接近 1 的匹配。

图 4 : 用户历史中的语义复用机会。左图为 1 星与 5 星评论中 token 的语义分布，右图为新评论 token 与历史池的最大相似度累积分布。

基于这一观察，系统将语义和位置信息一起编码，借助 Locality-Sensitive Hashing（LSH，局部敏感哈希）构建紧凑的语义原型库，并预计算对应的 KV 状态。在线请求通过近邻匹配复用这些状态。该缓存池在 Qwen3-8B 下包含约 10⁵ 个原型、占用约 30 GB，复制到各节点的 CPU 内存，使历史缓存可以在本地访问。

候选商品采用另一种组织方式。商品标题、描述等内容通常在请求到达前已知，可以按商品预计算 KV。但以 100 万件商品、每件 100 个 token 为例，Qwen3-8B 的完整商品缓存约需 27.5 TB，难以在每个节点保存一份。图 5 显示，商品热度呈长尾分布，为区别处理热门商品和长尾商品提供了依据。

图 5 : Amazon、Yelp 和 Goodreads 的商品热度分布。横轴为商品评论数，采用对数刻度；纵轴为累积比例。

RcLLM 将最热门的 0.1% 商品复制到所有实例，其余商品按共现关系分片。具体而言，系统构建商品关联图，再通过 METIS 划分，使经常共同出现在请求中的商品尽可能存放在同一节点。这样既降低单节点存储压力，也提高一次请求在本地找到所需缓存的机会。

3.2 缓存感知调度兼顾命中率与负载

请求到达后，Global Scheduler 为各节点计算 affinity score，综合预计商品缓存命中率与节点空闲程度，选择执行位置。缓存命中能够减少计算，负载均衡则避免请求在热门节点长时间排队，两者共同决定实际延迟。

执行节点随后读取匹配的历史和商品 KV，缓存缺失的内容即时计算。任务指令以及时间戳、商品 ID 等请求专属信息仍完整计算，以保留当前推荐任务的要求。系统通过逻辑位置到物理缓存块的映射组织非连续 KV，减少额外拼接拷贝。

3.3 选择性重计算保留关键上下文

缓存复用会引入近似，RcLLM 因此把部分计算预算留给影响排序的关键位置。图 6 中的 Attention 分布显示，商品内部主要关注相邻内容，同时存在少量跨越较长距离的关注位置。这些 heavy hitters 包括部分任务指令和分隔符，承担着连接全局上下文的作用。

图 6 : Qwen3-8B 的平均 Attention 分布。局部结构与少量全局关注位置，为选择性重计算提供依据。

RcLLM 在首个 decoder layer 执行完整 Attention，识别重要 token，并结合缓存偏差确定需要更新的历史状态；随后各层对关键位置和局部窗口精确重计算，其余部分继续复用。位置对齐与重计算共同修正跨上下文复用的误差。系统还让首层计算与 CPU 到 GPU 的缓存传输重叠，降低数据搬运带来的等待。

四、主要实验结果 4.1 实验设置

实验采用 Amazon Reviews、Yelp 和 Goodreads 三个公开数据集。分布式服务性能通过扩展 Vidur 推理仿真器评估，模拟缓存放置、请求排队、PCIe 传输和 100 Gbps 网络；推荐质量则通过基于 Hugging Face Transformers 的 Qwen3-8B 功能原型验证。

默认集群包含 40 个实例。Qwen3-8B 每实例配置一张 80 GB A100，Qwen-72B 每实例使用四张 A100 进行 Tensor Parallelism。延迟对比包括完整重计算 Full-Recompute 与前缀复用 Prefix-Cache；质量评估还比较了 CacheBlend 和 EPIC。

4.2 两种模型均获得更低的首 token 延迟

在默认配置下，相比 Prefix-Cache，Qwen3-8B 的中位数（P50）TTFT 获得 1.5–2.2 倍加速，尾部（P99）获得 1.4–2.4 倍加速。图 7 中，RcLLM 的曲线整体向左移动，说明在三个数据集上，更多请求可以更早开始生成结果。

图 7 : Qwen3-8B 的 TTFT 累积分布，集群为 40 实例。各子图依次为 Amazon、Yelp 和 Goodreads，曲线越靠左表示延迟越低。

对 Qwen-72B，P50 与 P99 的加速比分别为 1.3–2.1 倍和 1.4–2.8 倍，如图 8 所示。这里的加速比为基线延迟除以 RcLLM 延迟。收益来自更广的复用范围：在实验轨迹中，固定前缀仅占输入的约 7%–10%，候选商品与用户历史则占据主要部分，RcLLM 能够利用这两部分中的重复内容。

图 8 : Qwen-72B 在 40 实例配置下的 TTFT 累积分布。各子图依次为 Amazon、Yelp 和 Goodreads。

4.3 通过重计算预算调节推荐质量

更快的响应也需要保留有效的排序信息。实验采用 HR 衡量推荐命中情况，并用 NDCG 同时考虑相关商品的排序位置，两项指标均为数值越高越好。在 Amazon 上，当商品与历史 token 均重计算 30% 时，相比 Full-Recompute，RcLLM 的 HR@10 从 0.700 提升至 0.740，NDCG@10 从 0.403 提升至 0.438。

不同数据集对复用的敏感程度有所差异。在 Goodreads 上，商品与历史 token 分别重计算 30% 和 20% 时，HR@10 与完整计算相同，均为 0.776；NDCG@20 从 0.484 降至 0.468，保留约 96.7%。在 Yelp 上，两类 token 分别重计算 40% 和 50% 时，HR@10 从 0.698 提升至 0.744，但 NDCG@10 从 0.477 降至 0.407，说明命中率和排序质量需要分别观察。

这些结果表明，重计算预算需要结合数据集与目标指标选择。图 9 以 Amazon 为例展示了两类重计算比例的联合影响，为选择质量与效率之间的合适配置提供依据。

图 9 : Amazon 上的重计算预算与 NDCG@20 差异。横轴为商品 token 比例，纵轴为历史 token 比例；格内数值表示 RcLLM 减去 Full-Recompute 的结果，越高越好。

4.4 分布式缓存兼顾扩展性与存储成本

当实例数从 1 增加到 100，RcLLM 仍保持对 Prefix-Cache 的加速优势。图 10 展示了不同集群规模下的结果；Qwen3-8B 与 Qwen-72B 的 P99 最高分别获得约 3.5 倍和 9.5 倍加速，这些最高值对应扩展性实验中的特定配置。

图 10 : 不同集群规模下的 TTFT 加速比。上排为 Qwen3-8B，下排为 Qwen-72B，各列依次为 Amazon、Yelp 和 Goodreads。虚线表示 Prefix-Cache。

分片带来的另一项收益是单节点存储下降。图 11 显示，Amazon 每实例保存的商品 token 数由单实例时约 6600 万降至 40 实例时约 170 万。同时，缓存仍保持较高命中率，说明相似度感知放置能够在减少存储复制的同时保留局部性。

图 11 : 集群扩展时的缓存命中率与存储占用。左图为商品缓存命中率；右图为每实例保存的商品 token 数，以千 token 为单位并采用对数刻度。

4.5 调度与重计算共同影响服务效率

图 12 对比了只关注命中率的 Hit-Only、只关注负载的 Load-Only 和 RcLLM 的联合调度策略。随着请求强度增加，Hit-Only 容易在热门节点产生排队，Load-Only 则可能增加缓存缺失。综合考虑两者的 RcLLM 在不同负载下获得最低或接近最低的平均 TTFT。

图 12 : 不同调度策略的平均 TTFT，集群为 10 实例。三个子图依次为 Amazon、Yelp 和 Goodreads，横轴 QPS 表示每秒请求数。

重计算预算同样影响响应速度。图 13 显示，预算增大时 TTFT 曲线逐步右移。在 Amazon、Qwen3-8B 和 40 实例配置下，商品与历史均重计算 30% 时，P90 TTFT 从 Prefix-Cache 的 0.38 秒降至 0.18 秒。结合质量评估，系统可以按目标指标选择预算，在保留必要上下文计算的同时获得延迟收益。

图 13 : 重计算比例对 TTFT 的影响。Qwen3-8B、40 实例配置，历史与商品采用相同重计算比例；灰色虚线为 Prefix-Cache。

五、总结与展望

RcLLM 将生成式推荐中的重复内容转化为可共享的计算资源：通过语义历史缓存复用相似表达，通过商品缓存分片支撑大规模目录，再以缓存感知调度和选择性重计算兼顾执行效率与推荐质量。实验表明，这一设计能够在不同数据集、模型规模和集群配置下减少冗余 Prefill，降低首 token 延迟。

这项工作的启示是，面向大模型应用的推理优化，可以进一步利用任务输入自身的结构。对于具有大量重复商品与相似历史表达的推荐场景，内容复用、数据放置和请求调度需要协同设计，才能把缓存命中转化为实际的服务效率。

-The End-

扫码观看！

本周上新！

“AI技术流”原创投稿计划

TechBeat是由将门创投建立的AI学习社区（www.techbeat.net）。社区上线700+期talk视频，3000+篇技术干货文章，方向覆盖CV/NLP/ML/Robotis等；每月定期举办顶会及其他线上交流活动，不定期举办技术人线下聚会交流活动。我们正在努力成为AI人才喜爱的高质量、知识型交流平台，希望为AI人才打造更专业的服务和体验，加速并陪伴其成长。

投稿内容

// 最新技术解读/系统性知识分享 //

// 前沿资讯解说/心得经历讲述 //

投稿须知

稿件需要为原创文章，并标明作者信息。

我们会选择部分在深度技术解析及科研心得方向，对用户启发更大的文章，做原创性内容奖励

投稿方式

发送邮件到

yimingzhang@thejiangmen.com

或添加工作人员微信（aceyiming）投稿，沟通投稿详情

关于我“门”

将门是一家以专注于数智核心科技领域的新型创投机构，也是北京市标杆型孵化器。 公司致力于通过连接技术与商业，发掘和培育具有全球影响力的科技创新企业，推动企业创新发展与产业升级。

将门成立于2015年底，创始团队由微软创投在中国的创始团队原班人马构建而成，曾为微软优选和深度孵化了126家创新的技术型创业公司。

如果您是技术领域的初创企业，不仅想获得投资，还希望获得一系列持续性、有价值的投后服务，欢迎发送或者推荐项目给我“门”:

bp@thejiangmen.com

点击右上角，把文章分享到朋友圈