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

Cette page aide les ingénieurs en machine learning (ML) et les administrateurs de plate-forme à diagnostiquer et à résoudre les problèmes liés aux charges de travail Pathways sur Google Cloud. Utilisez ce guide pour inspecter les journaux des composants, vérifier l'aptitude des clusters et des tranches, surveiller les métriques de transfert Megascale XLA (MXLA) et corriger les erreurs d'exécution courantes. Dans chaque section, sélectionnez l'onglet GKE ou Cluster Director pour votre environnement.

Avant de commencer

Avant de commencer

GKE

Avant de continuer, assurez-vous de remplir les conditions préalables suivantes :

Cluster Director

Avant de continuer, assurez-vous de remplir les conditions préalables suivantes :

Afficher les journaux

GKE

Vous pouvez afficher les journaux de vos charges de travail Pathways directement à l'aide de la commande gcluster job logs (transmettez --main-only=false pour inclure les journaux des pods de nœuds de calcul) :

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

Remplacez les éléments suivants :

  • WORKLOAD_NAME : nom de votre charge de travail lorsque vous utilisez Cluster Toolkit, ou nom du JobSet lorsque vous utilisez kubectl.
  • CLUSTER : nom de votre cluster GKE.
  • PROJECT_ID : ID de votre projetGoogle Cloud .
  • LOCATION : région ou zone dans laquelle vous avez créé votre cluster GKE.

Pour lister tous les pods de votre charge de travail à l'aide de kubectl, filtrez par l'étiquette de nom JobSet :

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

Pour vérifier l'état de la charge de travail ou lister les jobs ayant échoué, utilisez la commande gcluster job list :

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

Vous pouvez également exécuter la requête suivante dans l'explorateur de journaux de Cloud Logging, en l'adaptant à votre projet, votre emplacement, votre cluster et votre charge de travail :

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"

Cette requête correspond à plusieurs conteneurs Kubernetes Pathways portant des noms tels que pathways-rm, pathways-proxy, pathways-worker et workload-container. Pour déterminer quel conteneur est à l'origine d'un problème, ajoutez un filtre de nom de conteneur tel que resource.labels.container_name:"CONTAINER_NAME", où CONTAINER_NAME est le nom du conteneur.

Cluster Director

Les scripts Pathways écrivent des journaux dans le système de fichiers partagé :

  • Le job du service Pathways écrit pathways-service-SERVICE_JOB_ID.out et pathways-service-SERVICE_JOB_ID.err dans le répertoire où vous avez exécuté sbatch, par exemple ~/pathways.
  • Le gestionnaire de ressources Pathways, le serveur proxy IFRT et les nœuds de calcul TPU écrivent dans ~/pathways/service_SERVICE_JOB_ID/logs, y compris rm.log, proxy.log, et un fichier slice-*.out et slice-*.err par tâche de nœud de calcul.
  • L'exemple de charge de travail MaxText écrit son journal dans maxtext-llama31-JOB_ID.err.

Sur le nœud de connexion, vérifiez l'état des jobs Pathways et recherchez leurs ID :

squeue -u ${USER}

Surveiller les composants et les métriques Pathways

Les sections suivantes s'appliquent à Pathways sur GKE.

Surveillance d'état

Vous pouvez surveiller l'état de divers composants Pathways en recherchant des entrées dans les journaux de conteneurs.

Le conteneur pathways-proxy est prêt à diffuser de nouvelles requêtes de connexion lorsqu'il écrit l'entrée de journal suivante. Pour afficher les journaux, exécutez la commande suivante :

kubectl logs HEAD_POD_NAME --container pathways-proxy

Remplacez HEAD_POD_NAME par le nom du pod principal Pathways.

Le résultat inclut une ligne semblable à celle-ci :

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

Le conteneur pathways-rm est prêt à diffuser de nouvelles requêtes de connexion lorsqu'il écrit l'entrée de journal suivante :

kubectl logs HEAD_POD_NAME --container pathways-rm

Le résultat inclut une ligne semblable à celle-ci :

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

POD_IP est l'adresse IP du pod, qui peut changer lorsque le pod redémarre ou est replanifié.

Pour vérifier que toutes les tranches de TPU sont prêtes, recherchez Pathways Slices Now Ready dans les journaux du conteneur pathways-rm :

