פתרון בעיות בתוכניות הלימודים ב-Cloud

בדף הזה מוסבר למהנדסי למידת מכונה (ML) ולאדמינים של פלטפורמות איך לאבחן ולפתור בעיות בעומסי עבודה של Pathways ב- Google Cloud. במדריך הזה מוסבר איך לבדוק את יומני הרכיבים, לוודא שהאשכול והפרוסות מוכנים, לעקוב אחרי מדדי ההעברה של Megascale XLA‏ (MXLA) ולתקן שגיאות נפוצות בזמן הריצה. בכל חלק, בוחרים את הכרטיסייה GKE או Cluster Director בהתאם לסביבה שלכם.

לפני שמתחילים

  • צריך לבחור את הכרטיסייה הרלוונטית לאופן שבו תכננתם להשתמש בדוגמאות בדף הזה:

    gcloud

    מפעילים את Cloud Shell במסוף Google Cloud .

    הפעלת Cloud Shell

    בחלק התחתון של מסוף Google Cloud יתחיל סשן של Cloud Shell ותופיע הודעה של שורת הפקודה. Cloud Shell היא סביבת מעטפת שבה ה-CLI של Google Cloud מותקן ומוגדרים ערכים לפרויקט הקיים. הסשן יופעל תוך כמה שניות.

    REST

    כדי להשתמש בסביבת פיתוח מקומית בדוגמאות של API בארכיטקטורת REST שבדף הזה, צריך להשתמש בפרטי הכניסה שאתם נותנים ל-CLI של gcloud.

      התקינו את ה-CLI של Google Cloud.

      אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

    מידע נוסף מופיע במאמר אימות לשימוש ב-REST במסמכי האימות של Google Cloud .

לפני שמתחילים

GKE

לפני שממשיכים, צריך לבצע את הפעולות הבאות:

Cluster Director

לפני שממשיכים, צריך לבצע את הפעולות הבאות:

צפייה ביומנים

GKE

אתם יכולים להציג את היומנים של עומסי העבודה ב-Pathways ישירות באמצעות הפקודה gcluster job logs (כדי לכלול את היומנים של pod של ה-worker, מעבירים את --main-only=false):

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

מחליפים את מה שכתוב בשדות הבאים:

  • ‫WORKLOAD_NAME: שם עומס העבודה כשמשתמשים ב-Cluster Toolkit, או שם ה-JobSet כשמשתמשים ב-kubectl.
  • ‫CLUSTER: השם של אשכול GKE.
  • ‫PROJECT_ID: מזהה הפרויקט ב-Google Cloud .
  • ‫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

לחלופין, ב-Logs Explorer של 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 Kubernetes עם שמות כמו pathways-rm,‏ pathways-proxy,‏ pathways-worker ו-workload-container. כדי לזהות איזה קונטיינר גורם לבעיה, מוסיפים מסנן לשם הקונטיינר, למשל resource.labels.container_name:"CONTAINER_NAME", כאשר CONTAINER_NAME הוא שם הקונטיינר.

Cluster Director

הסקריפטים של Pathways כותבים יומנים למערכת הקבצים המשותפת:

  • המשימה של שירות Pathways כותבת את pathways-service-SERVICE_JOB_ID.out ואת pathways-service-SERVICE_JOB_ID.err בספרייה שבה הפעלתם את sbatch, לדוגמה ~/pathways.
  • מנהל המשאבים של Pathways, שרת ה-proxy של IFRT ו-TPU workers כותבים ב-~/pathways/service_SERVICE_JOB_ID/logs, כולל rm.log,‏ proxy.log וקובץ אחד של slice-*.out ו-slice-*.err לכל משימת worker.
  • עומס העבודה לדוגמה של MaxText כותב את היומן שלו ב-maxtext-llama31-JOB_ID.err.

מחליפים את מה שכתוב בשדות הבאים:

  • ‫SERVICE_JOB_ID: מזהה המשימה ב-Slurm של משימת השירות של Pathways, שמודפס על ידי sbatch start_pathways.sh.
  • ‫JOB_ID: מזהה המשימה של MaxText ב-Slurm, שמודפס על ידי sbatch run_maxtext.sh.

