十月二十日晚上八点，一家做合同审阅的小团队，客户一口气传上来两百份二十页的合同。客户催得紧，第二天上午九点就要用。后台开始跑，那位工程师盯着进度条，五份并排，剩下的全在转圈。
他嫌慢，把同时压上去的活从五份改成五十份，重试也留在默认值上，失败就立刻重发。半小时后，后台只交出二十份结果，其余一百八十份全标着“请求超时”。那批活退回人工，两个人从头看到尾。
同时压上去的活翻了十倍，为什么交出来的反而更少？
为什么会这样
一句话：那个“同时压上去的活”，行内叫并发。它管的不是一秒能跑几个，是同一时刻最多有几个在跑。
像小饭馆的五个灶眼。五口锅一起烧，一份菜八分钟，第八分钟才端出五份。你一次递两百张单子进去，灶眼还是那五个。
平台给这个团队的额度就是五个。第六个请求进门，得等前五个里有人跑完。
一份二十页合同进去一万八千个 token（模型眼里的字），出来八百个。按每秒吐一百个字算，一份八秒。五个槽除以八秒，一秒钟零点六二五份；两百份除以它，三百二十秒，五分二十秒。
问题出在客户端那个三十秒的超时上。三十除以八，三点七五，凑整四轮；四轮乘五个槽，二十份。第二十一份要等三十二秒，还没轮到，就被自己的代码判死。
队列还在长。剩下的一百八十份各重试三次，加上原来的，七百四十个请求。
七百四十除以零点六二五，一千一百八十四秒，将近二十分钟。槽一刻没空，交出来的仍是那二十份。
怎么解决
三条路，从最便宜的往上走。
- 把客户端的超时改长。 改什么：三十秒改成一百八十秒，比最坏那次等待还长；重试改成等一秒、两秒、四秒，别一失败就重发。改完差多少：两百份在三百二十秒内跑完，交出来的从二十份回到两百份。花的是两行配置，十分钟。
- 把提交速度压到自己扛得住的量。 改什么：客户端先排一个本地队列，最多同时放五个请求，跑完一个放一个，界面上显示还剩多少份。改完差多少：队列攥在自己手里，剩下的份数看得见，不会一秒丢两百个进去把超时全踩响。花的是半天。
- 花钱买更大的并发额度。 改什么：跟平台把五个提到二十个，或者开第二个 key（调用凭证）分走一半。改完差多少：吞吐从零点六二五变二点五，两百份从三百二十秒变八十秒。花的是钱，一个月多几百。
别踩的三个坑：坑一，超时就加并发，服务端还是五个槽，只是更多人一起等。坑二，重试不留间隔，失败瞬间重发，刚空的槽又被抢满。坑三，只调大超时不管提交速度，队列越堆越长，前端先崩。
平台怎么管这些问题
这些事落到平台上，是六个功能串成一条线。
- 并发与速率配置：一处设“同时在跑几个”和“每分钟几个请求”，所有调用方一起生效，不用每个客户端各写一遍。
- 排队与优先级：请求进门先排队，实时问答走快队，批量合同走慢队，慢队排得再长也不占快队的位置。
- 限流回执：额度满了返回明确错误码 429，还带一句等几秒再来，客户端照做就不必瞎重试。
- 并发看板：实时显示在跑几个、排队几个、失败多少，一眼分出是额度不够还是代码在乱重试。
- 失败分类：把超时、限流、服务端报错分开统计，三十秒超时和 429 不是一回事。
- 多通道分流：一个应用挂两把 key 或两家供应商，一边满了自动去另一边，单点额度不再卡死一整晚。
这些功能平时谁管，比功能本身更要紧。
- 谁能改并发额度：平台运维，一人一号，改一次留一条记录，往上调要业务方签字。
- 谁能批临时提额：值班工程师，活动前一小时可提，事后自动回落到原值。
- 出事能不能倒查到人：能。每个请求记四个时间点，进门、开始跑、跑完、返回，一对就知道是排队还是真慢。
- 限流告警发给谁：应用负责人，一分钟内 429 超过百分之五就发，夜里没人接就升级给值班。
这笔钱值不值
掏钱的是这个团队自己。一份合同收客户十二块，人工看一份四十分钟。
那晚白扔多少：一百八十份乘四十分钟，一百二十小时，按一小时八十块（假设）算九千六百。当月 API 账单三百二十块。
改三处配置两小时，一百六十块，当晚就回来。量再涨十倍，两千份也只要五十三分钟。
行业规则怎么管这件事
这条线没有专门的国家文件管并发，管它的是平台自己的限流规则。
规则名就叫《限流》，发布方是阿里云百炼，2026 年这一版挂在它的模型服务文档里：额度按主账号下所有 key 合并算，超了直接拒，返回 429，通常一分钟恢复。
一分钟，正好是那晚工程师没给的耐心。他的代码只等三十秒。
二十份和两百份的差，不在模型，在那三十秒。
第二天早上，那位工程师把超时改成一百八十秒，重试加了间隔。同一批合同再跑一遍，五分二十秒，两百份全齐。他说那晚不是模型慢，是自己没等够。
Token工厂：贰号token工厂
主流大模型 API token 统一接入、统一计费，改个地址就能用。
点这里看详情 →