Pathways on Cloud 문제 해결

이 페이지는 머신러닝(ML) 엔지니어와 플랫폼 관리자가 Google Cloud에서 Pathways 워크로드 관련 문제를 진단하고 해결하는 데 도움이 됩니다. 이 가이드를 사용하여 구성요소 로그를 검사하고, 클러스터 및 슬라이스 준비 상태를 확인하고, Megascale XLA(MXLA) 전송 측정항목을 모니터링하고, 일반적인 런타임 오류를 해결하세요. 각 섹션에서 환경에 맞는 GKE 또는 Cluster Director 탭을 선택합니다.

시작하기 전에

시작하기 전에

GKE

계속하기 전에 다음 기본 요건을 완료하세요.

Cluster Director

계속하기 전에 다음 기본 요건을 완료하세요.

로그 보기

GKE

gcluster job logs 명령어를 사용하여 Pathways 워크로드의 로그를 직접 볼 수 있습니다(워커 포드 로그를 포함하려면 --main-only=false 전달).

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

다음을 바꿉니다.

  • WORKLOAD_NAME: Cluster Toolkit을 사용할 때의 워크로드 이름 또는 kubectl을 사용할 때의 JobSet 이름입니다.
  • CLUSTER: GKE 클러스터의 이름입니다.
  • PROJECT_ID:Google Cloud 프로젝트 ID입니다.
  • LOCATION: GKE 클러스터를 만든 리전 또는 영역입니다.

kubectl를 사용하여 워크로드의 모든 포드를 나열하려면 JobSet 이름 라벨로 필터링합니다.

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

워크로드 상태를 확인하거나 실패한 작업을 나열하려면 gcluster job list 명령어를 사용합니다.

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

또는 Cloud Logging 로그 탐색기에서 프로젝트, 위치, 클러스터, 워크로드에 맞게 조정된 다음 쿼리를 실행합니다.

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"

이 쿼리는 pathways-rm, pathways-proxy, pathways-worker, workload-container와 같은 이름의 여러 Pathways Kubernetes 컨테이너와 일치합니다. 문제를 일으키는 컨테이너를 확인하려면 resource.labels.container_name:"CONTAINER_NAME"와 같은 컨테이너 이름 필터를 추가합니다. 여기서 CONTAINER_NAME는 컨테이너 이름입니다.

Cluster Director

Pathways 스크립트는 공유 파일 시스템에 로그를 작성합니다.

  • Pathways 서비스 작업은 sbatch를 실행한 디렉터리(예: ~/pathways)에 pathways-service-SERVICE_JOB_ID.out 및 pathways-service-SERVICE_JOB_ID.err를 작성합니다.
  • Pathways 리소스 관리자, IFRT 프록시 서버, TPU 워커는 rm.log, proxy.log, 워커 태스크당 slice-*.out 및 slice-*.err 파일 하나를 포함하여 ~/pathways/service_SERVICE_JOB_ID/logs에 씁니다.
  • 예시 MaxText 워크로드는 로그를 maxtext-llama31-JOB_ID.err에 기록합니다.

다음을 바꿉니다.

  • SERVICE_JOB_ID: sbatch start_pathways.sh가 출력하는 Pathways 서비스 작업의 Slurm 작업 ID입니다.
  • JOB_ID: MaxText 작업의 Slurm 작업 ID(sbatch run_maxtext.sh가 출력함)

로그인 노드에서 Pathways 작업의 상태를 확인하고 작업 ID를 찾습니다.

squeue -u ${USER}

Pathways 구성요소 및 측정항목 모니터링

다음 섹션은 GKE의 Pathways에 적용됩니다.

상태 모니터링

컨테이너 로그에서 항목을 찾아 다양한 Pathways 구성요소의 상태를 모니터링할 수 있습니다.

pathways-proxy 컨테이너는 다음 로그 항목을 작성할 때 새 연결 요청을 처리할 준비가 됩니다. 로그를 보려면 다음 명령어를 실행합니다.

kubectl logs HEAD_POD_NAME --container pathways-proxy

HEAD_POD_NAME을 Pathways 헤드 포드의 이름으로 바꿉니다.

