Modellinferenzleistung und -kosten mit GKE Inference Quickstart analysieren

Auf dieser Seite wird beschrieben, wie Sie mit dem GKE Inference Quickstart die Bereitstellung von KI-/ML-Inferenzarbeitslasten in Google Kubernetes Engine (GKE) vereinfachen können. Inference Quickstart ist ein Dienstprogramm, mit dem Sie Ihre geschäftlichen Anforderungen für die Inferenz angeben und optimierte Kubernetes-Konfigurationen basierend auf Best Practices und den Benchmarks von Google für Modelle, Modellserver, Beschleuniger (GPUs, TPUs), Skalierung und Speicher erhalten können. So können Sie den zeitaufwendigen Prozess des manuellen Anpassens und Testens von Konfigurationen vermeiden.

Diese Seite richtet sich an Entwickler von maschinellem Lernen (ML), Plattformadministratoren und ‑operatoren sowie an Daten- und KI-Spezialisten, die erfahren möchten, wie sie GKE für KI-/ML-Inferenz effizient verwalten und optimieren können. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir in Trusted Cloud by S3NS Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und ‑Aufgaben.

Weitere Informationen zu Konzepten und Begriffen für die Bereitstellung von Modellen sowie dazu, wie GKE Gen AI-Funktionen die Leistung der Bereitstellung von Modellen verbessern und unterstützen können, finden Sie unter Modellinferenz in GKE.

Machen Sie sich vor dem Lesen dieser Seite mit Kubernetes, GKE und Model Serving vertraut.

Kurzanleitung für die Inferenz verwenden

Mit dem Inference Quickstart können Sie die Leistung und Kosteneffizienz Ihrer Inferenz-Arbeitslasten analysieren und datengestützte Entscheidungen zur Ressourcenzuweisung und zu Strategien für die Modellbereitstellung treffen.

Dies sind die allgemeinen Schritte zur Verwendung von Inference Quickstart:

1. Leistung und Kosten analysieren: Mit dem Befehl gcloud container ai profiles list können Sie verfügbare Konfigurationen aufrufen und nach Ihren Leistungs- und Kostenanforderungen filtern. Verwenden Sie den Befehl gcloud container ai profiles benchmarks list, um sich die vollständigen Benchmarking-Daten für eine bestimmte Konfiguration anzusehen. Mit diesem Befehl können Sie die kostengünstigste Hardware für Ihre spezifischen Leistungsanforderungen ermitteln.

2. Manifeste bereitstellen: Nach der Analyse können Sie ein optimiertes Kubernetes-Manifest generieren und bereitstellen. Optional können Sie Optimierungen für Speicher und Autoscaling aktivieren. Sie können die Bereitstellung über die Trusted Cloud Console oder mit dem kubectl apply-Befehl vornehmen. Vor der Bereitstellung müssen Sie prüfen, ob in Ihrem Trusted Cloud by S3NS -Projekt ein ausreichendes Beschleunigerkontingent für die ausgewählten GPUs oder TPUs vorhanden ist.

3. (Optional) Eigene Benchmarks ausführen: Die bereitgestellten Konfigurationen und Leistungsdaten basieren auf Benchmarks, die das ShareGPT-Dataset verwenden. Die Leistung für Ihre Arbeitslasten kann von dieser Baseline abweichen. Mit dem experimentellen Tool für Inferenz-Benchmarks können Sie die Leistung Ihres Modells unter verschiedenen Bedingungen messen.

Vorteile

Mit der Inference Quickstart können Sie Zeit und Ressourcen sparen, da optimierte Konfigurationen bereitgestellt werden. Diese Optimierungen verbessern die Leistung und senken die Infrastrukturkosten auf folgende Weise:

• Sie erhalten detaillierte, maßgeschneiderte Best Practices für die Konfiguration von Beschleuniger (GPU und TPU), Modellserver und Skalierung. GKE aktualisiert die Kurzanleitung für die Inferenz regelmäßig mit den neuesten Korrekturen, Bildern und Leistungsbenchmarks.
• Sie können die Anforderungen an Latenz und Durchsatz für Ihre Arbeitslast über dieTrusted Cloud -Konsolen-UI oder eine Befehlszeilenschnittstelle angeben und erhalten detaillierte, maßgeschneiderte Best Practices als Kubernetes-Bereitstellungsmanifeste.

Funktionsweise

