Best Practices für die Leistungsoptimierung

Auf dieser Seite finden Sie Informationen dazu, wie Sie Cloud Storage FUSE mithilfe wichtiger Cloud Storage FUSE-Funktionen und -Konfigurationen optimieren können, um maximalen Durchsatz und optimale Leistung zu erzielen, insbesondere für KI-/ML-Arbeitslasten (künstliche Intelligenz und maschinelles Lernen) wie Training, Bereitstellung und Checkpointing.

Hinweise

Bevor Sie die auf dieser Seite empfohlenen Konfigurationen anwenden, sollten Sie Folgendes beachten:

• Sie können die empfohlenen Konfigurationen auf dieser Seite mit drei Methoden anwenden:

  • Cloud Storage FUSE-Konfigurationsdatei

  • Cloud Storage FUSE-Befehlszeilenoptionen

  • Nur für Google Kubernetes Engine: Google Kubernetes Engine-YAML-Beispieldateien

• Prüfen Sie, ob Sie die aktuelle Version von Cloud Storage FUSE verwenden. Die empfohlenen Konfigurationen sollten nur auf Cloud Storage FUSE-Version 3.0 oder höher und den Cloud Storage FUSE CSI-Treiber für Google Kubernetes Engine angewendet werden, der auf GKE-Clustern mit Version 1.32.2-gke.1297001 oder höher ausgeführt wird.

• Bei den empfohlenen Konfigurationen werden Cloud Storage-Metadaten für die Dauer des Jobs im Cache gespeichert und nach dem ersten Mounten des Dateisystems nicht mehr geprüft. Daher empfehlen wir, dass das Dateisystem schreibgeschützt ist oder die Dateisystemsemantik write-to-new-Anwendungen verwendet, d. h. Anwendungen schreiben immer in neue Dateien, um eine optimale Leistung zu erzielen. Die folgenden KI-/ML-Arbeitslasten sind „write-to-new“:

  • Prüfpunktausführung

  • Training

  • Serving

  • jax.jit()-Caching

• Die empfohlenen Konfigurationen auf dieser Seite wurden für Cloud-GPUs und große Cloud TPU-Maschinentypen im großen Maßstab validiert, bei denen viel Arbeitsspeicher und eine Netzwerkbandbreite mit hoher Bandbreite vorhanden sind. Cloud-GPUs und Cloud TPU-Maschinentypen können sich hinsichtlich der Anzahl der verfügbaren Ressourcen wie CPU, Arbeitsspeicher und lokaler Speicher in ihrer Hostknotenkonfiguration unterscheiden. Dies kann sich direkt auf die Leistung von Konfigurationen wie den folgenden auswirken:

  • A3 Ultra

  • A3 Mega: 1,8 TiB Arbeitsspeicher, mit 6 TiB LSSD

  • Cloud TPU v5e – 188 GiB Speicher, ohne LSSD

  • Cloud TPU v5p: 448 GiB Arbeitsspeicher, kein LSSD

  • Cloud TPU v6 (Trillium): 1,5 TiB Arbeitsspeicher, kein LSSD

Buckets mit aktiviertem hierarchischen Namespace verwenden

Verwenden Sie immer Buckets mit aktiviertem hierarchischen Namespace. Im hierarchischen Namespace werden Ihre Daten in einer hierarchischen Dateisystemstruktur organisiert. Dadurch werden Vorgänge im Bucket effizienter, was zu schnelleren Reaktionszeiten und insgesamt weniger Listenaufrufen für jeden Vorgang führt.

Der hierarchische Namespace bietet unter anderem folgende Vorteile:

• Buckets mit hierarchischem Namespace bieten bis zu achtmal höhere anfängliche Abfragen pro Sekunde (QPS) als flache Buckets. Der hierarchische Namespace unterstützt 40.000 Lesevorgänge pro Sekunde und 8.000 Schreibvorgänge pro Sekunde, was deutlich mehr ist als bei typischen Cloud Storage FUSE-Buckets, die anfangs nur 5.000 Lesevorgänge pro Sekunde und 1.000 Schreibvorgänge pro Sekunde bieten.

