実践的な検索基盤モデルの本番環境へのデプロイメントガイド

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：デジタルオブジェクトの情報を embedding ベクトルに変換し、その本質的な特徴を捉えます。
• Rerankers：クエリとドキュメントのセットの詳細な意味分析を行い、検索の関連性を向上させます。
• Small language models：HTML2Markdown や情報抽出などのニッチなタスク向けの専門的な SLM として ReaderLM-v2 などがあります。

この投稿では、jina-embeddings-v3 の異なるデプロイメントオプションを検討し、3つの主要なアプローチを比較します：

• Jina API の使用
• AWS SageMaker などの CSP を介したデプロイ
• 商用ライセンスでの Kubernetes クラスターでのセルフホスティング

この比較では、各アプローチのコストへの影響とメリットを評価し、ニーズに最も適したオプションを判断するのに役立てます。

tag主要なパフォーマンス指標

様々な使用シナリオにおいて、5つの重要なパフォーマンス指標を評価しました：

• リクエスト成功率：embedding サーバーへのリクエストの成功率
• リクエストレイテンシー：embedding サーバーがリクエストを処理して返すまでの時間
• トークン処理量：embedding サーバーが1秒間に処理できるトークン数
• トークンあたりのコスト：テキスト単位あたりの総処理コスト

Kubernetes クラスターでセルフホストされた Jina embeddings については、ダイナミックバッチングの影響も調査しました。この機能は、最大バッチサイズ（jina-embeddings-v3 では 8,192）に達するまでリクエストをキューに入れてから embeddings を生成します。

分析から意図的に除外した2つの重要なパフォーマンス要因があります：

• オートスケーリング：これは変動するワークロードを持つクラウドデプロイメントにとって重要ですが、その効果はハードウェアの効率性、ネットワークアーキテクチャ、レイテンシー、実装の選択など、多くの変数に依存します。この複雑さは現在の範囲を超えています。Jina API には自動スケーリングが含まれており、結果にはこれが反映されています。
• 量子化：この技術は小さな embedding ベクトルを作成しデータ転送を削減しますが、主な利点はデータ転送の削減ではなく、他のシステムコンポーネント（データストレージとベクトル距離計算）から得られます。モデル使用コストに焦点を当てているため、この分析では量子化を除外しました。

最後に、総所有コストとトークン/リクエストあたりの費用の両方を考慮して、各アプローチの財務的影響を検討します。

tagデプロイメントのセットアップ

jina-embeddings-v3 について、3つのデプロイメントと使用シナリオを評価しました：

tagJina API の使用

すべての Jina AI embedding モデルは Jina API を通じてアクセス可能です。アクセスはプリペイドトークンシステムで動作し、テスト用に100万トークンが無料で提供されます。ドイツのオフィスからインターネット経由で API 呼び出しを行いパフォーマンスを評価しました。

tagAWS SageMaker の使用

Jina Embeddings v3 は AWS ユーザー向けに SageMaker を通じて利用可能です。使用には、このモデルへの AWS サブスクリプションが必要です。サンプルコードとして、AWS アカウントで Jina AI モデルをサブスクライブし使用する方法を示すノートブックを提供しています。

モデルは Microsoft Azure や Google Cloud Platform でも利用可能ですが、テストは AWS に焦点を当てました。他のプラットフォームでも同様のパフォーマンスが期待できます。すべてのテストは us-east-1 リージョンの ml.g5.xlarge インスタンスで実行されました。

tagKubernetes でのセルフホスティング

SentenceTransformer ライブラリを使用して HuggingFace から jina-embeddings-v3 をロードする FastAPI アプリケーションを Python で構築しました。アプリには2つのエンドポイントがあります：

• /embed：テキスト文を入力として受け取り、その embeddings を返します
• /health：基本的なヘルスモニタリングを提供します

これを us-east-1 の g5.xlarge インスタンスを使用して、Amazon の Elastic Kubernetes Service 上の Kubernetes サービスとしてデプロイしました。

ダイナミックバッチングの有無