Die Kurzanleitung für die Inferenz enthält maßgeschneiderte Best Practices, die auf den umfassenden internen Benchmarks von Google zur Leistung einzelner Replikate für Kombinationen aus Modell, Modellserver und Beschleunigertopologie basieren. In diesen Benchmarks wird die Latenz im Vergleich zum Durchsatz dargestellt, einschließlich der Messwerte für die Warteschlangengröße und den KV-Cache, die Leistungskurven für jede Kombination abbilden.

So werden maßgeschneiderte Best Practices generiert

Wir messen die Latenz in normalisierter Zeit pro Ausgabetoken (Normalized Time per Output Token, NTPOT) und Zeit bis zum ersten Token (Time to First Token, TTFT) in Millisekunden und den Durchsatz in Ausgabetokens pro Sekunde, indem wir Beschleuniger sättigen. Weitere Informationen zu diesen Leistungsmesswerten finden Sie unter Modellinferenz in GKE.

Das folgende Beispiel für ein Latenzprofil veranschaulicht den Wendepunkt, an dem der Durchsatz stagniert (grün), den Bereich nach dem Wendepunkt, in dem sich die Latenz verschlechtert (rot), und die ideale Zone (blau) für einen optimalen Durchsatz bei der angestrebten Latenz. Der Inference Quickstart enthält Leistungsdaten und Konfigurationen für diese ideale Zone.

Anhand der Latenzanforderungen einer Inferenzanwendung ermittelt Inference Quickstart geeignete Kombinationen und den optimalen Betriebspunkt auf der Latenz-Durchsatz-Kurve. Dieser Punkt legt den HPA-Schwellenwert (Horizontal Pod Autoscaler) mit einem Puffer fest, um die Latenz beim Hochskalieren zu berücksichtigen. Der Gesamtschwellenwert gibt auch die anfängliche Anzahl der erforderlichen Replikate an. Der HPA passt diese Anzahl jedoch dynamisch an die Arbeitslast an.

Berechnung der Kosten

Zur Berechnung der Kosten verwendet Inference Quickstart ein konfigurierbares Kostenverhältnis zwischen Ausgabe und Eingabe. Wenn dieses Verhältnis beispielsweise auf 4 festgelegt ist, wird davon ausgegangen, dass jedes Ausgabetoken viermal so viel kostet wie ein Eingabetoken. Die folgenden Gleichungen werden verwendet, um die Messwerte für die Kosten pro Token zu berechnen:

\[ \$/\text{output token} = \frac{\text{GPU \$/s}}{(\frac{1}{\text{output-to-input-cost-ratio}} \cdot \text{input tokens/s} + \text{output tokens/s})} \]

Dabei gilt:

\[ \$/\text{input token} = \frac{\text{\$/output token}}{\text{output-to-input-cost-ratio}} \]

Benchmarking

Die bereitgestellten Konfigurationen und Leistungsdaten basieren auf Benchmarks, bei denen mit dem ShareGPT-Dataset Traffic mit der folgenden Ein- und Ausgabeverteilung gesendet wird.

Hinweise

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

• Aktivieren Sie die Google Kubernetes Engine API.
Google Kubernetes Engine API aktivieren
• Wenn Sie die Google Cloud CLI für diesen Task verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit gcloud components update ab.

• Wählen Sie in der Trusted Cloud Console auf der Seite für die Projektauswahl ein Projekt von Trusted Cloud by S3NS aus oder erstellen Sie eines.

• Die Abrechnung für Ihr Trusted Cloud by S3NS Projekt muss aktiviert sein.

• Prüfen Sie, ob Ihr Projekt über genügend Beschleunigerkapazität verfügt:

  • Wenn Sie GPUs verwenden: Prüfen Sie die Seite „Kontingente“.
  • Wenn Sie TPUs verwenden, lesen Sie den Abschnitt Kontingent für TPUs und andere GKE-Ressourcen sicherstellen.

Vorbereitung für die Verwendung der GKE AI/ML-Benutzeroberfläche

Wenn Sie die Trusted Cloud -Konsole verwenden, müssen Sie auch einen Autopilot-Cluster erstellen, falls noch keiner in Ihrem Projekt vorhanden ist. Folgen Sie der Anleitung unter Autopilot-Cluster erstellen.

Vorbereiten der Verwendung der Befehlszeile

Wenn Sie die gcloud CLI zum Ausführen der Kurzanleitung für die Inferenz verwenden, müssen Sie auch die folgenden zusätzlichen Befehle ausführen:

