AIゲートウェイにおけるロードバランシング：パフォーマンスの最適化

True Foundryでロードバランシングを設定する方法

TrueFoundryのAI Gatewayは、YAMLを介してロードバランシング設定を適用するための2つの主要な方法をサポートしています。ゲートウェイUIから直接行う方法と、GitOpsおよびtfy CLIを使用してプログラム的に行う方法です。

ゲートウェイUIでロードバランシングを更新するには、プロジェクトのAI Gatewayに移動し、「Load Balancing」の下にある「Config」タブを選択します。YAMLエディターには、現在のgateway-load-balancing-configマニフェストが表示されます。これには、nameやtypeなどのトップレベルフィールド、レート制限用のオプションのmodel_configs、およびルーティング戦略用のコアrules配列が含まれます。 

YAMLをインラインで編集し、モデル識別子を変更したり、usage_limitsやfailure_toleranceを調整したり、重みまたはレイテンシー戦略でload_balance_targetsを再定義したりするだけで、保存をクリックすると、ダウンタイムなしで即座に検証およびデプロイされます。内部では、TrueFoundryが構文を検証し、新しいルールを順番に適用し、更新されたポリシーに従ってトラフィックを即座にルーティングします。

あるいは、GitOpsを実践しているチームの場合、ロードバランシングマニフェスト（例：loadbalancer-config.yaml）を、インフラストラクチャコードとともにバージョン管理されたリポジトリに保存します。変更をコミットしてプッシュした後、TrueFoundry CLIを実行します。

• pip install truefoundry および tfy login --host https://app.truefoundry.com を実行して認証します
  
• tfy apply -f loadbalancer-config.yaml を実行して、YAMLをゲートウェイにプッシュします
  

このワークフローにより、ポリシー変更が本番環境に適用される前に、プルリクエストレビュー、CI/CD検証、および完全な監査可能性が強制されます。迅速なイテレーションのために直接UI編集を好む場合でも、堅牢なガバナンスのためにGitOpsを好む場合でも、TrueFoundryの宣言型YAMLアプローチは、ロードバランシングポリシーが透過的で、バージョン管理され、アプリケーションコードに触れることなく一貫して適用されることを保証します。 

True Foundryのロードバランシング設定について

TrueFoundryのロードバランシング設定は、宣言型のYAMLマニフェストで完全に定義されており、主にmodel_configsとrulesの2つのセクションで構成されます。最上位レベルでは、ログ記録に使用される人間が読める識別子であるnameと、プラットフォームがこのファイルをロードバランシング仕様として認識できるようにgateway-load-balancing-configである必要があるtypeを指定します。

オプションのmodel_configsブロックを使用すると、各モデルエンドポイントにグローバルな制約を適用できます。各エントリには以下を含めます。

• model: ゲートウェイ識別子（例: azure/gpt4）

• usage_limits: いずれのモデルも割り当てられたスループットを超えないように、tokens_per_minuteとrequests_per_minuteに上限を設定します。

• failure_tolerance: モデルが異常と見なされる時期を決定するパラメータ。allowed_failures_per_minute、cooldown_period_minutes、および障害と見なされるHTTPステータスコードのリストが含まれます。
  

モデルが使用量または障害のしきい値を超えると、ゲートウェイは指定されたクールダウン期間中、そのモデルを異常とマークし、回復するまでルーティングから除外します。

設定の中核はrules配列です。各ルールは以下を宣言する必要があります。

• id: メトリクスとログに使用される一意の名前

• type: weight-based-routingまたはlatency-based-routingのいずれか

• when: モデルによって、オプションでサブジェクトまたはメタデータによって、ルールを特定の要求に限定する条件
  

ルールは出現順に評価され、最初の一致するルールのみが適用されます。これにより、予測可能で決定論的なトラフィックルーティングが保証されます。

load_balance_targetsの下に、1つ以上のターゲットモデルをリストします。重みベースのルーティングの場合、各ターゲットには0から100までの整数値の重みが必要で、すべての重みの合計は100になります。レイテンシベースのルーティングの場合、重みは不要です。ゲートウェイは最近のトークンごとのレイテンシを測定し、各リクエストを最も高速で健全なモデルにルーティングします。どちらの戦略も、ターゲットごとにオプションのoverride_paramsをサポートしており、temperatureやmax_tokensなどのランタイムパラメータをカスタマイズできます。

