Risolvi i problemi relativi a Pathways on Cloud

Anteprima

Questo prodotto o funzionalità è soggetto ai "Termini delle offerte pre-GA" nella sezione Termini di servizio generali dei Termini specifici dei servizi. I prodotti e le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per ulteriori informazioni, consulta le descrizioni delle fasi di lancio.

Prima di iniziare

• XPK installato
• Strumenti Kubernetes installati
• Installazione di gcloud CLI
• Abilitato l'API TPU
• Abilitato l'API Google Kubernetes Engine
• Hai creato un cluster Google Kubernetes Engine

Questo documento spiega come risolvere i problemi relativi ai carichi di lavoro di Pathways.

Visualizzazione dei log

In Esplora log di Cloud Logging, utilizza la seguente query modificata in modo che corrisponda al tuo progetto, alla tua regione, al tuo cluster e al tuo carico di lavoro.

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

Sostituisci quanto segue:

• PROJECT : il tuo ID progetto Google Cloud
• LOCATION: la regione o la zona in cui hai creato il cluster GKE
• CLUSTER : il nome del tuo cluster GKE
• WORKLOAD_NAME : il nome del tuo workload quando utilizzi XPK o il nome JobSet quando utilizzi kubectl

Questa query corrisponderà a più container Kubernetes di Pathways con nomi come pathways-rm, pathways-proxy, pathways-worker. Puoi restringere l'ambito dei contenitori che causano un problema aggiungendo un filtro in base al nome del contenitore, ad esempio resource.labels.container_name:"<container_name>"

Monitoraggio

Monitoraggio dello stato di integrità

Puoi monitorare l'integrità di vari componenti di Pathways cercando voci nei log dei container, ad esempio:

pathways-proxy è pronto a gestire nuove richieste di connessione quando viene scritto il seguente log:

kubectl logs ${HEAD_POD_NAME} --container pathways-proxy
...
I1101 04:51:41.967764       1 proxy_server.cc:125] IFRT proxy server started with status OK

pathways-rm è pronto a gestire nuove richieste di connessione quando viene scritto il seguente log:

kubectl logs $HEAD_POD_NAME --container pathways-rm
...
I1101 04:50:41.967764       1 server_lib.cc:1473] Pathways Server serving on [::]:29001

Per verificare che tutte le TPU registrate in Pathways Resource Manager siano pronte, puoi cercare ***<num slices>/<num slices> Pathways Slices Now Ready *** nei log del container pathways-rm:

kubectl logs $HEAD_POD_NAME --container pathways-rm
...
I1101 04:52:41.967764       1 multi_job_allocator.cc:1063] *** 2/2 Pathways Slices Now Ready ***

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

pathways-worker è pronto a gestire nuove richieste di connessione quando viene scritto il seguente log:

kubectl logs $WORKER_POD_NAME --container pathways-worker
...
I1101 04:50:41.967764       1 server_lib.cc:1473] Pathways Server serving on [::]:29001

Raccolta di metriche

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

• Latenza di trasferimento DCN
• Latenza collettiva
• Latenza di trasferimento da host a dispositivo
• Latenza di trasferimento da dispositivo a host

Puoi trovare le metriche nella dashboard di Cloud Monitoring del progetto {gcp_name} in cui è in esecuzione il cluster GKE.

Per monitorare queste metriche in Metrics Explorer:

1. Vai a Esplora metriche.
2. Filtra in base al nome della metrica utilizzando il campo Seleziona una metrica.
3. Filtra per nome del workload e intervallo di tempo selezionando Aggiungi filtro e filtrando per pod_name.
4. Scegli un tipo di aggregazione appropriato in base alla metrica e ai carichi di lavoro che stai monitorando.

Latenza di trasferimento DCN

Si tratta di una metrica Megascale XLA (MXLA) che misura la distribuzione cumulativa delle latenze di trasferimento di rete per il traffico multislice. La misurazione della latenza inizia quando viene emessa una richiesta di trasferimento dei dati tramite la DCN e termina quando viene ricevuta una conferma che il trasferimento dei dati è stato completato. Per monitorare questa metrica, filtra in base al nome della metrica dcn_transfer_latencies.

Latenza collettiva

