Diese Seite wurde von der Cloud Translation API übersetzt.

LLM mithilfe von TPU Trillium in GKE mit vLLM bereitstellen

Standard Autopilot

In dieser Anleitung wird beschrieben, wie Sie Large Language Models (LLMs) mit Tensor Processing Units (TPUs) in der Google Kubernetes Engine (GKE) mit dem vLLM-Bereitstellungs-Framework bereitstellen. In dieser Anleitung stellen Sie Llama 3.1 70b bereit, verwenden TPU Trillium und richten horizontales Pod-Autoscaling mithilfe von vLLM-Servermesswerten ein.

Dieses Dokument ist ein guter Ausgangspunkt, wenn Sie bei der Bereitstellung und Zugänglichmachung Ihrer KI/ML-Arbeitslasten die detaillierte Kontrolle, Skalierbarkeit, Robustheit, Übertragbarkeit und Kosteneffizienz von verwaltetem Kubernetes benötigen.

Hintergrund

Wenn Sie TPU Trillium in GKE verwenden, können Sie eine robuste, produktionsreife Bereitstellungslösung mit allen Vorteilen von verwaltetem Kubernetes implementieren, einschließlich effizienter Skalierbarkeit und höherer Verfügbarkeit. In diesem Abschnitt werden die in diesem Leitfaden verwendeten Schlüsseltechnologien beschrieben.

TPU Trillium

TPUs sind von Google speziell entwickelte anwendungsspezifische integrierte Schaltungen (Application-Specific Integrated Circuits, ASICs). TPUs werden verwendet, um das maschinelle Lernen und die KI-Modelle zu beschleunigen, die mit Frameworks wie TensorFlow, PyTorch und JAX erstellt wurden. In dieser Anleitung wird TPU Trillium verwendet, die TPU der sechsten Generation von Google.

Bevor Sie TPUs in GKE verwenden, sollten Sie den folgenden Lernpfad durcharbeiten:

vLLM

vLLM ist ein hoch optimiertes Open-Source-Framework für die Bereitstellung von LLMs. vLLM kann den Bereitstellungsdurchsatz auf GPUs über Funktionen wie die Folgenden beschleunigen:

Optimierte Transformer-Implementierung mit PagedAttention
Kontinuierliche Batchverarbeitung zur Verbesserung des allgemeinen Bereitstellungsdurchsatzes.
Tensor-Parallelität und verteilte Bereitstellung auf mehreren TPUs

Weitere Informationen finden Sie in der vLLM-Dokumentation.

Cloud Storage FUSE

Cloud Storage FUSE bietet Zugriff von Ihrem GKE-Cluster auf Cloud Storage für Modellgewichte, die sich in Objektspeicher-Buckets befinden. In dieser Anleitung ist der erstellte Cloud Storage-Bucket anfangs leer. Beim Starten von vLLM lädt GKE das Modell von Hugging Face herunter und speichert die Gewichte im Cloud Storage-Bucket im Cache. Beim Neustart des Pods oder beim Skalieren der Bereitstellung werden bei nachfolgenden Modellladungen im Cache gespeicherte Daten aus dem Cloud Storage-Bucket heruntergeladen. Dabei werden parallele Downloads genutzt, um eine optimale Leistung zu erzielen.

Weitere Informationen finden Sie in der Dokumentation zum CSI-Treiber für Cloud Storage FUSE.

Lernziele

Diese Anleitung richtet sich an MLOps- oder DevOps-Entwickler oder Plattformadministratoren, die GKE-Orchestrierungsfunktionen zum Bereitstellen von LLMs verwenden möchten.

Diese Anleitung umfasst die folgenden Schritte:

Erstellen Sie einen GKE-Cluster mit der empfohlenen TPU Trillium-Topologie anhand der Modelleigenschaften.
Stellen Sie das vLLM-Framework in einem Knotenpool in Ihrem Cluster bereit.
Verwenden Sie das vLLM-Framework, um Llama 3.1 70b über einen Load Balancer bereitzustellen.
Richten Sie horizontales Pod-Autoscaling mit vLLM-Servermesswerten ein.
Modell bereitstellen

Hinweise

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.

Go to project selector

Make sure that billing is enabled for your Google Cloud project.

Enable the required API.

Enable the API

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

Go to project selector

