Übersicht über Best Practices für die Inferenz in GKE

Autopilot Standard

Dieses Dokument bietet einen allgemeinen Überblick über Best Practices für die Ausführung von Inferenzarbeitslasten in GKE.

Dieses Dokument richtet sich an Datenadministratoren, Operatoren und Entwickler, die Best Practices für ihre Inferenzarbeitslasten mit Beschleunigern wie GPUs und TPUs mit Kubernetes und GKE anwenden möchten. Weitere Informationen zu gängigen Rollen finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

Inferenzbereitstellung in GKE vorbereiten

In diesem Abschnitt werden grundlegende Best Practices beschrieben, die Sie bei der Vorbereitung der Bereitstellung einer Inferenzarbeitslast beachten sollten. Dazu gehören die Analyse Ihres Anwendungsfalls, die Auswahl von Modellen und die Auswahl von Beschleunigern.

Merkmale Ihres Inferenz-Anwendungsfalls analysieren

Bevor Sie eine Inferenzarbeitslast bereitstellen, sollten Sie ihre spezifischen Anforderungen analysieren. Diese Analyse hilft Ihnen, Architektur-Entscheidungen zu treffen, die Leistung, Kosten und Zuverlässigkeit in Einklang bringen. Wenn Sie Ihren Anwendungsfall kennen, können Sie die geeigneten Modelle, Beschleuniger und Konfigurationen auswählen, um Ihre Service Level Objectives (SLOs) zu erreichen.

Bewerten Sie die folgenden wichtigen Dimensionen Ihrer Arbeitslast, um Ihre Analyse zu unterstützen:

• Leistungs- und Latenzanforderungen definieren: Legen Sie die SLOs Ihrer Anwendung für Latenz und Durchsatz fest. Zu den wichtigsten Messwerten, die definiert werden müssen, gehören Anfragen pro Sekunde (RPS), Antwortlatenz, Länge der Eingabe- und Ausgabetokens sowie die Trefferrate des Präfix-Cache. Weitere Informationen finden Sie unter Messwerte zur Inferenzleistung.
• Modellanforderungen und ‑skalierung bewerten: Die Merkmale des ausgewählten Modells haben direkten Einfluss auf Ihre Infrastrukturanforderungen. Berücksichtigen Sie die maximale Kontextlänge, die das Modell unterstützt, und vergleichen Sie sie mit den Anforderungen Ihrer Arbeitslast. Wenn für Ihren Anwendungsfall nicht der maximale Kontext erforderlich ist, können Sie die maximale Kontextlänge verringern, um Beschleunigerspeicher für einen größeren KV-Cache freizugeben. Dadurch kann der Durchsatz möglicherweise erhöht werden.
• Kosten- und Geschäftsbeschränkungen festlegen: Ihr Budget und Ihre Geschäftsziele sind wichtige Faktoren bei der Entwicklung eines nachhaltigen und kostengünstigen Inferenzdienstes. Definieren Sie den Ziel-CPM (Cost-per-Million) für Ein- und Ausgabe sowie das monatliche Gesamtbudget für diesen Arbeitslast. Legen Sie Ihr Optimierungsziel fest, z. B. Preis-Leistungs-Verhältnis, niedrigste Latenz oder höchster Durchsatz, und ob Ihre App variable Latenz tolerieren kann.

Die richtigen Modelle für Ihre Inferenzanwendungsfälle auswählen

Die Auswahl des richtigen Modells wirkt sich direkt auf die Leistung, die Kosten und die Machbarkeit Ihrer Inferenzanwendung aus. Um das optimale Modell auszuwählen, bewerten Sie die Kandidaten anhand der folgenden Kriterien:

• Aufgaben- und Modalitätsabstimmung: Bewerten Sie Modelle anhand ihrer zugewiesenen Aufgaben und unterstützten Modalitäten. Ein für eine bestimmte Aufgabe optimiertes Modell ist einem Modell für allgemeine Zwecke fast immer überlegen.
• Technische Merkmale: Die Architektur und die Datentypgenauigkeit eines Modells, z. B. FP16, FP8 und FP4, sind wichtige Faktoren für die Bestimmung der Ressourcenanforderungen und der Leistung. Anhand dieser Bewertung können Sie feststellen, ob Sie Quantisierungstechniken anwenden müssen. Prüfen Sie die unterstützte Genauigkeit für Modellgewichte, ob das Framework unterstützt wird und die maximale unterstützte Kontextlänge des Modells.
• Leistung und Kosteneffizienz: Treffen Sie eine datengestützte Entscheidung, indem Sie die in die engere Auswahl gekommenen Modelle anhand öffentlich verfügbarer Benchmarks und Ihrer eigenen internen Tests vergleichen. Verwenden Sie Bestenlisten wie die Chatbot Arena, um Modelle zu vergleichen und die Kosten pro Million Tokens für jedes Modell auf Ihrer Zielhardware zu bewerten.

Quantisierung auf das Modell anwenden

Die Quantisierung ist eine Methode zur Optimierung von Inferenzarbeitslasten, indem der Speicherbedarf des Modells reduziert wird. Dabei werden die Gewichte, Aktivierungen und der Key-Value-Cache (KV-Cache) des Modells von Gleitkommaformaten mit hoher Genauigkeit (z. B. FP16, FP32 und FP64) in Formate mit niedrigerer Genauigkeit (z. B. FP8 und FP4) konvertiert. Diese Reduzierung des Speichers kann zu erheblichen Verbesserungen bei Leistung und Kosteneffizienz führen.

Durch die Quantisierung wird der Speicherbedarf des Modells reduziert, was wiederum den Overhead für die Datenübertragung verringert und Speicherplatz für einen größeren KV-Cache freigibt.

Damit die Quantisierung Ihrer Modelle effektiv angewendet wird, sollten Sie die folgenden Empfehlungen beachten:

• Genauigkeitskompromiss bewerten: Die Quantisierung kann manchmal zu einem Verlust der Modellgenauigkeit führen. Wenn Sie den Kompromiss zwischen Genauigkeit und Quantisierung bewerten, sollten Sie berücksichtigen, dass die 8‑Bit-Quantisierung oft nur zu einem minimalen Genauigkeitsverlust führt. Im Gegensatz dazu kann die 4-Bit-Quantisierung den Arbeitsspeicherbedarf des Beschleunigers um das Vierfache reduzieren, aber auch einen größeren Genauigkeitsverlust im Vergleich zur 8-Bit-Quantisierung verursachen. Bewerten Sie die Leistung des quantisierten Modells für Ihren spezifischen Anwendungsfall, um sicherzustellen, dass die Genauigkeit weiterhin in einem akzeptablen Bereich liegt. Um den Genauigkeitsverlust zu bewerten, können Sie Tools wie OpenCompass und Language Model Evaluation Harness verwenden.
• Unterstützung der Hardwarebeschleunigung bewerten: Um die Quantisierung optimal zu nutzen, sollten Sie Beschleuniger verwenden, die Hardwarebeschleunigung für die Datenformate bieten, die vom quantisierten Modell verwendet werden. Beispiel:
  • NVIDIA H100-GPUs bieten Hardwarebeschleunigung für FP8- und FP16-Vorgänge.
  • NVIDIA B200-GPUs bieten Hardwarebeschleunigung für FP4-, FP8- und FP16-Vorgänge.
  • Cloud TPU v5p bietet Hardwarebeschleunigung für FP8-Vorgänge.
