靠计时窃取提示词：多租户 LLM 中的前缀缓存旁路
共享前缀缓存让 LLM API 更快——也会泄露提示词。攻击者通过对首个 token 计时，可重建另一租户的提示词。2026 年 3 月的一篇论文在不牺牲性能的前提下完成防御。
这是什么？
现代 LLM 服务系统会缓存已经完成的计算。自动前缀缓存（Automatic Prefix Caching，APC） 在后续请求以相同文本开头时，重用此前为请求开头计算出的键-值张量——这对长文档和多轮对话带来显著加速。问题在于：缓存命中（hit）比缓存未命中（miss）更快，而这一时间差从外部即可观测。在前缀缓存跨用户共享的多租户部署中，攻击者可以发送精心构造的提示词，测量首个 token 的耗时，从而推断其猜测的前缀是否与某个其他租户已缓存的内容相匹配。逐 token 重复这一探测，便能重建陌生人的提示词。
这并非纸上谈兵。斯坦福团队（Chenchen Gu、Xiang Lisa Li、Rohith Kuditipudi、Percy Liang 与 Tatsunori Hashimoto）在 Auditing Prompt Caching in Language Model APIs（arXiv 2502.07776，2025 年 2 月，被 ICML 2025 接收）中审计了真实 API，并在包括 OpenAI 在内的七家 API 提供商处检测到跨用户的全局缓存共享。同样的计时信号甚至泄露了一项架构事实：OpenAI 的嵌入模型是仅解码器（decoder-only）的 Transformer。这一研究脉络中最新的成果 CacheSolidarity（arXiv 2603.10726，2026 年 3 月）正是本文的缘起。
工作原理
这里没有需要打码的攻击载荷——攻击纯粹是对黑盒 API 的测量。机制如下：
阶段 发生了什么
--------------------------- --------------------------------------------------
1. 选定目标前缀 猜测受害者提示词可能的开头（system prompt 头部、
电子邮件地址、账户 ID 等）
2. 探测 发送以该候选开头的请求，记录首个 token 的耗时
（time-to-first-token, TTFT）
3. 判定命中 / 未命中 TTFT 低 => 该前缀已被他人缓存（hit）；
TTFT 高 => 未命中（miss）
4. 扩展并重复 追加下一个 token，再次探测，逐段推进前缀攻击者从不直接读取其他用户的数据；它们是从延迟中推断出来的。后续工作显示了其威力：据 SafeKV 研究转述，PromptPeek（Wu 等，2025）在已知提示词模板时可以高达 99% 的准确率重建提示词，未知模板时约为 95%，其针对的是 SGLang 等框架所用的基数树（radix tree）前缀调度。CacheSolidarity 与 SafeKV 都列出了同一组内置前缀缓存的系统：OpenAI、DeepSeek、Google Gemini、MoonShot Kimi、vLLM 与 SGLang。
为什么重要
暴露面随着进入共享前缀的敏感文本量而增长。SafeKV 作者指出，C4、Pile 等常见预训练语料中包含用户名、电话号码、支付卡号与社会安全号——一旦被缓存并跨租户共享，恰恰是这类序列会变得可被推断。凡是放在提示词开头的内容——含密钥的 system prompt、为提供上下文而前置的客户记录、检索到的文档——都可能被同租户重建。
需要客观看待：这是在特定条件下的机密性泄露，并非远程代码执行。攻击者需要一个跨安全边界共享缓存的多租户服务、一个可测量的时间差，以及足够的探测预算。CacheSolidarity 自身的分析强调，可利用性取决于硬件、模型规模、系统负载与请求长度——在某些配置下，命中/未命中的差异噪声过大，难以武器化。这是真实的缓解因素，但它是部署的属性，而非保证。
防御
研究已收敛到三类防御，按其”切割”的精细程度呈现清晰递进。
- 完全的按用户隔离。 彻底关闭跨租户前缀共享；每个用户（或组织）拥有私有缓存。这能关闭旁路，但放弃了 APC 的收益。SafeKV 测得隔离会使大模型的首 token 耗时上升至多约 38%；CacheSolidarity 也报告了类似代价。有效、粗暴、昂贵。
- 时间混淆。 通过填充（padding）或抖动（jitter）让命中与未命中看起来一致。两篇论文都点明其陷阱：攻击者只需统计上的可分性，因此必须将命中响应填充到未命中分布的慢尾——这会抹去大部分延迟收益，并抬高 P95/P99。
- 选择性隔离。 默认共享，仅隔离有风险者。SafeKV（arXiv 2508.08438）异步地对敏感前缀分类并将其保持私有，相较完全隔离将吞吐恢复至多 2.66 倍。CacheSolidarity 更进一步：它跟踪前缀的归属，标记被多个用户可疑重用的前缀并仅隔离这些前缀——还配有一个”Activator”，仅当时间差对当前硬件与负载真正可分时才启用隔离。该系统构建于 vLLM 之上，在九个模型（5 亿至 130 亿参数）上评估，报告称相较按用户隔离，缓存重用最多提高 70%、延迟最多降低 30%，开销可忽略，作者并表示将开源。
对于运营或采购 LLM 推理的团队，实用清单如下：
- 不要把机密放在共享前缀的位置。 让 API 密钥、凭证与各用户专属的个人信息远离 system prompt 与请求中可缓存的开头部分。
- 将缓存限定在信任边界内。 按组织或按租户划分的缓存可消除跨租户旁路；请确认你的提供商采用此方式，而非全局共享。
- 把缓存策略当作采购问题。 询问供应商前缀缓存或语义缓存是否在客户间共享、缓存条目保留多久——审计中的提供商保留时长从数分钟到数天不等。
- 若自托管，优先选择选择性隔离。 完全隔离有效但昂贵；SafeKV 与 CacheSolidarity 式的方案在关闭旁路的同时保留了加速收益。
状态
| 项目 | 参考 | 日期 | 备注 |
|---|---|---|---|
| API 实证审计 | arXiv 2502.07776（斯坦福，ICML 2025） | 2025-02 | 7 家提供商存在跨用户缓存共享，含 OpenAI |
| 提示词窃取攻击 | NDSS 2025（Wu 等） | 2025 | 经共享 KV 缓存，提示词重建率高达 99% / 95% |
| SafeKV（选择性隔离） | arXiv 2508.08438 | 2025-08 | 异步敏感度分类；吞吐相较隔离至多 2.66 倍 |
| CacheSolidarity（选择性隔离） | arXiv 2603.10726 | 2026-03 | 标记可疑重用；相较隔离重用最多 +70%、延迟最多 -30% |
两年研究的主线是：LLM 服务赖以提速的优化——前缀缓存与 KV 缓存共享——一旦缓存跨越信任边界，也就成了机密性旁路。2026 年的工作并不要求你在速度与安全之间二选一；它表明，只需隔离少数真正关键的前缀，而非把每个用户都隔开，便可关闭该旁路。