Memecahkan masalah Pathways on Cloud

Halaman ini membantu engineer machine learning (ML) dan administrator platform mendiagnosis dan menyelesaikan masalah terkait workload Pathways di Google Cloud. Gunakan panduan ini untuk memeriksa log komponen, memverifikasi kesiapan cluster dan slice, memantau metrik transfer Megascale XLA (MXLA), dan memperbaiki error runtime umum. Di setiap bagian, pilih tab GKE atau Cluster Director untuk lingkungan Anda.

Sebelum memulai

Sebelum memulai

GKE

Selesaikan prasyarat berikut sebelum melanjutkan:

Cluster Director

Selesaikan prasyarat berikut sebelum melanjutkan:

Melihat log

GKE

Anda dapat melihat log untuk workload Pathways secara langsung menggunakan perintah gcluster job logs (teruskan --main-only=false untuk menyertakan log pod worker):

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

Ganti kode berikut:

  • WORKLOAD_NAME: nama workload Anda saat menggunakan Cluster Toolkit, atau nama JobSet saat Anda menggunakan kubectl.
  • CLUSTER: nama cluster GKE Anda.
  • PROJECT_ID:Google Cloud project ID Anda.
  • LOCATION: region atau zona tempat Anda membuat cluster GKE.

Untuk mencantumkan semua pod untuk workload Anda menggunakan kubectl, filter berdasarkan label nama JobSet:

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

Untuk memeriksa status workload atau mencantumkan tugas yang gagal, gunakan perintah gcluster job list:

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

Atau, di Logs Explorer Cloud Logging, jalankan kueri berikut yang disesuaikan untuk project, lokasi, cluster, dan workload Anda:

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"

Kueri ini cocok dengan beberapa container Kubernetes Pathways dengan nama seperti pathways-rm, pathways-proxy, pathways-worker, dan workload-container. Untuk menentukan container mana yang menyebabkan masalah, tambahkan filter nama container seperti resource.labels.container_name:"CONTAINER_NAME", dengan CONTAINER_NAME adalah nama container.

Cluster Director

Skrip Pathways menulis log ke sistem file bersama:

  • Tugas layanan Pathways menulis pathways-service-SERVICE_JOB_ID.out dan pathways-service-SERVICE_JOB_ID.err di direktori tempat Anda menjalankan sbatch, misalnya, ~/pathways.
  • Resource manager Pathways, server proxy IFRT, dan TPU worker menulis ke ~/pathways/service_SERVICE_JOB_ID/logs, termasuk rm.log, proxy.log, serta satu file slice-*.out dan slice-*.err per tugas worker.
  • Contoh workload MaxText menulis lognya ke maxtext-llama31-JOB_ID.err.

Ganti kode berikut:

  • SERVICE_JOB_ID: ID pekerjaan Slurm dari tugas layanan Pathways, yang dicetak oleh sbatch start_pathways.sh.
  • JOB_ID: ID pekerjaan Slurm dari tugas MaxText, yang dicetak oleh sbatch run_maxtext.sh.

Di node login, periksa status tugas Pathways dan temukan ID tugasnya:

squeue -u ${USER}

Memantau komponen dan metrik Pathways

Bagian berikut berlaku untuk Pathways di GKE.

Pemantauan kesehatan

Anda dapat memantau kondisi berbagai komponen Pathways dengan mencari entri di log container.

Container pathways-proxy siap melayani permintaan koneksi baru saat menulis entri log berikut. Untuk melihat log, jalankan perintah berikut:

kubectl logs HEAD_POD_NAME --container pathways-proxy

Ganti HEAD_POD_NAME dengan nama pod head Pathways.

Output-nya mencakup baris yang mirip dengan berikut ini:

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

Container pathways-rm siap melayani permintaan koneksi baru saat menulis entri log berikut:

kubectl logs HEAD_POD_NAME --container pathways-rm

Output-nya mencakup baris yang mirip dengan berikut ini:

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

POD_IP adalah alamat IP pod, yang dapat berubah saat pod dimulai ulang atau dijadwalkan ulang.

Untuk memastikan bahwa semua slice TPU sudah siap, periksa log container pathways-rm untuk Pathways Slices Now Ready:

kubectl logs HEAD_POD_NAME --container pathways-rm

Misalnya, entri log berikut menunjukkan bahwa 2 dari 2 slice sudah siap:

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

Klien Pathways dapat terhubung ke server proxy IFRT segera setelah server proxy siap, meskipun tidak semua slice siap. Tugas Anda akan berfungsi dengan slice virtual hingga slice TPU siap. Slice virtual memungkinkan kode Anda berjalan saat TPU tidak tersedia.

