Risolvi i problemi di Pathways on Cloud

Questa pagina aiuta gli ingegneri di machine learning (ML) e gli amministratori della piattaforma a diagnosticare e risolvere i problemi relativi ai workload Pathways su Google Cloud. Utilizza questa guida per ispezionare i log dei componenti, verificare l'idoneità di cluster e sezioni, monitorare le metriche di trasferimento di Megascale XLA (MXLA) e correggere gli errori di runtime comuni. In ogni sezione, seleziona la scheda GKE o Cluster Director per il tuo ambiente.

Prima di iniziare

Prima di iniziare

GKE

Prima di procedere, completa i seguenti prerequisiti:

Cluster Director

Prima di procedere, completa i seguenti prerequisiti:

Visualizza i log

GKE

Puoi visualizzare i log dei workload Pathways direttamente utilizzando il comando gcluster job logs (passa --main-only=false per includere i log dei pod worker):

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

Sostituisci quanto segue:

  • WORKLOAD_NAME: il nome del tuo workload quando utilizzi Cluster Toolkit o il nome del JobSet quando utilizzi kubectl.
  • CLUSTER: il nome del tuo cluster GKE.
  • PROJECT_ID: il tuo ID progettoGoogle Cloud .
  • LOCATION: la regione o la zona in cui hai creato il cluster GKE.

Per elencare tutti i pod del tuo workload utilizzando kubectl, filtra in base all'etichetta del nome del JobSet:

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

Per controllare lo stato del workload o elencare i job non riusciti, utilizza il comando gcluster job list:

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

In alternativa, in Esplora log di Cloud Logging, esegui la seguente query modificata per il tuo progetto, la tua località, il tuo cluster e il tuo workload:

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"

Questa query corrisponde a più container Kubernetes Pathways con nomi come pathways-rm, pathways-proxy, pathways-worker e workload-container. Per determinare quale container sta causando un problema, aggiungi un filtro per il nome del container, ad esempio resource.labels.container_name:"CONTAINER_NAME", dove CONTAINER_NAME è il nome del container.

Cluster Director

Gli script Pathways scrivono i log nel file system condiviso:

  • Il job del servizio Pathways scrive pathways-service-SERVICE_JOB_ID.out e pathways-service-SERVICE_JOB_ID.err nella directory in cui hai eseguito sbatch, ad esempio ~/pathways.
  • Il gestore delle risorse Pathways, il server proxy IFRT e i worker TPU scrivono in ~/pathways/service_SERVICE_JOB_ID/logs, inclusi rm.log, proxy.log e un file slice-*.out e slice-*.err per attività worker.
  • Il workload MaxText di esempio scrive il log in maxtext-llama31-JOB_ID.err.

Sul nodo di accesso, controlla lo stato dei job Pathways e trova i relativi ID job:

squeue -u ${USER}

Monitora i componenti e le metriche di Pathways

Le sezioni seguenti si applicano a Pathways su GKE.

Monitoraggio dello stato di integrità

Puoi monitorare l'integrità dei vari componenti di Pathways cercando le voci nei log dei container.

Il container pathways-proxy è pronto per gestire nuove richieste di connessione quando scrive la seguente voce di log. Per visualizzare i log, esegui questo comando:

kubectl logs HEAD_POD_NAME --container pathways-proxy

Sostituisci HEAD_POD_NAME con il nome del pod head di Pathways.

L'output include una riga simile alla seguente:

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

Il container pathways-rm è pronto per gestire nuove richieste di connessione quando scrive la seguente voce di log:

kubectl logs HEAD_POD_NAME --container pathways-rm

L'output include una riga simile alla seguente:

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

POD_IP è l'indirizzo IP del pod, che può cambiare quando il pod viene riavviato o ripianificato.

Per verificare che tutte le sezioni TPU siano pronte, controlla i log del container pathways-rm per Pathways Slices Now Ready:

kubectl logs HEAD_POD_NAME --container pathways-rm

Ad esempio, la seguente voce di log mostra che 2 sezioni su 2 sono pronte:

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

Il client Pathways può connettersi al server proxy IFRT non appena il server proxy è pronto, anche se non tutti gli slice sono pronti. Il job funziona con slice virtuali finché le slice TPU non sono pronte. Le sezioni virtuali consentono l'esecuzione del codice quando le TPU non sono disponibili.