• Nach vorquantisierten Modellen suchen: Bevor Sie ein Modell selbst quantisieren, sollten Sie in öffentlichen Modell-Repositories wie Hugging Face nachsehen. Im Idealfall sollten Sie ein Modell verwenden, das von Anfang an mit geringerer Genauigkeit trainiert wurde, da dies Leistungsvorteile ohne den potenziellen Genauigkeitsverlust durch die Quantisierung nach dem Training bieten kann.
• Quantisierungsbibliothek verwenden: Wenn kein vorab quantisiertes Modell verfügbar ist, verwenden Sie eine Bibliothek, um die Quantisierung selbst durchzuführen. Inferenzserver wie vLLM unterstützen die Ausführung von Modellen, die mit verschiedenen Techniken quantisiert wurden. Mit Tools wie llm-compressor können Sie Quantisierungstechniken auf ein nicht quantisiertes Modell anwenden.
• KV-Cache-Quantisierung in Betracht ziehen: Neben der Quantisierung der Gewichte des Modells können Sie auch den KV-Cache quantisieren. Diese Technik reduziert den für den KV-Cache während der Laufzeit erforderlichen Speicherplatz weiter, was zu einer besseren Leistung führen kann.

Weitere Informationen finden Sie unter LLM-Inferenzarbeitslasten auf GPUs optimieren.

Die richtigen Beschleuniger auswählen

Die Auswahl des richtigen Beschleunigers wirkt sich direkt auf die Leistung, die Kosten und die Nutzerfreundlichkeit Ihres Inferenzdienstes aus. Die optimale Wahl hängt von einer Analyse der Speicheranforderungen Ihres Modells, Ihren Leistungszielen und Ihrem Budget ab.

Tipp :Für eine detaillierte Analyse der Leistung und Kosten der Modellbereitstellung empfehlen wir die Verwendung des GKE Inference Quickstart-Tools. Weitere Informationen finden Sie in der Kurzanleitung für GKE Inference und dem zugehörigen Colab-Notebook.

So wählen Sie den richtigen Beschleuniger für Ihren spezifischen Anwendungsfall aus:

1. Arbeitsspeicheranforderungen berechnen: Berechnen Sie zuerst den minimalen Arbeitsspeicher des Beschleunigers, der zum Laden und Ausführen Ihres Modells erforderlich ist. Der Gesamtspeicher ist die Summe des Speichers, der für die Modellgewichte, den Overhead der Inferenz-Engine, Zwischenaktivierungen und den KV-Cache erforderlich ist.

   Verwenden Sie die folgende Gleichung, um den erforderlichen Arbeitsspeicher zu schätzen:

   \[ \begin{aligned} \text{Required accelerator memory} = {} & (\text{Model weights} + \text{Overhead} + \text{Activations}) \\ & + (\text{KV cache per batch} \times \text{Batch size}) \end{aligned} \]

   Die Begriffe in der Gleichung sind:

   • Modellgewichte: Die Größe der Parameter des Modells.
   • Overhead: Ein Puffer für den Inferenzserver und andere System-Overheads, in der Regel 1–2 GB.
   • Aktivierung: Der Arbeitsspeicher, der für Zwischenaktivierungen während der Ausführung eines Modells erforderlich ist.
   • KV-Cache pro Batch: Der für den KV-Cache für eine einzelne Sequenz erforderliche Arbeitsspeicher, der mit der Kontextlänge und der Modellkonfiguration skaliert wird.
   • Batchgröße: Die Anzahl der Sequenzen (max_num_sequences), die von der Inferenz-Engine gleichzeitig verarbeitet werden.

   Beispiel: Anforderungen an den Accelerator-Speicher für Gemma 3 berechnen

   Um den erforderlichen Beschleunigerspeicher für die Bereitstellung eines Gemma 3-Modells mit 27 Milliarden Parametern mit einer BF16-Präzision für einen Anwendungsfall zur Textgenerierung zu berechnen, können Sie die folgenden Werte verwenden.

   Eine interaktive Anleitung für diese Berechnung finden Sie unter How Much VRAM Does My Model Need? (Wie viel VRAM benötigt mein Modell?). Colab-Notebook

   • Eingaben:
     • Modellgewichte: 54 GB
     • Batchgröße (max_num_sequences): 1
     • Durchschnittliche Eingabelänge: 1.500 Tokens
     • Durchschnittliche Ausgabelänge: 200 Tokens
     • Overhead der Inferenz-Engine: 1 GB (geschätzt)
     • Größe des KV-Cache-Datentyps: 2 (für BF16)
     • KV-Vektoren: 2 (einer für „Key“, einer für „Value“)
   • Modellkonfiguration für ein für die Anleitung abgestimmtes Modell Gemma 3 27B:
     • hidden_size: 5376
     • intermediate_size: 21504
     • num_attention_heads: 32
     • num_hidden_layers: 62
     • num_key_value_heads: 16
   • Arbeitsspeicherberechnung:
     • sequence_length = avg_input_length + avg_output_length = 1.500 + 200 = 1.700 Tokens
     • pytorch_activation_peak_memory = (max_num_sequences * sequence_length * (18 * hidden_size + 4 * intermediate_size)) / (1000^3) = ~0,31 GB (geschätzt).
     • head_dims = hidden_size / num_attention_heads = 5376 / 32 = 168
     • kv_cache_memory_per_batch = (kv_vectors * max_num_sequences * sequence_length * num_key_value_heads * head_dims * num_hidden_layers * kv_data_type_size) / (1000^3) = (2 * 1 * 1700 * 16 * 168 * 62 * 2) / (1000^3) = ~1,13 GB
     • Erforderlicher Beschleunigerspeicher = Model weights + Overhead + Activations + KV cache per batch = 54 + 1 + 0,31 + 1,13 = ~56,44 GB

   Der geschätzte Gesamtspeicher des Beschleunigers, den Sie für die Bereitstellung des Modells benötigen, beträgt etwa 57 GB.

