Resolver problemas do Pathways on Cloud

Esta página ajuda engenheiros de machine learning (ML) e administradores de plataforma a diagnosticar e resolver problemas com cargas de trabalho do Pathways no Google Cloud. Use este guia para inspecionar registros de componentes, verificar a prontidão de clusters e frações, monitorar métricas de transferência do Megascale XLA (MXLA) e corrigir erros comuns de tempo de execução. Em cada seção, selecione a guia GKE ou Cluster Director para seu ambiente.

Antes de começar

Antes de começar

GKE

Conclua os seguintes pré-requisitos antes de continuar:

Cluster Director

Conclua os seguintes pré-requisitos antes de continuar:

Como visualizar registros

GKE

É possível visualizar os registros das cargas de trabalho do Pathways diretamente usando o comando gcluster job logs (transmita --main-only=false para incluir registros de pods de worker):

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

Substitua:

  • WORKLOAD_NAME: o nome da carga de trabalho ao usar o Cluster Toolkit ou o nome do JobSet ao usar kubectl.
  • CLUSTER: o nome do cluster do GKE.
  • PROJECT_ID: o ID do projeto doGoogle Cloud .
  • LOCATION: a região ou zona em que você criou o cluster do GKE.

Para listar todos os pods da carga de trabalho usando kubectl, filtre pelo rótulo de nome do JobSet:

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

Para verificar o status da carga de trabalho ou listar jobs com falha, use o comando gcluster job list:

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

Como alternativa, na Análise de registros do Cloud Logging, execute a consulta a seguir ajustada para seu projeto, local, cluster e carga de trabalho:

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"

Essa consulta corresponde a vários contêineres do Kubernetes do Pathways com nomes como pathways-rm, pathways-proxy, pathways-worker e workload-container. Para determinar qual contêiner está causando um problema, adicione um filtro de nome de contêiner, como resource.labels.container_name:"CONTAINER_NAME", em que CONTAINER_NAME é o nome do contêiner.

Cluster Director

Os scripts do Pathways gravam registros no sistema de arquivos compartilhado:

  • O job de serviço do Pathways grava pathways-service-SERVICE_JOB_ID.out e pathways-service-SERVICE_JOB_ID.err no diretório em que você executou sbatch, por exemplo, ~/pathways.
  • O gerenciador de recursos do Pathways, o servidor proxy do IFRT e os workers da TPU gravam em ~/pathways/service_SERVICE_JOB_ID/logs, incluindo rm.log, proxy.log e um arquivo slice-*.out e slice-*.err por tarefa do worker.
  • A carga de trabalho de exemplo do MaxText grava o registro em maxtext-llama31-JOB_ID.err.

Substitua:

  • SERVICE_JOB_ID: o ID da tarefa do Slurm do job de serviço do Pathways, que é impresso por sbatch start_pathways.sh.
  • JOB_ID: o código da tarefa do Slurm do job do MaxText, que é mostrado por sbatch run_maxtext.sh.

No nó de login, verifique o estado dos jobs do Pathways e encontre os IDs deles:

squeue -u ${USER}

Monitorar componentes e métricas do Pathways

As seções a seguir se aplicam ao Pathways no GKE.

Monitoramento de integridade

É possível monitorar a integridade de vários componentes do Pathways procurando entradas nos registros do contêiner.

O contêiner pathways-proxy estará pronto para atender a novas solicitações de conexão quando gravar a seguinte entrada de registro. Para ver os registros, execute o seguinte comando:

kubectl logs HEAD_POD_NAME --container pathways-proxy

Substitua HEAD_POD_NAME pelo nome do pod principal do Pathways.

A saída inclui uma linha semelhante a esta:

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

O contêiner pathways-rm estará pronto para atender a novas solicitações de conexão quando gravar a seguinte entrada de registro:

kubectl logs HEAD_POD_NAME --container pathways-rm

A saída inclui uma linha semelhante a esta:

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

POD_IP é o endereço IP do pod, que pode mudar quando o pod é reiniciado ou reprogramado.

Para verificar se todas as frações de TPU estão prontas, verifique os registros do contêiner pathways-rm em busca de Pathways Slices Now Ready:

kubectl logs HEAD_POD_NAME --container pathways-rm

Por exemplo, a entrada de registro a seguir mostra que 2 de 2 frações estão prontas:

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

