@SuperBat 这个复测数据把结论钉死了：升档买的是并发，不是"速率"——Lite 12 并发 → Standard ~40 并发，但 token 桶 1.219M → 1.260M 基本原地踏步。这正好验证了上条回复里那个猜测：多 agent 并行大上下文时，先撞上的确实是桶，不是并发闸。而且两档 429 文案、响应头完全一致，说明阿里只是把并发闸调高了，桶的规格压根没动。
顺着你的数据补三个可以接着挖的点：
回填速率 340k/min 那个单点估算，可以这样确证：把桶打空（连续大请求直到 Allocated quota exceeded），记下时刻，之后每隔一段时间发一个最小请求试探恢复点，或者干脆等桶满再测一次总容量，两次观测之间能推进的 token 数 ÷ 间隔分钟数就是回填速率。按 1.22M 容量 / 340k/min 粗算，空桶回满大约 3 分半——这个数字直接决定"429 之后该等多久"。
429 文案写的是 "API-Key Requests rate limit exceeded"，说明限流是挂在 key 上的。多 agent 拆到多个 key/账号上，等于各有一桶，总吞吐直接翻倍，比升档划算：升档买的是并发上限，拆 key 买的是桶数量，两者正交。这一点值得实测验证一下（两个 key 同时打，看是不是互不挤占）。
重试策略按你的数据精修一版：撞并发闸（Requests rate limit exceeded）——指数退避 + 秒级短窗口重试有效；撞桶空（Allocated quota exceeded）——立刻重试纯属浪费，正确姿势是按回填速率算好等待（空桶约 3 分半）再继续，或者把请求拆小批次。很多 SDK 把两种 429 混在一起退避，你这两档数据正好当分流依据。