Make sure that billing is enabled for your Google Cloud project.

Enable the required API.

Enable the API

Make sure that you have the following role or roles on the project: roles/container.admin, roles/iam.serviceAccountAdmin, roles/iam.securityAdmin, roles/artifactregistry.writer, roles/container.clusterAdmin
Check for the roles
1. In the Google Cloud console, go to the IAM page.
  Go to IAM
2. Select the project.
3. In the Principal column, find all rows that identify you or a group that you're included in. To learn which groups you're included in, contact your administrator.
4. For all rows that specify or include you, check the Role colunn to see whether the list of roles includes the required roles.
Grant the roles
1. In the Google Cloud console, go to the IAM page.
  IAM aufrufen
2. Wählen Sie das Projekt aus.
3. Klicken Sie auf Zugriff erlauben.
4. Geben Sie im Feld Neue Hauptkonten Ihre Nutzer-ID ein. Dies ist in der Regel die E-Mail-Adresse eines Google-Kontos.
5. Wählen Sie in der Liste Rolle auswählen eine Rolle aus.
6. Wenn Sie weitere Rollen hinzufügen möchten, klicken Sie auf Weitere Rolle hinzufügen und fügen Sie weitere Rollen hinzu.
7. Klicken Sie auf Speichern.

Erstellen Sie ein Hugging Face-Konto, falls Sie noch keines haben.
Prüfen Sie, ob Ihr Projekt ein ausreichendes Kontingent für Cloud TPU in GKE hat.

Umgebung vorbereiten

In diesem Abschnitt stellen Sie die Ressourcen bereit, die Sie zum Bereitstellen von vLLM und dem Modell benötigen.

Zugriff auf das Modell erhalten

Sie müssen die Einwilligungsvereinbarung unterzeichnen, um Llama 3.1 70b im Hugging Face-Repository verwenden zu können.

Zugriffstoken erstellen

Generieren Sie ein neues Hugging Face-Token, falls Sie noch keines haben:

Klicken Sie auf Profil > Einstellungen > Zugriffstokens.
Wählen Sie Neues Token aus.
Geben Sie einen Namen Ihrer Wahl und eine Rolle von mindestens Read an.
Wählen Sie Token generieren aus.

Cloud Shell starten

In dieser Anleitung verwenden Sie Cloud Shell zum Verwalten von Ressourcen, die inGoogle Cloudgehostet werden. Die Software, die Sie für diese Anleitung benötigen, ist in Cloud Shell vorinstalliert, einschließlich kubectl und der gcloud CLI.

So richten Sie Ihre Umgebung mit Cloud Shell ein:

Starten Sie in der Google Cloud -Konsole eine Cloud Shell-Sitzung. Klicken Sie dazu in der Google Cloud -Konsole auf Cloud Shell aktivieren. Dadurch wird im unteren Bereich der Google Cloud -Konsole eine Sitzung gestartet.
Legen Sie die Standardumgebungsvariablen fest:
```
gcloud config set project PROJECT_ID && \
export PROJECT_ID=$(gcloud config get project) && \
export PROJECT_NUMBER=$(gcloud projects describe ${PROJECT_ID} --format="value(projectNumber)") && \
export CLUSTER_NAME=CLUSTER_NAME && \
export ZONE=ZONE && \
export HF_TOKEN=HUGGING_FACE_TOKEN && \
export CLUSTER_VERSION=CLUSTER_VERSION && \
export GSBUCKET=GSBUCKET && \
export KSA_NAME=KSA_NAME && \
export NAMESPACE=NAMESPACE \
export IMAGE_NAME=IMAGE_NAME
```
Ersetzen Sie die folgenden Werte:
- PROJECT_ID: Ihre Google Cloud Projekt-ID.
- CLUSTER_NAME: der Name Ihres GKE-Clusters.
- ZONE: Eine Zone, die TPU Trillium (v6e) unterstützt.
- CLUSTER_VERSION: Die GKE-Version, die den gewünschten Maschinentyp unterstützen muss. Die GKE-Standardversion ist für Ihre Ziel-TPU möglicherweise nicht verfügbar. TPU Trillium wird in GKE-Versionen 1.31.2-gke.1115000 und höher unterstützt.
- GSBUCKET: Der Name des Cloud Storage-Bucket, der für Cloud Storage FUSE verwendet werden soll.
- KSA_NAME: Der Name des Kubernetes-Dienstkontos, das für den Zugriff auf Cloud Storage-Buckets verwendet wird. Der Bucketzugriff ist erforderlich, damit Cloud Storage FUSE funktioniert.
- NAMESPACE: der Kubernetes-Namespace, in dem Sie die vLLM-Assets bereitstellen möchten.
- IMAGE_NAME: Das TPU-Image für vLLM. Sie können das öffentliche Image docker.io/vllm/vllm-tpu:2e33fe419186c65a18da6668972d61d7bbc31564 verwenden oder ein eigenes erstellen.