בצומת ההתחברות, בודקים את המצב של משימות Pathways ומוצאים את מזהי המשימות שלהן:

squeue -u ${USER}

מעקב אחרי הרכיבים והמדדים של Pathways

הקטעים הבאים רלוונטיים ל-Pathways ב-GKE.

מעקב אחר בריאות

כדי לעקוב אחרי התקינות של רכיבי Pathways השונים, אתם יכולים לחפש רשומות ביומני הקונטיינרים.

אחרי שהקונטיינר pathways-proxy כותב את רשומת היומן הבאה, הוא מוכן לטפל בבקשות חיבור חדשות. כדי לראות את היומנים, מריצים את הפקודה הבאה:

kubectl logs HEAD_POD_NAME --container pathways-proxy

מחליפים את HEAD_POD_NAME בשם של ה-head pod ב-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 של ה-Pod, שיכולה להשתנות כשה-Pod מופעל מחדש או מתוזמן מחדש.

כדי לוודא שכל פרוסות ה-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 יכול להתחבר לשרת ה-proxy של IFRT ברגע ששרת ה-proxy מוכן, גם אם לא כל הפרוסות מוכנות. המשימה פועלת עם פרוסות וירטואליות עד שפרוסות ה-TPU מוכנות. פרוסות וירטואליות מאפשרות להריץ את הקוד כשאין יחידות TPU זמינות.

כדי לוודא שמאגר pathways-worker מוכן, בודקים את היומנים שלו:

kubectl logs WORKER_POD_NAME --container pathways-worker

מחליפים את WORKER_POD_NAME בשם של pod של Pathways worker.

כשה-worker מוכן, הפלט כולל שורה דומה לזו:

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

‫POD_IP היא כתובת ה-IP של ה-Pod, שיכולה להשתנות כשה-Pod מופעל מחדש או מתוזמן מחדש.

אוסף מדדים

‫Pathways יכול לכתוב מדדי מערכת ברמה נמוכה ל-Cloud Monitoring לצורך ניפוי באגים. המדדים כוללים:

  • זמן האחזור של העברה ברשת של מרכז הנתונים (DCN)
  • זמן אחזור קולקטיבי
  • זמן האחזור של ההעברה מהמארח למכשיר
  • זמן האחזור של ההעברה מהמכשיר למארח

המדדים מופיעים בלוח הבקרה של Monitoring בפרויקט ב-Google Cloud שבו פועל אשכול GKE.

כדי לעקוב אחרי המדדים האלה ב-Metrics Explorer:

  1. נכנסים לדף Metrics Explorer במסוף Google Cloud .
  2. בשדה בחירת מדד, מסננים לפי שם המדד.
  3. כדי לסנן לפי שם עומס העבודה וטווח תאריכים, לוחצים על Add filter ואז מסננים לפי pod_name.
  4. בשדה Aggregation, בוחרים סוג צבירה בהתאם למדד ולעומסי העבודה שאחריהם עוקבים.

זמן האחזור של העברת 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 נדחתה במשאב

אם מופיעה השגיאה הבאה, ודאו שלחשבון השירות של Compute Engine שמשמש את Vertex AI Workbench יש הרשאה לכתוב רשומות יומן ב-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)."}"
>

כדי לפתור את הבעיה, צריך להקצות את התפקיד כתיבת יומנים (roles/logging.logWriter) לחשבון השירות של Compute Engine.

לא ניתן להתחבר לשרת ה-Proxy של IFRT

כשמנסים להריץ את פקודת JAX הראשונה ששולחת פקודת IFRT לאשכול Pathways, יכול להיות שהיא תפסיק להגיב למשך כדקה ואז תופיע 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)

אם השגיאה הזו מופיעה, לקוח ה-proxy של IFRT לא יכול להתחבר לשרת ה-proxy של IFRT. זה מה שכדאי לבדוק:

  • מוודאים שהגדרתם נכון את הרשת של הענן הווירטואלי הפרטי (VPC).
  • מוודאים שהכללים של חומת האש מאפשרים את החיבור.
  • מוודאים שאשכול Pathways מוקצה.
  • בודקים אם יש הודעות שגיאה בהפעלה ביומני הקונטיינר.