Kubernetes クラスターでのパフォーマンスを2つの構成でテストしました：受信時に各リクエストを即時処理する場合と、ダイナミックバッチングを使用する場合です。ダイナミックバッチングの場合、サービスは MAX_TOKENS（8192）がキューに集まるか、あらかじめ定義された2秒のタイムアウトに達するまで待機してから、モデルを呼び出して embeddings を計算します。このアプローチにより、GPU の利用率が向上し、GPU メモリの断片化が減少します。

各デプロイメントシナリオで、3つの主要なパラメータを変更してテストを実行しました：

• バッチサイズ：各リクエストには1、32、または128のテキスト文が embedding 用に含まれます
• 文の長さ：128、512、または1,024トークンを含むテキスト文を使用しました
• 同時リクエスト数：1、5、または10のリクエストを同時に送信しました

tagベンチマーク結果

以下の表は、上記の3つの変数のすべての設定を平均した各使用シナリオの結果の要約です。

tagリクエスト成功率

テストでの成功率は、SageMaker のほぼ完全な99.9%からセルフホストソリューションの56-58%まで幅があり、プロダクションシステムで100%の信頼性を達成することが依然として困難であることを示しています。これには3つの主要な要因があります：

• ネットワークの不安定性により、クラウド環境でも避けられない障害が発生します
• 特に GPU メモリのリソース競合により、負荷時にリクエストが失敗します
• システムの健全性を維持するために、必要なタイムアウト制限により一部のリクエストは失敗する必要があります

tagバッチサイズ別の成功率

セルフホストされた Kubernetes 構成では、大きなバッチサイズが頻繁にメモリ不足エラーを引き起こします。ダイナミックバッチングがない場合、32または128アイテムを含むバッチのすべてのリクエストがこの理由で失敗しました。ダイナミックバッチングを実装しても、大きなバッチの失敗率は依然として著しく高いままでした。

この問題は自動スケーリングで簡単に解決できますが、ここではその選択肢を検討しませんでした。自動スケーリングは予測不可能なコスト増加につながり、また、利用可能な自動スケーリング設定オプションが非常に多いため、実用的な洞察を提供するのが難しいためです。

tag同時実行レベル別の成功率

同時実行（複数のリクエストを同時に処理する能力）は、セルフホスト型 Kubernetes 構成ではリクエスト成功率に強い影響も一貫した影響も与えませんでした。AWS SageMaker でも、少なくとも同時実行レベル 10 までは、最小限の影響しかありませんでした。

tagトークン長別の成功率

トークン数の多い長いパッセージは、Jina Embedding API と動的バッチング付きの Kubernetes の両方に対して、大きなバッチと同様の影響を与えます：サイズが大きくなるにつれて、失敗率が大幅に上昇します。ただし、動的バッチングのないセルフホストソリューションは大きなバッチでほぼ必ず失敗する一方で、個々の長いパッセージではより良いパフォーマンスを示します。SageMaker に関しては、同時実行とバッチサイズと同様に、パッセージの長さもリクエスト成功率に顕著な影響を与えませんでした。

tagリクエストレイテンシー

すべてのレイテンシーテストは、同時実行レベル 1、5、10 で 5 回繰り返されました。応答時間は 5 回の試行の平均値です。リクエストスループットは、秒単位の応答時間の逆数に同時実行数を掛けたものです。

tagJina API

Jina API の応答時間は、同時実行レベルに関係なく、主にバッチサイズの影響を受けます。パッセージの長さもパフォーマンスに影響を与えますが、その影響は単純ではありません。一般的な原則として、より大きなバッチサイズやより長いパッセージのいずれかによってデータ量が多いリクエストは、処理に時間がかかります。

同時実行 1：

Concurrency 5：

Concurrency 10：

個別リクエスト（バッチサイズ 1）の場合：

• レスポンス時間は比較的安定しており、パッセージの長さに関係なく約 600-800ms の範囲を維持
• 高い同時実行性（5 または 10 の同時リクエスト）でもリクエストごとのパフォーマンスは大きく低下しない

