保护用户的限流，不只是保护上游

LLM 应用里的限流是一次解三个问题，多数实现只解一个。上游问题：模型 API 有配额，你不能超。成本问题：你自己代码里的失控循环，一个小时能花一千美元。用户保护问题：单个用户，无论是恶意还是无心，不应该把服务降级到影响所有人。

分开的限制长什么样

上游边界做按 key 限制，按 API 配额留余量。应用层做按用户限制，比上游限制更紧，按”一个用户一小时合理能消耗多少”来定。按会话的 token 预算，因为会话会随时间变长，无界会话就是无界成本。每一档限制走在不同时间尺度、不同单位上；把它们塞进一个限流器，是你被账单吓到的方式。

触发限制时怎么办

在你的应用里把预算耗尽当一等态来呈现，而不是一个泛泛错误。用户对”你的小时配额用完了”的容忍度，比对”出错了”高得多。对面向开发者的 API，返回 rate-limit header 让客户端正确退避，不要让你去逆向它的重试逻辑。对内部服务，上游限流命中就 page——那个信号通常是 bug，不是合法负载。

好的限流器在一切正常时是隐形的，不正常时是果断的。糟糕的限流器是事故之后你才想起来的那个。