部署搜尋基礎模型到生產環境的實用指南

在 Jina AI，我們的使命是為企業用戶提供高品質的搜尋解決方案。為達成此目標，我們透過多種管道提供模型使用。然而，為特定使用情境選擇正確的管道可能會有點棘手。在這篇文章中，我們將引導您完成決策過程並分析權衡取捨，根據您的用戶特性和需求，為您提供存取我們搜尋基礎模型的最佳方式之實用指南。

tagJina 搜尋基礎模型

Our Search Foundation Models

We've been moving the needle in search models since day one. Take a look at our model evolution below—hover or click to discover each milestone.

Jina AI

我們的搜尋基礎模型包括：

• Embeddings：將數位物件的資訊轉換為嵌入向量，捕捉其基本特徵。
• Rerankers：對查詢-文件集進行深入的語義分析，以提高搜尋相關性。
• 小型語言模型：包括專門的 SLM，如用於 HTML2Markdown 或資訊提取等特定任務的 ReaderLM-v2。

在這篇文章中，我們將探討 jina-embeddings-v3 的不同部署選項，比較三種主要方式：

• 使用 Jina API
• 透過雲端服務提供商部署，如 AWS SageMaker
• 在商業授權下於 Kubernetes 叢集中自行部署

比較將評估每種方式的成本影響和優勢，幫助您確定最適合您需求的選項。

tag關鍵性能指標

我們在不同使用情境中評估了五個關鍵性能指標：

• 請求成功率：對嵌入伺服器的成功請求百分比
• 請求延遲：嵌入伺服器處理並回傳請求所需的時間
• Token 吞吐量：嵌入伺服器每秒可處理的 Token 數量
• 每 Token 成本：每個文本單位的總處理成本

對於在 Kubernetes 叢集上自行部署的 Jina embeddings，我們還研究了動態批次處理的影響。此功能會將請求排入佇列，直到達到最大批次大小（jina-embeddings-v3 為 8,192）才生成嵌入。

我們特意在分析中排除了兩個重要的性能因素：

• 自動擴展：雖然這對於工作負載變化的雲端部署很重要，但其效果取決於許多變數—硬體效率、網路架構、延遲和實作選擇。這些複雜性超出了我們目前的討論範圍。請注意，Jina API 包含自動擴展，我們的結果反映了這一點。
• 量化：雖然這種技術可以創建更小的嵌入向量並減少數據傳輸，但主要效益來自其他系統組件（數據存儲和向量距離計算）而不是減少數據傳輸。由於我們專注於直接模型使用成本，我們在此分析中省略了量化。

最後，我們將檢視每種方式的財務影響，同時考慮總擁有成本和每 token/每請求的費用。

tag部署設置

我們評估了 jina-embeddings-v3 的三種部署和使用情境：

tag使用 Jina API

所有 Jina AI 嵌入模型都可以通過 Jina API 存取。存取採用預付 token 系統，提供一百萬個 token 供免費測試。我們從德國辦公室通過互聯網進行 API 呼叫來評估性能。

tag使用 AWS SageMaker

Jina Embeddings v3 可供 AWS 使用者通過 SageMaker 使用。使用需要訂閱此模型的 AWS 服務。我們提供了一個 notebook，展示如何使用 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：接收文本段落作為輸入並回傳其嵌入
• /health：提供基本健康監控

我們將其部署為 Amazon Elastic Kubernetes Service 上的 Kubernetes 服務，使用 us-east-1 區域的 g5.xlarge 實例。

有無動態批次處理

我們在 Kubernetes 叢集中以兩種配置測試性能：一種在接收到請求時立即處理，另一種使用動態批次處理。在動態批次處理的情況下，服務會等待直到佇列中收集了 MAX_TOKENS（8192）或達到預定義的 2 秒超時，才調用模型並計算嵌入。這種方法提高了 GPU 使用率並減少了 GPU 記憶體的碎片化。

對於每個部署情境，我們通過變更三個關鍵參數進行測試：

• 批次大小：每個請求包含 1、32 或 128 個文本段落進行嵌入
• 段落長度：我們使用包含 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 tokens）時顯示更明顯的減速
  • 在高併發（10）且最大負載（批次 128、1024 tokens）時，SageMaker 需要約 26 秒，而 Jina 需要約 18 秒
• 併發性影響：
  • 兩種服務的吞吐量都從增加的併發數中受益
  • 兩者在不同併發級別下都保持類似的吞吐量模式
  • SageMaker 在並發數 10 時可達到略高的峰值吞吐量（17 req/s vs 15 req/s）

tag自託管 Kubernetes 叢集

自託管測試是在 Amazon 的 Elastic Kubernetes Service 上使用 g5.xlarge 執行個體進行的。

並發數 1：

並發數 5：

並發數 10：

當處理超過 16,384 個 token 的請求時，我們的自託管設置會出現伺服器錯誤，通常是記憶體不足錯誤。這種情況與並發級別無關。因此，不顯示超過該數據量的測試結果。

高並發會大致線性地增加回應時間：並發級別 5 的回應時間大約是 1 的五倍。並發級別 10 則是十倍。

動態批處理會使小批量的回應時間增加約 2 秒。這是因為批處理佇列會等待 2 秒才處理未滿的批次。然而，對於較大的批次大小，它可以帶來適度的回應時間改善。

tagToken 吞吐量

在所有平台上，Token 吞吐量都會隨著批次大小增加、段落長度增加和並發級別提高而增加。因此，我們只呈現高使用量級別的結果，因為較低級別無法提供有意義的實際性能指標。

所有測試都在並發級別 10 下進行，每個請求 16,384 個 token，取五次請求的平均值。我們測試了兩種配置：批次大小 32 配合 512 token 段落，以及批次大小 128 配合 128 token 段落。兩種配置的總 token 數保持不變。

Token 吞吐量（每秒 token 數）：

在高負載條件下，Jina API 的性能明顯優於其他選擇，而這裡測試的自託管解決方案顯示出明顯較低的性能。

tag每百萬 Token 成本

成本可能是選擇嵌入解決方案時最關鍵的因素。雖然計算 AI 模型成本可能很複雜，以下是不同選項的比較分析：

tagJina API

該服務採用基於 token 的定價模式，提供兩種預付層級：

• 10 億 token 收費 $20（每百萬$0.02）- 適合原型設計和開發的入門費率
• 110 億 token 收費 $200（每百萬$0.018）- 更適合大量使用的經濟費率

值得注意的是，這些 token 可以在 Jina 的整個產品套件中使用，包括閱讀器、重新排序器和零樣本分類器。

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 是企業可用的最經濟選項之一。很少有替代方案能在提供相似功能的同時達到我們的價格水準。

我們致力於提供不僅強大且易用，而且對各種規模的組織來說都具有成本效益的搜尋功能。無論是通過主要雲端供應商還是自行託管的部署，我們的解決方案都能滿足超越純粹成本考量的最複雜企業需求。本分析分解了各種成本因素，以協助您的決策。

鑑於每個組織都有其獨特的需求，我們認識到單一文章無法涵蓋所有情況。如果您有本文未涵蓋的特定需求，請聯繫我們討論如何最佳支援您的實施。