生产环境部署 Jina AI 搜索底座模型的实战指南

想要打造更好的搜索体验？选择合适的部署方案是关键。Jina AI 针对不同业务场景，提供了多种模型接入方式。

本文将详细介绍各种部署方案，分析它们的优缺点，并结合实际业务场景，给出更实用的最佳实践建议，帮你快速找到最合适的方案。

Jina 搜索底座模型概览

我们的搜索底座模型(Jina AI Search Foundation Models)包括：

• Embedding 模型：通过向量空间映射，将数字对象转化为蕴含语义特征的向量表示
• Reranker 模型：通过深入的语义分析，优化搜索结果的相关性排序。
• 小型语言模型（Small Language Models, SLM）：例如针对 HTML 转 Markdown、信息提取等特定场景的 ReaderLM-v2。

本文将以 jina-embeddings-v3 为例，重点介绍以下三种部署方案：

1. 直接通过 Jina API 调用
?: https://jina.ai/api-dashboard
2. 基于 AWS SageMaker 等云平台部署
?: https://aws.amazon.com/marketplace/pp/prodview-kdi3xkt62lo32
3. 通过商业授权，在 Kubernetes 集群中进行自主托管

接下来，我们将从功能与成本两个方面，全面对比这三个方案，希望能为你在技术选型时提供参考。

核心评估指标

针对不同的部署场景，我们设定了五项关键性能指标：

• 请求成功率：服务器成功响应请求的比例。

• 响应延迟：从发送请求到获取结果所花费的总时间。

• Token 吞吐量：每秒处理的 token 数量

• Token 成本：单个 token 的处理成本

本次评估暂不包括以下因素：

• 弹性伸缩：其效果受到硬件配置、网络架构等多因素的影响，需要单独评估（注：Jina API 已经内置了自动伸缩）。
• 量化压缩：它主要用于存储和计算，与模型直接使用成本关联不大。

最后，我们将综合总拥有成本（TCO）和单次请求费用，进行全面的成本分析。

部署配置说明

我们对 jina-embeddings-v3 的三种部署方式进行了实际测试：

方案 1：Jina API 直连

通过 Jina API 可以直接调用所有 Embedding 模型，采用预付费模式，并赠送了百万 Token 的测试额度。性能测试基于德国节点，通过公网发起 API 调用。

方案 2：AWS SageMaker 部署

用户可以通过 AWS Marketplace 订阅部署服务，我们提供了实战指南供你参考。

?: https://github.com/jina-ai/jina-sagemaker/blob/main/notebooks/Real-time%20embedding.ipynb

测试环境选择了美东 1 区的 ml.g5.xlarge 实例，另外，我们的模型也在 Microsoft Azure 和 Google Cloud Platform 上线了，在这些云平台上模型的表现是近似的。

方案 3：Kubernetes 自托管

【说明】：商业授权需要联系销售团队获取: https://jina.ai/api-dashboard/license-config

我们构建了一个基于 FastAPI 的服务应用，通过 HuggingFace 加载模型，并将其部署在 Amazon EKS 集群中，使用同区域同规格的 g5.xlarge 实例。该服务提供两个接口：

• /embed：文本向量化处理。
• /health：服务健康监测。

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

动态批处理优化

在 Kubernetes 集群中，我们对比测试了两种运行模式：实时处理和动态批处理。后者是通过累积请求至 MAX_TOKENS 8192 Token，或者等待预定义的 2 秒超时，才会调用模型并计算 embeddings。从而显著提高 GPU 利用率，并减少显存碎片。

• 单次请求量：每个请求包含 1、32 或 128 个文本段落
• 段落长度：使用包含了 128、512 或 1,024 个 token 的文本段落
• 并发压力：同时发送 1、5 或 10 个请求

基准测试结果

下表汇总了我们在不同使用场景下的测试结果，数据是多次测试后取的平均值。

请求成功率

从测试结果来看，各方案的请求成功率表现差异很大。其中，SageMaker 几乎完美（99.9%），而自托管方案只有 55%-58% 的成功率。要想在生产环境里达到接近 100% 的可靠性，自托管方案还得解决不少问题。主要原因有这几个：