출력에 다음과 비슷한 줄이 포함됩니다.

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

pathways-rm 컨테이너는 다음 로그 항목을 작성할 때 새 연결 요청을 처리할 준비가 됩니다.

kubectl logs HEAD_POD_NAME --container pathways-rm

출력에 다음과 비슷한 줄이 포함됩니다.

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

POD_IP은 포드의 IP 주소이며, 포드가 다시 시작되거나 일정이 변경될 때 변경될 수 있습니다.

모든 TPU 슬라이스가 준비되었는지 확인하려면 pathways-rm 컨테이너 로그에서 Pathways Slices Now Ready를 확인합니다.

kubectl logs HEAD_POD_NAME --container pathways-rm

예를 들어 다음 로그 항목은 슬라이스 2개 중 2개가 준비되었음을 보여줍니다.

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

Pathways 클라이언트는 모든 슬라이스가 준비되지 않았더라도 프록시 서버가 준비되는 즉시 IFRT 프록시 서버에 연결할 수 있습니다. TPU 슬라이스가 준비될 때까지 작업이 가상 슬라이스에서 작동합니다. 가상 슬라이스를 사용하면 TPU를 사용할 수 없을 때 코드를 실행할 수 있습니다.

pathways-worker 컨테이너가 준비되었는지 확인하려면 로그를 확인합니다.

kubectl logs WORKER_POD_NAME --container pathways-worker

WORKER_POD_NAME을 Pathways 워커 포드 이름으로 바꿉니다.

작업자가 준비되면 출력에 다음과 비슷한 줄이 포함됩니다.

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

POD_IP은 포드의 IP 주소이며, 포드가 다시 시작되거나 일정이 변경될 때 변경될 수 있습니다.

측정항목 수집

Pathways는 디버깅을 위해 하위 수준 시스템 측정항목을 Cloud Monitoring에 기록할 수 있습니다. 측정항목에는 다음이 포함됩니다.

  • 데이터 센터 네트워크(DCN) 전송 지연 시간
  • 집합적 지연 시간
  • 호스트-기기 전송 지연 시간
  • 기기-호스트 전송 지연 시간

GKE 클러스터가 실행 중인Google Cloud 프로젝트의 Monitoring 대시보드에서 측정항목을 찾을 수 있습니다.

측정항목 탐색기에서 이러한 측정항목을 모니터링하려면 다음 단계를 따르세요.

  1. Google Cloud 콘솔에서 측정항목 탐색기 페이지로 이동합니다.
  2. 측정항목 선택 필드에서 측정항목 이름으로 필터링합니다.
  3. 워크로드 이름 및 기간으로 필터링하려면 필터 추가를 클릭한 후 pod_name로 필터링합니다.
  4. 집계에서 모니터링하는 측정항목 및 워크로드를 기반으로 집계 유형을 선택합니다.

DCN 전송 지연 시간

이 Megascale XLA(MXLA) 측정항목은 멀티슬라이스 트래픽에 대한 네트워크 전송 지연 시간의 누적 분포를 측정합니다. 지연 시간 측정은 시스템이 DCN을 통해 데이터를 전송하라는 요청을 발행할 때 시작되고 데이터 전송이 완료되었다는 확인을 수신할 때 종료됩니다. 이 측정항목을 모니터링하려면 dcn_transfer_latencies 측정항목 이름으로 필터링합니다.

집합적 지연 시간

이 MXLA 측정항목은 멀티슬라이스 트래픽의 엔드 투 엔드 집합 지연 시간의 누적 분포를 측정합니다. 지연 시간 측정은 시스템이 수집 작업 요청을 실행할 때 시작되고 데이터 전송이 완료되었다는 확인을 수신할 때 종료됩니다. 이 측정항목을 모니터링하려면 collective_end_to_end_latencies 측정항목 이름으로 필터링합니다.

호스트-기기 전송 지연 시간

