7.1 跨请求 KV 共享与安全边界

7.1 跨请求 KV 共享与安全边界

本节摘要：跨请求共享 KV 与提示词前缀是复用经济学最激进的形态——同样一段公共前缀，成百上千个请求只算一次。收益有明确上限（前缀必须重复出现），风险也有明确下限（别人的内容不能漏进你的上下文）。本节先量化共享能省到什么程度，再拆解多租户场景下的三类泄漏面，给出分级隔离原则，并用一个文档协作 SaaS 的实例把原则落到配置。

第 6 章我们把缓存的账算到了 TCO 和盈亏平衡点，结论很清楚：跨请求复用 KV 越充分，单位成本越低。但账算得越细，越要补一个问题——这些被复用的 KV 和提示词前缀，究竟属于谁？一旦把它们当成公共资产在请求之间共享，省下的钱和冒出的险就绑在了一起。这一节先把收益的天花板量出来，再看地板下面藏着的三道裂缝。

复用收益的天花板在哪里

缓存省钱的底层逻辑在前面几章反复出现过：一段文本只要被 N 个请求共用，Prefill 阶段就少算 N-1 次。跨请求共享把它推到极致——不是同一会话内的多轮复用，而是不同用户、不同时间到达的请求，只要前缀相同就命中同一份 KV。

收益上限由两个因素锁死。第一是前缀的稳定性：共享只在"大量请求带着一模一样的前缀"时才有意义。最典型的场景有三类——系统提示词固定不变、产品手册或知识库作为固定上下文注入、以及多人在同一份共享文档上协作时那份文档本身就是公共前缀。第二是共享粒度：前缀越长且越靠前，复用的 token 越多，收益越高；一旦用户内容在第 5 个 token 就分叉，后面几千个 token 的 KV 全部无法共享，前面省下的也一并作废。

举个可感知的数字。假设某协作产品给每个请求都注入同一份 8000 token 的产品手册作为上下文，平均每次请求的独有部分只有 200 token。如果不共享，每个请求都要为那 8000 token 付 Prefill 算力；如果跨请求共享这份手册的 KV，那么只有第一个到达的请求付全价，之后所有请求只付 200 token 的增量 Prefill 加 Decode。在日均十万请求、命中率九成的稳态下，手册部分的 Prefill 算力被压缩到原来的约十分之一。共享收益的天花板等于"可被公共前缀覆盖的 token 量 × 复用次数"，这个公式本身就给收益画了顶。

但天花板之外还有个容易被忽略的前提：共享要求这些请求真的落在同一片缓存里。多租户系统里，如果隔离策略把每个租户的缓存完全切开，这份 8000 token 手册就要在每个租户内各算一遍——共享收益随租户数被摊薄，这正是后面要谈的隔离代价。

共享打开的三道风险缝

收益讲完，风险面才是这节的重点。把不同用户的 KV 放进同一片缓存，等于让本该隔离的数据流产生交叉，泄漏不一定以"明文读出别人内容"的形式发生，更多是间接的。

第一道缝是侧信道探测。攻击者不需要直接读取缓存内容，只要测量自己请求的响应时延就能反推：如果我发了某个前缀之后命中极快，说明缓存里已经有这份前缀的 KV，换言之有别的用户最近用过同样的开头。更隐蔽的玩法是有意构造探针前缀去"探测"某家公司是否在用某个系统提示词——命中即证实。这种通过命中时延差异推断他人上下文的手法，在共享前缀缓存上天然存在，是纯工程手段难以彻底消除的信息泄漏面，只能在时延上做平滑去掩盖"命中与否"的差异。

第二道缝是前缀投毒。如果缓存命中只看前缀是否一致、不做来源校验，攻击者可以抢先提交一段精心设计的前缀，把"污染过的 KV"种进共享缓存。后续真实用户带着相同前缀到达时，命中到的就是被篡改的中间结果，模型输出被悄悄带偏。这在检索增强场景尤其危险：攻击者控制的一份文档若进入共享前缀，会影响所有命中该前缀的请求，危害被成倍放大。

第三道缝是合规与上下文预算的串味。用户 A 的长文档或敏感资料一旦进入共享 KV 池，用户 B 的上下文窗口预算可能被不属于自己的内容挤占；更严重的是，某些司法辖区要求用户数据在租户间物理隔离，共享缓存会直接撞上数据驻留合规红线。这不是性能问题，是能不能上线的硬约束，比前两种技术风险更不容妥协。