kubectl logs HEAD_POD_NAME --container pathways-rm

Par exemple, l'entrée de journal suivante indique que deux tranches sur deux sont prêtes :

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 dès que le serveur proxy est prêt, même si toutes les tranches ne sont pas prêtes. Votre job fonctionne avec des tranches virtuelles jusqu'à ce que les tranches de TPU soient prêtes. Les tranches virtuelles permettent à votre code de s'exécuter lorsque les TPU ne sont pas disponibles.

Pour vérifier qu'un conteneur pathways-worker est prêt, consultez ses journaux :

kubectl logs WORKER_POD_NAME --container pathways-worker

Remplacez WORKER_POD_NAME par le nom d'un pod de nœud de calcul Pathways.

Une fois le nœud de calcul prêt, le résultat inclut une ligne semblable à celle-ci :

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

POD_IP est l'adresse IP du pod, qui peut changer lorsque le pod redémarre ou est replanifié.

Collecte de métriques

Pathways peut écrire des métriques système de bas niveau dans Cloud Monitoring pour le débogage. Les métriques incluent les éléments suivants :

  • Latence de transfert du réseau de centre de données (DCN)
  • Latence collective
  • Latence de transfert hôte à appareil
  • Latence de transfert d'appareil à hôte

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

Pour surveiller ces métriques dans l'explorateur de métriques, procédez comme suit :

  1. Dans la console Google Cloud , accédez à la page Explorateur de métriques.
  2. Dans le champ Sélectionner une métrique, filtrez par nom de métrique.
  3. Pour filtrer par nom de charge de travail et par période, cliquez sur Ajouter un filtre, puis filtrez par pod_name.
  4. Pour Agrégation, choisissez un type d'agrégation en fonction de la métrique et des charges de travail que vous surveillez.

Latence de transfert DCN

Cette métrique Megascale XLA (MXLA) mesure la distribution cumulative des latences de transfert réseau pour le trafic multislice. La mesure de la latence commence lorsque le système émet une requête de transfert de données sur le DCN et se termine lorsqu'il reçoit un accusé de réception indiquant que le transfert de données est terminé. Pour surveiller cette métrique, filtrez par le nom de métrique dcn_transfer_latencies.

Latence collective

Cette métrique MXLA mesure la distribution cumulative de la latence collective de bout en bout pour le trafic multislice. La mesure de la latence commence lorsque le système émet une requête pour une opération collective et se termine lorsqu'il reçoit un accusé de réception indiquant que le transfert de données est terminé. Pour surveiller cette métrique, filtrez par le nom de métrique collective_end_to_end_latencies.

Latence de transfert hôte à appareil

Cette métrique MXLA mesure la distribution cumulative des latences de transfert hôte à appareil pour le trafic multitranche. La mesure de la latence commence lorsque le système émet une requête de transfert de données de l'hôte vers un appareil TPU et se termine lorsqu'il reçoit un accusé de réception indiquant que le transfert de données est terminé. Pour surveiller cette métrique, filtrez par le nom de métrique host_to_device_transfer_latencies.

Latence de transfert d'appareil à hôte

Cette métrique MXLA mesure la distribution cumulative des latences de transfert d'appareil à hôte pour le trafic multislice. La mesure de la latence commence lorsque le système émet une requête de transfert de données d'un appareil TPU vers l'hôte et se termine lorsqu'il reçoit un accusé de réception indiquant que le transfert de données est terminé. Pour surveiller cette métrique, filtrez par le nom de métrique device_to_host_transfer_latencies.

Déboguer les erreurs courantes

GKE

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

Pour résoudre ce problème, attribuez le rôle Rédacteur de journaux (roles/logging.logWriter) au compte de service Compute Engine.

Impossible de se connecter au serveur proxy IFRT

Lorsque votre première commande JAX qui envoie une commande IFRT au cluster Pathways tente de s'exécuter, elle peut cesser de répondre pendant environ une minute, puis afficher un RuntimeError semblable à celui-ci :

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)

Si cette erreur s'affiche, cela signifie que votre client proxy IFRT ne peut pas se connecter au serveur proxy IFRT. Vérifiez les éléments suivants :

  • Vérifiez que vous avez correctement configuré votre réseau de cloud privé virtuel (VPC).
  • Vérifiez que vos règles de pare-feu autorisent la connexion.
  • Vérifiez que votre cluster Pathways est provisionné.
  • Recherchez les messages d'erreur de démarrage dans les journaux du conteneur.