O cliente do Pathways pode se conectar ao servidor proxy do IFRT assim que o servidor proxy estiver pronto, mesmo que nem todas as frações estejam prontas. Seu job funciona com frações virtuais até que as frações de TPU estejam prontas. As frações virtuais permitem que seu código seja executado quando as TPUs estão indisponíveis.

Para verificar se um contêiner pathways-worker está pronto, confira os registros dele:

kubectl logs WORKER_POD_NAME --container pathways-worker

Substitua WORKER_POD_NAME pelo nome de um pod de worker do Pathways.

Quando o worker estiver pronto, a saída vai incluir uma linha semelhante a esta:

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

POD_IP é o endereço IP do pod, que pode mudar quando o pod é reiniciado ou reprogramado.

Coleta de métricas

O Pathways pode gravar métricas de sistema de baixo nível no Cloud Monitoring para depuração. As métricas incluem:

  • Latência de transferência da rede de data center (DCN, na sigla em inglês)
  • Latência coletiva
  • Latência de transferência de host para dispositivo
  • Latência de transferência de dispositivo para host

Encontre as métricas no painel do Monitoring do projeto doGoogle Cloud em que o cluster do GKE está em execução.

Para monitorar essas métricas no Metrics Explorer, siga estas etapas:

  1. No console do Google Cloud , acesse a página do Metrics Explorer.
  2. No campo Selecionar uma métrica, filtre pelo nome da métrica.
  3. Para filtrar por nome e período da carga de trabalho, clique em Adicionar filtro e, em seguida, filtre por pod_name.
  4. Em Agregação, escolha um tipo de agregação com base na métrica e nas cargas de trabalho que você está monitorando.

Latência de transferência da DCN

Essa métrica do Megascale XLA (MXLA) mede a distribuição cumulativa de latências de transferência de rede para tráfego multislice. A medição de latência começa quando o sistema emite uma solicitação para transferir dados pela DCN e termina quando recebe uma confirmação de que a transferência de dados foi concluída. Para monitorar essa métrica, filtre pelo nome dcn_transfer_latencies.

Latência coletiva

Essa métrica do MXLA mede a distribuição cumulativa da latência coletiva de ponta a ponta para o tráfego multislice. A medição de latência começa quando o sistema emite uma solicitação para uma operação de comunicação coletiva e termina quando recebe uma confirmação de que a transferência de dados foi concluída. Para monitorar essa métrica, filtre pelo nome collective_end_to_end_latencies.

Latência de transferência de host para dispositivo

Essa métrica do MXLA mede a distribuição cumulativa de latências de transferência de host para dispositivo para tráfego multislice. A medição de latência começa quando o sistema emite uma solicitação para transferir dados do host para um dispositivo de TPU e termina quando recebe uma confirmação de que a transferência de dados foi concluída. Para monitorar essa métrica, filtre pelo nome host_to_device_transfer_latencies.

Latência de transferência de dispositivo para host

Essa métrica do MXLA mede a distribuição cumulativa de latências de transferência de dispositivo para host para tráfego multislice. A medição de latência começa quando o sistema emite uma solicitação para transferir dados de um dispositivo de TPU para o host e termina quando recebe uma confirmação de que a transferência de dados foi concluída. Para monitorar essa métrica, filtre pelo nome device_to_host_transfer_latencies.

Depurar erros comuns

GKE

Não foi possível gerar hash dos avisos de configuração do acelerador

As mensagens a seguir são apenas avisos e não afetam o desempenho do código 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'>)

Permissão logging.logEntries.create negada no recurso

Se você receber o erro a seguir, verifique se a conta de serviço do Compute Engine usada pelo Vertex AI Workbench tem permissão para gravar entradas de registro no 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 corrigir esse problema, conceda o papel de Gravador de registros (roles/logging.logWriter) à conta de serviço do Compute Engine.

Não é possível se conectar ao servidor proxy do IFRT

Quando o primeiro comando JAX que envia um comando IFRT ao cluster do Pathways tentar ser executado, ele poderá parar de responder por cerca de um minuto e, em seguida, exibir um RuntimeError semelhante ao seguinte:

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)

Se você receber esse erro, significa que o cliente proxy do IFRT não consegue se conectar ao servidor proxy do IFRT. Verifique se:

  • Verifique se você configurou corretamente a rede de nuvem privada virtual (VPC).
  • Verifique se as regras de firewall permitem a conexão.
  • Verifique se o cluster do Pathways está provisionado.
  • Verifique se há mensagens de erro de inicialização nos registros do contêiner.