隔离不是全有或全无

面对风险，最省事的做法是"所有租户完全硬隔离，谁也别共享"。但这样把前面那一整块共享收益也一起扔了。实务上隔离是分级的，每一级都在收益和泄漏之间取不同平衡点。

第一级是按租户硬隔离：每个租户独立缓存命名空间，KV 绝不跨租户命中。收益损失最大——公共前缀在每个租户内各算一遍；但风险面最小，合规最稳，适合强监管或客户明确禁止数据共享的场景。

第二级是按共享语料白名单共享：只有明确的公共资产（官方系统提示词、平台级知识库、产品手册）进入共享缓存，用户私有内容一律不共享。这是多数 SaaS 的甜点区间——既吃掉最大块的固定前缀收益，又把泄漏限制在"本来就公开的内容"上。风险只剩白名单本身的管控（白名单里的东西必须真公共）。

第三级是全共享：连用户内容都参与跨请求复用，收益最高但风险也最高，只适合完全同质的匿名流量（例如公开问答机器人，所有用户共享同一套语境且内容无敏感差异）。

三者的收益损失大致是阶梯式的：硬隔离放弃约全部跨租户共享收益，白名单共享放弃的只是"用户私有前缀"那一小块，全共享几乎不放弃任何收益。选型时先看合规能不能接受共享，再看公共前缀占比够不够大值得做白名单——先看红线，再看账本，顺序不能反。

一个 SaaS 协作产品的共享策略实例

下面用前文那家文档协作 SaaS 把原则落到配置，完整走一遍背景、操作、结果、解读、变式。

背景：产品给每个请求注入同一份 8000 token 产品手册，叠加用户当前正在看的文档片段（平均 3000 token，随用户不同各异），再附上用户提问。租户是企业客户，合同里写明"客户数据不出租户"。日均请求百万级，手册部分高度稳定，但每家企业看的是自己的文档，彼此毫无重叠。

操作：采用白名单共享策略。把 8000 token 产品手册标记为一个共享缓存断点，进入全局共享缓存命名空间；用户文档片段和提问不标记共享，按租户维度隔离存储。共享前缀的写入走显式断点控制，命中统计单独上报。同时在前缀命中逻辑里加一层来源校验，拒绝任何非白名单内容进入共享区，关闭投毒窗口。侧信道方面，对共享区命中响应做时延平滑处理，抹平"命中与否"带来的可观测差异。

结果：手册部分跨租户共享后，Prefill 算力在稳态下降到原有约百分之十二，按第 6 章的 TCO 口径，月度推理账单下降约三成。用户文档片段因按租户隔离未参与共享，租户间零交叉，合规审计一次通过。来源校验上线后，内部红队尝试的前缀投毒探针全部失效，侧信道探测因时延平滑也无法稳定区分命中状态。

解读：这个 case 的关键不是"共享了"，而是"只共享了白名单里的公共资产"。它正好落在收益和风险的中间带——吃掉了最大块的固定前缀收益，却没碰用户私有内容那块高风险区。如果当初图省事选全共享，月度账单还能再降几个点，但会直接违反合同里的数据隔离条款，属于省了钱丢了单。隔离级别选错，省下的推理费远不够赔违约。

变式：若这家公司后来推出面向个人的免费版，个人版用户间无隔离需求且内容公开，可对个人版切到全共享以进一步压低成本，同时保留企业版的白名单策略。这正说明隔离级别应按"数据敏感度"而非"技术方便"来定——同一套架构，两种隔离档位，红线之内灵活，红线之外死守。

图 7-1：共享缓存收益与隔离边界示意图

把边界画进配置里

回到工程落地，共享边界最终要落到两处：一是缓存命名空间的划分（共享区与租户私有区物理分开），二是写入共享区的准入控制（只有白名单资产能进，且带来源校验）。少做任何一处，收益或安全就有一头落空。下一节我们把视角从"共享不共享"转向"端侧能不能共享"——当设备只有几 GB 显存时，连"在自己设备上留一份 KV"都要重新算账，云端的弹性优势在端侧根本不存在。