博客
一手测评｜RAG总卡死？大模型给Embedding API 时延背了太多锅了

一手测评｜RAG总卡死？大模型给Embedding API 时延背了太多锅了

2025-05-08

By 朱文星

开发RAG，还有谁没遇到过以下几个崩溃时刻：

该有的知识全都喂进去了，但就是没办法找到想要的内容

明明设备、SaaS全都性能拉满，但就是一个查询，花费几十秒

同一套系统，美国同事用的好好地，结果中国区同事一用就崩

……

报错来的猝不及防，可能的原因五花八门。大部分人的第一想法就是，优化 LLM 或向量检索，但可能一开始你的方向就走错了。

对大部分RAG应用来说，真正的卡顿杀手，大概率来自你调用的 Embedding API。

基于LLM构建RAG，以及电商搜索、信息流推荐的过程中，Embedding 技术是核心，它可以将文本转化为向量，让机器能够理解语义并进行高效相似性搜索。通常，我们会提前预计算文档库的 Embedding 向量，但在用户查询时，还是需要实时调用 Embedding 模型将问题转化为向量，再进行检索。

而这个实时调用的时延，往往会成为整个应用链条中的性能瓶颈。

Milvus 将在2.6版本提供 TextEmbedding Function 功能，允许用户在 Milvus 内部直接调用各种主流的 Embedding API 服务。Embedding服务Provider提供的便利的背后，性能代价如何？不同服务商、不同网络环境下的表现又有多大差异？

近期，我们利用 Milvus TextEmbedding Function 对国内外多个主流 Embedding 服务商进行了实测：

为什么 Embedding API 时延如此重要？

值得注意的是，目前行业内流行的 Embedding 模型排行榜（如 MTEB）大多关注模型的效果指标（如召回率）和参数规模，却往往忽略了在实际部署中同样关键的性能指标——调用时延。这使得开发者在选型时容易陷入“唯效果论”的误区，而忽略了高延迟可能带来的性能瓶颈。

实际上，Embedding API 的时延问题体现在两个关键阶段：

查询阶段 (Query Time): 想象一下 RAG 应用的典型流程：
- 用户提出问题。
- 调用 Embedding API 将问题转换为向量 (Query Vector)。 <-- 实时查询时延瓶颈点！
- 用 Query Vector 在 Milvus 向量数据库中搜索相似文档向量。
- 将检索到的相关文档和原始问题一起提交给 LLM。
- LLM 生成最终答案。很多人认为步骤 5 (LLM 生成答案) 是最耗时的，但随着流式输出 (Streaming Output) 技术的普及，用户能很快看到第一个 Token，感知上的延迟可能并不长。相比之下，步骤 2 中调用 Embedding API 的延迟，如果高达数百毫秒甚至数秒，就会成为用户能明显感受到的、阻塞整个流程的‘第一道坎’，因此常常是实际的性能瓶颈点。
入库阶段 (Insertion Time): 除了查询时延，当你需要将大量文档数据灌入 Milvus 时，Embedding API 的时延同样是主要瓶颈。无论是初次建库还是定期更新，都需要将成千上万甚至数百万的文本块进行向量化。如果使用 Embedding API，大部分的数据插入时间实际上都耗费在了等待 API 返回 Embedding 向量上。缓慢的 Embedding 过程会严重拖长数据准备周期，影响应用的上线速度和数据更新频率。

因此，无论是追求实时响应的查询（RAG 或实时搜索），还是高效的数据批量处理，Embedding API 的时延都是一个必须正视的关键性能指标。

Milvus 实测：时延真相远超想象

我们模拟了真实应用场景，在 Milvus 中通过 TextEmbedding Function 调用不同服务商的模型，记录了端到端的时延数据。测试覆盖了 OpenAI、Cohere、Bedrock 、Google Vertex AI、 VoyageAI、阿里云 Dashscope、SiliconFlow 等国内外主流服务商下的多个embedding模型。

5.8-1.png

时延对比

海外模型

5.8-2.png

5.8-3.png