GKE-Cluster erstellen

Sie können LLMs auf GPUs in einem GKE-Cluster im Autopilot- oder Standardmodus bereitstellen. Für eine vollständig verwaltete Kubernetes-Umgebung empfehlen wir die Verwendung eines Autopilot-Clusters. Informationen zum Auswählen des GKE-Betriebsmodus, der für Ihre Arbeitslasten am besten geeignet ist, finden Sie unter GKE-Betriebsmodus auswählen.

Autopilot

Erstellen Sie einen GKE Autopilot-Cluster:
```
gcloud container clusters create-auto CLUSTER_NAME \
    --cluster-version=CLUSTER_VERSION \
    --release-channel=rapid
```
Ersetzen Sie PROJECT_ID durch Ihre Google Cloud Projekt-ID.

Hinweis: Wenn Ihre Cloud Shell-Instanz während der Ausführung der Anleitung getrennt wird, wiederholen Sie den vorherigen Schritt.

Standard

So erstellen Sie einen GKE Standard-Cluster:

gcloud container clusters create CLUSTER_NAME \
    --project=PROJECT_ID \
    --zone=ZONE \
    --cluster-version=CLUSTER_VERSION \
    --release-channel=rapid \
    --workload-pool=PROJECT_ID.svc.id.goog \
    --addons GcsFuseCsiDriver

So erstellen Sie einen TPU-Slice-Knotenpool:
```
gcloud container node-pools create tpunodepool \
    --zone=ZONE \
    --num-nodes=1 \
    --machine-type=ct6e-standard-8t \
    --cluster=CLUSTER_NAME \
    --enable-autoscaling --total-min-nodes=1 --total-max-nodes=2
```
GKE erstellt die folgenden Ressourcen für das LLM:
- Ein GKE Standard-Cluster, der die Workload Identity-Föderation für GKE verwendet und für den der CSI-Treiber für Cloud Storage FUSE aktiviert ist.
- Ein TPU-Trillium-Knotenpool mit dem Maschinentyp ct6e-standard-8t. Dieser Knotenpool hat einen Knoten, acht TPU-Chips und das Autoscaling ist aktiviert.

Konfigurieren Sie kubectl für die Kommunikation mit Ihrem Cluster.

Führen Sie den folgenden Befehl aus, um kubectl für die Kommunikation mit Ihrem Cluster zu konfigurieren:

  gcloud container clusters get-credentials CLUSTER_NAME --location=ZONE

Kubernetes-Secret für Hugging Face-Anmeldedaten erstellen

Namespace erstellen Wenn Sie den default-Namespace verwenden, können Sie diesen Schritt überspringen:
```
kubectl create namespace NAMESPACE
```

Erstellen Sie ein Kubernetes-Secret, das das Hugging Face-Token enthält. Führen Sie dazu den folgenden Befehl aus:

kubectl create secret generic hf-secret \
    --from-literal=hf_api_token=HUGGING_FACE_TOKEN \
    --namespace NAMESPACE

Cloud Storage-Bucket erstellen

Führen Sie in Cloud Shell den folgenden Befehl aus:

gcloud storage buckets create gs://GSBUCKET \
    --uniform-bucket-level-access

Dadurch wird ein Cloud Storage-Bucket zum Speichern der Modelldateien erstellt, die Sie von Hugging Face herunterladen.

Kubernetes-Dienstkonto für den Zugriff auf den Bucket einrichten

Erstellen Sie das Kubernetes-Dienstkonto:

kubectl create serviceaccount KSA_NAME --namespace NAMESPACE

Gewähren Sie dem Kubernetes-Dienstkonto Lese- und Schreibzugriff, um auf den Cloud Storage-Bucket zuzugreifen:

gcloud storage buckets add-iam-policy-binding gs://GSBUCKET \
  --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"

Alternativ können Sie Lese- und Schreibzugriff auf alle Cloud Storage-Buckets im Projekt gewähren:
```
gcloud projects add-iam-policy-binding PROJECT_ID \
--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"
```
GKE erstellt die folgenden Ressourcen für das LLM:
1. Ein Cloud Storage-Bucket zum Speichern des heruntergeladenen Modells und des Kompilierungscaches. Ein CSI-Treiber für Cloud Storage FUSE liest den Inhalt des Buckets.
2. Volumes mit aktiviertem Datei-Caching und die Funktion paralleler Download von Cloud Storage FUSE.
Best Practice:
Verwenden Sie einen Dateicache, der von tmpfs oder Hyperdisk / Persistent Disk unterstützt wird, je nach erwarteter Größe des Modellinhalts, z. B. Gewichtsdateien. In dieser Anleitung verwenden Sie den Cloud Storage FUSE-Dateicache, der vom RAM unterstützt wird.

(Optional) TPU-Image erstellen und bereitstellen

Wenn Sie den Inhalt Ihres Docker-Images genauer steuern möchten, wählen Sie diese Option aus.

Containerisieren Sie Ihren vLLM-Server:

Klonen Sie das vLLM-Repository und erstellen Sie das Image:

git clone https://github.com/vllm-project/vllm && cd vllm && git reset --hard 2e33fe419186c65a18da6668972d61d7bbc31564 && docker build -f Dockerfile.tpu . -t vllm-tpu

Übertragen Sie das Image per Push an Artifact Registry.

gcloud artifacts repositories create vllm-tpu --repository-format=docker --location=REGION_NAME && \
gcloud auth configure-docker REGION_NAME-docker.pkg.dev && \
docker image tag vllm-tpu REGION_NAME-docker.pkg.dev/PROJECT_ID/vllm-tpu/vllm-tpu:latest && \
docker push REGION_NAME-docker.pkg.dev/PROJECT_ID/vllm-tpu/vllm-tpu:latest

vLLM-Modellserver bereitstellen

So stellen Sie den vLLM-Modellserver bereit:

Prüfen Sie das als vllm-llama3-70b.yaml gespeicherte Deployment-Manifest. Ein Deployment ist ein Kubernetes API-Objekt, mit dem Sie mehrere Replikate von Pods ausführen können, die auf die Knoten in einem Cluster verteilt sind:


apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm-tpu
spec:
  replicas: 1
  selector:
    matchLabels:
      app: vllm-tpu
  template:
    metadata:
      labels:
        app: vllm-tpu
      annotations:
        gke-gcsfuse/volumes: "true"
        gke-gcsfuse/cpu-limit: "0"
        gke-gcsfuse/memory-limit: "0"
        gke-gcsfuse/ephemeral-storage-limit: "0"
    spec:
      serviceAccountName: KSA_NAME
      nodeSelector:
        cloud.google.com/gke-tpu-topology: 2x4
        cloud.google.com/gke-tpu-accelerator: tpu-v6e-slice
      containers:
      - name: vllm-tpu
        image: IMAGE_NAME
        command: ["python3", "-m", "vllm.entrypoints.openai.api_server"]
        args:
        - --host=0.0.0.0
        - --port=8000
        - --tensor-parallel-size=8
        - --max-model-len=8192
        - --model=meta-llama/Meta-Llama-3.1-70B
        - --download-dir=/data
        env: 
        - name: HUGGING_FACE_HUB_TOKEN
          valueFrom:
            secretKeyRef:
              name: hf-secret
              key: hf_api_token
        - name: VLLM_XLA_CACHE_PATH
          value: "/data"
        ports:
        - containerPort: 8000
        resources:
          limits:
            google.com/tpu: 8
        readinessProbe:
          tcpSocket:
            port: 8000
          initialDelaySeconds: 15
          periodSeconds: 10
        volumeMounts:
        - name: gcs-fuse-csi-ephemeral
          mountPath: /data
        - name: dshm
          mountPath: /dev/shm
      volumes:
      - name: gke-gcsfuse-cache
        emptyDir:
          medium: Memory
      - name: dshm
        emptyDir:
          medium: Memory
      - name: gcs-fuse-csi-ephemeral
        csi:
          driver: gcsfuse.csi.storage.gke.io
          volumeAttributes:
            bucketName: GSBUCKET
            mountOptions: "implicit-dirs,file-cache:enable-parallel-downloads:true,file-cache:parallel-downloads-per-file:100,file-cache:max-parallel-downloads:-1,file-cache:download-chunk-size-mb:10,file-cache:max-size-mb:-1"
