
模型网关限流设计保护下游模型也保护业务体验一、模型限流不能只看 QPS传统微服务限流常以 QPS 为核心指标但大模型服务的资源消耗并不只取决于请求次数。一个短 Prompt 和一个包含数万字上下文的请求对延迟、成本和供应商额度的影响完全不同。因此模型网关限流要同时关注请求数、token 预算、并发数、超时时间和业务优先级。如果只按接口 QPS 限流可能出现两个问题低价值长上下文请求占满模型容量导致核心业务失败或者高峰期简单问答被过度拒绝用户体验变差。模型网关应该把限流从“接口保护”升级为“资源配额治理”让不同租户、业务线和任务类型拥有清晰的预算边界。二、配额模型按租户、场景和成本分层flowchart TD A[业务请求] -- B[模型网关] B -- C[租户配额] C -- D[任务优先级] D -- E[Token 预算] E -- F[并发控制] F -- G[模型供应商] E -- H[降级回复]一个可落地的配额模型至少包含租户级日预算、接口级分钟额度、任务级优先级和用户级并发限制。租户级预算控制总体成本接口级额度保护下游容量任务优先级保障核心业务用户并发限制避免单个用户误操作拖垮系统。还要区分同步和异步任务。在线问答、客服辅助和页面生成属于同步体验必须快速失败或降级批量摘要、知识库重建和离线报告可以进入队列按预算慢慢执行。不要把所有请求都塞进同一个模型调用池否则低优先级任务会挤占在线请求。三、Java 网关实现限流结果要可解释下面是一个简化的限流判断。真实系统可以用 Redis、Sentinel、Resilience4j 或自研配额服务实现但返回结果一定要可解释。public LimitDecision check(ModelRequest request) { String tenantId request.tenantId(); int estimatedTokens tokenEstimator.estimate(request.prompt(), request.context()); if (!quotaService.tryConsumeDailyBudget(tenantId, estimatedTokens)) { return LimitDecision.reject(tenant daily token budget exceeded); } if (!concurrencyLimiter.tryAcquire(request.taskType())) { quotaService.rollbackDailyBudget(tenantId, estimatedTokens); return LimitDecision.defer(model concurrency is full); } if (request.priority().isLow() trafficWindow.isPeak()) { return LimitDecision.defer(low priority task delayed during peak traffic); } return LimitDecision.allow(estimatedTokens); }估算 token 不可能完全准确但比完全不估要好。可以先按字符数和历史比例做粗估模型返回后再用真实 token 消耗修正预算。关键是要建立“预扣减”和“最终结算”的机制避免并发请求同时通过检查后把预算打穿。四、降级策略拒绝不是唯一答案模型服务被限流时业务不一定只能返回错误。对于摘要类任务可以返回“已进入队列”对于客服辅助可以切换到小模型或模板回复对于研发助手可以提示缩短上下文对于高风险决策可以转人工。降级策略应该由业务场景决定而不是由网关统一返回 429。监控上要区分限流原因。租户预算不足、供应商额度不足、模型延迟升高、网关并发满、低优先级延迟执行这些都叫限流但处理方式完全不同。看板应展示按租户、任务类型、模型版本和失败原因拆分的数据便于产品和研发共同调整策略。最后要定期复盘额度配置。AI 调用量往往随功能推广快速增长早期写死的阈值很快失效。建议每周检查 token 消耗 Top 场景、拒绝率、降级成功率和单次任务成本把预算治理变成持续运营而不是一次性配置。多模型供应商的路由策略也能提升性价比。可以为不同任务类型配置首选模型和降级模型例如在线客服优先使用低成本模型只在置信度不足时切换大模型离线摘要可以使用异步队列配合较便宜的模型版本。路由决策应基于任务特征、成本预算、延迟要求和输出质量历史数据而不是简单地随机选择或固定配置。五、总结模型网关限流要从 QPS 思维升级到资源配额治理综合考虑 token、并发、租户、任务优先级和成本。Java 后端实现时要让限流结果可解释、可回滚、可监控并为不同业务设计合适的降级路径。