Rollout-Vorgänge für GKE Inference Gateway ausführen

Auf dieser Seite erfahren Sie, wie Sie inkrementelle Roll-out-Vorgänge ausführen, bei denen neue Versionen Ihrer Inferenzinfrastruktur für GKE Inference Gateway schrittweise bereitgestellt werden. Mit diesem Gateway können Sie sichere und kontrollierte Updates an Ihrer Inferenzinfrastruktur vornehmen. Sie können Knoten, Basismodelle und LoRA-Adapter mit minimalen Dienstunterbrechungen aktualisieren. Auf dieser Seite finden Sie auch Anleitungen zur Traffic-Aufteilung und zu Rollbacks, um zuverlässige Bereitstellungen zu gewährleisten.

Diese Seite richtet sich an GKE-Identitäts- und Kontoadministratoren und Entwickler, die Roll-out-Vorgänge für GKE Inference Gateway ausführen möchten.

Die folgenden Anwendungsfälle werden unterstützt:

Roll-out eines Knotenupdates

Bei Knotenupdates werden Inferenzarbeitslasten sicher zu neuen Knoten- oder Accelerator-Konfigurationen migriert. Dieser Vorgang erfolgt kontrolliert, ohne den Modelldienst zu unterbrechen. Verwenden Sie Knotenupdates, um Dienstunterbrechungen bei Hardware-Upgrades, Treiberupdates oder der Behebung von Sicherheitsproblemen zu minimieren.

  1. Neuen InferencePool erstellen: Stellen Sie einen InferencePool bereit, der mit den aktualisierten Knoten- oder Hardwarespezifikationen konfiguriert ist.

  2. Traffic mit einer HTTPRoute aufteilen: Konfigurieren Sie eine HTTPRoute, um Traffic zwischen den vorhandenen und neuen InferencePool-Ressourcen zu verteilen. Verwenden Sie das Feld weight in backendRefs, um den Trafficanteil zu verwalten, der an die neuen Knoten weitergeleitet wird.

  3. Konsistentes InferenceObjective beibehalten: Behalten Sie die vorhandene InferenceObjective Konfiguration bei, um ein einheitliches Modellverhalten in beiden Knotenkonfigurationen zu gewährleisten.

  4. Ursprüngliche Ressourcen beibehalten: Lassen Sie den ursprünglichen InferencePool und die Knoten während des Roll-outs aktiv, um bei Bedarf Rollbacks zu ermöglichen.

Sie können beispielsweise einen neuen InferencePool mit dem Namen llm-new erstellen. Konfigurieren Sie diesen Pool mit derselben Modellkonfiguration wie Ihr vorhandener InferencePool llm. Stellen Sie den Pool auf einer neuen Gruppe von Knoten in Ihrem Cluster bereit. Verwenden Sie ein HTTPRoute Objekt, um den Traffic zwischen dem ursprünglichen llm und dem neuen llm-new InferencePool aufzuteilen. Mit dieser Methode können Sie Ihre Modellknoten schrittweise aktualisieren.

Das folgende Diagramm zeigt, wie GKE Inference Gateway einen Roll-out für Knotenupdates ausführt.

Prozess für die Einführung von Knotenupdates
Abbildung: Roll-out-Prozess für Knotenupdates

So führen Sie einen Roll-out für Knotenupdates aus:

  1. Speichern Sie das folgende Beispielmanifest als routes-to-llm.yaml:

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

  2. Wenden Sie das Beispielmanifest auf Ihren Cluster an:

    kubectl apply -f routes-to-llm.yaml

Der ursprüngliche llm InferencePool erhält den Großteil des Traffics, während der llm-new InferencePool den Rest erhält. Erhöhen Sie das Traffic-Gewicht für den InferencePool llm-new schrittweise, um den Roll-out für Knotenupdates abzuschließen.

Roll-out eines Basismodells

Roll-outs von Basismodellupdates erfolgen in Phasen zu einem neuen Basis-LLM, wobei die Kompatibilität mit vorhandenen LoRA-Adaptern beibehalten wird. Sie können Roll-outs von Basismodellupdates verwenden, um auf verbesserte Modellarchitekturen umzusteigen oder modellspezifische Probleme zu beheben.

So führen Sie einen Roll-out für ein Basismodellupdate aus:

  1. Neue Infrastruktur bereitstellen: Erstellen Sie neue Knoten und einen neuen InferencePool konfiguriert mit dem neuen Basismodell, das Sie ausgewählt haben.
  2. Verteilung des Traffics konfigurieren: Verwenden Sie eine HTTPRoute, um den Traffic zwischen dem vorhandenen InferencePool (der das alte Basismodell verwendet) und dem neuen InferencePool (der das neue Basismodell verwendet) aufzuteilen. Das Feld backendRefs weight steuert den Trafficanteil, der jedem Pool zugewiesen wird.
  3. InferenceObjective-Integrität beibehalten: Behalten Sie die Konfiguration von InferenceObjective unverändert bei. So wird sichergestellt, dass das System dieselben LoRA-Adapter konsistent für beide Basismodellversionen verwendet.
  4. Rollback-Funktion beibehalten: Behalten Sie die ursprünglichen Knoten und InferencePool während des Roll-outs bei, um bei Bedarf ein Rollback zu ermöglichen.

Sie erstellen einen neuen InferencePool mit dem Namen llm-pool-version-2. In diesem Pool wird eine neue Version des Basismodells auf einer neuen Gruppe von Knoten bereitgestellt. Wenn Sie eine HTTPRoute konfigurieren, wie im Beispiel gezeigt, können Sie den Traffic schrittweise zwischen dem ursprünglichen llm-pool und llm-pool-version-2 aufteilen. So können Sie Basismodellupdates in Ihrem Cluster steuern.

So führen Sie einen Roll-out für ein Basismodellupdate aus:

  1. Speichern Sie das folgende Beispielmanifest als routes-to-llm.yaml:

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

  2. Wenden Sie das Beispielmanifest auf Ihren Cluster an:

    kubectl apply -f routes-to-llm.yaml

Der ursprüngliche llm-pool InferencePool erhält den Großteil des Traffics, während der llm-pool-version-2 InferencePool den Rest erhält. Erhöhen Sie das Traffic-Gewicht für den InferencePool llm-pool-version-2 schrittweise, um den Roll-out für Basismodellupdates abzuschließen.

Nächste Schritte