---
apiVersion: v1
kind: Service
metadata:
  name: vllm-service
spec:
  selector:
    app: vllm-tpu
  type: LoadBalancer	
  ports:
    - name: http
      protocol: TCP
      port: 8000  
      targetPort: 8000

Wenden Sie das Manifest mit dem folgenden Befehl an:

kubectl apply -f vllm-llama3-70b.yaml -n NAMESPACE

So rufen Sie die Logs des laufenden Modellservers auf:

kubectl logs -f -l app=vllm-tpu -n NAMESPACE

Die Ausgabe sollte in etwa so aussehen:

INFO:     Started server process [1]
INFO:     Waiting for application startup.
INFO:     Application startup complete.
INFO:     Uvicorn running on http://0.0.0.0:8080 (Press CTRL+C to quit)

Modell bereitstellen

Führen Sie den folgenden Befehl aus, um die externe IP-Adresse des Dienstes abzurufen:

export vllm_service=$(kubectl get service vllm-service -o jsonpath='{.status.loadBalancer.ingress[0].ip}')

Verwenden Sie in einem neuen Terminal curl, um mit dem Modell zu interagieren:

curl http://$vllm_service:8000/v1/completions \
-H "Content-Type: application/json" \
-d '{
    "model": "meta-llama/Meta-Llama-3.1-70B",
    "prompt": "San Francisco is a",
    "max_tokens": 7,
    "temperature": 0
}'

Die Ausgabe sollte in etwa so aussehen:

{"id":"cmpl-6b4bb29482494ab88408d537da1e608f","object":"text_completion","created":1727822657,"model":"meta-llama/Meta-Llama-3-8B","choices":[{"index":0,"text":" top holiday destination featuring scenic beauty and","logprobs":null,"finish_reason":"length","stop_reason":null,"prompt_logprobs":null}],"usage":{"prompt_tokens":5,"total_tokens":12,"completion_tokens":7}}

Benutzerdefiniertes Autoscaling einrichten

In diesem Abschnitt richten Sie das horizontale Pod-Autoscaling mit benutzerdefinierten Prometheus-Messwerten ein. Sie verwenden die Google Cloud Managed Service for Prometheus-Messwerte vom vLLM-Server.

Weitere Informationen finden Sie unter Google Cloud Managed Service for Prometheus. Diese Option sollte standardmäßig auf dem GKE-Cluster aktiviert sein.

Richten Sie den Stackdriver-Adapter für benutzerdefinierte Messwerte in Ihrem Cluster ein:

kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-stackdriver/master/custom-metrics-stackdriver-adapter/deploy/production/adapter_new_resource_model.yaml

Fügen Sie dem Dienstkonto, das vom Stackdriver-Adapter für benutzerdefinierte Messwerte verwendet wird, die Rolle „Monitoring-Betrachter“ hinzu:
```
gcloud projects add-iam-policy-binding projects/PROJECT_ID \
    --role roles/monitoring.viewer \
    --member=principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/custom-metrics/sa/custom-metrics-stackdriver-adapter
```
Hinweis :Das Dienstkonto, das für Ihren GKE-Cluster verwendet wird, muss die Rolle Monitoring-Messwert-Autor haben. In dieser Anleitung wird das standardmäßige Compute Engine-Dienstkonto verwendet.

Speichern Sie das folgende Manifest als vllm_pod_monitor.yaml:


apiVersion: monitoring.googleapis.com/v1
kind: PodMonitoring
metadata:
 name: vllm-pod-monitoring
spec:
 selector:
   matchLabels:
     app: vllm-tpu
 endpoints:
 - path: /metrics
   port: 8000
   interval: 15s

Wenden Sie es auf den Cluster an:
```
kubectl apply -f vllm_pod_monitor.yaml
```

Last auf dem vLLM-Endpunkt erzeugen