2. Beschleunigeroptionen bewerten: Nachdem Sie Ihren Arbeitsspeicherbedarf geschätzt haben, bewerten Sie die verfügbaren GPU- und TPU-Optionen in GKE.

   Berücksichtigen Sie bei der Bewertung nicht nur die Menge des Beschleunigerspeichers, sondern auch die folgenden Modellanforderungen:

   • Bei Modellen, für die mehr als ein Beschleuniger erforderlich ist, sollten Sie prüfen, ob Hochgeschwindigkeitsverbindungen wie NVLINK und GPUDirect unterstützt werden, um die Kommunikationslatenz zu verringern.
   • Verwenden Sie für quantisierte Modelle Beschleuniger mit nativer Hardwarebeschleunigung für Datentypen mit niedrigerer Präzision wie FP8 und FP4, um die maximale Leistung zu erzielen.

   Bei Ihrer Entscheidung müssen Sie einen Kompromiss zwischen diesen Funktionen, Leistung, Kosten und Verfügbarkeit eingehen.

   Empfohlene Beschleuniger nach Anwendungsfall

   Tipp: Mit dem GKE Inference Quickstart-Tool erhalten Sie die neuesten Empfehlungen für Beschleuniger basierend auf Benchmarks für die Bereitstellungsleistung und Kostenanalysen. Weitere Informationen finden Sie in der GKE Inference-Kurzanleitung.

   Die folgende Tabelle enthält eine Zusammenfassung der am besten geeigneten Optionen für gängige Inferenzanwendungsfälle, um Ihnen die Auswahl der richtigen Beschleuniger für Ihre Arbeitslast zu erleichtern. Diese Anwendungsfälle sind so definiert:

   • Inferenz mit kleinen Modellen: für Modelle mit einigen Milliarden Parametern, bei denen die Rechenlast auf einen einzelnen Host beschränkt ist.
   • Inferenz für große Modelle auf einem einzelnen Host: für Modelle mit zehn bis hunderten Milliarden von Parametern, bei denen die Rechenlast auf mehrere Beschleuniger auf einem einzelnen Hostcomputer verteilt wird.
   • Inferenz für große Modelle mit mehreren Hosts: für Modelle mit Hunderten von Milliarden bis hin zu Billionen von Parametern, bei denen die Rechenlast auf mehrere Beschleuniger auf mehreren Hostcomputern verteilt wird.

   Anwendungsfall	Empfohlene Beschleuniger	Maschinenreihe	Wichtige Merkmale
   Kleine Modellinferenz	NVIDIA L4	G2	Kostengünstige Option für kleine Modelle (24 GB Arbeitsspeicher pro GPU).
   	NVIDIA RTX Pro 6000	G4	Kostengünstig für Modelle mit weniger als 30 Milliarden Parametern und für die Bildgenerierung (96 GB Arbeitsspeicher pro GPU). Unterstützt die direkte Peer-to-Peer-Kommunikation zwischen GPUs und eignet sich daher für die Inferenz mit mehreren GPUs auf einem einzelnen Host.
   	TPU v5e	-	Für Kosteneffizienz optimiert.
   	TPU v6e	-	Bietet den höchsten Wert für Transformer- und Text-zu-Bild-Modelle.
   Inferenz für große Modelle auf einem einzelnen Host	NVIDIA A100	A2	Geeignet für die meisten Modelle, die auf einen einzelnen Knoten passen (bis zu 640 GB Gesamtspeicher).
   	NVIDIA H100	A3	Ideal für Inferenzarbeitslasten, die auf einen einzelnen Knoten passen (bis zu 640 GB Gesamtspeicher).
   	NVIDIA B200	A4	Zukunftssichere Option für anspruchsvolle Modelle,die auf einen einzelnen Knoten passen (bis zu 1.440 GB Gesamtspeicher).
   	TPU v4	-	Bietet ein gutes Verhältnis zwischen Kosten und Leistung.
   	TPU v5p	-	Eine leistungsstarke Option für anspruchsvolle Arbeitslasten.
   Inferenz für große Modelle mit mehreren Hosts	NVIDIA H200	A3 Ultra	Geeignet für große, speicherintensive Modelle (bis zu 1.128 GB Gesamtspeicher).
   	NVIDIA B200 / GB200	A4 / A4X	Für die anspruchsvollsten, rechenintensiven und netzwerkgebundenen Arbeitslasten. A4X-Maschinen verwenden Arm-basierte CPUs, was möglicherweise ein Refactoring der Arbeitslast (Codeänderungen, die über einen einfachen Container-Neubau hinausgehen) erfordert, wenn Ihre Arbeitslast x86-spezifische Funktionen oder Optimierungen verwendet.
   	TPU v5e	-	Optimiert für Kosteneffizienz und Leistung für das Bereitstellen von mittelgroßen bis großen LLMs.
   	TPU v5p	-	Eine leistungsstarke Option für die Inferenz mit mehreren Hosts, die eine groß angelegte Parallelisierung erfordert.
   	TPU v6e	-	Optimiert für die Bereitstellung von Transformer-, Text-zu-Bild- und CNN-Modellen.

   Beispiel: Beschleuniger für ein 260 GB großes Modell auswählen

   Angenommen, Sie müssen ein Modell bereitstellen, das insgesamt 260 GB Beschleunigerspeicher benötigt (200 GB für das Modell, 50 GB für den KV-Cache und 10 GB für den Overhead).

   Allein aufgrund der Arbeitsspeicheranforderungen können Sie NVIDIA L4-GPUs ausschließen, da die größte G2-Maschine maximal 192 GB Beschleunigerarbeitsspeicher bietet. Da L4-GPUs außerdem keine Hochgeschwindigkeitsverbindungen mit geringer Latenz zwischen Beschleunigern unterstützen, ist die Verteilung der Arbeitslast auf mehrere Knoten keine praktikable Option, um die gewünschte Leistung zu erzielen.

   Wenn Sie das Refactoring Ihrer x86-64-Arbeitslasten vermeiden möchten (d. h. Ihren Code nicht ändern müssen, damit er auf einem anderen Prozessortyp ausgeführt werden kann), schließen Sie auch NVIDIA GB200- und GB300-Beschleuniger aus, die Arm-basierte CPUs verwenden.

   Sie haben dann folgende Möglichkeiten:

   • NVIDIA A100
   • NVIDIA RTX Pro 6000
   • NVIDIA H100
   • NVIDIA H200
   • NVIDIA B200

   Alle diese Beschleuniger haben genügend Arbeitsspeicher. Als Nächstes müssen Sie die Verfügbarkeit in Ihren Zielregionen prüfen. Angenommen, Sie stellen fest, dass in einer bestimmten Region nur NVIDIA A100- und NVIDIA H100-GPUs verfügbar sind. Nachdem Sie das Preis-Leistungs-Verhältnis dieser beiden Optionen verglichen haben, entscheiden Sie sich möglicherweise für die NVIDIA H100 für Ihre Arbeitslast.

   GPUs mit mehreren Instanzen

   Um die GPU-Auslastung zu erhöhen und die GPU-Kosten zu optimieren, können Sie GPU-Konfigurationen mit mehreren Instanzen verwenden. Bei dieser Konfiguration partitionieren Sie eine unterstützte GPU, um eine einzelne GPU für mehrere Container in GKE freizugeben. Wenn Sie eine GPU mit mehreren Instanzen bereitstellen, hängen Sie nur ganze GPUs an Ihre GKE-Knoten an und unterliegen der entsprechenden GPU-Preisgestaltung. Wir empfehlen, GPUs mit mehreren Instanzen nur für vertrauenswürdige Arbeitslasten zu verwenden.

   Sie können beispielsweise eine NVIDIA RTX PRO 6000 anhängen und Folgendes tun:

   • Partitionieren Sie sie in vier Instanzen (jede Instanz bietet 24 GB Beschleunigerspeicher) und führen Sie Diffusionsmodelle oder kleine Modellinferenz-Arbeitslasten aus, z. B. Modelle mit etwa 8 Milliarden Parametern, die das FP16-Datenformat für die Präzision von Modellgewichten verwenden. Diese Partition hat möglicherweise ein besseres Preis-Leistungs-Verhältnis als eine NVIDIA L4.
   • Partitionieren Sie sie in zwei Instanzen (jede Instanz bietet 48 GB Beschleunigerspeicher) und führen Sie Inferenzarbeitslasten für kleine Modelle aus, z. B. Modelle mit etwa 15 Milliarden Parametern, für die die Genauigkeit des FP16-Datenformats für Modellgewichte verwendet wird. Diese Partition kann eine Alternative zum Ausführen von Inferenz-Workloads auf einer NVIDIA A100-GPU mit 40 GB sein.

   Weitere Informationen finden Sie unter GPUs mit mehreren Instanzen ausführen.

   Weitere Informationen finden Sie in der Compute Engine-Dokumentation unter GPU-Maschinentypen und Beschleunigeroptimierte Maschinenfamilie.