从时延指标来看，cohere > google > VoyageAI> openai > Bedrock

国内模型

5.8-4.png

5.8-5.png

从延迟来看，硅基流动优于 dashscope

核心发现一：国内和海外提供商对长文本支持差异较大

国内提供商支持长文本（8K token）的模型并不多，只有text-embedding-v3和bge-m3，但是海外提供商的模型都支持了8K的长文本

核心发现二：网络环境是“王道”，地域差异巨大！

为什么网络环境如此关键？因为 Embedding 服务通常涉及发送较长的文本（作为输入）和接收高维度的向量（作为输出），这意味着网络传输的数据包（Package）相对较大。当网络链路长、质量不稳定（尤其是跨境传输）时，这些较大的数据包更容易受到延迟、抖动甚至丢包的影响，从而显著增加 API 的整体响应时间。

这正是本次测试最关键的发现！同一个 Embedding API 服务商，在不同网络环境下的表现可能天差地别。

国内访问海外服务: 当你的应用部署在国内，访问部署在海外的 OpenAI, Cohere, VoyageAI 等服务时，网络延迟显著增加，实测显示 API 调用时延普遍增加了 3 到 4 倍！
海外访问国内服务: 反之，当你的应用部署在海外，访问国内的 Dashscope, SiliconFlow 等服务时，性能“劣化”更为严重，尤其是 SiliconFlow，时延甚至可能增加近百倍！

这意味着：

选择 Embedding 服务商，必须优先考虑你的应用部署地和主要用户所在地！脱离网络环境谈性能，毫无意义！

5.8-6.png

核心发现三：同一provider的large模型，标准模型和small(lite)模型时延差距因Provider而不同

我们测试了不同Provider的不同规模模型，latency基本趋势是large > standard > small(lite),cohere和openai不同规格的模型时延差异并没有想象中大，但是VoyageAI的则是有明显差异

5.8-7.png

5.8-8.png

5.8-9.png

这说明 API 的实际响应时间不仅取决于模型本身，还可能受到服务商后端架构（如请求批处理机制）等多种因素的影响。

不要迷信模型参数或发布时间，实际性能需要通过在你自己的环境中进行测试来验证。

核心发现四： token长度对时延的影响，因模型和批次大小而不同

这个应该同样是可能受到服务商后端架构（如请求批处理机制）等因素的影响。

Openai 在大批次和小批次文本下，不同token下，时延变化并不明显：可能攒批窗口较大，目前的测试还没达到临界值
VoyageAI在大批次和小批次文本下，token长度对时延有明显影响：可能没有设置攒批机制
其他模型在小批次文本下，token是时延没有显著影响，但是当批次增加后，影响变得明显：可能设置了攒批机制，但是窗口较小，当前测试达到了临界值

核心发现五：合理使用batch size

一个请求中文本batch size越大，时延越高，但是时延的增长倍数是少于batch size的倍数，这也意味着整体的吞吐量是提高的。批次从1增加到10，时延的增加在2～5倍

5.8-10.png

核心发现六：API 可靠性风险不容忽视

虽然本次测试主要关注时延，但依赖任何外部 API 都存在一定的失败风险（如网络抖动、服务商限流、服务宕机等）。尤其在许多服务商不提供明确 SLA 的情况下，应用设计时需要考虑加入重试、超时和熔断机制。

5.8-11.png

5.8-12.png

Openai ai和VoyageAI的延迟并不稳定，方差很大，这会给上游服务带来很大的不确定性

核心发现七：Milvus 自身调用开销极低

我们的测试也验证了通过 Milvus TextEmbedding Function 调用这些 API 所引入的额外开销非常小，几乎可以忽略不计。性能瓶颈主要在于网络传输和 Embedding API 服务商自身的处理能力。

核心发现八：小成本自建的CPU推理服务也能够媲美云服务提供商的性能

使用TEI在4c8g的cpu模式下部署的bge-base-en-v1.5可以提供与硅基流动相同时延的性能

5.8-13.png

如何应对？给开发者的 actionable insights

面对复杂的时延现状，我们该如何选择和优化？

