生产环境部署 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

基于 AWS SageMaker 等云平台部署

🔗: https://aws.amazon.com/marketplace/pp/prodview-kdi3xkt62lo32

通过商业授权，在 Kubernetes 集群中进行自主托管

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

核心评估指标

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

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

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

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

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

对于 Kubernetes 自托管方案，我们重点考察 动态批处理机制 的影响。该机制通过累积请求，直至达到最大处理量(比如jina-embeddings-v3 最大支持 8192 个 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