阿里云百炼coding plan lite 限流

用百炼编程套餐 Lite 写代码，最烦的不是写不出来，而是写着写着突然开始报错、响应变慢或者直接拒答，回头又不知道是哪条限制被撞上了。这篇不重复讲协议和客户端配置，只讲工程侧怎么定位：先分清是并发、频率还是额度口径的问题，再按顺序降速、排队、退避，最后落到一个能长期跑的调用节奏上。

用百炼编程套餐 Lite 写代码，最烦的不是写不出来，而是写着写着突然开始报错、响应变慢，甚至直接拒答，回头又不知道是哪条限制被撞上了。多数人的第一反应是「是不是额度用完了」，但限流和额度耗尽其实是两回事，混着看会白白折腾半天。

这篇不重复讲协议和客户端配置，只讲工程侧怎么定位：先分清你撞的是并发、频率还是额度口径的问题，再按顺序降速、排队、退避，最后落到一个能长期跑的调用节奏上。判断标准给清楚，不适用的情况也一并标出来。

先分清你撞的是哪种限制

限流不是一个单一现象。你以为的「服务挂了」，很可能只是某一类请求被拦。动手改参数之前，先给现象归个类，归一类的过程本身就是一次排查。

• 对照错误返回里的限流字段，多数平台会给出剩余额度或建议的重试等待时间，这个字段比报错文案可信
• 确认限制是账号级还是单 key、单项目级，多人共用一个 key 时很容易互相挤占，几个人同时开 IDE 并发是叠加的
• 不适用的情况：如果只有某一个模型报错、换个模型就正常，那更像模型侧容量问题，不是你的调用方式问题，改并发没用

Lite 档常见的几个触发点

Lite 这类入门档位的定位本来就是轻量使用，它的限制设计得比较紧是正常的。问题通常不在「限制太小」，而在于你的调用方式和这个档位不匹配。

高频小请求

编辑器插件补全一次可能触发好几条调用，单看每条都不大，加起来并发很吓人

长上下文

长对话比短问答烧得快得多，同一份额度下更容易先撞上限

周期尾段

额度按周期重置，尾段剩余不多时体感会明显变紧，不是服务变差了

共享账号

团队里多人同时开着 IDE，实际并发远高于你单人预估

套餐口径和额度规则会调整，别按印象里的数字排调用量。到 /coding-plans/aliyun-bailian-coding-plan-pro 核对当前档位的额度口径。不适用的情况：如果日志里能看到网络层超时或连接重置，优先按网络问题排查，不要一上来就改并发参数。

一套能照着走的排查顺序

排查限流最忌一次改好几个变量，最后不知道是哪个起了作用。下面这套顺序的核心是每步只动一个变量，并且每步都要有可验证的结果。

1. 固定变量只留一个客户端、一个 key、一个模型，把并发降到最低跑几条请求。还报错说明不是并发问题；正常了就是并发或频率问题。
2. 看时间分布把报错时间点和你的批量任务时间对齐，确认是不是集中在某个脚本、某个插件或某个时段。
3. 量基线先到 /tools/speed-test 测出正常情况下的延迟，报错时段再测一次，能区分是限流还是链路本身慢。
4. 分层放量按 1、2、4 这样逐级往上加并发，找到第一次开始出现失败的那一档，把它当作工作上限。
5. 留余量把工作并发定在实测上限之下，给编辑器插件和临时对话留出空间，别把上限当日常值用。

工程上怎么改，能不靠人工盯着

靠人盯着报错再手动降速，只适合一次性脚本。要长期跑，得让程序自己在被限流时退一步，而不是把错误抛给用户。

• 给请求加指数退避加重试上限，退避基数和最大重试次数写在配置里，别硬编码在业务代码里
• 把批量任务改成任务队列串行消费，加一个令牌桶控制发出速率，比一次并发十几条稳得多
• 做降级预案：主模型被限流时切到备选模型或走自建通道，切换条件写清楚，比如连续失败多少次才切
• 每次请求的耗时、状态码、是否重试、消耗量都记进日志，复盘限流才有依据
• 长会话主动裁剪上下文，必要时用摘要压缩，减少单次请求的 token 量

不适用的情况：如果只是临时跑一次性脚本，花时间搭队列不划算，直接串行加 sleep 就够。搭不搭队列要看这个任务会不会长期反复跑，而不是看它现在多烦人。

把额度、价格和限制口径对齐

限流往往不是孤立的，它背后是「你的用量已经接近这个档位的天花板」。所以除了改代码，还要定期核对套餐额度和计费口径，判断是继续凑合还是换档。

把限流事件当信号记录：一个月触发几次、集中在哪个时段、是不是每次都同一个任务。如果只是偶发一次且当时在压测，不必为它改架构，记录一下就行。反之如果每周都撞，那问题不在参数，在档位或者调用架构。

限流不是故障，它是套餐在告诉你当前的调用方式和这个档位不匹配。