阿里云百炼限流全表实测：162 张表里，同一个模型换个名字，RPM 能差 500 倍

本文数据全部来自阿里云官方文档《限流》页面（页面标注更新时间 2026-10-12 16:45:36），由 timew 在 2026-10-15 12:0x 直接抓取该页 HTML 后逐表解析得到。文中所有 RPM / TPM 数字均可在官方原表逐行核对，未做任何估算或推断。凡官方未写的，本文一律标 UNKNOWN。

一、多数人第一次遇到 429，并不是因为”买得太少”

如果你在百炼上调模型，偶发撞到 429，多数人会先去充值。但官方 FAQ 里有一句话把这事说死了：

充值不改变模型默认的 RPM 和 TPM 限流阈值。限流按阿里云主账号维度配置，与计费相互独立；充值（按量付费）仅确保账号不因欠费停服，不会提升限流值。如需更高的限流额度，请联系商务经理申请。

这句话意味着：限流和你的钱包余额是两套完全独立的机制。你充值十万元，qwen-plus 在北京地域的 30,000 RPM 依然还是 30,000 RPM。真正能改变限流值的只有两个动作——换模型，或者联系商务。

而”换模型”这件事，恰好是这份文档里信息密度最高、也最被忽略的部分。本文把这张页面完整拆开：它一共包含 162 张限流表，覆盖 11 个模型家族、多个地域、多种第三方直供通道。真正的问题不是”你超了限流”，而是你以为的限流值和真实的限流值可能差 500 倍。

二、先搞清两个基础规则，否则你会算错所有账

官方在表格之前只给四条规则，但正是这四条决定了你怎么读后面的数字。

2.1 限流是按”主账号”算的，不是按 API Key 算的

账号级别限流：限流按主账号维度计算，账号下所有 RAM 子账号、业务空间和 API Key 的调用量合并计算。

这条经常被忽略。官方同页给的”如何查看模型调用量”里说：模型调用发生后分钟级即可在监控图表查看。所以在多人协作的团队里，一个同事的脚本跑飞，会把全公司主账号的配额吃掉。你在控制台看到的调用量是主账号合计，429 也是主账号合并触发的。

2.2 不同模型的配额互相独立

模型独立限流：不同模型限流额度相互独立，具体参见下方表格。

这是好消息也是坏消息：好消息是你不会因为刷文本模型而撞到图像模型的限流；坏消息是你也不能指望把一个模型的配额”匀”给另一个模型用。所谓”多模型混合负载均衡”只能缓解限流，绕不过去。

2.3 真正的不只是 RPM 和 TPM，还有 RPS 和 TPS

除 RPM 和 TPM 外，限流策略可能按秒级 RPS（RPM/60）与 TPS（TPM/60）执行。即使每分钟总调用量未超限，短时间内的请求爆发也可能触发限流。

这个细节在图像和视频模型上是决定性的。后面会看到，万相 wan2.6-t2i 在北京的 RPS 只有 1，也就是每秒只能发一次，哪怕你一分钟能发 5 次。

2.4 429 和 403 是两回事，别搞混

限流（RPM/TPM）仅导致超出限制的请求被拒绝（返回 429 错误）。免费额度耗尽时（开通免费额度用完即停）返回 403 错误，同样不影响已接受请求的速度。429 为速率限制，403 为配额耗尽，两者均为拒绝机制。

官方同时明确：限流不会降低已接受请求的生成速度。如果你发现”充值之后变慢了”，那不是限流导致的，是别的原因。

三、错误信息就是限流类型的诊断书

官方给了三类报错的判定方法，这套映射建议直接抄进你的告警规则：

第三类是最容易误判的一种。它不代表你的配额用完了，只代表你发得太急。官方给的解法是匀速调度、指数退避或请求队列。这也是为什么很多团队”明明监控面板上用量还很空，却一直报 429″——问题出在秒级突发，不在分钟总量。

四、最大的一条缝：稳定版和快照版差 500 倍

这是本文最值得你立刻拿去用的发现。

在华北2（北京）地域的千问语言模型表里，同一个模型家族的不同版本，RPM 差距极其悬殊：

两条可以直接当结论用的规律：

第一，带日期的快照版一律远低于同族稳定版。 qwen-plus 稳定版 30,000 RPM，而它最老的那个快照 qwen-plus-2025-01-25 只有 60 RPM——整整 500 倍。很多人为了”可复现”而锁定一个具体日期的模型版本，这个决定会让你的并发能力下降两个数量级。官方的建议原话是：“稳定版或最新版比带日期的快照版本限流更宽松。”

第二，qwen3.7-flash-2026-07-15 是个例外中的例外。 它虽然是快照版，RPM 却是 30,000，和稳定版完全一致。这说明快照版并不必然低配额——个别快照会被单独提额。所以别机械套规则，把你要用的那个确切版本号查一遍。

需要特别注意的是：几乎所有稳定版的备注里都写了 “用 Batch API 调用服务时，不受限流限制”，而大部分快照版没有这句。批量推理这条路对稳定版是完全敞开的。

五、第二个缝：同一个模型，换地域差 50 倍

美国（弗吉尼亚）地域的表，和全球口径对比之后出现了更极端的情况：

最后一行值得专门点出来：qwen-flash 在美国地域的 RPM 比全球口径高一倍。也就是说，美国不是所有模型都吃亏，个别模型反而更宽裕。

这一列数据在官方表里是以”服务部署范围”字段来区分的——同一个模型名会同时出现”全球”和”美国”两行。如果你只盯着第一行看，就会按错误的口径做容量规划。选地域不是选机房，是选配额。