• Der hierarchische Namespace bietet atomare Verzeichnisumbenennungen, die für das Erstellen von Prüfpunkten mit Cloud Storage FUSE erforderlich sind, um die Atomizität zu gewährleisten. Die Verwendung von Buckets mit aktiviertem hierarchischen Namespace ist besonders beim Checkpointing im großen Maßstab von Vorteil, da ML-Frameworks Verzeichnisumbenennungen verwenden, um Checkpoints abzuschließen. Dies ist ein schneller, atomarer Befehl, der nur in Buckets mit aktiviertem hierarchischen Namespace unterstützt wird. Wenn Sie keinen Bucket mit aktiviertem hierarchischen Namespace verwenden möchten, lesen Sie den Abschnitt Limit für das Umbenennen von Buckets ohne hierarchischen Namespace erhöhen.

Informationen zum Erstellen eines Buckets mit aktiviertem hierarchischen Namespace finden Sie unter Buckets mit aktiviertem hierarchischen Namespace erstellen. Informationen zum Einbinden eines Buckets mit aktiviertem hierarchischen Namespace finden Sie unter Buckets mit aktiviertem hierarchischen Namespace einbinden. Hierarchical Namespace wird in Google Kubernetes Engine-Versionen ab 1.31.1-gke.2008000 unterstützt.

Verzeichnisspezifische Bereitstellung durchführen

Wenn Sie auf ein bestimmtes Verzeichnis in einem Bucket zugreifen möchten, können Sie nur das jeweilige Verzeichnis mit der Bereitstellungsoption only-dir bereitstellen, anstatt den gesamten Bucket bereitzustellen. Durch die verzeichnisspezifische Einbindung werden Listenaufrufe beschleunigt und die Gesamtzahl der Listen- und Statusaufrufe reduziert. Das liegt daran, dass die Anzahl der zu durchlaufenden Verzeichnisse beim Auflösen eines Dateinamens begrenzt wird. LookUpInode-Aufrufe und Bucket- oder Verzeichniszugriffsanfragen generieren automatisch Listen- und Statusaufrufe für jede Datei oder jedes Verzeichnis im Pfad.

Verwenden Sie die folgende Bereitstellungskonfiguration, um ein bestimmtes Verzeichnis bereitzustellen:

volumeHandle: BUCKET_NAME
 - only-dir:DIRECTORY_NAME

Wobei:

• BUCKET_NAME ist der Name des Buckets, in dem Sie das Verzeichnis bereitstellen möchten.

• DIRECTORY_NAME ist der Name des Verzeichnisses, das Sie einbinden möchten.

Weitere Informationen zum Bereitstellen eines Verzeichnisses finden Sie unter Verzeichnis in einem Bucket bereitstellen.

Metadaten-Cache-Werte erhöhen

Zur Verbesserung der Leistung bei wiederholten Lesevorgängen können Sie Cloud Storage FUSE so konfigurieren, dass eine große Menge an Metadaten im Cache gespeichert und das Ablaufen von Metadaten umgangen wird. Dadurch werden wiederholte Metadatenanfragen an Cloud Storage vermieden und die Leistung deutlich verbessert.

Das Erhöhen der Metadatencachewerte ist für Arbeitslasten mit wiederholten Lesevorgängen von Vorteil, um wiederholte Cloud Storage-Aufrufe zu vermeiden, und für schreibgeschützte Volumes, für die eine unendliche TTL festgelegt werden kann.

Beachten Sie Folgendes, bevor Sie die Werte für den Metadaten-Cache erhöhen:

• Eine unendliche Gültigkeitsdauer (Time to Live, TTL) sollte nur für Volumes festgelegt werden, die entweder schreibgeschützt sind oder nur in neue Volumes geschrieben werden.

