重算反而省算力：长上下文下KV Cache与局部重计算的博弈

我需要先说明一点写这篇文章之前我把标题里的 DeepSeek V4.1 当作一个代号来理解它描述的是当前主流 LLM 推理服务里一类非常有代表性的优化思路——局部重计算Replay。我手头并没有深挖这套私有系统的源码但这类技术在开源社区和工业界已经有大量同构实现。换句话说这篇文章讲的是一个通用且已经被验证过的工程范式而不是某个产品的使用说明书。做得久了你会发现LLM 推理优化这个领域最迷人的地方就是它到处充满了反直觉显存不够了不加大显存反而是少缓存一点算力不够了不多算反而是重算一下更省。为什么重算一小段输入反而能省下大量计算这个标题本身就是一个绝佳的引子——今天我们就顺着这条线把 KV Cache 到底贵在哪、Replay 为什么能在某些场景下省钱、以及它背后的 Roofline 模型逻辑一次说透。1. 从缓存说起KV Cache 到底贵在哪1.1 缓存不是免费的它是一笔显存账先给不太熟悉 LLM 推理链路的朋友补个基础。无论是 ChatGPT 类的对话模型还是自研的生成模型推理过程都分成两个阶段Prefill预填充和Decode逐字生成。Prefill 把用户输入的 Prompt 一次性喂给模型产出第一个 token同时把每一层 Transformer 的 K 和 V 矩阵Key 矩阵和 Value 矩阵保存下来Decode 阶段每生成一个新 token都要拿着新的 Query 去跟历史所有的 K、V 做 Attention因此历史上所有 token 对应的 K、V 必须常驻显存这就是 KV Cache 的由来。听起来很简单缓存嘛空间换时间多存点中间结果省得每次重新算。但工程上的账从来不是这么算的。KV Cache 有三个绕不开的痛第一个痛是显存成本随上下文长度线性增长。以一个大模型为例假设层数 L80KV 头数 G8每个头的维度 H128那么每个 token 每层要存的 KV 大小是 8 × 128 × 2 × 2 字节 8 KB。这还只是一个 token。如果用户传了一个 128K 长度的上下文单个请求的 KV Cache 就能吃掉约 1 GB 显存。你可能会觉得 1 GB 不算多但要知道这是一次请求的量。生产环境里并发拉到 16 路、32 路显存瞬间就爆了。第二个痛是KV Cache 重读的带宽开销。Decode 阶段是逐个 token 生成的每个新 token 都需要对整个历史序列的 KV Cache 做一次完整读取。换句话说显存的容量压力和带宽压力是同时存在的。我见过不少新手只盯着显存容量调参结果容量压下来了吞吐反而掉了一半——瓶颈转移到了 HBM 带宽上。具体到 NVIDIA 的 GPUH100 的显存带宽大约是 3.35 TB/s而 A100 只有 2 TB/s 左右。一旦 KV Cache 的读取量超过了带宽能承载的极限无论你把计算单元用得多满生成速度都会被死死摁住。第三个痛是缓存的生命周期管理。动态 batch 里有的请求生成了 20 个 token 就结束了有的还在持续生成新加入的请求又要抢占显存。KV Cache 的碎片化问题、显存预留问题、OOM 回退机制每一样都让人头疼。你会发现KV Cache 本质上是在用容量换算力但这个交换的汇率在长上下文和高并发场景下越来越不划算。1.2 一个让我印象深刻的线上事故有一家做文档问答的朋友他们部署了一个 70B 级别的开源模型显存是 8 卡 80GB 的 A100。刚开始他们用最简单的静态显存分配把 KV Cache 预留到最大跑短上下文一点问题没有。后来用户开始上传长 PDF上下文从 2K 涨到 32K问题就来了显存预留过大导致 batch 上不去GPU 利用率只有 20% 左右长上下文请求的 KV Cache 占满显存后新请求要排队等显存释放时延肉眼可见地飙升最离谱的是8 卡里有一半的卡显存很空但因为负载均衡策略不感知 KV Cache 的实际占用流量还是往满的卡上打导致频繁 OOM。后来他们尝试把缓存策略改成动态分配稍微缓解了容量问题但带宽瓶颈又出现了——32K 上下文的 KV Cache 每次 decode 要读取的量太大单 token 生成延迟从 40ms 涨到了 130ms。这个例子让我意识到一件事只盯着减少计算量是不够的KV Cache 的工程优化核心其实是减少显存和带宽的开销。Replay 这类方案的思路恰恰是既然缓存有这么多隐性成本那我干脆在特定条件下就不缓存了改为局部重算反而可能更划算。2. Replay 的底层逻辑为什么重算反而省钱2.1 用 Roofline 模型量化算 vs 访存要说清楚 Replay 为什么划算必须搬出 Roofline 模型。这个模型在传统 HPC 里是评估算法性能的标配但用在 LLM 推理优化上恰好能说明重算比读缓存快的临界条件。GPU 有两个核心指标峰值算力FLOPs/s和显存带宽Byte/s。两者之比称为算术强度Arithmetic Intensity单位是 FLOPs/Byte它代表 GPU 每读取一个字节可以执行的浮点运算次数。对于 H100 SXM 来说FP16 稠密算力约 989 TFLOPSHBM 带宽约 3.35 TB/s算术强度大约是 295 FLOPs/Byte。这是一个非常重要的参考数字。KV Cache 的存取是典型的访存密集型操作它把一个 token 的 K、V 从 HBM 搬到片上 SRAM这个过程中计算量几乎为零纯粹是搬运字节。而 Attention 计算本身是计算密集型矩阵乘法和 Softmax 充分利用了算力单元。Replay 的本质就是把一部分访存密集型的 KV Cache 读取替换成计算密集型的 K/V 重算和 Attention 重算。那什么时候替换最划算核心不等式是这样的重算耗时 ≈ 重算所需的 FLOPs / GPU 峰值算力 读取耗时 ≈ KV Cache 字节数 / 显存带宽当重算耗时低于读取耗时即满足以下条件时Replay 就是正向优化重算 FLOPs / 读取字节数 峰值算力 / 显存带宽约 295看到没有关键就在于重算 FLOPs / 读取字节数这个比值是否低于硬件平台的算术强度阈值。2.2 长上下文里的惊人反转接下来是我认为整个 Replay 最精彩的地方。你可能觉得重算一个 token 的 K/V 矩阵怎么也得算上整个序列长度的注意力吧FLOPs 肯定爆炸。但在长上下文场景下恰恰相反。先算重算代价。对于 Transformer 的某一层重算单个 token 的 K或 V只需要做一次线性变换输入向量维度 d_model乘上权重矩阵d_model × d_headFLOPs 大约是 2 × d_model × d_head。这个数字跟上下文长度 M 没有关系它是常数。再算后续的 Attention 计算。如果我们要重新生成第 M1 个 token 的 Attention 输出需要拿它的 Query维度 d_head跟前面 M 个 token 的 K 做点积再做 Softmax最后对 V 做加权求和。这部分 FLOPs 是 O(M × d_head)。这意味着如果 Replay 需要从第 0 个 token 开始重算那代价确实和序列长度线性相关没有优势但如果只重算最近一小段 token比如最后几十个成本就是一个常数项 C 一个小窗口 W × d_head看起来仍然远远小于老老实实读取整段 KV Cache 的字节量。我先把两者比较用直观的公式写出来。假设重算窗口大小是 W比如 32 或 64 个 token模型的层数是 L每层的 K/V 维度是 H重算成本FLOPs≈ L × W × (2 × d_model × d_head W × d_head) 窗口内 Attention 读取成本Byte≈ L × W × (2 × d_head × dtype_size) 整段 KV Cache把具体数字代进去。以某主流 70B 级模型为例L80d_head128dtype_size2FP16取 W64d_model8192重算成本 ≈ 80 × 64 × (2 × 8192 × 128 64 × 128) ≈ 80 × 64 × (2.1M 8.2K) ≈ 107 亿 FLOPs读取成本 ≈ 80 × 64 × (2 × 128 × 2) ≈ 80 × 64 × 512 ≈ 262 万字节 2.6 MB两者比值 ≈ 107 亿 / 262 万 ≈ 4072 FLOPs/Byte等一下4072 远大于 295 的算术强度阈值这说明如果真要把这 64 个 token 的 KV Cache 整段换成重算反而是不划算的。你可能觉得那 Replay 就是伪命题了但注意这个公式是把重算窗口内每个 token 的 Attention 都重算一遍作为代价而实际工程中 Replay 并非每次都触发全窗口重算。这里的关键区别在于大部分情况下模型只需要重算最近一小段 token 的 K/V 及 Attention 结果而不是重算整段输入而 KV Cache 的读取成本是按所有历史 token累计的。当上下文长度 M 远大于重算窗口 W 时读取成本是 O(M)重算成本是 O(M_重算 W²)只要 M 足够大重算优势就出来了。举个例子M128K 上下文KV Cache 读取字节数约为 L × M × (2 × d_head × 2) 80 × 131072 × 512 ≈ 5.4 GB。而如果只重算最后 32 个 token重算 FLOPs 约为 80 × 32 × (2.1M 32 × 128) ≈ 80 × 32 × 2.1M ≈ 53.8 亿 FLOPs。在 H100 上这个 FLOPs 大约耗时 53.8e9 / 989e12 ≈ 0.05ms而读取 5.4 GB 的 KV Cache 在 3.35 TB/s 带宽下耗时约 1.6ms。即使把重算效率打个折实际矩阵运算达不到峰值算力通常只有 40%~60%0.08~0.12ms 也远低于 1.6ms。这就是标题里那个重算一小段输入反而省下大量计算的数学解释——在极长上下文的场景下KV Cache 的读带宽成本是 O(M)而重算窗口的成本是 O(W²)当 M ≫ W 时后者的优势是数量级的。2.3 类比一下你是选翻笔记本还是重新心算拿一个生活化的例子帮助理解。假设你在做一道需要连续推导的数学题已经写了满满十页草稿纸。现在要验证最后一行的结果你可以方案 A从第一页开始把十页草稿的每一步重算一遍全量重算——这显然很蠢。 方案 B翻了十页纸找到中间某一步的结果然后只基于这个结果往后推读取 KV Cache——这是常规做法。 方案 C最后一行只依赖最后几步推导那与其在十页纸里找那几行不如直接心算最后几步甚至比翻纸还快Replay 窗口。方案 C 成立的原因有两个一是找纸这个动作越来越贵显存带宽瓶颈二是心算最后几步的成本与总页数无关重算窗口与历史长度无关。顺着这个类比你会发现Replay 并不是盲目推翻缓存而是一种选择性失效只在读取缓存比重新计算更贵的局部区域主动放弃缓存。3. Replay 的工程落点什么时候真正用得上3.1 典型场景一长上下文对话的 Decode 阶段先别急着否定我上面算的 128K 上下文场景并不是刻意堆出来的极端数。现在的对话应用动辄支持 100K 以上的上下文用户一上来就传了一本几十万字的文档并要求模型基于全文回答问题。这种长文档场景KV Cache 的读取成本非常可观。实际工程中我见过一个比较实用的做法维护一个最近重算窗口大小通常在 16~64 个 token 之间。每次生成新 token 之前系统会评估两笔开销开销1 从显存读取全部历史 KV Cache 的预估耗时与上下文长度正相关 开销2 隐式重算最近 W 个 token 的 K/V 及 Attention 的预估耗时与窗口大小正相关与总上下文长度弱相关当开销1 开销2时触发 Replay。核心逻辑就是用极小的重算窗口替代全长的 KV Cache 读取让 decode 的时延从受上下文长度约束变成受局部窗口约束。不过这里有个很好玩的细节重算窗口太小FLOPs 也许不大但 W 太短也会有问题。比如 W 只有 1 个 token那相当于只重算最后一个位置。可是 Attention 本身需要所有位置的 K/V 来计算 Softmax你重算最后一个 token 的 K/V 虽然省了 KV Cache 的读取但恰恰遗漏了后续要做的 Attention 计算中涉及的历史 K/V——这部分还是得读。因此Replay 窗口的下限要能覆盖整个 Attention 所依赖的历史范围。W 通常不会小于 16。3.2 典型场景二PD 分离架构中的 Prefill 与 Decode 负载均衡PD 分离Prefill 和 Decode 分别跑在不同卡上是当前大规模推理服务的热门架构也是 Replay 能发挥最大价值的地方之一。背景是Prefill 阶段的计算特性是大矩阵乘、高算力、低访存Decode 阶段是小矩阵乘、低算力、高访存。把两者混在同一批 GPU 上会互相干扰所以很多生产系统把它们分到不同的卡池中间通过高速互联传输 KV Cache。超大规模并发时KV Cache 的传输就成了瓶颈。比如一个 Prefill 节点算完了 10 个请求的 KV Cache要把这几十 GB 的数据传输到 Decode 节点跨卡、跨节点的带宽是有限的。这时候一个聪明的优化是Decode 节点收到请求后并不急着去拉全量 KV Cache而是只拿最近的一小段 K/V 以及中间层的部分 Tensor进入解码时才逐步重算。这不像听起来那么复杂。实际上很多框架已经在做类似的事把请求的 KV Cache 分成直接缓存段和重算段。直接缓存段通常是较早的上下文这部分特征稳定重算成本高不如传输重算段是最近的上下文占显存少、传输量小且在 Decode 节点算力充裕的情况下重算起来比从远端拉数据快得多。我记得有个内部模拟实验跑一个 32K 上下文的请求PD 分离下从 Prefill 节点拉 KV Cache 到 Decode 节点大概要 2.9ms而在 Decode 节点本地重算最后 64 个 token 的 KV 只需约 0.4ms。在这种架构下Replay 的价值就不只是省显存了更是省跨节点通信带宽——通信带宽在很多机群里比显存带宽更稀缺。3.3 典型场景三投机解码Speculative Decoding的验证阶段投机解码是最近很火的推理加速方法小模型先草拟多个候选 token大模型一次性验证草稿。验证阶段有两个关键点一是草稿的 token 序列是全新的不在原来的解码轨迹上二是验证过程是并行的多个 token 的 Attention 可以同时计算。问题来了草稿 token 进入大模型时它们对应的 K/V 还没有被计算过。如果严格按原始解码流程需要先把草稿 token 逐个输入模型、逐个计算 K/V这恰恰是投机解码想避免的串行开销。但如果你对草稿 token 走一遍 Replay:忽略 KV Cache 的直接命中直接从草稿的最后一个真实 token 之后全部用重算的方式计算出草稿段的 K/V——你会发现这一切是高度并行的草稿 token 的 Prefill 本质就是一个短序列的批量矩阵乘效率远高于逐 token decode。这里 Replay 的重算一小段体现得更微妙重算的不是历史 token 的 KV Cache而是草稿 token 自己的 KV Cache。由于草稿长度很短通常 4~8 个 token重算几层 K/V 的成本低到可以忽略但它换来的并行化收益极高。这个思路在很多开源框架里已经有实现只是大家没意识到它本质上也属于 Replay 家族的策略。3.4 一个容易踩的误区Replay 不是禁用缓存聊到这必须厘清一个常见的误解有些人一听 Replay就觉得是全链路把 KV Cache 关了每次生成都从零算起。这是完全错误的理解。实际工程里Replay 一定是部分重算、部分缓存的组合策略——早段的 KV Cache 照常缓存晚段最近窗口允许丢弃并按需重算。原因很简单早段距离当前位置很远的 token即使只缓存一两个 token显存占比也可能不小但重算它们的成本是 O(M)便宜不了多少。晚段几十个 token缓存占用小但读取频率极高重算成本 O(W²) 却非常小。所以在同一序列里Replay 和 KV Cache 是协同关系不是替代关系。一个常见的配置是维护一个全局 KV Cache同时设定一个窗口阈值当序列长度超过阈值时自动把窗口外的 KV Cache 标记为可丢弃后续读取时如果发现所需的 K/V 不在缓存里就基于现存缓存往前重算 W 步。这样既不需要存全量历史也不会因为重算丢失太多上下文信息。这就像你写论文时已经完成的前 80 页内容保留在正式文档里缓存但最后几页的临时草稿在修改期间不存档丢弃缓存每次需要看最新状态时花几分钟重写一下最后几页Replay。前 80 页的内容不是被丢掉的只是不在草稿里重复存放而已。4. 实操指南怎么配置、怎么调优4.1 基本参数与触发条件下面给出一个可以落地的配置参考。假设你在跑一个 70B 模型单卡显存 80GB目标是长上下文32K~128K下的高吞吐推理。我建议从这几组参数入手Replay 窗口W16~64 之间建议从 32 起步。窗口太小会频繁触发重算、损失缓存收益窗口太大则重算成本上升触发阈值会变得保守。实际测试里32 对于 70B 模型在 32K 上下文下表现良好窗口对应重算 FLOPs 大约是总上下文的 1/1000成本非常低。触发条件触发策略不是每种情况都要触发 Replay。建议设置一个显存压力阈值和一个带宽压力阈值。显存余量低于 20% 或带宽利用率超过 80% 时优先触发 Replay否则维持正常缓存。同时注意区分每请求触发和全局触发如果机器整体负载不高Replay 反而会白白增加计算。重算段划分Chunk SizeReplay 不是一次重算一个 token而是按 chunk 批量重算。chunk size 推荐与 W 一致或者取 W 的一半。但要注意chunk 太大时重算的 Attention 计算量按 O(W²) 增长可能会抵消缓存收益见 2.2 的公式。所以 chunk 通常不能超过 64。下面是我常用的一份推荐配置表方便抄作业参数推荐值说明模型规模7B~70B越大越能体现 Replay 优势上下文长度≥32K上下文越短Replay 越不划算Replay 窗口 W16~64建议用 32 起步触发条件显存余量 20% 或带宽 80%避免无意义的主动重算重算 chunk 大小16~64与 W 保持一致或减半是否启用早段缓存是序列的前 60%~80% 仍缓存缓存淘汰策略按最近使用淘汰长上下文下表现稳定4.2 结合现有框架的落地路径如果你用的是主流推理框架落地 Replay 有两条路路线一用已有的局部重算开关。有部分框架在长上下文场景提供了类似 rolling cache 或 replay last chunk 的开关。你只需要把窗口大小配好剩下交给框架。这种路线适合快速验证但参数可调空间小。路线二自己接一个缓存控制器。更灵活的做法是在推理引擎外层实现一个轻量控制器它维护每个请求的 KV Cache 状态并决定是否触发 Replay。伪代码逻辑其实很简单class ReplayController: def __init__(self, window32, trigger_threshold0.2): self.window window self.trigger_threshold trigger_threshold # 记录每个序列的缓存范围 self.cached_ranges {} # seq_id - [start_pos, end_pos] def should_replay(self, seq_id, current_pos, mem_ratio, bw_ratio): # 触发条件缓存缺失 or 显存紧张 or 带宽饱和 if seq_id not in self.cached_ranges: return True cached_start, cached_end self.cached_ranges[seq_id] # 如果当前位置已经超出缓存末端就需要重算 if current_pos cached_end - 1: return True # 在显存或带宽压力下即使缓存可用也选择重算 if mem_ratio self.trigger_threshold or bw_ratio 0.8: return True return False def replay_window(self, seq_id, current_pos): start max(0, current_pos - self.window) return start, current_pos # 返回需要重算的起止位置实际实现比这复杂一些因为要处理多头注意力、张量并行下的 K/V 收集、以及重算结果的写回时机。但核心判断逻辑就是上面这么简单。注意重算后的 KV 是否需要写回缓存大多数工程实现是不写回写回又占用带宽和显存不如让缓存范围自然滑动。只有在长序列中重复触发 Replay 时写回才可能带来收益。4.3 调优时最该看的几个指标判断 Replay 配置是否合理不要只看延迟还要看一组指标Prefill 占比浮点利用率MFU重算阶段的矩阵乘是否充分命中了 GPU 的算力。如果 MFU 很低说明重算没有发挥位数不如走缓存。Decoder 的带宽利用率KV Cache 读取导致的带宽占用。Replay 的一个主要目的就是降低带宽峰值如果指标还是很高说明触发条件太保守。序列长度分布80% 的请求都小于 4K 时Replay 不上也罢但如果 20% 的请求撑起了 80% 的 KV Cache 占用Replay 只针对那 20% 做优化即可。端到端 TTFT首 token 延迟和 TPOT后续 token 延迟Replay 主要在 TPOT 上做优化如果 TTFT 也显著增加了说明重算挪到了 Prefill 阶段可能得不偿失。调优的顺序建议是先把 Replay 窗口固定为 32触发条件设为显存余量低于 20% 或带宽高于 80%观测 TPOT 变化、显存峰值和 MFU如果 TPOT 降了但 MFU 掉了说明窗口太大如果显存降得不明显说明触发条件设得太保守可以调低显存余量阈值到 10%。这个迭代过程大概需要半天到一天的时间非常值得。另外replay 触发的判定最好放在调度器层面而不是单请求层面。因为 Replay 会改变请求所需的显存和算力分布调度器需要提前预留算力。我的经验是把 Replay 的触发做成全局调度器的水位线信号而不是每个解码步去判断。这样可以避免在高并发下多个请求同时触发 Replay导致算力被瞬间拉满。5. 常见问题与排查技巧实录这部分内容来自我实际调试过的若干次压测不排除部分环境差异但思路是通用的。5.1 触发 Replay 后TTFT 反而变长了现象开启 Replay 后首 token 延迟从原来的 700ms 涨到 1.2s但后续 TPOT 明显下降。排查后发现Replay 窗口设置得太大33K 序列的首个 token 在显存完全处于压力状态下触发了重算重算需要冷加载大量权重反而拖慢了第一步。解决方法是把 Replay 触发条件改为仅在当前序列生成位置超过上下文长度的 70% 之后才允许触发——早期上下文较短时KV Cache 读取成本低重算不划算。5.2 多卡并行时K/V 分散在各卡Replay 的通信开销爆炸现象8 卡张量并行跑 70B 模型Replay 开启后每一步生成都伴随大量 AllReduce通信占比高达 40%。原因重算需要在当前卡上持有完整的 K/V 矩阵而张量并行下 K/V 可能被拆分到不同卡。每次重算都触发跨卡通信开销甚至高于读取原始缓存。解决思路只对单一 Attention 头做 Replay即把 K/V 重新计算限定在本地卡持有的头范围内或者干脆在 PD 分离架构中将 Replay 放在 Prefill 节点完成避免跨卡通信。5.3 显存降了但 MFU 也降了批量吞吐上不来现象Replay 大幅降低了显存占用但 GPU 利用率掉到 30% 以下。原因是显存虽然省出来了但空闲的显存没有被调度器有效利用新请求没有被填充进空余显存因为调度器还按旧的高水位预留策略分配资源。解法是同步调整调度器的批量大小上限让 Replay 省出来的显存真正转化为更大的 batch。简单说Replay 是给调度器松绑的不给它松绑它不会自动省钱。5.4 长稳定运行后Replay 效果衰减现象压测跑了几小时后吞吐量又逐渐下降。排查发现Replay 触发的窗口 K/V 虽然在显存中被丢弃了但相关的中间状态比如上一轮 Replay 的结果仍然残留在缓存里越积越多。需要在每次 Replay 之后清理旧的 K/V 缓存段否则缓存段碎片化会导致命中率降低。这里推荐一个经验值窗口 W 设置为 K/V 缓存段大小的 1/8~1/4这样清理和重算的比例比较健康。5.5 一个小测试你的场景到底适不适合 Replay最后教大家一个自我诊断方法。先在服务器上记录三组数据平均上下文长度 C、KV Cache 平均占用字节数 KV_bytes、GPU 峰值算力和带宽Roofline 模型的 R 值。然后计算读取 KV Cache 的时间估计 KV_bytes / 带宽 重算固定窗口 W 的时间估计 L × W × (2 × d_model × d_head W × d_head) / (峰值算力 × 效率系数)其中效率系数取 0.5 左右比较稳妥。如果读取时间估计大于重算时间估计还超过 20% 以上那 Replay 就值得上而且收益值得期待如果两者差不多甚至相反硬上 Replay 就是给自己找麻烦。我用这个方法给好几个项目做过预判准确率很高推荐先算一算再动手。写在最后关于反直觉的一点体会前面把原理、公式和踩坑案例都铺开了我想补一个自己的实际感受这类重算反而更省钱的优化思路其实在计算机系统领域并不新鲜数据库里的物化视图选择、CPU 里分支预测失败时的流水线冲刷都是同样的道理——**系统的瓶颈在哪优化的方向就在哪。**KV Cache 的本质是用显存换算力但当算力不再是瓶颈、显存带宽和容量成为瓶颈时反着操作反而对。我做过的几次长上下文压测里Replay 的最佳收益往往不是让单请求变快而是让单卡能承载的并发请求数变多——同样的显存原来只能跑 8 路并发现在能跑到 16 路甚至 32 路吞吐量提升比单请求延迟更重要。这可能是这个技巧最值钱的地方它不是一个减少计算的优化而是一个重新分配计算与存储位置的优化。最后再提醒一点Replay 窗口、触发阈值这些参数一定要放到你自己的数据集和流量模型里去调别照搬任何人的默认值。我踩过的坑就是过度相信文档结果在短上下文密集的场景里Replay 反而拖慢了吞吐。先在模拟流量上跑一遍 Replay 的触发率统计确保不是每个请求都在触发再上线到生产环境。有好结果的话也欢迎回来聊一聊你们压出来的数据。