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

Autopilot Standard

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

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

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

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

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

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

新しい InferencePool を作成する: ノードやハードウェアの更新済み仕様で構成した InferencePool をデプロイします。
HTTPRoute を使用してトラフィックを分割する: 既存の InferencePool リソースと新しい InferencePool リソースの間でトラフィックが分配されるように HTTPRoute を構成します。backendRefs の weight フィールドを使用して、新しいノードに分配するトラフィックの割合を管理します。
一貫性のある InferenceModel を維持する: 既存の InferenceModel 構成を保持して、両方のノード構成でモデルの動作が同一になるようにします。
元のリソースを保持する: 必要に応じてロールバックできるように、ロールアウト中は元の InferencePool とノードをアクティブな状態に保持します。

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

GKE Inference Gateway によってノードの更新がロールアウトされる様子を次の図に示します。

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

次のサンプルマニフェストを 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

このサンプルマニフェストをクラスタに適用します。
```
kubectl apply -f routes-to-llm.yaml
```

元の llm InferencePool がトラフィックの大部分を受け取り、llm-new InferencePool は残りのトラフィックを受け取ります。llm-new InferencePool に対するトラフィックの重み付けを段階的に大きくして、ノードの更新のロールアウトを完了します。

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

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

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

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

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

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

次のサンプルマニフェストを 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

このサンプルマニフェストをクラスタに適用します。
```
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 アダプタを更新する手順は次のとおりです。

アダプタを使用可能にする: 新しいバージョンの LoRA アダプタをモデルサーバー上で使用できることを確認します。詳細についてはアダプタのロールアウトをご覧ください。
InferenceModel の構成を変更する: 既存の InferenceModel の構成で、複数バージョンの LoRA アダプタを定義します。各バージョンに一意の modelName を割り当てます（llm-v1、llm-v2 など）。
トラフィックを分配する: InferenceModel の仕様にある weight フィールドを使用して、さまざまなバージョンの LoRA アダプタ間でトラフィック分配を制御します。
一貫性のある poolRef を維持する: すべてのバージョンの LoRA アダプタが同じ InferencePool を参照するようにします。これにより、ノードや InferencePool が再デプロイされなくなります。ロールバックできるようにするには、以前のバージョンの LoRA アダプタを InferenceModel 構成に保持します。

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

LoRA アダプタの更新をロールアウトするには次のコマンドを使用します。

次のサンプルマニフェストを 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

このサンプルマニフェストをクラスタに適用します。
```
kubectl apply -f inferencemodel-sample.yaml
```

llm-v1 バージョンがトラフィックの大部分を受け取り、llm-v2 バージョンは残りのトラフィックを受け取ります。llm-v2 バージョンに対するトラフィックの重み付けを段階的に大きくして、LoRA アダプタの更新のロールアウトを完了します。

GKE Inference Gateway のロールアウト オペレーションを実行する コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

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

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

LoRA アダプタの更新をロールアウトする

次のステップ

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