GKE 推論 Gateway のロールアウト オペレーションを実行する

---

このページでは、GKE Inference Gateway で新しいバージョンの推論インフラストラクチャを段階的にデプロイする増分ロールアウト オペレーションを実行する方法について説明します。このゲートウェイを使用すると、推論インフラストラクチャを安全かつ制御された方法で更新できます。ノードの更新、ベースモデルの更新、LoRA アダプタの更新は、サービスを中断することなく行えます。このページでは、信頼性の高いデプロイを実現するためのトラフィック分割とロールバックに関するガイダンスも提供します。

このページは、GKE Inference Gateway のロールアウト オペレーションを実行する GKE ID とアカウントの管理者とデベロッパーを対象としています。

次のユースケースがサポートされています。

• ノードの更新（コンピューティング、アクセラレータ）のロールアウト
• ベースモデルのアップデートのロールアウト
• LoRA アダプターの更新ロールアウト

ノードのロールアウトを更新する

ノードの更新ロールアウトにより、推論ワークロードを新しいノード ハードウェアまたはアクセラレータ構成に安全に移行できます。このプロセスは、モデル サービスを中断することなく、制御された方法で実行されます。ノード アップデートのロールアウトを使用すると、ハードウェアのアップグレード、ドライバの更新、セキュリティ問題の解決中にサービスの中断を最小限に抑えることができます。

1. 新しい InferencePool を作成する: 更新されたノードまたはハードウェア仕様で構成された InferencePool をデプロイします。

2. HTTPRoute を使用してトラフィックを分割する: 既存の InferencePool リソースと新しい InferencePool リソース間でトラフィックを分散するように HTTPRoute を構成します。backendRefs の weight フィールドを使用して、新しいノードに転送されるトラフィックの割合を管理します。

3. InferenceModel の一貫性を維持する: 既存の InferenceModel 構成を保持して、両方のノード構成でモデルの動作を統一します。

4. 元のリソースを保持する: ロールアウト中は元の InferencePool とノードをアクティブにして、必要に応じてロールバックできるようにします。

たとえば、llm-new という名前の新しい InferencePool を作成できます。このプールを、既存の llm InferencePool と同じモデル構成で構成します。クラスタ内の新しいノードセットにプールをデプロイします。HTTPRoute オブジェクトを使用して、元の llm と新しい llm-new InferencePool の間でトラフィックを分割します。この方法では、モデルノードを段階的に更新できます。

次の図は、GKE Inference Gateway がノードの更新ロールアウトを実行する方法を示しています。

ノードの更新ロールアウトを行う手順は次のとおりです。

1. 次のサンプル マニフェストを routes-to-llm.yaml として保存します。

   apiVersion: gateway.networking.k8s.io/v1
   kind: `HTTPRoute`
   metadata:
     name: routes-to-llm
   spec:
     parentRefs:
       - name: my-inference-gateway
     rules:
       backendRefs:
       - name: llm
         kind: InferencePool
         weight: 90
       - name: llm-new
         kind: InferencePool
         weight: 10
   

2. マニフェストをクラスタに適用します。

   kubectl apply -f routes-to-llm.yaml
   

元の llm InferencePool がトラフィックの大部分を受信し、llm-new InferencePool が残りのトラフィックを受信します。llm-new InferencePool のトラフィック重みを徐々に増やして、ノードのアップデート ロールアウトを完了します。

ベースモデルをロールアウトする

ベースモデルの更新は、既存の LoRA アダプタとの互換性を維持しながら、新しいベース LLM に段階的にロールアウトされます。ベースモデルの更新ロールアウトを使用すると、改善されたモデル アーキテクチャにアップグレードしたり、モデル固有の問題に対処したりできます。

ベースモデルのアップデートをロールアウトするには:

1. 新しいインフラストラクチャをデプロイする: 選択した新しいベースモデルで構成された新しいノードと新しい InferencePool を作成します。
2. トラフィック分散を構成する: HTTPRoute を使用して、既存の InferencePool（古いベースモデルを使用）と新しい InferencePool（新しいベースモデルを使用）の間でトラフィックを分割します。backendRefs weight フィールドは、各プールに割り当てられるトラフィックの割合を制御します。
3. InferenceModel の完全性を維持する: InferenceModel の構成を変更しないでください。これにより、両方のベースモデル バージョンで同じ LoRA アダプターが一貫して適用されます。
4. ロールバック機能を保持する: ロールアウト中に元のノードと InferencePool を保持し、必要に応じてロールバックを容易にします。

