Modellladen in GKE mit Run:ai Model Streamer beschleunigen

Autopilot Standard

In diesem Dokument erfahren Sie, wie Sie das Laden der großen KI-Modellgewichte aus Cloud Storage mit Run:ai Model Streamer mit dem vLLM-Inferenzserver in Google Kubernetes Engine (GKE) beschleunigen können.

Bei der Lösung in diesem Dokument wird davon ausgegangen, dass Sie Ihr KI-Modell und die Gewichte im safetensors-Format bereits in einen Cloud Storage-Bucket hochgeladen haben.

Wenn Sie Ihrer vLLM-Bereitstellung das Flag --load-format=runai_streamer hinzufügen, können Sie den Run:ai Model Streamer verwenden, um die Effizienz des Modell-Downloads für Ihre KI-Arbeitslasten in GKE zu verbessern.

Dieses Dokument richtet sich an die folgenden Nutzer:

• ML-Entwickler, die große KI-Modelle so schnell wie möglich aus dem Objektspeicher in GPU-/TPU-Knoten laden müssen.
• Plattformadministratoren und ‑operatoren, die die Infrastruktur für die Bereitstellung von Modellen in GKE automatisieren und optimieren.
• Cloud-Architekten, die spezielle Tools zum Laden von Daten für KI-/ML-Arbeitslasten bewerten.

Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die in Google Cloud Inhalten verwiesen wird, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

Übersicht

Die in diesem Dokument beschriebene Lösung verwendet drei Kernkomponenten: Run:ai Model Streamer, vLLM und das safetensors-Dateiformat, um das Laden von Modellgewichten aus Cloud Storage auf GPU-Knoten zu beschleunigen.

Run:ai Model Streamer

Run:ai Model Streamer ist ein Open-Source-Python SDK, das das Laden großer KI-Modelle auf GPUs beschleunigt. Die Modellgewichte werden direkt aus dem Speicher, z. B. Cloud Storage-Buckets, in den GPU-Arbeitsspeicher gestreamt. Der Modell-Streamer eignet sich besonders für den Zugriff auf safetensors-Dateien in Cloud Storage.

Safetensors

safetensors ist ein Dateiformat zum Speichern von Tensoren, den wichtigsten Datenstrukturen in KI-Modellen, das sowohl die Sicherheit als auch die Geschwindigkeit verbessert. safetensors ist als Alternative zum Pickle-Format von Python konzipiert und ermöglicht durch einen Zero-Copy-Ansatz schnelle Ladezeiten. So können die Tensoren direkt von der Quelle aus aufgerufen werden, ohne dass die gesamte Datei zuerst in den lokalen Speicher geladen werden muss.

vLLM

vLLM ist eine Open-Source-Bibliothek für LLM-Inferenz und ‑Bereitstellung. Es handelt sich um einen leistungsstarken Inferenzserver, der für das schnelle Laden großer KI-Modelle optimiert ist. In diesem Dokument ist vLLM die Core-Engine, die Ihr KI-Modell in GKE ausführt und eingehende Inferenzanfragen verarbeitet. Die integrierte Authentifizierungsunterstützung von Run:ai Model Streamer für Cloud Storage erfordert vLLM-Version 0.11.1 oder höher.

Wie Run:ai Model Streamer das Laden von Modellen beschleunigt

Wenn Sie eine LLM-basierte KI-Anwendung für die Inferenz starten, tritt oft eine erhebliche Verzögerung auf, bevor das Modell einsatzbereit ist. Diese Verzögerung, auch Kaltstart genannt, tritt auf, weil die gesamte mehrere Gigabyte große Modelldatei von einem Speicherort wie einem Cloud Storage-Bucket auf die lokale Festplatte Ihres Computers heruntergeladen werden muss. Die Datei wird dann in den Speicher Ihrer GPU geladen. Während dieser Ladezeit ist die teure GPU inaktiv, was ineffizient und kostspielig ist.

