Soluciona problemas de Pathways on Cloud

En esta página, se ayuda a los ingenieros de aprendizaje automático (AA) y a los administradores de plataformas a diagnosticar y resolver problemas con las cargas de trabajo de Pathways en Google Cloud. Usa esta guía para inspeccionar los registros de los componentes, verificar la preparación del clúster y de la porción, supervisar las métricas de transferencia de Megascale XLA (MXLA) y corregir los errores de tiempo de ejecución comunes. En cada sección, selecciona la pestaña GKE o Cluster Director para tu entorno.

Antes de comenzar

Antes de comenzar

GKE

Completa los siguientes requisitos previos antes de continuar:

Cluster Director

Completa los siguientes requisitos previos antes de continuar:

Ver registros

GKE

Puedes ver los registros de tus cargas de trabajo de Pathways directamente con el comando gcluster job logs (pasa --main-only=false para incluir los registros de los Pods de trabajadores):

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

Reemplaza lo siguiente:

  • WORKLOAD_NAME: Es el nombre de tu carga de trabajo cuando usas Cluster Toolkit o el nombre de JobSet cuando usas kubectl.
  • CLUSTER: el nombre del clúster de GKE.
  • PROJECT_ID: Es el ID del proyecto deGoogle Cloud .
  • LOCATION: Es la región o zona en la que creaste el clúster de GKE.

Para enumerar todos los Pods de tu carga de trabajo con kubectl, filtra por la etiqueta de nombre del JobSet:

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

Para verificar el estado de la carga de trabajo o enumerar los trabajos con errores, usa el comando gcluster job list:

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

Como alternativa, en el Explorador de registros de Cloud Logging, ejecuta la siguiente consulta ajustada para tu proyecto, ubicación, clúster y carga de trabajo:

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"

Esta consulta coincide con varios contenedores de Kubernetes de Pathways con nombres como pathways-rm, pathways-proxy, pathways-worker y workload-container. Para determinar qué contenedor está causando un problema, agrega un filtro de nombre de contenedor, como resource.labels.container_name:"CONTAINER_NAME", en el que CONTAINER_NAME es el nombre del contenedor.

Cluster Director

Las secuencias de comandos de Pathways escriben registros en el sistema de archivos compartido:

  • El trabajo del servicio de Pathways escribe pathways-service-SERVICE_JOB_ID.out y pathways-service-SERVICE_JOB_ID.err en el directorio en el que ejecutaste sbatch, por ejemplo, ~/pathways.
  • El administrador de recursos de Pathways, el servidor proxy de IFRT y los trabajadores TPU escriben en ~/pathways/service_SERVICE_JOB_ID/logs, incluidos rm.log, proxy.log y un archivo slice-*.out y slice-*.err por tarea de trabajador.
  • La carga de trabajo de ejemplo de MaxText escribe su registro en maxtext-llama31-JOB_ID.err.

Reemplaza lo siguiente:

  • SERVICE_JOB_ID: Es el ID de trabajo de Slurm del trabajo de servicio de Pathways, que imprime sbatch start_pathways.sh.
  • JOB_ID: Es el ID del trabajo de Slurm del trabajo de MaxText, que imprime sbatch run_maxtext.sh.

En el nodo de acceso, verifica el estado de los trabajos de Pathways y busca sus IDs de trabajo:

squeue -u ${USER}

Supervisa los componentes y las métricas de Pathways

Las siguientes secciones se aplican a Pathways en GKE.

Supervisión del estado

Puedes supervisar el estado de varios componentes de Pathways buscando entradas en los registros del contenedor.

El contenedor pathways-proxy está listo para entregar solicitudes de conexión nuevas cuando escribe la siguiente entrada de registro. Para ver los registros, ejecuta el siguiente comando:

kubectl logs HEAD_POD_NAME --container pathways-proxy

Reemplaza HEAD_POD_NAME por el nombre del Pod principal de Pathways.

El resultado incluye una línea similar a la siguiente:

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

El contenedor pathways-rm está listo para entregar solicitudes de conexión nuevas cuando escribe la siguiente entrada de registro:

kubectl logs HEAD_POD_NAME --container pathways-rm

El resultado incluye una línea similar a la siguiente:

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

POD_IP es la dirección IP del Pod, que puede cambiar cuando el Pod se reinicia o se reprograma.

Para verificar que todas las porciones de TPU estén listas, revisa los registros del contenedor de pathways-rm en busca de Pathways Slices Now Ready:

kubectl logs HEAD_POD_NAME --container pathways-rm