이 MXLA 측정항목은 멀티슬라이스 트래픽의 호스트-기기 전송 지연 시간의 누적 분포를 측정합니다. 지연 시간 측정은 시스템이 호스트에서 TPU 기기로 데이터를 전송하라는 요청을 발행할 때 시작되고 데이터 전송이 완료되었다는 확인을 수신할 때 종료됩니다. 이 측정항목을 모니터링하려면 host_to_device_transfer_latencies 측정항목 이름으로 필터링합니다.

기기-호스트 전송 지연 시간

이 MXLA 측정항목은 멀티슬라이스 트래픽의 기기-호스트 전송 지연 시간의 누적 분포를 측정합니다. 지연 시간 측정은 시스템이 TPU 기기에서 호스트로 데이터를 전송하라는 요청을 발행할 때 시작되고 데이터 전송이 완료되었다는 확인을 수신할 때 종료됩니다. 이 측정항목을 모니터링하려면 device_to_host_transfer_latencies 측정항목 이름으로 필터링합니다.

일반적인 오류 디버그

GKE

가속기 구성 경고를 해싱할 수 없음

다음 메시지는 경고일 뿐이며 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'>)

리소스에 대한 logging.logEntries.create 권한이 거부됨

다음 오류가 표시되면 Vertex AI Workbench에서 사용하는 Compute Engine 서비스 계정에 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)."}"
>

이 문제를 해결하려면 Compute Engine 서비스 계정에 로그 작성자(roles/logging.logWriter) 역할을 부여합니다.

IFRT 프록시 서버에 연결할 수 없음

IFRT 명령어를 Pathways 클러스터로 전송하는 첫 번째 JAX 명령어가 실행을 시도하면 약 1분 동안 응답이 중지된 후 다음과 유사한 RuntimeError가 표시될 수 있습니다.

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)

이 오류가 표시되면 IFRT 프록시 클라이언트가 IFRT 프록시 서버에 연결할 수 없는 것입니다. 다음을 확인하세요.

  • Virtual Private Cloud(VPC) 네트워크가 올바르게 구성되었는지 확인합니다.
  • 방화벽 규칙이 연결을 허용하는지 확인합니다.
  • Pathways 클러스터가 프로비저닝되었는지 확인합니다.
  • 컨테이너 로그에서 시작 오류 메시지를 확인합니다.

IFRT 프록시 서버에 연결할 때 ALTS 핸드셰이크가 실패하거나 소켓이 닫힘

GKE용 워크로드 아이덴티티 제휴 노드 풀에서 hostNetwork: true 필드 없이 커스텀 매니페스트를 실행하면 Alts handshake failed (TSI_INTERNAL_ERROR) 또는 UNAVAILABLE: Unable to establish connection to ifrt_proxy server ... Socket closed가 표시될 수 있습니다. 이 문제를 해결하려면 pathways-proxy 컨테이너와 JAX 클라이언트 컨테이너 모두에서 IFRT_PROXY_USE_INSECURE_GRPC_CREDENTIALS: "true" 환경 변수를 설정합니다(양쪽이 일치해야 함). 이 환경 변수를 추가하면 ALTS가 사용 중지되고 대신 안전하지 않은 gRPC가 사용되므로 신뢰할 수 있는 클러스터 네트워크 내에서만 사용하세요.

Pathways 클러스터에 대한 기존 연결이 있음

Pathways 클러스터는 한 번에 하나의 클라이언트와만 세션을 유지할 수 있습니다. 두 개의 개별 노트북이 동일한 Pathways 클러스터에 연결하려고 하면 하나는 연결되고 다른 하나는 다음 오류를 표시합니다.

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)

원래 클라이언트의 연결이 끊어지면 두 번째 클라이언트가 연결할 수 있습니다. 예기치 않은 연결 해제 후 다른 클라이언트가 연결할 수 있도록 Pathways 클러스터를 다시 시작해야 할 수 있습니다.

LocalProxy.__init__()에 예기치 않은 키워드 인수 'unbound_message'가 있습니다.

pathwaysutils를 가져온 후 다음 오류가 표시되면 환경에 오래된 버전의 Flask 또는 Werkzeug가 설치되어 있는지 확인합니다(필요한 경우 pip3를 pip로 바꿈).

pip3 list --outdated