Anstelle des Prozesses „Herunterladen und dann laden“ streamt der Modell-Streamer das Modell direkt aus Ihrem Cloud Storage in den Speicher der GPU. Der Streamer verwendet ein leistungsstarkes Backend, um mehrere Teile des Modells, sogenannte Tensoren, parallel zu lesen. Das gleichzeitige Lesen von Tensoren ist deutlich schneller als das sequenzielle Laden der Datei.

Architektur

Der Run:ai Model Streamer lässt sich in vLLM in GKE einbinden, um das Laden von Modellen zu beschleunigen. Dazu werden Modellgewichte direkt aus Cloud Storage in den GPU-Arbeitsspeicher gestreamt, ohne dass die lokale Festplatte verwendet wird.

Das folgende Diagramm zeigt diese Architektur:

Run:ai Model Streamer-Architektur mit vLLM und Cloud Storage.

Diese Architektur umfasst die folgenden Komponenten und den folgenden Workflow:

• Cloud Storage-Bucket: Hier werden die Gewichte des KI-Modells im safetensors-Format gespeichert.
• GKE-Pod mit GPU: Führt den vLLM-Inferenzserver aus.
• vLLM-Inferenzserver: Konfiguriert mit dem Flag --load-format=runai_streamer, das die Modell-Streamer-Funktion aktiviert.
• Run:ai Model Streamer: Beim Start von vLLM liest der Model Streamer Modellgewichte aus dem angegebenen gs://-Pfad im Cloud Storage-Bucket. Anstatt Dateien auf die Festplatte herunterzuladen, werden Tensordaten direkt in den GPU-Arbeitsspeicher des GKE-Pods gestreamt, wo sie sofort für die Inferenz in vLLM verfügbar sind.
• Cloud Storage Anywhere Cache (optional): Wenn diese Option aktiviert ist, werden Bucket-Daten durch Anywhere Cache in derselben Zone wie die GKE-Knoten zwischengespeichert, wodurch der Datenzugriff für den Streamer weiter beschleunigt wird.

Vorteile

• Kürzere Kaltstartzeiten:Der Modell-Streamer verkürzt die Zeit, die zum Starten von Modellen benötigt wird, erheblich. Die Modellgewichte werden im Vergleich zu herkömmlichen Methoden bis zu sechsmal schneller geladen. Weitere Informationen finden Sie unter Run:ai Model Streamer-Benchmarks.
• Verbesserte GPU-Auslastung:Durch die Minimierung von Verzögerungen beim Laden von Modellen können GPUs mehr Zeit für tatsächliche Inferenzaufgaben aufwenden, was die Gesamteffizienz und Verarbeitungskapazität steigert.
• Optimierter Workflow:Die in diesem Dokument beschriebene Lösung lässt sich in GKE einbinden, sodass Inferenzserver wie vLLM oder SGLang direkt auf Modelle in Cloud Storage-Buckets zugreifen können.

Hinweise

Führen Sie die folgenden Schritte aus.

Projekt auswählen oder erstellen und APIs aktivieren

Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

• Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
• Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Enable the Kubernetes Engine, Cloud Storage, Compute Engine, IAM APIs.

Roles required to enable APIs

To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

Enable the APIs

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

• Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
• Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Enable the Kubernetes Engine, Cloud Storage, Compute Engine, IAM APIs.

Roles required to enable APIs

To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

Enable the APIs

Cloud Shell einrichten

In diesem Dokument werden die Google Cloud CLI- und kubectl-Befehle verwendet, um die für diese Lösung erforderlichen Ressourcen zu erstellen und zu verwalten. Sie können diese Befehle in Cloud Shell ausführen, indem Sie oben in der Google Cloud Konsole auf Cloud Shell aktivieren klicken.

In the Google Cloud console, activate Cloud Shell.

Activate Cloud Shell

Alternativ können Sie die gcloud CLI in Ihrer lokalen Shellumgebung installieren und initialisieren, um die Befehle auszuführen. Wenn Sie ein lokales Shell-Terminal verwenden möchten, führen Sie den Befehl gcloud auth login aus, um sich bei Google Cloudzu authentifizieren.

IAM-Rollen zuweisen