トラフィック分散ポリシーを単一のYAMLファイルに一元化することで、TrueFoundryはアプリケーションコードを変更することなく、バージョン管理、プルリクエストレビュー、ロードバランシング戦略の迅速な反復を可能にします。

一般的に使用されるロードバランシング設定

企業は、異なる運用目標を達成するために、独自のロードバランシングパターンを採用することがよくあります。以下に、TrueFoundry AI Gatewayで広く利用されている4つの設定を紹介します。それぞれが特定のユースケースに合わせて調整されています。

1. カナリアデプロイメント

段階的なロールアウトにより、チームは新しいモデルバージョンを安全に導入できます。トラフィックのごく一部をカナリアモデルに割り当て、残りを安定版に割り当てます。カナリアモデルのエラー率とレイテンシを監視することで、完全な切り替えの前に問題が検出されることを保証します。

名前: loadbalancing-config
タイプ: gateway-load-balancing-config
ルール:
  - ID: "gpt4-canary"
    タイプ: "weight-based-routing"
    条件:
      モデル:
        - "gpt-4"
    ロードバランス対象:
      - ターゲット: "azure/gpt4-v1"
        重み: 90
      - ターゲット: "azure/gpt4-v2"
        重み: 10

2. ヘルスアウェアな重みベースルーティング

プレミアムユーザーや優先度の高いワークフローは、最もパフォーマンスの高いモデルに誘導できます。`model_configs`で障害許容度を定義することで、エラーしきい値を超えたモデルは、回復するまで自動的に削除されます。その後、トラフィックの割合は、残りの正常なエンドポイント間で継続されます。

名前: loadbalancing-config
タイプ: gateway-load-balancing-config
モデル設定:
  - モデル: "azure/gpt4"
    障害許容度:
      1分あたりの許容失敗回数: 3
      クールダウン期間（分）: 5
      失敗ステータスコード: [429, 500, 502, 503, 504]
  - モデル: "openai/gpt4"
    障害許容度:
      1分あたりの許容失敗回数: 5
      クールダウン期間（分）: 10
      失敗ステータスコード: [429, 500, 502, 503, 504]
ルール:
  - ID: "premium-users"
    タイプ: "重みベースルーティング"
    条件:
      対象:
        - "virtualaccount:premium"
      モデル:
        - "gpt-4"
    ロードバランスターゲット:
      - ターゲット: "azure/gpt4"
        ウェイト: 80
        オーバーライドパラメータ:
          テンパチャー: 0.7
      - ターゲット: "openai/gpt4"
        ウェイト: 20

3. トークン認識型レイテンシーベースルーティング

コストとパフォーマンスのバランスを取るため、あるモデルのトークン使用量に上限を設定し、代替エンドポイントがオーバーフローを処理できるようにすることができます。レイテンシーベースルーティングは、クォータ内で利用可能なモデルの中から、各リクエストが最速のモデルに送られるようにします。

名前: loadbalancing-config
タイプ: gateway-load-balancing-config
モデル設定:
  - モデル: "azure/gpt4"
    使用量制限:
      1分あたりのトークン数: 50000
      1分あたりのリクエスト数: 100
ルール:
  - ID: "cost-effective"
    タイプ: "latency-based-routing"
    条件:
      モデル:
        - "gpt-4"
    load_balance_targets:
      - target: "azure/gpt4"
        override_params:
          max_tokens: 500
      - target: "openai/gpt4"
        override_params:
          max_tokens: 1000

4. 環境ベースのルーティング

開発、ステージング、本番などの異なる環境では、それぞれ異なるルーティングポリシーが必要となることがよくあります。環境メタデータを使用すると、リクエストのコンテキストに応じて、重みベースまたはレイテンシーベースのルールを適用できます。

name: loadbalancing-config
type: gateway-load-balancing-config
rules:
  - id: "dev-environment"
    type: "weight-based-routing"
    when:
      models:
        - "gpt-4"
      metadata:
        environment: "development"
    ロードバランス対象:
      - ターゲット: "openai/gpt4"
        ウェイト: 100
        オーバーライドパラメータ:
          temperature: 0.8
  - ID: "prod-environment"
    タイプ: "レイテンシーベースルーティング"
    条件:
      モデル:
        - "gpt-4"
      メタデータ:
        環境: "production"
    ロードバランス対象:
      - ターゲット: "azure/gpt4"
      - ターゲット: "openai/gpt4"

