Best Practices für den Speicher für KI-/ML-Arbeitslasten auf TPU-VMs

Um die Leistung und Kosteneffizienz Ihrer KI-/ML-Arbeitslasten auf TPU-VMs zu maximieren, wählen Sie die richtige Speicherlösung für Ihre Arbeitslast aus und konfigurieren Sie sie entsprechend. Durch das Beseitigen von E/A-Engpässen können Sie die Zeit, in der Ihre TPU-Beschleuniger inaktiv sind, reduzieren. Dadurch werden Trainingszeit und -kosten gesenkt.

Dieses Dokument enthält arbeitslastspezifische Speicherempfehlungen und Best Practices für die Optimierung von Training, Checkpointing, Bereitstellung und Caching auf TPU-VMs. Bevor Sie diese Best Practices anwenden, sollten Sie sich die verfügbaren Speicheroptionen für TPU-Daten ansehen. In diesem Dokument wird davon ausgegangen, dass Sie mit TPU-VMs vertraut sind und grundlegende Erfahrung mit der Bereitstellung von Cloud Storage-Ressourcen haben.

Arbeitslastspezifische Anleitung

Die folgende Tabelle enthält Speicherempfehlungen für verschiedene Arbeitslasten, die nach Priorität sortiert sind:

Arbeitslast Empfehlung Optimierung und Tools (falls zutreffend)
Trainings-Datasets, einschließlich Datenvorbereitung
  1. Verwenden Sie regionale Cloud Storage-Buckets mit Rapid Cache und clientseitiger Optimierung (z. B. Read-Ahead-Lesevorgänge), um die Kosten zu minimieren.
  2. Verwenden Sie Cloud Storage Rapid Bucket, um die beste Leistung und Skalierung zu erzielen.
  3. Verwenden Sie Managed Lustre, wenn Sie Lustre (Dateisystemspeicher) aufgrund hoher Metadaten-Nebenläufigkeit oder kleiner Dateien (unter 1 MB) standardisieren.
  • Aktivieren Sie für regionale Cloud Storage-Buckets den hierarchischen Namespace.
  • Verwenden Sie für regionale Cloud Storage-Buckets oder Rapid Bucket Cloud Storage FUSE und gRPC. Verwenden Sie für GKE das gcsfusecsi-training-Profil.
  • Für Managed Lustre sollten Sie die dynamische Stufe verwenden, um die Kosten zu senken und die Leistung automatisch zu optimieren.
Checkpointing und Gewichte für bestärkendes Lernen
  1. Verwenden Sie Managed Lustre für hohe Leistung ohne umfangreiche Optimierung für Anforderungen mit geringer Latenz (weniger als 1 ms), z. B. synchrone Prüfpunkte und schnelle Gewichtspropagierung für Reinforcement Learning.
  2. Verwenden Sie Cloud Storage Rapid Bucket für den höchsten Durchsatz für asynchrones und mehrstufiges Checkpointing und zum Parallelisieren von Checkpoint-Vorgängen im Speicher. Rapid Bucket bietet den hohen Durchsatz, der für diese Arbeitslasten erforderlich ist.
Verwenden Sie für Rapid Bucket das gcsfusecsi-checkpointing-Profil.
Modellspeicher und ‑download
  1. Verwenden Sie Hyperdisk ML für das Caching kleiner Modelle und bis zu 2.500 Instanzen.
  2. Verwenden Sie dieselbe Speicherlösung, die Sie für Trainings-Datasets verwenden (Managed Lustre, Rapid Bucket oder regionale Buckets), wenn Sie eine einheitliche Speicherlösung verwenden möchten.
