HopBase先说答案:大模型 API 的高并发问题,本质不是「网关转发快不快」,而是三件事叠加——上游配额稀缺(RPM/TPM 有硬顶)、上游错误常态化(429/5xx 是日常而非事故)、单请求生命周期长(流式几十秒、视频任务分钟级)。所以企业级网关的高可用靠的不是吞吐参数,而是调度:多上游互备、把错误纳入调度判决的自动 failover、以及不牺牲缓存命中率的亲和调度。这三样在接入前都可以用可复现的方法验证,文末给出清单。
大模型 API 的高并发,和传统 API 不是一回事
传统 API 网关谈高并发,拼的是每秒转发多少请求;大模型网关的瓶颈根本不在这里:
- 单请求生命周期长:一次流式对话几十秒,一个视频生成任务分钟级,并发容量吃的是「同时在途的长连接」,不是 QPS;
- 上游配额稀缺:每个上游账号的 RPM/TPM 有硬顶,单账号永远扛不住业务峰值,「高并发」的第一性来源是账号池的总配额;
- 上游错误是常态:429 限流、5xx 波动、时段性拥堵在所有大模型上游都存在,网关不处理,这些错误就会原样砸在每个调用方头上。
结论:传统网关拼吞吐,大模型网关拼调度。评估一个「高并发网关」,要看的是它的调度层怎么设计。
多上游分组:并发容量的第一性来源
HopBase 的做法是分组调度:一把 API Key 背后是一个分组,组内是多个上游账号与通道,并发容量等于组内配额之和,而不是任何单账号的 RPM。业务侧的用法:
- 按业务线或团队拆分组,配额互相隔离,批量任务不会挤占在线业务;
- 峰值业务单独建组、单独扩容,不影响其他调用方;
- 换模型、换通道在网关侧调度完成,客户端不改一行代码。
分组机制怎么同时把成本降下来,另有一篇:一个 API Key 调度多家上游。
failover:错误要参与调度判决,而不是直接甩给你
多数网关对上游错误的处理是「原样返回,重试留给客户端」——高并发场景下这等于把上游的不稳定放大给每一个调用方。我们的做法:
- 上游报错先进入调度判决:不止 5xx,绝大多数可判定的 4xx 同样触发自动换账号、换通道重试;
- 重试穷尽后,把上游的原始响应回放给你——不吞错误码、不把 429 改造成超时,你客户端自己的退避逻辑不会被毁掉;
- 计费以真实成功为准:失败的请求(错误码非空)不计费,这一条在用量导出里逐行可验。
探针与事件流:问题要在用户感知之前被发现
高可用的另一半是主动发现,而不是等用户报错:
- 常驻健康探针持续拨测各通道;
- 每个上游账号的错误与恢复形成事件流,异常账号自动降权或摘除,恢复后再回池;
- 判断上游死活用凭证直连对照实测,而不是猜——「感觉上游挂了」和「证明上游挂了」是两回事。
缓存亲和:高并发不该牺牲 prompt cache
这是最容易被忽视的一项。prompt cache 的命中要求请求落在同一个上游账号上;把请求随机撒进账号池的「负载均衡」,命中率会掉到接近零——高并发和缓存收益在朴素设计里是互斥的。
解法是亲和调度:同一会话钉住同一账号,亲和窗口覆盖官方缓存的有效期,扩容时不打散既有会话。命中的收益是双重的:缓存读取按折扣价计费,首字延迟也显著下降。原理与实测见Prompt Cache 能省多少钱。
怎么验证一个网关的高并发成色(可复现)
机制要能被验证才有意义。接入前建议跑这五项,对任何供应商都适用:
- 并发压测看分布:固定任务集、温度 0,并发 N 跑,看首字延迟(TTFT)的 P95/P99 而不是均值——长尾抖动大说明链路在排队;
- 长输出断流率:让模型输出长内容,统计流式中途静默截断的比例,这是最恶劣的故障形态;
- 错误透传测试:故意触发限流或传错参数,看返回的错误码是否与官方行为一致;
- 缓存命中率:同一长系统提示连续请求,看 usage 里缓存读取 token 的占比是否稳定;
- 隔时段复测:高峰与低谷各测一轮,防时段性劣化。
模型身份与质量的验证(防偷换、防降智)是另一套方法,见保真检测方法。
常见问题
HopBase 支持多大并发?
并发承载按业务场景配置:企业批量任务、研发团队共享、多业务线峰值调用是设计目标。接入前联系顾问按量评估,给出与你的负载匹配的分组方案。
为什么不直接承诺 99.99% SLA?
页面上的可用性数字无法被你验证,我们更愿意给可复现的验证方法和公开的通道属性(每条通道是什么渠道、什么倍率,定价页全部写明)。商务合同层面的服务条款,联系顾问洽谈。
上游全部故障时会发生什么?
多通道互备把单点故障变成局部降级;极端情况下所有重试穷尽,网关把上游原始错误透传给你,不伪造成功,失败不计费。
高并发扩容会导致缓存命中率下降吗?
不会。亲和调度按会话钉账号,扩容增加的是新会话的容量,既有会话不被打散,命中率不受扩容影响。