5 篇博文 含有标签「multi-tenant」

你的仪表盘显示 GPU 状态健康。利用率维持在 80% 左右，每秒生成的 token 吞吐量看起来很正常，冷启动很少见，而且模型也是你要求的那个。然而，你的报警器响了，因为 p99 延迟翻了三倍，少数用户遇到了超时，支持工单都在描述同一件事：“应用冻结了 20 秒，然后又恢复了。” 你调取了一个追踪（trace），发现一个毫不相关的客户发送的 28,000 个 token 的推理请求，正与每一个停滞的调用处在同一个批次（batch）中。某个租户的深度思考提示词刚刚抢走了其他所有人的机会。

这就是队头阻塞（head-of-line blocking），它是推理模型进入流量组合后，破坏共享 LLM 推理的典型故障模式。这种模式并不新鲜 —— 存储系统和网络栈已经与之斗争了几十年 —— 但由于连续批次（continuous batching）和 KV 缓存固定（KV-cache pinning）的工作方式，它在 GPU 上呈现出一种特定的形态。大多数团队针对平均负载进行设计，却太晚才发现，一旦请求大小不再相似，“共享推理更便宜”就不再成立了。

错误报告显示服务很慢。仪表板显示服务很健康。每分钟 Token 使用量处于层级上限的 62%，稳稳处于绿色安全范围内。然后你打开追踪（traces）查看形态：一个用户请求生成了一个规划步骤，该步骤发出了 11 个并行工具调用，其中 4 个是搜索扇出，每个都触发了子智能体，而这些子智能体又分别并行调用了 3 个工具——那个单一的“请求”现在正同时从 47 个不同的工作线程猛击你自己的 Token 桶。产品的其他 99 名用户被堵在它后面，收到了他们本不该得到的 429 错误。你的智能体正在对自己发起 DoS 攻击，而速率限制器（rate limiter）正在忠实执行你给它的指令。

这就是速率限制层级崩塌。你购买了为 HTTP API 设计的边界防御系统，在那样的系统中，一个请求等于一个工作单元；然后你把它连接到一个请求意味着深度未知且分支因子无界的树形系统前端。单一桶模型不仅无法提供保护，而且它的失败是隐形的，因为你的聚合数据从未突破任何限制。损害发生在尾部、相关的爆发中，以及那些恰好在时间上紧邻重度请求的专注用户身上。

语义缓存命中是唯一一种能在不到一毫秒的时间内，将错误答案发送给错误用户的 LLM 优化方式。SQL 缓存之所以会返回你或他人的数据行，是因为有人写错了 join —— 这种故障模式属于查询 bug。而语义缓存返回另一个租户的响应，是因为两个 embedding 在 0.03 的余弦距离内落到了一起，这正是系统完全按设计运行的结果。缓存完成了它的工作，问题在于这份工作本身。

大多数团队将语义缓存作为一种成本方案来推行 —— 每个 AI 工程 Slack 频道里都流传着一份“削减 70% 账单”的 PPT —— 并且像对待 Redis TTL 一样审查缓存键（cache key）：完全不审。这种审查通常交由性能团队负责。安全团队永远看不到设计文档，因为没有人会为“我们增加了一条更快的路径”提交安全审查。六个月后，某人的合规审计发现，“我无法登录我的账户，我的电子邮件是 [email protected]”和“我无法登录我的账户，我的电子邮件是 [email protected]”在向量化后都处于“我无法登录我的账户”的阈值内，于是缓存愉快地向 Bob 提供了原本为 Jane 生成的响应，其中包含了她账户请求的密码重置链接。

这篇文章将讨论为什么语义缓存值得拥有与 SQL 谓词相同的审查严谨性、如何通过缓存键设计从结构上防止跨用户泄露，以及你需要什么样的审计追踪来区分“缓存命中提供了正确答案”与“缓存命中在亚毫秒级延迟下提供了他人的答案”。

2024 年 8 月，安全研究人员发现 Slack AI 在回答查询时会将公开频道和私密频道的内容同时拉入同一个上下文窗口。公开频道中的攻击者可以精心构造一条消息，当 Slack AI 摄取该消息时，就会将指令注入受害者的会话——由于 Slack AI 不引用来源，由此导致的数据外泄几乎无从追踪。这种攻击甚至可以泄露私信中嵌入的 API 密钥。Slack 在负责任披露后修复了这一问题。

这并不是传统意义上的漏洞。它是将上下文视为无用户访问控制的共享可变资源所带来的后果。而这正是大多数正在构建共享 AI 助手的团队现在都在犯的错误，只是更加悄无声息而已。

大多数团队最初都使用单一的 LLM 提供商 API 密钥，并在所有业务中共享。这在起初行得通，直到某天它突然失效。也许在某个下午，数据管道中的一个批量任务耗尽了全部速率限制，导致面向用户的聊天功能陷入沉寂。或者财务部门要求你按团队细分 4 万美元的 LLM 账单，而你意识到自己根本无法回答这个问题。

在 LLM 提供商前部署生产级 API 网关可以解决这两个问题 —— 但它也会引入一类复杂性，大多数团队在遇到麻烦之前往往会低估这种复杂性。