2 篇博文 含有标签「api-gateway」

收到一张读起来像幻觉一样的客户支持工单。用户附上了一张截图：一个他们从未问过的问题，顶部显示着他们的账户名，接着是引用了他们从未上传过的文件的模型回复。追踪记录看起来很干净。模型完全按照要求执行了任务。问题在于，这个提问完全来自另一个租户，而你的网关由于 conversation_id 值发生了碰撞，将两个对话路由到了同一个后端状态。

你在餐巾纸上算了算。UUID v4 有 122 位的熵。在 5000 万个对话的语料库中，发生任何碰撞的生日边界概率远低于五千万分之一。一年前设计系统时你跑过这个计算。数学是正确的。数学现在依然正确。改变的是你的两个后端层不再以相同的方式生成 ID，而数学所描述的概率从来就不是你实际运行中的概率。

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

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