Verwenden Sie zum Herunterladen von Modellen GKE Run:ai Model Streamer oder Cloud Storage FUSE mit einem separaten Bereitstellungspunkt mit dem gcsfusecsi-serving-Profil.
Auslagerung des Schlüssel/Wert-Cache (KV)
  1. Verwende immer den Arbeitsspeicher (RAM) der Host-CPU als primäre Ebene, um VRAM freizugeben, ohne die Latenz erheblich zu erhöhen.
  2. Wenn der CPU-Arbeitsspeicher nicht ausreicht, verwenden Sie Managed Lustre als parallele, latenzarme zweite Ebene in der Cachehierarchie, um die Anforderungen an die extrem niedrige Latenz (weniger als 1 ms) für das Auslagern von Schlüssel/Wert-Caches bei hohem Durchsatz (bis zu 10 TB/s) zu erfüllen.

Cloud Storage-Optimierungen

In den folgenden Abschnitten werden Best Practices zur Optimierung der Leistung bei der Verwendung von Cloud Storage mit TPU-VMs beschrieben.

Hierarchischen Namespace für die Metadatenoptimierung aktivieren

Um die Metadatenleistung zu verbessern, aktivieren Sie den hierarchischen Namespace, wenn Sie regionale Buckets für KI/ML-Arbeitslasten erstellen. Die Metadatenleistung bezieht sich darauf, wie schnell Cloud Storage Vorgänge verarbeiten kann, bei denen Objektpfade und Ordner gesucht, aufgelistet oder geändert werden, anstatt den Dateiinhalt selbst zu lesen oder zu schreiben.

In Buckets ohne aktivierten hierarchischen Namespace sind Ordner keine tatsächlichen Ressourcen, sondern simulierte Ordner, die durch Objektname-Präfixe dargestellt werden, die durch Schrägstriche (/) getrennt sind. Dadurch werden Vorgänge wie das Auflisten von Verzeichnisinhalten oder das Umbenennen von Verzeichnissen langsam, da das System alle Objekte mit diesem Präfix scannen muss. Der hierarchische Namespace bietet eine echte Dateisystemstruktur, die aus mehreren Gründen für KI-/ML-Arbeitslasten wichtig ist:

  • Atomare Verzeichnisumbenennungen: ML-Frameworks verwenden Verzeichnisumbenennungen, um Checkpoints abzuschließen. Der hierarchische Namespace unterstützt atomare Umbenennungen, sodass Checkpoints schnell abgeschlossen werden.
  • Höhere anfängliche QPS: Der hierarchische Namespace unterstützt bis zu achtmal mehr anfängliche Abfragen pro Sekunde (QPS) für Lese- und Schreibvorgänge im Vergleich zu Buckets ohne aktivierten hierarchischen Namespace. So werden Engpässe vermieden, wenn viele TPUs gleichzeitig auf den Speicher zugreifen.
  • Effiziente Vorgänge auf Ordnerebene: Das Suchen und Auflisten von Dateien in bestimmten Verzeichnissen ist viel schneller, was die Reaktionszeiten beim Training und Laden von Daten verkürzt.

Für zonale Buckets, die über Rapid Bucket angeboten werden, wird standardmäßig ein hierarchischer Namespace verwendet. Weitere Informationen finden Sie unter Hierarchischer Namespace – Übersicht.

Cloud Storage FUSE mit geeigneten Profilen verwenden

Cloud Storage FUSE ist ein FUSE-Adapter, mit dem Sie Buckets als lokales Dateisystem bereitstellen können. Wenn Sie Google Kubernetes Engine verwenden, empfehlen wir, den Cloud Storage FUSE-CSI-Treiber und die Cloud Storage FUSE-Profile zu verwenden, um die Leistungsoptimierung zu automatisieren.

Weitere Informationen zu Best Practices für die Verwendung von Cloud Storage FUSE finden Sie unter Best Practices für die Leistungsoptimierung.

TPU-VM-Bootlaufwerk anpassen