• Der Metadatencache sollte nur auf Knoten mit großen Arbeitsspeicherkonfigurationen aktiviert werden, da er alle Metadaten für den angegebenen Mount-Point auf jedem Knoten speichert und zusätzliche Zugriffe auf Cloud Storage überflüssig macht.

• Die Konfigurationen in diesem Abschnitt speichern alle aufgerufenen Metadaten mit einer unendlichen TTL im Cache. Dies kann sich auf die Konsistenzgarantien auswirken, wenn Änderungen am selben Cloud Storage-Bucket durch einen anderen Client vorgenommen werden, z. B. Überschreibungen oder Löschungen einer Datei.

• Prüfen Sie, ob der Arbeitsspeicherverbrauch nicht beeinträchtigt wird, indem Sie bestätigen, dass die Menge des vom Metadatencache verbrauchten Arbeitsspeichers für Sie akzeptabel ist. Sie kann in Gigabyte anwachsen und hängt von der Anzahl der Dateien in den eingebundenen Buckets und der Anzahl der verwendeten Mount-Punkte ab. Die Metadaten jeder Datei benötigen beispielsweise etwa 1,5 KiB Arbeitsspeicher. Die Metadaten von einer Million Dateien benötigen also etwa 1,5 GiB Arbeitsspeicher. Weitere Informationen finden Sie unter Caching – Übersicht.

Führen Sie die folgenden Schritte aus, um Cloud Storage FUSE so zu konfigurieren, dass eine große Menge an Metadaten im Cache gespeichert und das Ablaufen von Metadaten umgangen wird:

gcsfuse --metadata-cache-ttl-secs=-1 \
      --stat-cache-max-size-mb=-1 \
      --type-cache-max-size-mb=-1 \
      BUCKET_NAME MOUNT_POINT

metadata-cache:
stat-cache-max-size-mb: -1
ttl-secs: -1
type-cache-max-size-mb: -1

  mountOptions:
      - metadata-cache:ttl-secs:-1
      - metadata-cache:stat-cache-max-size-mb:-1
      - metadata-cache:type-cache-max-size-mb:-1

Metadaten-Cache vorab füllen

Bevor Sie eine Arbeitslast ausführen, empfehlen wir, den Metadaten-Cache vorab zu füllen. Dadurch wird die Leistung erheblich verbessert und die Anzahl der Metadatenaufrufe an Cloud Storage deutlich reduziert, insbesondere wenn die Konfigurationsoption implicit-dirs verwendet wird. Der Cloud Storage FUSE-CSI-Treiber für GKE bietet eine API, mit der der Metadatencache vorab aufgefüllt werden kann. Weitere Informationen finden Sie unter Metadaten-Prefetching zum Vorab-Auffüllen des Metadatencache verwenden.

Verwenden Sie eine der folgenden Methoden, um den Metadatencache vorab zu füllen:

  apiVersion: v1
  kind: PersistentVolume
  metadata:
    name: training-bucket-pv
  spec:
    ...
    csi:
      volumeHandle: BUCKET_NAME
      volumeAttributes:
        ...
        gcsfuseMetadataPrefetchOnMount: "true"
  

ls -R MOUNT_POINT > /dev/null

Dateicaching und parallele Downloads aktivieren

Mit dem Dateicaching können Sie häufig aufgerufene Dateidaten lokal auf Ihrem Computer speichern. Dadurch werden wiederholte Lesevorgänge beschleunigt und die Cloud Storage-Kosten gesenkt. Wenn Sie das Zwischenspeichern von Dateien aktivieren, werden auch parallele Downloads automatisch aktiviert. Bei parallelen Downloads wird eine Datei mithilfe mehrerer Worker parallel heruntergeladen und das Dateicache-Verzeichnis als Prefetch-Puffer verwendet. Dadurch wird die Modellladezeit um das Neunfache verkürzt.

