前言

2025年了，应该没有企业还没有构建自己的企业知识库吧！！！

自今年年初DeepSeek爆火，紧随其后MCP降低应用开发难度，构建企业级知识库，早就从可选项变成了必选项。

毕竟，部门有分工、人员有流动、业务有更替，但历史文档散落各处。对任何公司来说，让信息高效流动，让新员工可以对公司业务快速上手，让老员工跨部门协作更加顺畅，都意义非凡。

但对各位企业内部IT来说，开发RAG，谁还没遇到过以下几个崩溃时刻：

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

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

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

……

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

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

那么，国内外各主流 Embedding 服务商的API时延究竟有多大？接下来就是我们的一手实测。

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

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

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

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

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

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

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

1. 查询阶段 (Query Time): 想象一下 RAG 应用的典型流程：

   1. 用户提出问题。

   2. 调用 Embedding API 将问题转换为向量 (Query Vector)。 <-- 实时查询时延瓶颈点！

   3. 用 Query Vector 在 Milvus 向量数据库中搜索相似文档向量。

   4. 将检索到的相关文档和原始问题一起提交给 LLM。

   5. LLM 生成最终答案。 很多人认为步骤 5 (LLM 生成答案) 是最耗时的，但随着流式输出 (Streaming Output) 技术的普及，用户能很快看到第一个 Token，感知上的延迟可能并不长。相比之下，步骤 2 中调用 Embedding API 的延迟，如果高达数百毫秒甚至数秒，就会成为用户能明显感受到的、阻塞整个流程的‘第一道坎’，因此常常是实际的性能瓶颈点。

2. 入库阶段 (Insertion Time):

   除了查询时延，当你需要将大量文档数据灌入 Milvus 时，Embedding API 的时延同样是主要瓶颈。无论是初次建库还是定期更新，都需要将成千上万甚至数百万的文本块进行向量化。如果使用 Embedding API，大部分的数据插入时间实际上都耗费在了等待 API 返回 Embedding 向量上。缓慢的 Embedding 过程会严重拖长数据准备周期，影响应用的上线速度和数据更新频率。

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

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

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

时延对比

海外模型

median latency with batch size 1

median latency with batch size 10

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

国内模型

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

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

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

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

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

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

• 国内访问海外服务: 当你的应用部署在国内，访问部署在海外的 OpenAI, Cohere, VoyageAI 等服务时，网络延迟显著增加，实测显示 API 调用时延普遍增加了 3 到 4 倍！

• 海外访问国内服务: 反之，当你的应用部署在海外，访问国内的 Dashscope, SiliconFlow 等服务时，性能“劣化”更为严重，尤其是 SiliconFlow，时延甚至可能增加近百倍！

这意味着：

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

客户端在不同网络环境中的时延对比

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

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

cohere

openai

VoyageAI

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

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

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

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

• Openai  在大批次和小批次文本下，不同token下，时延变化并不明显：可能攒批窗口较大，目前的测试还没达到临界值

• VoyageAI在大批次和小批次文本下，token长度对时延有明显影响： 可能没有设置攒批机制

• 其他模型在小批次文本下，token是时延没有显著影响，但是当批次增加后，影响变得明显： 可能设置了攒批机制，但是窗口较小，当前测试达到了临界值

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

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

当batch size从1增加到10 ，各个模型的时延增长倍数

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

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

batch size为1时，时延标准差

batch size为10时，时延标准差

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

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

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

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

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

TEI时延

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

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

1. 本地化测试是王道: 不要轻信任何通用 Benchmark 报告（包括本文！），即使是 MTEB 这样的效果榜单也未包含时延。最可靠的方法是在你真实的部署网络环境下，对你关心的几个候选服务商进行实测。

2. 网络环境决定选型:

   1. 应用/用户在国内: 优先考虑国内服务商（如阿里云 Dashscope、SiliconFlow 等），并实测其稳定性。

   2. 应用/用户在海外: 优先考虑海外服务商（如 Cohere、VoyageAI、OpenAI、Azure OpenAI、GCP Vertex AI 等），同样需要实测。

   3. 服务全球用户: 可能需要根据用户地域进行动态路由，或者选择在多区域部署节点的服务商，并仔细评估其跨区域性能。

3. 不盲目跟风使用openai embedding，本次测试发现openai 的性能和稳定性都一般

4. 合理调整batch size和文本 chunk size，同一个设置，并不适配所有embedding 模型

5. 缓存常用查询 Embedding: 对于搜索框、热门问题等高频查询场景，将查询文本及其生成的 Embedding 向量缓存起来（如使用 Redis）。下次相同查询可以直接命中缓存，将延迟降至毫秒级。这是成本最低、效果最显著的查询时延优化手段之一。

6. 考虑本地推理 (兼顾个人开发者困境): 如果对入库时延、查询时延和数据隐私有极高要求，或者 API 调用成本过高，并且标准套餐往往伴随着 QPS 限制、时延不稳定、缺乏 SLA 保障等诸多限制，难以满足生产环境要求，可以考虑将 Embedding 模型部署在本地进行推理。对于许多个人开发者或小型团队而言，缺乏企业级 GPU 可能是本地部署高性能 Embedding 模型的一大障碍。然而，这并不意味着完全放弃本地推理。结合高性能的推理引擎（如 https://github.com/huggingface/text-embeddings-inference），即使在 CPU 上运行一些中小型 Embedding 模型也能获得不错的性能，可能优于高延迟的 API 调用，尤其适合大批量数据的离线 Embedding 生成。这需要在成本、性能和维护复杂度之间进行权衡。

04 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 都能轻松集成，为你提供统一的向量存储和检索服务。

总之，Milvus 致力于打通从非结构化数据到向量、再到洞察的全链路，TextEmbedding Function 正是简化这一流程、提升开发效率的关键一环。

结语

选择 Embedding 服务是一项需要综合考量的决策，不能只看 MTEB 等榜单上的效果分数。API 时延（影响查询和入库）、网络环境以及服务限制是同样重要的关键因素。希望 Milvus 的这份实测报告能为你提供有价值的参考，助你构建出性能更佳、响应更快的 AI 应用。

互动一下：

• 你目前在用哪个 Embedding 服务？体验如何？

• 你在 RAG 或实时搜索应用中遇到过哪些性能瓶颈？（查询慢？入库慢？API 限制？）