Sie können die Gastbetriebssystemumgebung auf einer TPU-VM anpassen, indem Sie Startskripts verwenden oder benutzerdefinierte Images erstellen. Die Anpassung des Bootlaufwerks ist in den folgenden Szenarien nützlich:

  • Vorabladen von Software und Bibliotheken: Installieren Sie bestimmte ML-Frameworks, Abhängigkeiten oder benutzerdefinierte Software, um die Startzeit von VMs zu verkürzen und für konsistente Umgebungen zu sorgen.
  • Verwendung nicht standardmäßiger Betriebssystemversionen: Sie verwenden eine Betriebssystemversion, die nicht in der von Google verwalteten Liste enthalten ist.
  • Sicherheits- und Monitoringkonfigurationen anwenden: Wenden Sie benutzerdefinierte Sicherheitseinstellungen an, installieren Sie Monitoring-Agents oder legen Sie Umgebungsvariablen fest.

Die Wiederherstellung von Bootlaufwerken für TPU-VMs ist jedoch eingeschränkt. Sie können das Bootlaufwerk nicht trennen oder einen Snapshot davon erstellen, um es offline zu reparieren. Seien Sie daher vorsichtig, wenn Sie Änderungen vornehmen, die sich auf den Bootvorgang auswirken. Wenn Sie diese Best Practices befolgen, können Sie das Risiko von Startfehlern beim Anpassen Ihrer TPU-VM-Umgebungen verringern.

Beachten Sie beim Anpassen Ihres Bootlaufwerks die folgenden wichtigen Grundsätze:

  • Änderungen am Bootlaufwerk minimieren: Installieren Sie Anwendungen und speichern Sie Daten nach Möglichkeit auf Persistent Disk- oder Hyperdisk-Volumes, anstatt das Bootlaufwerk stark zu ändern.

  • UUIDs für die Bereitstellung verwenden: Wenn Sie der Datei /etc/fstab Einträge hinzufügen, verwenden Sie immer UUIDs, um Laufwerke und Partitionen (UUID=...) zu identifizieren, anstatt Gerätenamen wie /dev/sdb1. Automatisch generierte Gerätenamen sind nicht garantiert stabil bei Neustarts.

Mit diesen Empfehlungen können Sie das Risiko von Startfehlern bei Systemänderungen verringern:

  • Fehlerbehandlung: Implementieren Sie in Ihren Skripts eine robuste Fehlerprüfung und einen ordnungsgemäßen Fehlermodus. Detaillierte Meldungen in der seriellen Konsole und in Cloud Logging protokollieren, um die Fehlersuche zu erleichtern.

  • Kritische Abhängigkeiten: Seien Sie äußerst vorsichtig, wenn Sie Dateien ändern, die für den Startvorgang unerlässlich sind, z. B. die Datei /etc/fstab, Netzwerkkonfigurationen oder Bootloader-Einstellungen. Ein Syntaxfehler oder eine falsche Eingabe kann dazu führen, dass die VM nicht mehr gestartet werden kann.

  • Sekundäre Laufwerke: Wenn Ihr Skript auf sekundären Laufwerken basiert, muss es Fälle berücksichtigen, in denen das Laufwerk möglicherweise nicht vorhanden ist oder das Anhängen länger als erwartet dauert. Vermeiden Sie es, den Bootvorgang kritisch von sekundären Laufwerkbereitstellungen abhängig zu machen, es sei denn, dies ist unbedingt erforderlich.

    Im Folgenden finden Sie Beispiele für empfohlene und nicht empfohlene /etc/fstab-Einträge zum Bereitstellen eines sekundären Laufwerks:

    • Empfohlen: UUID=a1b2c3d4-e5f6-7890-1234-567890abcdef /mnt/mydata ext4 defaults,nofail 0 2
    • Nicht empfohlen: /dev/sdb1 /mnt/mydata ext4 defaults 0 2

    Mit der Option nofail kann verhindert werden, dass das System angehalten wird, wenn das Laufwerk nicht gefunden wird. Ihre Anwendung muss jedoch in der Lage sein, den nicht verfügbaren Bereitstellungspunkt zu verarbeiten.

  • Paketverwaltung: Seien Sie vorsichtig, wenn Sie Drittanbieter-Repositories hinzufügen. Sie müssen vertrauenswürdig und mit dem Basis-Betriebssystem-Image kompatibel sein. Machen Sie sich mit den Abhängigkeiten aller installierten Pakete und ihren potenziellen Auswirkungen auf Systembibliotheken vertraut.

  • Speicherplatz: Überwachen Sie die Nutzung des Bootlaufwerks. Umfangreiches Logging oder große Softwareinstallationen können das Bootlaufwerk füllen und verhindern, dass die VM gestartet wird.

  • Logging: Konfigurieren Sie Ihre Anwendungen und Skripts so, dass sie ausführlich in der seriellen Konsole protokolliert werden, da dies das primäre Tool zur Diagnose von Startproblemen auf TPU-VMs ist.

