Résoudre les problèmes liés à Pathways on Cloud

Preview

Ce produit ou cette fonctionnalité sont soumis aux "Conditions des offres de pré-DG" de la section "Conditions générales du service" des Conditions spécifiques du service. Les produits et fonctionnalités de pré-DG sont proposés "en l'état" et peuvent avoir une compatibilité limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Avant de commencer

• XPK installé
• Outils Kubernetes installés
• gcloud CLI installé
• Activer l'API TPU
• Activer l'API Google Kubernetes Engine
• Créer un cluster Google Kubernetes Engine

Ce document explique comment résoudre les problèmes liés à vos charges de travail Pathways.

Afficher les journaux

Dans l'explorateur de journaux de Cloud Logging, utilisez la requête suivante, ajustée pour correspondre à votre projet, votre région, votre cluster et votre charge de travail.

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"

Remplacez les éléments suivants :

• PROJECT : ID de votre projet Google Cloud
• LOCATION : région ou zone dans laquelle vous avez créé votre cluster GKE
• CLUSTER : nom de votre cluster GKE
• WORKLOAD_NAME : nom de votre charge de travail lorsque vous utilisez XPK ou nom JobSet lorsque vous utilisez kubectl

Cette requête correspondra à plusieurs conteneurs Kubernetes Pathways avec des noms tels que pathways-rm, pathways-proxy et pathways-worker. Vous pouvez identifier le conteneur à l'origine du problème en ajoutant un filtre sur le nom du conteneur, par exemple resource.labels.container_name:"<container_name>".

Surveillance

Surveillance de l'état

Vous pouvez surveiller l'état de différents composants Pathways en recherchant des entrées dans les journaux de conteneur, par exemple :

pathways-proxy est prêt à traiter les nouvelles demandes de connexion lorsque le journal suivant est écrit :

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 est prêt à traiter les nouvelles demandes de connexion lorsque le journal suivant est écrit :

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

Pour vérifier que tous les TPU enregistrés dans Pathways Resource Manager sont prêts, vous pouvez rechercher ***<num slices>/<num slices> Pathways Slices Now Ready *** dans les journaux de conteneur 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 ***

Le client Pathways peut se connecter au serveur proxy IFRT tant que le serveur proxy est prêt, même si toutes les tranches ne le sont pas. Votre tâche fonctionne avec des tranches virtuelles jusqu'à ce que la tranche soit prête. Les tranches virtuelles permettent à votre code de s'exécuter lorsque les TPU ne sont pas disponibles.

pathways-worker est prêt à traiter les nouvelles demandes de connexion lorsque le journal suivant est écrit :

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

Collecte de métriques

Les pathways peuvent écrire des métriques système de bas niveau dans Cloud Monitoring à des fins de débogage. Ces métriques incluent les éléments suivants :

• Latence de transfert DCN
• Latence collective
• Latence de transfert hôte à appareil
• Latence de transfert d'appareil à hôte

Vous trouverez les métriques dans le tableau de bord Cloud Monitoring du projet {gcp_name} sur lequel le cluster GKE est exécuté.

Pour surveiller ces métriques dans l'explorateur de métriques :

1. Accédez à l'explorateur de métriques.
2. Filtrez par nom de métrique à l'aide du champ Sélectionner une métrique.
3. Filtrez par nom de charge de travail et plage de dates en sélectionnant Ajouter un filtre, puis filtrez par pod_name.
4. Choisissez un type d'agrégation approprié en fonction de la métrique et des charges de travail que vous surveillez.

Latence de transfert DCN

Il s'agit d'une métrique Megascale XLA (MXLA) qui mesure la distribution cumulative des latences de transfert réseau pour le trafic multitranche. La mesure de la latence commence lorsqu'une demande de transfert de données sur le DCN est émise et se termine lorsqu'un accusé de réception est reçu indiquant que le transfert de données est terminé. Pour surveiller cette métrique, filtrez par nom de métrique dcn_transfer_latencies.

Latence collective

Il s'agit d'une métrique MXLA qui mesure la distribution cumulative de la latence collective de bout en bout pour le trafic multitranche. La mesure de la latence commence lorsqu'une demande de collectif est émise et se termine lorsqu'un accusé de réception est reçu indiquant que le transfert de données est terminé. Pour surveiller cette métrique, filtrez par nom de métrique collective_e2e_latency.

Latence de transfert hôte à appareil

