在生产环境中部署搜索基础模型的实用指南

在 Jina AI，我们的使命是为企业用户提供高质量的搜索解决方案。为实现这一目标，我们通过多种渠道提供模型访问。然而，为特定用例选择合适的渠道可能比较困难。在这篇文章中，我们将带您了解决策过程并分析权衡，根据您的用户画像和需求为您提供选择访问搜索基础模型最佳方式的实用指导。

tagJina 搜索基础模型

我们的搜索基础模型

我们从一开始就在推动搜索模型的发展。查看下面我们的模型演进历程—悬停或点击以了解每个里程碑。

Jina AI

我们的搜索基础模型包括：

• Embeddings：将数字对象的信息转换为 embedding 向量，捕获其基本特征。
• Rerankers：对查询-文档集进行深入语义分析，提高搜索相关性。
• 小型语言模型：包括专门的 SLM，如用于 HTML2Markdown 或信息提取等特定任务的 ReaderLM-v2。

在本文中，我们将探讨 jina-embeddings-v3 的不同部署选项，比较三种主要方法：

• 使用 Jina API
• 通过 CSP 部署，如 AWS SageMaker
• 在 Kubernetes 集群上使用商业许可自行托管

我们将评估每种方法的成本影响和优势，帮助您确定最适合您需求的选项。

tag关键性能指标

我们在不同使用场景下评估了五个关键性能指标：

• 请求成功率：向嵌入服务器发送的成功请求百分比
• 请求延迟：嵌入服务器处理并返回请求所需的时间
• Token 吞吐量：嵌入服务器每秒可处理的 token 数量
• 每 Token 成本：每个文本单元的总处理成本

对于在 Kubernetes 集群上自托管的 Jina embeddings，我们还研究了动态批处理的影响。这个功能会将请求排队直到达到最大批量大小（jina-embeddings-v3 为 8,192）再生成 embeddings。

我们有意从分析中排除了两个重要的性能因素：

• 自动扩展：虽然这对于工作负载变化的云部署至关重要，但其有效性取决于多个变量—硬件效率、网络架构、延迟和实现选择。这些复杂性超出了我们当前的讨论范围。请注意 Jina API 包含自动扩展功能，我们的结果反映了这一点。
• 量化：虽然这种技术可以创建更小的 embedding 向量并减少数据传输，但主要优势来自其他系统组件（数据存储和向量距离计算），而不是减少的数据传输。由于我们专注于直接模型使用成本，因此在本分析中未包含量化。

最后，我们将研究每种方法的财务影响，同时考虑总拥有成本和每 token/每请求的费用。

tag部署设置

我们评估了 jina-embeddings-v3 的三种部署和使用场景：

tag使用 Jina API

所有 Jina AI embedding 模型都可以通过 Jina API 访问。访问采用预付费 token 系统，提供一百万个免费 token 用于测试。我们通过从德国办公室通过互联网进行 API 调用来评估性能。

tag使用 AWS SageMaker

Jina Embeddings v3 可供 AWS 用户通过 SageMaker 使用。使用需要订阅此模型的 AWS 服务。对于示例代码，我们提供了一个笔记本，展示如何使用 AWS 账户订阅和使用 Jina AI 模型。

虽然这些模型也在 Microsoft Azure 和 Google Cloud Platform 上提供，但我们的测试重点是 AWS。我们预计在其他平台上会有类似的性能。所有测试都在 us-east-1 区域的 ml.g5.xlarge 实例上运行。

tag在 Kubernetes 上自托管

我们用 Python 构建了一个 FastAPI 应用程序，该应用程序使用 SentenceTransformer 库从 HuggingFace 加载 jina-embeddings-v3。该应用程序包含两个端点：

• /embed：接收文本段落作为输入并返回其 embeddings
• /health：提供基本的健康监控

我们将其作为 Kubernetes 服务部署在 Amazon 的 Elastic Kubernetes Service 上，使用 us-east-1 区域的 g5.xlarge 实例。