Por ejemplo, la siguiente entrada de registro muestra que 2 de 2 porciones están listas:

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

El cliente de Pathways puede conectarse al servidor proxy de IFRT en cuanto el servidor proxy esté listo, incluso si no todas las porciones están listas. Tu trabajo funciona con porciones virtuales hasta que las porciones de TPU estén listas. Los segmentos virtuales permiten que tu código se ejecute cuando las TPU no están disponibles.

Para verificar que un contenedor de pathways-worker esté listo, revisa sus registros:

kubectl logs WORKER_POD_NAME --container pathways-worker

Reemplaza WORKER_POD_NAME por el nombre de un Pod de trabajador de Pathways.

Cuando el trabajador está listo, el resultado incluye una línea similar a la siguiente:

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

POD_IP es la dirección IP del Pod, que puede cambiar cuando el Pod se reinicia o se reprograma.

Recopilación de métricas

Pathways puede escribir métricas del sistema de bajo nivel en Cloud Monitoring para la depuración. Las métricas incluyen lo siguiente:

  • Latencia de transferencia de la red del centro de datos (DCN)
  • Latencia colectiva
  • Latencia de transferencia de host a dispositivo
  • Latencia de transferencia de dispositivo a host

Puedes encontrar las métricas en el panel de Monitoring del proyecto deGoogle Cloud en el que se ejecuta el clúster de GKE.

Para supervisar estas métricas en el Explorador de métricas, sigue estos pasos:

  1. En la consola de Google Cloud , ve a la página Explorador de métricas.
  2. En el campo Seleccionar una métrica, filtra por el nombre de la métrica.
  3. Para filtrar por el nombre de la carga de trabajo y el período, haz clic en Agregar filtro y, luego, filtra por pod_name.
  4. En Agregación, elige un tipo de agregación según la métrica y las cargas de trabajo que supervisas.

Latencia de transferencia de DCN

Esta métrica de Megascale XLA (MXLA) mide la distribución acumulativa de las latencias de transferencia de red para el tráfico de Multislice. La medición de la latencia comienza cuando el sistema emite una solicitud para transferir datos a través de la DCN y finaliza cuando recibe un acuse de recibo de que se completó la transferencia de datos. Para supervisar esta métrica, filtra por el nombre de la métrica dcn_transfer_latencies.

Latencia colectiva

Esta métrica de MXLA mide la distribución acumulativa de la latencia colectiva de extremo a extremo para el tráfico de varias porciones. La medición de la latencia comienza cuando el sistema emite una solicitud para una operación colectiva y finaliza cuando recibe un reconocimiento de que se completó la transferencia de datos. Para supervisar esta métrica, filtra por el nombre de la métrica collective_end_to_end_latencies.

Latencia de transferencia de host a dispositivo

Esta métrica de MXLA mide la distribución acumulativa de las latencias de transferencia de host a dispositivo para el tráfico de Multislice. La medición de la latencia comienza cuando el sistema emite una solicitud para transferir datos del host a un dispositivo TPU y finaliza cuando recibe una confirmación de que se completó la transferencia de datos. Para supervisar esta métrica, filtra por el nombre de la métrica host_to_device_transfer_latencies.

Latencia de transferencia de dispositivo a host

Esta métrica de MXLA mide la distribución acumulativa de las latencias de transferencia de dispositivo a host para el tráfico de varias porciones. La medición de la latencia comienza cuando el sistema emite una solicitud para transferir datos de un dispositivo TPU al host y finaliza cuando recibe un acuse de recibo de que se completó la transferencia de datos. Para supervisar esta métrica, filtra por el nombre de la métrica device_to_host_transfer_latencies.

Depura los errores comunes

GKE

No se pueden generar hashes de las advertencias de configuración del acelerador

Los siguientes mensajes son solo advertencias y no afectan el rendimiento de tu código de 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'>)

Se denegó el permiso logging.logEntries.create en el recurso

Si ves el siguiente error, asegúrate de que la cuenta de servicio de Compute Engine que usa Vertex AI Workbench tenga permiso para escribir entradas de registro en 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)."}"
>

Para solucionar este problema, otorga el rol de Escritor de registros (roles/logging.logWriter) a la cuenta de servicio de Compute Engine.

No se puede establecer conexión con el servidor proxy de IFRT

