大模型 API 的并发怎么规划？从峰值流量倒推容量
并发数不是性能旋钮，是和服务端额度匹配的配置项。设得比额度大，多出来的部分不会更快，只会变成 429 和重试；设得太小，额度买了用不上。
这篇讲怎么算出一个合适的数。限流的两把尺子见 RPM 和 TPM 是什么。
并发和速率是两回事
速率是单位时间发出多少（每分钟多少次、多少 token）。并发是同一时刻有多少请求正在飞。
两者通过耗时联系起来：速率 ≈ 并发数 ÷ 单请求耗时。
一个直观的例子：单请求平均 3 秒，并发 3，那么稳态速率大约是每分钟 60 次。要达到每分钟 120 次，要么并发翻倍到 6，要么把耗时压到 1.5 秒。
搞混这两个概念的典型后果，是把并发数直接设成 RPM 的数值——那会在开头几秒把整分钟的额度打光，然后剩下的时间全在吃 429。
从峰值倒推容量
规划顺序应该是：业务峰值 → 所需速率 → 所需并发 → 所需额度档位。
第一步，估业务峰值。 注意是分钟级峰值，不是小时平均。流量集中的业务，峰值可能是日均的好几倍。没有线上数据时，按场景推断：面向消费者的产品通常晚间高峰，面向企业的通常工作日上午。
第二步，换算成所需速率。 峰值请求数除以时间窗口。如果一次用户操作触发多次模型调用（意图识别、检索改写、生成、安全检查），要按实际调用次数算，不是用户操作数——这是最常见的低估来源。
第三步，换算成并发。 用上面的公式，乘上单请求平均耗时。长输出场景耗时长，同样的速率需要更高的并发。
第四步，对照额度。 把算出的速率和额度比，同时检查 RPM 和 TPM 两条线。哪条先到顶，哪条就是你的真实瓶颈。
第五步，留余量。 耗时是波动的，建议在算出的并发上留两三成。
并发调大反而变慢的三种情况
一、超过服务端额度。 多出来的请求直接被拒，重试排队，端到端延迟反而上升。这是最常见的一种。
二、客户端资源打满。 连接池不够、事件循环阻塞、内存吃紧。这时候瓶颈在你自己这边，加并发只会加剧。
三、下游依赖被拖垮。 每次模型调用前后往往还有检索、数据库、日志写入。模型这一环加速了，下游先崩。
所以调并发之前先确认瓶颈在哪：如果 429 比例很低而延迟很高，瓶颈多半在客户端或下游，不在额度上。
队列该怎么设计
超出并发上限的请求要排队，队列的设计决定了体验好坏。
一、设队列长度上限。 无限队列会在流量洪峰时无限堆积，最后所有人都超时，还占着内存。到上限就快速拒绝，把压力反馈给上游。
二、设排队超时。 一个请求在队列里等了很久才被处理，用户早就走了。发出前检查是否已超时，超了就丢弃——省下的是实打实的钱。
三、分优先级。 用户正在等待的交互请求优先，后台批量任务让路。所有请求一视同仁的结果是最重要的那些也被拖慢。
四、把离线任务彻底分开。 独立的密钥、独立的队列、走批处理接口。一个跑飞的离线脚本吃光线上额度，是很常见也很容易避免的事故。
三个必备的监控指标
在飞请求数：实时并发。看它是不是长期贴着上限跑，贴着说明容量不足。
队列等待时间：这部分延迟用户能感知，但在模型侧的耗时统计里看不到，容易被忽略。
429 比例：超过阈值就该降并发或提额了。它和队列等待时间一起看：429 高说明发太快，队列等待高说明发太慢——两者不会同时高，看哪个高就往哪个方向调。
一次压测该怎么做
上线前的压测，目的不是「跑出一个最大值」，而是找到在可接受的延迟和错误率下的稳定容量。
第一步，定义可接受标准。 比如：错误率低于某个阈值、P95 延迟不超过某个值。没有标准的压测跑出来的数字没有意义。
第二步，阶梯加压。 从低并发开始，每档跑足够长时间（至少几分钟，让系统进入稳态），记录三个数：吞吐量、P95 延迟、错误率。然后逐档提高。
第三步，找到拐点。 通常会看到这样的曲线：并发上升时吞吐量线性增长，到某个点之后吞吐量不再增长而延迟开始飙升，错误率同时上升。那个点就是你的稳定容量，实际配置建议取它的七八成。
第四步，区分瓶颈在哪。 拐点处如果 429 比例高，瓶颈是服务端额度；如果 429 低但延迟高，瓶颈在客户端资源或下游依赖。两者的解法完全不同。
注意：用免费额度或试用档压测，得到的数字不代表付费档的真实容量，因为速率限制不同。这是很常见的误判来源，见免费额度怎么查、怎么比。
压测之外，日常还要看什么
压测给的是静态容量，线上是动态的。日常需要盯三条曲线：
在飞请求数随时间的变化：能直观看出流量的峰谷形态，也能看出是不是长期贴着上限跑。
队列等待时间：这部分延迟用户能感知，但在模型侧的耗时统计里看不到，很容易被漏掉。
429 比例与重试成功率：前者说明发太快，后者说明退避策略是否有效。
三条曲线一起看，就能判断当前的并发配置是保守了还是激进了，而不是等用户投诉才知道。
容量和成本要一起看
并发规划的目标不只是「不被限流」，还有「不为用不上的额度付钱」。
高档额度通常伴随更高的门槛或费用。如果你的峰值只在每天两个小时出现，为峰值买全天的高档额度是浪费——更好的做法是把可延迟的任务错峰，把峰值削平，用低一档的额度就够了。
削峰的常见手段：批量任务挪到低谷、非实时功能异步化、给用户端加一层轻量的本地缓存避免重复请求。削峰之后再回头算月成本估算器，往往能省下不止一档的钱。
三个高频问题
问：并发设成多少才合适？ 用 RPM ÷ 60 × 单请求耗时算出稳态值，再留两三成余量。没有普适数字，因为它取决于你的请求大小和耗时。
问：延迟高是不是该调大并发？ 先看 429 比例。429 低说明瓶颈不在额度，调大并发只会更糟，该查客户端资源或下游依赖。
问：怎么防止离线任务影响线上？ 独立密钥、独立队列、走批处理接口。这是最有效也最简单的隔离。