Per verificare che un container pathways-worker sia pronto, controlla i relativi log:

kubectl logs WORKER_POD_NAME --container pathways-worker

Sostituisci WORKER_POD_NAME con il nome di un pod worker Pathways.

Quando il worker è pronto, l'output include una riga simile alla seguente:

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

POD_IP è l'indirizzo IP del pod, che può cambiare quando il pod viene riavviato o ripianificato.

Raccolta di metriche

Pathways può scrivere metriche di sistema di basso livello in Cloud Monitoring per il debug. Le metriche includono:

  • Latenza di trasferimento della rete del data center (DCN)
  • Latenza collettiva
  • Latenza di trasferimento da host a dispositivo
  • Latenza di trasferimento da dispositivo a host

Puoi trovare le metriche nella dashboard di Monitoring del progettoGoogle Cloud in cui è in esecuzione il cluster GKE.

Per monitorare queste metriche in Metrics Explorer, segui questi passaggi:

  1. Nella console Google Cloud , vai alla pagina Esplora metriche.
  2. Nel campo Seleziona una metrica, filtra in base al nome della metrica.
  3. Per filtrare in base al nome del workload e all'intervallo di tempo, fai clic su Aggiungi filtro, quindi filtra in base a pod_name.
  4. Per Aggregazione, scegli un tipo di aggregazione in base alla metrica e ai workload che stai monitorando.

Latenza di trasferimento DCN

Questa metrica Megascale XLA (MXLA) misura la distribuzione cumulativa delle latenze di trasferimento di rete per il traffico multislice. La misurazione della latenza inizia quando il sistema invia una richiesta di trasferimento dei dati tramite la DCN e termina quando riceve una conferma del completamento del trasferimento dei dati. Per monitorare questa metrica, filtra in base al nome della metrica dcn_transfer_latencies.

Latenza collettiva

Questa metrica MXLA misura la distribuzione cumulativa della latenza collettiva end-to-end per il traffico multislice. La misurazione della latenza inizia quando il sistema invia una richiesta per un'operazione collettiva e termina quando riceve una conferma del completamento del trasferimento di dati. Per monitorare questa metrica, filtra in base al nome della metrica collective_end_to_end_latencies.

Latenza di trasferimento da host a dispositivo

Questa metrica MXLA misura la distribuzione cumulativa delle latenze di trasferimento da host a dispositivo per il traffico multislice. La misurazione della latenza inizia quando il sistema invia una richiesta di trasferimento di dati dall'host a un dispositivo TPU e termina quando riceve una conferma del completamento del trasferimento di dati. Per monitorare questa metrica, filtra in base al nome della metrica host_to_device_transfer_latencies.

Latenza di trasferimento da dispositivo a host

Questa metrica MXLA misura la distribuzione cumulativa delle latenze di trasferimento da dispositivo a host per il traffico multislice. La misurazione della latenza inizia quando il sistema invia una richiesta di trasferimento dei dati da un dispositivo TPU all'host e termina quando riceve una conferma del completamento del trasferimento dei dati. Per monitorare questa metrica, filtra in base al nome della metrica device_to_host_transfer_latencies.

Esegui il debug degli errori comuni

GKE

Impossibile eseguire l'hashing degli avvisi di configurazione dell'acceleratore

I seguenti messaggi sono solo avvisi e non influiscono sulle prestazioni del tuo codice JAX:

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'>)

Autorizzazione logging.logEntries.create negata per la risorsa

Se visualizzi il seguente errore, assicurati che il service account Compute Engine utilizzato da Vertex AI Workbench disponga dell'autorizzazione per scrivere voci di log in Logging:

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)."}"
>

Per risolvere il problema, concedi il ruolo Writer log (roles/logging.logWriter) al service account Compute Engine.

Impossibile connettersi al server proxy IFRT

Quando il primo comando JAX che invia un comando IFRT al cluster Pathways tenta di essere eseguito, potrebbe non rispondere per circa un minuto e poi visualizzare un RuntimeError simile al seguente:

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)

Se visualizzi questo errore, il client proxy IFRT non riesce a connettersi al server proxy IFRT. Verifica quanto segue:

  • Verifica di aver configurato correttamente la rete Virtual Private Cloud (VPC).
  • Verifica che le regole firewall consentano la connessione.
  • Verifica che sia stato eseguito il provisioning del cluster Pathways.
  • Controlla se nei log del container sono presenti messaggi di errore di avvio.