Cuando se intente ejecutar el primer comando de JAX que envía un comando de IFRT al clúster de Pathways, es posible que deje de responder durante un minuto y, luego, muestre un RuntimeError similar al siguiente:

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 ves este error, significa que tu cliente de proxy de IFRT no puede conectarse al servidor proxy de IFRT. Verifica lo siguiente:

  • Verifica que hayas configurado correctamente tu red de nube privada virtual (VPC).
  • Verifica que las reglas de firewall permitan la conexión.
  • Verifica que tu clúster de Pathways esté aprovisionado.
  • Verifica si hay mensajes de error de inicio en los registros del contenedor.

Se produjo un error en el protocolo de enlace de ALTS o se cerró el socket cuando se estableció la conexión con el servidor proxy de IFRT

Es posible que veas Alts handshake failed (TSI_INTERNAL_ERROR) o UNAVAILABLE: Unable to establish connection to ifrt_proxy server ... Socket closed cuando ejecutes un manifiesto personalizado sin el campo hostNetwork: true en un grupo de nodos de Workload Identity Federation para GKE. Para resolver este problema, establece la variable de entorno IFRT_PROXY_USE_INSECURE_GRPC_CREDENTIALS: "true" en el contenedor pathways-proxy y en el contenedor del cliente de JAX (ambos lados deben coincidir). Si agregas esta variable de entorno, se inhabilita ALTS y, en su lugar, se usa gRPC no seguro, por lo que debes usarla solo dentro de una red de clústeres de confianza.

Hay una conexión existente con el clúster de Pathways

Un clúster de Pathways puede mantener una sesión con un solo cliente a la vez. Si dos notebooks independientes intentan conectarse al mismo clúster de Pathways, uno se conecta y el otro muestra los siguientes errores:

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)

Después de que se desconecte el cliente original, se podrá conectar el segundo cliente. Después de una desconexión inesperada, es posible que debas reiniciar el clúster de Pathways para que otros clientes puedan conectarse.

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

Si ves el siguiente error después de importar pathwaysutils, verifica si hay versiones desactualizadas de Flask o Werkzeug instaladas en tu entorno (reemplaza pip3 por pip si es necesario):

pip3 list --outdated

Si Flask o Werkzeug aparecen en la lista, actualiza los paquetes (ten en cuenta que la actualización puede afectar a otros paquetes o dependencias de tu proyecto):

pip3 install --upgrade flask Werkzeug

Error interno del servidor proxy

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

Este error indica que el servidor proxy de IFRT se desconectó del cliente. Para solucionar este problema, reinicia el cliente. En el caso de los notebooks, reinicia el kernel y vuelve a ejecutarlo.

OOM de SIGTERM y HBM

Una entrada SIGTERM en los registros asociados con un error RESOURCE_EXHAUSTED podría indicar un error de memoria insuficiente (OOM) de la memoria de ancho de banda alto (HBM). En este caso, reduce la cantidad de HBM que usa tu código de 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"

Este error se produce si el bucket de Cloud Storage que se pasó a la marca --pathways-gcs-location alcanzó el límite máximo de la política del ciclo de vida (50 prefijos). Para resolver este problema, borra las políticas del ciclo de vida de Cloud Storage que ya no uses.

Error permanente

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

El administrador de recursos de Pathways o los trabajadores de Pathways imprimen este error cuando proporcionas una ubicación de Cloud Storage no válida a los contenedores de Pathways.

Error response from daemon

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

Este error se produce cuando usas una versión anterior de Docker. Actualiza tu versión de Docker.

El cliente y el servidor del proxy de IFRT no pudieron establecer un acuerdo

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

Este error indica que estás usando una versión anterior de MaxText. Vuelve a compilar la imagen de MaxText más reciente.

Cluster Director

setup_env.sh falla con un error mktemp de Enroot

Si setup_env.sh falla con el siguiente error, el directorio temporal de Enroot no existe:

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

Para solucionar este problema, ejecuta mkdir -p /tmp/$(id -u)/tmp y, luego, vuelve a ejecutar la secuencia de comandos.

setup_env.sh no puede extraer las imágenes de Pathways

Si setup_env.sh falla con Couldn't pull ..., no se etiqueta ninguna imagen de Pathways para el JAX_VERSION solicitado. Usa una versión de JAX compatible.

El clúster no tiene una partición cpu

Si sinfo no muestra una partición cpu, a la definición del clúster le falta el conjunto de nodos de CPU o su partición tiene un nombre diferente. Las secuencias de comandos de Pathways envían trabajos a una partición llamada cpu. Para solucionar este problema, actualiza el esquema del clúster para definir una partición de CPU llamada cpu y vuelve a implementar el clúster, o actualiza el nombre de la partición en las secuencias de comandos de tu trabajo de Pathways para que coincida con la partición de CPU que muestra sinfo.