1. Aktivieren Sie die gkerecommender.googleapis.com API:

   gcloud services enable gkerecommender.googleapis.com
   

2. Legen Sie das Abrechnungskontingentprojekt fest, das Sie für API-Aufrufe verwenden:

   gcloud config set billing/quota_project PROJECT_ID
   

3. Prüfen Sie, ob Ihre gcloud CLI-Version mindestens 536.0.1 ist. Falls nicht, führen Sie Folgendes aus:

   gcloud components update
   

Beschränkungen

Beachten Sie die folgenden Einschränkungen, bevor Sie mit der Kurzanleitung für die Inferenz beginnen:

• Bei der Bereitstellung von Modellen über dieTrusted Cloud -Konsole werden nur Autopilot-Cluster unterstützt.
• Die Inference Quickstart-Anleitung enthält keine Profile für alle Modelle, die von einem bestimmten Modellserver unterstützt werden.
• Wenn Sie die Umgebungsvariable HF_HOME nicht festlegen, wenn Sie ein generiertes Manifest für ein großes Modell (90 GiB oder mehr) von Hugging Face verwenden, müssen Sie entweder einen Cluster mit Bootlaufwerken verwenden, die größer als die Standardlaufwerke sind, oder das Manifest ändern, um HF_HOME auf /dev/shm/hf_cache festzulegen. Dadurch wird RAM für den Cache anstelle des Bootlaufwerks des Knotens verwendet. Weitere Informationen finden Sie im Abschnitt Fehlerbehebung.
• Modelle aus Cloud Storage laden wird nur für die Bereitstellung in Clustern mit dem Cloud Storage FUSE CSI-Treiber und aktivierter Workload Identity-Föderation für GKE unterstützt. Beide sind standardmäßig in Autopilot-Clustern aktiviert. Weitere Informationen finden Sie unter CSI-Treiber für Cloud Storage FUSE für GKE einrichten.

Optimierte Konfigurationen für die Modellinferenz analysieren und ansehen

In diesem Abschnitt wird beschrieben, wie Sie Konfigurationsempfehlungen mit der Google Cloud CLI untersuchen und analysieren.

Verwenden Sie den Befehl gcloud container ai profiles, um optimierte Profile (Kombinationen aus Modell, Modellserver, Modellserverversion und Beschleunigern) zu untersuchen und zu analysieren:

  gcloud container ai profiles models list

gcloud container ai profiles list \
    --model=openai/gpt-oss-20b \
    --pricing-model=on-demand \
    --target-ttft-milliseconds=300

  Instance Type Accelerator      Cost/M Input Tokens Cost/M Output Tokens Output Tokens/s NTPOT(ms) TTFT(ms) Model Server Model Server Version Model
  a3-highgpu-1g nvidia-h100-80gb 0.009               0.035                13335           67        297      vllm         gptoss               openai/gpt-oss-20b

gcloud container ai profiles benchmarks list \
    --model=deepseek-ai/DeepSeek-R1-Distill-Qwen-7B \
    --model-server=vllm \
    --pricing-model=on-demand

Nachdem Sie ein Modell, einen Modellserver, eine Modellserverversion und einen Beschleuniger ausgewählt haben, können Sie ein Bereitstellungsmanifest erstellen.

Empfohlene Konfigurationen bereitstellen

In diesem Abschnitt wird beschrieben, wie Sie Konfigurationsempfehlungen mit der Trusted Cloud -Konsole oder der Befehlszeile generieren und bereitstellen.

Bereitstellungsendpunkte testen

Wenn Sie das Manifest bereitgestellt haben, wird der bereitgestellte Dienst über den folgenden Endpunkt verfügbar gemacht:

http://model-model_server-service:8000/

Der Modellserver, z. B. vLLM, überwacht in der Regel Port 8000.

Wenn Sie Ihre Bereitstellung testen möchten, müssen Sie die Portweiterleitung einrichten. Führen Sie den folgenden Befehl in einem separaten Terminal aus:

kubectl port-forward service/model-model_server-service 8000:8000

Beispiele für das Erstellen und Senden einer Anfrage an Ihren Endpunkt finden Sie in der vLLM-Dokumentation.

Manifestversionierung