Prüfen Sie, ob Ihr Google Cloud -Konto die folgenden IAM-Rollen für Ihr Projekt hat, damit Sie einen GKE-Cluster erstellen und Cloud Storage verwalten können:

• roles/container.admin
• roles/storage.admin

Führen Sie die folgenden Befehle aus, um diese Rollen zuzuweisen:

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="user:$(gcloud config get-value account)" \
    --role="roles/container.admin"
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="user:$(gcloud config get-value account)" \
    --role="roles/storage.admin"

Ersetzen Sie PROJECT_ID durch Ihre Projekt-ID.

Umgebung vorbereiten

In diesem Abschnitt erfahren Sie, wie Sie Ihren GKE-Cluster einrichten und Berechtigungen für den Zugriff auf Ihr Modell in Cloud Storage konfigurieren.

Hinweis :Ihr KI-Modell muss im safetensors-Format in einem Cloud Storage-Bucket gespeichert sein.

GKE-Cluster mit GPUs erstellen

Der Run:ai Model Streamer kann sowohl mit GKE Autopilot- als auch mit Standardclustern verwendet werden. Wählen Sie den Clustermodus aus, der Ihren Anforderungen am besten entspricht.

1. Legen Sie Variablen für Ihr Projekt und den Clusternamen fest:

   export PROJECT_ID=PROJECT_ID
   export CLUSTER_NAME=CLUSTER_NAME
   

   Ersetzen Sie Folgendes:

   • PROJECT_ID: Projekt-ID in Google Cloud . Sie können Ihre Projekt-ID mit dem Befehl gcloud config get-value project ermitteln.
   • CLUSTER_NAME ist der Name Ihres Clusters. Beispiel: run-ai-test.

2. Erstellen Sie entweder einen Autopilot- oder einen Standardcluster:

   Autopilot

   So erstellen Sie einen GKE Autopilot-Cluster:

   1. Legen Sie die Region für den Cluster fest:

      export REGION=REGION
      

      Ersetzen Sie REGION durch die Region, in der Sie den Cluster erstellen möchten. Für eine optimale Leistung sollten Sie dieselbe Region wie für Ihren Cloud Storage-Bucket verwenden.

   2. Erstellen Sie den Cluster:

      gcloud container clusters create-auto $CLUSTER_NAME \
          --project=$PROJECT_ID \
          --location=$REGION
      

   Bei Autopilot-Clustern werden Knoten automatisch auf Grundlage der Arbeitslastanforderungen bereitgestellt. Wenn Sie den vLLM-Server in einem späteren Schritt bereitstellen, werden die GPU-Knoten bei Bedarf von Autopilot bereitgestellt. Weitere Informationen finden Sie unter Automatische Erstellung von Knotenpools.

   Standard

   So erstellen Sie einen GKE-Standardcluster:

   1. Legen Sie die Zone für Ihren Cluster fest:

      export ZONE=ZONE
      

      Ersetzen Sie ZONE durch die Zone, in der Sie den Cluster erstellen möchten. Für eine optimale Leistung sollten Sie eine Zone in derselben Region wie Ihr Cloud Storage-Bucket verwenden.

   2. Erstellen Sie den Cluster:

      gcloud container clusters create $CLUSTER_NAME \
          --project=$PROJECT_ID \
          --zone=$ZONE \
          --workload-pool=$PROJECT_ID.svc.id.goog \
          --num-nodes=1
      

   3. Knotenpool mit einer G2-Maschine (NVIDIA L4-GPU) erstellen:

      gcloud container node-pools create g2-gpu-pool \
          --cluster=$CLUSTER_NAME \
          --zone=$ZONE \
          --machine-type=g2-standard-16 \
          --num-nodes=1 \
          --accelerator=type=nvidia-l4
      

Workload Identity Federation for GKE konfigurieren

Konfigurieren Sie die Identitätsföderation von Arbeitslasten für GKE, damit Ihre GKE-Arbeitslasten sicher auf das Modell in Ihrem Cloud Storage-Bucket zugreifen können.