顺带一提，qwen3.8-max-0902 是个特例：全球 30,000 RPM 但 TPM 只有 150,000，而 qwen3.8-max 是 30,000 / 5,000,000。同为 3.8 max，TPM 差 33 倍。高并发下这个差异会直接体现为吞吐塌方。

六、动态限流：14 个模型不公开具体数字

官方在这张页面上明确标注：

部分模型，如 qwen3.8-max、qwen3.8-flash 采用动态限流（新）的方式，根据百炼月消费档位进行软限流。

在 162 张表里，”动态限流”一共出现 16 次，涉及 8 个模型：

• 千问文本：qwen3.8-max、qwen3.8-max-0902、qwen3.8-flash
• 千问 Omni：qwen3.8-omni-flash
• 千问开源版：qwen3.8-2.4t-a95b、qwen3.8-27b
• DeepSeek：deepseek-v4-pro-0813（北京、新加坡）
• Kimi：kimi-k3（北京、新加坡）

“根据月消费档位进行软限流”是这句话的关键。它意味着这些模型的限额不是一个公开常数，而是一个与你的消费额绑定、会浮动的值。这也顺带回答了第一节那个问题——虽然充值本身不直接提升限流，但如果你所在的消费档位足够高，动态限流模型的实际可用额度确实可能更高。

不过官方没有公开任何换算公式或档位阈值，这部分属于 UNKNOWN，本文不做推测。要拿准确数字，只能在自己的控制台看监控页实测。

七、第三方直供通道：同款模型，限流能差 500 倍

这是第三层被忽略的差异。百炼同时提供 DeepSeek、Kimi、GLM、MiniMax 等第三方模型，其中部分带”直供”通道——它们的限流和原生通道完全是两套数字：

deepseek-v4-pro 原生 15,000 RPM，走万擎直供只剩 60 RPM，掉到 1/250。而反过来，MiniMax M2.5 走稀宇直供，TPM 从 1,000,000 涨到 20,000,000，涨了 20 倍。

所以”选通道”这件事，在百炼上是一个和”选模型”同等量级的决策。

八、共享配额：有些配额不是你以为的那个模型的

还有一类更隐蔽的规则，官方在表格单元格里直接用长句写明了：

• Kimi-月之暗面直供：同一个阿里云百炼 API Key 下，kimi/kimi-k3、kimi-k2.7-code-highspeed、kimi-k2.7-code、kimi-k2.6、kimi-k2.5 这 5 个模型共享 500 RPM 和 3,000,000 TPM。即这 5 个模型的每分钟请求总数加起来不能超过 500。
• 可灵系列：kling/kling-v3-omni-image-generation 等 5 个图像及视频模型共享 10 个并发数。
• Vidu 系列：参考生图系列 6 个模型共享 5 个并发数。

这意味着这些模型的实际可用并发，取决于你同时调了其中几个。用三个 Vidu 模型不等于三份额度，而是共用一份。压测时务必按”整组”而不是”单模型”来算。

九、图像和视频：限流单位根本不是 RPM

翻到文档下半部分的图像与视频章节，你会发现限流单位变了：

qwen-image-2.0-pro 只有每分钟 2 次。2.0 的基础版反而放宽到 2 次/秒，而 pro 版被压回 2 次/分钟——这是本文全站最反直觉的一处。而且注意区分”次/分钟”和”次/秒”，两者差 60 倍。

视频侧的规律类似：万相 wan2.6-t2i 在北京 RPS=1、德国 RPS=1，而美国和新加坡都是 RPS=5——同一个模型换个地域差 5 倍。wan2.7-image 在北京和新加坡都是 5。

十、可以照抄的五条实操建议

官方 FAQ 自己给的建议加上本文的实测对照，可以整理成一份可直接落地的清单：

1. 优先用稳定版，不要为了可复现锁快照版。 qwen-plus 稳定版 30,000 RPM vs 最老快照 60 RPM，差 500 倍。确实需要固定版本时，先查那一行确切的数值——因为 qwen3.7-flash-2026-07-15 就没有这个问题。
2. 把 Request rate increased too quickly 单独做告警。 它代表突发而非配额耗尽，需要的是匀速队列或指数退避，加并发是没用的。
3. 429 和 403 分开处理。 429 是速率问题（退避重试），403 是配额问题（需要调整额度或开关），混在一起重试只会放大故障。
4. 批量任务走 Batch API。 稳定版备注里明确”用 Batch API 调用服务时，不受限流限制”，这是最干净的绕开路径。
5. 跨地域前先查”服务部署范围”那一列。 同一个模型名在表里可能同时有”全球”和”美国”两行，容量规划要用对口径；并且要意识到充值不提升限流，只能换模型或找商务。
6. 第三方直供按”共享配额”设计容量。 Kimi 直供 5 个模型共用 500 RPM，可灵 5 个模型共用 10 并发。压测时按整组算。
7. 监控数据不作为计费依据。 官方原话：”监控数据按分钟级更新，仅供参考，不作为计费依据。” 排查用监控，对账用账单。

十一、口径与未知项声明

为避免把推断当事实，本文明确以下几点：

• 数据来源：仅阿里云官方《限流》文档页，抓取时间 2026-10-15 12:0x（Asia/Shanghai），页面自身标注更新时间 2026-10-12 16:45:36。本文解析了该页全部 162 张表格。
• 未验证项：本文所有数字均为官方表格原文转录，未在控制台实际发起调用做实测验证。真实运行中的动态限流模型（8 个）会随消费档位浮动，静态表值不代表实际可得额度。
• UNKNOWN：动态限流的换算公式与月消费档位阈值，官方未公开；文中未做任何推测。
• 抓取环境说明：同一次抓取中，官方文档站对不存在的路径（如 /zh/model-studio/limits）返回 HTTP 200 + 24,899B 且