• 网络环境：云计算环境总会有一些网络波动。

• 资源竞争：在高负载情况下，抢 GPU 内存可能导致请求失败。

• 超时机制：为了保证系统健康，我们需要设置超时时间，但也可能导致部分请求超时失败。

按批量大小划分的成功率

在自托管的 Kubernetes 环境里，我们发现批量越大，越容易内存溢出。 在没开动态批处理时，包含 32 个或 128 个项目的批量请求会因为内存不足而全部失败。即使开了动态批处理，大批量的失败率也明显高于小批量。

虽然自动扩容能缓解这个问题，但配置比较复杂，成本也会增加，很难提供切实可行的指导，我们在此暂不深入探讨。

并发级别的成功率

测试结果表明，并发数（同时处理请求的数量）对自托管 Kubernetes 环境的请求成功率没有明显影响。AWS SageMaker 也一样，至少在并发数为 10 的情况下，影响很小。

按 Token 长度的成功率

与大批量的情况类似，如果请求中包含大量 token 的长文本段落，也会对 Jina Embedding API 和启用了动态批处理的 Kubernetes 产生负面影响：token 数量越多，请求失败率越高。

但是，没开动态批处理的自托管方案在处理单个长文本段落时，反而比其他方案好。SageMaker 的话，段落长度（和并发数、批量大小一样）对请求成功率影响比较小。

请求延迟

我们在并发级别为 1、5 和 10 的情况下，对所有方案进行了多次延迟测试，结果取平均值。请求吞吐量则通过响应时间（秒）的倒数乘以并发数计算得出。

Jina API

用 Jina API 时，响应时间主要取决于批量大小（Batch Size），也就是每个请求中包含多少个文本段落，与并发请求的数量关系不大。文本段落的长度也会影响性能，但不是线性关系，比较复杂。

总的来说，无论是增加每个请求的批量大小，还是增加每个段落的长度，只要请求中包含的数据量越大，所需的处理时间就越长。

并发 1：

并发 5：

并发 10：

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

• 响应时间相对稳定，基本维持在 600-800 毫秒之间，受段落长度的影响较小。
• 即使在高并发请求的情况下，比如 5 或 10 个同时请求，单个请求的性能也不会受到明显影响。

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

• 响应时间显著增加。当批量大小为 128 时，处理时间大约是单个请求的 4-6 倍。

• 文本段落长度对大批量请求的影响更为明显。

• 在高并发（10）和大批量（128）的情况下，响应时间显著延长，最长段落的处理时间接近 18 秒

对于吞吐量：

• 并发请求时，批量越小，吞吐量越高。
• 在并发度为 10、批大小为 1 时，系统达到最高吞吐量，约为每秒 15 个请求
• 批量越大，吞吐量越低，有些场景甚至不到每秒 1 个请求。

AWS SageMaker

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

并发 1：

并发 5：

并发 10：

• 基础性能：在处理小请求时，SageMaker 明显快很多，大约只需 200 毫秒，而 Jina API 需要 700-800 毫秒。

• 负载能力：

• 在处理较大批量或较长文本段落时，两种服务性能都会有所下降。

• SageMaker 在处理大批量（128 个项目）和长文本段落（1024 个 Token）时，性能下降更明显。

• 在高并发（10）和最大负载（批量 128，1024 token）下，SageMaker 需要约 26 秒，而 Jina 需要约 18 秒。

• 并发影响：

• 两种服务的吞吐量都随着并发请求数的增加而提高。

• 两种服务在不同并发级别下的吞吐量模式相似。

• 在并发度为 10 时，SageMaker 实现了稍高的峰值吞吐量，达到 17 req/s，而 Jina API 为 15 req/s。

自托管 Kubernetes 集群

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

并发度 1：

并发度 5：

并发度 10：

上图第三行的异常结果，是因为动态批处理的 2 秒超时机制。在高并发（10 个并发请求）且每个请求发送 1024 个 Token 时，请求队列会很快填满，批处理系统无需等待超时即可开始处理。但在较低的并发和请求大小下，系统需要等待超时，相当于每个请求都额外增加了 2 秒的延迟。这种现象在未经优化的批处理实现中比较常见。

