单租户推理隔离：当共享缓存、微调模型和嵌入在客户间泄露时

多租户 SaaS 在十年前就解决了数据隔离问题。Postgres 中的行级安全性（Row-level security）、每个租户的加密密钥、范围限定为租户前缀的 S3 存储桶策略——到 2018 年，这套方案已经非常成熟，以至于当审计员询问“向我展示客户 A 的数据如何无法触及客户 B 的数据”时，只需要提供一份一页纸的回答，并在每一层附上引用即可。AI 功能悄然重新引入了这个问题，而现在的答案不再只有一页纸。

有趣的部分并不是 AI 破坏了隔离。有趣的是它在 哪里 破坏了隔离：不是审计团队守卫了十年的数据层，而是没有人画在图表上的四个新层级。提示词缓存前缀（Prompt cache prefixes）以跨请求共享 KV 状态的方式，将首字生成时间（time-to-first-token）变成了一个侧信道。在聚合客户数据上训练的微调模型会记住特定租户的措辞，并将其反馈给错误的客户。当威胁模型要求物理分离时，嵌入索引（Embedding indexes）却通过查询过滤器进行逻辑分区。跨请求的 KV 缓存重用创建了时间信道，而当“共享推理没问题”被视为一种合理的捷径时，没有人对此进行过威胁建模。

本篇文章讨论了发生了哪些变化，以及当你认真对待这个问题时，这种规范看起来是什么样子的。

共享推理模式正在过时

当两个请求之间唯一共享的是 GPU 和模型检查点时，单租户推理是没问题的。模型是输入 Token 的纯函数。缓存是基于每个请求的。嵌入索引属于一个客户，因为当时只有一个客户。微调是针对单一用途的。但在 2026 年的生产堆栈中，这些假设都无法成立。

现代服务运行系统——vLLM、SGLang、TGI，以及主要 API 提供商内部的闭源等效系统——都在激进地共享状态，因为这是降低成本的关键。自动前缀缓存（Automatic prefix caching）在具有相同提示词前缀的请求之间重用 KV 块。连续批处理（Continuous batching）在同一个前向传播中混合了多个租户。投机采样（Speculative decoding）共享草案模型状态。嵌入索引将数百万租户整合到一个 ANN 图中，以便在客户数量增长时召回率保持平稳。微调模型池化了数据，因为梯度的信号收集成本很高。

每一个决策孤立来看都是正确的，但集合在一起就是错误的。2026 年 NDSS 的论文 I Know What You Asked 表明，vLLM 和 SGLang 的 KV 缓存共享——正是这个让你的推理成本降低 40% 的功能——允许恶意租户通过发出精心设计的查询并记录响应时间来重建另一个租户的提示词。这种攻击不需要破坏加密，也不需要模型漏洞。它只需要两个租户共享一个启用了前缀缓存的运行时环境，而这在各处都是默认设置。

这种模式在 AI 功能为了性能而牺牲隔离的每一个层级都在重复。解决办法不是关闭优化，而是在威胁模型要求的层级上有意识地支付“隔离税”，并清楚哪些层级需要这样做。

第一层：作为侧信道的提示词缓存

提示词缓存是最清晰的例子，因为这种泄露是可以证明的，且数学原理是公开的。当一个请求进来时，运行时会哈希提示词前缀，并检查 KV 状态是否已在 GPU 显存中。命中意味着首字生成时间（TTFT）从几百毫秒缩短到几十毫秒。未命中则意味着需要支付完整的预填充（prefill）成本。这种差异是巨大的、确定性的，并且可以从网络客户端测量。

如果两个租户共享该缓存，攻击者可以通过发送带有猜测前缀的提示词来探测缓存。较短的 TTFT 意味着前缀匹配到了缓存的内容。通过足够的探测——现在的攻击文献中已有使用强化学习的变体，需要的探测次数出奇地少——你就能重建另一个租户的提示词内容。

缓解措施分为三类，且它们并不等效：

• 全租户隔离 在缓存层禁用共享。每个租户获得自己的缓存命名空间；跨租户探测始终会未命中。这是唯一能抵御坚定攻击者的缓解措施，也是最昂贵的一种，因为你放弃了之前追求的缓存重用收益。
• 时间模糊化 向 TTFT 注入噪声以掩盖缓存命中的信号。它成本较低但并非万无一失——如果噪声分布是有界的，足够的探测最终仍能恢复信号，而且攻击文献的发展速度比防御文献更快。
• 选择性隔离 对分类为非机密的提示词共享缓存，并隔离其他所有内容。像 CacheSolidarity 这样的方案会监控跨用户重用，标记可疑的共享，并自适应地隔离前缀。这是目前的研究前沿，也是大多数生产团队应该关注的方向，因为它保留了大部分的成本优势。

