14 篇博文 含有标签「multi-tenancy」

告警在凌晨 2:47 响起。面向客户的聊天助手正为一半的付费用户返回 429 错误。工程师们在仪表板中忙乱寻找，试图找到那天下午发布的 Bug。他们一无所获 —— 代码没问题。真正的罪魁祸首是另一个团队在当晚启动的批量摘要任务，它共享了同一个供应商 API 密钥，耗尽了该账户接下来四小时的每分钟 Token 预算。没有人拥有这个共享密钥，也没有人负责这个限制。

这就是“喧闹邻居”（noisy-neighbor）问题。与经典的 API 配额事故不同，它在 LLM 系统中表现出一种独特的残酷性。一个达到速率上限的 REST 端点会迅速失败并进行重试；而 LLM 的“每分钟 Token”（TPM）桶是根据请求内容非对称消耗的。因此，一个生成 8K Token 的功能可能会使一个进行低成本 200 Token 分类调用的功能陷入饥饿，而这一切在请求计数图表中甚至都不会显现。流量在你所测量的维度上并不“喧闹”。

大多数团队发现这一点的方式正如上文提到的团队：一个无关团队的任务与付费用户的会话发生冲突，而两者唯一的共同点只是环境变量中的一个字符串。

大多数多租户 LLM 产品都存在一个其工程师尚未测试过的安全漏洞。这并非理论上的漏洞 —— 而是一个实实在在的漏洞，已有记录在案的攻击向量和真实的确认案例。这个漏洞在于：现代 AI 栈中的每一层都引入了自己的隔离原语，而每一层都可能以静默的方式失效，导致一个客户的数据进入另一个客户的上下文。

这与提示词注入（prompt injection）或越狱（jailbreaking）无关。它关乎基础设施本身 —— 提示词缓存（prompt caches）、向量索引（vector indexes）、内存存储（memory stores）和微调流水线（fine-tuning pipelines） —— 以及大多数团队在未经核实的情况下就交付的“隔离”这一组织层面的虚构。