此外，我们的自托管集群在处理超过 16384 个 Token 的请求时，经常会因为服务器错误（通常是内存溢出）而失败，并且这种现象与并发请求的数量无关。因此，我们没有展示更大规模数据的测试结果。

从整体趋势来看，在高并发场景下，响应时间会大致呈线性增长：并发度为 5 的响应时间大约是 1 的五倍。并发度为 10 时，响应时间约为十倍。

动态批处理机制对不同大小的请求也存在不同的影响。对于小批量请求，由于需要等待超时，动态批处理实际上会导致响应时间增加约 2 秒。但对于大批量请求，动态批处理在一定程度上能够提升响应速度。

Token 吞吐量

一般来说，在所有测试平台上，Token 吞吐量都会随着批量大小、文本段落长度以及并发请求数量的增加而提升。考虑到低负载条件下的测试数据对于实际应用价值有限，因此我们只展示了高负载场景下的性能测试结果。

所有测试都在并发数为 10 的情况下进行，每个请求 16384 个 tokens，对五个请求取平均值。我们测试了两种配置，两种配置的 tokens 总数保持不变。

1. 批大小为 32，每个文本段落为 512 Token。
2. 批大小为 128，每个文本段落为 128 Token。

Token 吞吐量（tokens/秒）：

最终的测试结果表明，在高负载条件下，Jina API 的性能明显优于其他部署方案。相比之下，我们所测试的自托管解决方案则表现出明显的性能劣势。

每百万 Tokens 成本

成本可能是选择解决方案时最重要的因素。我们对不同方案的成本做了对比分析：

Jina API

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

• 入门级：10 亿 Token 收费 20 美元（即每百万 Token 0.02 美元），适合原型开发和项目初期阶段使用。

• 经济级：110 亿 Token 收费 200 美元（即每百万 Token 0.018 美元），更适合大规模应用场景。

AWS SageMaker

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

• 实例费用：每小时 1.408 美元（美国东部）或 1.761 美元（欧洲法兰克福）。
• jina-embeddings-v3 许可费用：每小时 2.50 美元。
• 总计小时费用：根据不同地区，每小时 3.908 美元或 4.261 美元。

假设平均吞吐量为每秒 15,044 个 Token（即每小时 5416 万个 Token），则每百万 Token 的成本大约在 0.0723 美元到 0.0788 美元之间。

使用 Kubernetes 自托管

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

• 实例费用：每小时 1.006 美元（美国东部）或 1.258 美元（欧洲法兰克福）。
• jina-embeddings-v3 许可费用：每季度 5000 美元（折合每小时 2.282 美元）。
• 总计小时费用：根据不同地区，每小时 3.288 美元或 3.540 美元。

假设平均吞吐量为每秒 2,588 个 Token（即每小时 932 万个 Token），则每百万 Token 的成本大约在 0.352 美元到 0.379 美元之间。尽管自托管方案的每小时费用低于 SageMaker，但由于吞吐量较低，导致每个 Token 的成本反而更高。

选择自托管方案时，要考虑这些因素：

• 固定成本：许可费用和基础设施费用均为固定成本，不会随着使用量的变化而变化。
• 额外成本：即使采用本地托管，也需要支付许可费用和人员维护成本。
• 工作负载变化：工作负载的波动会对自托管方案的成本效益产生显著影响。

划重点：选哪个最值？

就算不考虑冷启动，而且假设每个方案都跑到了极限，还是 Jina API 最划算。

如果企业已经有现成的基础设施，新增服务器也不贵，那自托管可以考虑。另外，要是使用 AWS 以外的云服务商，也许能拿到更低的价格。

对大多数公司，特别是想要省心又好用一站式服务的中小企业来说，选 Jina API 肯定没错，因为它最兼顾成本和性能。

安全和数据隐私

对于企业来说，安全和数据隐私绝对是重中之重。考虑到了各种客户的安全需求，我们也提供了灵活的部署选项，保证企业用得安心。

云服务提供商

