Fehlerbehebung bei Pathways on Cloud

Diese Seite hilft ML-Entwicklern und Plattformadministratoren, Probleme mit Pathways-Arbeitslasten in Google Cloudzu diagnostizieren und zu beheben. In diesem Leitfaden erfahren Sie, wie Sie Komponentenlogs prüfen, die Bereitschaft von Clustern und Slices verifizieren, MXLA-Übertragungsmesswerte (Megascale XLA) überwachen und häufige Laufzeitfehler beheben. Wählen Sie in jedem Abschnitt den Tab GKE oder Cluster Director für Ihre Umgebung aus.

Hinweis

Hinweis

GKE

Bevor Sie fortfahren, müssen die folgenden Voraussetzungen erfüllt sein:

Cluster Director

Bevor Sie fortfahren, müssen die folgenden Voraussetzungen erfüllt sein:

Logs ansehen

GKE

Sie können Logs für Ihre Pathways-Arbeitslasten direkt mit dem Befehl gcluster job logs aufrufen. Übergeben Sie --main-only=false, um Logs von Worker-Pods einzuschließen:

gcluster job logs WORKLOAD_NAME \
    --cluster=CLUSTER \
    --project=PROJECT_ID \
    --location=LOCATION \
    --main-only=false

Ersetzen Sie Folgendes:

  • WORKLOAD_NAME: Der Name Ihrer Arbeitslast, wenn Sie das Cluster Toolkit verwenden, oder der JobSet-Name, wenn Sie kubectl verwenden.
  • CLUSTER: Name Ihres GKE-Clusters.
  • PROJECT_ID: IhreGoogle Cloud -Projekt-ID.
  • LOCATION: die Region oder Zone, in der Sie Ihren GKE-Cluster erstellt haben.

Wenn Sie alle Pods für Ihre Arbeitslast mit kubectl auflisten möchten, filtern Sie nach dem JobSet-Namenlabel:

kubectl get pods \
    -l jobset.sigs.k8s.io/jobset-name=WORKLOAD_NAME

Mit dem Befehl gcluster job list können Sie den Arbeitslaststatus prüfen oder fehlgeschlagene Jobs auflisten:

gcluster job list --status Failed \
    --cluster=CLUSTER \
    --project=PROJECT_ID \
    --location=LOCATION

Alternativ können Sie im Log-Explorer von Cloud Logging die folgende Abfrage ausführen, die an Ihr Projekt, Ihren Standort, Ihren Cluster und Ihre Arbeitslast angepasst ist:

resource.type="k8s_container"
resource.labels.project_id="PROJECT_ID"
resource.labels.location="LOCATION"
resource.labels.cluster_name="CLUSTER"
resource.labels.namespace_name="default"
resource.labels.pod_name:"WORKLOAD_NAME"

Diese Abfrage stimmt mit mehreren Pathways-Kubernetes-Containern mit Namen wie pathways-rm, pathways-proxy, pathways-worker und workload-container überein. Wenn Sie herausfinden möchten, welcher Container ein Problem verursacht, fügen Sie einen Container-Namensfilter wie resource.labels.container_name:"CONTAINER_NAME" hinzu, wobei CONTAINER_NAME der Name des Containers ist.

Cluster Director

Die Pathways-Skripts schreiben Logs in das freigegebene Dateisystem:

  • Der Pathways-Dienstjob schreibt pathways-service-SERVICE_JOB_ID.out und pathways-service-SERVICE_JOB_ID.err in das Verzeichnis, in dem Sie sbatch ausgeführt haben, z. B. ~/pathways.
  • Der Pathways-Ressourcenmanager, der IFRT-Proxyserver und die TPU-Worker schreiben in ~/pathways/service_SERVICE_JOB_ID/logs, einschließlich rm.log, proxy.log und einer slice-*.out- und slice-*.err-Datei pro Worker-Aufgabe.
  • Die MaxText-Beispielarbeitslast schreibt ihr Log in maxtext-llama31-JOB_ID.err.

Prüfen Sie auf dem Login-Knoten den Status der Pathways-Jobs und rufen Sie ihre Job-IDs ab:

squeue -u ${USER}

Pathways-Komponenten und -Messwerte überwachen

Die folgenden Abschnitte gelten für Pathways in GKE.

Statusmonitoring