Speicherkapazität planen

Es ist wichtig, die Menge an Speicherkapazität zu planen, die für Ihre Arbeitslast erforderlich ist, um Ihre Beschleuniger vollständig zu nutzen. Dazu gehören die Speicherkapazität und die Bandbreite für Checkpoints.

Speicher schätzen

Sie können die folgenden Schätzungen als Start für Ihren Speicherbedarf verwenden:

Arbeitslasttyp Speicherung von Datasets Speicher für Prüfpunkte
LLM-Vortraining 2 TB pro TPU 200 GB pro TPU
Multimodales Training 12 TB pro TPU 1 TB pro TPU
Inferenz 1 TB pro TPU 1 GB pro TPU

Bandbreite für Checkpoints schätzen

Mit der folgenden Formel können Sie die für Trainingsarbeitslasten erforderliche Mindestbandbreite für Prüfpunkte schätzen. Erhöhen Sie für Datenlesevorgänge, mehrere Trainingsläufe oder Training und Inferenz die geschätzten Bandbreitenanforderungen entsprechend.

  1. Checkpoint-Größe: Anzahl der Parameter × Bytes pro Parameter (ungefähr 12–16 Bytes pro Parameter für FP16 + Optimiererstatus). Fügen Sie einen Puffer (etwa das Dreifache) für Optimierungsstatus und verschiedene Genauigkeiten hinzu.
  2. Prüfpunktintervall: Wie oft Sie einen Prüfpunkt speichern (z. B. alle 15 Minuten).
  3. Erforderliche Bandbreite: Checkpoint-Größe ÷ Checkpoint-Intervall.

Das folgende Beispiel zeigt, wie die minimale Checkpointing-Bandbreite für Qwen3-72B geschätzt wird:

  1. Größe des Prüfpunkts: 72 Mrd. Parameter × 12 Byte ≈ 864 GB pro Prüfpunkt. Mit Puffer: 3 × 864 GB ≈ 2,5 TB.
  2. Prüfpunktintervall: 2 Minuten = 120 Sekunden.
  3. Erforderliche Bandbreite: 2,5 TB ÷ 120 Sekunden ≈ 20 GB/s.

Referenzrezepte

Beispiele für Speicherkonfigurationen für bestimmte Hardware und Arbeitslasten finden Sie in den folgenden Rezepten:

Kontingente und Bandbreitenbeschränkungen

Die Bandbreite für Cloud Storage- und Compute Engine-Angebote wird durch Standardkontingente begrenzt. Wenn Sie ein Kontingent überschreiten, werden Ihre Ein- und Ausgabefelder möglicherweise gedrosselt.

Informationen zu Cloud Storage-Kontingenten und zum Anfordern von Erhöhungen finden Sie in der Cloud Storage-Dokumentation unter Kontingente und Limits. Informationen zu Compute Engine-Kontingenten für Hyperdisk und Persistent Disk finden Sie unter Kontingente für Laufwerke.

Nächste Schritte