上周帮一个做合同的团队看故障。他们的 API 预算只花掉三成，但每天下午三点左右，有一半请求开始返回 429，日志里刷满"指数退避重试中"。运维第一反应是加钱，把账户从低档升上去，第二天照样三点准时犯病。
后来发现跟钱关系不大。白天跑交互式问答，晚上跑批量抽取，两拨流量共用一个账号的每分钟 token 额度。下午是业务高峰，问答先把额度吃满，长文档批处理排到后面，一批塞进去就顶到天花板。钱还在账上躺着，管道先堵了。
翻完各家文档我才意识到，成本一直是两本账：一本记"花了多少"，一本记"能跑多快"。大多数人只盯第一本。
一、限流管的是功率，账单管的是电量
家里的电表上有两个数，一个是同时开几台空调，一个是这个月用了多少度。交得起电费，不代表线路受得住。
API 这边一样。账单看月度总量，限流看单位时间的吞吐------你完全可以预算还剩九成，同时被 429 拦在门外。
刻度还不止一个：RPM 是每分钟请求数，ITPM、OTPM 是输入输出 token，还有按天算的 TPD、RPD，以及并发数，撞任何一个都报错。阿里云百炼的文档写得很直白，除了 RPM 和 TPM，还会按每秒的 RPS、TPS 执行。Anthropic 用令牌桶，容量连续补充，文档专门提了一句，60 RPM 可能被落成每秒 1 个请求。
所以"分钟均值很漂亮"不是护身符。五个子 agent 同时起来，摊到一分钟毫无问题，那一秒就是五倍。多 agent 架构撞限流，基本都这么撞的。
统计范围也各不一样。Anthropic 按组织级算，工作空间只能往下压；Google 按 project 算，同一个 project 下开两把 key 共享一个预算，多开一分不多；DeepSeek 刚开放的搜索接口每账号 5 QPS，文档写清楚加 key 也不涨。
顺带一个信号：OpenAI 10 月 6 日把付费档从五个并成三个（Build、Launch、Grow），累计充值 5、100、500 美元对应，示例限流从 5000 RPM 加 100 万 TPM 一路到 1.5 万加 4000 万。价格没动，动的是"容量"这套说法。
二、同一个 429，至少三种意思
429 不是一个错误，是一类错误。
第一种是速率，响应头带 retry-after，按它说的秒数等，早于它重试一定失败。第二种是月度封顶，Anthropic 的 spend cap 也返回 429，但没有 retry-after，错误详情是 enforced_spend_limit_reached，等几秒毫无意义，要么升档，要么等下个月 1 号零点 UTC。第三种是额度耗尽，阿里云给 403 而不是 429，DeepSeek 是 402。OpenAI 那边配额错误和限流共用一个状态码，得看 error.code 才分得清。
把所有 429 塞进同一个指数退避分支，就变成对着一堵墙反复撞。
更要命的是失败请求本身也占配额。OpenAI 文档明确写了不成功的请求同样计入每分钟限额，火山引擎的突发流量实践里也有一句"避免失败请求占据限流配额"。紧循环重试不是"多试几次"，是在烧你正等着恢复的那点额度。
状态码还在漂移：OpenAI 把流量涨太快的信号从 503 改成 429 slow_down，视频过载反而从 429 改成 503。按状态码写死重试逻辑的代码，迟早重写。
时间尺度也不一样。限流通常一分钟内自动恢复，账单封顶要等到下个月。一个秒级问题，一个月级问题，用一套逻辑处理注定一半是错的。这也是我建议把调用尽量收在同一个入口的原因------各家的剩余额度、重置时间、429 原因能在一张表上对齐，不用翻六个控制台才搞清谁把额度吃完了。EasyAPI这类聚合入口在这件事上的价值，比单价那点差别更实在。
三、缓存那一栏，还有个副作用
缓存我们写过好几次，都是算钱。这次说个别的。
多数 Claude 模型下，只有未命中缓存的输入 token 和缓存写入 token 计入 ITPM，缓存读取不计入。官方算例：200 万 ITPM 的额度，命中率 80%，一分钟能处理约 1000 万输入 token。等于额度凭空翻了五倍。
所以缓存的第一价值可能不是省钱，是扩容。省的是账单，扩的是管道。一个长期跑着的 agent，前缀稳定、工具定义固定，命中率高的时候等于免费多了一条车道。
反过来就难受。改 system prompt 前缀、发版、换工具描述，缓存全冷，每个请求都在写缓存，而缓存写入是计入限流的------同一件事你付两次钱，也多占两次配额。官方的建议是 prompt 变更分批灰度，别一次全推。
还有两条容易误解的：思考 token 算输出，推理重的负载会先撞 OTPM；max_tokens 设多大不影响 OTPM，因为只算真正生成的。很多人以为调小 max_tokens 能换更多并发，其实没用。
最后
结论不复杂，难在执行。
把 429 当分类问题而不是重试问题，先读 code、看有没有 retry-after，再决定是等、是切、还是停。把"功率"接进监控，响应头的 remaining 和 reset 是免费的预报，提前减速比事后重试便宜；
给子 agent 的并行度设上限；非实时任务丢进 Batch，它有独立配额，还便宜一半。最后把额度当资源分配，别让白天的问答和夜里的批处理抢同一碗饭，备用通道写在配置里，主通道被打回时切过去只改一个 model 名。这也是"入口做薄"真正的意思------EasyAPI****这类东西省下的不是钱，是换的时候不用动业务代码。
限流以前不太被当回事，因为额度宽、流量小，撞不上。现在上游容量本身就紧，这头的 429 只会更常见。
账单是月底才来的，429 是当下就来的。先管好当下这本，可能更划算。