Sie können den Zustand verschiedener Pathways-Komponenten überwachen, indem Sie nach Einträgen in den Containerlogs suchen.

Der pathways-proxy-Container ist bereit, neue Verbindungsanfragen zu verarbeiten, wenn er den folgenden Logeintrag schreibt. Führen Sie den folgenden Befehl aus, um die Logs aufzurufen:

kubectl logs HEAD_POD_NAME --container pathways-proxy

Ersetzen Sie HEAD_POD_NAME durch den Namen des Pathways-Head-Pods.

Die Ausgabe enthält eine Zeile, die etwa so aussieht:

I1101 04:51:41.967764       1 proxy_server.cc:125] IFRT proxy server started with status OK

Der pathways-rm-Container ist bereit, neue Verbindungsanfragen zu verarbeiten, wenn er den folgenden Logeintrag schreibt:

kubectl logs HEAD_POD_NAME --container pathways-rm

Die Ausgabe enthält eine Zeile, die etwa so aussieht:

I1101 04:50:41.967764       1 server_lib.cc:1473] Pathways Server serving on POD_IP:29001

POD_IP ist die IP-Adresse des Pods, die sich ändern kann, wenn der Pod neu gestartet oder neu geplant wird.

Prüfen Sie in den Containerlogs von pathways-rm, ob alle TPU-Slices bereit sind, und suchen Sie nach Pathways Slices Now Ready:

kubectl logs HEAD_POD_NAME --container pathways-rm

Der folgende Logeintrag zeigt beispielsweise, dass 2 von 2 Slices bereit sind:

I1101 04:52:41.967764       1 multi_job_allocator.cc:1063] *** 2/2 Pathways Slices Now Ready ***

Der Pathways-Client kann eine Verbindung zum IFRT-Proxyserver herstellen, sobald der Proxyserver bereit ist, auch wenn nicht alle Slices bereit sind. Ihr Job arbeitet mit virtuellen Slices, bis die TPU-Slices bereit sind. Mit virtuellen Slices kann Ihr Code ausgeführt werden, wenn TPUs nicht verfügbar sind.

Prüfen Sie die Logs, um festzustellen, ob ein pathways-worker-Container bereit ist:

kubectl logs WORKER_POD_NAME --container pathways-worker

Ersetzen Sie WORKER_POD_NAME durch den Namen eines Pathways-Worker-Pods.

Wenn der Worker bereit ist, enthält die Ausgabe eine Zeile wie die folgende:

I1101 04:50:41.967764       1 server_lib.cc:1473] Pathways Server serving on POD_IP:29005

POD_IP ist die IP-Adresse des Pods, die sich ändern kann, wenn der Pod neu gestartet oder neu geplant wird.

Messwerterfassung

Pathways kann Low-Level-Systemmesswerte zum Debuggen in Cloud Monitoring schreiben. Zu den Messwerten gehören:

  • Übertragungslatenz im Rechenzentrumsnetzwerk (DCN)
  • Gesamtlatenz
  • Host-zu-Gerät-Übertragungslatenz
  • Übertragungslatenz von Gerät zu Host

Sie finden die Messwerte im Monitoring-Dashboard des ProjektsGoogle Cloud , in dem der GKE-Cluster ausgeführt wird.

So überwachen Sie diese Messwerte im Metrics Explorer:

  1. Wechseln Sie in der Google Cloud Console zur Seite Metrics Explorer.
  2. Filtern Sie im Feld Messwert auswählen nach dem Namen des Messwerts.
  3. Wenn Sie nach dem Namen und dem Zeitraum der Arbeitslast filtern möchten, klicken Sie auf Filter hinzufügen und filtern Sie dann nach pod_name.
  4. Wählen Sie für Aggregation einen Aggregationstyp basierend auf dem Messwert und den Arbeitslasten aus, die Sie überwachen.

DCN-Übertragungslatenz

Dieser Megascale XLA-Messwert (MXLA) misst die kumulative Verteilung der Netzwerkübertragungslatenzen für Multi-Slice-Traffic. Die Latenzmessung beginnt, wenn das System eine Anfrage zur Datenübertragung über das DCN sendet, und endet, wenn es eine Bestätigung erhält, dass die Datenübertragung abgeschlossen ist. Wenn Sie diesen Messwert im Blick behalten möchten, filtern Sie nach dem Messwertnamen dcn_transfer_latencies.