Flask 또는 Werkzeug가 나열되면 패키지를 업그레이드합니다. 업그레이드하면 프로젝트의 다른 패키지나 종속 항목에 영향을 줄 수 있습니다.

pip3 install --upgrade flask Werkzeug

프록시 서버의 내부 오류

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

이 오류는 IFRT 프록시 서버가 클라이언트에서 연결 해제되었음을 나타냅니다. 이 문제를 해결하려면 클라이언트를 다시 시작하세요. 노트북의 경우 노트북 커널을 다시 시작하고 노트북을 다시 실행합니다.

SIGTERM 및 HBM OOM

RESOURCE_EXHAUSTED 오류와 연결된 로그의 SIGTERM 항목은 고대역폭 메모리(HBM) 메모리 부족(OOM) 오류를 나타낼 수 있습니다. 이 경우 JAX 코드에서 사용하는 HBM 양을 줄입니다.

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"

이 오류는 --pathways-gcs-location 플래그에 전달된 Cloud Storage 버킷이 최대 수명 주기 정책 한도(프리픽스 50개)에 도달한 경우 발생합니다. 이 문제를 해결하려면 더 이상 사용하지 않는 Cloud Storage 수명 주기 정책을 삭제하세요.

영구 오류

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

Pathways 컨테이너에 잘못된 Cloud Storage 위치를 제공하면 Pathways 리소스 관리자 또는 Pathways 작업자가 이 오류를 출력합니다.

데몬의 오류 응답

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

이 오류는 이전 버전의 Docker를 사용할 때 발생합니다. Docker 버전을 업그레이드합니다.

IFRT 프록시 클라이언트와 서버가 동의하지 않음

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

이 오류는 이전 버전의 MaxText를 사용하고 있음을 나타냅니다. 최신 MaxText 이미지를 다시 빌드합니다.

Cluster Director

setup_env.sh가 Enroot mktemp 오류와 함께 실패함

setup_env.sh가 다음 오류와 함께 실패하면 Enroot의 임시 디렉터리가 존재하지 않는 것입니다.

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

이 문제를 해결하려면 mkdir -p /tmp/$(id -u)/tmp를 실행한 후 스크립트를 다시 실행합니다.

setup_env.sh에서 Pathways 이미지를 가져올 수 없음

setup_env.sh가 Couldn't pull ...로 실패하면 요청된 JAX_VERSION에 Pathways 이미지가 태그되지 않습니다. 지원되는 JAX 버전을 사용합니다.

클러스터에 cpu 파티션이 없음

sinfo에 cpu 파티션이 표시되지 않으면 클러스터 정의에 CPU 노드 세트가 누락되었거나 파티션 이름이 다르게 지정된 것입니다. Pathways 스크립트는 cpu라는 파티션에 작업을 제출합니다. 이 문제를 해결하려면 클러스터 청사진을 업데이트하여 cpu라는 CPU 파티션을 정의하고 클러스터를 다시 배포하거나 Pathways 작업 스크립트의 파티션 이름을 sinfo에 표시된 CPU 파티션과 일치하도록 업데이트합니다.

TPU 노드가 표시되지 않음

예약이 클러스터 영역에 있고 ct6e-standard-4t VM이 충분하며 staticNodeCount 및 acceleratorTopology가 일치하는지 확인합니다.

Pathways 서비스가 Invalid partition name specified로 종료됨

PARTITION 변수가 잘못되었습니다. sinfo 출력에서 TPU 파티션을 선택합니다.

Pathways 서비스가 준비되지 않음

서비스 로그가 Waiting for at least MIN_SLICES=...에 머물러 있으면 실행 중인 슬라이스가 충분하지 않은 것입니다. 다음 명령어의 NODELIST(REASON) 열에는 사용 가능한 용량이 없거나 TPU 노드 세트와 일치하지 않는 SLICE_SHAPE 값과 같은 이유가 표시됩니다.

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

Pathways 리소스 관리자 또는 IFRT 프록시 서버가 시작되지 않음

서비스가 Timed out waiting for Pathways Resource Manager 또는 Timed out waiting for Pathways IFRT Proxy Server로 실패하면 Pathways 컨테이너가 시작되지 않은 것입니다. 로그 디렉터리에서 rm.log 및 proxy.log를 확인합니다.