3. Strategie für die Inferenzverteilung auswählen: Wenn Ihr Modell zu groß für einen einzelnen Beschleuniger ist, wählen Sie eine Verteilungsstrategie basierend auf den Anforderungen Ihrer Arbeitslast aus.

   Wählen Sie zuerst eine Verteilungsstrategie basierend auf der Topologie Ihrer Hardware aus:

   • Einzelner Beschleuniger: Wenn Ihr Modell auf einen einzelnen Beschleuniger passt, ist dies der einfachste und empfohlene Ansatz.
   • Einzelner Knoten, mehrere Beschleuniger: Wenn Ihr Modell auf einen einzelnen Knoten mit mehreren Beschleunigern passt, können Sie Tensor-Parallelität verwenden, um das Modell auf die Beschleuniger auf diesem Knoten zu verteilen.
   • Mehrere Knoten, mehrere Beschleuniger: Wenn Ihr Modell zu groß für einen einzelnen Knoten ist, können Sie es mithilfe einer Kombination aus Tensor- und Pipeline-Parallelität auf mehrere Knoten verteilen.

   Zur Umsetzung dieser Strategien können Sie die folgenden Parallelisierungstechniken verwenden:

   • Tensor-Parallelität: Bei dieser Technik werden die Ebenen eines Modells auf mehrere Beschleuniger verteilt. Sie ist innerhalb eines einzelnen Knotens mit Hochgeschwindigkeitsverbindungen wie NVLINK oder direktem Peer-to-Peer-PCIe sehr effektiv, erfordert jedoch eine erhebliche Kommunikation zwischen Beschleunigern.

     Beispiel: Tensor-Parallelität

     Angenommen, Sie müssen ein Modell mit 109 Milliarden Parametern bereitstellen. Bei der standardmäßigen BF16-Präzision (16 Bit) erfordert das Laden der Gewichte des Modells in den Beschleunigerspeicher etwa 113 GB. Eine einzelne NVIDIA H100-GPU bietet 80 GB Arbeitsspeicher. Selbst wenn Sie andere Arbeitsspeicheranforderungen wie den KV-Cache nicht berücksichtigen, benötigen Sie daher mindestens zwei NVIDIA H100-GPUs, um das Modell mit einer Tensorparallelismusgröße von zwei zu laden.

   • Pipeline-Parallelität: Bei dieser Technik werden die Ebenen eines Modells sequenziell auf mehrere Knoten aufgeteilt. Sie eignet sich gut, um ein Modell auf mehrere Knoten in einer Bereitstellung mit mehreren Hosts zu verteilen, und erfordert weniger Kommunikation zwischen den Modellrängen als Tensorparallelismus.

     Beispiel: Hybride Parallelität (Tensor und Pipeline)

     Bei einem sehr großen Modell mit über 600 Milliarden Parametern kann der Speicherbedarf 1, 1 TB überschreiten. In einem Szenario mit zwei a3-megagpu-8g-Knoten (jeweils mit acht NVIDIA H100-GPUs) hat der gesamte Cluster 1,28 TB Beschleunigerspeicher. Um das Modell auszuführen, würden Sie eine Hybridstrategie implementieren: 8-facher Tensorparallelismus innerhalb jedes Knotens und 2-facher Pipelineparallelismus über die beiden Knoten hinweg. Das Modell würde in zwei Phasen aufgeteilt, wobei die erste Hälfte der Ebenen auf dem ersten Knoten und die zweite Hälfte auf dem zweiten Knoten ausgeführt würde. Wenn eine Anfrage eingeht, wird sie vom ersten Knoten verarbeitet. Die Zwischenergebnisse werden dann über das Netzwerk an den zweiten Knoten gesendet, der die Berechnung abschließt.

   Weitere Richtlinien zur Auswahl einer Strategie für die verteilte Inferenz für ein einzelnes Modellreplikat finden Sie in der vLLM-Dokumentation unter Parallelism and Scaling (Parallelität und Skalierung).

4. Beschleunigungsoptimierten Maschinentyp auswählen: Wählen Sie basierend auf der Auswahl des Beschleunigers und der benötigten Anzahl einen Maschinentyp aus, der diese Ressourcen bereitstellt. Jeder Maschinentyp bietet eine bestimmte Kombination aus vCPUs, Arbeitsspeicher und Netzwerkbandbreite, die sich auch auf die Leistung Ihrer Arbeitslast auswirken kann. Wenn Sie beispielsweise 16 NVIDIA H100-GPUs benötigen, wählen Sie den Maschinentyp a3-megagpu-16g aus.

5. Eigene Benchmarks ausführen: Die Leistung Ihrer Inferenzarbeitslast hängt stark von Ihrem spezifischen Anwendungsfall ab. Führen Sie eigene Benchmarks aus, um Ihre Auswahl zu validieren und die Konfiguration zu optimieren.

Konfiguration des Inferenzservers optimieren

Um eine optimale Leistung beim Bereitstellen Ihrer Inferenz-Arbeitslast zu erzielen, empfehlen wir einen Zyklus aus Benchmarking und Optimierung:

1. Beginnen Sie mit der GKE Inference-Kurzanleitung, um eine optimierte Kubernetes-Basiskonfiguration für Ihren Anwendungsfall zu erhalten.
2. Führen Sie Benchmarks aus, um Messwerte für den Baseline-Durchsatz und die Baseline-Latenz zu erfassen.
3. Konfiguration des Inferenzservers optimieren
4. Führen Sie die Benchmarks noch einmal aus und vergleichen Sie die Ergebnisse, um Ihre Änderungen zu validieren.

Die folgenden Empfehlungen basieren auf dem vLLM-Inferenzserver, die Prinzipien gelten jedoch auch für andere Server. Eine detaillierte Anleitung zu allen verfügbaren Einstellungen finden Sie in der Dokumentation vLLM Optimization and Tuning:

• Parallelität konfigurieren:
  • Tensor-Parallelität (tensor_parallel_size): Legen Sie diesen Wert auf die Anzahl der Beschleuniger auf einem einzelnen Knoten fest, um die Arbeitslast aufzuteilen. Wenn Sie beispielsweise tensor_parallel_size=4 festlegen, wird die Arbeitslast auf vier Beschleuniger verteilt. Beachten Sie, dass eine Erhöhung dieses Werts zu einem übermäßigen Synchronisierungsaufwand führen kann.
  • Pipeline-Parallelität (pipeline_parallel_size): Legen Sie diesen Wert auf die Anzahl der Knoten fest, auf die Sie Ihr Modell verteilen. Wenn Sie beispielsweise die Bereitstellung auf zwei Knoten mit jeweils acht Beschleunigern vornehmen, legen Sie tensor_parallel_size=8 und pipeline_parallel_size=2 fest. Wenn Sie diesen Wert erhöhen, kann das zu Latenzproblemen führen.
• KV-Cache optimieren (gpu_memory_utilization): Mit diesem Parameter wird der Prozentsatz des GPU-Speichers gesteuert, der für die Modellgewichte, Aktivierungen und den KV-Cache reserviert ist. Ein höherer Wert erhöht die Größe des KV-Cache und kann den Durchsatz verbessern. Wir empfehlen, diesen Wert auf einen Wert zwischen 0.9 und 0.95 zu setzen. Wenn OOM-Fehler (Out-of-Memory) auftreten, verringern Sie diesen Wert.
• Maximale Kontextlänge konfigurieren (max_model_len): Um die Größe des KV-Cache und den Speicherbedarf zu verringern, können Sie eine niedrigere maximale Kontextlänge als die Standardeinstellung des Modells festlegen. So können Sie kleinere, kostengünstigere GPUs verwenden. Wenn für Ihren Anwendungsfall beispielsweise nur ein Kontext von 40.000 Tokens erforderlich ist, der Standardwert Ihres Modells jedoch 256.000 beträgt, wird durch Festlegen von max_model_len auf 40.000 Speicherplatz für einen größeren KV-Cache freigegeben, was möglicherweise zu einem höheren Durchsatz führt.
• Anzahl der gleichzeitigen Anfragen konfigurieren (max_num_batched_tokens, max_num_seqs): Passen Sie die maximale Anzahl der Anfragen an, die vLLM gleichzeitig verarbeitet, um eine Unterbrechung zu vermeiden, wenn der KV-Cache wenig Speicherplatz hat. Niedrigere Werte für max_num_batched_tokens und max_num_seqs reduzieren den Arbeitsspeicherbedarf, während höhere Werte den Durchsatz verbessern können, allerdings mit dem Risiko von OOM-Fehlern. Um die optimalen Werte zu ermitteln, empfehlen wir, Leistungstests auszuführen und die Anzahl der Anfragen für das Unterbrechen von Aufgaben in den Prometheus-Messwerten zu beobachten, die von vLLM exportiert werden.

Weitere Informationen finden Sie in den folgenden Ressourcen:

• Eine ausführliche Anleitung zum Optimieren dieser Parameter finden Sie unter vLLM Performance Tuning: The Ultimate Guide to xPU Inference Configuration.
• Weitere Informationen zur Optimierung des Modellspeichers finden Sie unter Best Practices für die Optimierung von Inferenzen für LLMs mit GPUs in GKE.
• Ein vollständiges, bereitstellbares Beispiel finden Sie in der Referenzimplementierung für GKE Inference.

Für Latenz und Verfügbarkeit optimieren

Damit Ihr Inferenzdienst sowohl reaktionsschnell als auch zuverlässig ist, müssen Sie ihn für eine niedrige Startlatenz und eine hohe Ressourcenverfügbarkeit optimieren.

Kaltstartlatenz von Inferenzarbeitslasten optimieren

Die Zeit, die zum Starten Ihrer Inferenzarbeitslasten benötigt wird, muss sowohl aus Kostengründen als auch im Hinblick auf die Nutzerfreundlichkeit minimiert werden. Eine niedrige Kaltstartlatenz ermöglicht es Ihrem Cluster, schnell hochzuskalieren, um die Nachfrage zu decken. So wird ein reaktionsschneller Dienst gewährleistet und gleichzeitig die Notwendigkeit einer kostspieligen Überbereitstellung minimiert.

Pod-Startzeit optimieren

Die Zeit, die ein Pod benötigt, um bereit zu sein, hängt hauptsächlich davon ab, wie lange es dauert, das Container-Image abzurufen und die Modellgewichte herunterzuladen. Berücksichtigen Sie die folgenden Strategien, um beides zu optimieren:

• Modellladen mit einem optimierten Datenloader beschleunigen: Die Methode, mit der Sie Ihre Modellgewichte speichern und laden, hat einen erheblichen Einfluss auf die Startzeit. Für vLLM-Versionen 0.10.2 und höher wird empfohlen, Run:ai Model Streamer zu verwenden, um Modelle zu laden, indem Sie sie direkt aus einem Cloud Storage-Bucket streamen.

  Wenn der Streamer für Ihren Anwendungsfall nicht verfügbar ist, können Sie einen Cloud Storage-Bucket mit Cloud Storage FUSE bereitstellen und seine Leistung optimieren, indem Sie hierarchische Namespaces aktivieren und Techniken wie parallele Downloads und Prefetching verwenden. Weitere Informationen zu diesen Techniken finden Sie unter CSI-Treiber für Cloud Storage FUSE für GKE-Leistung optimieren. In beiden Fällen empfehlen wir, Anywhere Cache zu verwenden, um leistungsstarke zonale Lesecaches für Ihre Buckets zu erstellen, und einheitlichen Zugriff auf Bucket-Ebene zu aktivieren, um den Zugriff auf Ihre Buckets einheitlich zu steuern.

  Wenn Sie Managed Lustre bereits für Hochleistungs-Dateispeicher für Ihre Trainingsarbeitslasten verwenden, können Sie es auch zum Laden von Modellgewichten für die Inferenz verwenden. Dieser Ansatz bietet Zugriff mit niedriger Latenz, wenn Datenlokalität und POSIX-Kompatibilität entscheidend sind.

• Image-Streaming aktivieren: Um die Zeit zu verkürzen, die zum Abrufen Ihrer Container-Images benötigt wird, aktivieren Sie Image-Streaming in Ihrem GKE-Cluster. Mit Image-Streaming können Ihre Container gestartet werden, bevor das gesamte Image heruntergeladen wurde. Dadurch kann die Startzeit von Pods erheblich verkürzt werden.

Schnell startende Knoten aktivieren

Für Arbeitslasten, die eine schnelle Skalierung erfordern, können Sie Knoten mit schnellem Start in GKE nutzen. Knoten mit Schnellstart sind vorinitialisierte Hardwareressourcen, die eine deutlich kürzere Startzeit als Standardknoten haben. Wenn Ihr Cluster die Anforderungen erfüllt, aktiviert GKE automatisch schnell startende Knoten.

Kapazität planen und Beschleunigerverfügbarkeit maximieren

Stark nachgefragte Beschleuniger wie GPUs und TPUs sind möglicherweise nur begrenzt verfügbar. Daher ist eine proaktive Kapazitätsplanung unerlässlich.

Kapazität planen und reservieren

Beschleuniger mit hoher Nachfrage sind möglicherweise nur begrenzt verfügbar. Daher ist eine proaktive Strategie zur Kapazitätsplanung unerlässlich. Damit Sie Zugriff auf die benötigten Ressourcen haben, sollten Sie die folgenden Empfehlungen beachten:

• Kapazitätsreferenz und Spitzenlastbewältigung festlegen: Planen Sie die Referenzkapazität für Beschleuniger, die Sie reservieren müssen. Die Höhe der Reservierung hängt von Ihrem Anwendungsfall ab. Sie können beispielsweise 100% der erforderlichen Kapazität für kritische Arbeitslasten ohne Toleranz für Verzögerungen reservieren oder ein bestimmtes Perzentil (z. B. das 90. oder 95.) reservieren und den Rest bei Bedarf abrufen, um Spitzen zu bewältigen.

• Referenzkapazität reservieren: Wenn Sie Ressourcen mit einem hohen Maß an Sicherheit erhalten möchten, erstellen Sie Reservierungen. Sie können je nach Bedarf einen Reservierungstyp auswählen. Wenn Sie beispielsweise Ressourcen mit hoher Nachfrage wie Beschleuniger für einen bestimmten zukünftigen Zeitraum reservieren möchten, können Sie vorausschauende Reservierungen im Kalendermodus erstellen.

• Kapazität für Spitzen orchestrieren: Für die Nachfrage, die Ihre Basisreservierungen übersteigt, können Sie eine Fallback-Strategie mit anderen Kapazitätstypen wie On-Demand-VMs, Spot-VMs oder dem Dynamic Workload Scheduler (DWS) implementieren. Sie können diese Fallback-Strategie automatisieren, indem Sie benutzerdefinierte Compute-Klassen verwenden, um eine Prioritätsreihenfolge für die Bereitstellung verschiedener Kapazitätstypen zu definieren.

• Zugriff auf ermäßigte Preise: Kaufen Sie für Ihre Basiskapazität Rabatte für zugesicherte Nutzung (Committed Use Discounts, CUDs), um im Gegenzug für eine ein- oder dreijährige Zusicherung stark ermäßigte Preise zu erhalten.

Dynamic Workload Scheduler mit dem Bereitstellungsmodus „Flex-Start“ verwenden, wenn Ihre Arbeitslasten Verzögerungen beim Erwerb von Kapazität tolerieren

Für Arbeitslasten, bei denen eine gewisse Verzögerung beim Erwerb von Kapazität toleriert werden kann, ist der Dynamic Workload Scheduler (DWS) mit dem Bereitstellungsmodus „Flex-Start“ eine Option, um Beschleuniger zu einem reduzierten Preis zu erhalten. Mit DWS können Sie Anfragen für Kapazität für bis zu sieben Tage in die Warteschlange stellen.

Wenn Sie DWS mit dem Bereitstellungsmodus „Flex-Start“ verwenden, empfehlen wir Folgendes:

• In eine benutzerdefinierte Compute-Klasse einbinden: Verwenden Sie eine benutzerdefinierte Compute-Klasse, um DWS als Teil einer priorisierten Fallback-Strategie für die Kapazitätsbeschaffung zu definieren.
• Maximale Laufzeit festlegen: Mit dem Parameter maxRunDurationSeconds wird die maximale Laufzeit für Knoten festgelegt, die über DWS angefordert werden. Wenn Sie diesen Wert auf einen Wert unter dem Standardwert von sieben Tagen festlegen, erhöhen Sie die Wahrscheinlichkeit, dass Sie die angeforderten Knoten erhalten.
• Knoten-Recycling aktivieren: Um Ausfallzeiten für Ihre Arbeitslasten zu vermeiden, aktivieren Sie das Knoten-Recycling. Mit dieser Funktion wird ein neuer Knoten bereitgestellt, bevor der alte abläuft, um einen reibungsloseren Übergang zu ermöglichen.
• Unterbrechungen minimieren: Um Unterbrechungen durch das Entfernen von Knoten und Upgrades zu minimieren, konfigurieren Sie Wartungsfenster und ‑ausschlüsse, deaktivieren Sie die automatische Knotenreparatur und nutzen Sie die Strategie für kurzlebige Upgrades.