Gesamtlatenz

Dieser MXLA-Messwert erfasst die kumulative Verteilung der End-to-End-Gesamtlatenz für Multi-Slice-Traffic. Die Latenzmessung beginnt, wenn das System eine Anfrage für einen kollektiven Vorgang sendet, und endet, wenn es eine Bestätigung erhält, dass die Datenübertragung abgeschlossen ist. Wenn Sie diesen Messwert im Blick behalten möchten, filtern Sie nach dem Messwertnamen collective_end_to_end_latencies.

Host-zu-Gerät-Übertragungslatenz

Dieser MXLA-Messwert misst die kumulative Verteilung der Host-zu-Gerät-Übertragungslatenzen für Multi-Slice-Traffic. Die Latenzmessung beginnt, wenn das System eine Anfrage zum Übertragen von Daten vom Host an ein TPU-Gerät sendet, und endet, wenn es eine Bestätigung erhält, dass die Datenübertragung abgeschlossen ist. Wenn Sie diesen Messwert im Blick behalten möchten, filtern Sie nach dem Messwertnamen host_to_device_transfer_latencies.

Übertragungslatenz von Gerät zu Host

Dieser MXLA-Messwert misst die kumulative Verteilung der Übertragungslatenzen von Gerät zu Host für Multi-Slice-Traffic. Die Latenzmessung beginnt, wenn das System eine Anfrage zur Übertragung von Daten von einem TPU-Gerät an den Host sendet, und endet, wenn es eine Bestätigung erhält, dass die Datenübertragung abgeschlossen ist. Wenn Sie diesen Messwert im Blick behalten möchten, filtern Sie nach dem Messwertnamen device_to_host_transfer_latencies.

Häufige Fehler beheben

GKE

Warnungen zur Beschleunigerkonfiguration können nicht gehasht werden

Die folgenden Meldungen sind nur Warnungen und wirken sich nicht auf die Leistung Ihres JAX-Codes aus:

INFO:jax._src.cache_key:get (_hash_accelerator_config): unable to hash accelerator config, falling back to hashing devices + platform: UNIMPLEMENTED: GetTopologyForDevices is not supported for the IFRT proxy client. (type <class 'jaxlib.xla_extension.XlaRuntimeError'>)

Berechtigung logging.logEntries.create für Ressource verweigert

Wenn der folgende Fehler angezeigt wird, prüfen Sie, ob das von Vertex AI Workbench verwendete Compute Engine-Dienstkonto die Berechtigung hat, Logeinträge in Logging zu schreiben:

INFO:absl:Created 'ArrayHandler' with primary_host=0, replica-id=0
WARNING:absl:pathwaysutils: Detected Pathways-on-Cloud backend. Applying changes.
Failed to submit 1 logs.
Traceback (most recent call last):
  File "/opt/conda/lib/python3.10/site-packages/google/api_core/grpc_helpers.py", line 65, in error_remapped_callable
    return callable_(**args, **kwargs)
  File "/opt/conda/lib/python3.10/site-packages/grpc/_channel.py", line 1181, in __call__
    return _end_unary_response_blocking(state, call, False, None)
  File "/opt/conda/lib/python3.10/site-packages/google/api_core/grpc_helpers.py", line 1006, in _end_unary_response_blocking
    raise _InactiveRpcError(state) # pytype: disable-not-instantiable
grpc._channel._InactiveRpcError: <_InactiveRpcError of RPC that terminated with:
  status = StatusCode.PERMISSION_DENIED
  details = "Permission 'logging.logEntries.create' denied on resource (or it may not exist)."
  debug_error_string = "UNKNOWN:Error received from peer ipv4:216.239.34.174:443 {created_time:"2024-10-03T20:30:44.820425276+00.00", grpc_status:7, grpc_message:"Permission \'logging.logEntries.create\' denied on resource (or it may not exist)."}"
>

Weisen Sie dem Compute Engine-Dienstkonto die Rolle Logautor (roles/logging.logWriter) zu, um dieses Problem zu beheben.

Verbindung zum IFRT-Proxyserver kann nicht hergestellt werden

Wenn der erste JAX-Befehl, der einen IFRT-Befehl an den Pathways-Cluster sendet, ausgeführt wird, reagiert er möglicherweise etwa eine Minute lang nicht mehr und zeigt dann einen RuntimeError ähnlich dem folgenden an:

RuntimeError: Unable to initialize backend 'proxy': UNAVAILABLE: Unable to establish connection to ifrt_proxy server, please check provided address example-workload-proxy-0-0.example-workload.default.svc.example-cluster-domain.:38676'; detailed error: DNS resolution failed (set JAX_PLATFORMS='' to automatically choose an available backend)

Wenn dieser Fehler angezeigt wird, kann Ihr IFRT-Proxy-Client keine Verbindung zum IFRT-Proxy-Server herstellen. Prüfen Sie Folgendes:

  • Prüfen Sie, ob Sie Ihr VPC-Netzwerk (Virtual Private Cloud) richtig konfiguriert haben.
  • Prüfen Sie, ob Ihre Firewallregeln die Verbindung zulassen.
  • Prüfen Sie, ob Ihr Pathways-Cluster bereitgestellt wurde.
  • Suchen Sie in den Containerlogs nach Fehlermeldungen beim Start.

ALTS-Handshake fehlgeschlagen oder Socket beim Herstellen einer Verbindung zum IFRT-Proxyserver geschlossen

Möglicherweise wird Alts handshake failed (TSI_INTERNAL_ERROR) oder UNAVAILABLE: Unable to establish connection to ifrt_proxy server ... Socket closed angezeigt, wenn Sie ein benutzerdefiniertes Manifest ohne das Feld hostNetwork: true in einem Knotenpool der Workload Identity Federation for GKE ausführen. Um dieses Problem zu beheben, legen Sie die Umgebungsvariable IFRT_PROXY_USE_INSECURE_GRPC_CREDENTIALS: "true" sowohl für den pathways-proxy-Container als auch für den JAX-Client-Container fest (beide Seiten müssen übereinstimmen). Wenn Sie diese Umgebungsvariable hinzufügen, wird ALTS deaktiviert und stattdessen unsicheres gRPC verwendet. Verwenden Sie sie daher nur innerhalb eines vertrauenswürdigen Clusternetzwerks.

Es besteht eine Verbindung zum Pathways-Cluster

Ein Pathways-Cluster kann jeweils nur eine Sitzung mit einem Client aufrechterhalten. Wenn zwei separate Notebooks versuchen, eine Verbindung zum selben Pathways-Cluster herzustellen, wird eine Verbindung hergestellt und das andere zeigt die folgenden Fehler an:

INFO:absl:Created ArrayHandler with primary_host=0, replica_id=0
WARNING:absl:pathwaysutils: Detected Pathways-on-Cloud backend. Applying changes.
E0927 21:19:52.919607   37624 rpc_helper.cc:56] Connection to IFRT proxy server was terminated: CANCELLED: Cancelled
E0927 21:20:03.467547   37719 rpc_helper.cc:56] Connection to IFRT proxy server was terminated: CANCELLED: Cancelled
E0927 21:20:14.011645   37807 rpc_helper.cc:56] Connection to IFRT proxy server was terminated: CANCELLED: Cancelled
E0927 21:20:24.557955   37924 rpc_helper.cc:56] Connection to IFRT proxy server was terminated: CANCELLED: Cancelled
---------------------------------------------------------------------------
XlaRuntimeError                           Traceback (most recent call last)
File /opt/conda/lib/python3.10/site-packages/jax/_src/xla_bridge.py:887, in backends()
    885   continue
--> 887 backend = _init_backend(platform)
    888 _backends[platform] = backend

File /opt/conda/lib/python3.10/site-packages/jax/_src/xla_bridge.py:973, in _init_backend(platform)
    972 logger.debug("Initializing backend '%s'", platform)
--> 973 backend = registration.factory()
    974 # TODO: consider raising more descriptive errors directly from backend
    975 # factories instead of returning None.

File /opt/conda/lib/python3.10/site-packages/pathwaysutils/proxy_backend.py:24, in register_backend_factory.<locals>.<lambda>()
     21 def register_backend_factory():
     22   xla_bridge.register_backend_factory(
     23       "proxy",
---> 24       lambda: ifrt_proxy.get_client(
     25           jax.config.read("jax_backend_target"),
     26           ifrt_proxy.ClientConnectionOptions(),
     27       ),
     28       priority=-1,
     29   )