运营方面的启示是，“我们使用了提示词缓存”不再是一个完整的回答。完整的回答应该是：“我们使用了提示词缓存，并将其限定在每个租户的命名空间内，我们的威胁模型记录了在什么情况下租户 A 的缓存会影响租户 B 的 TTFT。”如果你说不出这句话，那么你的提示词缓存就是一个等待研究人员发表论文的侧信道。

第二层：会记住训练集的微调模型

第二层的影响显现最慢，但伤害最大。在聚合客户数据上训练的微调模型会记住这些数据的片段——这不是指模糊的分布意义上的记忆，而是指提取提示词可以从模型中拉取出逐字对应的原文序列。2024 年关于从微调大语言模型（LLMs）中提取训练数据的研究指出，在真实场景下，可恢复的部分超过 50%。2026 年关于 LoRA 微调的最新研究显示，尽管泄露量小于全量微调，但依然存在，且泄露集中在模型的高层。

失效模式并不是攻击者从模型中提取出了某个客户的 API 密钥。失效模式更为枯燥，但在法律上更令人不安：租户 A 的微调模型是在包含租户 B、C 和 D 的措辞、名称、内部术语或文档片段的语料库上训练的。现在，模型生成的输出在租户 A 的会话中显现了租户 B 的词汇。没有人发起攻击。训练流水线完成了它的工作。合同规定租户数据不会影响其他租户的输出，而该模型在结构上违反了这一合同。

必须建立的规范是 训练数据血缘 (training-data lineage)。微调集中的每个示例都有一个租户标签。默认策略排除任何跨租户聚合；加入必须通过明确的合同许可，而非默认不反对。训练流水线会生成一份清单，列出所有影响最终权重的租户。当客户询问“我的数据是否训练了你的模型”时，答案是对清单的查询，而不是猜测。

这里的架构认识是：微调模型是训练数据的 存储衍生品 (stored derivative)，具有与数据库相同的合规属性——在没有合同许可的情况下，你绝不会将所有客户的交易数据聚合到一个共享表中，微调模型面临的是同样性质的问题。大多数团队在法务部门第一次审计训练流水线时，才会意识到这一点。

第三层：嵌入索引与逻辑 vs 物理陷阱

向量数据库支持两种模式的多租户，其区别至关重要。逻辑 (Logical) 多租户将所有租户存储在同一个索引中，并在查询时通过 tenant_id 谓词进行过滤。物理 (Physical) 多租户则为每个租户提供自己的索引、命名空间或集合——即独立的 ANN 图、独立的内存和独立的查询路径。

逻辑隔离成本低廉，且能很好地在数百万个小租户之间进行负载均衡。但它也会以三种可预见的方式失败。第一种是“缺失过滤器”的 Bug，即本应包含 tenant_id = $current 的查询路径却没有包含，导致 ANN 搜索返回了跨越边界的邻居。代码审查能发现其中的一部分；生产环境的流量则会暴露其余部分。第二种是“元数据泄露”路径，即过滤器排除了向量，但列表 API 或管理界面却返回了跨租户的向量 ID 和元数据。第三种——这一点并不直观——是 原生的跨租户相似性 (organic cross-tenant similarity)：由于现实世界存在共享话题，一个租户的文档可能在语义上接近另一个租户。即使过滤器正确，一个合法的查询也可能返回泄露的内容，因为过滤器是在检索之后应用的，而不是作为 ANN 遍历内部的前置过滤。

物理隔离为每个租户提供自己的索引。跨租户查询在结构上变得不可能，而不仅仅是被政策禁止。代价是小租户需要承担额外开销，而超大规模多租户模式会触及底层引擎的单索引限制。Pinecone 的命名空间 (namespaces)、Weaviate 的“一集合一租户”以及 Qdrant 的“一租户一集合”模式之所以存在，是因为业界得出结论：逻辑隔离的失效成本太高，无法持续承担。

这个决定是由威胁模型驱动的，而非个人偏好。如果你的租户彼此是竞争对手，或者其中任何一个是受监管的，且审计员会直接询问跨租户隔离问题，那么答案就是物理隔离。如果你的租户是低风险功能的独立用户，最坏的情况只是在大规模客户群中出现极少数泄露，那么带有审计过滤器的逻辑隔离是可以辩护的。团队常犯的错误是选择了逻辑隔离，因为它是默认选项，结果在审计时才发现威胁模型始终要求的是物理隔离。