大きなバッチ（32 および 128 アイテム）の場合：

• レスポンス時間が大幅に増加し、バッチサイズ 128 では単一リクエストの約 4-6 倍の時間がかかる
• パッセージの長さの影響は、より大きなバッチでより顕著になる
• 高い同時実行性（10）と大きなバッチ（128）の組み合わせでは、最も長いパッセージで約 18 秒のレスポンス時間に達する

スループットについて：

• 小さなバッチは一般的に同時リクエストを実行する際により良いスループットを達成
• 同時実行性 10 でバッチサイズ 1 の場合、システムは約 15 リクエスト/秒の最高スループットを達成
• より大きなバッチでは一貫してスループットが低下し、いくつかのシナリオでは 1 リクエスト/秒未満に低下

tagAWS SageMaker

AWS SageMaker のテストは ml.g5.xlarge インスタンスで実行されました。

Concurrency 1：

Concurrency 5：

Concurrency 10：

Jina API との主な違い：

• 基本パフォーマンス：SageMaker は小さなリクエスト（単一アイテム、短いパッセージ）に対して大幅に高速で、Jina の 700-800ms に対して約 200ms
• スケーリング動作：
  • 両サービスとも大きなバッチと長いパッセージで速度が低下
  • SageMaker は大きなバッチ（128）と長いパッセージ（1024 トークン）でより劇的な速度低下を示す
  • 高い同時実行性（10）で最大負荷（バッチ 128、1024 トークン）の場合、SageMaker は約 26 秒、Jina は約 18 秒
• 同時実行性の影響：
  • 両サービスともスループットは同時実行性の増加から恩恵を受ける
  • 両サービスとも同時実行性レベル全体で同様のスループットパターンを維持
  • SageMaker は若干高いピークスループット（同時実行数10で17リクエスト/秒 対 15リクエスト/秒）を達成します

tag自己ホスト型 Kubernetes クラスター

自己ホストのテストは、g5.xlargeインスタンスを使用してAmazon の Elastic Kubernetes Serviceで実施されました。

同時実行数 1：

同時実行数 5：

同時実行数 10：

16,384トークンを超えるリクエストが与えられた場合、自己ホスティングのセットアップは通常メモリ不足のサーバーエラーで失敗しました。これは同時実行レベルに関係なく発生しました。そのため、それ以上のデータでのテストは表示されていません。

高い同時実行数は応答時間をおおむね線形に増加させました：同時実行数5は1の場合と比べて約5倍の応答時間がかかり、10の場合は10倍かかりました。

動的バッチングは小さなバッチでは応答時間を約2秒遅くします。これは、バッチングキューが不完全なバッチを処理する前に2秒待つためで予想された結果です。しかし、より大きなバッチサイズでは、応答時間に適度な改善をもたらします。

tagトークンスループット

トークンスループットは、すべてのプラットフォームでバッチサイズが大きくなり、パッセージ長が長くなり、同時実行レベルが高くなるにつれて増加します。そのため、実際の性能を意味のある形で示すために、高負荷レベルでの結果のみを提示します。

すべてのテストは同時実行数10で、リクエストあたり16,384トークン、5回のリクエストの平均で実施されました。バッチサイズ32で512トークンのパッセージ、およびバッチサイズ128で128トークンのパッセージという2つの構成をテストしました。総トークン数は両構成で一定です。

トークンスループット（トークン/秒）：

高負荷条件下では、Jina API は代替手段を大きく上回る性能を示し、ここでテストした自己ホストソリューションは大幅に低い性能を示しました。

tag100万トークンあたりのコスト

コストは埋め込みソリューションを選択する際の最も重要な要因と言えるでしょう。AI モデルのコスト計算は複雑になり得ますが、以下に異なるオプションの比較分析を示します：

tagJina API

このサービスは2つの前払いティアを持つトークンベースの価格モデルに従っています：

• 10億トークンで$20（100万あたり$0.02）- プロトタイピングと開発に適したエントリーレベルのレート
• 110億トークンで$200（100万あたり$0.018）- より大きなボリューム向けの経済的なレート

