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

Auf dieser Seite wird beschrieben, wie Sie für das GKE Inference Gateway Vorgänge für die inkrementelle Bereitstellung ausführen, mit denen neue Versionen Ihrer Inferenzinfrastruktur nach und nach 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 Ausführen von Rollbacks, 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

Bei Knotenupdates werden Inferenzarbeitslasten sicher auf neue Knotenhardware oder Beschleunigerkonfigurationen migriert. Dieser Vorgang erfolgt kontrolliert, ohne den Modelldienst zu unterbrechen. Mit Knotenupdates können Sie Dienstunterbrechungen bei Hardware-Upgrades, Treiberupdates oder der Behebung von Sicherheitsproblemen 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 InferenceObjective beibehalten: Behalten Sie die vorhandene InferenceObjective-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

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
      group: inference.networking.k8s.io
      kind: InferenceGateway
  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

Die ursprüngliche llm InferencePool erhält den Großteil des Traffics, die llm-new InferencePool den Rest. 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 einen neuen InferencePool, der 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
      group: inference.networking.k8s.io
      kind: InferenceGateway
  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

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.

Nächste Schritte