DashScope 限流 fallback 路由：阿里云把 429 变成模型策略问题

DashScope 限流 fallback 路由不再只是藏在 429 响应后的错误处理细节。阿里云百炼（Model Studio）现在把限流写成了账号级运营面：RPM、TPM、短时突发保护、按模型独立的额度、Batch API 例外、备选模型重试、小时级监控、费用告警，以及 30 天有效的临时 TPM 提额。对通过 DashScope 路由 Qwen 和第三方模型的团队来说，实际结论很直接：限流策略应该放在 gateway 里，而不是散落在某个 SDK retry loop 中。

发生了什么

阿里云百炼的限流页面说明，DashScope 限流按主账号维度计算。RAM 子账号、业务空间和 API Key 的调用量会合并统计。不同模型有独立的限流表，但如果多个应用共享同一账号和业务空间假设，仍然可能在同一模型族下互相挤占容量。

文档区分了几类经常被客户端统一折叠成 429 的失败模式。Requests rate limit exceeded 或 You exceeded your current requests list 指向 RPM 压力。Allocated quota exceeded 或 You exceeded your current quota 指向 TPM 压力。Request rate increased too quickly 又是另一类：阿里云将其描述为请求频率在短时间内激增触发的系统稳定性保护，即使总 RPM 或 TPM 尚未达到表格中的上限，也可能触发。页面还说明，服务可能按由分钟级限额折算出的秒级 RPS 和 TPS 执行限制。

对 operator 最有价值的是阿里云给出的缓解建议。文档建议在合适场景优先使用 qwen-plus 等高限流模型，注意稳定版或最新版 alias 通常比带日期的 snapshot 限流更宽松；遇到 RPM 错误时降低调用频率；遇到 TPM 错误时缩短输入或限制输出长度；用队列、指数退避和平滑调度削峰；模型被限流后切换到备选模型；拆分大型任务；非实时任务使用 Batch API；并在控制台申请临时 TPM 提额。示例代码展示了在 qwen-plus-2025-07-28 触发 429 后，fallback 到 qwen-plus-2025-07-14。

为什么对 AI 工程团队重要

DashScope 限流 fallback 路由重要，是因为同一个 provider 账号往往承载多类 workload：chat completions、coding agents、文档处理、语音或多模态实验，以及内部 eval 任务。如果它们在没有路由策略的情况下共享 API Key 或 workspace，一次突发的 agent run 就可能让普通生产聊天看起来像 provider 不稳定。

这些失败模式也要求不同处理方式。RPM 压力说明请求数过多。TPM 压力说明 workload 消耗了太多 token。突发保护说明调度过于尖峰。天真的 fallback 如果把所有 429 都发到更便宜的模型，可能保住 API 形状，却丢掉质量、上下文窗口、structured output、tool support 或合规约束。更糟的是，它会把流量搬到第二个模型的 quota bucket，而没有解决最初导致失败的突发模式。

模型表也强化了这一点。当前 DashScope 列表中，qwen3.7-max、qwen3.7-plus、qwen3.6-flash 等高限流 rolling alias 与 RPM 低得多的日期 snapshot 并列存在。这意味着 model ID 不只是能力标签，也是容量契约。为了可复现性而 pin 日期 snapshot 的团队，需要为更窄的实时容量做预算，或把更多任务路由到 Batch API。

路由与运维视角

router/operator 角度是：先分类 DashScope 429，再决定 fallback。一个实用策略应把错误原因当作路由信号：

1. RPM pressure: queue、丢弃低优先级流量，或只把幂等请求切到兼容的 backup model。
2. TPM pressure: 缩短输入、降低 max_tokens、下调 reasoning 或 thinking budget，或先路由摘要再重试完整任务。
3. Burst protection: 加 jitter、平滑并发，避免把整个尖峰立刻 failover 到另一个模型 bucket。
4. Realtime vs batch: 把非交互任务送到 Batch API，不要和交互式用户流量抢实时额度。
5. Temporary capacity: 为已知活动或迁移申请 30 天 TPM 提额，但要在路由计划里记录到期时间。

这也会改变 observability。DashScope operator 应该为每个请求打上 workload class、workspace、model alias、versioned model ID、retry reason、fallback target，以及最终响应来自 rolling alias 还是 pinned snapshot。没有这套 ledger，成功 fallback 反而会掩盖一个产品团队正在消耗另一个团队 quota 的事实。

TheRouter 用户应该把这些 lane 映射到 provider policy，而不是散落在应用代码中。可以从 TheRouter docs 的请求路由概念开始，再结合此前的 DashScope workspace endpoint routing analysis 和 Qwen3.7-Plus default-tier routing analysis。三者合在一起，定义了一个稳定 DashScope route 的三块基础：endpoint/workspace、model tier 和 rate-limit behavior。

TheRouter 用户应关注或尝试什么

第一，在增加更多 backup model 之前，先按 workload class 拆分 DashScope 流量。交互聊天、coding agents、eval batches、文档抽取和媒体相关任务，不应该共享一条无差别的 quota path。如果暂时无法拆账号，至少拆 API Key、metadata、dashboard 和 retry budget。

第二，显式编码 fallback compatibility。qwen-plus 的 backup model 可能适合普通对话，但不一定适合 structured-output routes、长上下文分析或 tool-using agents。把所需上下文窗口、structured-output support、tool policy、latency target 和可接受的最高成本，和每条 route 一起存储。

第三，把临时 TPM 提额当成 operational debt。30 天提额可能非常适合发布、迁移或 eval campaign，但它应该同时创建到期提醒、成本复盘和活动后的 rollback plan。DashScope 限流 fallback 路由只有在容量、成本和模型质量一起规划时才最稳，而不是等生产环境出现 429 后再临时发现。