第四层：无人建立威胁模型的 KV 缓存侧信道

第四层是大多数团队从未关注过的。现代推理运行时出于显式提示词缓存之外的原因，会在请求之间共享 KV 缓存状态：连续批处理 (continuous batching) 将多个租户打包在同一个前向传播中，投机解码共享草稿模型状态，而分页注意力 (paged attention) 在逻辑序列之间重用物理内存块。每一项都是性能上的进步，但也都是潜在的信息通道。

2024 年的论文 The Early Bird Catches the Leak 记录了 vLLM 风格服务中的时间信道，通过调度请求的时间可以揭示队列深度，进而揭示其他租户的流量模式。2025 年的 NDSS 研究将其扩展到了提示词内容重建。2026 年的 Selective KV-Cache Sharing 论文正式界定了哪些共享模式是安全的，哪些不是，其结论大致是“跨租户边界的共享默认是不安全的”。

缓解措施并非禁用批处理——那将牺牲让 AI 功能落地的 GPU 经济效益。缓解措施是 限定在安全域内的批处理 (batching scoped to a security domain)。来自同一信任级别的租户请求可以被批处理在一起；跨信任级别的请求则由独立的批次、队列或副本提供服务。这会损耗 GPU 利用率，但换取了你回答审计员问题的能力。

更深层的架构观点是：推理时的每一个共享资源都是潜在的侧信道。审计员的问题——“向我展示客户 A 的查询如何无法影响客户 B 的输出”——是一个关于全链路的问题：缓存、批处理、嵌入索引、微调模型、日志流水线、错误路径。如果该链路中的任何环节在没有记录隔离边界的情况下被共享，那么对审计员问题的回答就是“我们不知道”，在受监管的行业中，这等同于“否”。

必须落地的纪律

这四个层级的模式都是一样的：一个旨在提升性能的功能，在不知不觉中引入了跨租户状态。修复的方法并非移除该功能，而是限定其作用域。

一个生产级的单租户推理隔离方案至少应涵盖以下方面：

• 像审计行级过滤器一样审计缓存命名空间。 每个缓存层——提示词缓存、语义缓存、嵌入缓存——在查找路径中都包含租户密钥，并且该密钥已被纳入威胁模型。团队可以根据需要随时提供测试证明，以确保跨租户探测会失效。
• 微调训练数据的血缘追踪。 默认情况下禁止跨租户聚合。选择加入（Opt-in）必须是合同约定的，而非隐式的。训练流水线会生成一份清单，列出哪些租户的数据影响了权重。该清单是持久化且可查询的。
• 在威胁模型要求的地方对嵌入索引进行物理隔离。 对于低风险的大扇出（large-fanout）模式，逻辑多租户是可以接受的；但在竞争对手租户共享基础设施，或审计员会对跨租户问题提出质疑的情况下，必须进行物理隔离。
• 将推理批处理限定在安全域内。 请求应在同一信任级别内进行批处理，严禁跨级别批处理。这种纪律的成本是真实且可衡量的；而忽视它的代价则是写一份事故复盘报告（postmortem）。
• 对租户的合同级承诺。 合同中应明确规定租户数据会（或不会）影响哪些环节——训练、缓存、检索、遥测——并且工程实现必须逐条匹配合同条款。销售人员的承诺与系统运行时实际表现之间的不匹配，是此类事件中代价最高昂的一种。

最终形成的闭环认知是：“共享推理没问题”这种姿态在 AI 功能尚处于实验阶段、租户能容忍一定模糊性时是站得住脚的。但只要你的客户同时也成为了你竞争对手的客户，这种做法就会迅速崩塌——此时，这就不再是一个学术问题，而是一个关乎续约的谈判。那些能妥善处理这一问题的团队，通常在被迫采取行动之前就提前支付了“隔离税”。而处理不当的团队则会在审计时发现，“我们以后再添加租户隔离”是 AI 时代的“我们以后再添加加密”——这句话在出事之前听起来总是很合理。

这种架构层面的认知比 AI 本身还要古老：每一个共享资源都是一个潜在的泄露路径，唯一持久的对策是让共享变得有意为之、限定范围并可审计。这四个新层级——提示词缓存、微调、嵌入索引、KV 缓存复用——只不过是我们需要付出全额代价重新学习这一教训的最新场所。