Informationen zum Aktivieren und Konfigurieren von Datei-Caching und parallelen Downloads finden Sie unter Caching-Verhalten aktivieren und konfigurieren. Eine Beispielkonfiguration finden Sie unter Beispielkonfiguration zum Aktivieren von Datei-Caching und parallelen Downloads.

Cloud-GPUs und Cloud TPU für die Verwendung von Dateicaching und parallelen Downloads

Der Datei-Cache kann auf lokalen SSDs, RAM, Persistent Disk oder Google Cloud Hyperdisk gehostet werden. Beachten Sie dabei die folgenden Hinweise. In allen Fällen müssen die Daten oder die einzelne große Datei in die verfügbare Kapazität des Dateicache-Verzeichnisses passen, das mit der Konfiguration max-size-mb gesteuert wird.

Cloud GPUs – Überlegungen

Lokale SSDs eignen sich ideal für Trainingsdaten und Checkpoint-Downloads. Cloud GPU-Maschinentypen enthalten SSD-Kapazität, die verwendet werden kann, z. B. A4-Maschinentypen mit 12 TiB SSD.

• Eine RAM-Disk bietet die beste Leistung zum Laden von Modellgewichten, da sie im Vergleich zum nicht verwendeten RAM auf dem System klein sind.

• Sowohl Persistent Disk als auch Google Cloud Hyperdisk können als Cache verwendet werden.

Cloud TPU-Überlegungen

Cloud TPU unterstützen keine lokalen SSDs. Wenn Sie das Dateicaching auf Cloud TPU ohne Änderungen verwenden, ist der Standardspeicherort das Boot-Volume. Dies wird nicht empfohlen und führt zu einer schlechten Leistung.

Anstelle des Boot-Volumes empfehlen wir die Verwendung einer RAM-Disk, die aufgrund ihrer Leistung und ohne zusätzliche Kosten bevorzugt wird. Eine RAM-Festplatte ist jedoch oft in der Größe begrenzt und eignet sich nicht für die Bereitstellung von Modellgewichten. Alternativ empfehlen wir, Persistent Disk und Google Cloud Hyperdisk für Caching-Zwecke zu verwenden.

Beispielkonfiguration zum Aktivieren des Dateicachings und paralleler Downloads

Standardmäßig wird für den Dateicache eine lokale SSD verwendet, wenn der ephemeral-storage-local-ssd-Modus für den Google Kubernetes Engine-Knoten aktiviert ist. Wenn keine lokale SSD verfügbar ist, z. B. auf Cloud TPU-Maschinen, verwendet der Dateicache die Bootdisk des Google Kubernetes Engine-Knotens. Dies wird nicht empfohlen. In diesem Fall können Sie eine RAM-Festplatte als Cacheverzeichnis verwenden. Berücksichtigen Sie jedoch die Menge an RAM, die für das Zwischenspeichern von Dateien verfügbar ist, im Vergleich zu dem, was der Pod benötigt.

gcsfuse --file-cache-max-size-mb: -1 \
      --file-cache-cache-file-for-range-read: true \
      --file-cache-enable-parallel-downloads: true \
      BUCKET_NAME

file-cache:
  max-size-mb: -1
  cache-file-for-range-read: true
  enable-parallel-downloads: true

mountOptions:
    - file-cache:max-size-mb:-1
    - file-cache:cache-file-for-range-read:true
    - file-cache:enable-parallel-downloads:true

# RAM disk file cache if LSSD not available. Uncomment to use
# volumes:
#   - name: gke-gcsfuse-cache
#     emptyDir:
#       medium: Memory

mountOptions:
    - file-cache:max-size-mb:-1
    - file-cache:cache-file-for-range-read:true 
    - file-cache:enable-parallel-downloads:true 

volumes:
    - name: gke-gcsfuse-cache
      emptyDir:
        medium: Memory

Negative Statistik-Cache-Einträge deaktivieren