XlaRuntimeError: UNAVAILABLE: Unable to establish connection to ifrt_proxy server, please check provided address example-workload-proxy-0-0.example-workload.default.svc.example-cluster-domain.:38676'; detailed error: Connection to IFRT proxy server was terminated: CANCELLED: Cancelled

During handling of the above exception, another exception occurred:

RuntimeError                              Traceback (most recent call last)
Cell In[2], line 4
      1 import pathwaysutils
      3 import jax
----> 4 print(jax.devices())

File /opt/conda/lib/python3.10/site-packages/jax/_src/xla_bridge.py:1085, in devices(backend)
   1060 def devices(
   1061     backend: str | xla_client.Client | None = None
   1062 ) -> list[xla_client.Device]:
   1063   """Returns a list of all devices for a given backend.
   1064
   1065   .. currentmodule:: jaxlib.xla_extension
   (...)
   1083     List of Device subclasses.
   1084   """
-> 1085   return get_backend(backend).devices()

File /opt/conda/lib/python3.10/site-packages/jax/_src/xla_bridge.py:1019, in get_backend(platform)
   1015 @lru_cache(maxsize=None)  # don't use util.memoize because there is no X64 dependence.
   1016 def get_backend(
   1017     platform: None | str | xla_client.Client = None
   1018 ) -> xla_client.Client:
-> 1019   return _get_backend_uncached(platform)

File /opt/conda/lib/python3.10/site-packages/jax/_src/xla_bridge.py:998, in _get_backend_uncached(platform)
    994   return platform
    996 platform = (platform or _XLA_BACKEND.value or _PLATFORM_NAME.value or None)
--> 998 bs = backends()
    999 if platform is not None:
   1000   platform = canonicalize_platform(platform)

File /opt/conda/lib/python3.10/site-packages/jax/_src/xla_bridge.py:903, in backends()
    901       else:
    902         err_msg += " (you may need to uninstall the failing plugin package, or set JAX_PLATFORMS=cpu to skip this backend.)"
--> 903       raise RuntimeError(err_msg)
    905 assert _default_backend is not None
    906 if not config.jax_platforms.value:

RuntimeError: Unable to initialize backend 'proxy': UNAVAILABLE: Unable to establish connection to ifrt_proxy server, please check provided address 'example-workload-proxy-0-0.example-workload.default.svc.example-cluster-domain.:38676'; detailed error: Connection to IFRT proxy server was terminated: CANCELLED: Cancelled (set JAX_PLATFORMS='' to automatically choose an available backend)

Nachdem die Verbindung zum ursprünglichen Client getrennt wurde, kann der zweite Client eine Verbindung herstellen. Nach einer unerwarteten Trennung der Verbindung müssen Sie den Pathways-Cluster möglicherweise neu starten, damit andere Clients eine Verbindung herstellen können.

LocalProxy.__init__() hat ein unerwartetes Schlüsselwortargument erhalten 'unbound_message'

Wenn nach dem Importieren von pathwaysutils der folgende Fehler angezeigt wird, prüfen Sie, ob in Ihrer Umgebung veraltete Versionen von Flask oder Werkzeug installiert sind. Ersetzen Sie bei Bedarf pip3 durch pip:

pip3 list --outdated

Wenn Flask oder Werkzeug aufgeführt ist, aktualisieren Sie die Pakete. Beachten Sie, dass sich das Upgrade auf andere Pakete oder Abhängigkeiten in Ihrem Projekt auswirken kann:

pip3 install --upgrade flask Werkzeug

Interner Fehler vom Proxyserver

"Internal error from proxy server during Array::IsDeleted(): UNAVAILABLE:Connection to IFRT proxy server was terminated: FAILED_PRECONDITION:
GrpcClientSession: writes no longer allowed."

Dieser Fehler gibt an, dass die Verbindung zwischen dem IFRT-Proxyserver und dem Client getrennt wurde. Starten Sie den Client neu, um das Problem zu beheben. Starten Sie bei Notebooks den Notebook-Kernel neu und führen Sie das Notebook noch einmal aus.

SIGTERM und HBM-OOM

Ein SIGTERM-Eintrag in den Logs, der mit einem RESOURCE_EXHAUSTED-Fehler verknüpft ist, kann auf einen OOM-Fehler (Out-of-Memory) im High-Bandwidth Memory (HBM) hinweisen. Reduzieren Sie in diesem Fall die Menge an HBM, die Ihr JAX-Code verwendet.