Si tratta di una metrica MXLA che misura la distribuzione cumulativa della latenza collettiva end-to-end per il traffico multi-slice. La misurazione della latenza inizia quando viene emessa una richiesta per una raccolta e termina quando viene ricevuta una conferma che il trasferimento dei dati è stato completato. Per monitorare questa metrica, filtra in base al nome della metrica collective_e2e_latency.

Latenza di trasferimento dall'host al dispositivo

Si tratta di una metrica MXLA che misura la distribuzione cumulativa delle latenze di trasferimento da host a dispositivo per il traffico multislice. La misurazione della latenza inizia quando viene emessa una richiesta di trasferimento dei dati tramite la DCN e termina quando viene ricevuta una conferma che il trasferimento dei dati è stato completato. Per monitorare questa metrica, filtra in base al nome della metrica host_to_device_transfer_latencies.

Latenza di trasferimento da dispositivo a host

Si tratta di una metrica MXLA che misura la distribuzione cumulativa delle latenze di trasferimento da dispositivo a host per il traffico multislice. La misurazione della latenza inizia quando viene emessa una richiesta di trasferimento dei dati tramite la DCN e termina quando viene ricevuta una conferma che il trasferimento dei dati è stato completato. Per monitorare questa metrica, filtra in base al nome della metrica device_to_host_transfer_latencies.

Eseguire il debug degli errori comuni

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

I seguenti messaggi sono solo avvisi e non influiscono sul rendimento del 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 delle autorizzazioni per scrivere voci di log nel sistema di logging Google Cloud .

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, aggiungi il ruolo Scrittore log al account di servizio Compute Engine.

Impossibile connettersi al server proxy IFRT

Se visualizzi questo errore, il client proxy IFRT non è in grado di connettersi al server proxy IFRT.

• Assicurati che la rete VPC sia configurata correttamente
• Assicurati che il firewall sia configurato per consentire la connessione.
• Assicurati che il cluster Pathways sia stato sottoposto al provisioning
• Controllare i messaggi di errore di avvio

Quando viene eseguito il primo comando JAX che invia un comando IFRT al cluster Pathways, smette di rispondere per circa un minuto e poi visualizza 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)

Esiste una connessione al cluster Pathways

Un cluster di percorsi può mantenere una sessione con un solo client alla volta. Se due notebook separati tentano di connettersi allo stesso cluster Pathways, uno riuscirà a connettersi e l'altro mostrerà 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)

Una volta disconnesso il client originale, il secondo client potrà 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 con parola chiave inaspettato "unbound_message"

Se visualizzi questo errore dopo aver importato pathwaysutils, controlla se nel tuo ambiente sono installate versioni obsolete di Flask o Werkzeug:

 pip3 list --outdated (replacing pip with pip3 as needed)

Se Flask o Werkzeug sono elencati, valuta la possibilità di eseguire l'upgrade con l'avvertenza che questa operazione potrebbe interrompere altri pacchetti o dipendenze nel tuo progetto:

 pip install flask Werkzeug --upgrade ()

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. Questo problema può essere risolto riavviando il client. Per i notebook, puoi riavviare il kernel del notebook ed eseguirlo di nuovo.

SIGTERMS e HBM OOM

Un SIGTERM trovato nei log associati a un errore RESOURCE_EXHAUSTED potrebbe indicare un errore HBM OOM. In questo caso, puoi ridurre la quantità di memoria HBM utilizzata nel 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 del criterio del ciclo di vita. In questo caso, pulisci i criteri del ciclo di vita di Cloud Storage che non vengono più utilizzati.

Errore permanente

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

Questo errore viene stampato sui worker di Resource Manager o Pathways quando fornisci una posizione Cloud Storage non valida ai container di percorsi.

Risposta di errore dal daemon

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

Ciò è dovuto a una vecchia versione di Docker, esegui l'upgrade della versione di Docker.

Impossibile raggiungere un accordo tra il client proxy IFRT e il server

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

Ciò indica che viene utilizzata una versione precedente di MaxText. Assicurati di ricompilare l'ultima immagine di MaxText.

Passaggi successivi

• Inferenza multihost con Pathways
• Carichi di lavoro batch con percorsi
• Modalità interattiva di Pathways
• Portare i carichi di lavoro JAX su Pathways
• Formazione resiliente con Pathways