原创 Jina AI 2025-02-11 12:43 北京
在生产环境下部署，到底选哪种方案最优？
想要打造更好的搜索体验？选择合适的部署方案是关键。Jina AI 针对不同业务场景，提供了多种模型接入方式。
本文将详细介绍各种部署方案，分析它们的优缺点，并结合实际业务场景，给出更实用的最佳实践建议，帮你快速找到最合适的方案。
Jina 搜索底座模型概览
我们的搜索底座模型(Jina AI Search Foundation Models)包括：
Embedding 模型：通过向量空间映射，将数字对象转化为蕴含语义特征的向量表示
Reranker 模型：通过深入的语义分析，优化搜索结果的相关性排序。
小型语言模型（Small Language Models, SLM）：例如针对 HTML 转 Markdown、信息提取等特定场景的 ReaderLM-v2。
本文将以 jina-embeddings-v3 为例，重点介绍以下三种部署方案：
直接通过 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 区域的 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：
与 Jina API 相比，SageMaker 主要有以下不同：
基础性能：在处理小请求时，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 总数保持不变。
批大小为 32，每个文本段落为 512 Token。
批大小为 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 美元），更适合大规模应用场景。
这些 token 可以在 Jina AI 的整个产品生态中使用，例如 Readers、Rerankers 和零样本分类器等，可以用这些即插即用的套件，构建出更强大的搜索应用。
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
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 的模型产品，让你可以根据自己的安全需求，灵活选择部署方案。
如何选择最适合你的方案？
我们综合之前的测试和数据，做了这张流程图，帮你理清思路：
希望这张图能让你更清楚地知道，选择方案时应该关注哪些方面。
总结一下，选择方案时，主要看以下几个方面：
安全需求与灵活性：您对数据安全性有多高的要求？为了满足这些安全需求，您愿意在灵活性上做出多大的妥协？
AI 的应用场景：您计划如何将 AI 应用于您的业务中？
场景一：离线索引和非实时性任务：这类场景可以考虑采用批处理优化，提高资源利用率。
场景二：需要高可靠性和可扩展性的场景：例如检索增强生成（RAG）和 LLM 集成等。
场景三：对时延有较高要求的场景：例如在线搜索和实时检索等。
内部技术能力与现有基础设施：您是否具备相应的技术实力和基础设施来支撑特定方案？
您的技术栈是否已经高度依赖云服务？如果是，选择云服务部署可能更方便。
您是否拥有一支能够进行大规模自托管的专业运维团队？
数据规模：您预计每天需要使用模型执行多少次操作？如果数据规模巨大，可能需要考虑高吞吐量的解决方案。
结论
目前，对于许多 IT 部门来说，将 AI 整合到运营决策中仍然是一个相对较新的领域。市场上虽然不乏解决方案，但真正成熟且全面的“一站式”服务还比较稀缺。这种不确定性难免给战略规划带来挑战。因此，我们希望通过本次定量分析，为您提供一份更具参考价值的指南，帮助您将我们的搜索底模型整合到您特定的工作流程和应用中。
从单位成本角度来看，Jina API 无疑是企业最经济的选择之一。在提供同等功能的前提下，很少有其他方案能够达到我们这样的价格水平。这也是我们希望能让更多企业更容易接触到先进 AI 搜索技术的一种尝试。
Jina AI 致力于提供功能强大、易于使用，并且能够满足各种规模组织成本效益需求的搜索解决方案。无论是选择通过主流云服务商快速上手，还是选择自托管部署以获得更高的自主性，我们的解决方案都力求满足企业在成本之外的更复杂需求。本次分析详细拆解了各种成本因素，目的正是为了帮助您更好地评估并做出最适合的决策。
当然，每个组织都有其独特的需求，我们深知一篇文章无法覆盖所有情况。如果您在阅读本文后，仍然有未解决的具体需求，或者有任何疑问，欢迎随时与我们联系(sales@jina.ai)，我们将竭诚为您提供支持，共同探讨最佳的实施方案。期待与您携手，共同探索 AI 搜索的更多可能性。