Die Kurzanleitung für die Inferenz enthält die neuesten Manifeste, die für aktuelle GKE-Clusterversionen validiert wurden. Das für ein Profil zurückgegebene Manifest kann sich im Laufe der Zeit ändern, sodass Sie bei der Bereitstellung eine optimierte Konfiguration erhalten. Wenn Sie ein stabiles Manifest benötigen, speichern Sie es separat.

Das Manifest enthält Kommentare und eine recommender.ai.gke.io/version-Annotation im folgenden Format:

# Generated on DATE using:
# GKE cluster CLUSTER_VERSION
# GPU_DRIVER_VERSION GPU driver for node version NODE_VERSION
# Model server MODEL_SERVER MODEL_SERVER_VERSION

Die vorherige Anmerkung hat die folgenden Werte:

• DATE: Das Datum, an dem das Manifest generiert wurde.
• CLUSTER_VERSION: Die GKE-Clusterversion, die für die Validierung verwendet wird.
• NODE_VERSION: Die für die Validierung verwendete GKE-Knotenversion.
• GPU_DRIVER_VERSION: (nur GPU) Die GPU-Treiberversion, die für die Validierung verwendet wird.
• MODEL_SERVER: Der im Manifest verwendete Modellserver.
• MODEL_SERVER_VERSION: Die im Manifest verwendete Modellserverversion.

Inferenzarbeitslasten überwachen

Wenn Sie Ihre bereitgestellten Inferenzarbeitslasten überwachen möchten, rufen Sie den Metrics Explorer in der Trusted Cloud Console auf.

Automatisches Monitoring aktivieren

GKE bietet eine automatische Monitoring-Funktion, die Teil der umfassenderen Observability-Funktionen ist. Mit dieser Funktion wird der Cluster nach Arbeitslasten durchsucht, die auf unterstützten Modellservern ausgeführt werden, und die PodMonitoring-Ressourcen werden bereitgestellt, damit diese Arbeitslastmesswerte in Cloud Monitoring sichtbar sind. Weitere Informationen zum Aktivieren und Konfigurieren der automatischen Überwachung finden Sie unter Automatische Anwendungsüberwachung für Arbeitslasten konfigurieren.

Nachdem Sie die Funktion aktiviert haben, installiert GKE vorgefertigte Dashboards zum Monitoring von Anwendungen für unterstützte Arbeitslasten.

Wenn Sie die Bereitstellung über die Seite „GKE AI/ML“ in der Trusted Cloud Console vornehmen, werden PodMonitoring- und HPA-Ressourcen automatisch anhand der targetNtpot-Konfiguration für Sie erstellt.

Fehlerbehebung

• Wenn Sie die Latenz zu niedrig festlegen, wird im Inference Quickstart möglicherweise keine Empfehlung generiert. Um dieses Problem zu beheben, wählen Sie ein Latenzziel zwischen der minimalen und der maximalen Latenz aus, die für die ausgewählten Beschleuniger beobachtet wurde.
• Die Kurzanleitung für die Inferenz ist unabhängig von GKE-Komponenten. Ihre Clusterversion ist daher für die Verwendung des Dienstes nicht direkt relevant. Wir empfehlen jedoch, einen neuen oder aktuellen Cluster zu verwenden, um Leistungsabweichungen zu vermeiden.
• Wenn Sie für gkerecommender.googleapis.com-Befehle den Fehler PERMISSION_DENIED erhalten, der besagt, dass ein Kontingentprojekt fehlt, müssen Sie es manuell festlegen. Führen Sie gcloud config set billing/quota_project PROJECT_ID aus, um das Problem zu beheben.

Pod wurde aufgrund von zu wenig flüchtigem Speicher entfernt

Wenn Sie ein großes Modell (90 GiB oder mehr) von Hugging Face bereitstellen, wird Ihr Pod möglicherweise mit einer Fehlermeldung wie dieser entfernt:

Fails because inference server consumes too much ephemeral storage, and gets evicted low resources:  Warning  Evicted              3m24s                   kubelet                                The node was low on resource: ephemeral-storage. Threshold quantity: 10120387530, available: 303108Ki. Container inference-server was using 92343412Ki, request is 0, has larger consumption of ephemeral-storage..,

Dieser Fehler tritt auf, weil das Modell auf dem Bootlaufwerk des Knotens zwischengespeichert wird, einer Form von flüchtigem Speicher. Das Bootlaufwerk wird für sitzungsspezifischen Speicher verwendet, wenn im Bereitstellungsmanifest die Umgebungsvariable HF_HOME nicht auf ein Verzeichnis im RAM des Knotens festgelegt ist.