Benutzerdefinierte Compute-Klassen verwenden

Benutzerdefinierte Compute-Klassen (Custom Compute Classes, CCCs) sind eine GKE-Funktion, mit der Sie eine priorisierte Liste von Infrastrukturkonfigurationen für Ihre Arbeitslasten definieren können. CCCs bieten wichtige Funktionen, die die Verfügbarkeit von Beschleunigern verbessern sollen:

• Fallback-Computing-Prioritäten: Sie können eine priorisierte Liste von Konfigurationen definieren. Wenn Ihre bevorzugte Option während eines Scale-up-Ereignisses nicht verfügbar ist, greift der Autoscaler automatisch auf die nächste Option in der Liste zurück. Dadurch wird die Wahrscheinlichkeit, dass Sie Kapazität erhalten, erheblich erhöht.
• Aktive Migration zu Knoten mit höherer Priorität: Wenn Sie diese Funktion konfigurieren, ersetzt GKE automatisch Knoten, die auf Konfigurationen mit niedrigerer Priorität ausgeführt werden, durch Knoten aus Konfigurationen mit höherer Priorität, sobald diese verfügbar sind. So werden Ihre Pods schließlich auf den von Ihnen bevorzugten (und oft kostengünstigsten) Knoten ausgeführt.

Mit benutzerdefinierten Compute-Klassen (Custom Compute Classes, CCCs) können Sie eine Fallback-Strategie für den Abruf von Knoten erstellen. Bei dieser Strategie wird eine priorisierte Liste verschiedener Kapazitätstypen verwendet, z. B. On-Demand-VMs, Spot-VMs oder Reservierungen. Jeder dieser Kapazitätstypen hat eine andere Verfügbarkeit:

• Reservierungen: bieten das höchste Maß an Sicherheit für das Anfordern von Kapazität. Beachten Sie die Einschränkungen, wenn Sie Reservierungen mit CCCs nutzen. Bei einigen Reservierungstypen ist beispielsweise die Anzahl der reservierbaren Maschinentypen oder die maximale Anzahl der anforderbaren Maschinen begrenzt.
• On-Demand: Das Standardbereitstellungsmodell, das Flexibilität bietet, aber bei Ressourcen mit hoher Nachfrage regionalen Kapazitätsbeschränkungen unterliegen kann.
• Spot-VMs: Sie können ungenutzte Kapazität zu einem niedrigeren Preis nutzen, aber die VMs können vorzeitig beendet werden. Wenn ein Ereignis zum vorzeitigen Beenden eintritt, gewährt GKE betroffenen Pods auf Best-Effort-Basis einen Zeitraum von bis zu 30 Sekunden für die ordnungsgemäße Beendigung. Damit Sie davon profitieren können, müssen Ihre Arbeitslasten tolerant gegenüber Preemption-Ereignissen sein. Implementieren Sie dazu Prüfpunkte und Wiederholungsmechanismen.
• Dynamic Workload Scheduler (DWS): Mit dieser Option können Sie Anfragen für knappe Ressourcen zu ermäßigten Preisen in die Warteschlange stellen. Diese Funktion ist ideal für Arbeitslasten, bei denen Verzögerungen beim Erwerb von Kapazität toleriert werden können.

Die Reihenfolge Ihrer Prioritätenliste sollte sich je nachdem ändern, ob Ihr primäres Ziel die Minimierung der Latenz oder die Kostenoptimierung ist. Sie können beispielsweise die folgenden Prioritätslisten für unterschiedliche Arbeitslastanforderungen konfigurieren:

Priorität	Arbeitslasten mit niedriger Latenz	Kostenoptimierte (latenztolerante) Arbeitslasten
1	Reservierungen (bestimmte, dann beliebige)	Reservierungen (bestimmte, dann beliebige)
2	On demand	Spot-VMs
3	Spot-VMs	Dynamic Workload Scheduler
4	Dynamic Workload Scheduler	On demand

Bei Anwendungsfällen mit geringer Latenz wird On-Demand-Kapazität nach Reservierungen priorisiert, da Kapazitätsengpässe schnell gemeldet werden. So kann der CCC schnell auf die nächste Option zurückgreifen.

Bei kostenoptimierten Anwendungsfällen werden Spot-VMs und DWS mit Flex-Start nach Reservierungen priorisiert, um von niedrigeren Kosten zu profitieren. On-Demand-Kapazität wird als letzter Fallback verwendet.

Standortrichtlinie Ihrer GKE-Cluster und ‑Knotenpools konfigurieren

Die Standortrichtlinie von Cluster Autoscaler steuert, wie GKE Knoten während eines Hochskalierungsereignisses auf Zonen verteilt. Diese Einstellung ist besonders wichtig, wenn Sie benutzerdefinierte Compute-Klassen verwenden, da sie bestimmt, welche Zonen der Cluster Autoscaler berücksichtigt, bevor er die Prioritätsliste der benutzerdefinierten Compute-Klasse anwendet.

Um die Wahrscheinlichkeit zu erhöhen, dass Sie Beschleuniger erhalten, konfigurieren Sie die Standortrichtlinie entsprechend den Anforderungen Ihrer Arbeitslast:

• location-policy=ANY: Priorisiert die Beschaffung von Kapazität gegenüber der gleichmäßigen Verteilung von Knoten auf Zonen. Diese Einstellung ist besonders relevant, wenn Ihr CCC Spot-VMs oder Maschinentypen mit variabler Verfügbarkeit enthält, da ANY es dem Cluster Autoscaler ermöglicht, die Zone mit der größten Wahrscheinlichkeit für die Erfüllung der priorisierten Knotentypen des CCC auszuwählen. Verwenden Sie diese Einstellung auch, um die Nutzung nicht verwendeter Reservierungen zu priorisieren. Wenn Sie diese Richtlinie verwenden, empfehlen wir, mit num-nodes=0 zu beginnen, damit der Cluster-Autoscaler maximale Flexibilität bei der Suche nach Kapazität hat.

• location-policy=BALANCED: Versucht, Knoten gleichmäßig auf alle verfügbaren Zonen zu verteilen. Verwenden Sie diese Richtlinie, wenn für Ihre Arbeitslasten leicht verfügbare Ressourcen verwendet werden und Sie die zonale Redundanz für eine hohe Verfügbarkeit beibehalten möchten.

Sie können diese Einstellung konfigurieren, wenn Sie einen Knotenpool erstellen oder aktualisieren.

Effizienz und Kosten optimieren

Durch die sorgfältige Überwachung Ihrer Beschleuniger und die intelligente Skalierung Ihrer Arbeitslasten können Sie Verschwendung erheblich reduzieren und Ihre Betriebskosten senken.

Beschleuniger und Inferenzserver beobachten

Eine umfassende Observability-Strategie ist unerlässlich, um die Leistung und Auslastung Ihrer Inferenz-Arbeitslasten zu verstehen. GKE bietet eine Reihe von Tools, mit denen Sie Ihre Beschleuniger und Inferenzserver überwachen können:

• DCGM-Messwerte für NVIDIA-GPUs überwachen: Wenn Sie den Zustand und die Leistung Ihrer NVIDIA-GPUs überwachen möchten, konfigurieren Sie GKE so, dass NVIDIA Data Center GPU Manager (DCGM)-Messwerte an Cloud Monitoring gesendet werden.
• Automatisches Anwendungsmonitoring aktivieren: Um das Monitoring Ihrer Inferenzserver zu vereinfachen, aktivieren Sie das automatische Anwendungsmonitoring in GKE.
• Arbeitslasten mit OpenTelemetry instrumentieren: Verwenden Sie für Arbeitslasten, die nicht von der automatischen Anwendungsüberwachung unterstützt werden, OpenTelemetry, um benutzerdefinierte Messwerte und Traces zu erfassen.