Los nodos TPU no aparecen

Verifica que la reserva esté en la zona del clúster y tenga suficientes VMs ct6e-standard-4t, y que staticNodeCount y acceleratorTopology coincidan.

El servicio de Pathways se cierra con Invalid partition name specified

La variable PARTITION es incorrecta. Elige una partición de TPU del resultado de sinfo.

El servicio de Pathways no se prepara

Si el registro del servicio se mantiene en Waiting for at least MIN_SLICES=..., no se están ejecutando suficientes porciones. En la columna NODELIST(REASON) del siguiente comando, se muestra el motivo, por ejemplo, que no hay capacidad disponible o que un valor de SLICE_SHAPE no coincide con el conjunto de nodos de TPU:

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

El administrador de recursos de Pathways o el servidor proxy de IFRT no se inicia

Si el servicio falla con Timed out waiting for Pathways Resource Manager o Timed out waiting for Pathways IFRT Proxy Server, un contenedor de Pathways no se inició. Verifica rm.log y proxy.log en el directorio de registros.

El servicio de Pathways se detiene de forma inesperada

Si el servicio se detiene con The Pathways Resource Manager or IFRT proxy exited, uno de ellos falló y el servicio detuvo sus trabajadores. Verifica rm.log y proxy.log en el directorio de registros y, luego, vuelve a iniciar el servicio.

Un nodo TPU está atascado en un estado incorrecto

Para recuperar el nodo, ejecuta el siguiente comando en el nodo de acceso:

sudo scontrol update nodename=NODE \
    state=power_down_force

Reemplaza NODE por el nombre del nodo, como se muestra en sinfo.

MaxText no puede encontrar un servicio de Pathways en ejecución

Si MaxText falla con No running Pathways service after 60 minutes, el servicio no se está ejecutando o aún no está listo. Verifica el registro del servicio. Para esperar más tiempo, establece SERVICE_WAIT_MINUTES cuando envíes run_maxtext.sh.

MaxText falla con RESOURCE_EXHAUSTED

El modelo no cabe en la memoria de la TPU. Usa porciones 2x4 o 4x4, o bien establece REDUCED_LAYERS=1.

El trabajo de MaxText permanece pendiente

El nodo de CPU no tiene las 8 CPU ni los 160 GB de memoria que solicita run_maxtext.sh, además de las 4 CPU y los 80 GB de memoria que usa el servicio de Pathways. Ambos trabajos se ajustan en un nodo n2-highmem-32. Para solucionar este problema, aumenta la capacidad de CPU y memoria (o la cantidad de nodos) en tu partición cpu, o reduce la solicitud de recursos en run_maxtext.sh.

No se puede establecer conexión con el servidor proxy de IFRT

Si el cliente deja de responder o falla con UNAVAILABLE, no puede comunicarse con el servidor proxy:

  • Verifica que el registro del servicio muestre READY.
  • Verifica que JAX_BACKEND_TARGET coincida con la dirección en ~/pathways/cluster.env.
  • Si usas la redirección de puertos, verifica que el túnel SSH aún se esté ejecutando.

  • Si el cliente se ejecuta en una VM, verifica que la VM esté en la subred del clúster. El siguiente comando debería completarse correctamente:

    nc -zv PROXY_IP 29000

    Reemplaza PROXY_IP por la dirección IP del proxy de IFRT del registro del servicio.

jax.devices() enumera los dispositivos de CPU en lugar de los dispositivos de TPU

Configuraste las variables de entorno JAX_PLATFORMS y JAX_BACKEND_TARGET después de importar jax. Reinicia el kernel del notebook y establece las variables antes de importar jax.

Errores justo después de conectarse al servidor proxy de IFRT

La versión de jax o pathwaysutils del cliente no coincide con la del servidor de Pathways. Instala las versiones en ~/pathways/venv.

Un cálculo falla con DATA_LOSS y PlacementDataLoss

El cálculo usó un dispositivo en una porción que no se está ejecutando, por ejemplo, porque se interrumpió la porción. El servidor proxy de IFRT permanece conectado mientras Slurm vuelve a poner en cola la porción. Verifica si se están ejecutando todas las tareas de trabajador y vuelve a ejecutar el cálculo después de que se restablezca la porción:

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

Un cálculo falla después de una interrupción de Spot

Los cálculos que usan los dispositivos de la porción interrumpida fallan. Para recuperarte de las interrupciones de Spot automáticamente, configura los puntos de control y el cambio de escala de las porciones elásticas, como se describe en Entrenamiento resiliente con Pathways.

¿Qué sigue?