• Standardmäßig haben GKE-Knoten ein 100 GiB großes Bootlaufwerk.
• GKE reserviert 10% des Bootlaufwerks für den System-Overhead, sodass 90 GiB für Ihre Arbeitslasten verbleiben.
• Wenn die Modellgröße mindestens 90 GiB beträgt und das Modell auf einem Bootlaufwerk mit Standardgröße ausgeführt wird, entfernt kubelet den Pod, um temporären Speicherplatz freizugeben.

Wählen Sie eine der folgenden Optionen, um dieses Problem zu beheben:

• RAM für das Zwischenspeichern von Modellen verwenden: Legen Sie in Ihrem Bereitstellungsmanifest die Umgebungsvariable HF_HOME auf /dev/shm/hf_cache fest. Dabei wird der RAM des Knotens verwendet, um das Modell zu cachen, anstatt das Bootlaufwerk.
• Größe des Bootlaufwerks erhöhen:
  • GKE Standard: Erhöhen Sie die Größe des Bootlaufwerks, wenn Sie einen Cluster erstellen, einen Knotenpool erstellen oder einen Knotenpool aktualisieren.
  • Autopilot: Wenn Sie ein größeres Bootlaufwerk anfordern möchten, erstellen Sie eine benutzerdefinierte Compute-Klasse und legen Sie das Feld bootDiskSize in der Regel machineType fest.

Pod gerät beim Laden von Modellen aus Cloud Storage in eine Absturzschleife

Nachdem Sie ein mit dem Flag --model-bucket-uri generiertes Manifest bereitgestellt haben, kann das Deployment hängen bleiben und der Pod wechselt in den Status CrashLoopBackOff. Wenn Sie die Logs für den Container inference-server prüfen, wird möglicherweise ein irreführender Fehler wie huggingface_hub.errors.HFValidationError angezeigt. Beispiel:

huggingface_hub.errors.HFValidationError: Repo id must use alphanumeric chars or '-', '_', '.', '--' and '..' are forbidden, '-' and '.' cannot start or end the name, max length is 96: '/data'.

Dieser Fehler tritt in der Regel auf, wenn der im --model-bucket-uri-Flag angegebene Cloud Storage-Pfad falsch ist. Der Inferenzserver, z. B. vLLM, kann die erforderlichen Modelldateien (z. B. config.json) nicht am bereitgestellten Pfad finden. Wenn die lokalen Dateien nicht gefunden werden, geht der Server davon aus, dass der Pfad eine Repository-ID für den Hugging Face Hub ist. Da der Pfad keine gültige Repository-ID ist, schlägt der Server mit einem Validierungsfehler fehl und gerät in eine Absturzschleife.

Prüfen Sie zur Behebung dieses Problems, ob der Pfad, den Sie für das Flag --model-bucket-uri angegeben haben, auf das genaue Verzeichnis in Ihrem Cloud Storage-Bucket verweist, das die config.json-Datei des Modells und alle zugehörigen Modellgewichte enthält.

Nächste Schritte

• Im Portal zur KI-/ML-Orchestrierung in GKE finden Sie offizielle Anleitungen, Tutorials und Anwendungsfälle für die Ausführung von KI-/ML-Arbeitslasten in GKE.
• Weitere Informationen zur Optimierung der Bereitstellung von Modellen finden Sie unter Best Practices für die Optimierung der Inferenz großer Sprachmodelle mit GPUs. Darin werden Best Practices für die Bereitstellung von LLMs mit GPUs in GKE behandelt, z. B. Quantisierung, Tensorparallelismus und Arbeitsspeicherverwaltung.
• Weitere Informationen zu Best Practices für das Autoscaling finden Sie in den folgenden Anleitungen:
  • Best Practices für das Autoscaling von Inferenzen für LLM-Arbeitslasten (Large Language Model) mit GPUs
  • Best Practices für das Autoscaling von Inferenzen für LLM-Arbeitslasten (Large Language Model) mit TPUs
• Informationen zu Best Practices für den Speicher finden Sie unter CSI-Treiber für Cloud Storage FUSE für GKE-Leistung optimieren.
• In GKE AI Labs finden Sie experimentelle Beispiele dafür, wie Sie GKE nutzen können, um Ihre KI-/ML-Initiativen zu beschleunigen.