Handshake ALTS non riuscito o socket chiuso durante la connessione al server proxy IFRT

Potresti visualizzare Alts handshake failed (TSI_INTERNAL_ERROR) o UNAVAILABLE: Unable to establish connection to ifrt_proxy server ... Socket closed quando esegui un manifest personalizzato senza il campo hostNetwork: true su un pool di nodi di Workload Identity Federation for GKE. Per risolvere il problema, imposta la variabile di ambiente IFRT_PROXY_USE_INSECURE_GRPC_CREDENTIALS: "true" sia sul container pathways-proxy sia sul container client JAX (entrambi i lati devono corrispondere). L'aggiunta di questa variabile di ambiente disattiva ALTS e utilizza gRPC non sicuro, quindi utilizzala solo all'interno di una rete di cluster attendibile.

Esiste una connessione al cluster Pathways

Un cluster Pathways può mantenere una sessione con un solo client alla volta. Se due notebook separati tentano di connettersi allo stesso cluster Pathways, uno si connette e l'altro visualizza i seguenti errori:

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)

Dopo la disconnessione del client originale, il secondo client può connettersi. Dopo una disconnessione imprevista, potrebbe essere necessario riavviare il cluster Pathways per consentire la connessione di altri client.

LocalProxy.__init__() ha ricevuto un argomento di parola chiave imprevisto 'unbound_message'

Se visualizzi il seguente errore dopo aver importato pathwaysutils, controlla se nel tuo ambiente sono installate versioni obsolete di Flask o Werkzeug (sostituisci pip3 con pip, se necessario):

pip3 list --outdated

Se Flask o Werkzeug sono elencati, esegui l'upgrade dei pacchetti (tieni presente che l'upgrade potrebbe influire su altri pacchetti o dipendenze del progetto):

pip3 install --upgrade flask Werkzeug

Errore interno del server proxy

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

Questo errore indica che il server proxy IFRT si è disconnesso dal client. Per risolvere il problema, riavvia il client. Per i notebook, riavvia il kernel del notebook ed esegui di nuovo il notebook.

SIGTERM e OOM HBM

Una voce SIGTERM nei log associata a un errore RESOURCE_EXHAUSTED potrebbe indicare un errore di memoria esaurita (OOM) della memoria a larghezza di banda elevata (HBM). In questo caso, riduci la quantità di HBM utilizzata dal codice JAX.

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"

Questo errore si verifica se il bucket Cloud Storage passato al flag --pathways-gcs-location ha raggiunto il limite massimo della policy del ciclo di vita (50 prefissi). Per risolvere il problema, elimina le policy del ciclo di vita di Cloud Storage che non utilizzi più.

Errore permanente

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

Il gestore delle risorse Pathways o i worker Pathways stampano questo errore quando fornisci una posizione Cloud Storage non valida ai container Pathways.

Error response from daemon

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

Questo errore si verifica quando utilizzi una versione precedente di Docker. Esegui l'upgrade della versione Docker.

Mancato accordo tra client e server proxy IFRT

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

Questo errore indica che stai utilizzando una versione precedente di MaxText. Ricostruisci l'ultima immagine MaxText.

Cluster Director

setup_env.sh non va a buon fine con un errore Enroot mktemp

Se setup_env.sh non va a buon fine con il seguente errore, la directory temporanea di Enroot non esiste:

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

Per risolvere il problema, esegui mkdir -p /tmp/$(id -u)/tmp, quindi esegui di nuovo lo script.

setup_env.sh non può eseguire il pull delle immagini Pathways

Se setup_env.sh non va a buon fine con Couldn't pull ..., non è stato aggiunto un tag a nessuna immagine Pathways per il JAX_VERSION richiesto. Utilizza una versione JAX supportata.

Il cluster non ha una partizione cpu

Se sinfo non mostra una partizione cpu, nella definizione del cluster manca il nodeset della CPU o la partizione ha un nome diverso. Gli script Pathways inviano i job a una partizione denominata cpu. Per risolvere il problema, aggiorna il blueprint del cluster per definire una partizione della CPU denominata cpu e rifai il deployment del cluster oppure aggiorna il nome della partizione negli script dei job Pathways in modo che corrisponda alla partizione della CPU mostrata da sinfo.

I nodi TPU non vengono visualizzati