Pods automatisch skalieren

Damit sich Ihre Inferenzarbeitslasten dynamisch an Änderungen der Nachfrage anpassen können, verwenden Sie ein horizontales Pod-Autoscaling (HPA), um die Anzahl der Pods automatisch zu skalieren. Bei Inferenzarbeitslasten ist es wichtig, Ihre Skalierungsentscheidungen auf Messwerte zu stützen, die die Last auf dem Inferenzserver direkt widerspiegeln, und nicht auf Standardmesswerte für CPU oder Arbeitsspeicher.

Wir empfehlen, Autoscaling für Ihre Inferenzarbeitslasten so zu konfigurieren:

• HPA basierend auf inferenzbezogenen Messwerten konfigurieren: Für eine optimale Leistung konfigurieren Sie die HPA so, dass sie basierend auf Messwerten von Ihrem Inferenzserver skaliert wird. Die beste Messgröße hängt davon ab, ob Sie die Latenz oder den Durchsatz optimieren möchten.

  • Für latenzempfindliche Arbeitslasten haben Sie zwei Hauptoptionen:

    • KV-Cache-Auslastung (z. B. vllm:gpu_cache_usage_perc): Dieser Messwert ist oft der beste Indikator für bevorstehende Latenzspitzen. Eine hohe Auslastung des KV-Cache deutet darauf hin, dass die Inferenz-Engine sich der Kapazitätsgrenze nähert. Der HPA kann dieses Signal verwenden, um präventiv Replikate hinzuzufügen und eine stabile Nutzererfahrung aufrechtzuerhalten.
    • Anzahl der laufenden Anfragen (Batchgröße) (z. B.vllm:num_requests_running): Dieser Messwert hängt direkt mit der Latenz zusammen, da kleinere Batchgrößen in der Regel zu einer geringeren Latenz führen. Die Verwendung für das Autoscaling kann jedoch schwierig sein, da die Maximierung des Durchsatzes von der Größe der eingehenden Anfragen abhängt. Möglicherweise müssen Sie einen Wert auswählen, der niedriger als die maximal mögliche Batchgröße ist, damit die HPA richtig skaliert wird.

  • Bei durchsatzsensiblen Arbeitslasten sollten Sie die Skalierung anhand der Warteschlangengröße (z. B. vllm:num_requests_waiting) vornehmen. Dieser Messwert misst direkt den Arbeitsrückstand und ist eine einfache Möglichkeit, die Verarbeitungskapazität an die eingehende Nachfrage anzupassen. Da bei diesem Messwert nur Anfragen berücksichtigt werden, die warten, und nicht die, die gerade verarbeitet werden, wird im Vergleich zur Skalierung nach Batchgröße möglicherweise nicht die niedrigstmögliche Latenz erreicht.

• Mindestanzahl von Replikaten festlegen: Um eine konsistente Verfügbarkeit und eine grundlegende Nutzererfahrung zu gewährleisten, sollten Sie immer eine Mindestanzahl von Replikaten für Ihr Inferenz-Deployment festlegen.

• HPA-Leistungsprofil aktivieren: In GKE-Versionen 1.33 oder höher ist das HPA-Leistungsprofil standardmäßig in entsprechenden Clustern aktiviert, um die Reaktionszeit des HPA zu verbessern.

Weitere Informationen finden Sie unter HPA für LLM-Arbeitslasten auf GPUs konfigurieren und LLM-Inferenzarbeitslasten auf TPUs automatisch skalieren.

Daten näher an Ihre Arbeitslasten heranbringen

Die Zeit, die Ihre Arbeitslasten zum Laden von Daten wie Modellgewichten benötigen, kann eine erhebliche Quelle für Latenz sein. Wenn Sie Ihre Daten näher an Ihre Rechenressourcen verlagern, können Sie die Datenübertragungszeiten verkürzen und die Gesamtleistung verbessern.

• Zonale Lese-Caches mit Anywhere Cache erstellen: Wenn Sie Cloud Storage zum Speichern von Daten für Ihre KI-/ML-Arbeitslasten verwenden, aktivieren Sie Anywhere Cache. Mit Anywhere Cache werden leistungsstarke zonale Lesecaches für Ihre Cloud Storage-Buckets erstellt.
• Häufig aufgerufene Daten auf lokalen SSDs zwischenspeichern: Verwenden Sie für Arbeitslasten, die einen Zugriff mit extrem niedriger Latenz auf temporäre Daten erfordern, lokale SSDs als Hochleistungscache. Wenn Sie lokale SSDs als temporären Speicher mit niedriger Latenz für häufig verwendete Daten verwenden, können Sie die Leerlaufzeit teurer Ressourcen wie Beschleuniger reduzieren, da die Zeit, die Beschleuniger auf den Abschluss von E/A-Vorgängen warten, drastisch verkürzt wird. Beachten Sie, dass nicht alle Maschinenserien lokale SSDs unterstützen. Dies kann sich auf die Auswahl von Accelerators auswirken.
• Caches mit GKE Data Cache verwalten: Aktivieren Sie GKE Data Cache für Arbeitslasten, die häufig Daten von nichtflüchtigen Speichern lesen. GKE Data Cache verwendet lokale SSDs, um einen verwalteten Hochleistungscache für Ihre Persistent Disks zu erstellen. Für die meisten Produktionsarbeitslasten empfehlen wir den Modus Writethrough, um Datenverlust zu verhindern, indem Daten synchron sowohl in den Cache als auch auf den zugrunde liegenden nichtflüchtigen Speicher geschrieben werden.

Für erweiterte Skalierungsarchitekturen optimieren

Um den Anforderungen von groß angelegten oder global verteilten Anwendungen gerecht zu werden, können Sie fortschrittliche Skalierungsarchitekturen einsetzen, um Leistung, Zuverlässigkeit und Traffic-Management zu verbessern.

Traffic mit GKE Inference Gateway ausgleichen

Für Inferenz-Arbeitslasten in einem einzelnen Cluster empfehlen wir die Verwendung von GKE Inference Gateway. Das Inference Gateway ist ein KI-bezogener Load-Balancer, der Inferenzmesswerte überwacht, um Anfragen an den optimalsten Endpunkt weiterzuleiten. Diese Funktion verbessert die Leistung und die Nutzung von Beschleunigern.

Bei Verwendung von GKE Inference Gateway empfehlen wir, die folgenden Best Practices zu beachten:

• Bereitstellungs-Pods in einer InferencePool gruppieren: Definieren Sie eine InferencePool für jede Gruppe von Pods, die Ihre Inferenzarbeitslasten bereitstellen. Weitere Informationen finden Sie unter GKE Inference Gateway-Konfiguration anpassen.
• Latenzkritische Arbeitslasten multiplexen: Definieren Sie InferenceObjectives, um die Bereitstellungseigenschaften Ihres Modells anzugeben, z. B. Name und Priorität. GKE Inference Gateway bevorzugt Arbeitslasten mit höherer Priorität. So können Sie latenzkritische und latenztolerante Arbeitslasten multiplexen und bei hohem Traffic Load-Shedding-Richtlinien implementieren.
• Modellbasiertes Routing verwenden: Wenn Sie Anfragen basierend auf dem Modellnamen im Anfragetext weiterleiten möchten, verwenden Sie bodybasiertes Routing. Wenn Sie Body-basiertes Routing verwenden, müssen Ihre Back-Ends hochverfügbar sein. Das Gateway gibt einen Fehler zurück, wenn die Erweiterung nicht verfügbar ist. So wird verhindert, dass Anfragen falsch weitergeleitet werden.
• Traffic automatisch über das Gateway verteilen: Das GKE Inference Gateway leitet Traffic intelligent weiter, indem es wichtige Messwerte der Inferenzserver im InferencePool überwacht, z. B. die KV-Cache-Auslastung, die Warteschlangenlänge und die Präfix-Cache-Indizes. Durch diesen Echtzeit-Lastausgleich wird die Nutzung von Beschleunigern optimiert, die Tail-Latenz verringert und der Gesamtdurchsatz im Vergleich zu herkömmlichen Methoden erhöht.
• Mit Apigee und Model Armor integrieren: Für mehr Sicherheit und eine bessere Verwaltung können Sie die API-Verwaltung in Apigee und Sicherheitsprüfungen in Model Armor integrieren.