Standardmäßig speichert Cloud Storage FUSE negative Statistikeinträge, d. h. Einträge für nicht vorhandene Dateien, mit einer TTL von fünf Sekunden im Cache. Bei Arbeitslasten, bei denen Dateien häufig erstellt oder gelöscht werden, z. B. bei der verteilten Erstellung von Prüfpunkten, können diese Cacheeinträge schnell veralten, was zu Leistungsproblemen führt. Um dies zu vermeiden, empfehlen wir, den Cache für negative Statistiken für Trainings-, Bereitstellungs- und Checkpointing-Arbeitslasten mit der Konfigurationsoption negative-ttl-secs zu deaktivieren.

So deaktivieren Sie den Cache für negative Statistiken:

gcsfuse --metadata-cache-negative-ttl-secs: 0 \
  BUCKET_NAME

metadata-cache:
 negative-ttl-secs: 0

mountOptions:
    - metadata-cache:negative-ttl-secs:0

Streaming-Schreibvorgänge aktivieren

Beim Streaming-Schreiben werden Daten direkt in Cloud Storage hochgeladen, während sie geschrieben werden. Dadurch werden Latenz und Speicherplatzbedarf reduziert. Das ist besonders bei großen, sequenziellen Schreibvorgängen wie Checkpoints von Vorteil. Streaming-Schreibvorgänge sind in Cloud Storage FUSE-Version 3.0 und höher standardmäßig aktiviert.

Wenn Streaming-Schreibvorgänge nicht standardmäßig aktiviert sind, folgen Sie der Anleitung unten, um sie zu aktivieren. Für das Aktivieren von Streaming-Schreibvorgängen ist Cloud Storage FUSE Version 3.0 erforderlich, die in Google Kubernetes Engine-Versionen 1.32.1-gke.1729000 oder höher verfügbar ist.

gcsfuse --enable-streaming-writes: true \
  BUCKET_NAME

write:
 enable-streaming-writes: true

mountOptions:
    - write:enable-streaming-writes:true

Größe des Kernel-Read-Ahead erhöhen

Bei Arbeitslasten, die hauptsächlich sequenzielle Lesevorgänge großer Dateien umfassen, z. B. beim Serving und beim Wiederherstellen von Checkpoints, kann eine Erhöhung der Readahead-Größe die Leistung erheblich verbessern. Dazu können Sie den Linux-Kernelparameter read_ahead_kb auf Ihrem lokalen Computer verwenden. Wir empfehlen, den Kernelparameter read_ahead_kb auf 1 MB zu erhöhen, anstatt die Standardeinstellung von 128 KB zu verwenden, die in den meisten Linux-Distributionen festgelegt ist. Für Compute Engine-Instanzen sind entweder sudo- oder root-Berechtigungen erforderlich, um den Kernelparameter zu erhöhen.

Um den Kernelparameter read_ahead_kb für ein bestimmtes mit Cloud Storage FUSE bereitgestelltes Verzeichnis auf 1 MB zu erhöhen, verwenden Sie den folgenden Befehl, wobei /path/to/mount/point Ihr Cloud Storage FUSE-Bereitstellungspunkt ist. Ihr Bucket muss in Cloud Storage FUSE eingebunden sein, bevor Sie den Befehl ausführen. Andernfalls wird der Kernelparameter nicht erhöht.

  mountOptions:
    - read_ahead_kb=1024
  

Security Token Service deaktivieren, um redundante Prüfungen zu vermeiden

Der Cloud Storage FUSE-CSI-Treiber für Google Kubernetes Engine führt Zugriffsprüfungen durch, um die Wiederherstellbarkeit von Pods aufgrund von Fehlkonfigurationen von Workload Identity-Bindungen zwischen dem Bucket und dem GKE-Dienstkonto durch den Nutzer sicherzustellen. Diese können im großen Maßstab die Standardkontingente der Security Token Service API erreichen. Dies kann deaktiviert werden, indem Sie das Volume-Attribut skipCSIBucketAccessCheck des CSI-Treibers für nichtflüchtige Volumes festlegen. Wir empfehlen, dass Sie dafür sorgen, dass das GKE-Dienstkonto den richtigen Zugriff auf den Cloud Storage-Ziel-Bucket hat, um Mount-Fehler für den Pod zu vermeiden.

