长上下文这几年几乎是所有做大模型应用的人绕不开的话题。大家都希望模型能一次读完整本书、整份财报、整段代码仓库但真把上下文从4K干到128K甚至1M的时候最先崩的往往不是模型本身而是显存、延迟和效果。说白了长上下文不是“把窗口调大”那么简单它背后牵扯的是Attention的计算方式、KV Cache怎么存、存不下怎么压缩、超出单次窗口怎么办这一整条链路。这篇文章我想把这套底层逻辑完整拆一遍结合我实际踩过的坑聊聊为什么长上下文难以及主流的解法各自在解决什么问题。这篇文章适合正在做RAG、做长文档问答、做大模型推理优化的工程师也适合想搞明白“长上下文到底贵在哪”的技术负责人。不涉及太复杂的数学推导但会把关键的计算开销、显存占用的数量级讲清楚让之后选方案的时候心里有数。1. 先把问题拆清楚长上下文的瓶颈到底在哪1.1 从自回归解码说起一次生成要算多少账大模型生成文本是自回归的一个token一个token往外蹦。每生成一个新token都要让全部输入token过一遍Transformer的每一层。这一遍的计算量大概可以拆成两块一块是对每个token做矩阵乘法把隐藏状态从d维映射到d维这部分其实和上下文长度没什么直接关系你给它1K还是128K上下文单个token的前向计算量基本一样另一块是Attention也就是让每个token和上下文里所有其他token做交互算相关性、加权求和这一块的计算量和上下文长度直接挂钩而且是平方级增长。所以关键点来了当上下文变长时生成的速度瓶颈其实主要集中在Attention部分。你可能会说那我把Attention用Flash Attention优化一下不就行了Flash Attention确实把Attention的计算效率提升了一大截但还有一个更隐蔽、更占资源的东西——KV Cache它在长上下文场景下的膨胀速度远比你想象的要夸张。1.2 KV Cache才是内存爆炸的“真凶”Transformer推理时每个token在每个层都会产出一组Key和Value向量用来和后面的token做Attention计算。如果不做任何缓存每生成一个新token理论上要把前面所有token的Key和Value重新算一遍计算量直接变成O(n³)这在工程上是完全不可接受的。所以业界通用的做法是KV Cache把已生成token的Key和Value缓存下来之后只需要算新token的K和V然后拼到缓存后面去。KV Cache需要占多少显存可以用一个公式估算内存总量 2K和V各一份× 层数 × KV头数 × 每个头的维度 × 序列长度 × 每个元素占用的字节数拿一个常见的70B规模开源模型举例假设它有80层、8个KV头、每个头维度128用FP16存储每个元素2字节那么每缓存一个token需要的内存就是2 × 80 × 8 × 128 × 2 327,680字节大约320KB。看着单token不多但你要支持100K上下文哪怕只缓存用户的输入和已经生成的内容保守估算就需要 100000 × 320KB ≈ 32GB 显存。这还没算模型权重、激活值、优化器状态。一张80GB的A100光KV Cache就能吃掉将近一半。这就能解释为什么很多号称支持超长上下文的模型实际跑起来并行度一高就OOM。KV Cache不只是“存不存得下”的问题还直接影响你的吞吐——显存被KV Cache占了能同时服务的并发请求数就少了。2. Attention的进化路线从标准实现到Flash Attention2.1 标准Attention的Softmax中间矩阵是个“显存黑洞”标准Attention的计算路径是这样的先拿Q和K做矩阵乘法得到一个n×n的分数矩阵然后对这个矩阵做Softmax再和V相乘。问题出在那个n×n的分数矩阵上。序列长度n一旦变大这个矩阵的大小就是n²。比如上下文是128K那光是这一个分数矩阵就有128K × 128K 163.8亿个元素哪怕用FP16存也要327GB。这显然没法放进任何一张显卡里必须得想别的办法。而且还有一个更微妙的问题Softmax这个操作不是逐元素独立的它需要所有元素都参与计算——先求最大值做归一化算指数再求和。这就意味着你不能随便把矩阵切开各自Softmax之后再拼回去因为每一块的Softmax分母是局部的不是全局的拼回去结果就错了。2.2 Flash Attention的“分块重算”思路Flash Attention解决这个问题的方式简单说就是“不保存中间矩阵分块算在线修正”。它把Q、K、V都切成小块一次只计算一小块注意力分数在片上SRAM速度极快但容量很小里临时算Softmax然后把结果累加回输出。为了实现全局正确的Softmax它在累加过程中会不断根据新块算出的最大值去修正之前已经累加过的输出权重。Flash Attention最牛的地方在于IO感知的优化。它不把中间结果写回显存HBM全程在SRAM里完成分块计算只在最后把结果写回去。这样虽然计算量没有减少但显存访问量从O(n²)降到了O(n)实际运行速度可以快好几倍长序列下尤其明显。从工程角度我强烈建议推理和训练都默认带上Flash Attention。如果你用的是开源的推理框架绝大多数都集成了。自己做模型服务的话优先用支持Flash Attention的后端别自己手写Attention内核——不是不能写是你大概率写不过cuDNN和Triton里已经被优化到极致的内核。2.3 稀疏Attention与滑动窗口省计算但有代价Flash Attention解决了标准Attention的中间矩阵问题但没解决Attention本身的平方级计算复杂度。要真正降低计算量就得做稀疏化不让每个token和所有token都做Attention而是只和一部分token做。常见的做法是滑动窗口Attention每个token只看它前面的W个token。这样计算量从O(n²)降到O(n×W)W是常量的话就是线性复杂度。还有一类更激进的稀疏模式比如全局token加局部窗口的组合每隔一段距离设置一个全局token让它能看到整个序列。这类方案真实效果如何我的体验是在纯长文本续写和summary任务上滑动窗口的效果常常会打折扣——因为真正重要的依赖关系不一定就在窗口内可能隔着几千token的某个关键实体滑动窗口根本看不到。反过来如果任务是流式的流式对话、按块处理的文档解析滑动窗口就非常合适速度提升肉眼可见。选不选取决于你的任务里到底要不要“全程全局可见”。3. 压缩把上下文“瘦身”的几种主流路径3.1 KV Cache压缩量化、剪枝、低秩分解既然KV Cache是长上下文的最大内存消耗者最直接的办法就是压缩KV Cache本身。KV Cache量化是目前工程落地最成熟的方案。把FP16的K和V从16bit降到8bit甚至4bit显存直接降到原来的1/4甚至1/8。很多推理框架现在默认支持KV Cache量化比如INT8、INT4量化。精度上8bit量化在多数任务里几乎无损4bit量化在长序列、需要强事实细节的任务上会有一定的质量下降需要做评估再上。H2O这类剪枝方法是按score评估token的重要性把不重要的token对应的KV Cache丢弃。这个思路很直观Attention分数极低的token说明它对后续生成的影响本来就可忽略留着纯属浪费内存。实际效果在保留80%左右的KV时很多任务上依然能维持接近全量Cache的效果但分配率偏低的任务比如实体密集的文档会明显受损。低秩分解类的方法更学术一点认为KV Cache矩阵本身有大量冗余可以用低秩矩阵近似。这条路线目前还没有像量化那样大规模的工程落地但从长上下文推理未来的角度来看是一个值得关注的方向它有可能把KV Cache的压缩率推到比量化更极致同时保留更多的表达能力。3.2 上下文层面的压缩摘要、隐状态与向量化KV Cache压缩解决的是“显存放不下”的问题但还有一种场景是“内容太多、质量不集中”——比如你给模型塞了整本500页的手册里面真正和问题相关的可能只有几页。这种情况下上下文压缩的本质是内容层面的信息筛选。最朴素的做法是摘要压缩把长文档切成块先用模型做分层摘要把摘要作为新的上下文在需要细节时再从原始文档里检索对应的段落补充回去。这是很多长文档问答系统的底层套路本质上是用“预先压缩按需展开”的方式控制上下文长度。更“端到端”的做法是训练模型直接对输入做隐状态压缩模型内部有一个压缩模块把一段文本编码成一个固定长度的向量又用另一个方式把它解压出来。这类模型比如一些基于自动编码器思路训练的模型在固定压缩比下能保持不错的语义保真度但在事实性要求高的场景比如数值、法律条款、代码逻辑里压缩后的信息丢失是不可控的我建议谨慎使用。3.3 压缩比与效果之间怎么取舍动手前先做这几件事压缩永远是一种权衡。你压缩得越狠显存占用越低但模型能看到的信息就越少生成质量就越不可控。我的建议是分三步走第一步先量化识别你的任务对“细节”的敏感度。如果是开放域的创意写作压缩狠一点问题不大如果是菜谱、合同条款、代码API这种“差一个字符就出错”的任务尽量少压缩或者不压缩。第二步做一张精度曲线。针对你的目标任务采样一批真实问题分别测试完整KV、8bit量化KV、4bit量化KV和剪枝后的效果差异画出压缩比和效果的曲线找出“拐点”。第三步再做容量规划。根据你的最大并发数和期望上下文长度算清楚KV Cache需要多少显存再决定压缩策略。不要在没算量的情况下盲目上4bit量化看着显存是省了但效果崩了还得回头调更浪费时间。4. 缓存KV Cache的复用与生命周期管理4.1 一次推理里的两级缓存角色KV Cache在推理过程中有两个阶段的表现差异非常大值得单独说。第一个阶段叫Prefill预填充也就是用户把一大段输入一次性发给模型此时模型要同时处理所有输入token并把它们的KV Cache算出来。这个阶段是计算密集型的显存和算力占用都会冲高。第二个阶段叫Decode解码模型逐token生成每次只需要算新token的KV Cache追加到现有缓存后面。这个阶段变成了访存密集型瓶颈主要在KV Cache的读取带宽上。这两个阶段的差异直接影响你的推理框架配置选择。Prefill阶段要关注算力峰值Decode阶段要关注KV Cache的带宽和容量。如果你在一个框架里统一处理这两个阶段很可能出现“Prefill很快但Decode很慢”或者反之的情况。现在很多框架都支持Prefill和Decode分离部署本质上是让不同阶段用不同的资源策略长上下文场景下收益非常明显。4.2 跨请求复用前缀缓存与RadixAttention单个请求内的KV Cache复用是框架自动做的但跨请求复用就不一定了。最常见的场景是多个用户问相似的问题或者一个系统里所有请求共用同一个系统提示词system prompt。这些请求的前缀token完全一样理论上KV Cache可以共用。vLLM里的Prefix Caching和SGLang里的RadixAttention就是干这件事的。它们会把计算过的KV Cache按前缀存成树状结构新请求来的时候直接复用命中的前缀缓存只计算差异部分。在系统提示词固定、对话历史经常复用的场景下这种方式能省掉大量重复计算首token延迟能降低一半甚至更多。不过前缀缓存有一个实际难题只有前缀完全一致的请求才能复用。哪怕系统提示词里有一个字符不同缓存就命中不了。所以做这类优化时系统提示词要尽量固定不要往里面塞时间戳、随机ID之类动态内容否则缓存全是Miss等于白搭。4.3 缓存的失效、淘汰与一致性KV Cache本质上也面临传统缓存系统同样的问题容量有限、需要淘汰、需要处理一致性。服务端缓存超过上限之后常见的淘汰策略包括LRU很久没被用到的先淘汰和LFU用得少的先淘汰。长上下文场景下KV Cache的“体积”差异很大——一个1M上下文的请求可能会占掉大量缓存空间直接把其他缓存挤出去。这时候只按“条数”做淘汰是不够的还要考虑“总字节数”的配额管理。另一个容易忽略的问题是“一致性”。如果你的系统里有更新过的文档旧的KV Cache是基于旧文档生成的在新文档生效后还复用旧缓存就会生成错误答案。所以必须有缓存失效机制文档更新时清掉相关前缀的缓存。实践中我见过不少团队做了前缀缓存但忘了做失效结果用户问新版本的问题模型还在用旧版本的内容回答很尴尬。5. 跨页推理上下文超过窗口上限时的处理策略5.1 “跨页推理”解决的是什么问题“跨页推理”这个词听起来有点抽象其实对应的是一个很现实的场景当模型窗口上限是32K但你要处理的文档有200K放不下怎么办这就跟你看一本很长的书但书签一次只能夹在一页里你必须翻页看翻页之后还得记住前面讲了什么。长文档处理里的跨页本质上就是“如何把超长内容拆碎让模型分批看完并把前面部分的关键信息保留下来用于后续的推理”。这里面有两个核心矛盾一是拆开之后分散在不同“页”里的信息要能关联起来二是前面的“页”不能白看要留下有用的记忆而不是把所有内容机械地塞进上下文。5.2 滑动窗口接力的实现方式与信息丢失风险最简单直接的跨页方式是滑动窗口接力把长文档切分成有重叠的窗口段模型按顺序逐个处理前一个窗口的结论或摘要拼接到后一个窗口的头部形成接力。这样处理的过程中模型实际上是在一个“不断推进的上下文”里工作。这个方案工程实现上最容易但风险也很明显信息会沿着窗口链逐级衰减。如果每个窗口结束时只保留固定长度的摘要那么第10个窗口看到的内容已经是对第1个窗口摘要的摘要的摘要细节早就丢了。我实际做过一次长合同审查早期的几个关键条款在窗口滑动过程中被摘要掉最终结论漏掉了一个重要风险点。解决办法是两层设计一是滑动窗口的摘要不是“唯一记忆”原始窗口的KV Cache或原文段落仍然保存在一个外部存储里需要时检索回来二是窗口之间加“重点标记”——在处理过程中发现关键信息金额、日期、主体名等显式提取出来存入全局记忆而不是依赖自然语言摘要隐式携带。5.3 长文档问答的分层检索加摘要回填足够日用如果你不是在做那种“一字不差必须通读全文”的任务比如综合分析、写报告、多轮答疑长文档处理目前最稳的工程路线是分层检索加摘要回填。具体做法先用一个轻量级模型或规则把文档按章节切块做向量索引对每块生成一级摘要对整章生成二级摘要形成“章摘要→节摘要→原始块”的树状结构。回答问题时先用问题匹配到相关章和节再只把命中的那部分原始块、上一层的摘要和问题一起拼进上下文。这一步实际是“检索压缩片段缓存按需展开”的组合拳。这套方案单次推理的上下文长度远小于全文KV Cache占用可控推理速度快并且由于最终会取回原始块事实性也远好于纯摘要压缩。它不能解决的问题是“全局跨章节关联推理”比如需要把第2章的背景和第8章的数据放在一起推导——这是RAG类做法的天花板如果这类需求是你的核心场景那还是得回到更大的上下文窗口或训练时针对长程依赖做优化。6. 实操中踩过的坑与排查建议6.1 显存里KV Cache占用突增怎么定位我在做推理服务时碰到过几次线上OOM第一反应都是去查模型权重后来发现大头全在KV Cache上。排查KV Cache问题一个很有效的命令级做法是用nvidia-smi观察显存曲线再配合推理框架的监控指标来定位。如果在Prefill阶段显存瞬间冲高多半是输入序列过长导致的KV Cache初始化存储过大如果在Decode阶段显存缓慢爬升则是随着生成长度增加KV Cache在持续增长。还有一个经常被忽略的问题连续服务多个长请求时上一个请求的KV Cache如果没有及时释放会一直占着显存。做容量规划时不能只按单请求算要把并发数、平均请求长度和缓存淘汰速度全部放进去估算。我的经验是给KV Cache按请求设置一个“显存配额”超过配额直接触发最老缓存淘汰比等OOM了再重启服务稳妥得多。6.2 KV Cache量化后为什么效果反而变差曾经有一个场景给一个客服问答系统加上4bit KV Cache量化显存占用降了很多但测试集准确率掉了4到5个百分点。排查下来发现这个系统的问题里有大量专有名词和产品编号KV Cache量化后这些关键token的K/V向量精度损失导致Attention打分出现偏差关键实体匹配失败。而换到8bit量化准确率基本持平。这个教训想提醒大家量化不是好不好看的问题是“信息精度”的问题。你的模型对token的区分度越敏感比如大量近似的专有名词量化的容忍度就越低。上量化之前务必要在自己的数据上跑一遍对比测试而不是直接参考论文里的结论。6.3 前缀缓存命中率低问题可能出在Prompt结构前缀缓存是用好了很香、用不好很憋屈的技术。有次我们改造一个问答服务要求用户每轮请求都携带时间戳和随机会话ID在系统提示词里。结果就是每个请求的KV Cache都独一份命中率基本是零缓存占了大量显存却起不到复用效果。后来把动态字段从系统提示词挪到了用户消息末尾保证了前缀一致性命中率才提上来。这事的工程价值在于你设计Prompt的时候就要有“前缀可复用”的意识。把动态信息统统往后放固定模板放前面这不仅对缓存有帮助对后续诊断、测试也会省力很多。4. 缓存KV Cache的复用与生命周期管理4.1 一次推理里的两级缓存角色KV Cache在推理过程中有两个阶段的表现差异非常大值得单独说。第一个阶段叫Prefill预填充也就是用户把一大段输入一次性发给模型此时模型要同时处理所有输入token并把它们的KV Cache算出来。这个阶段是计算密集型的显存和算力占用都会冲高。第二个阶段叫Decode解码模型逐token生成每次只需要算新token的KV Cache追加到现有缓存后面。这个阶段变成了访存密集型瓶颈主要在KV Cache的读取带宽上。这两个阶段的差异直接影响你的推理框架配置选择。Prefill阶段要关注算力峰值Decode阶段要关注KV Cache的带宽和容量。如果你在一个框架里统一处理这两个阶段很可能出现“Prefill很快但Decode很慢”或者反之的情况。现在很多框架都支持Prefill和Decode分离部署本质上是让不同阶段用不同的资源策略长上下文场景下收益非常明显。4.2 跨请求复用前缀缓存与RadixAttention单个请求内的KV Cache复用是框架自动做的但跨请求复用就不一定了。最常见的场景是多个用户问相似的问题或者一个系统里所有请求共用同一个系统提示词。这些请求的前缀token完全一样理论上KV Cache可以共用。vLLM里的Prefix Caching和SGLang里的RadixAttention就是干这件事的。它们会把计算过的KV Cache按前缀存成树状结构新请求来的时候直接复用命中的前缀缓存只计算差异部分。在系统提示词固定、对话历史经常复用的场景下这种方式能省掉大量重复计算首token延迟能降低一半甚至更多。不过前缀缓存有一个实际难题只有前缀完全一致的请求才能复用。哪怕系统提示词里有一个字符不同缓存就命中不了。所以做这类优化时系统提示词要尽量固定不要往里面塞时间戳、随机ID之类动态内容否则缓存全是Miss等于白搭。4.3 缓存的失效、淘汰与一致性KV Cache本质上也面临传统缓存系统同样的问题容量有限、需要淘汰、需要处理一致性。服务端缓存超过上限之后常见的淘汰策略包括LRU很久没被用到的先淘汰和LFU用得少的先淘汰。长上下文场景下KV Cache的“体积”差异很大——一个1M上下文的请求可能会占掉大量缓存空间直接把其他缓存挤出去。这时候只按“条数”做淘汰是不够的还要考虑“总字节数”的配额管理。另一个容易忽略的问题是“一致性”。如果你的系统里有更新过的文档旧的KV Cache是基于旧文档生成的在新文档生效后还复用旧缓存就会生成错误答案。所以必须有缓存失效机制文档更新时清掉相关前缀的缓存。实践中我见过不少团队做了前缀缓存但忘了做失效结果用户问新版本的问题模型还在用旧版本的内容回答很尴尬。5. 跨页推理上下文超过窗口上限时的处理策略5.1 “跨页推理”解决的是什么问题“跨页推理”这个词听起来有点抽象其实对应的是一个很现实的场景当模型窗口上限是32K但你要处理的文档有200K放不下怎么办这就跟你看一本很长的书但书签一次只能夹在一页里你必须翻页看翻页之后还得记住前面讲了什么。长文档处理里的跨页本质上就是“如何把超长内容拆碎让模型分批看完并把前面部分的关键信息保留下来用于后续的推理”。这里面的核心矛盾一个是拆开之后分散在不同“页”里的信息要能关联起来另一个是前面的“页”不能白看要留下有用的记忆而不是把所有内容机械地塞进上下文。5.2 滑动窗口接力的实现方式与信息丢失风险最简单直接的跨页方式是滑动窗口接力把长文档切分成有重叠的窗口段模型按顺序逐个处理前一个窗口的结论或摘要拼接到后一个窗口的头部形成接力。这样处理的过程中模型实际上是在一个“不断推进的上下文”里工作。这个方案工程实现上最容易但风险也很明显信息会沿着窗口链逐级衰减。如果每个窗口结束时只保留固定长度的摘要那么第10个窗口看到的内容已经是对第1个窗口摘要的摘要的摘要细节早就丢了。我实际做过一次长合同审查早期的几个关键条款在窗口滑动过程中被摘要掉最终结论漏掉了一个重要风险点。解决办法是两层设计一是滑动窗口的摘要不是“唯一记忆”原始窗口的KV Cache或原文段落仍然保存在一个外部存储里需要时检索回来二是窗口之间加“重点标记”——在处理过程中发现关键信息金额、日期、主体名等显式提取出来存入全局记忆而不是依赖自然语言摘要隐式携带。5.3 长文档问答的分层检索加摘要回填足够日用如果你不是在做那种“一字不差必须通读全文”的任务比如综合分析、写报告、多轮答疑长文档处理目前最稳的工程路线是分层检索加摘要回填。具体做法先用一个轻量级模型或规则把文档按章节切块做向量索引对每块生成一级摘要对整章生成二级摘要形成“章摘要→节摘要→原始块”的树状结构。回答问题时先用问题匹配到相关章和节再只把命中的那部分原始块、上一层的摘要和问题一起拼进上下文。这一步实际是“检索压缩片段缓存按需展开”的组合拳。这套方案单次推理的上下文长度远小于全文KV Cache占用可控推理速度快并且由于最终会取回原始块事实性也远好于纯摘要压缩。它不能解决的问题是“全局跨章节关联推理”比如需要把第2章的背景和第8章的数据放在一起推导——这是RAG类做法的天花板如果这类需求是你的核心场景那还是得回到更大的上下文窗口或训练时针对长程依赖做优化。6. 实操中踩过的坑与排查建议6.1 显存里KV Cache占用突增怎么定位我在做推理服务时碰到过几次线上OOM第一反应都是去查模型权重后来发现大头全在KV Cache上。排查KV Cache问题一个很有效的做法是先用nvidia-smi观察显存曲线再配合推理框架的监控指标来定位。如果在Prefill阶段显存瞬间冲高多半是输入序列过长导致的KV Cache初始化存储过大如果在Decode阶段显存缓慢爬升则是随着生成长度增加KV Cache在持续增长。还有一个经常被忽略的问题连续服务多个长请求时上一个请求的KV Cache如果没有及时释放会一直占着显存。做容量规划时不能只按单请求算要把并发数、平均请求长度和缓存淘汰速度全部放进去估算。我的经验是给KV Cache按请求设置一个“显存配额”超过配额直接触发最老缓存淘汰比等OOM了再重启服务稳妥得多。6.2 KV Cache量化后为什么效果反而变差曾经有一个场景给一个客服问答系统加上4bit KV Cache量化显存占用降了很多但测试集准确率掉了四五个百分点。排查下来发现这个系统的问题里有大量专有名词和产品编号KV Cache量化后这些关键token的K/V向量精度损失导致Attention打分出现偏差关键实体匹配失败。而换到8bit量化准确率基本持平。这个教训想提醒大家量化不是好不好看的问题是“信息精度”的问题。你的模型对token的区分度越敏感比如大量近似的专有名词量化的容忍度就越低。上量化之前务必要在自己的数据上跑一遍对比测试而不是直接参考论文里的结论。6.3 前缀缓存命中率低问题可能出在Prompt结构前缀缓存是用好了很香、用不好很憋屈的技术。有次我们改造一个问答服务要求用户每轮请求都携带时间戳和随机会话ID在系统提示词里。结果就是每个请求的KV Cache都独一份命中率基本是零缓存占了大量显存却起不到复用效果。后来把动态字段从系统提示词挪到了用户消息末尾保证了前缀一致性命中率才提上来。这事的工程价值在于你设计Prompt的时候就要有“前缀可复用”的意识。把动态信息统统往后放固定模板放前面这不仅对缓存有帮助对后续诊断、测试也会省力很多。6.4 长上下文任务排查速查表症状可能原因优先检查项Prefill阶段显存瞬间冲高输入序列太长KV Cache一次性初始化过大是否有超长输入未做截断或分块Decode阶段显存持续增长生成内容过长KV Cache逐步累积是否设置了max_tokens上限量化后效果下降KV量化精度不足关键实体打分出错对比8bit与4bit效果差异前缀缓存命中率极低prompt前缀不一致动态字段放在前面检查系统提示词是否严格固定长文档跨页处理后结论有遗漏摘要链信息衰减增加重点信息显式提取并发一高就OOM并发请求的KV Cache总占用超限按并发数重算KV Cache总预算最后再分享一个这两年摸索下来的个人体会吧。长上下文这件事本质上不是某一种技术救世而是Attention、压缩、缓存和跨页策略的组合博弈。我的选择逻辑是能用合理成本扩大窗口就先扩扩不了就压缩能在请求间复用就先做好前缀缓存不急着上复杂的压缩算法跨页处理尽量用检索加摘要回填兜底。先把链路上最容易出问题的KV Cache预算算清楚再逐层上优化手段基本能稳住。这套思路我后面还打算继续补一版关于长上下文评测的实操内容——怎么自己搭一套稳定的长文本任务基准来验证各项优化到底有没有把效果保住。到时候有进展再来更新。