有无动态批处理

我们在 Kubernetes 集群中测试了两种配置的性能：一种是收到请求时立即处理，另一种是使用动态批处理。在动态批处理的情况下，服务会等待直到队列中收集了 MAX_TOKENS（8192）个 token，或达到预定义的 2 秒超时，然后才调用模型并计算 embeddings。这种方法提高了 GPU 利用率并减少了 GPU 内存的碎片化。

对于每个部署场景，我们通过改变三个关键参数进行测试：

• 批量大小：每个请求包含 1、32 或 128 个文本段落用于 embedding
• 段落长度：我们使用包含 128、512 或 1,024 个 token 的文本段落
• 并发请求：我们同时发送 1、5 或 10 个请求

tag基准测试结果

下表是每个使用场景的结果汇总，对上述三个变量的所有设置取平均值。

tag请求成功率

我们的测试中，成功率从 SageMaker 接近完美的 99.9% 到自托管解决方案的 56-58% 不等，这突出表明了在生产系统中实现 100% 可靠性仍然难以实现。三个关键因素导致了这一点：

• 网络不稳定性在云环境中也会导致不可避免的失败
• 资源竞争，特别是 GPU 内存，在负载下会导致请求失败
• 必要的超时限制意味着某些请求必须失败以维护系统健康

tag按批量大小划分的成功率

在自托管 Kubernetes 配置中，大批量大小经常导致内存不足错误。在没有动态批处理的情况下，所有包含 32 或 128 个项目的批量请求都因此原因而失败。即使实施了动态批处理，大批量的失败率仍然显著较高。

虽然这个问题可以通过自动扩展轻松解决，但我们在这里选择不探讨该选项。自动扩展会导致不可预测的成本增加，而且考虑到可用的自动扩展配置选项数量众多，很难提供切实可行的见解。

tag并发级别的成功率

并发性（同时处理多个请求的能力）对自托管 Kubernetes 配置的请求成功率既没有显著影响也没有一致性影响，对 AWS SageMaker 的影响也很小，至少在并发级别为 10 的情况下是这样。

tag按 Token 长度的成功率

具有高 token 数量的长段落对 Jina Embedding API 和具有动态批处理的 Kubernetes 的影响与大批量类似：随着大小增加，失败率显著上升。然而，虽然没有动态批处理的自托管解决方案在处理大批量时几乎总是失败，但它们在处理单个长段落时表现更好。至于 SageMaker，长段落长度——就像并发性和批量大小一样——对请求成功率没有明显影响。

tag请求延迟

所有延迟测试都在并发级别 1、5 和 10 下重复进行了五次。响应时间是五次尝试的平均值。请求吞吐量是响应时间（秒）的倒数乘以并发数。

tagJina API

Jina API 的响应时间主要受批量大小的影响，与并发级别无关。虽然段落长度也会影响性能，但其影响并不简单直接。作为一般原则，包含更多数据的请求（无论是通过更大的批量还是更长的段落）都需要更长的处理时间。

并发数 1：

并发 5：

并发 10：

对于单个请求（批大小为 1）：

• 响应时间保持相对稳定，无论段落长度如何，都在约 600-800 毫秒范围内
• 更高的并发（5 或 10 个同时请求）不会显著降低每个请求的性能

对于较大的批量（32 和 128 项）：

• 响应时间显著增加，批大小为 128 时所需时间大约是单个请求的 4-6 倍
• 段落长度对大批量的影响更为明显
• 在高并发（10）和大批量（128）的情况下，这种组合导致响应时间显著延长，最长段落的处理时间接近 18 秒

对于吞吐量：

• 在运行并发请求时，较小的批量通常能实现更好的吞吐量
• 在并发度为 10、批大小为 1 时，系统达到最高吞吐量，约为每秒 15 个请求
• 较大的批量始终显示较低的吞吐量，在多个场景中降至每秒不到 1 个请求

tagAWS SageMaker

AWS SageMaker 测试使用 ml.g5.xlarge 实例进行。