如果企业已经在用 AWS、Azure 或 GCP 这些云服务提供商，那在它们的应用商店里部署我们的模型就太方便了，可以说是无缝衔接。

• AWS Marketplace：https://aws.amazon.com/marketplace/pp/prodview-kdi3xkt62lo32
• Azure：https://azuremarketplace.microsoft.com/en-us/marketplace/apps/jinaai.jina-embeddings-v3-vm?tab=Overview
• GCP：https://console.cloud.google.com/marketplace/browse?hl=en&inv=1&invt=AboIuQ&q=jina

具体好处有：

• 直接沿用云服务商的安全控制和合规性标准。

• 直接集成到您现有的安全和数据体系里。

• 几乎不用修改现有的数据处理流程。

• 符合各种数据合规的要求。

自托管和本地部署

有些公司对安全要求特别严格，或者受到某些法规限制，那必须自己掌控基础设施才行。我们的自托管方案就能帮你：

• 完全掌控部署环境。

• 数据处理都在你的安全范围里。

• 合现有的安全监控体系无缝对接。

如果需要获取我们 CC-BY-NC 模型的商业许可，请务必提前联系我们的销售团队进行申请：? https://jina.ai/api-dashboard/license-config

Jina API 服务

如果是初创公司或者中小企业，想在安全、方便和成本之间找个平衡点，那我们的 API 服务就非常适合你！它不仅有企业级的安全保障，还不用你操心运维。

• 通过了 SOC2 认证，有强大的安全性保障。
• 符合 GDPR 数据规范。
• 我们承诺零数据留存，绝不会存储或记录客户的任何请求。
• 加密传输 + 安全基础设施的双重保险。

Jina AI 的模型产品，让你可以根据自己的安全需求，灵活选择部署方案。

如何选择最适合你的方案？

我们综合之前的测试和数据，做了这张流程图，帮你理清思路：

希望这张图能让你更清楚地知道，选择方案时应该关注哪些方面。

总结一下，选择方案时，主要看以下几个方面：

1. 安全需求与灵活性：您对数据安全性有多高的要求？为了满足这些安全需求，您愿意在灵活性上做出多大的妥协？
2. AI 的应用场景：您计划如何将 AI 应用于您的业务中？

• 场景一：离线索引和非实时性任务：这类场景可以考虑采用批处理优化，提高资源利用率。
• 场景二：需要高可靠性和可扩展性的场景：例如检索增强生成（RAG）和 LLM 集成等。
• 场景三：对时延有较高要求的场景：例如在线搜索和实时检索等。

1. 内部技术能力与现有基础设施：您是否具备相应的技术实力和基础设施来支撑特定方案？

• 您的技术栈是否已经高度依赖云服务？如果是，选择云服务部署可能更方便。
• 您是否拥有一支能够进行大规模自托管的专业运维团队？

1. 数据规模：您预计每天需要使用模型执行多少次操作？如果数据规模巨大，可能需要考虑高吞吐量的解决方案。

结论

目前，对于许多 IT 部门来说，将 AI 整合到运营决策中仍然是一个相对较新的领域。市场上虽然不乏解决方案，但真正成熟且全面的“一站式”服务还比较稀缺。这种不确定性难免给战略规划带来挑战。因此，我们希望通过本次定量分析，为您提供一份更具参考价值的指南，帮助您将我们的搜索底模型整合到您特定的工作流程和应用中。

从单位成本角度来看，Jina API 无疑是企业最经济的选择之一。在提供同等功能的前提下，很少有其他方案能够达到我们这样的价格水平。这也是我们希望能让更多企业更容易接触到先进 AI 搜索技术的一种尝试。

Jina AI 致力于提供功能强大、易于使用，并且能够满足各种规模组织成本效益需求的搜索解决方案。无论是选择通过主流云服务商快速上手，还是选择自托管部署以获得更高的自主性，我们的解决方案都力求满足企业在成本之外的更复杂需求。本次分析详细拆解了各种成本因素，目的正是为了帮助您更好地评估并做出最适合的决策。

当然，每个组织都有其独特的需求，我们深知一篇文章无法覆盖所有情况。