Untuk memverifikasi bahwa container pathways-worker sudah siap, periksa log-nya:

kubectl logs WORKER_POD_NAME --container pathways-worker

Ganti WORKER_POD_NAME dengan nama pod worker Pathways.

Jika worker sudah siap, output-nya akan menyertakan baris yang mirip dengan berikut ini:

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

POD_IP adalah alamat IP pod, yang dapat berubah saat pod dimulai ulang atau dijadwalkan ulang.

Pengumpulan metrik

Pathways dapat menulis metrik sistem tingkat rendah ke Cloud Monitoring untuk proses debug. Metrik ini mencakup:

  • Latensi transfer jaringan pusat data (DCN)
  • Latensi kolektif
  • Latensi transfer host-ke-perangkat
  • Latensi transfer perangkat ke host

Anda dapat menemukan metrik di dasbor Monitoring pada projectGoogle Cloud tempat cluster GKE berjalan.

Untuk memantau metrik ini di Metrics Explorer, ikuti langkah-langkah berikut:

  1. Di konsol Google Cloud , buka halaman Metrics Explorer.
  2. Di kolom Select a metric, filter menurut nama metrik.
  3. Untuk memfilter menurut nama workload dan rentang waktu, klik Add filter, lalu filter menurut pod_name.
  4. Untuk Aggregation, pilih jenis agregasi berdasarkan metrik dan workload yang Anda pantau.

Latensi transfer DCN

Metrik Megascale XLA (MXLA) ini mengukur distribusi kumulatif latensi transfer jaringan untuk traffic multislice. Pengukuran latensi dimulai saat sistem mengeluarkan permintaan untuk mentransfer data melalui DCN dan berakhir saat sistem menerima konfirmasi bahwa transfer data telah selesai. Untuk memantau metrik ini, filter menurut nama metrik dcn_transfer_latencies.

Latensi kolektif

Metrik MXLA ini mengukur distribusi kumulatif latensi kolektif menyeluruh untuk traffic multislice. Pengukuran latensi dimulai saat sistem mengeluarkan permintaan untuk operasi kolektif dan berakhir saat sistem menerima konfirmasi bahwa transfer data telah selesai. Untuk memantau metrik ini, filter menurut nama metrik collective_end_to_end_latencies.

Latensi transfer host-ke-perangkat

Metrik MXLA ini mengukur distribusi kumulatif latensi transfer host-ke-perangkat untuk traffic multislice. Pengukuran latensi dimulai saat sistem mengeluarkan permintaan untuk mentransfer data dari host ke perangkat TPU dan berakhir saat sistem menerima konfirmasi bahwa transfer data telah selesai. Untuk memantau metrik ini, filter menurut nama metrik host_to_device_transfer_latencies.

Latensi transfer perangkat ke host

Metrik MXLA ini mengukur distribusi kumulatif latensi transfer perangkat ke host untuk traffic multislice. Pengukuran latensi dimulai saat sistem mengeluarkan permintaan untuk mentransfer data dari perangkat TPU ke host dan berakhir saat sistem menerima konfirmasi bahwa transfer data telah selesai. Untuk memantau metrik ini, filter menurut nama metrik device_to_host_transfer_latencies.

Men-debug error umum

GKE

Tidak dapat melakukan hashing pada peringatan konfigurasi akselerator

Pesan berikut hanyalah peringatan dan tidak memengaruhi performa kode JAX Anda:

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'>)

Izin logging.logEntries.create ditolak pada resource

Jika Anda melihat error berikut, pastikan akun layanan Compute Engine yang digunakan oleh Vertex AI Workbench memiliki izin untuk menulis entri log ke 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)."}"
>

Untuk memperbaiki masalah ini, berikan peran Logs Writer (roles/logging.logWriter) ke akun layanan Compute Engine.

Tidak dapat terhubung ke server proxy IFRT

Saat perintah JAX pertama Anda yang mengirim perintah IFRT ke cluster Pathways mencoba berjalan, perintah tersebut mungkin berhenti merespons selama sekitar satu menit, lalu menampilkan RuntimeError yang mirip dengan berikut ini:

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)

Jika Anda melihat error ini, klien proxy IFRT Anda tidak dapat terhubung ke server proxy IFRT. Periksa hal-hal berikut:

  • Pastikan Anda telah mengonfigurasi jaringan Virtual Private Cloud (VPC) dengan benar.
  • Pastikan aturan firewall Anda mengizinkan koneksi.
  • Pastikan cluster Pathways Anda telah disediakan.
  • Periksa pesan error startup di log container.