これらのトークンは、リーダー、リランカー、ゼロショット分類器を含むJinaの製品スイート全体で使用できることに注目する価値があります。

tagAWS SageMaker

SageMaker の料金は、インスタンスの時間単価とモデルのライセンス料金を組み合わせたものです。ml.g5.xlarge インスタンスの場合:

• インスタンス料金: $1.408/時間 (US East) または$1.761/時間 (EU Frankfurt)
• jina-embeddings-v3 ライセンス: $2.50/時間
• 総時間単価: 地域によって $3.908-$4.261

平均スループット 15,044 トークン/秒 (54.16M トークン/時間) の場合、100万トークンあたりのコストは $0.0723 から$0.0788 の範囲となります。

tagKubernetes によるセルフホスティング

セルフホスティングのコストは、インフラの選択によって大きく異なります。AWS EC2 の g5.xlarge インスタンスを例にとると：

• インスタンス料金: $1.006/時間 (US East) または$1.258/時間 (EU Frankfurt)
• jina-embeddings-v3 ライセンス: $5000/四半期 ($2.282/時間)
• 総時間単価: 地域によって $3.288-$3.540

2,588 トークン/秒 (9.32M トークン/時間) のスループットでは、100万トークンあたりのコストは $0.352-$0.379 となります。時間単価は SageMaker より低いものの、スループットが低いため、トークンあたりのコストは高くなります。

セルフホスティングに関する重要な考慮事項：

• 固定費用（ライセンス、インフラ）は使用量に関係なく発生
• オンプレミスのホスティングでもライセンス料金とスタッフコストが必要
• 変動する作業負荷がコスト効率に大きく影響する可能性がある

tag重要なポイント

Jina API は、コールドスタート時間を考慮せず、代替案の最適なスループットを想定しても、最もコスト効率の良いソリューションとして浮上します。

既存の堅牢なインフラを持ち、サーバーの限界費用が最小限である組織では、セルフホスティングが意味を持つかもしれません。また、AWS 以外のクラウドプロバイダーを検討することで、より良い価格を得られる可能性もあります。

ただし、特に即座に使える解決策を求める中小企業にとっては、Jina API が比類のないコスト効率を提供します。

tagセキュリティとデータプライバシーに関する考慮事項

埋め込みモデルのデプロイメント戦略を選択する際、パフォーマンスとコストの考慮事項に加えて、セキュリティとデータプライバシーの要件が決定的な役割を果たす場合があります。私たちは異なるセキュリティニーズに対応する柔軟なデプロイメントオプションを提供しています：

tagクラウドサービスプロバイダー

主要なクラウドプロバイダーとすでに連携している企業向けに、クラウドマーケットプレイスの提供（AWS Marketplace、Azure、GCP）で、既存のセキュリティフレームワーク内でのデプロイメントを自然な形で実現できます。これらのデプロイメントには以下の利点があります：

• CSP との関係からのセキュリティ制御とコンプライアンスの継承
• 既存のセキュリティポリシーとデータガバナンスルールとの容易な統合
• 既存のデータ処理契約の変更がほとんどまたは全く不要
• 既存のデータ主権に関する考慮事項との整合性

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 は企業が利用できる最も経済的なオプションの1つとして際立っています。同等の機能を提供しながら、私たちの価格に匹敵する代替案はほとんどありません。

私たちは、強力で使いやすいだけでなく、あらゆる規模の組織にとってコスト効率の良い検索機能を提供することに取り組んでいます。主要なクラウドプロバイダーを通じてであれ、セルフホストデプロイメントを通じてであれ、純粋なコストの考慮を超えて最も複雑な企業要件にも対応するソリューションを提供します。この分析は、意思決定に役立つよう、さまざまなコスト要因を分解しています。

各組織には独自の要件があるため、1つの記事ですべてのシナリオに対応できないことを認識しています。ここで扱われていない特定のニーズがある場合は、最適な実装サポート方法について相談するためにご連絡ください。