先说清楚性质：这个页面上的所有数字，都是把你填进去的参数做了一遍算术， 没有连接任何服务商、没有内置任何厂商的额度或价格。它给的是量级判断和初始配置的参考值， 实际能跑多少，一切以你自己的监控数据与账单为准。

为什么并发数不能拍脑袋定

接大模型 API 的时候，很多人配置并发的方式是「先开 10 个试试，报错了就调小」。 这么干短期能跑，问题是你永远不知道自己离限流红线还有多远， 也不知道一旦流量涨上去，第一个撑不住的到底是哪个环节。 更麻烦的是，限流报错往往伴随重试，而重试又会把请求量进一步放大， 于是一次小小的流量抖动就可能滚成雪崩。

要把这件事算明白，得先接受一个事实：约束你的从来不是一个数，而是两个数。 一个是每分钟能发多少次请求，另一个是每分钟能过多少 token。 这两条线各自独立，谁先撞上，谁就是你的真实上限。 很多人只盯着请求数那条线，结果实际卡住的是 token 吞吐那条， 于是出现了「明明请求数远没到额度，却一直被限流」的困惑。

这个工具具体算什么

输入六个参数：你的 RPM 额度、TPM 额度、单请求平均 token 数（输入加输出）、 单请求平均耗时、想预留的余量百分比，以及你的业务峰值请求数。工具会依次算出四件事。

第一，两条线各自允许多少请求。按请求数那条线算，答案就是你填的 RPM； 按 token 那条线算，是 TPM 除以单请求平均 token，向下取整。两者取小，就是你的实际可用速率。 工具会直接告诉你哪一条先到顶，这个判定是后面所有优化动作的方向盘—— 如果是 token 那条先到顶，减少输入体积立刻见效；如果是请求数那条先到顶，压缩 token 完全没用。

第二，稳态并发数。用实际可用速率除以 60 得到每秒请求数， 再乘以单请求平均耗时，就是同一时刻平均在途的请求条数。这个数才是并发池该有的规模。 第三，按余量折算后的建议值。耗时是有分布的，平均值背后藏着长尾， 所以工具会按你填的余量百分比往下折一档再取整，作为建议配置。 第四，峰值对照。拿你填的业务峰值跟实际可用速率比，够用就是够用， 不够则直接给出每分钟差多少次请求的缺口数字。

结果怎么读，以及它的边界在哪

读结果的时候，最该先看的是瓶颈判定那一行，其次才是建议并发数。 瓶颈告诉你该往哪个方向使劲，并发数只是个起点值。 然后建议你把单请求平均耗时上下拨动一下，观察建议并发的变化幅度—— 如果轻微改动耗时就让并发数跳很大，说明你的方案对延迟波动很敏感，余量得给得更厚。

局限也必须说明白。这个模型假设请求是均匀到达的，而真实流量往往是一阵一阵的； 它用平均耗时代表整个分布，而实际的长尾请求可能是平均值的好几倍； 它不知道服务端的限流窗口具体怎么切分，固定窗口和滑动窗口在边界处的表现差别很大； 它也没有把你的重试放大效应算进去。所以这些数字适合用来定初始值、判断量级、 发现「方向选错了」这类结构性问题，不适合拿来当容量承诺。

延伸阅读

想把并发控制、限流应对的工程做法看完整，可以读 并发控制与速率限制实战； 限流之后的退避重试怎么写才不会把自己打垮，见 重试与指数退避怎么写， 这两件事必须配套做，只调并发不改重试，往往会在高峰期原地放大问题。