Handshake ALTS gagal atau soket ditutup saat terhubung ke server proxy IFRT

Anda mungkin melihat Alts handshake failed (TSI_INTERNAL_ERROR) atau UNAVAILABLE: Unable to establish connection to ifrt_proxy server ... Socket closed saat menjalankan manifes kustom tanpa kolom hostNetwork: true di node pool Workload Identity Federation for GKE. Untuk mengatasi masalah ini, tetapkan variabel lingkungan IFRT_PROXY_USE_INSECURE_GRPC_CREDENTIALS: "true" pada container pathways-proxy dan container klien JAX (kedua sisi harus cocok). Menambahkan variabel lingkungan ini akan menonaktifkan ALTS dan menggunakan gRPC yang tidak aman, jadi gunakan hanya dalam jaringan cluster tepercaya.

Ada koneksi yang sudah ada ke cluster Pathways

Cluster Pathways dapat mempertahankan sesi hanya dengan satu klien dalam satu waktu. Jika dua notebook terpisah mencoba terhubung ke cluster Pathways yang sama, satu notebook akan terhubung dan notebook lainnya akan menampilkan error berikut:

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)

Setelah klien asli terputus, klien kedua dapat terhubung. Setelah terjadi pemutusan koneksi yang tidak terduga, Anda mungkin perlu memulai ulang cluster Pathways agar klien lain dapat terhubung.

LocalProxy.__init__() mendapatkan argumen kata kunci yang tidak diharapkan 'unbound_message'

Jika Anda melihat error berikut setelah mengimpor pathwaysutils, periksa apakah versi Flask atau Werkzeug yang sudah tidak berlaku diinstal di lingkungan Anda (ganti pip3 dengan pip jika diperlukan):

pip3 list --outdated

Jika Flask atau Werkzeug tercantum, upgrade paket (perhatikan bahwa upgrade dapat memengaruhi paket atau dependensi lain dalam project Anda):

pip3 install --upgrade flask Werkzeug

Error internal dari server proxy

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

Error ini menunjukkan bahwa server proxy IFRT terputus dari klien. Untuk memperbaiki masalah ini, mulai ulang klien Anda. Untuk notebook, mulai ulang kernel notebook dan jalankan ulang notebook Anda.

SIGTERM dan OOM HBM

Entri SIGTERM dalam log yang terkait dengan error RESOURCE_EXHAUSTED mungkin menunjukkan error kehabisan memori (OOM) pada memori bandwidth tinggi (HBM). Dalam hal ini, kurangi jumlah HBM yang digunakan kode JAX Anda.

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"

Error ini terjadi jika bucket Cloud Storage yang diteruskan ke flag --pathways-gcs-location telah mencapai batas kebijakan siklus proses maksimum (50 awalan). Untuk mengatasi masalah ini, hapus kebijakan siklus proses Cloud Storage yang tidak lagi Anda gunakan.

Error permanen

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

Resource manager Pathways atau worker Pathways mencetak error ini saat Anda memberikan lokasi Cloud Storage yang tidak valid ke container Pathways.

Respons error dari daemon

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

Error ini terjadi saat Anda menggunakan Docker versi lama. Upgrade versi Docker Anda.

Klien dan server proxy IFRT gagal menyetujui

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

Error ini menunjukkan bahwa Anda menggunakan MaxText versi lama. Bangun ulang image MaxText terbaru.

Cluster Director

setup_env.sh gagal dengan error Enroot mktemp

Jika setup_env.sh gagal dengan error berikut, direktori sementara Enroot tidak ada:

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

Untuk memperbaiki masalah ini, jalankan mkdir -p /tmp/$(id -u)/tmp, lalu jalankan skrip lagi.

setup_env.sh tidak dapat mengambil image Pathways

Jika setup_env.sh gagal dengan Couldn't pull ..., tidak ada gambar Pathways yang diberi tag untuk JAX_VERSION yang diminta. Gunakan versi JAX yang didukung.

Cluster tidak memiliki partisi cpu

Jika sinfo tidak menampilkan partisi cpu, definisi cluster tidak memiliki nodeset CPU atau menamai partisinya secara berbeda. Skrip Pathways mengirimkan tugas ke partisi bernama cpu. Untuk memperbaiki masalah ini, perbarui blueprint cluster Anda untuk menentukan partisi CPU bernama cpu dan deploy ulang cluster, atau perbarui nama partisi dalam skrip tugas Pathways agar cocok dengan partisi CPU yang ditampilkan oleh sinfo.

