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

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

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

Die folgenden Anwendungsfälle werden unterstützt:

Knoten-Rollout aktualisieren

Durch die Einführung von Knotenupdates werden Inferenzarbeitslasten sicher auf neue Knotenhardware oder Beschleunigerkonfigurationen migriert. Dieser Vorgang erfolgt kontrolliert, ohne den Modelldienst zu unterbrechen. Verwenden Sie Node-Update-Rollouts, um Dienstunterbrechungen während Hardware-Upgrades, Treiber-Updates oder der Behebung von Sicherheitsproblemen zu minimieren.

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

  2. Traffic mit einem HTTPRoute aufteilen: Konfigurieren Sie ein HTTPRoute, um den Traffic zwischen den vorhandenen und neuen InferencePool-Ressourcen aufzuteilen. 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. Originalressourcen beibehalten: Behalten Sie die ursprünglichen InferencePool und Knoten während der Einführung bei, 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 Technik können Sie Ihre Modellknoten inkrementell aktualisieren.

Das folgende Diagramm zeigt, wie GKE Inference Gateway ein Node-Update-Roll-out durchführt.

Prozess für die Einführung von Knotenupdates
Abbildung: Prozess für die Einführung von Knotenupdates

Führen Sie die folgenden Schritte aus, um ein Knotenupdate durchzuführen:

  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 restlichen Traffic erhält. Erhöhen Sie das Traffic-Gewicht für llm-new InferencePool nach und nach, um die Einführung des Knotenupdates abzuschließen.

Basismodell einführen

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

So führen Sie ein Update eines Basismodells aus:

  1. Neue Infrastruktur bereitstellen: Erstellen Sie neue Knoten und eine neue InferencePool, die mit dem neuen ausgewählten Basismodell konfiguriert ist.
  2. Traffic-Verteilung konfigurieren: Verwenden Sie ein HTTPRoute, um den Traffic zwischen dem vorhandenen InferencePool (mit dem alten Basismodell) und dem neuen InferencePool (mit dem neuen Basismodell) aufzuteilen. Mit dem Feld backendRefs weight wird der Prozentsatz des Traffics gesteuert, der jedem Pool zugewiesen wird.
  3. Integrität von InferenceModel beibehalten: Die InferenceModel-Konfiguration bleibt unverändert. So wird sichergestellt, dass das System dieselben LoRA-Adapter konsistent für 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 ein neues 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 Updates des Basismodells in Ihrem Cluster steuern.

So führen Sie die Einführung eines Updates für das Basismodell 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 des Traffics, die llm-pool-version-2 InferencePool den Rest. Erhöhen Sie das Trafficgewicht für llm-pool-version-2 InferencePool schrittweise, um die Einführung des Updates des Basismodells abzuschließen.

LoRA-Adapter-Updates einführen

Mit der Einführung von LoRA-Adaptern können Sie neue Versionen von feinabgestimmten Modellen phasenweise bereitstellen, ohne das zugrunde liegende Basismodell oder die Infrastruktur zu ändern. Mit 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 Adapter-Rollout.

  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: Verwenden Sie das Feld weight in der InferenceModel-Spezifikation, um die Traffic-Verteilung auf die verschiedenen LoRA-Adapterversionen zu steuern.

  4. Einheitliche poolRef beibehalten: Alle LoRA-Adapterversionen müssen auf dieselbe InferencePool verweisen. Dadurch werden Knoten- oder InferencePool-Neubereitstellungen verhindert. 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. Beide Versionen verwenden dasselbe Basismodell. Sie definieren llm-v1 und llm-v2 innerhalb desselben InferenceModel. Sie weisen Gewichte zu, um den Traffic schrittweise von llm-v1 zu llm-v2 zu verschieben. Diese Steuerung ermöglicht eine kontrollierte Einführung, ohne dass Änderungen an Ihren Knoten oder der InferencePool-Konfiguration erforderlich sind.

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 Version llm-v1 erhält den Großteil des Traffics, die Version llm-v2 den Rest. Erhöhen Sie das Traffic-Gewicht für die llm-v2-Version schrittweise, um die Einführung des LoRA-Adapters abzuschließen.

Nächste Schritte