Échec du handshake ALTS ou socket fermé lors de la connexion au serveur proxy IFRT

Vous pouvez voir Alts handshake failed (TSI_INTERNAL_ERROR) ou UNAVAILABLE: Unable to establish connection to ifrt_proxy server ... Socket closed lorsque vous exécutez un fichier manifeste personnalisé sans le champ hostNetwork: true sur un pool de nœuds Workload Identity Federation for GKE. Pour résoudre ce problème, définissez la variable d'environnement IFRT_PROXY_USE_INSECURE_GRPC_CREDENTIALS: "true" sur le conteneur pathways-proxy et le conteneur client JAX (les deux côtés doivent correspondre). L'ajout de cette variable d'environnement désactive ALTS et utilise gRPC non sécurisé à la place. Par conséquent, ne l'utilisez que dans un réseau de cluster de confiance.

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 se connecte et l'autre affiche 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 que le client d'origine se déconnecte, le deuxième client peut se connecter. Après une déconnexion inattendue, vous devrez peut-être redémarrer le cluster Pathways pour que d'autres clients puissent se connecter.

LocalProxy.__init__() got an unexpected keyword argument 'unbound_message'

Si l'erreur suivante 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 (remplacez pip3 par pip si nécessaire) :

pip3 list --outdated

Si Flask ou Werkzeug sont listés, mettez à niveau les packages (notez que la mise à niveau peut affecter d'autres packages ou dépendances de votre projet) :

pip3 install --upgrade flask Werkzeug

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, redémarrez le noyau du notebook et réexécutez votre notebook.

SIGTERM et OOM HBM

Une entrée SIGTERM dans les journaux associée à une erreur RESOURCE_EXHAUSTED peut indiquer une erreur de mémoire insuffisante (OOM) de la mémoire à haut débit (HBM). Dans ce cas, réduisez la quantité de mémoire HBM utilisée par 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'option --pathways-gcs-location a atteint la limite maximale de règles de cycle de vie (50 préfixes). Pour résoudre ce problème, supprimez les règles de cycle de vie Cloud Storage que vous n'utilisez plus.

Erreur permanente

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

Le gestionnaire de ressources Pathways ou les nœuds de calcul Pathways affichent cette erreur lorsque vous fournissez un emplacement Cloud Storage non valide aux conteneurs Pathways.

Error response from daemon

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

Cette erreur se produit lorsque vous utilisez une ancienne version de Docker. Mettez à niveau votre version de Docker.

Le client et le serveur proxy IFRT n'ont pas réussi à s'accorder

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

Cette erreur indique que vous utilisez une ancienne version de MaxText. Recompilez la dernière image MaxText.

Cluster Director

setup_env.sh échoue avec une erreur Enroot mktemp

Si setup_env.sh échoue avec l'erreur suivante, le répertoire temporaire d'Enroot n'existe pas :

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

Pour résoudre ce problème, exécutez mkdir -p /tmp/$(id -u)/tmp, puis exécutez à nouveau le script.

setup_env.sh ne peut pas extraire les images Pathways

Si setup_env.sh échoue avec Couldn't pull ..., aucune image Pathways n'est taguée pour le JAX_VERSION demandé. Utilisez une version de JAX compatible.

Le cluster ne comporte aucune partition cpu

Si sinfo n'affiche pas de partition cpu, la définition du cluster ne contient pas l'ensemble de nœuds de processeur ou nomme sa partition différemment. Les scripts Pathways envoient des jobs à une partition nommée cpu. Pour résoudre ce problème, mettez à jour votre plan de cluster afin de définir une partition de processeur nommée cpu et redéployez le cluster, ou mettez à jour le nom de la partition dans vos scripts de job Pathways pour qu'il corresponde à la partition de processeur indiquée par sinfo.

Les nœuds TPU ne s'affichent pas

Vérifiez que la réservation se trouve dans la zone du cluster et qu'elle dispose de suffisamment de VM ct6e-standard-4t, et que staticNodeCount et acceleratorTopology correspondent.

Le service Pathways se ferme avec le code Invalid partition name specified

La variable PARTITION est incorrecte. Choisissez une partition TPU dans le résultat de sinfo.

Le service Pathways n'est pas prêt

Si le journal de service reste à Waiting for at least MIN_SLICES=..., cela signifie qu'un nombre insuffisant de segments sont en cours d'exécution. La colonne NODELIST(REASON) de la commande suivante indique la raison, par exemple l'absence de capacité disponible ou une valeur SLICE_SHAPE qui ne correspond pas au nœud TPU :

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

Le gestionnaire de ressources Pathways ou le serveur proxy IFRT ne démarre pas

Si le service échoue avec Timed out waiting for Pathways Resource Manager ou Timed out waiting for Pathways IFRT Proxy Server, un conteneur Pathways n'a pas démarré. Vérifiez rm.log et proxy.log dans le répertoire des journaux.

Le service Pathways s'arrête de manière inattendue

Si le service s'arrête avec The Pathways Resource Manager or IFRT proxy exited, l'un d'eux a planté et le service a arrêté ses nœuds de calcul. Vérifiez rm.log et proxy.log dans le répertoire de journaux, puis redémarrez le service.

Un nœud TPU est bloqué dans un état incorrect

Pour récupérer le nœud, exécutez la commande suivante sur le nœud de connexion :

sudo scontrol update nodename=NODE \
    state=power_down_force

Remplacez NODE par le nom du nœud, comme indiqué par sinfo.

MaxText ne trouve pas de service Pathways en cours d'exécution

Si MaxText échoue avec No running Pathways service after 60 minutes, cela signifie que le service n'est pas en cours d'exécution ou n'est pas encore prêt. Vérifiez le journal du service. Pour attendre plus longtemps, définissez SERVICE_WAIT_MINUTES lorsque vous envoyez run_maxtext.sh.

MaxText échoue avec RESOURCE_EXHAUSTED

Le modèle ne tient pas dans la mémoire du TPU. Utilisez des tranches 2x4 ou 4x4, ou définissez REDUCED_LAYERS=1.

Le job MaxText reste en attente

Le nœud CPU ne dispose pas des 8 processeurs et des 96 Go de mémoire demandés par run_maxtext.sh, en plus de ce qu'utilise le service Pathways. Pour résoudre ce problème, augmentez la capacité du processeur et de la mémoire (ou le nombre de nœuds) dans votre partition cpu, ou réduisez la requête de ressource dans run_maxtext.sh.

Impossible de se connecter au serveur proxy IFRT

Si le client cesse de répondre ou échoue avec UNAVAILABLE, il ne peut pas joindre le serveur proxy :

  • Vérifiez que le journal du service affiche READY.
  • Vérifiez que JAX_BACKEND_TARGET correspond à l'adresse dans ~/pathways/cluster.env.
  • Si vous utilisez le transfert de port, vérifiez que le tunnel SSH est toujours en cours d'exécution.

  • Si le client s'exécute sur une VM, vérifiez que celle-ci se trouve dans le sous-réseau du cluster. La commande suivante devrait aboutir :

    nc -zv PROXY_IP 29000

    Remplacez PROXY_IP par l'adresse IP du proxy IFRT du journal de service.

jax.devices() liste les appareils CPU au lieu des appareils TPU

Vous avez défini les variables d'environnement JAX_PLATFORMS et JAX_BACKEND_TARGET après avoir importé jax. Redémarrez le kernel du notebook et définissez les variables avant d'importer jax.

Erreurs survenant juste après la connexion au serveur proxy IFRT

La version jax ou pathwaysutils du client ne correspond pas à celle du serveur Pathways. Installez les versions dans ~/pathways/venv.

Un calcul échoue avec DATA_LOSS et PlacementDataLoss

Le calcul a utilisé un appareil sur une tranche qui n'est pas en cours d'exécution. Vérifiez que MIN_SLICES est égal à MAX_SLICES et que chaque tâche de nœud de calcul est en cours d'exécution :

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

Échec d'un calcul après une préemption Spot

Les calculs qui utilisent les appareils de la tranche préemptée échouent. Pour récupérer automatiquement après une préemption Spot, configurez la création de points de contrôle et le redimensionnement élastique des tranches, comme décrit dans Entraînement résilient avec Pathways.

Étapes suivantes