Node TPU tidak muncul

Pastikan pemesanan berada di zona cluster dan memiliki VM ct6e-standard-4t yang cukup, serta staticNodeCount dan acceleratorTopology cocok.

Layanan Pathways keluar dengan Invalid partition name specified

Variabel PARTITION salah. Pilih partisi TPU dari output sinfo.

Layanan Pathways tidak siap

Jika log layanan tetap di Waiting for at least MIN_SLICES=..., berarti tidak cukup slice yang berjalan. Kolom NODELIST(REASON) dari perintah berikut menunjukkan alasannya, misalnya, tidak ada kapasitas yang tersedia atau nilai SLICE_SHAPE yang tidak cocok dengan TPU nodeset:

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

Pengelola resource Pathways atau server proxy IFRT tidak dimulai

Jika layanan gagal dengan Timed out waiting for Pathways Resource Manager atau Timed out waiting for Pathways IFRT Proxy Server, container Pathways tidak dimulai. Periksa rm.log dan proxy.log di direktori log.

Layanan Pathways berhenti secara tidak terduga

Jika layanan berhenti dengan The Pathways Resource Manager or IFRT proxy exited, salah satunya mengalami error, dan layanan menghentikan worker-nya. Periksa rm.log dan proxy.log di direktori log, lalu mulai layanan lagi.

TPU node macet dalam status buruk

Untuk memulihkan node, jalankan perintah berikut di node login:

sudo scontrol update nodename=NODE \
    state=power_down_force

Ganti NODE dengan nama node, seperti yang ditunjukkan oleh sinfo.

MaxText tidak dapat menemukan layanan Pathways yang berjalan

Jika MaxText gagal dengan No running Pathways service after 60 minutes, layanan tidak berjalan atau belum siap. Periksa log layanan. Untuk menunggu lebih lama, tetapkan SERVICE_WAIT_MINUTES saat Anda mengirimkan run_maxtext.sh.

MaxText gagal dengan RESOURCE_EXHAUSTED

Model tidak muat dalam memori TPU. Gunakan slice 2x4 atau 4x4, atau tetapkan REDUCED_LAYERS=1.

Tugas MaxText tetap tertunda

Node CPU tidak memiliki 8 CPU dan memori 160 GB yang diminta run_maxtext.sh, selain 4 CPU dan memori 80 GB yang digunakan layanan Pathways. Kedua tugas tersebut cocok di node n2-highmem-32. Untuk memperbaiki masalah ini, tingkatkan kapasitas CPU dan memori (atau jumlah node) di partisi cpu, atau kurangi permintaan resource di run_maxtext.sh.

Tidak dapat terhubung ke server proxy IFRT

Jika klien berhenti merespons atau gagal dengan UNAVAILABLE, klien tidak dapat menjangkau server proxy:

  • Pastikan log layanan menampilkan READY.
  • Pastikan JAX_BACKEND_TARGET cocok dengan alamat di ~/pathways/cluster.env.
  • Jika Anda menggunakan penerusan port, pastikan tunnel SSH masih berjalan.

  • Jika klien berjalan di VM, pastikan VM berada di subnet cluster. Perintah berikut akan berhasil:

    nc -zv PROXY_IP 29000

    Ganti PROXY_IP dengan alamat IP proxy IFRT dari log layanan.

jax.devices() mencantumkan perangkat CPU, bukan perangkat TPU

Anda menetapkan variabel lingkungan JAX_PLATFORMS dan JAX_BACKEND_TARGET setelah mengimpor jax. Mulai ulang kernel notebook, dan tetapkan variabel sebelum Anda mengimpor jax.

Error tepat setelah terhubung ke server proxy IFRT

Versi jax atau pathwaysutils klien tidak cocok dengan server Pathways. Instal versi di ~/pathways/venv.

Komputasi gagal dengan DATA_LOSS dan PlacementDataLoss

Komputasi menggunakan perangkat pada slice yang tidak berjalan—misalnya, karena slice di-preempt. Server proxy IFRT tetap terhubung saat Slurm mengantrekan ulang slice. Periksa apakah setiap tugas worker berjalan, dan jalankan komputasi lagi setelah slice kembali:

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

Komputasi gagal setelah preemption Spot

Komputasi yang menggunakan perangkat slice yang di-preempt akan gagal. Untuk memulihkan dari preemption Spot secara otomatis, konfigurasikan pembuatan checkpoint dan penskalaan ulang slice elastis seperti yang dijelaskan dalam Pelatihan tangguh dengan Pathways.

Langkah berikutnya