1. Legen Sie Variablen für Ihr Kubernetes-Dienstkonto und Ihren Namespace fest:

   export KSA_NAME=KSA_NAME
   export NAMESPACE=NAMESPACE
   

   Ersetzen Sie Folgendes:

   • NAMESPACE: der Namespace, in dem Ihre Arbeitslasten ausgeführt werden sollen. Achten Sie darauf, für alle Ressourcen in diesem Dokument denselben Namespace zu verwenden.
   • KSA_NAME: der Name des Kubernetes-Dienstkontos, das Ihr Pod zur Authentifizierung bei Google Cloud -APIs verwenden kann.

2. Erstellen Sie einen Kubernetes-Namespace:

   kubectl create namespace $NAMESPACE
   

3. Erstellen Sie ein Kubernetes-Dienstkonto (Kubernetes service account, KSA):

   kubectl create serviceaccount $KSA_NAME \
       --namespace=$NAMESPACE
   

   Achtung :Um das Prinzip der geringsten Berechtigung einzuhalten, sollten Sie dieses Kubernetes-Dienstkonto nicht in anderen Pods im selben Namespace wiederverwenden. Jede Arbeitslast, die dieses Dienstkonto verwendet, hat unbeabsichtigt Zugriff auf den angegebenen Cloud Storage-Bucket.

4. Erteilen Sie Ihrem KSA die erforderlichen Berechtigungen:

   1. Legen Sie die Umgebungsvariablen fest:

      export BUCKET_NAME=BUCKET_NAME
      export PROJECT_ID=PROJECT_ID
      export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID \
          --format 'get(projectNumber)')
      

      Ersetzen Sie Folgendes:

      • BUCKET_NAME: der Name Ihres Cloud Storage-Bucket, der Ihre safetensors-Dateien enthält.
      • PROJECT_ID: Projekt-ID in Google Cloud .

      Die Werte PROJECT_NUMBER, PROJECT_ID, NAMESPACE und KSA_NAME werden in den folgenden Schritten verwendet, um die Prinzipal-ID der Identitätsföderation von Arbeitslasten für GKE für Ihr Projekt zu erstellen.

   2. Weisen Sie Ihrem KSA die Rolle roles/storage.bucketViewer zu, damit Objekte in Ihrem Cloud Storage-Bucket angezeigt werden können:

      gcloud storage buckets add-iam-policy-binding gs://$BUCKET_NAME \
          --member="principal://iam.googleapis.com/projects/$PROJECT_NUMBER/locations/global/workloadIdentityPools/$PROJECT_ID.svc.id.goog/subject/ns/$NAMESPACE/sa/$KSA_NAME" \
          --role="roles/storage.bucketViewer"
      

   3. Erteilen Sie Ihrem KSA die Rolle roles/storage.objectUser, damit Objekte in Ihrem Cloud Storage-Bucket gelesen, geschrieben und gelöscht werden können:

      gcloud storage buckets add-iam-policy-binding gs://$BUCKET_NAME \
          --member="principal://iam.googleapis.com/projects/$PROJECT_NUMBER/locations/global/workloadIdentityPools/$PROJECT_ID.svc.id.goog/subject/ns/$NAMESPACE/sa/$KSA_NAME" \
          --role="roles/storage.objectUser"
      

Sie haben jetzt einen GKE-Cluster mit GPUs eingerichtet und die Workload Identity-Föderation für GKE konfiguriert. Dadurch wird einem Kubernetes-Dienstkonto die erforderlichen Berechtigungen für den Zugriff auf Ihr KI-Modell in Cloud Storage gewährt. Nachdem Sie den Cluster und die Berechtigungen eingerichtet haben, können Sie den vLLM-Inferenzserver bereitstellen. Dieser verwendet das Dienstkonto, um Modellgewichte mit dem Run:ai Model Streamer zu streamen.

vLLM mit dem Run:ai Model Streamer bereitstellen

Stellen Sie einen Pod bereit, auf dem der vLLM OpenAI-kompatible Server ausgeführt wird und der mit dem Flag --load-format=runai_streamer konfiguriert ist, um den Run:ai Model Streamer zu verwenden. Die vLLM-Version muss 0.11.1 oder höher sein.

