LLMサービスの公平性
Cohereは、マルチテナントLLMプラットフォームにおいて、レート制限、パフォーマンス階層、Deficit Round Robin、優先度セレクターを組み合わせ、テナント間で推論リクエストを公平にスケジューリングする新しいソリューションを導入し、「ノイジーネイバー」問題を防ぎます。
大規模言語モデルをマルチテナントSaaSプラットフォームとして実行するには、一見単純だが厄介な問題があります。多くの組織が同じGPUプールを共有し、そのトラフィックはバースト的で不均一です。管理しないままにしておくと、ある顧客のスパイクが他の顧客のレイテンシ問題になりかねません。
このブログ記事では、Cohereがアーキテクチャパターンと古典的なスケジューリングアルゴリズムを組み合わせて、テナント間で推論リクエストを公平にスケジューリングする新しいソリューションを紹介します。
問題：ノイジーネイバー
推論は、リクエストがバッチ処理される場合に最も効率的です。満杯のバッチを供給されたGPUは効率的に動作し、経済的ですが、一度に1つのリクエストを処理するGPUはほとんどアイドル状態になります。したがって、リクエストは一時的にキューに入れられ、ハードウェアに送られる前にバッチに詰め込まれます。
問題は順序付けです。単純なキューを想像してみてください。優先度と期限だけで順序付けられた単一の共有キューです。ここで、ある組織が10,000のリクエストをバーストで送信し、別の組織が5つだけ送信するとどうなるかを考えてみます。単一のグローバルキューでは、10,000のリクエストが前に積まれ、5つの行儀の良いリクエストは後ろで待ちます。
これが古典的な「ノイジーネイバー」問題であり、マルチテナントLLMプラットフォームもこのようなトラフィックパターンに直面する他の共有システムと変わりません。
サービスの公平性の目標は、テナントを互いに分離し、テナントが受け取る推論容量のシェアが、キューをどの程度積極的に溢れさせるかではなく、公平なスケジューリングに依存するようにすることです。同時に、各テナント内の優先度と期限の順序を維持し、バッチ処理効率も保ちます。
解決策：容量管理への階層的アプローチ
Cohereは、4つの異なるメカニズムを組み合わせてテナント間のワークロードを公平に管理します。各メカニズムは問題の異なる部分を解決します。これらは固定順序で実行されます。レート制限が入口でアドミッションを制御し、次に3つのセレクター（パフォーマンス階層、Deficit Round Robin、優先度）が出口で次のリクエストを選択します。
以下がアーキテクチャと段階的なフローです。
- レート制限
リクエストがスケジューリングキューに参加する前に、アドミッションコントロールを通過します。レート制限は、単一のテナントが特定の時間枠（1分あたりや1ヶ月あたりなど）内に送信できる推論リクエストの最大数を制限します。
Cohereでは、これらの制限はエンドポイントレベルで設定され、各モデルが消費するリソース量に基づいてモデルごとに異なります。例えば、重量級の生成モデルは軽量の埋め込みモデルよりも厳しい制限を持ちます。
また、リアルタイムのスロットリングチェックもあります。キューが既に滞っており、新しいリクエストがレイテンシ目標内に処理できない場合、リクエストは早期に拒否されます。これにより、システムが処理できない作業を受け入れないように保護し、負荷下でもレイテンシを予測可能に保ちます。
リクエストがアドミッションされた後、以下のセレクターの連鎖に進みます。
- パフォーマンス階層（セレクター1）
最初の選択決定は階層です。コンピューティングリソースはサービスレベルアグリーメント（SLA）に基づいて優先順位付けされます。支払いの高い階層は、低い階層（またはトライアル階層）よりも高い処理優先度と高速なキュー処理が割り当てられます。逆に、後者の顧客は容量の許す限りサービスを受けます。
重要なのは、階層化が誰が先に行くかを決定することです。それ自体では、階層内の単一の大規模テナントが支配するのを防ぐことはできません。それが次の2つの層の目的です。
- Deficit Round Robin（セレクター2）
システムの中核はDeficit Round Robin（DRR）アルゴリズムであり、階層内のフリート全体にわたって公平なコンピューティングの分配を保証します。
各テナント（「組織」）は独自のキューを持ちます。スケジューラーは最長のキューを空にする代わりに、テナント間で交代で処理します。各テナントは、自身のターンに実行できる小さな予算（量子）を付与されます。テナントがターンを使用すると、その予算は送信したリクエストのコストだけ減算されます。予算を使い切ったテナントは、次のラウンドで予算が補充されるまでスキップされます。
DRRのエレガントさは、それがワークコンサーブであり、重み付けされていることです。安価なリクエストはテナントがより頻繁にターンに来ることを可能にし、高価なリクエストはその頻度を減らすため、どのテナントもGPUを占有することはありませんが、容量も無駄になりません。先の例に戻ると、組織Aが10,000のリクエストをキューに入れ、組織Bが5つだけだったとしても、組織Bは各サイクルで正当なターンを得ます。組織Aのバーストはもはや組織Bのレイテンシに影響しません。
予算の測定基準
このスキームは2つの重要な変数に依存します。
- 量子：各ラウンドでテナントに付与される予算量
- コスト：各リクエストが消費する予算量
重要な設計上の選択は、これらの変数がどの単位で表現されるかです。これは、推論コンテキストの違いに応じて「公平性」をどのように概念化するかを決定します。Cohereでは、エンドポイントに応じて2つのコストモデルを使用しています。リクエストベースの予算設定とトークンベースの予算設定です。
リクエストベースの予算設定
単純化のため、各リクエストのコストは1とされ、量子はテナントが1ターンに送信できるリクエスト数です。したがって、公平性は純粋にリクエスト数で測定されます。
これは、チャットや補完などの生成エンドポイントでは最適ではありません。リクエストのサービスコストは劇的に異なる可能性があります。100Kトークンのプロンプトを持つリクエストは、1Kトークンのプロンプトを持つものよりも数桁多くのリソースを消費する可能性があります。推論能力のあるモデルの場合、総コストは入力サイズだけでなく、リクエストの特定のコンテキストによってトリガーされる中間推論、計画、出力生成の量にも依存します。
理想的には、DRRはリクエストのトークン正規化サービスコストの指数移動平均（EMA）に基づくフィードバックループを使用し、予算が観測されたリソース消費に適応できるようにします。静的な予算設定は、エンドポイント内のリクエストのサイズとコストがほぼ同じ場合に最も効果的です。
トークンベースの予算設定
ここでは、リクエストのコストはそのトークン数であり、量子は1ラウンドあたりのトークン予算です。公平性は実際に行われた作業で測定されます。これは、埋め込みやリランカーなどのバッチエンドポイントに自然に適合します。これらのエンドポイントでは、バッチのトークン合計（アイテム数ではなく）がGPUコストを駆動します。非常に大きなドキュメントをいくつか送信するテナントは、すぐに予算を使い切り、早く譲ります。多くの小さなリクエストを送信するテナントは、リクエストごとにほとんど課金されず、より頻繁に出現します。これにより、どのテナントも少数の非常に大きなリクエストを送信することでGPUを独占することはできません。
各モデルがリクエストに与える意味
| 特性 | リクエストベース | トークンベース | |------|------------------|----------------| | 1リクエストのコスト | サイズに関わらず常に1 | トークン数に比例 | | 量子（1ターンあたりの予算） | リクエスト数 | トークン許容量 | | 大きなリクエスト | 小さなものと同じカウント | より多く課金され、テナントのシェアを多く消費 | | 小さなリクエストのテナント | 他のテナントと同じターン数 | より多くのターンを得る（各リクエストが安価） | | 最適な用途 | 生成/ストリーミングエンドポイント | 埋め込み/リランカー（バッチ）エンドポイント | | 公平性の測定 | 処理されたリクエスト | 行われた作業（トークン） |
したがって、リクエストベースの予算設定では、リクエストは競合する各テナントからの最大固定数のリクエストの後ろに待ちます。これらのリクエストがどれほど大きくても関係ありません。このカウントは予測可能かもしれませんが、隣人の大きなリクエストは、それらのターンのたびにGPU時間を消費する可能性があります。
トークンベースの予算設定では、大きなリクエストは「重く」、そのテナントの予算をより速く消費するため、テナントはより早く譲り、小さなリクエストが効率的に通過できます。このモデルは、作業の真のコストをより忠実に反映し、単一テナントの重いトラフィックによるボトルネックに対するより強力な保証です。
量子のサイズは、エンドポイントのバッチ戦略にも合わせられています。ストリーミングエンドポイントは、密なインターリーブのためにテナントあたり約1リクエストの後にローテーションしますが、バッチエンドポイントは完全なバッチに近い予算を付与します。これにより、テナントはスケジューラーが次に移る前に意味のあるチャンクを貢献でき、公平性を犠牲にすることなくバッチ効率を維持します。
- 優先度（セレクター3）
公平性がどのテナントが次に行くかを決定することであるなら、優先度セレクターはそのテナントのどのリクエストが次に行くかを決定します。
Deficit Round Robinがテナントのターンを選択すると、スケジューラーはそのテナントのキューから1つのリクエストを取り出します。ただし、盲目的には行いません。各キューは次のように順序付けられた体系化されたキューです。
- 優先度：明示的に高い優先度のリクエストが先に処理されます。
- 期限：同じ優先度の中で、最も早い期限のリクエストが勝ちます。これにより、時間に敏感な作業が期限切れになることがありません。
- 到着時間：最終的なタイブレーカーとして、より早いリクエストが先に処理され、安定した予測可能な先入れ先出し動作を提供します。
この順序付けを各テナント内に保持することで、公平性と緊急性がプラットフォーム上で共存できるようになります。テナントは、プラットフォームを共有しているからといって、優先度や期限の保証を失うことはありません。単に、それらの保証を自身の公平な容量シェアに適用するだけです。
統合
4つの段階は、明確なリクエストライフサイクルを構成します。レート制限が入口でアドミッションを制御し、階層化、公平性、テナントごとの緊急性が出口で選択を制御し、各バッチがアセンブルされます。
個別に見ると、これらのメカニズム（レート制限、階層化、ラウンドロビンスケジューリング、優先度キュー）は、MLOpsやプラットフォームエンジニアにはよく知られています。それらの新規性は、それらがどのように統合されるかにあります。
- レート制限はシステムを過負荷から保護し、テナントごとのクォータを強制します。
- 階層化は商業的なコミットメントを尊重します。
- Deficit Round Robinは、同等の階層のアドミッションされたトラフィックの中で、各テナントが公平でバースト耐性のあるシェアを得ることを保証します。
- 優先度は、各テナントの公平なシェア内で、そのテナント自身の緊急性と期限の順序を保持します。
ステップ2〜4はバッチが満杯になるまで繰り返され、その後バッチはGPUに送信されます。結果として、あなたの体験は、あなたの階層と公平な容量シェアに依存するプラットフォームが実現します。隣人がその日にどれだけうるさいかには依存しません。
今すぐより公平で摩擦のない推論を
Serving Fairnessは現在、Cohere SaaS APIおよびAWSを含むサードパーティのマーケットプレイス展開を通じて、任意のCohereモデルを使用するすべての顧客に対して有効化されています。
当社は、お客様のニーズを最優先にこの機能を開発しました。Cohereモデルを使用していて、フィードバック、パフォーマンスの問題の観察、または改善の提案がある場合は、Discordのエンジニアリングチームにお問い合わせください。