Verifica che la prenotazione si trovi nella zona del cluster e disponga di un numero sufficiente di VM ct6e-standard-4t e che staticNodeCount e acceleratorTopology corrispondano.

Il servizio Pathways si chiude con Invalid partition name specified

La variabile PARTITION è errata. Scegli una partizione TPU dall'output di sinfo.

Il servizio Pathways non è pronto

Se il log del servizio rimane su Waiting for at least MIN_SLICES=..., non sono in esecuzione sezioni sufficienti. La colonna NODELIST(REASON) del comando seguente mostra il motivo, ad esempio la capacità non disponibile o un valore SLICE_SHAPE che non corrisponde al set di nodi TPU:

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

Il gestore delle risorse Pathways o il server proxy IFRT non si avvia

Se il servizio non va a buon fine con Timed out waiting for Pathways Resource Manager o Timed out waiting for Pathways IFRT Proxy Server, un container Pathways non è stato avviato. Controlla rm.log e proxy.log nella directory dei log.

Il servizio Pathways si interrompe in modo imprevisto

Se il servizio si interrompe con The Pathways Resource Manager or IFRT proxy exited, uno di questi si è arrestato in modo anomalo e il servizio ha interrotto i relativi worker. Controlla rm.log e proxy.log nella directory dei log, quindi avvia di nuovo il servizio.

Un nodo TPU è bloccato in uno stato non valido

Per recuperare il nodo, esegui questo comando sul nodo di accesso:

sudo scontrol update nodename=NODE \
    state=power_down_force

Sostituisci NODE con il nome del nodo, come mostrato da sinfo.

MaxText non riesce a trovare un servizio Pathways in esecuzione

Se MaxText non va a buon fine con No running Pathways service after 60 minutes, il servizio non è in esecuzione o non è ancora pronto. Controlla il log del servizio. Per attendere più a lungo, imposta SERVICE_WAIT_MINUTES quando invii run_maxtext.sh.

MaxText non va a buon fine con RESOURCE_EXHAUSTED

Il modello non rientra nella memoria della TPU. Utilizza sezioni 2x4 o 4x4 oppure imposta REDUCED_LAYERS=1.

Il job MaxText rimane in attesa

Il nodo CPU non dispone delle 8 CPU e dei 96 GB di memoria richiesti da run_maxtext.sh, oltre a ciò che viene utilizzato dal servizio Pathways. Per risolvere il problema, aumenta la capacità della CPU e della memoria (o il numero di nodi) nella partizione cpu oppure riduci la richiesta di risorse in run_maxtext.sh.

Impossibile connettersi al server proxy IFRT

Se il client smette di rispondere o non va a buon fine con UNAVAILABLE, non può raggiungere il server proxy:

  • Verifica che il log del servizio mostri READY.
  • Verifica che JAX_BACKEND_TARGET corrisponda all'indirizzo in ~/pathways/cluster.env.
  • Se utilizzi il port forwarding, verifica che il tunnel SSH sia ancora in esecuzione.

  • Se il client viene eseguito su una VM, verifica che la VM si trovi nella subnet del cluster. Il seguente comando dovrebbe riuscire:

    nc -zv PROXY_IP 29000

    Sostituisci PROXY_IP con l'indirizzo IP del proxy IFRT dal log del servizio.

jax.devices() elenca i dispositivi CPU anziché i dispositivi TPU

Hai impostato le variabili di ambiente JAX_PLATFORMS e JAX_BACKEND_TARGET dopo aver importato jax. Riavvia il kernel del notebook e imposta le variabili prima di importare jax.

Errori subito dopo la connessione al server proxy IFRT

La versione jax o pathwaysutils del client non corrisponde a quella del server Pathways. Installa le versioni in ~/pathways/venv.

Un calcolo non va a buon fine con DATA_LOSS e PlacementDataLoss

Il calcolo ha utilizzato un dispositivo su uno slice non in esecuzione. Verifica che MIN_SLICES sia uguale a MAX_SLICES e che ogni attività worker sia in esecuzione:

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

Un calcolo non va a buon fine dopo un prerilascio di Spot

I calcoli che utilizzano i dispositivi dello slice prerilasciato non vanno a buon fine. Per recuperare automaticamente dalle prerilasci di Spot, configura il checkpoint e la scalabilità delle sezioni elastiche come descritto in Addestramento resiliente con Pathways.

Passaggi successivi