לחיצת היד של ALTS נכשלה או שהשקע נסגר במהלך ההתחברות לשרת ה-proxy של IFRT

יכול להיות שתראו את השגיאה Alts handshake failed (TSI_INTERNAL_ERROR) או UNAVAILABLE: Unable to establish connection to ifrt_proxy server ... Socket closed כשתריצו מניפסט בהתאמה אישית בלי השדה hostNetwork: true במאגר צמתים של איחוד זהויות של עומסי עבודה ל-GKE. כדי לפתור את הבעיה, מגדירים את משתנה הסביבה IFRT_PROXY_USE_INSECURE_GRPC_CREDENTIALS: "true" גם בקונטיינר של pathways-proxy וגם בקונטיינר של לקוח JAX (שני הצדדים צריכים להתאים). הוספת משתנה הסביבה הזה משביתה את ALTS ומשתמשת ב-gRPC לא מאובטח במקום זאת, לכן צריך להשתמש בו רק בתוך רשת אשכולות מהימנה.

יש חיבור קיים לאשכול Pathways

אשכול Pathways יכול לנהל סשן עם לקוח אחד בלבד בכל פעם. אם שני Notebooks נפרדים מנסים להתחבר לאותו אשכול 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

שגיאה פנימית משרת ה-proxy

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

השגיאה הזו מציינת ששרת ה-Proxy של IFRT התנתק מהלקוח. כדי לפתור את הבעיה, צריך להפעיל מחדש את הלקוח. ב-notebooks, מפעילים מחדש את הליבה של ה-notebook ומריצים אותו שוב.

‫SIGTERM ו-HBM OOM

רשומה של SIGTERM ביומנים שמשויכת לשגיאה RESOURCE_EXHAUSTED יכולה להצביע על שגיאת OOM (אין מספיק זיכרון) בזיכרון ברוחב פס גבוה (HBM). במקרה כזה, צריך להקטין את כמות ה-HBM שבה משתמש קוד ה-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"

השגיאה הזו מתרחשת אם הקטגוריה של Cloud Storage שהועברה לדגל --pathways-gcs-location הגיעה למגבלה המקסימלית של מדיניות מחזור החיים (50 קידומות). כדי לפתור את הבעיה, צריך למחוק את כללי מדיניות מחזור החיים של Cloud Storage שכבר לא בשימוש.

שגיאה קבועה

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

מנהל המשאבים של Pathways או ה-workers של Pathways מדפיסים את השגיאה הזו כשמספקים מיקום לא חוקי ב-Cloud Storage לקונטיינרים של Pathways.

תגובת שגיאה מהדמון

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

השגיאה הזו מתרחשת כשמשתמשים בגרסה ישנה יותר של Docker. שדרגו את גרסת Docker.

הלקוח והשרת של שרת ה-proxy של 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 ..., אין תמונת Pathways מתויגת עבור JAX_VERSION המבוקש. משתמשים בגרסת JAX נתמכת.

באשכול אין מחיצה של cpu

אם לא מופיעה מחיצה של cpu ב-sinfo, בהגדרת האשכול חסרה קבוצת הצמתים של המעבד (CPU) או שהמחיצה שלה נקראת בשם אחר. הסקריפטים של Pathways שולחים משימות למחיצה בשם cpu. כדי לפתור את הבעיה, צריך לעדכן את תרשים האשכול כך שתוגדר מחיצת מעבד (CPU) בשם cpu ולפרוס מחדש את האשכול, או לעדכן את שם המחיצה בסקריפטים של משימות Pathways כך שיתאים למחיצת המעבד (CPU) שמוצגת על ידי sinfo.

צומתי TPU לא עולים

בודקים שההזמנה נמצאת באזור של האשכול, שיש בה מספיק מכונות וירטואליות מסוג ct6e-standard-4t, ושהערכים של staticNodeCount ו-acceleratorTopology תואמים.

השירות Pathways נסגר עם Invalid partition name specified