并发 1：

并发 5：

并发 10：

与 Jina API 相比的主要差异：

• 基础性能：SageMaker 在处理小请求时（单个项目、短段落）明显更快 - 约 200 毫秒，而 Jina 需要 700-800 毫秒。
• 扩展行为：
  • 两种服务在处理更大的批量和更长的段落时都会变慢
  • SageMaker 在处理大批量（128）和长段落（1024 token）时显示出更显著的性能下降
  • 在高并发（10）和最大负载（批量 128，1024 token）下，SageMaker 需要约 26 秒，而 Jina 需要约 18 秒
• 并发影响：
  • 两种服务的吞吐量都从增加的并发中受益
  • 两种服务在不同并发级别上保持类似的吞吐量模式
  • 在并发度为 10 时，SageMaker 实现了稍高的峰值吞吐量（17 req/s vs 15 req/s）

tag自托管 Kubernetes 集群

自托管测试在 Amazon 的 Elastic Kubernetes Service 上使用 g5.xlarge 实例进行。

并发度 1：

并发度 5：

并发度 10：

当处理超过 16,384 个 tokens 的请求时，我们的自托管设置会因服务器错误（通常是内存不足）而失败。这与并发度水平无关。因此，这里没有显示更多数据的测试。

高并发度会使响应时间大致呈线性增加：并发度为 5 的响应时间大约是 1 的五倍。并发度为 10 时，响应时间约为十倍。

动态批处理会使小批量的响应时间增加约两秒。这是因为批处理队列在处理未满的批次前会等待 2 秒。然而，对于较大的批量，它在响应时间上带来了适度的改进。

tagToken 吞吐量

在所有平台上，Token 吞吐量都随着批量大小增加、段落长度增加和并发度提高而增加。因此，我们只展示高使用率水平的结果，因为较低水平无法提供有意义的实际性能指标。

所有测试都在并发度为 10 的情况下进行，每个请求 16,384 个 tokens，对五个请求取平均值。我们测试了两种配置：批大小 32 配合 512-token 段落，以及批大小 128 配合 128-token 段落。两种配置的 tokens 总数保持不变。

Token 吞吐量（tokens/秒）：

在高负载条件下，Jina API 的性能显著优于其他方案，而这里测试的自托管解决方案显示出明显较低的性能。

tag每百万 Tokens 成本

成本可能是选择嵌入解决方案时最关键的因素。虽然计算 AI 模型成本可能很复杂，以下是不同选项的比较分析：

tagJina API

该服务采用基于 token 的预付费定价模型，有两个层级：

• 10 亿 tokens 收费 $20（每百万$0.02）- 适合原型开发和开发阶段的入门级价格
• 110 亿 tokens 收费 $200（每百万$0.018）- 更适合大量使用的经济价格

值得注意的是，这些 tokens 可以在 Jina 的整个产品套件中使用，包括 readers、rerankers 和零样本分类器。

tagAWS SageMaker

SageMaker 定价包含每小时实例成本和模型许可费用。使用 ml.g5.xlarge 实例：

• 实例成本：$1.408/小时（美东）或$1.761/小时（欧洲法兰克福）
• jina-embeddings-v3 许可：$2.50/小时
• 总小时成本：$3.908-$4.261 取决于地区

按平均吞吐量 15,044 个 tokens/秒（54.16M tokens/小时）计算，每百万 tokens 的成本在 $0.0723 到$0.0788 之间。

tag使用 Kubernetes 自托管

自托管成本因基础设施选择而异。以 AWS EC2 的 g5.xlarge 实例为例：

• 实例成本：$1.006/小时（美东）或$1.258/小时（欧洲法兰克福）
• jina-embeddings-v3 许可：$5000/季度（$2.282/小时）
• 总小时成本：$3.288-$3.540 取决于地区

以 2,588 个 tokens/秒（9.32M tokens/小时）的速度，每百万 tokens 的成本为 $0.352-$0.379。尽管每小时费率低于 SageMaker，但由于吞吐量较低导致每个 token 的成本更高。

