Resolver problemas com os programas do Pathways on Cloud

Pré-lançamento

Este produto ou recurso está sujeito aos "Termos das Soluções Pré-GA" na seção Termos Gerais de Serviço dos Termos Específicos de Serviço. Os produtos e recursos pré-GA estão disponíveis no estado em que se encontram e podem ter assistência limitada. Para mais informações, consulte as descrições das fases de lançamento.

Antes de começar

• XPK instalado
• Ferramentas do Kubernetes instaladas
• Instale a CLI gcloud.
• Ativou a API TPU
• Ativou a API Google Kubernetes Engine
• Criar um cluster do Google Kubernetes Engine

Este documento explica como resolver problemas com as cargas de trabalho dos programas.

Como ver registros

No Explorador de registros do Cloud Logging, use a consulta ajustada para corresponder ao seu projeto, região, cluster e carga de trabalho.

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"

Substitua:

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

Essa consulta vai corresponder a vários contêineres do Kubernetes do programa de aprendizado com nomes como pathways-rm, pathways-proxy e pathways-worker. Para restringir a pesquisa e descobrir qual contêiner está causando um problema, adicione um filtro ao nome do contêiner, como resource.labels.container_name:"<container_name>".

Monitoramento

Monitoramento de integridade

É possível monitorar a integridade de vários componentes dos programas olhando as entradas nos registros do contêiner, por exemplo:

O pathways-proxy está pronto para atender a novas solicitações de conexão quando o seguinte registro é gravado:

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

O pathways-rm está pronto para atender a novas solicitações de conexão quando o seguinte registro é gravado:

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 se todas as TPUs registradas no Resource Manager do Pathways estão prontas, procure ***<num slices>/<num slices> Pathways Slices Now Ready *** nos registros do contêiner 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 ***

O cliente do programa de aprendizado pode fazer conexões com o servidor proxy do IFRT desde que ele esteja pronto, mesmo que nem todas as partes estejam. Seu job funciona com slices virtuais até que o slice fique pronto. As frações virtuais permitem que seu código seja executado quando as TPUs não estão disponíveis.

O pathways-worker está pronto para atender a novas solicitações de conexão quando o seguinte registro é gravado:

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

Coleta de métricas

Os programas podem 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 DCN
• Latência coletiva
• Latência de transferência de host para dispositivo
• Latência de transferência de dispositivo para host

É possível encontrar as métricas no painel do Cloud Monitoring do projeto {gcp_name} em que o cluster do GKE está sendo executado.

Para monitorar essas métricas no Metrics Explorer:

1. Acesse o Metrics Explorer
2. Filtre pelo nome da métrica usando o campo Selecionar uma métrica.
3. Filtre pelo nome da sua carga de trabalho e pelo período selecionando Adicionar filtro e pod_name.
4. Escolha um tipo de agregação adequado com base na métrica e nas cargas de trabalho que você está monitorando.

Latência de transferência da DCN

Essa é uma métrica de XLA em megascala (MXLA, na sigla em inglês) que mede a distribuição cumulativa de latências de transferência de rede para tráfego multislice. A medição da latência começa quando uma solicitação de dados a serem transferidos pela DCN é emitida e termina quando um reconhecimento é recebido 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 é uma métrica do MXLA que 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 uma solicitação de uma operação coletiva é emitida e termina quando um reconhecimento é recebido de que a transferência de dados foi concluída. Para monitorar essa métrica, filtre pelo nome collective_e2e_latency.

Latência de transferência de host para dispositivo

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

Latência de transferência de dispositivo para host

Essa é uma métrica do MXLA que mede a distribuição cumulativa das latências de transferência de dispositivo para host no tráfego multislice. A medição da latência começa quando uma solicitação de transferência de dados pela DCN é emitida e termina quando um reconhecimento de que a transferência de dados foi concluída é recebido. Para monitorar essa métrica, filtre pelo nome device_to_host_transfer_latencies.

Como depurar erros comuns

Não foi possível fazer 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ê encontrar o seguinte erro, verifique se a conta de serviço do Compute Engine usada pelo Vertex AI Workbench tem permissões para gravar entradas de registro no sistema de geração de registros 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 corrigir esse problema, adicione o papel Gravador de registros à conta de serviço do Compute Engine.

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

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

• Verificar se a rede VPC está configurada corretamente
• Verifique se o firewall está configurado para permitir a conexão.
• Verifique se o cluster do programa de aprendizado foi provisionado
• Verificar mensagens de erro de inicialização

Quando o primeiro comando JAX que envia um comando IFRT ao cluster do Pathways tentar ser executado, ele vai parar de responder por cerca de um minuto e mostrar um RuntimeError como este:

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)

Já existe uma conexão com o cluster do programa de aprendizado

Um cluster do Pathways só pode manter uma sessão com um cliente por vez. Se dois notebooks separados tentarem se conectar ao mesmo cluster do programa, um deles vai conseguir se conectar, e o outro vai mostrar 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)

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

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

Se você encontrar esse erro depois de importar pathwaysutils, verifique se há versões desatualizadas do Flask ou do Werkzeug instaladas no seu ambiente:

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

Se Flask ou Werkzeug estiverem listados, considere fazer upgrade deles, mas saiba que isso pode quebrar outros pacotes ou dependências no seu projeto:

 pip install flask Werkzeug --upgrade ()

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 se desconectou do cliente. Para corrigir isso, reinicie o cliente. Para notebooks, é possível reiniciar o kernel e executar o notebook novamente.

SIGTERMS e HBM OOM

Um SIGTERM encontrado nos registros associados a um erro RESOURCE_EXHAUSTED pode indicar um OOM de HBM. Nesse caso, é possível reduzir a quantidade de memória HBM usada no 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 ocorre se o bucket do Cloud Storage transmitido à flag --pathways_gcs_location atingiu o limite máximo da política de ciclo de vida. Se isso acontecer, limpe as políticas de ciclo de vida do Cloud Storage que não estão mais em uso.

Erro permanente

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

Esse erro é impresso nos workers do Resource Manager ou do Pathways quando você fornece um local inválido do Cloud Storage para contêineres de programas de aprendizado.

Resposta de erro do daemon

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

Isso ocorre devido a uma versão antiga do Docker. Faça upgrade da versão.

Falha na concordância entre o cliente e o servidor proxy do IFRT

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

Isso indica que uma versão mais antiga do MaxText está sendo usada. Recompile a imagem mais recente do MaxText.

A seguir

• Inferência com vários hosts usando o Pathways
• Cargas de trabalho em lote com os programas
• Modo interativo dos programas
• Como migrar cargas de trabalho do JAX para o Pathways
• Treinamento resiliente com programas de aprendizado