המשתנה PARTITION שגוי. בוחרים מחיצת TPU מהפלט של sinfo.

שירות Pathways לא מוכן

אם יומן השירות נשאר ב-Waiting for at least MIN_SLICES=..., לא פועלים מספיק פרוסות. בעמודה NODELIST(REASON) של הפקודה הבאה מוצגת הסיבה, למשל, אין קיבולת זמינה או ערך SLICE_SHAPE שלא תואם לקבוצת הצמתים של ה-TPU:

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

מנהל המשאבים של Pathways או שרת ה-proxy של 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, אחד מהם קרס והשירות עצר את ה-workers שלו. בודקים את 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, השירות לא פועל או עדיין לא מוכן. בודקים את יומן השירות. כדי להמתין יותר זמן, מגדירים את SERVICE_WAIT_MINUTES כששולחים את run_maxtext.sh.

הפעולה של MaxText נכשלת עם השגיאה RESOURCE_EXHAUSTED

המודל לא מתאים לזיכרון של ה-TPU. משתמשים ב-2x4 או ב-4x4 פרוסות, או מגדירים את REDUCED_LAYERS=1.

המשימה ב-MaxText נשארת בהמתנה

בצומת המעבד (CPU) אין את 8 המעבדים ו-160GB הזיכרון ש-run_maxtext.sh מבקש, בנוסף ל-4 המעבדים ו-80GB הזיכרון שבהם משתמש שירות Pathways. שני המשימות מתאימות יחד לצומת n2-highmem-32. כדי לפתור את הבעיה, צריך להגדיל את קיבולת המעבד (CPU) והזיכרון (או את מספר הצמתים) במחיצה cpu, או להקטין את בקשת המשאבים ב-run_maxtext.sh.

לא ניתן להתחבר לשרת ה-Proxy של IFRT

אם הלקוח מפסיק להגיב או נכשל עם UNAVAILABLE, הוא לא יכול להגיע לשרת ה-proxy:

  • בודקים שביומן השירות מופיע READY.
  • מוודאים שהכתובת JAX_BACKEND_TARGET תואמת לכתובת ב-~/pathways/cluster.env.
  • אם אתם משתמשים בהעברה ליציאה אחרת, ודאו שמנהרת ה-SSH עדיין פועלת.

  • אם הלקוח פועל במכונה וירטואלית, צריך לוודא שהמכונה הווירטואלית נמצאת ברשת המשנה של האשכול. הפקודה הבאה אמורה להצליח:

    nc -zv PROXY_IP 29000

    מחליפים את PROXY_IP בכתובת ה-IP של שרת ה-Proxy של IFRT מיומן השירות.

הפקודה jax.devices() מציגה רשימה של מכשירי CPU במקום מכשירי TPU

הגדרתם את משתני הסביבה JAX_PLATFORMS ו-JAX_BACKEND_TARGET אחרי שייבאתם את jax. מפעילים מחדש את ליבת ה-notebook ומגדירים את המשתנים לפני שמייבאים את jax.

שגיאות מיד אחרי החיבור לשרת ה-proxy של IFRT

גרסת ה-jax או ה-pathwaysutils של הלקוח לא תואמת לשרת של Pathways. מתקינים את הגרסאות ב-~/pathways/venv.

חישוב נכשל עם DATA_LOSS ו-PlacementDataLoss

החישוב השתמש במכשיר בפרוסה שלא פועלת – לדוגמה, כי הפרוסה הופסקה. שרת ה-proxy של IFRT נשאר מחובר בזמן ש-Slurm מוסיף את הפרוסה לתור מחדש. בודקים אם כל משימות ה-worker פועלות, ומריצים שוב את החישוב אחרי שהפרוסה חוזרת:

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

חישוב נכשל אחרי הפקעה של Spot

חישובים שמשתמשים במכשירים של הפרוסה שהופקעה נכשלים. כדי להתאושש באופן אוטומטי מהפקעות של Spot, צריך להגדיר נקודות ביקורת ושינוי קנה מידה של פרוסות גמישות, כפי שמתואר במאמר אימון גמיש באמצעות Pathways.

המאמרים הבאים