Michael Johnson2つのサービスがモデルに同じ数のリクエストを送っていても、負荷は大きく異なることがある。10月9日に公開されたCohereのEmbedとRerankに関するガイドでは、リクエストの形態、負荷の時間的なパターン、レイテンシ要件に応じて、共有処理と専用処理を選ぶことを提案している。これはインフラに関する実践的な解説であり、新たな料金プランや製品の発表ではない。
検索やRAGを構築するチームにとって、この結論はインデックス作成やユーザーの検索リクエストを計画するうえで重要だ。呼び出し回数だけでは、計算量を十分に把握できない。埋め込み生成のための文書バッチ1つが、多数の短い検索リクエストより多くのリソースを消費することもある。
1分あたりのリクエスト数が誤解を招く理由
埋め込みはテキストを数値表現に変換し、検索システムが意味的な照合に利用する。カタログの初回インデックス作成では、アプリケーションが説明文の大きなバッチを送ることがある。一方、通常の検索では、モデルに渡されるのは短いクエリテキストだ。これらのタスクで重視される指標は異なる。バッチ処理では通常、スループットとコストを評価し、検索ではユーザーへの応答時間を重視する。
Rerankでは、システムが並べ替えのためにモデルへ渡す候補数も重要だ。Cohereの例では、短いクエリを50件の文書と照合し、この処理を約1万1,000トークンと見積もっている。候補数を増やすと、ユーザー検索の頻度が変わらなくても処理量は増える。
Cohereの試算が示すこと
記事では、従量課金から専用キャパシティへの切り替えが経済的に有利になる目安として、概算値を示している。約200トークンのテキスト100件をバッチでインデックス化する場合は毎分約20リクエスト、より長い文書の場合は約4リクエスト、提示されたRerankのシナリオでは約29リクエストだ。短い検索用埋め込みでは、著者らは損益分岐点を毎分数万リクエストと見積もっている。
これらの数値は、NVIDIA A10を1基、24時間365日フル稼働させること、所定のリクエストサイズ、公開済みの料金を前提に算出されている。Cohereは、稼働時間、ハードウェア構成、割引、文書量が異なれば、グラフやしきい値も変わると説明している。これらは計算方法を示す例として捉えるべきで、普遍的な基準ではない。
ただし、この選択の考え方は、具体例の範囲を超えて応用できる。予測可能で継続的な負荷なら、予約済みのキャパシティを有効活用できる可能性がある。一方、長いアイドル時間を挟む短い負荷の急増には、実際の消費量に応じた課金が適していることが多い。対話型検索では、想定負荷でのレイテンシも確認する必要がある。ハードウェアの最大スループットが、実運用時に必要な応答時間を保証するわけではない。
自社の検索に解説を生かす方法
選択肢を比較する前に、実際のトラフィックでいくつかの項目を測定しよう。リクエストあたりのトークン数と文書数、インデックス作成バッチのサイズ、再ランキングする候補数、ピークの継続時間、目標レイテンシだ。そのうえで、平均リクエスト数だけでなく、実際の負荷スケジュールに基づいてコストを計算する。全体像を把握するには、現在の料金とホスティング条件をCohereの料金ページで確認しよう。専用モデルと従量課金の処理では、料金体系が異なる。
ハイブリッド検索では、カタログのバックグラウンド再インデックス、短いユーザー検索、候補の再ランキングを別々に評価するのが妥当だ。この試算により、単一のインフラが適切か、それともパイプラインの各部分を異なるホスティング方式で処理するほうが有利かを確かめられる。Cohereの解説の実務的な結論はシンプルだ。まず各リクエストが担う処理量を測り、その後で課金方式とリソースの割り当て方を選ぼう。