Inferenzarbeitslasten auf mehreren Knoten bereitstellen

Bei sehr großen Modellen, die nicht auf einen einzelnen Knoten passen, müssen Sie die Inferenzarbeitslast auf mehrere Knoten verteilen. Dazu ist eine Architektur erforderlich, die die Latenz der Kommunikation zwischen Knoten minimiert und dafür sorgt, dass alle Komponenten der verteilten Arbeitslast als eine Einheit verwaltet werden.

Beachten Sie die folgenden Best Practices:

• Bandbreite und Durchsatz des Beschleunigernetzwerks maximieren: Wenn eine Arbeitslast auf mehrere Knoten verteilt wird, wird das Netzwerk zu einem kritischen Leistungsfaktor. Um die Latenz bei der Kommunikation zwischen Knoten zu minimieren, verwenden Sie leistungsstarke Netzwerktechnologien wie NVIDIA GPUDirect. Je nach Größe Ihres Clusters und der Intensität der Kommunikation, die für Ihre Arbeitslast erforderlich ist, können Sie aus den folgenden Optionen auswählen:

  • GPUDirect-TCPX: effektiv für eine Reihe von Inferenzarbeitslasten mit mehreren Knoten, die auf A3 High ausgeführt werden.
  • GPUDirect-TCPXO: Bietet eine verbesserte Leistung mit größerer Auslagerung und höherer Bandbreite, was für größere Cluster im Vergleich zu Standard-TCPX von Vorteil ist. Es wird auf A3 Mega-Maschinen ausgeführt.
  • GPUDirect RDMA: Bietet die höchste Bandbreite zwischen Knoten und die niedrigste Latenz, da der direkte Speicherzugriff zwischen GPUs auf verschiedenen Knoten möglich ist, ohne dass die CPU durchlaufen werden muss. Diese Option eignet sich am besten für die anspruchsvollsten, groß angelegten Inferenzszenarien auf A3 Ultra- und A4-Maschinen.

  Weitere Informationen finden Sie unter:

  • GPU-Netzwerkbandbreite in Clustern im Standardmodus maximieren
  • GPU-Netzwerkbandbreite in Clustern im Autopilot-Modus maximieren

  Um zu prüfen, ob Ihre Multi-Node-Netzwerkkonfiguration wie erwartet funktioniert, empfehlen wir, Tests mit Tools wie der NVIDIA Collective Communications Library (NCCL) durchzuführen.

• LeaderWorkerSet zum Verwalten verteilter Arbeitslasten verwenden: Wenn Sie eine zustandsorientierte verteilte Arbeitslast wie einen Inferenzdienst mit mehreren Knoten bereitstellen, ist es wichtig, alle Komponenten als eine Einheit zu verwalten. Verwenden Sie dazu LeaderWorkerSet, eine Kubernetes-native API, mit der Sie eine Gruppe verwandter Pods als einzelne Einheit verwalten können. Ein LeaderWorkerSet sorgt dafür, dass alle Pods im Set gemeinsam erstellt und gelöscht werden. Das ist wichtig, um die Integrität einer verteilten Arbeitslast aufrechtzuerhalten.

• Knoten mit kompakter Platzierung in physischer Nähe platzieren: Der physische Abstand zwischen den Knoten in Ihrer verteilten Arbeitslast kann sich erheblich auf die Netzwerklatenz zwischen den Knoten auswirken. Um diese Latenz zu minimieren, verwenden Sie eine Richtlinie für kompakte Platzierung für Ihre GKE-Knotenpools. Eine Richtlinie für kompakte Platzierung weist GKE an, die Knoten in einem Knotenpool innerhalb einer Zone so nah wie möglich aneinander zu platzieren.

Inferenzarbeitslasten in mehreren Regionen bereitstellen

Für global verteilte Anwendungen, die Hochverfügbarkeit und geringe Latenz erfordern, ist die Bereitstellung Ihrer Inferenz-Arbeitslasten in mehreren Regionen eine wichtige Best Practice. Eine Architektur mit mehreren Regionen kann Ihnen helfen, die Zuverlässigkeit zu erhöhen, die Verfügbarkeit von Beschleunigern zu verbessern, die von Nutzern wahrgenommene Latenz zu verringern und standortspezifische behördliche Anforderungen zu erfüllen.

Wenn Sie einen multiregionalen Inferenzdienst effektiv bereitstellen und verwalten möchten, sollten Sie die folgenden Empfehlungen beachten:

• Stellen Sie GKE-Cluster in mehreren Regionen bereit, in denen Sie Kapazität reserviert haben oder in denen Sie voraussichtlich Kapazität für die Verarbeitung von Spitzenlasten benötigen.
• Wählen Sie die richtige Speicherstrategie für Ihre Modellgewichte aus. Um die betriebliche Effizienz zu optimieren, erstellen Sie einen multiregionalen Cloud Storage-Bucket. Um die Kosten zu optimieren, erstellen Sie in jeder Region einen regionalen Bucket und replizieren Sie die Modellgewichte.
• Mit Anywhere Cache können Sie zonale Lesecaches für Ihre Cloud Storage-Buckets erstellen, um sowohl die Netzwerklatenz als auch die Kosten für ausgehenden Datentraffic zu reduzieren.

Zusammenfassung der Best Practices

In der folgenden Tabelle sind die Best Practices zusammengefasst, die in diesem Dokument empfohlen werden:

Thema	Aufgabe
Bereitstellung und Konfiguration	Merkmale Ihres Anwendungsfalls für die Inferenz analysieren Die richtigen Modelle für Ihre Inferenzanwendungsfälle auswählen Quantisierung auf das Modell anwenden Die richtigen Accelerators auswählen Strategie für die Inferenzverteilung auswählen Konfiguration des Inferenzservers optimieren
Kaltstartlatenz	Pod-Startzeit optimieren Knoten mit schnellem Start aktivieren
Kapazitätsplanung und Verfügbarkeit von Beschleunigern	Kapazität planen und reservieren Dynamic Workload Scheduler verwenden Benutzerdefinierte Compute-Klassen verwenden Standortrichtlinie Ihrer GKE-Cluster und -Knotenpools konfigurieren
Effizienz von Ressourcen und Beschleunigern	Beschleuniger und Inferenzserver beobachten Pods automatisch skalieren Daten näher an Ihre Arbeitslasten verschieben
Load Balancing	GKE Inference Gateway für Single-Cluster-Bereitstellungen verwenden
Bereitstellungen auf mehreren Knoten	Netzwerkbandbreite und ‑durchsatz des Beschleunigers maximieren Pods mit LeaderWorkerSet gruppieren Knoten mithilfe von kompakter Platzierung in räumlicher Nähe platzieren
Multiregionale Bereitstellungen	GKE-Cluster in mehreren Regionen bereitstellen Traffic über Regionen hinweg ausgleichen Modellgewichte in Cloud Storage-Buckets speichern Daten mit Anywhere Cache im Cache speichern

Nächste Schritte

• Weitere Informationen finden Sie in der GKE-Referenzarchitektur für Inferenz.