Erstellen Sie eine Auslastung auf dem vLLM-Server, um zu testen, wie GKE mit einem benutzerdefinierten vLLM-Messwert automatisch skaliert.

Führen Sie ein Bash-Script (load.sh) aus, um N parallele Anfragen an den vLLM-Endpunkt zu senden:

#!/bin/bash
N=PARALLEL_PROCESSES
export vllm_service=$(kubectl get service vllm-service -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
for i in $(seq 1 $N); do
  while true; do
    curl http://$vllm_service:8000/v1/completions -H "Content-Type: application/json" -d '{"model": "meta-llama/Meta-Llama-3.1-70B", "prompt": "Write a story about san francisco", "max_tokens": 100, "temperature": 0}'
  done &  # Run in the background
done
wait

Ersetzen Sie PARALLEL_PROCESSES durch die Anzahl der parallelen Prozesse, die Sie ausführen möchten.

Führen Sie das Bash-Script aus:
```
nohup ./load.sh &
```

Prüfen, ob die Messwerte in Google Cloud Managed Service for Prometheus aufgenommen werden

Nachdem Google Cloud Managed Service for Prometheus die Messwerte gescrapt hat und Sie dem vLLM-Endpunkt eine Last hinzufügen, können Sie die Messwerte in Cloud Monitoring aufrufen.

Rufen Sie in der Google Cloud -Konsole die Seite Metrics Explorer auf.

Zu Metrics Explorer
Klicken Sie auf < > PromQL.

Geben Sie die folgende Abfrage ein, um Traffic-Messwerte zu beobachten:

vllm:avg_generation_throughput_toks_per_s{cluster='CLUSTER_NAME_HERE'}

Im Liniendiagramm wird der Messwert „vLLM“ von 0 (vor dem Laden) auf einen Wert (nach dem Laden) skaliert. In diesem Diagramm wird bestätigt, dass Ihre vLLM-Messwerte in Google Cloud Managed Service for Prometheus aufgenommen werden.

Das folgende Bild zeigt ein Beispiel für ein Diagramm nach der Ausführung des Ladescripts. In diesem Fall liefert der Modellserver etwa 2.000 Generierungstokens pro Sekunde.

Test

Konfiguration für horizontales Pod-Autoscaling bereitstellen

Für vLLM-TPUs empfehlen wir die folgenden Messwerte für das Autoscaling:

num_requests_waiting: Dieser Messwert bezieht sich auf die Anzahl der Anfragen, die in der Warteschlange des Modellservers warten. Diese Zahl steigt merklich an, wenn der kv-Cache voll ist.
gpu_cache_usage_perc: Dieser Messwert bezieht sich auf die KV-Cache-Auslastung, die direkt mit der Anzahl der Anfragen zusammenhängt, die für einen bestimmten Inferenzzyklus auf dem Modellserver verarbeitet werden. Dieser Messwert funktioniert auf GPUs und TPUs gleich, ist aber an das GPU-Benennungsschema gebunden.

Wir empfehlen num_requests_waiting, wenn Sie den Durchsatz und die Kosten optimieren und Ihre Latenzziele mit dem maximalen Durchsatz Ihres Modellservers erreichbar sind.

Wir empfehlen die Verwendung von gpu_cache_usage_perc, wenn Sie latenzempfindliche Arbeitslasten haben, bei denen die warteschlangenbasierte Skalierung nicht schnell genug ist, um Ihre Anforderungen zu erfüllen.

Weitere Informationen finden Sie unter Best Practices für das Autoscaling von LLM-Inferenzarbeitslasten (Large Language Model) mit TPUs.

Wenn Sie ein averageValue-Ziel für Ihre HPA-Konfiguration auswählen, müssen Sie dies experimentell ermitteln. Weitere Ideen zur Optimierung dieses Teils finden Sie im Blogpost GPUs sparen: Intelligentere automatische Skalierung für Ihre GKE-Inferenzanwendungen. Der in diesem Blogpost verwendete Profilgenerator funktioniert auch für vLLM TPU.

So stellen Sie die Konfiguration des horizontalen Pod-Autoscalings mit num_requests_waiting bereit:

Speichern Sie das folgende Manifest als vllm-hpa.yaml:


apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
 name: vllm-hpa
spec:
 scaleTargetRef:
   apiVersion: apps/v1
   kind: Deployment
   name: vllm-tpu
 minReplicas: 1
 maxReplicas: 2
 metrics:
   - type: Pods
     pods:
       metric:
         name: prometheus.googleapis.com|vllm:num_requests_waiting|gauge
       target:
         type: AverageValue
         averageValue: 10

Die vLLM-Messwerte in Google Cloud Managed Service for Prometheus folgen dem vllm:metric_name-Format.

Best Practice:

Verwenden Sie num_requests_waiting, um den Durchsatz zu skalieren. Verwenden Sie gpu_cache_usage_perc für latenzempfindliche TPU-Anwendungsfälle.

Konfigurieren Sie das horizontale Pod-Autoscaling:
```
kubectl apply -f vllm-hpa.yaml
```
GKE plant die Bereitstellung eines weiteren Pods, wodurch der Knotenpool-Autoscaler einen zweiten Knoten hinzufügt, bevor das zweite vLLM-Replikat bereitgestellt wird.

Beobachten Sie den Fortschritt des Pod-Autoscalings:

kubectl get hpa --watch

Die Ausgabe sieht in etwa so aus:

NAME       REFERENCE             TARGETS       MINPODS   MAXPODS   REPLICAS   AGE
vllm-hpa   Deployment/vllm-tpu   <unknown>/5   1         2         0          6s
vllm-hpa   Deployment/vllm-tpu   34972m/5      1         2         1          16s
vllm-hpa   Deployment/vllm-tpu   25112m/5      1         2         2          31s
vllm-hpa   Deployment/vllm-tpu   35301m/5      1         2         2          46s
vllm-hpa   Deployment/vllm-tpu   25098m/5      1         2         2          62s
vllm-hpa   Deployment/vllm-tpu   35348m/5      1         2         2          77s

Warten Sie 10 Minuten und wiederholen Sie die Schritte im Abschnitt Prüfen, ob Google Cloud Managed Service for Prometheus die Messwerte aufnimmt. Google Cloud Managed Service for Prometheus nimmt die Messwerte von beiden vLLM-Endpunkten auf.

test2

Bereinigen

Damit Ihrem Google Cloud-Konto die in dieser Anleitung verwendeten Ressourcen nicht in Rechnung gestellt werden, löschen Sie entweder das Projekt, das die Ressourcen enthält, oder Sie behalten das Projekt und löschen die einzelnen Ressourcen.

Bereitgestellte Ressourcen löschen

Führen Sie die folgenden Befehle aus, damit Ihrem Google Cloud -Konto die in dieser Anleitung erstellten Ressourcen nicht in Rechnung gestellt werden:

ps -ef | grep load.sh | awk '{print $2}' | xargs -n1 kill -9

gcloud container clusters delete CLUSTER_NAME \
  --location=ZONE

Nächste Schritte

Mehr über TPUs in GKE erfahren
Weitere Informationen zu den verfügbaren Messwerten zum Einrichten des horizontalen Pod-Autoscalings
Sehen Sie sich das GitHub-Repository und die Dokumentation zu vLLM an.

LLM mithilfe von TPU Trillium in GKE mit vLLM bereitstellen

Hintergrund

TPU Trillium

vLLM

Cloud Storage FUSE

Lernziele

Hinweise

Check for the roles

Grant the roles

Umgebung vorbereiten

Zugriff auf das Modell erhalten

Zugriffstoken erstellen

Cloud Shell starten

GKE-Cluster erstellen

Autopilot

Standard

Konfigurieren Sie kubectl für die Kommunikation mit Ihrem Cluster.

Kubernetes-Secret für Hugging Face-Anmeldedaten erstellen

Cloud Storage-Bucket erstellen

Kubernetes-Dienstkonto für den Zugriff auf den Bucket einrichten

(Optional) TPU-Image erstellen und bereitstellen

vLLM-Modellserver bereitstellen

Modell bereitstellen

Benutzerdefiniertes Autoscaling einrichten

Last auf dem vLLM-Endpunkt erzeugen

Prüfen, ob die Messwerte in Google Cloud Managed Service for Prometheus aufgenommen werden

Konfiguration für horizontales Pod-Autoscaling bereitstellen

Bereinigen

Bereitgestellte Ressourcen löschen

Nächste Schritte