Falha no handshake do ALTS ou soquete fechado ao se conectar ao servidor proxy do IFRT

Talvez você veja Alts handshake failed (TSI_INTERNAL_ERROR) ou UNAVAILABLE: Unable to establish connection to ifrt_proxy server ... Socket closed ao executar um manifesto personalizado sem o campo hostNetwork: true em um pool de nós da Federação de Identidade da Carga de Trabalho para GKE. Para resolver esse problema, defina a variável de ambiente IFRT_PROXY_USE_INSECURE_GRPC_CREDENTIALS: "true" no contêiner pathways-proxy e no contêiner do cliente JAX (os dois lados precisam corresponder). Adicionar essa variável de ambiente desativa o ALTS e usa o gRPC não seguro. Portanto, use-a apenas em uma rede de cluster confiável.

Há uma conexão com o cluster do Pathways

Um cluster do Pathways pode manter uma sessão com apenas um cliente por vez. Se dois notebooks separados tentarem se conectar ao mesmo cluster do Pathways, um vai se conectar e o outro vai exibir os seguintes erros:

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)

Depois que o cliente original se desconectar, o segundo poderá se conectar. Após uma desconexão inesperada, talvez seja necessário reiniciar o cluster do Pathways para que outros clientes possam se conectar.

LocalProxy.__init__() recebeu um argumento de palavra-chave inesperado 'unbound_message'

Se o erro a seguir aparecer depois de importar pathwaysutils, verifique se versões desatualizadas do Flask ou do Werkzeug estão instaladas no seu ambiente (substitua pip3 por pip, se necessário):

pip3 list --outdated

Se o Flask ou o Werkzeug estiverem listados, faça upgrade dos pacotes (isso pode afetar outros pacotes ou dependências no seu projeto):

pip3 install --upgrade flask Werkzeug

Erro interno do 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."

Esse erro indica que o servidor proxy do IFRT foi desconectado do cliente. Para corrigir esse problema, reinicie o cliente. Para notebooks, reinicie o kernel do notebook e execute-o novamente.

SIGTERM e OOM de HBM

Uma entrada SIGTERM nos registros associados a um erro RESOURCE_EXHAUSTED pode indicar um erro de falta de memória (OOM, na sigla em inglês) de alta largura de banda (HBM, na sigla em inglês). Nesse caso, reduza a quantidade de HBM usada pelo código 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"

Esse erro vai ocorrer se o bucket do Cloud Storage transmitido para a flag --pathways-gcs-location tiver atingido o limite máximo da política de ciclo de vida (50 prefixos). Para resolver esse problema, exclua as políticas de ciclo de vida do Cloud Storage que você não usa mais.

Erro permanente

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

O gerenciador de recursos ou os workers do Pathways mostram esse erro quando você fornece um local inválido do Cloud Storage para os contêineres do Pathways.

Resposta de erro do daemon

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

Esse erro ocorre quando você usa uma versão mais antiga do Docker. Faça upgrade da versão do Docker.

O cliente e o servidor do proxy IFRT não concordaram

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

Esse erro indica que você está usando uma versão mais antiga do MaxText. Recrie a imagem mais recente do MaxText.

Cluster Director

setup_env.sh falha com um erro mktemp do Enroot

Se setup_env.sh falhar com o erro a seguir, o diretório temporário do Enroot não existe:

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

Para corrigir esse problema, execute mkdir -p /tmp/$(id -u)/tmp e, em seguida, execute o script novamente.

setup_env.sh não consegue extrair as imagens do Pathways

Se setup_env.sh falhar com Couldn't pull ..., nenhuma imagem do Pathways será marcada para o JAX_VERSION solicitado. Use uma versão compatível do JAX.

O cluster não tem partição cpu

Se sinfo não mostrar uma partição cpu, a definição do cluster não terá o conjunto de nós da CPU ou nomeará a partição de maneira diferente. Os scripts do Pathways enviam jobs para uma partição chamada cpu. Para corrigir esse problema, atualize o blueprint do cluster para definir uma partição de CPU chamada cpu e reimplante o cluster ou atualize o nome da partição nos scripts de job do Pathways para corresponder à partição de CPU mostrada por sinfo.

Os nós de TPU não aparecem