Pathways 서비스가 예기치 않게 중지됨

서비스가 The Pathways Resource Manager or IFRT proxy exited로 중지되면 그중 하나가 비정상 종료되고 서비스가 작업자를 중지한 것입니다. 로그 디렉터리에서 rm.log 및 proxy.log를 확인한 후 서비스를 다시 시작합니다.

TPU 노드가 비정상 상태에서 멈춤

노드를 복구하려면 로그인 노드에서 다음 명령어를 실행합니다.

sudo scontrol update nodename=NODE \
    state=power_down_force

NODE을 sinfo에 표시된 노드 이름으로 바꿉니다.

MaxText에서 실행 중인 Pathways 서비스를 찾을 수 없음

MaxText가 No running Pathways service after 60 minutes로 실패하면 서비스가 실행 중이 아니거나 아직 준비되지 않은 것입니다. 서비스 로그를 확인합니다. 더 오래 기다리려면 run_maxtext.sh를 제출할 때 SERVICE_WAIT_MINUTES를 설정합니다.

MaxText가 RESOURCE_EXHAUSTED와 함께 실패함

모델이 TPU 메모리에 맞지 않습니다. 2x4 또는 4x4 슬라이스를 사용하거나 REDUCED_LAYERS=1를 설정합니다.

MaxText 작업이 대기 중 상태로 유지됨

CPU 노드에는 Pathways 서비스에서 사용하는 CPU 4개와 메모리 80GB 외에 run_maxtext.sh에서 요청하는 CPU 8개와 메모리 160GB가 없습니다. 두 작업 모두 n2-highmem-32 노드에 적합합니다. 이 문제를 해결하려면 cpu 파티션에서 CPU 및 메모리 용량(또는 노드 수)을 늘리거나 run_maxtext.sh에서 리소스 요청을 줄입니다.

IFRT 프록시 서버에 연결할 수 없음

클라이언트가 응답을 중지하거나 UNAVAILABLE로 실패하면 프록시 서버에 연결할 수 없습니다.

  • 서비스 로그에 READY가 표시되는지 확인합니다.
  • JAX_BACKEND_TARGET가 ~/pathways/cluster.env의 주소와 일치하는지 확인합니다.
  • 포트 전달을 사용하는 경우 SSH 터널이 계속 실행 중인지 확인합니다.

  • 클라이언트가 VM에서 실행되는 경우 VM이 클러스터의 서브넷에 있는지 확인합니다. 다음 명령어가 성공해야 합니다.

    nc -zv PROXY_IP 29000

    PROXY_IP를 서비스 로그의 IFRT 프록시 IP 주소로 바꿉니다.

jax.devices()가 TPU 기기 대신 CPU 기기를 나열함

jax를 가져온 후 JAX_PLATFORMS 및 JAX_BACKEND_TARGET 환경 변수를 설정했습니다. jax를 가져오기 전에 노트북 커널을 다시 시작하고 변수를 설정합니다.

IFRT 프록시 서버에 연결한 직후 오류 발생

클라이언트의 jax 또는 pathwaysutils 버전이 Pathways 서버와 일치하지 않습니다. ~/pathways/venv에 버전을 설치합니다.

DATA_LOSS 및 PlacementDataLoss로 인해 계산이 실패함

계산에서 실행되지 않는 슬라이스의 기기를 사용했습니다. 예를 들어 슬라이스가 선점되었기 때문입니다. Slurm이 슬라이스를 다시 큐에 추가하는 동안 IFRT 프록시 서버는 연결된 상태를 유지합니다. 모든 작업자 태스크가 실행 중인지 확인하고 슬라이스가 돌아온 후 계산을 다시 실행합니다.

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

Spot 선점 후 컴퓨팅 실패

선점된 슬라이스의 기기를 사용하는 계산이 실패합니다. 스팟 선점에서 자동으로 복구하려면 Pathways를 사용한 탄력적 학습에 설명된 대로 체크포인트 및 탄력적 슬라이스 재조정을 구성합니다.

다음 단계