详细解释
并发请求数（Concurrent Requests，也叫在飞请求数 / In-Flight Requests） 指在任意一个瞬间，你的账号已经发出去、但还没收到响应的请求总数。与 RPM（按”发起次数”计数）不同，并发按”占用时长”计数——请求执行时间越长，占用并发数越久。
一些厂商（最典型是 DeepSeek）不用 RPM/TPM 作为主限制轴，直接用”最大并发数”做闸门：比如 DeepSeek V4 Flash 给到 2,500 并发，非常适合短时间内爆发式并发的 Agent 场景。
两种限流模型的对比
| 限流维度 | 统计口径 | 谁先中招 |
|---|---|---|
| RPM | 一分钟内发起次数 | 请求很小但数量极多（聊天 QPS 高） |
| 并发数 | 同一瞬间在飞请求数 | 请求很慢、返回时间长（RAG 超长上下文、大图片） |
举个直观例子：你 1 秒发 100 个请求、每个请求执行 10 秒返回：
- 并发数 = 1,000（每一秒同时在飞的请求数）；
- RPM = 100 × 60 = 6,000。
如果并发上限是 500，你这一秒的第 501 个请求会立刻 429，即使远没到 RPM 上限。
唯元智创（Weimeta）提供 “请求在飞看板”，实时展示当前并发占用，超出时主动帮你做客户端排队，减少无效请求。
常见问题
如何估算业务需要多少并发？
经验公式：并发 ≈ QPS × 平均响应时间(秒)。如果业务 QPS=50、每次请求平均 3 秒 → 需要 150 并发。建议留 2–3 倍冗余应对高峰。