日调用量从 1000 涨到 10 万、429 错误率从 0.1% 升到 8%，我们的判断是：大模型应用走到生产环境后，最先暴露短板的通常不是模型本身，而是限流、排队和配额这些“看不见”的基础设施。
这是什么
这是一篇讲 LLM（大语言模型）应用如何做限流的工程文章，核心不是“如何多调一次 API”，而是“如何在调用暴涨时不把系统挤爆”。文章给出四层防护：按用户 Token 配额的令牌桶、全局滑动窗口限流、优先级队列，以及熔断器（下游错误过多时先暂停请求，避免连锁故障）。
值得注意的是，它把问题从“429 了就重试”提升到了“应用层流量治理”。原因很简单：模型服务商的限流通常只管你的总账户，不会替你区分哪个用户、哪个团队、哪个请求更重要。对于对话、RAG（检索增强生成，先查资料再让模型回答）这类 token 消耗波动很大的场景，只看请求次数已经不够，必须看 token 配额和调度策略。
行业怎么看
行业里对这件事的共识正在形成：模型能力越来越接近，真正决定体验和成本的，开始转向工程系统。谁能把高峰期的请求管住、把高价值用户优先服务、把异常流量挡在外面，谁的产品稳定性就更像“业务系统”而不是“演示项目”。
但也要看到反对意见和风险。第一，这类方案会明显增加系统复杂度，尤其是 Redis、队列、熔断规则一上来，维护成本并不低。第二，优先级队列和用户配额如果设计粗糙，可能引发新的公平性问题：付费用户更快，普通用户更慢，产品体验会被重新分层。第三，过度限流也可能误伤增长，团队为了压错误率，把可用性做成了“保守可用”。
我们的判断是，这不是可做可不做的“优化项”，而是大模型应用商业化后的必修课；但它更像一门运营工程，而不是一套现成代码贴上去就结束。
对普通人的影响
对企业 IT：如果公司正在接入模型 API，预算管理和服务稳定性会越来越依赖这类限流系统。以后采购大模型，不只看单价和效果，也要看内部能不能把调用配额管起来。
对个人职场：产品、技术、运营之间会多出一层共同语言：哪些请求优先、哪些用户该限额、异常时怎么降级。懂一点这套逻辑的人，会比只会“接模型”的人更有落地价值。
对消费市场：用户会越来越频繁地感受到“会员更快、免费更慢、忙时需排队”的差异。这未必是产品变差，而是 AI 服务开始像云服务一样，进入精细化分配阶段。