これらの各設定は、TrueFoundryの宣言型YAMLが、段階的なロールアウト、ヘルス状態を考慮したトラフィックスプリット、コストを重視したパフォーマンス最適化、環境に応じたポリシーなど、高度なルーティングロジックをアプリケーションコードに手を加えることなく迅速に実装できることを示しています。

結論

ロードバランシングは変革します AIゲートウェイ を単純なルーターからインテリジェントなトラフィックマネージャーへと変革し、複数のLLMエンドポイント間で高可用性、一貫したパフォーマンス、シームレスなフェイルオーバーを保証します。グローバルな使用制限と障害許容度を定義することで、過負荷になったモデルやエラーが発生しやすいモデルがサービスを中断するのを防ぎます。重みベースのルーティングにより、トラフィックの割合を正確に制御でき、カナリアリリースやプレミアムワークフローに最適です。一方、レイテンシーベースのルーティングは、リクエストを最も高速で健全なモデルに動的に誘導します。宣言型YAML設定により、これらのポリシーは透過的で、バージョン管理され、レビューが容易になります。TrueFoundryのロードバランシング機能により、チームはLLMを自信を持ってデプロイできます。トラフィックの分散がアプリケーションコードの変更なしにリアルタイムの状況に自動的に適応することを理解しているからです。

よくある質問

AIゲートウェイにおけるロードバランシングとは何ですか？

AIゲートウェイシステムにおけるロードバランシングは、ボトルネックを防ぐために推論リクエストをさまざまなモデルエンドポイントに分散させることを含みます。これにより、単一のプロバイダーやモデルインスタンスが過負荷になることを防ぎ、システムの可用性を維持します。リクエスト数やエラー率などのヘルス指標を監視することで、ゲートウェイはスムーズで信頼性の高いユーザーエクスペリエンスを保証します。

AIゲートウェイは、複数のLLMプロバイダー間でどのようにロードバランシングを実行しますか？

ゲートウェイは、リアルタイムのプロバイダーパフォーマンスに基づいてトラフィックをルーティングするために特殊なアルゴリズムを使用します。重みベースのルーティングなどの手法により固定のトラフィックスプリットが可能になり、レイテンシーベースの戦略は最も高速で健全なエンドポイントを動的に選択します。プロバイダーがレート制限に達したり障害が発生したりした場合、ゲートウェイは自動的にトラフィックを機能する代替手段にリダイレクトします。

AIゲートウェイにおけるロードバランシングは、APIゲートウェイと比べてどのように異なりますか？

APIゲートウェイがCPU負荷などのネットワークレベルのメトリクスに焦点を当てるのに対し、AIゲートウェイアーキテクチャにおけるロードバランシングはセマンティックアウェアです。これは、1分あたりのトークン数やモデル固有のエラーコードなど、AIに特化したデータを追跡します。これにより、さまざまなLLMの独自の処理能力制限と処理動作を尊重した、より正確なトラフィック管理が可能になります。

マルチモデルAIデプロイメントにとってロードバランシングは必要ですか？

はい、高可用性を維持し、本番AIアプリケーションを効果的にスケーリングするために不可欠です。それがなければ、システムは個々のプロバイダーの停止やパフォーマンスの遅延に対して脆弱なままです。複数のモデルにリクエストを分散させることで、大規模なトラフィックを処理するために必要な冗長性が提供され、すべてのエンドユーザーに対して一貫した応答時間を保証します。

TrueFoundryはAIゲートウェイにおけるロードバランシングにどのように役立ちますか？

TrueFoundryは、宣言型のYAMLベースの構成を通じてAIゲートウェイ管理におけるロードバランシングを簡素化します。自動ヘルスチェック、レイテンシーベースのルーティング、シームレスなフェイルオーバーを提供し、ミッションクリティカルな信頼性を確保します。このインフラストラクチャを独自のVPC内でホストすることで、プラットフォームはデータセキュリティを犠牲にすることなく、パフォーマンスとコストを最適化することを可能にします。