Außerdem muss das Kontingent für den Security Token Service über den Standardwert von 6000 hinaus erhöht werden, wenn ein Google Kubernetes Engine-Cluster aus mehr als 6.000 Knoten besteht. Andernfalls kann es bei großen Bereitstellungen zu 429-Fehlern kommen. Das Kontingent für den Security Token Service muss über die Seite Kontingente und Limits erhöht werden. Wir empfehlen, das Kontingent an die Anzahl der Bereitstellungen anzupassen. Wenn es beispielsweise 10.000 Bereitstellungen im Cluster gibt, sollte das Kontingent auf 10000 erhöht werden.

So legen Sie das Attribut „skipCSIBucketAccessCheck“ für das Volume fest:

  volumeAttributes:
      - skipCSIBucketAccessCheck: "true"
   

Weitere Hinweise zur Leistung

Neben den primären Optimierungen, die wir besprochen haben, können auch andere Faktoren die Gesamtleistung von Cloud Storage FUSE erheblich beeinträchtigen. In den folgenden Abschnitten werden zusätzliche Leistungsaspekte beschrieben, die Sie bei der Verwendung von Cloud Storage FUSE berücksichtigen sollten.

Limit für das Umbenennen von Buckets, die nicht HNS-kompatibel sind, erhöhen

Für Checkpointing-Arbeitslasten sollte immer ein Bucket mit aktiviertem hierarchischen Namespace verwendet werden, da atomare und schnellere Umbenennungen sowie ein höherer QPS für Lese- und Schreibvorgänge möglich sind. Wenn Sie jedoch das Risiko akzeptieren, dass das Umbenennen von Verzeichnissen nicht atomar ist und länger dauert, können Sie die Konfigurationsoption rename-dir-limit verwenden, wenn Sie Checkpointing mit Buckets ohne hierarchischen Namespace durchführen, um ein Limit für die Anzahl der Dateien oder Vorgänge festzulegen, die zu einem bestimmten Zeitpunkt an einem Umbenennungsvorgang für ein Verzeichnis beteiligt sind.

Wir empfehlen, die Konfigurationsoption rename-dir-limit auf einen hohen Wert zu setzen, um Checkpointing-Fehler zu vermeiden. Da Cloud Storage FUSE einen flachen Namespace verwendet und Objekte unveränderlich sind, müssen beim Umbenennen eines Verzeichnisses alle einzelnen Dateien im Verzeichnis umbenannt und gelöscht werden. Sie können die Anzahl der Dateien, die von einem Umbenennungsvorgang betroffen sind, mit der Konfigurationsoption rename-dir-limit steuern.

So legen Sie die Konfigurationsoption rename-dir-limit fest:

gcsfuse --rename-dir-limit: 200000 \
  BUCKET_NAME

file-system:
 rename-dir-limit: 200000

mountOptions:
    - rename-dir-limit=200000

Kernel-Listen-Caching

Der Listen-Cache ist ein Cache für Verzeichnis- und Dateilisten oder ls, Antworten zur Verbesserung der Geschwindigkeit von Listenvorgängen. Im Gegensatz zu den Statistik- und Typ-Caches, die von Cloud Storage FUSE verwaltet werden, wird der Listen-Cache im Seitencache des Kernels gespeichert und vom Kernel basierend auf der Arbeitsspeicherverfügbarkeit gesteuert.

Das Aktivieren des Kernel-Listen-Cachings ist für die folgenden Anwendungsfälle am sinnvollsten:

• Arbeitslasten mit wiederholten Verzeichniseinträgen: Diese Konfiguration ist besonders nützlich für Arbeitslasten, die häufig vollständige Verzeichniseinträge ausführen, z. B. KI/ML-Trainingsläufe. Das kann sowohl für Bereitstellungs- als auch für Trainingsarbeitslasten von Vorteil sein.