INVALID_ARGUMENT

"INVALID_ARGUMENT : Permanent error, with a last message of Lifecycle
matches_prefix cannot specify more than 50 prefixes per config.; Error while
initializing persistent cache storage Cloud Storage"

Dieser Fehler tritt auf, wenn der Cloud Storage-Bucket, der an das Flag --pathways-gcs-location übergeben wurde, das maximale Limit für Lebenszyklusrichtlinien (50 Präfixe) erreicht hat. Löschen Sie nicht mehr verwendete Cloud Storage-Lebenszyklusrichtlinien, um dieses Problem zu beheben.

Dauerhafter Fehler

Permanent error, with a last message of The specified bucket does not exist.; Error while initializing persistent cache storage gcs

Der Pathways-Ressourcenmanager oder die Pathways-Worker geben diesen Fehler aus, wenn Sie einen ungültigen Cloud Storage-Speicherort für Pathways-Container angeben.

Error response from daemon

Error response from daemon: dockerfile parse error line 16: Unknown flag: exclude

Dieser Fehler tritt auf, wenn Sie eine ältere Version von Docker verwenden. Führen Sie ein Upgrade Ihrer Docker-Version durch.

IFRT-Proxy-Client und -Server konnten sich nicht einigen

IFRT Proxy client and server failed to agree on the protocol version; supported versions: client = [1, 1], server = [3, 14]

Dieser Fehler weist darauf hin, dass Sie eine ältere Version von MaxText verwenden. Erstellen Sie das neueste MaxText-Image neu.

Cluster Director

setup_env.sh schlägt mit einem Enroot-mktemp-Fehler fehl

Wenn setup_env.sh mit dem folgenden Fehler fehlschlägt, ist das temporäre Verzeichnis von Enroot nicht vorhanden:

mktemp: failed to create directory via template '/tmp/UID/tmp/enroot...'

Führen Sie mkdir -p /tmp/$(id -u)/tmp aus und führen Sie das Skript dann noch einmal aus, um dieses Problem zu beheben.

setup_env.sh kann die Pathways-Images nicht abrufen

Wenn setup_env.sh mit Couldn't pull ... fehlschlägt, ist kein Pathways-Image für die angeforderte JAX_VERSION getaggt. Verwenden Sie eine unterstützte JAX-Version.

Der Cluster hat keine cpu-Partition

Wenn sinfo keine cpu-Partition anzeigt, fehlt in der Clusterdefinition das CPU-Knotenset oder die Partition hat einen anderen Namen. Die Pathways-Skripts senden Jobs an eine Partition mit dem Namen cpu. Aktualisieren Sie zur Behebung dieses Problems Ihren Cluster-Blueprint, um eine CPU-Partition mit dem Namen cpu zu definieren, und stellen Sie den Cluster neu bereit. Alternativ können Sie den Partitionsnamen in Ihren Pathways-Jobskripts so aktualisieren, dass er mit der von sinfo angezeigten CPU-Partition übereinstimmt.

TPU-Knoten werden nicht angezeigt

Prüfen Sie, ob sich die Reservierung in der Zone des Clusters befindet und genügend ct6e-standard-4t-VMs hat und ob staticNodeCount und acceleratorTopology übereinstimmen.

Der Pathways-Dienst wird mit Invalid partition name specified beendet

Die Variable PARTITION ist falsch. Wählen Sie eine TPU-Partition aus der Ausgabe von sinfo aus.

Der Pathways-Dienst wird nicht bereit

Wenn das Dienstprotokoll bei Waiting for at least MIN_SLICES=... bleibt, werden nicht genügend Slices ausgeführt. In der Spalte NODELIST(REASON) des folgenden Befehls wird der Grund angezeigt, z. B. keine verfügbare Kapazität oder ein SLICE_SHAPE-Wert, der nicht mit dem TPU-Knotensatz übereinstimmt:

squeue -u ${USER} -n pw-slice

Der Pathways-Ressourcenmanager oder der IFRT-Proxyserver startet nicht

Wenn der Dienst mit Timed out waiting for Pathways Resource Manager oder Timed out waiting for Pathways IFRT Proxy Server fehlschlägt, wurde ein Pathways-Container nicht gestartet. Prüfen Sie rm.log und proxy.log im Logverzeichnis.

