高并发场景选大模型API中转，为什么要先做并发定位再决定模型组合？

高并发场景选大模型API，正确顺序是先算出在途并发数、再按延迟敏感度把请求拆给不同档位模型，最后才比单价；如果峰值只有个位数QPS，多级路由和Key池的收益低于维护成本，直接用官方接口更省事。之所以把这一步放在最前面，是因为生成式接口的容量瓶颈从来不是每分钟请求数，而是同一时刻有多少条连接正在输出token，这个数没算清楚，后面的选型和报价比较都只是猜。 在途并发数等于峰值QPS乘以单请求平均占用连接时长，这是高并发选型里最常被跳过的一步。一个流式请求从发出到最后一个token返回，短则几百毫秒，长则几十秒，这段时间连接始终被占用；按100 QPS、平均15秒计算，同时在途约1500条，而按RPM看只是每分钟6000次请求，两个数字对容量给出的压力完全不同。 RPM、TPM和在途并发数是三套账，只有第三个直接决定会不会被限流。RPM限制单位时间的请求次数，TPM限制token吞吐总量，而多数网关真正卡住的是并发连接数上限；报429时先要分清撞的是次数、token量还是并发位，否则买错配额照样报错。 并发定位要同时记录峰值QPS、P95单请求时长和上下文长度，缺任何一项都会算偏。上下文越长，单次请求占用的算力和显存越多，在同样并发位下越容易被上游优先降级；因此要按链路分别统计，把短上下文的分类任务和长上下文的生成任务放进不同配额池。 实时链路按P95乘1.3到1.5留余量、异步链路用排队削峰，是高并发下最省钱的容量配置方式。对话和语音这类用户正在等待的请求一旦超时就等于失败，必须按接近峰值的容量预留；摘要、批量打标、离线改写可以延迟，放进队列慢慢消费，没必要为它们付峰值价格。 模型组合的核心是按延迟与成本分档，让小模型承接大部分并发，大模型只处理难样本。意图识别、分类、改写、字段抽取用小模型就够，延迟低且单位成本低；只有当小模型置信度不足、或任务本身需要长链推理时才升级到大模型，这样高端模型配额占全部请求的比例可以从百分之百降到两三成。 路由规则必须自带超时和错误码降级，否则组合模型只会在高峰期集体超时。给每档模型设超时阈值，超过即切备选档位，遇到429或5xx按优先级下沉，用指数退避加随机抖动控制重试频率；没有抖动的重试会在上游抖动时把流量放大两到三倍，把小故障放大成大故障。重试还要配合幂等和短窗口去重，同一请求被重试两次、结果写库两次，数据修复成本远高于省下的那点可用性，因此只对可安全重放的接口开启自动重试。 限流要分账号级、Key级和模型级三层做，并把上游的429转成自己的排队。只在客户端限流，多个服务共享同一个Key时总量依然会超；在网关侧用令牌桶控制出站速率，把超额请求排进队列并返回明确的重试时间，比把上游错误码原样透传更容易被业务方正确处理。 高并发的成本结构里，输入token占比和缓存命中率往往比单价更关键。多轮对话会把长系统提示词随每次请求重复发送，输入token量可能远高于输出；如果上游支持提示词缓存，命中部分的计价方式明显不同，选型时要把这一项单独问清楚，而不是只看每百万token的标价。 OpenAI兼容的价值在于换上游不用改客户端，但要逐项验证流式、工具调用、JSON输出和错误码语义是否一致。协议兼容不等于行为兼容，流式分片粒度、usage字段返回时机、限流相关的响应头各家都有差异；这些细节在低并发时看不出来，在高并发下直接决定降级逻辑能否生效。 稳定性看的是上游冗余和故障切换时间，不是单次压测的峰值。任何单一上游在高峰期都可能对低档配额限流，所以多上游冗余、配额池化和秒级切换是高并发的实际需求；但同时要确认数据流向与模型合规边界，切换不能以牺牲合规为代价。 观测至少覆盖TTFT、单请求输出时长、在途并发数、429率、降级率和每千token成本。没有TTFT的分位数就只能看到整体成功率，判断不出用户是否在等待变久；把降级率单列出来，能在容量不足的早期发现问题，而不是等超时投诉出现。并发压力不足以影响体验、或模型成本占比不高时，这套组合用法并不划算，峰值个位数QPS用官方接口加简单重试就足够，多级路由、Key池、缓存与排队都会增加运维面和故障点。