• Schreibgeschützte Bereitstellungen: Bei schreibgeschützten Bereitstellungen wird das Zwischenspeichern von Listen empfohlen, um Konsistenzprobleme zu vermeiden.

Das Aktivieren des Kernel-Listen-Caching sollte mit Vorsicht erfolgen und nur verwendet werden, wenn das Dateisystem wirklich schreibgeschützt ist und während der Ausführung eines Jobs keine Änderungen am Verzeichnisinhalt erwartet werden. Das liegt daran, dass die lokale Anwendung mit diesem Flag nie Updates sieht, insbesondere wenn die TTL auf -1 festgelegt ist.

In Client 1 ist beispielsweise directoryA aufgeführt, wodurch directoryA im Kernel-Listen-Cache verbleibt. Client 2 erstellt fileB unter directoryA im Cloud Storage-Bucket. Client 1 sucht kontinuierlich nach fileB in directoryA. Dabei wird im Grunde der Cacheeintrag der Kernelliste geprüft und es wird nie über das Netzwerk gesucht. Client 1 sieht nicht, dass sich eine neue Datei im Verzeichnis befindet, da die Liste der Dateien kontinuierlich aus dem lokalen Kernel-Listencache bereitgestellt wird. Client 1 hat dann ein Zeitlimit überschritten und das Programm wird beendet.

So aktivieren Sie das Listencaching:

gcsfuse --kernel-list-cache-ttl-secs: -1 \
  BUCKET_NAME

file-system:
 kernel-list-cache-ttl-secs: -1

mountOptions:
    - file-system:kernel-list-cache-ttl-secs:-1

Wenn Sie die Bereitstellungsoption file-system:kernel-list-cache-ttl-secs verwenden, haben die Werte folgende Bedeutung:

• Ein positiver Wert, der die TTL in Sekunden darstellt, um die Antwort der Verzeichnisliste im Seitencache des Kernels zu speichern.

• Der Wert -1 umgeht den Ablauf des Eintrags und gibt die Listenantwort aus dem Cache zurück, wenn sie verfügbar ist.

JAX-Cache für persistente Kompilierung (JIT) mit Cloud Storage FUSE verwenden

JAX unterstützt den Just-In-Time-Cache (JIT), einen optionalen persistenten Kompilierungscache, in dem kompilierte Funktionsartefakte gespeichert werden. Wenn Sie diesen Cache verwenden, können Sie nachfolgende Skriptausführungen erheblich beschleunigen, da redundante Kompilierungsschritte vermieden werden.

Damit Sie JIT-Caching aktivieren können, müssen die folgenden Anforderungen erfüllt sein:

• Neueste Version von JAX verwenden: Verwenden Sie JAX-Versionen 0.5.1 oder höher, um die neuesten Cachefunktionen und ‑optimierungen zu nutzen.

• Cachekapazität maximieren: Um Leistungseinbußen aufgrund von Cache-Entfernung zu vermeiden, sollten Sie eine unbegrenzte Cachegröße festlegen, insbesondere wenn Sie die Standardeinstellungen überschreiben möchten. Dazu können Sie die Umgebungsvariable so festlegen:

  export JAX_COMPILATION_CACHE_MAX_SIZE=-1
  

• YAML-Datei für Checkpoint-Pod prüfen: Verwenden Sie die Checkpoint-Konfiguration für den Mountpoint für den JAX-JIT-Cache.

Nächste Schritte

• Verwenden Sie eine Beispiel-YAML-Datei für Google Kubernetes Engine, um Best Practices für die Optimierung zu konfigurieren.

• Weitere Informationen zu Optionen für die Konfigurationsdatei von Cloud Storage FUSE

• Weitere Informationen zu Cloud Storage FUSE-Befehlszeilenoptionen