自托管的重要考虑因素：

• 固定成本（许可、基础设施）与使用量无关
• 本地托管仍需要支付许可费和人员成本
• 工作负载变化可能显著影响成本效率

tag关键要点

即使不考虑冷启动时间并假设替代方案达到最佳吞吐量，Jina API 仍然是最具成本效益的解决方案。

对于已有强大基础设施、边际服务器成本较低的组织来说，自托管可能是合理的选择。此外，探索 AWS 以外的云服务提供商可能会获得更好的定价。

但是，对于大多数企业，尤其是寻求一站式解决方案的中小企业来说，Jina API 提供了无与伦比的成本效益。

tag安全和数据隐私考虑

在选择嵌入模型的部署策略时，除了性能和成本考虑外，安全和数据隐私要求可能起到决定性作用。我们提供灵活的部署选项以满足不同的安全需求：

tag云服务提供商

对于已经在使用主流云服务提供商的企业，我们在云市场的产品（如 AWS Marketplace、Azure 和 GCP）在现有安全框架内提供了自然的部署解决方案。这些部署的优势包括：

• 继承云服务提供商的安全控制和合规性
• 可轻松集成现有安全策略和数据治理规则
• 几乎无需更改现有数据处理协议
• 符合既定的数据主权考虑

tag自托管和本地部署

具有严格安全要求或特定监管义务的组织通常更倾向于对其基础设施进行完全的物理控制。我们的自托管选项可以实现：

• 对部署环境的完全控制
• 数据处理完全在您的安全边界内
• 与现有安全监控和控制的集成

要获取我们 CC-BY-NC 模型的商业许可，您首先需要从我们这里获取许可。请随时联系我们的销售团队。

tagJina API 服务

对于试图在安全性、便利性和成本之间取得平衡的初创企业和中小企业，我们的 API 服务提供企业级安全保护，无需增加运营开销：

• SOC2 认证确保强大的安全控制
• 完全符合 GDPR 的数据处理
• 零数据保留政策 - 我们不存储或记录您的请求
• 加密数据传输和安全基础设施

Jina AI 的模型产品使组织能够选择最符合其安全要求的部署策略，同时保持运营效率。

tag选择您的解决方案

下面的流程图总结了您已经看到的所有实证测试和表格的结果：

首先，考虑您的安全需求以及为满足这些需求可以做出多少灵活性的牺牲。

然后，考虑您计划如何在企业中使用 AI：

1. 离线索引和可以优化使用批处理的非时间敏感用例。
2. 需要可靠性和可扩展性的用途，如检索增强生成和 LLM 集成。
3. 时间敏感的用途，如在线搜索和检索。

同时，也要考虑您的内部专业知识和现有基础设施：

1. 您的技术栈是否已经高度依赖云服务？
2. 您是否拥有能够进行自托管的大规模内部 IT 运营？

最后，考虑您预期的数据量。您是否是每天需要使用 AI 模型执行数百万次操作的大规模用户？

tag结论

对于许多 IT 部门来说，将 AI 整合到运营决策中仍是一个未知领域，因为市场缺乏成熟的一站式解决方案。这种不确定性可能使战略规划变得具有挑战性。我们的定量分析旨在为将我们的搜索基础模型整合到您特定的工作流程和应用中提供具体指导。

就单位成本而言，Jina API 是企业可用的最经济选择之一。很少有替代方案能够在提供相comparable功能的同时匹配我们的价位。

我们致力于提供不仅功能强大、用户友好，而且对各种规模的组织都具有成本效益的搜索功能。无论是通过主要云提供商还是自托管部署，我们的解决方案都能满足超出纯成本考虑的最复杂企业需求。这个分析分解了各种成本因素，以帮助您做出决策。

鉴于每个组织都有其独特的需求，我们认识到单篇文章无法涵盖每种情况。如果您有本文未涉及的具体需求，请联系我们，讨论如何最好地支持您的实施。