从5万次到日均2000万次调用：大模型推理服务的性能工程实践
写在前面
2025年初，我接手了一个对外提供大模型API调用服务的内部平台。当时它刚上线三个月，日调用量不到5万次，整体技术架构轻量化、简易化，仅满足初期小流量验证需求：一台GPU服务器，跑着一个Qwen-7B模型，外面包了一层FastAPI。彼时P99延迟稳定在4800ms，体感尚可。
半年后，这个平台需要扛起日均2000万次的大模型API调用，高峰QPS突破1800。在承担了近400倍的流量压力下，系统的P99延迟反而从4800ms降到了720ms。
性能大幅优化并非偶然，是多轮压测、故障复盘、架构迭代重构后的工程成果。而其中最核心的决策，就是双供应商架构。
第一阶段：自建方案的崩塌与被迫转型
最初选自建推理，核心优势在于自主可控、无外部API调用资费、模型参数与推理逻辑可完全自定义。初期仅部署单台GPU服务器，依托transformers原生框架加载Qwen-7B模型，每条请求独立执行generate推理。
当日调用量从5万攀升至50万，系统隐患集中爆发：压测500并发场景下，P99延迟从4.8秒飙升至7秒以上，GPU算力长期接近满载。一次客户批量提交200条推理请求时，由于缺乏KV缓存复用和批量调度，模型实例直接显存溢出宕机。
我们先期尝试过模型量化、请求限流、推理参数调优等自建优化手段，但性能提升幅度有限。若扩容自建GPU集群，硬件采购、机房部署、审批流程周期长达数月，业务流量暴涨节奏无法等待。此时架构只有两条可行路线：持续重资产扩建自建集群，或是切换成熟MaaS推理服务。我们最终选择了后者，并且决定同时引入两家厂商，而非单一依赖。
第二阶段：双供应商架构------成本、性能与风险的三角平衡
在我们的架构里，第二厂商并非冷备份，而是常态化分担流量，承担分摊+兜底双重职责：
- 分摊流量：日常将20%-30%延迟容忍度高的批量任务、非核心业务流量调度至第二厂商。分流后主力厂商负载降低，整体P99延迟同步优化。
- 兜底容灾：主力厂商出现区域故障或性能剧烈抖动时，数分钟内可全量切换流量，绝大多数用户无感知，仅少部分正在处理中的请求需要重试。
- 成本博弈：流量拆分至两家服务商形成竞争关系，我们可依据实时报价动态调整流量权重，在同等服务规格下整体TCO相较单一厂商更具优势。
- 故障兜底保障：我们定期在平峰和高峰时段分别进行故障切换演练，主动关停主供应商的API接入点，验证备用系统可在7分钟内完成全量切流。
本质上，那20%-30%的流量本就需要支付推理费用，区别只是全部结算给单一厂商，还是拆分给两家结算。依靠分流换取议价空间与高可用保障，并未凭空新增闲置冗余开销。
代价也是真实的：我们需要自研轻量级权重调度层（支持健康探测、动态权重）、对接两套API、维护两份监控看板、与两家供应商分别进行售后沟通。这带来了持续的运维增量。但对于日均2000万次调用的生产系统，这笔投入的ROI远高于单点故障的潜在损失。
第三阶段：双供应商的选型与落地
明确了双供应商策略后，我们花了三周时间考察主流MaaS服务商，最终锁定了两家：蓝耘元生代 作为主力，阿里云百炼作为兜底与分摊层。
蓝耘元生代：实测数据支撑的主力推理节点
蓝耘承载了我们70%-80%的核心流量，负责所有对延迟敏感的智能对话和实时推理。这个选择不是拍脑袋，而是基于权威的第三方评测平台------AI Ping 的长周期实测数据。
AI Ping评测输出核心指标为P90延迟，即全部端到端请求里 90% 请求能达到的响应耗时。根据AI Ping2026年6月4日至6月11日的评测结果，蓝耘在DeepSeek-V3.2模型上的吞吐量和P90延迟表现位列前茅；在Qwen系列模型上同样处于行业前游。同时它还是20余家服务商中，少数能稳定把 P90 延迟控制在1秒内的厂商，且指标大幅领先第二梯队。具体细节截图放在下面了大家可以参考一下。值得一提的是，最近两家服务商也适配DeepSeek-V4了，我们也准备将核心业务切换过去。
图：2026.6.4-6.11， AI Ping平台Qwen3-235B-A22B的吞吐数据
图：2026.6.4-6.11， AI Ping平台Qwen3-235B-A22B的延迟数据
图：2026.6.4-6.11， AI Ping第三方评测平台Deepseek-V3.2的吞吐数据
图：2026.6.4-6.11，AI Ping第三方评测平台Deepseek-V3.2的延迟数据
从工程角度，蓝耘提供标准OpenAI兼容API，我们只改了base_url和api_key两行配置就接入了。这种低迁移成本，让我们可以在两家服务商之间灵活调度流量。
短板：它采用精选模型运营策略，不会批量上架海量小众开源模型。但我们生产业务仅稳定使用DeepSeek和Qwen两大系列，其反而针对这两类模型做了深度性能调优，完全匹配业务需求。模型库数量多并不等同于适配自身业务场景，核心场景的极致优化能力才是选型关键。
阿里云百炼：兜底与分摊的稳定基石
阿里云百炼在我们架构中的定位非常清晰：稳定、兼容、多地域覆盖的兜底与分摊层。
选它的理由很务实：
- 阿里云的机房覆盖全国，可以就近接入，降低网络延迟。
- 百炼对Qwen、DeepSeek等主流模型的兼容性极好，几乎零适配成本。
- 团队对阿里云的监控和运维体系最熟悉，出问题能快速定位。
作为国内云厂商的头部，其成熟的企业级服务保障和紧急响应机制为整体架构兜底稳定性提供了可靠支撑。
第四阶段：最终架构的运行机制与成果
经过半年的演进，我们最终的架构运行逻辑包含多层优化叠加：
- 高性能推理底座：MaaS厂商底层采用vLLM/TensorRT-LLM等专业推理引擎，替代了自建的低效transformers。
- 双厂商分流削峰：全局峰值QPS突破1800，流量拆分后两家厂商各自负载压力显著降低，避免单一厂商满载触发性能暴跌。
- 动态路由与健康探测：自研轻量调度服务持续探测两家厂商的P90延迟（参考AI Ping口径及内部监控）和错误率，自动调整流量权重；当某厂商延迟超阈值或出现区域性故障时，快速切流。
- 弹性集群资源池：厂商侧拥有海量GPU集群，无单服务器显存/算力瓶颈，且支持自动伸缩。
这套机制带来的最终效果，用内部监控的P99数据来说明：
| 指标 | 优化前 | 优化后 |
|---|---|---|
| P99延迟 | 4800ms | 720ms |
| GPU资源 | 单GPU长期满载 | 弹性伸缩，无自建硬件 |
| 最大日调用量 | 约30万次（瓶颈） | 超2000万次 |
需要特别说明 ：4800ms是优化前在日调用5万 时的P99延迟（内部监控数据），720ms是在日调用2000万、高峰QPS 1800+时的实测P99。流量增长400倍，延迟反而降低了85%------这是专业推理底座、双厂商分流、动态路由、弹性集群多层优化叠加的结果。
至于第三方评测维度，AI Ping的P90数据为我们选型提供了关键依据，而生产环境我们更关注P99以保障长尾用户体验。
Q&A：关于双供应商架构，大家最常问的两个问题
Q1：双供应商听起来不错，但我们公司预算有限，到底什么情况下才值得做？
A： 根据我们的实践经验，同时满足以下三个条件时，双供应商是理性的架构投资：
- 你有足够的总流量可以拆分：日调用至少百万级以上，分出20%-30%给第二家后，对其仍是"有意义的生意"，能拿到正常价格；同时这20%-30%本身是有效负载（如延迟容忍度高的批量任务、非核心业务），并非闲置。
- 你有能力做流量调度：不需要很复杂，一个基于权重的路由层加健康检查即可。
- 你愿意接受双供应商的运维成本：对接两套API、两份监控、两家售后，换取容灾能力和议价空间。
如果流量太小（如日调用十万级），或者所有业务都对延迟极度敏感（无法拆分），那么老老实实选最好的那家单供应商更划算。
Q2：除了看第三方评测，你们还有什么实际的选型方法？
A： 除了参考 AI Ping 这类平台的长周期 P90 数据，我们内部坚持做三件事：真实流量回放压测、生产 A/B 测试、故障切换演练。
盯紧"性能衰减率"，别被低并发峰值迷惑------重点看 50 并发、100 并发时的 P99 延迟和吞吐量相对于单并发的衰减倍数。衰减率越接近 1，系统在高压下才越"稳"。
此外，再补充两个特别提醒：
- 第一 ，AI Ping 平台仅提供 P90 延迟 数据，并不提供 P99 延迟。如果需要评估长尾延迟（P95/P99），必须自行搭建压测环境，用真实业务流量模拟高并发场景。不要直接拿 AI Ping 的 P90 数据当作 P99 来用。
- 第二 ，部分 MaaS 服务商默认会对每个 API Key 施加 请求频率上限（Rate Limit） 。以蓝耘为例，我们刚接入时发现每秒只能调用 20 次左右，远低于业务需求。这类限制属行业默认，通常不会在官网文档中显著标明，需要在压测前主动联系客服申请提额，否则压测数据会因限流而完全失真。
结语
从5万到2000万次日调用量，从4800ms到720ms的P99延迟------这个看似反直觉的结果，背后是对自建路线的理性放弃，是对中间优化路径的真实尝试，更是对"双供应商不是浪费"这一架构理念的坚持。
虽然双供应商也带来了额外的运维成本，以及对接两套系统的复杂性，但是双供应商分工、同时在线、动态调配，辅以自研调度层和健康探测，才成就了这套既能抗住千万级流量、又能保持极速响应的推理架构。
如果你也在做大模型推理的架构选型，建议先去AI Ping上看一圈持续监测数据（重点关注P90延迟），然后务必自行压测获取P99指标，同时提前与供应商沟通频率上限。毕竟，在真正的生产压力面前，没有备选的架构，本质上都是在赌博。