Il s'agit d'une métrique MXLA qui mesure la distribution cumulative des latences de transfert hôte à appareil pour le trafic multitranche. La mesure de la latence commence lorsqu'une requête de transfert de données sur le DCN est émise et se termine lorsqu'un accusé de réception est reçu indiquant que le transfert de données est terminé. Pour surveiller cette métrique, filtrez par nom de métrique host_to_device_transfer_latencies.

Latence de transfert d'appareil à hôte

Il s'agit d'une métrique MXLA qui mesure la distribution cumulative des latences de transfert d'appareil à hôte pour le trafic multislice. La mesure de la latence commence lorsqu'une requête de transfert de données sur le DCN est émise et se termine lorsqu'un accusé de réception est reçu indiquant que le transfert de données est terminé. Pour surveiller cette métrique, filtrez par nom de métrique device_to_host_transfer_latencies.

Déboguer les erreurs courantes

Impossible de hacher les avertissements de configuration de l'accélérateur

Les messages suivants ne sont que des avertissements et n'affectent pas les performances de votre code 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'>)

Autorisation logging.logEntries.create refusée pour la ressource

Si l'erreur suivante s'affiche, assurez-vous que le compte de service Compute Engine utilisé par Vertex AI Workbench est autorisé à écrire des entrées de journal dans le système de journalisation 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)."}"
>

Pour résoudre ce problème, ajoutez le rôle Rédacteur de journaux au compte de service Compute Engine.

Impossible de se connecter au serveur proxy IFRT

Si ce message d'erreur s'affiche, cela signifie que votre client proxy IFRT ne parvient pas à se connecter au serveur proxy IFRT.

• Vérifier que votre réseau VPC est correctement configuré
• Assurez-vous que votre pare-feu est configuré pour autoriser la connexion.
• Vérifier que votre cluster Pathways a été provisionné
• Rechercher les messages d'erreur au démarrage

Lorsque votre première commande JAX qui envoie une commande IFRT au cluster Pathways tente de s'exécuter, elle cesse de répondre pendant environ une minute, puis affiche un RuntimeError semblable à ce qui suit :

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)

Une connexion au cluster Pathways existe déjà

Un cluster Pathways ne peut maintenir une session qu'avec un seul client à la fois. Si deux notebooks distincts tentent de se connecter au même cluster Pathways, l'un pourra se connecter, tandis que l'autre affichera les erreurs suivantes.

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)

Une fois le client d'origine déconnecté, le deuxième client pourra se connecter. Après une déconnexion inattendue, vous devrez peut-être redémarrer le cluster Pathways pour permettre à d'autres clients de se connecter.

LocalProxy.init() a reçu un argument de mot clé inattendu 'unbound_message'

Si cette erreur s'affiche après l'importation de pathwaysutils, vérifiez si des versions obsolètes de Flask ou Werkzeug sont installées dans votre environnement :

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

Si Flask ou Werkzeug sont listés, envisagez de les mettre à niveau, en sachant que cela peut casser d'autres packages ou dépendances dans votre projet :

 pip install flask Werkzeug --upgrade ()

Erreur interne du serveur proxy

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

Cette erreur indique que le serveur proxy IFRT s'est déconnecté du client. Pour résoudre ce problème, redémarrez votre client. Pour les notebooks, vous pouvez redémarrer le noyau du notebook et le réexécuter.

SIGTERMS et HBM OOM

Un SIGTERM trouvé dans les journaux associés à une erreur RESOURCE_EXHAUSTED peut indiquer une erreur OOM HBM. Dans ce cas, vous pouvez réduire la quantité de mémoire HBM utilisée dans votre code 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"

Cette erreur se produit si le bucket Cloud Storage transmis à l'indicateur --pathways_gcs_location a atteint la limite maximale de règles de cycle de vie. Si cela se produit, supprimez les règles de cycle de vie Cloud Storage qui ne sont plus utilisées.

Erreur permanente

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

Cette erreur s'affiche sur les nœuds de calcul Resource Manager ou Pathways lorsque vous fournissez un emplacement Cloud Storage non valide aux conteneurs Pathways.

Réponse d'erreur du daemon

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

Cela est dû à une ancienne version de Docker. Mettez à niveau votre version de Docker.

Échec de l'accord entre le client et le serveur proxy IFRT

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

Cela indique qu'une ancienne version de MaxText est utilisée. Veuillez vous assurer de reconstruire la dernière image MaxText.

Étapes suivantes

• Inférence multihôte avec Pathways
• Charges de travail par lot avec Pathways
• Mode interactif des parcours
• Transférer des charges de travail JAX vers Pathways
• Entraînement résilient avec Pathways