百炼接入 Qwen 后，单条提问能成功，一次提交多条任务却出现 429。本文面向首次做批量摘要或 Agent 调用的同学，用一个六条笔记队列，区分请求频率、Token 用量和瞬时突发，再给出可执行的降速方法。依据 2026-10-12 官方资料整理，未对读者账号压测，不承诺固定并发数适用于所有模型。
1. 先抄下错误码，不急着换密钥
主环境是阿里云百炼按量模型接口，客户端使用 OpenAI 兼容格式。Coding Plan、图像任务和记忆库各有自己的规则，不套用本文参数。API Key 是请求身份凭证；429 则需要结合响应里的错误代码和消息判断具体限制，不能只看 HTTP 状态就认定余额不足。
先暂停自动循环，在日志中保留目标模型、地域、请求时间和脱敏错误信息。不要打印 Authorization 或完整文章内容。特别要区分 Throttling.RateQuota、Throttling.AllocationQuota 与 Throttling.BurstRate；服务过载或资源耗尽的代码，也不能机械归入某个固定配额。
百炼限流说明按主账号聚合相关业务空间和密钥的调用。仅创建另一把 Key，不能据此推断得到了新的调用额度。先确认同账号是否还有定时任务、其他同学的客户端或 Agent 运行，否则你看到的本机每分钟六次，未必代表账号整体只有六次。
2. 把限制翻译成具体调节动作
RPM 是每分钟请求数，TPM 是每分钟 Token 用量。Token 是模型处理文本的计量单位，不等于字符数；同样长度的文本在不同语言和模型中可能不同。频率受限时减少发送次数，Token 受限时还要压缩输入和限制输出，单独降低并发并不一定足够。
| RateQuota / 请求频率超限 | 排队、增加发送间隔 | 相同短输入串行执行 |
| AllocationQuota / Token 速率超限 | 缩短单条笔记，降低输出上限 | 用量统计与成功响应 usage |
| BurstRate / 请求增长过快 | 均匀启动任务，取消瞬间全发 | 对照每次发出时间 |
| ServiceOverloaded 等 | 等待并保留失败任务 | 观察后续小样本恢复情况 |
到控制台“运维管理 → 模型监控”查看相应模型、业务空间和时间范围。监控图表有更新延迟，所以不能用刚刷新的空图断言没有调用。官网额度表会随模型和服务策略变化，应查自己实际使用的模型；本文不提供一个看似通用的“并发开到十”的答案。
3. 先用串行小队列恢复一次任务
准备六条不含敏感内容的学习笔记，每条只要求输出一行摘要。先串行调用，关闭 SDK 内置重试，再由代码控制最多两次额外尝试，避免外层与内层重试叠加。下面是独立的教学队列，环境变量中填写你现有账号的 Key、控制台对应 Base URL 和可用模型名称。
import os
import time
import random
from openai import OpenAI, APIStatusError
client = OpenAI(
api_key=os.environ["DASHSCOPE_API_KEY"],
base_url=os.environ["BAILIAN_BASE_URL"],
max_retries=0,
timeout=60,
)
notes = [f"学习笔记{i}：今天理解了一个新的接口字段。" for i in range(1, 7)]
for number, note in enumerate(notes, 1):
for attempt in range(3):
try:
response = client.chat.completions.create(
model=os.environ["BAILIAN_MODEL"],
messages=[{"role": "user", "content": "用一行概括：" + note}],
max_tokens=128,
)
print(number, response.choices[0].message.content)
break
except APIStatusError as error:
if error.status_code != 429:
raise
if attempt == 2:
print(number, "暂停此项，稍后人工处理")
break
time.sleep(5 * (2 ** attempt) + random.uniform(0, 1))
time.sleep(3)
在装有 openai 包的 Python 虚拟环境运行。这里的三秒间隔、五秒退避和六条笔记是教学起点，不是供应商承诺的恢复时间，也不能保证某个账号立即成功。如果仍连续报错，停止该小批次，依据错误码重新调整，而不是无限等待直到产生一次成功。
4. 为什么减少并发后仍可能失败
串行任务也可能频率过高：如果一次请求很快结束，紧接着立即发下一条，每分钟仍会很多次。另一方面，一次任务携带长历史、整本文件或大量工具说明，即使请求数很低，也可能消耗较多 Token。对输入长度和发送节奏分别做实验，才知道是哪一个维度影响结果。
Agent 的“一次用户提问”可能展开成多次模型请求。记录计划中的业务任务编号，同时统计真实模型调用次数；不要用前台点击次数估算 RPM。某个工具失败触发重新规划时，还会继续产生请求。先固定一个无需外部工具的笔记摘要流程，走通后再恢复多步任务。
换备用模型是一种产品策略，但可能改变质量、上下文能力和成本。若要采用，须预先准备相同的摘要验收样本，不应在捕获所有异常后静默换成另一个模型。身份错误、输入错误和服务限流分别记录，让用户知道到底是哪一项没完成。
5. 恢复吞吐量时逐步增加任务
拿到一次真实成功响应后，不要直接从六条跳到几千条。先保存每条完成状态、发送时间和结果，再增加小批量。只有失败项进入下一次队列，成功项不重复调用。本文样例只在内存里展示逻辑，正式任务需要持久化这些状态，避免程序重启后丢失进度。
对带副作用的 Agent 工具尤其要谨慎。模型超时并不证明工具没有执行，下单、通知或写库不能跟着整段工作流随意重放。这里讨论的重试仅针对无副作用的模型摘要请求；加入外部操作时，应建立操作编号、结果查询和去重机制。
成功判据是这组六条任务各有可识别的结果，重复尝试次数可控，停止后没有后台继续发送的循环。保留实际错误消息、模型名、脱敏调用时间和监控区间，才能进一步申请额度或请供应商定位。充值解决计费条件，不自动等同于提高所有速率限制，最终以当前账号规则为准。
增加任务前做一次节奏审计：把每条发送时间写成相对秒数，例如第零秒、第八秒、第十六秒。若日志出现多个任务在同一秒开始，说明仍有某层批量启动或自动重试没有关闭。只看最后成功条数会漏掉这个问题。对长输入则记录每次成功请求的实际用量，不用中文字符长度直接代替 Token。若某条摘要要求输出很长，单独限制它的输出预算，并确认摘要仍保留业务需要的信息。降速期间界面应显示排队和暂停状态，让使用者知道任务尚未完成，避免不停点击提交制造新的请求。
参考资料
- 模型限流：账号维度、RPM、TPM 与平滑策略，阿里云百炼，访问日期 2026-10-12。
- 错误码：区分不同 429 原因，阿里云百炼，访问日期 2026-10-12。