llm-pool-version-2 という名前の新しい InferencePool を作成します。このプールは、新しいバージョンのベースモデルを新しいノードセットにデプロイします。提供されている例に示すように HTTPRoute を構成すると、元の llm-pool と llm-pool-version-2 間でトラフィックを段階的に分割できます。これにより、クラスタ内のベースモデルの更新を制御できます。

ベースモデルの更新ロールアウトを行う手順は次のとおりです。

1. 次のサンプル マニフェストを routes-to-llm.yaml として保存します。

   apiVersion: gateway.networking.k8s.io/v1
   kind: HTTPRoute
   metadata:
     name: routes-to-llm
   spec:
     parentRefs:
       - name: my-inference-gateway
     rules:
       backendRefs:
       - name: llm-pool
         kind: InferencePool
         weight: 90
       - name: llm-pool-version-2
         kind: InferencePool
         weight: 10
   

2. マニフェストをクラスタに適用します。

   kubectl apply -f routes-to-llm.yaml
   

元の llm-pool InferencePool がトラフィックの大部分を受信し、llm-pool-version-2 InferencePool が残りのトラフィックを受信します。llm-pool-version-2 InferencePool のトラフィック重みを徐々に増やして、ベースモデルのアップデート ロールアウトを完了します。

LoRA アダプターのアップデートをロールアウトする

LoRA アダプタの更新ロールアウトを使用すると、基盤となるベースモデルやインフラストラクチャを変更することなく、ファインチューニングされたモデルの新しいバージョンを段階的にデプロイできます。LoRA アダプターのアップデート ロールアウトを使用して、LoRA アダプターの改善、バグの修正、新機能をテストします。

LoRA アダプターを更新する手順は次のとおりです。

1. アダプタを使用可能にする: モデルサーバーで新しい LoRA アダプタ バージョンを使用できるようにします。詳細については、アダプターのロールアウトをご覧ください。

2. InferenceModel 構成を変更する: 既存の InferenceModel 構成で、LoRA アダプターの複数のバージョンを定義します。各バージョンに固有の modelName を割り当てます（例: llm-v1、llm-v2）。

3. トラフィックを分散する: InferenceModel 仕様の weight フィールドを使用して、さまざまな LoRA アダプター バージョン間でのトラフィック分散を制御します。

4. poolRef の一貫性を維持する: すべての LoRA アダプタ バージョンが同じ InferencePool を参照するようにします。これにより、ノードまたは InferencePool の再デプロイが防止されます。ロールバックを有効にするため、InferenceModel 構成で以前の LoRA アダプター バージョンを保持します。

次の例は、2 つの LoRA アダプター バージョン（llm-v1 と llm-v2）を示しています。どちらのバージョンも同じベースモデルを使用します。llm-v1 と llm-v2 は同じ InferenceModel 内で定義します。重みを割り当てて、トラフィックを llm-v1 から llm-v2 に段階的にシフトします。このコントロールを使用すると、ノードや InferencePool 構成を変更することなく、制御されたロールアウトを実行できます。

LoRA アダプターのアップデートをロールアウトするには、次のコマンドを実行します。

1. 次のサンプル マニフェストを inferencemodel-sample.yaml として保存します。

   apiVersion: inference.networking.x-k8s.io/v1alpha2
   kind: InferenceModel
   metadata:
     name: inferencemodel-sample
   spec:
   versions:
   -   modelName: llm-v1
     criticality: Critical
     weight: 90
     poolRef:
       name: llm-pool
   -   modelName: llm-v2
     criticality: Critical
     weight: 10
     poolRef:
       name: llm-pool
   

2. マニフェストをクラスタに適用します。

   kubectl apply -f inferencemodel-sample.yaml
   

llm-v1 バージョンはトラフィックの大部分を受信し、llm-v2 バージョンは残りのトラフィックを受信します。llm-v2 バージョンのトラフィック重みを徐々に増やして、LoRA アダプターの更新ロールアウトを完了します。

次のステップ

• GKE Inference Gateway の構成をカスタマイズする
• GKE Inference Gateway を使用して LLM をサービングする