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

Auf dieser Seite erfahren Sie, wie Sie für das GKE Inference Gateway inkrementelle Roll-out-Vorgänge ausführen, bei denen neue Versionen Ihrer Inferenzinfrastruktur nach und nach bereitgestellt werden. Über dieses 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 Informationen zur Traffic-Aufteilung und zu Rollbacks, um zuverlässige Bereitstellungen zu ermöglichen.

Diese Seite richtet sich an GKE-Identitäts- und Kontoadministratoren sowie Entwickler, die das GKE Inference Gateway einrichten möchten.

Die folgenden Anwendungsfälle werden unterstützt:

Knoten-Roll-out aktualisieren

Beim Roll-out von Knotenupdates werden Inferenzarbeitslasten sicher auf neue Knotenhardware oder Beschleunigerkonfigurationen migriert. Dieser Vorgang erfolgt kontrolliert, ohne den Modelldienst zu unterbrechen. Mit der Einführung von Knotenupdates können Sie Dienstunterbrechungen bei Hardware-Upgrades, Treiberupdates oder der Behebung von Sicherheitsproblemen minimieren.

  1. Neues InferencePool erstellen: Stellen Sie ein InferencePool bereit, das mit den aktualisierten Knoten- oder Hardwarespezifikationen konfiguriert ist.

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

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

  4. Ursprüngliche Ressourcen beibehalten: Lassen Sie die ursprünglichen InferencePool und Knoten während der Einführung aktiv, um bei Bedarf Rollbacks zu ermöglichen.

Sie können beispielsweise eine neue InferencePool mit dem Namen llm-new erstellen. Konfigurieren Sie diesen Pool mit derselben Modellkonfiguration wie Ihre vorhandene llm InferencePool. 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 das GKE Inference Gateway ein Knotenupdate durchführt.

Einführung von Knotenupdates
Abbildung: Einführungsprozess für Knotenupdates

So führen Sie ein Knotenupdate durch:

  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
  rules:
    backendRefs:
    - name: llm
      kind: InferencePool
      weight: 90
    - name: llm-new
      kind: InferencePool
      weight: 10

  2. Wenden Sie das Beispielmanifest auf Ihren Cluster an:

    kubectl apply -f routes-to-llm.yaml

Die ursprüngliche llm InferencePool erhält den Großteil des Traffics, während die llm-new InferencePool den Rest des Traffics erhält. Erhöhen Sie die Gewichtung der Zugriffe für den llm-new InferencePool nach und nach, um die Einführung des Knotenupdates abzuschließen.

Basismodell einführen

Updates des Basismodells werden in Phasen für ein neues Basis-LLM eingeführt, wobei die Kompatibilität mit vorhandenen LoRA-Adaptern erhalten bleibt. Sie können die Einführung von Basismodellupdates nutzen, um auf verbesserte Modellarchitekturen umzustellen oder modellspezifisch auftretende Probleme zu beheben.

So führen Sie ein Update des Basismodells ein:

  1. Neue Infrastruktur bereitstellen: Erstellen Sie neue Knoten und eine neue InferencePool, die mit dem von Ihnen ausgewählten neuen Basismodell konfiguriert ist.
  2. Traffic-Verteilung konfigurieren: Verwenden Sie eine HTTPRoute, um den Traffic zwischen der vorhandenen InferencePool (mit dem alten Basismodell) und der neuen InferencePool (mit dem neuen Basismodell) aufzuteilen. Im Feld backendRefs weight wird der prozentualen Anteil des Traffics festgelegt, der jedem Pool zugewiesen wird.
  3. InferenceModel-Integrität aufrechterhalten: Lassen Sie die InferenceModel-Konfiguration unverändert. So wird sichergestellt, dass das System dieselben LoRA-Adapter konsistent auf beide Basismodellversionen anwendet.
  4. Rollback-Funktion beibehalten: Behalten Sie die ursprünglichen Knoten und InferencePool während der Einführung 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 einen 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 Aktualisierungen des Basismodells in Ihrem Cluster steuern.

So führen Sie ein Update des Basismodells durch:

  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
  rules:
    backendRefs:
    - name: llm-pool
      kind: InferencePool
      weight: 90
    - name: llm-pool-version-2
      kind: InferencePool
      weight: 10

  2. Wenden Sie das Beispielmanifest auf Ihren Cluster an:

    kubectl apply -f routes-to-llm.yaml

Die ursprüngliche llm-pool InferencePool erhält den Großteil der Zugriffe, während die llm-pool-version-2 InferencePool den Rest erhält. Erhöhen Sie das Gewicht des Traffics für die llm-pool-version-2 InferencePool nach und nach, um die Einführung des aktualisierten Basismodells abzuschließen.

LoRA-Adapter-Updates einführen

Mit der Einführung von LoRA-Adapter-Updates können Sie neue Versionen optimierter Modelle in Phasen bereitstellen, ohne das zugrunde liegende Basismodell oder die Infrastruktur zu ändern. Mit der Einführung von LoRA-Adapter-Updates können Sie Verbesserungen, Fehlerkorrekturen oder neue Funktionen in Ihren LoRA-Adaptern testen.

So aktualisieren Sie einen LoRa-Adapter:

  1. Adapter verfügbar machen: Achten Sie darauf, dass die neuen LoRA-Adapterversionen auf den Modellservern verfügbar sind. Weitere Informationen finden Sie unter Roll-out des Adapters.

  2. InferenceModel-Konfiguration ändern: Definieren Sie in Ihrer vorhandenen InferenceModel-Konfiguration mehrere Versionen Ihres LoRA-Adapters. Weisen Sie jeder Version eine eindeutige modelName zu (z. B. llm-v1, llm-v2).

  3. Traffic verteilen: Mit dem Feld weight in der InferenceModel-Spezifikation können Sie die Traffic-Verteilung auf die verschiedenen LoRA-Adapterversionen steuern.

  4. Einheitliche poolRef verwenden: Alle LoRA-Adapterversionen müssen auf dieselbe InferencePool verweisen. Dadurch wird verhindert, dass Knoten oder InferencePool neu bereitgestellt werden. Behalten Sie vorherige LoRA-Adapterversionen in der InferenceModel-Konfiguration bei, um Rollbacks zu ermöglichen.

Das folgende Beispiel zeigt zwei LoRA-Adapterversionen, llm-v1 und llm-v2. Für beide Versionen wird dasselbe Basismodell verwendet. Sie definieren llm-v1 und llm-v2 innerhalb derselben InferenceModel. Sie weisen Gewichte zu, um den Traffic schrittweise von llm-v1 auf llm-v2 umzuverteilen. Mit dieser Einstellung können Sie ein kontrolliertes Roll-out durchführen, ohne Änderungen an Ihren Knoten oder an der InferencePool-Konfiguration vornehmen zu müssen.

Führen Sie den folgenden Befehl aus, um LoRA-Adapter-Updates bereitzustellen:

  1. Speichern Sie das folgende Beispielmanifest als 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. Wenden Sie das Beispielmanifest auf Ihren Cluster an:

    kubectl apply -f inferencemodel-sample.yaml

Die llm-v1-Version erhält den Großteil des Traffics, während die llm-v2-Version den Rest erhält. Erhöhen Sie das Traffic-Gewicht für die llm-v2-Version schrittweise, um die Einführung des LoRA-Adapterupdates abzuschließen.

Nächste Schritte