Der Pathways-Dienst wird unerwartet beendet

Wenn der Dienst mit The Pathways Resource Manager or IFRT proxy exited beendet wird, ist einer der Worker abgestürzt und der Dienst hat seine Worker beendet. Prüfen Sie rm.log und proxy.log im Logverzeichnis und starten Sie den Dienst dann neu.

Ein TPU-Knoten befindet sich in einem fehlerhaften Zustand

Führen Sie den folgenden Befehl auf dem Login-Knoten aus, um den Knoten wiederherzustellen:

sudo scontrol update nodename=NODE \
    state=power_down_force

Ersetzen Sie NODE durch den Namen des Knotens, wie von sinfo angezeigt.

MaxText kann keinen laufenden Pathways-Dienst finden

Wenn MaxText mit No running Pathways service after 60 minutes fehlschlägt, wird der Dienst nicht ausgeführt oder ist noch nicht bereit. Prüfen Sie das Dienstprotokoll. Wenn Sie länger warten möchten, legen Sie SERVICE_WAIT_MINUTES fest, wenn Sie run_maxtext.sh senden.

MaxText schlägt mit RESOURCE_EXHAUSTED fehl

Das Modell passt nicht in den TPU-Arbeitsspeicher. Verwenden Sie 2x4- oder 4x4-Slices oder legen Sie REDUCED_LAYERS=1 fest.

Der MaxText-Job bleibt ausstehend

Der CPU-Knoten hat nicht die 8 CPUs und 96 GB Arbeitsspeicher, die run_maxtext.sh zusätzlich zu dem, was der Pathways-Dienst verwendet, anfordert. Erhöhen Sie die CPU- und Arbeitsspeicherkapazität (oder die Anzahl der Knoten) in Ihrer cpu-Partition oder reduzieren Sie die Ressourcenanfrage in run_maxtext.sh, um dieses Problem zu beheben.

Verbindung zum IFRT-Proxyserver kann nicht hergestellt werden

Wenn der Client nicht mehr reagiert oder mit UNAVAILABLE fehlschlägt, kann er den Proxyserver nicht erreichen:

  • Prüfen Sie, ob im Dienstprotokoll READY angezeigt wird.
  • Prüfen Sie, ob JAX_BACKEND_TARGET mit der Adresse in ~/pathways/cluster.env übereinstimmt.
  • Wenn Sie die Portweiterleitung verwenden, prüfen Sie, ob der SSH-Tunnel noch ausgeführt wird.

  • Wenn der Client auf einer VM ausgeführt wird, prüfen Sie, ob sich die VM im Subnetz des Clusters befindet. Der folgende Befehl sollte erfolgreich sein:

    nc -zv PROXY_IP 29000

    Ersetzen Sie PROXY_IP durch die IFRT-Proxy-IP-Adresse aus dem Dienstprotokoll.

jax.devices() listet CPU-Geräte anstelle von TPU-Geräten auf

Sie haben die Umgebungsvariablen JAX_PLATFORMS und JAX_BACKEND_TARGET festgelegt, nachdem Sie jax importiert haben. Starten Sie den Notebook-Kernel neu und legen Sie die Variablen fest, bevor Sie jax importieren.

Fehler direkt nach dem Herstellen einer Verbindung zum IFRT-Proxyserver

Die jax- oder pathwaysutils-Version des Clients stimmt nicht mit dem Pathways-Server überein. Installieren Sie die Versionen in ~/pathways/venv.

Eine Berechnung schlägt mit DATA_LOSS und PlacementDataLoss fehl

Für die Berechnung wurde ein Gerät auf einem Slice verwendet, das nicht ausgeführt wird. Prüfen Sie, ob MIN_SLICES gleich MAX_SLICES ist und ob jede Worker-Aufgabe ausgeführt wird:

squeue -u ${USER} -n pw-slice

Eine Berechnung schlägt nach einem vorzeitigen Beenden einer Spot-VM fehl

Berechnungen, die die Geräte des vorzeitig beendeten Slice verwenden, schlagen fehl. Wenn Sie sich automatisch von Spot-Preemptions erholen möchten, konfigurieren Sie Checkpointing und die elastische Slice-Skalierung wie unter Ausfallsicheres Training mit Pathways beschrieben.

Nächste Schritte