Verifique se a reserva está na zona do cluster e tem VMs ct6e-standard-4t suficientes, e se staticNodeCount e acceleratorTopology correspondem.

O serviço Pathways é encerrado com Invalid partition name specified

A variável PARTITION está errada. Escolha uma partição de TPU na saída de sinfo.

O serviço Pathways não fica pronto

Se o registro do serviço permanecer em Waiting for at least MIN_SLICES=..., não há frações suficientes em execução. A coluna NODELIST(REASON) do comando a seguir mostra o motivo, por exemplo, nenhuma capacidade disponível ou um valor SLICE_SHAPE que não corresponde ao conjunto de nós da TPU:

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

O gerenciador de recursos do Pathways ou o servidor proxy do IFRT não é iniciado

Se o serviço falhar com Timed out waiting for Pathways Resource Manager ou Timed out waiting for Pathways IFRT Proxy Server, um contêiner do Pathways não foi iniciado. Verifique rm.log e proxy.log no diretório de registros.

O serviço Pathways é interrompido inesperadamente

Se o serviço for interrompido com The Pathways Resource Manager or IFRT proxy exited, um deles falhou, e o serviço interrompeu os workers. Verifique rm.log e proxy.log no diretório de registros e, em seguida, inicie o serviço novamente.

Um nó da TPU está travado em um estado inválido

Para recuperar o nó, execute o seguinte comando no nó de login:

sudo scontrol update nodename=NODE \
    state=power_down_force

Substitua NODE pelo nome do nó, conforme mostrado por sinfo.

O MaxText não consegue encontrar um serviço do Pathways em execução

Se o MaxText falhar com No running Pathways service after 60 minutes, o serviço não está em execução ou ainda não está pronto. Verifique o registro do serviço. Para esperar mais, defina SERVICE_WAIT_MINUTES ao enviar run_maxtext.sh.

O MaxText falha com RESOURCE_EXHAUSTED

O modelo não cabe na memória da TPU. Use frações 2x4 ou 4x4 ou defina REDUCED_LAYERS=1.

O job do MaxText permanece pendente

O nó de CPU não tem as 8 CPUs e os 160 GB de memória que o run_maxtext.sh solicita, além das 4 CPUs e dos 80 GB de memória que o serviço Pathways usa. Os dois jobs se encaixam em um nó n2-highmem-32. Para corrigir esse problema, aumente a capacidade de CPU e memória (ou o número de nós) na partição cpu ou reduza a solicitação de recurso em run_maxtext.sh.

Não é possível se conectar ao servidor proxy do IFRT

Se o cliente parar de responder ou falhar com UNAVAILABLE, ele não poderá acessar o servidor proxy:

  • Verifique se o registro do serviço mostra READY.
  • Verifique se JAX_BACKEND_TARGET corresponde ao endereço em ~/pathways/cluster.env.
  • Se você usa o encaminhamento de portas, verifique se o túnel SSH ainda está em execução.

  • Se o cliente for executado em uma VM, verifique se ela está na sub-rede do cluster. O comando a seguir deve ser bem-sucedido:

    nc -zv PROXY_IP 29000

    Substitua PROXY_IP pelo endereço IP do proxy do IFRT do registro do serviço.

jax.devices() lista dispositivos de CPU em vez de dispositivos de TPU

Você definiu as variáveis de ambiente JAX_PLATFORMS e JAX_BACKEND_TARGET depois de importar jax. Reinicie o kernel do notebook e defina as variáveis antes de importar jax.

Erros logo após a conexão com o servidor proxy do IFRT

A versão jax ou pathwaysutils do cliente não corresponde ao servidor do Pathways. Instale as versões em ~/pathways/venv.

Uma computação falha com DATA_LOSS e PlacementDataLoss

A computação usou um dispositivo em uma fração que não está em execução, por exemplo, porque a fração foi interrompida. O servidor proxy do IFRT permanece conectado enquanto o Slurm coloca a fração na fila novamente. Verifique se todas as tarefas de worker estão em execução e execute o cálculo novamente depois que a fração voltar:

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

Uma computação falha após uma preempção do Spot

As computações que usam os dispositivos da fração preemptiva falham. Para se recuperar de preempções de Spot automaticamente, configure o checkpoint e o reescalonamento de frações elásticas, conforme descrito em Treinamento resiliente com Pathways.

A seguir