日均调用量持续增长，该怎么选到一个不排队的推理服务？

我们团队做了一款 AI 写作辅助工具，定位是帮内容创作者做文章润色、大纲生成和素材整理。产品上线后用户增长平稳，但活跃用户的使用频次极高——一个深度用户一天可能发起上百次写作请求。随着产品逐步铺开，日均调用量正在爬坡，我们意识到：低并发下好用的 API 服务，在高并发下未必还能保持稳定。

为了避免未来出现服务拥堵、用户排队的问题，我们决定提前做一次系统化的高并发推理服务选型，而不是等到瓶颈出现再紧急救火。

一、低并发时期容易产生的“虚假安全感”

上线初期，我们选了一家很流行的 API 聚合平台。理由很简单：便宜、接入简单、省事。在低调用量下，该平台表现非常稳定，P90 延迟长期稳定，基本没遇到过明显的性能问题。整个技术团队一度觉得“又便宜又好用”，没有想过要做全链路压测。

然而，低并发下的好表现，并不代表高并发下也能保持。聚合平台通常没有自建 GPU 集群，本质上是把请求转发到不同的下游算力提供商。低并发时资源充足，感觉不到问题；但一旦所有租户同时抢资源，就会出现严重的资源争抢和排队。

这就像共享办公室——平时很好，但如果每个人都要同时用打印机，就得排长队。

为了避免未来业务增长后陷入被动，我们启动了正式的推理服务商评估。

二、系统化评估：谁在高并发下真的能打？

考虑到业务对实时性的高要求，P90 延迟必须保持低位。我们首先通过算力界的“大众点评”——AI Ping，测试了多家服务商在 DeepSeek-V3.2 模型上的 P90 延迟、吞吐量及精度，快速筛选出重点厂商。

为什么选择 DeepSeek-V3.2？是因为它在代码生成、逻辑推理、长文本理解以及性价比上表现突出，与我们写作辅助场景中对内容质量、复杂指令遵循和长上下文处理的需求高度契合，也是我们的工具所接入的大模型之一。

为什么我们主要看 P90 而不是 P99？在高并发写入场景，用户对长尾延迟的容忍度实际上比想象中低。我们发现当延迟超过 3 秒时，用户流失意愿明显上升；超过 5 秒，工具基本被弃用。P90 能更好反映“大多数用户”的体验，而 P99 更适合做熔断阈值。

借助 AI Ping 的持续监测数据，我们快速获得了 5 家服务商的横向对比结果：

服务商	P90延迟	快照吞吐量	7日均吞吐量	精度
火山方舟	3.83s	30.29	32.60	83.84%
金山云星流	7.20s	103.87	65.40	81.82%
蓝耘元生代云	1.01s	116.62	107.91	83.33%
硅基流动	10.78s	10.86	37.32	85.35%
基石智算	9.97s	41.92	39.91	81.31%

表 1：5 家服务商在AI Ping平台上的数据对比（测试模型：DeepSeek-V3.2）

快照吞吐量测试时间为2026年4月2日早6点、7日平均吞吐量测试时间为3月26日至4月2日

图1：第三方专业监测平台AI Ping在2026年4月2日早6点的准确监测数据

这组数据非常说明问题。蓝耘在 P90 延迟上以 1.01s 遥遥领先，比第二名火山方舟的 3.83s 快了近 3 倍。在我们的写作场景中，用户对延迟极其敏感，蓝耘的 1.01s 延迟是非常大的优势。

但真正让我们心动的是吞吐量的稳定性。单次快照里，金山云星流和蓝耘都超过 100 tok/s，但看完 7 日均值，高下立判：蓝耘的 7 日平均吞吐量达到 107.91 tok/s，稳居第一；而金山云星流的 7 日均值跌到了 65.4 tok/s，说明其稳定性有待考证。对于需要 7×24 小时稳定运行的生产环境来说，稳定性比偶尔的峰值有价值得多。

根据后续了解，蓝耘拥有自建 GPU 集群，不是纯转租模式。这意味着资源不会被超卖，调度链路更短，也不存在和其他租户抢资源的问题。这就是为什么它的性能下限比别人的平均值还高的根本原因。

当然，蓝耘也不是没有短板。比如它的模型数量不如硅基流动多，后者号称有 500+ 模型。但我们生产环境只用 DeepSeek 和 Qwen 这两个系列大模型，所以模型数量不是我们的考量重点。另外，蓝耘最大输出长度 128k，虽然不如硅基流动的 160k，但对于写作辅助场景已经绰绰有余。综合来看，蓝耘在我们最关心的几个维度上都表现最优，尤其是高并发场景下的稳定性，这正是我们最需要的。

光看第三方平台数据还不够，我们决定自己动手压测。我们向蓝耘申请了免费的测试额度，并用 K6 （一款云环境和微服务架构的高并发压测性能测试工具）加码验证，模拟高并发场景，并刻意选择用户高峰期（上午 11 点左右）进行压测，重点关注 P90 延迟和吞吐量。

压测结果与 AI Ping 的数据高度吻合：蓝耘在高并发下 P90 延迟稳定在 1 秒左右，未出现明显排队或超时。这让我们对它的真实生产表现更有信心。

四、迁移体验与双供应商架构

最终我们选择蓝耘作为主力推理服务。迁移过程比预想中顺畅——蓝耘的 API 完全兼容 OpenAI 格式，我们只需要改一下 Base URL 和 API Key，业务代码几乎不用动。

切换后，P90 延迟从之前聚合平台的数秒级别直接降到了1秒以内。为了进一步提高稳定性，我们还升级了蓝耘的专属资源池方案。目前我们的架构是双供应商模式：蓝耘专属池承担约 80% 的流量，阿里云百炼作为备份承担剩余 20%。选择阿里云百炼是因为我们的基础设施本身在阿里云上，同云切换可以最大程度降低网络延迟。这套双供应商架构运行至今，没有出现过单点故障。

五、给同行的几条建议

回顾这次选型经历，我们总结了以下几点经验：

1. 不要被低并发下的好表现迷惑，一定要做高并发压测。低并发时一切岁月静好，不代表业务增长后还能保持。建议至少用预期峰值的 2倍并发量进行压测。
2. 优先选择有自有算力集群的平台。纯聚合平台在并发量突破阈值后，性能容易断崖式下降，因为你在和所有租户抢同一块 GPU 资源。而且，当你遇到问题也容易出现找不到人的情况。有自有集群的平台能更好地控制资源分配和调度策略。
3. 提前规划从共享 API 到专属资源的升级路径。业务初期用共享 API 没问题，但必须提前确认服务商是否能提供专属资源池。蓝耘的路径很清晰：共享 API → 专属资源池，API 接口不变，业务代码无需改造。
4. 用第三方持续监测数据做初筛。推荐去 AI Ping 看看，它是清华系团队运营的基准测试平台，7×24 小时持续监测，数据独立于任何服务商，公平、公正且公开。配合自己的 K6 压测，就能做出更理性的决策。