Das folgende Beispielmanifest zeigt eine vLLM-Konfiguration mit aktiviertem Modell-Streamer für ein kleines Modell wie gemma-2-9b-it mit einer einzelnen NVIDIA L4-GPU.

• Wenn Sie ein großes Modell verwenden, für das mehrere GPUs erforderlich sind, erhöhen Sie den Wert von --tensor-parallel-size auf die erforderliche Anzahl von GPUs.
• Mit dem Flag --model-loader-extra-config='{"distributed":true}' wird das verteilte Laden von Modellgewichten aktiviert. Dies ist eine empfohlene Einstellung zur Verbesserung der Leistung beim Laden von Modellen aus dem Objektspeicher.

Weitere Informationen finden Sie unter Tensor-Parallelismus und Abstimmbare Parameter.

1. Speichern Sie das folgende Manifest als vllm-deployment.yaml. Das Manifest ist so konzipiert, dass es sowohl in Autopilot- als auch in Standardclustern flexibel eingesetzt werden kann.

       apiVersion: apps/v1
       kind: Deployment
       metadata:
         name: vllm-streamer-deployment
         namespace: NAMESPACE
       spec:
         replicas: 1
         selector:
           matchLabels:
             app: vllm-streamer
         template:
           metadata:
             labels:
               app: vllm-streamer
           spec:
             serviceAccountName: KSA_NAME
             containers:
               - name: vllm-container
                 image: vllm/vllm-openai:v0.11.1
                 command:
                   - python3
                   - -m
                   - vllm.entrypoints.openai.api_server
                 args:
                   - --model=gs://BUCKET_NAME/PATH_TO_MODEL
                   - --load-format=runai_streamer
                   - --model-loader-extra-config={"distributed":true}
                   - --host=0.0.0.0
                   - --port=8000
                   - --disable-log-requests
                   - --tensor-parallel-size=1
                 ports:
                   - containerPort: 8000
                     name: api
                 # startupProbe allows for longer startup times for large models
                 startupProbe:
                   httpGet:
                     path: /health
                     port: 8000
                   failureThreshold: 60  # 60 * 10s = 10 minutes timeout
                   periodSeconds: 10
                   initialDelaySeconds: 30
                 readinessProbe:
                   httpGet:
                     path: /health
                     port: 8000
                   failureThreshold: 3
                   periodSeconds: 10
                 resources:
                   limits:
                     nvidia.com/gpu: "1"
                   requests:
                     nvidia.com/gpu: "1"
                 volumeMounts:
                 - mountPath: /dev/shm
                   name: dshm
             nodeSelector:
               cloud.google.com/gke-accelerator: nvidia-l4
             volumes:
             - emptyDir:
                 medium: Memory
               name: dshm
   

   Ersetzen Sie Folgendes:

   • NAMESPACE: Ihr Kubernetes-Namespace.
   • KSA_NAME: Der Name Ihres Kubernetes-Dienstkontos.
   • BUCKET_NAME: Name Ihres Cloud Storage-Buckets.
   • PATH_TO_MODEL: Der Pfad zu Ihrem Modellverzeichnis im Bucket, z. B. models/my-llama.

2. Wenden Sie das Manifest an, um das Deployment zu erstellen:

   kubectl create -f vllm-deployment.yaml
   

Mit dem GKE Inference Quickstart-Tool können Sie weitere vLLM-Manifeste generieren.

Deployment prüfen

1. Prüfen Sie den Status der Bereitstellung:

   kubectl get deployments -n NAMESPACE
   

2. Rufen Sie den Namen des Pods ab:

   kubectl get pods -n NAMESPACE | grep vllm-streamer
   

   Notieren Sie sich den Namen des Pods, der mit vllm-streamer-deployment beginnt.

3. So prüfen Sie, ob der Modell-Streamer das Modell und die Gewichte herunterlädt:

   kubectl logs -f POD_NAME -n NAMESPACE
   

   Ersetzen Sie POD_NAME durch den Namen des Pods aus dem vorherigen Schritt. Erfolgreiche Streaming-Logs sehen etwa so aus:

   [RunAI Streamer] Overall time to stream 15.0 GiB of all files: 13.4s, 1.1 GiB/s
   

