14 篇博文 含有标签「rate-limiting」

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

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

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

在峰值流量期间，部分 LLM 提供商的失败率超过 20%。当系统撞上这堵墙，并通过加倍等待时间和重试来应对时，你解决的是一个错误的问题。指数退避处理的是单次调用的韧性，对整个系统毫无作用——无法减少浪费的 token，无法解决连接池耗尽，也无法照顾到排在刚收到 429 响应那个请求后面的 50 个请求。

冲击 LLM API 的流量模式也发生了根本性变化。2023 年到 2025 年间，100 token 以下的简单查询从占流量的 80% 骤降至约 20%，而超过 500 token 的请求则成为持续的多数。Agentic 工作流在短时间内串联 10-20 个顺序调用，产生的流量模式在传统的每分钟请求数（RPM）限速下，与 DDoS 攻击别无二致。为负载可预测的 REST API 构建的基础设施，并不是 LLM 流水线所需要的基础设施。