本地化测试是王道: 不要轻信任何通用 Benchmark 报告（包括本文！），即使是 MTEB 这样的效果榜单也未包含时延。最可靠的方法是在你真实的部署网络环境下，对你关心的几个候选服务商进行实测。
网络环境决定选型:
- 应用/用户在国内: 优先考虑国内服务商（如阿里云 Dashscope、SiliconFlow 等），并实测其稳定性。
- 应用/用户在海外: 优先考虑海外服务商（如 Cohere、VoyageAI、OpenAI、Azure OpenAI、GCP Vertex AI 等），同样需要实测。
- 服务全球用户: 可能需要根据用户地域进行动态路由，或者选择在多区域部署节点的服务商，并仔细评估其跨区域性能。
不盲目跟风使用openai embedding，本次测试发现openai 的性能和稳定性都一般
合理调整batch size和文本 chunk size，同一个设置，并不适配所有embedding 模型
缓存常用查询 Embedding: 对于搜索框、热门问题等高频查询场景，将查询文本及其生成的 Embedding 向量缓存起来（如使用 Redis）。下次相同查询可以直接命中缓存，将延迟降至毫秒级。这是成本最低、效果最显著的查询时延优化手段之一。
考虑本地推理 (兼顾个人开发者困境): 如果对入库时延、查询时延和数据隐私有极高要求，或者 API 调用成本过高，并且标准套餐往往伴随着 QPS 限制、时延不稳定、缺乏 SLA 保障等诸多限制，难以满足生产环境要求，可以考虑将 Embedding 模型部署在本地进行推理。对于许多个人开发者或小型团队而言，缺乏企业级 GPU 可能是本地部署高性能 Embedding 模型的一大障碍。然而，这并不意味着完全放弃本地推理。结合高性能的推理引擎（如 https://github.com/huggingface/text-embeddings-inference），即使在 CPU 上运行一些中小型 Embedding 模型也能获得不错的性能，可能优于高延迟的 API 调用，尤其适合大批量数据的离线 Embedding 生成。这需要在成本、性能和维护复杂度之间进行权衡。

Milvus 如何助你一臂之力？

面对 Embedding 获取和使用的复杂性，Milvus 不仅仅是一个向量数据库，更能通过其 TextEmbedding Function 等特性，在以下方面为你提供强大支持，简化开发流程：

高效向量管理: 这是 Milvus 的核心能力。作为专为海量向量数据设计的高性能数据库，它提供可靠的存储、灵活的索引（如 HNSW, IVF 系列等）和快速精准的向量检索能力。
简化测试与验证: TextEmbedding Function 提供了一个一站式的平台来测试和验证不同的 Embedding API 服务。你不再需要在代码中分别对接各个厂商的 SDK，只需在 Milvus 中配置好 Function 并提供你的 API Key（Bring Your Own Key, BYOK），就可以轻松切换和对比不同模型在真实 Milvus 操作（如插入、查询）中的端到端性能表现。
流式数据处理：从文本到入库一步到位: 配置好 TextEmbedding Function 后，你在调用 insert() 接口时，可以直接提供原始文本数据。Milvus 会自动调用配置好的 Function 将文本转换为向量，并将向量及其他字段数据一步存入数据库，极大简化了数据写入流程。
端到端语义查询：从文本到结果一步完成: 同样地，在调用 search() 接口时，你可以直接输入文本查询语句。Milvus 会利用 TextEmbedding Function 将其转换为查询向量，执行相似性搜索，并将最相关的结果返回给你，实现了从文本输入到查询结果的无缝对接。
便捷的 API 集成: Milvus 内部封装了对主流 Embedding API 的调用逻辑，屏蔽了底层实现的复杂性。开发者只需关注 Function 的配置（选择服务商、模型、输入输出字段等）和 API Key 的提供，即可快速集成。
开放的生态: 无论你的 Embedding 向量是通过 Milvus TextEmbedding Function 生成，还是通过本地模型推理或其他方式获得，Milvus 都能轻松集成，为你提供统一的向量存储和检索服务。