Erfolg: Sie haben einen vLLM-Inferenzserver in GKE bereitgestellt und den Run:ai Model Streamer verwendet, um das Laden von Modellen direkt aus Cloud Storage zu beschleunigen.

Optional: Leistung mit Anywhere Cache steigern

Mit Cloud Storage Anywhere Cache lässt sich das Laden von Modellen weiter beschleunigen, da Daten näher an Ihren GKE-Knoten gecacht werden. Das Caching ist besonders nützlich, wenn Sie mehrere Knoten in derselben Zone skalieren.

Sie aktivieren Anywhere Cache für einen bestimmten Cloud Storage-Bucket in einer bestimmten Google Cloud Zone. Zur Leistungsverbesserung muss die Zone des Cache mit der Zone übereinstimmen, in der Ihre GKE-Inferenz-Pods ausgeführt werden. Ihr Ansatz hängt davon ab, ob Ihre Pods in vorhersagbaren Zonen ausgeführt werden.

• Aktivieren Sie für zonale GKE Standard-Cluster, in denen Sie wissen, in welcher Zone Ihre Pods ausgeführt werden, Anywhere Cache für diese bestimmte Zone.

• Für regionale GKE-Cluster (Autopilot und Standard), in denen Pods in mehreren Zonen geplant werden können, haben Sie die folgenden Optionen:

  • Caching in allen Zonen aktivieren: Aktivieren Sie Anywhere Cache in jeder Zone in der Region des Clusters. So ist unabhängig davon, wo GKE Ihre Pods plant, immer ein Cache verfügbar. Beachten Sie, dass für jede Zone, in der das Caching aktiviert ist, Kosten anfallen. Weitere Informationen finden Sie unter Anywhere Cache-Preise.
  • Pods in einer bestimmten Zone platzieren: Verwenden Sie eine nodeSelector- oder nodeAffinity-Regel in Ihrem Arbeitslastmanifest, um Ihre Pods auf eine einzelne Zone zu beschränken. Anschließend können Sie Anywhere Cache nur in dieser Zone aktivieren. Dies ist ein kostengünstigerer Ansatz, wenn Ihre Arbeitslast auf eine einzelne Zone beschränkt werden kann.

Führen Sie die folgenden Befehle aus, um Anywhere Cache für die Zone zu aktivieren, in der sich Ihr GKE-Cluster befindet:

# Enable the cache
gcloud storage buckets anywhere-caches create gs://$BUCKET_NAME $ZONE

# Check the status of the cache
gcloud storage buckets anywhere-caches describe $BUCKET_NAME/$ZONE

Bereinigen

Damit Ihrem Google Cloud -Konto die in diesem Dokument verwendeten Ressourcen nicht in Rechnung gestellt werden, können Sie entweder das Projekt löschen, das die Ressourcen enthält, oder das Projekt beibehalten und die einzelnen Ressourcen löschen.

So löschen Sie die einzelnen Ressourcen:

1. Löschen Sie den GKE-Cluster. Bei dieser Aktion werden alle Knoten und Arbeitslasten entfernt.

   gcloud container clusters delete CLUSTER_NAME --location=ZONE_OR_REGION
   

   Ersetzen Sie Folgendes:

   • CLUSTER_NAME: Der Name Ihres Clusters.
   • ZONE_OR_REGION: Die Zone oder Region Ihres Clusters.

2. Deaktivieren Sie Anywhere Cache, falls Sie die Funktion aktiviert haben, um laufende Kosten zu vermeiden. Weitere Informationen finden Sie unter Cache deaktivieren.

Nächste Schritte

• Hugging Face-Modelle in Cloud Storage laden (experimentell)
• Informationen zum Bereitstellen von LLMs in GKE mit GPUs
• Weitere Informationen zu GPUs in GKE
• GKE-Speicherübersicht
• Workload Identity-Föderation konfigurieren