Antes de comenzar
- XPK instalado
- Herramientas de Kubernetes instaladas
- Instalaste la CLI de gcloud
- Habilitaste la API de TPU
- Habilitaste la API de Google Kubernetes Engine
- Creaste un clúster de Google Kubernetes Engine
En este documento, se explica cómo solucionar problemas relacionados con tus cargas de trabajo de Pathways.
Visualiza registros
En el Explorador de registros de Cloud Logging, usa la siguiente consulta ajustada para que coincida con tu proyecto, región, clúster y carga de trabajo.
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"
Reemplaza lo siguiente:
PROJECT: El ID de tu proyecto de Google CloudLOCATION: Es la región o zona en la que creaste el clúster de GKE.CLUSTER: Es el nombre de tu clúster de GKE.WORKLOAD_NAME: Es el nombre de tu carga de trabajo cuando usas XPK o el nombre de JobSet cuando usaskubectl.
Esta búsqueda coincidirá con varios contenedores de Kubernetes de Pathways con nombres como pathways-rm, pathways-proxy y pathways-worker. Para determinar qué contenedor está causando un problema, puedes agregar un filtro en el nombre del contenedor, como resource.labels.container_name:"<container_name>".
Supervisión
Supervisión del estado
Puedes supervisar el estado de varios componentes de Pathways buscando entradas en los registros del contenedor, por ejemplo:
pathways-proxy está listo para atender nuevas solicitudes de conexión cuando se escribe el siguiente registro:
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á listo para atender nuevas solicitudes de conexión cuando se escribe el siguiente registro:
kubectl logs $HEAD_POD_NAME --container pathways-rm
...
I1101 04:50:41.967764 1 server_lib.cc:1473] Pathways Server serving on [::]:29001
Para verificar que todas las TPU registradas en el Administrador de recursos de Pathways estén listas, puedes buscar ***<num slices>/<num slices> Pathways Slices Now Ready *** en los registros del contenedor 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 ***
El cliente de Pathways puede establecer conexiones con el servidor proxy de IFRT siempre que el servidor proxy esté listo, incluso si no lo están todos los segmentos. Tu trabajo funciona con segmentos virtuales hasta que el segmento está listo. Las porciones virtuales permiten que tu código se ejecute cuando las TPU no están disponibles.
pathways-worker está listo para atender nuevas solicitudes de conexión cuando se escribe el siguiente registro:
kubectl logs $WORKER_POD_NAME --container pathways-worker
...
I1101 04:50:41.967764 1 server_lib.cc:1473] Pathways Server serving on [::]:29001
Recopilación de métricas
Las rutas pueden 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 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 Cloud Monitoring del proyecto {gcp_name} en el que se ejecuta el clúster de GKE.
Para supervisar estas métricas en el Explorador de métricas, haz lo siguiente:
- Navega al Explorador de métricas.
- Filtra por el nombre de la métrica con el campo Seleccionar una métrica.
- Para filtrar por el nombre de tu carga de trabajo y el período, selecciona Agregar filtro y filtra por pod_name.
- Elige un tipo de agregación adecuado según la métrica y las cargas de trabajo que supervisas.
Latencia de transferencia de DCN
Esta es una métrica de Megascale XLA (MXLA) que mide la distribución acumulativa de las latencias de transferencia de red para el tráfico de varias porciones. La medición de la latencia comienza cuando se emite una solicitud de datos para transferir a través de la DCN y finaliza cuando se 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 dcn_transfer_latencies.
Latencia colectiva
Es una métrica de MXLA que 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 se emite una solicitud para un colectivo y finaliza cuando se 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 collective_e2e_latency.
Latencia de transferencia de host a dispositivo
Es una métrica de MXLA que mide la distribución acumulativa de las latencias de transferencia de host a dispositivo para el tráfico de varias porciones. La medición de la latencia comienza cuando se emite una solicitud de transferencia de datos a través de la DCN y finaliza cuando se 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
Es una métrica de MXLA que 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 se emite una solicitud de datos para transferir a través de la DCN y finaliza cuando se 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 device_to_host_transfer_latencies.
Depura los errores comunes
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 permisos para escribir entradas de registro en el sistema de registro 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)."}"
>
Para corregir este problema, agrega el rol de Logs Writer a la cuenta de servicio de Compute Engine.
No se puede establecer conexión con el servidor proxy de IFRT
Si ves este error, significa que tu cliente proxy de IFRT no puede conectarse al servidor proxy de IFRT.
- Asegúrate de que tu red de VPC esté configurada correctamente
- Asegúrate de que el firewall esté configurado para permitir la conexión.
- Asegúrate de que se haya aprovisionado tu clúster de Pathways
- Comprueba si hay mensajes de error de inicio
Cuando se intente ejecutar tu primer comando de JAX que envía un comando de IFRT al clúster de Pathways, dejará de responder durante aproximadamente un minuto y, luego, mostrará un RuntimeError como el 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)
Ya existe una conexión con el clúster de Pathways
Un clúster de Pathways solo puede mantener una sesión con un cliente a la vez. Si dos notebooks separados intentan conectarse al mismo clúster de Pathways, uno podrá conectarse y el otro mostrará 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)
Una vez que el cliente original se desconecte, el segundo cliente podrá conectarse. Después de una desconexión inesperada, es posible que debas reiniciar el clúster de Pathways para permitir que se conecten otros clientes.
LocalProxy.init() recibió un argumento de palabra clave inesperado "unbound_message"
Si ves este error después de importar pathwaysutils, verifica si hay versiones desactualizadas de Flask o Werkzeug instaladas en tu entorno:
pip3 list --outdated (replacing pip with pip3 as needed)
Si se muestran Flask o Werkzeug, considera actualizarlos, pero ten en cuenta que hacerlo puede dañar otros paquetes o dependencias de tu proyecto:
pip install flask Werkzeug --upgrade ()
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, puedes reiniciar el kernel y volver a ejecutar el notebook.
SIGTERMS y HBM OOM
Un SIGTERM que se encuentra en los registros asociados con un error RESOURCE_EXHAUSTED puede indicar un error de OOM de HBM. En este caso, puedes reducir la cantidad de memoria HBM que se usa en 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 políticas de ciclo de vida. Si esto ocurre, limpia las políticas de ciclo de vida de Cloud Storage que ya no se usan.
Error permanente
Permanent error, with a last message of The specified bucket does not exist.; Error while initializing persistent cache storage gcs
Este error se imprime en los trabajadores de Resource Manager o de Pathways cuando proporcionas una ubicación de Cloud Storage no válida para los contenedores de Pathways.
Respuesta de error del daemon
Error response from daemon: dockerfile parse error line 16: Unknown flag: exclude
Esto se debe a una versión anterior de Docker. Actualiza tu versión de Docker.
No se pudo establecer un acuerdo entre el cliente y el servidor de IFRT Proxy
IFRT Proxy client and server failed to agree on the protocol version; supported versions: client = [1, 1], server = [3, 14]
Esto indica que se está usando una versión anterior de MaxText. Asegúrate de volver a compilar la imagen más reciente de MaxText.
¿Qué sigue?
- Inferencia multihost con Pathways
- Cargas de trabajo por lotes con Pathways
- Modo interactivo de Rutas de aprendizaje
- Cómo portar cargas de trabajo de JAX a Pathways
- Capacitación resiliente con Pathways