为什么 LLM 应用需要多层配额设计
传统 API 的限流通常只关注防刷和过载保护,但 LLM 应用面临三个特殊挑战:成本高昂且按 token 计费、响应时间不可预测、多租户场景下需要精细化成本分摊。一个设计不当的配额系统会导致单个用户耗尽整个租户预算,或者某个租户拖垮整个应用的响应性能。
四层设计的核心思路是在不同粒度上设置防线,每层解决特定问题:用户级防止个体滥用,租户级实现商业隔离,应用级保护整体资源,基础设施级应对突发流量。
第一层:用户级配额 - 防止个体滥用
这是最细粒度的控制,通常包含两类限制:
请求频率限流:例如限制单个用户每分钟最多 10 次对话请求。实现时可以用 Redis 的滑动窗口计数器,键名设计为 rate:user:{user_id}:{window}。注意要区分轻量档模型和旗舰档模型的配额——旗舰档成本更高,限制应该更严格。
Token 用量配额:假设一个 SaaS 产品的免费用户每月有 10 万 token 配额,付费用户有 100 万。这需要在每次请求前检查累计用量,并在请求后异步更新计数。关键工程细节是要同时记录输入和输出 token,因为两者计费规则可能不同,且输出 token 通常更贵。
用户级配额的误区是设置得过于宽松。如果你的付费套餐是每月 50 元,单次旗舰档模型调用成本可能就接近 1 元,那么允许用户单日无限调用显然不合理。
第二层:租户级配额 - 商业隔离与成本控制
在 B2B SaaS 或白标部署场景中,租户(tenant)是独立的组织客户。租户级配额解决两个问题:
防止单租户挤占资源:假设你的应用服务 20 家企业客户,如果不做租户级限流,某家客户的内部培训活动可能在一小时内发起数万次请求,导致其他客户响应变慢。可以为每个租户设置 QPS 上限(例如每秒 50 次请求)和并发上限(例如同时最多 10 个流式响应)。
成本分摊与预算控制:每个租户通常有独立的账单周期和预算。实现时需要维护 quota:tenant:{tenant_id}:monthly 这样的计数器,并在接近阈值时触发告警或降级(例如自动切换到轻量档模型)。关键是要提供实时用量仪表板,让租户管理员能看到当前消耗和剩余配额。
租户级的工程难点在于多层嵌套:一个租户下有多个用户,用户配额耗尽后是否还能继续使用租户的共享配额?这需要明确的业务规则和优先级设计。
第三层:应用级配额 - 整体资源保护
这一层保护的是你的应用整体,防止所有用户和租户的总请求量超出后端承载能力或预算上限。
全局 QPS 限流:假设你的应用每月 LLM 成本预算是 10 万元,按旗舰档模型平均每次调用 0.5 元估算,月度总调用量上限约 20 万次。折算到秒级就是每秒约 77 次请求的平均速率。可以用令牌桶算法实现,允许短时突发但长期平均不超标。
模型调用队列:LLM 请求的响应时间可能从几秒到几十秒不等,直接放行所有请求会导致后端连接池耗尽。实现一个优先级队列,付费用户请求优先处理,免费用户请求在高峰期排队等待,超时后返回 503 Service Unavailable 并提示用户稍后重试。
应用级配额的关键是可观测性:需要实时监控当前 QPS、队列长度、平均响应时间和成本消耗速率,并设置自动熔断机制。
第四层:基础设施级限流 - 最后防线
即使前三层都失效,基础设施层也要有兜底保护:
API 网关限流:在 Nginx、Kong 或云服务商的 API Gateway 上设置全局速率限制,例如单 IP 每秒最多 100 请求。这能防御 DDoS 和恶意脚本。
上游供应商配额:如果你使用 OpenAI、Anthropic 等服务商的 API,他们通常有自己的 RPM(每分钟请求数)和 TPM(每分钟 token 数)限制。要在你的系统中预留 20% 的安全边界,不要把上游配额用满,否则一旦触发限流会导致大量请求失败。
成本告警与自动熔断:设置日成本阈值告警(例如单日超过预算的 150% 时自动暂停所有非关键请求),并通知运维人员介入。这是防止账单意外爆炸的最后一道防线。
实现建议与工程权衡
四层设计不是要全部实现,而是根据业务阶段选择:
- MVP 阶段:至少实现用户级 token 配额和应用级全局限流
- 多租户 SaaS:必须实现租户级隔离,否则商业模型无法成立
- 高并发场景:需要完整的四层设计加上请求队列和降级策略
技术栈选择上,Redis 是配额计数的标准方案,但要注意持久化策略——纯内存模式下重启会丢失计数,建议开启 AOF 或定期同步到数据库。对于 token 用量这类需要精确计费的数据,每次更新后应异步写入持久化存储。
如果你的团队正在构建多租户 LLM 应用,或需要优化现有系统的成本控制,Taylent Labs 提供 AI 应用架构咨询与定制开发服务,欢迎联系我们探讨具体方案。