אימון מבוזר

בדף הזה מוסבר איך להריץ משימות אימון מבוזרות ב-Vertex AI.

דרישות לגבי קודים

משתמשים במסגרת ML שתומכת באימון מבוזר. בקוד ההדרכה, אפשר להשתמש במשתני הסביבה CLUSTER_SPEC או TF_CONFIG כדי להפנות לחלקים ספציפיים באשכול ההדרכה.

מבנה אשכול ההדרכה

אם מריצים משימת אימון מבוזרת באמצעות Vertex AI, צריך לציין כמה מכונות (צמתים) באשכול אימון. שירות ההדרכה מקצה את המשאבים לסוגי המכונות שציינתם. העבודה שמתבצעת בצומת מסוים נקראת רפליקה. קבוצה של רפליקות עם אותה הגדרה נקראת מאגר עובדים.

לכל רפליקה באשכול האימון מוקצה תפקיד או משימה יחידים באימון מבוזר. לדוגמה:

רפליקה ראשית: בדיוק רפליקה אחת מוגדרת כרפליקה ראשית. המשימה הזו מנהלת את שאר המשימות ומדווחת על הסטטוס של העבודה כולה.
תהליכי Worker: יכול להיות שעותק אחד או יותר יוגדר כתהליך Worker. העותקים האלה מבצעים את החלק שלהם בעבודה, בהתאם להגדרות של העבודה.
שרתים של פרמטרים: אם יש תמיכה בפרמטרים ב-ML framework שלכם, אפשר להגדיר עותק אחד או יותר כשרתים של פרמטרים. הרפליקות האלה מאחסנות פרמטרים של המודל ומתאמות את מצב המודל המשותף בין העובדים.
הערכה: אם נתמך על ידי ה-framework של ה-ML, אפשר להגדיר עותק אחד או יותר כהערכה. אפשר להשתמש בעותקים האלה כדי להעריך את המודל. אם אתם משתמשים ב-TensorFlow, חשוב לדעת שבדרך כלל TensorFlow מצפה שלא תשתמשו ביותר ממעריך אחד.

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

אפשר להגדיר כל משימת אימון בלי שרת (serverless) ב-Vertex AI כמשימת אימון מבוזרת על ידי הגדרה של כמה מאגרי עובדים. אפשר גם להריץ אימון מבוזר בצינור אימון או במשימה של כוונון היפרפרמטרים.

כדי להגדיר משימת אימון מבוזרת, צריך להגדיר את רשימת מאגרי העובדים (workerPoolSpecs[]) ולהקצות WorkerPoolSpec אחד לכל סוג משימה:

מיקום ב`workerPoolSpecs[]`	המשימה בוצעה באשכול
הראשון (`workerPoolSpecs[0]`)	ראשי, מרכזי, מתזמן או "מאסטר"
שנייה (`workerPoolSpecs[1]`)	משני, עותקים, עובדים
שלישי (`workerPoolSpecs[2]`)	שרתי פרמטרים, שרת צמצום
הרביעי (`workerPoolSpecs[3]`)	מעריכים

צריך לציין רפליקה ראשית, שמתאמת את העבודה שמבצעות כל הרפליקות האחרות. משתמשים במפרט הראשון של מאגר העובדים רק בשביל הרפליקה הראשית, ומגדירים את replicaCount שלו ל-1:

{
  "workerPoolSpecs": [
     // `WorkerPoolSpec` for worker pool 0, primary replica, required
     {
       "machineSpec": {...},
       "replicaCount": 1,
       "diskSpec": {...},
       ...
     },
     // `WorkerPoolSpec` for worker pool 1, optional
     {},
     // `WorkerPoolSpec` for worker pool 2, optional
     {},
     // `WorkerPoolSpec` for worker pool 3, optional
     {}
   ]
   ...
}

ציון מאגרי עובדים נוספים

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

הסדר של מאגרי העובדים שאתם מציינים ברשימה workerPoolSpecs[] קובע את סוג מאגר העובדים. מגדירים ערכים ריקים למאגרי עובדים שלא רוצים להשתמש בהם, כדי שאפשר יהיה לדלג עליהם ברשימה workerPoolSpecs[] ולציין מאגרי עובדים שרוצים להשתמש בהם. לדוגמה:

אם רוצים לציין משימה שיש לה רק רפליקה ראשית ומאגר עובדים של שרת פרמטרים, צריך להגדיר ערך ריק למאגר העובדים 1:

{
  "workerPoolSpecs": [
     // `WorkerPoolSpec` for worker pool 0, required
     {
       "machineSpec": {...},
       "replicaCount": 1,
       "diskSpec": {...},
       ...
     },
     // `WorkerPoolSpec` for worker pool 1, optional
     {},
     // `WorkerPoolSpec` for worker pool 2, optional
     {
       "machineSpec": {...},
       "replicaCount": 1,
       "diskSpec": {...},
       ...
     },
     // `WorkerPoolSpec` for worker pool 3, optional
     {}
   ]
   ...
}

קיצור זמן האימון באמצעות שרת ההפחתה

כשמבצעים אימון של מודל גדול ללמידת מכונה באמצעות כמה צמתים, העברת הגרדיאנטים בין הצמתים עלולה להוסיף זמן אחזור משמעותי. שרת ההפחתה הוא אלגוריתם של הפחתה כוללת שיכול להגדיל את התפוקה ולהפחית את זמן האחזור באימון מבוזר. ‫Vertex AI מספקת את Reduction Server בקובץ אימג' של קונטיינר Docker שאפשר להשתמש בו באחד ממאגרי העובדים במהלך אימון מבוזר.

מידע נוסף על אופן הפעולה של Reduction Server זמין במאמר אימון מהיר יותר של GPU מבוזר באמצעות Reduction Server ב-Vertex AI.

דרישות מוקדמות

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

אתם מבצעים אימון מבוזר עם עובדי GPU.
קוד האימון משתמש ב-TensorFlow או ב-PyTorch ומוגדר לאימון מקביל של נתונים בכמה מארחים עם מעבדי GPU באמצעות NCCL all-reduce. (אפשר גם להשתמש במסגרות אחרות של ML שמשתמשות ב-NCCL).
הקונטיינרים שפועלים בצומת הראשי (workerPoolSpecs[0]) ובצומתי העובדים (workerPoolSpecs[1]) תומכים ב-Reduction Server. באופן ספציפי, כל מאגר תגים הוא אחד מהבאים:
- קונטיינר מוכן מראש לאימון TensorFlow, גרסה 2.3 ואילך.
- קונטיינר מוכן מראש לאימון Pytorch, גרסה 1.4 ואילך.
- מאגר תגים בהתאמה אישית עם NCCL 2.7 ואילך, וחבילת google-reduction-server מותקנת. אפשר להתקין את החבילה הזו בקובץ אימג' של קונטיינר בהתאמה אישית על ידי הוספת השורה הבאה ל-Dockerfile:
```
RUN echo "deb https://packages.cloud.google.com/apt google-fast-socket main" | tee /etc/apt/sources.list.d/google-fast-socket.list && \
    curl -s -L https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add - && \
    apt update && apt install -y google-reduction-server
```

אימון באמצעות שרת לצמצום נתונים

כדי להשתמש בשרת לצמצום, מבצעים את הפעולות הבאות כשיוצרים משאב אימון בלי שרת (serverless):

מציינים אחד ממזהי ה-URI הבאים בשדה containerSpec.imageUriשל מאגר העובדים השלישי (workerPoolSpecs[2]):
- us-docker.pkg.dev/vertex-ai-restricted/training/reductionserver:latest
- europe-docker.pkg.dev/vertex-ai-restricted/training/reductionserver:latest
- asia-docker.pkg.dev/vertex-ai-restricted/training/reductionserver:latest
בחירה של אזור במספר אזורים שקרוב למיקום שבו מתבצע אימון ללא שרתים עשויה להפחית את זמן האחזור.
כשבוחרים את סוג המכונה ומספר הצמתים למאגר העובדים השלישי, צריך לוודא שרוחב הפס הכולל של הרשת במאגר העובדים השלישי זהה לרוחב הפס הכולל של הרשת במאגר העובדים הראשון והשני, או גדול ממנו.

מידע על רוחב הפס המקסימלי שזמין לכל צומת במאגר העובדים השני זמין במאמר רוחב פס ברשת ומעבדי GPU.

לא משתמשים ב-GPU לצמתים של שרת ההפחתה. כדי לקבל מידע על רוחב הפס המקסימלי שזמין בכל צומת במאגר העובדים השלישי, אפשר לעיין בעמודות 'רוחב פס מקסימלי של תעבורת נתונים יוצאת (egress) (Gbps)' במשפחת מכונות לשימוש כללי.

לדוגמה, אם מגדירים את מאגרי העובדים הראשון והשני לשימוש ב-5 צמתים, כל אחד עם 8 מעבדי GPU, אז לכל צומת יש רוחב פס מקסימלי זמין של 100 Gbps, לרוחב פס כולל של 500 Gbps.n1-highmem-96NVIDIA_TESLA_V100 כדי להתאים את רוחב הפס הזה במאגר העובדים השלישי, אפשר להשתמש ב-16 צמתים של n1-highcpu-16, שלכל אחד מהם רוחב פס מקסימלי של 32 Gbps, כך שרוחב הפס הכולל יהיה 512 Gbps.

מומלץ להשתמש בסוג המכונה n1-highcpu-16 לצמתים של שרת לצמצום, כי סוג המכונה הזה מציע רוחב פס גבוה יחסית למשאבים שלו.

הפקודה הבאה היא דוגמה ליצירת משאב CustomJob באמצעות Reduction Server:

gcloud ai custom-jobs create \
  --region=LOCATION \
  --display-name=JOB_NAME \
  --worker-pool-spec=machine-type=n1-highmem-96,replica-count=1,accelerator-type=NVIDIA_TESLA_V100,accelerator-count=8,container-image-uri=CUSTOM_CONTAINER_IMAGE_URI \
  --worker-pool-spec=machine-type=n1-highmem-96,replica-count=4,accelerator-type=NVIDIA_TESLA_V100,accelerator-count=8,container-image-uri=CUSTOM_CONTAINER_IMAGE_URI \
  --worker-pool-spec=machine-type=n1-highcpu-16,replica-count=16,container-image-uri=us-docker.pkg.dev/vertex-ai-restricted/training/reductionserver:latest

למידע נוסף, אפשר לעיין במדריך ליצירת CustomJob.

שיטות מומלצות לאימון באמצעות Reduction Server

כדי לשפר את הביצועים והיעילות של משימות ההדרכה של שרת ההפחתה, כדאי לפעול לפי השיטות המומלצות הבאות להגדרת האשכול.

סוג המכונה ומספר המכונות

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

בחירה טובה למארחי פעולות צמצום היא מכונת VM לשימוש כללי מסוג N1/N2 עם לפחות 16 vCPU, שמספקת רוחב פס של 32 Gbps ליציאה, כמו n1-highcpu-16 ו-n2-highcpu-16. רוחב הפס של מכונות וירטואליות ברמה 1 עבור מכונות וירטואליות מסוג N1/N2 גדל, ורוחב הפס המקסימלי של התעבורה היוצאת נע בין 50 Gbps ל-100 Gbps. לכן, הן מהוות בחירה טובה לצמתי מכונות וירטואליות של רכיב ה-reducer.

רוחב הפס הכולל של תעבורת הנתונים היוצאת (egress) של העובדים והמצמצמים צריך להיות זהה. לדוגמה, אם אתם משתמשים ב-8 מכונות וירטואליות (VM) כעובדים, אתם צריכים להשתמש לפחות ב-25 מכונות וירטואליות כמצמצמים.a2-megagpu-16gn1-highcpu-16

`(8 worker VMs * 100&nbsp;Gbps) / 32&nbsp;Gbps egress = 25 reducer VMs`.

איחוד של הודעות קטנות

השרת לצמצום נתונים פועל בצורה הטובה ביותר אם ההודעות שמצטברות גדולות מספיק. ברוב מסגרות ה-ML כבר יש טכניקות עם טרמינולוגיה שונה לאיגום של טנסורים קטנים של גרדיאנטים לפני ביצוע פעולת all-reduce.

Horovod

‫Horovod תומך ב-Tensor Fusion כדי לאגד טנסורים קטנים ל-all-reduce. טנסורים ממולאים במאגר נתונים זמני של מיזוג עד שהמאגר מלא לגמרי ופעולת ה-all-reduce במאגר מבוצעת. אפשר לשנות את הגודל של מאגר הנתונים הזמני של המיזוג על ידי הגדרת משתנה הסביבה HOROVOD_FUSION_THRESHOLD.

הערך המומלץ למשתנה הסביבה HOROVOD_FUSION_THRESHOLD הוא לפחות 128 MB. במקרה כזה, מגדירים את משתנה הסביבה HOROVOD_FUSION_THRESHOLD ל-134217728 ‏ (128 * 1024 * 1024).

PyTorch

‫PyTorch DistributedDataParallel תומך בהודעות באצווה בתור 'חלוקת גרדיאנטים'. מגדירים את הפרמטר bucket_cap_mb בבונה DistributedDataParallel כדי לשלוט בגודל של קטגוריות האצווה. גודל ברירת המחדל הוא 25 MB.

שיטה מומלצת: הערך המומלץ של bucket_cap_mb הוא 64 (64 MB).

משתני סביבה של האשכול

‫Vertex AI מאכלס משתנה סביבה, CLUSTER_SPEC, בכל רפליקה כדי לתאר את ההגדרה של האשכול כולו. בדומה ל-TensorFlowTF_CONFIG,‏ CLUSTER_SPEC מתאר כל רפליקה באשכול, כולל האינדקס והתפקיד שלה (רפליקה ראשית, עובד, שרת פרמטרים או מעריך).

כשמריצים אימון מבוזר באמצעות TensorFlow, הקובץ TF_CONFIG עובר ניתוח כדי ליצור את tf.train.ClusterSpec. באופן דומה, כשמריצים אימון מבוזר עם מסגרות אחרות של ML, צריך לנתח את CLUSTER_SPEC כדי לאכלס את כל משתני הסביבה או ההגדרות שנדרשים על ידי המסגרת.

הפורמט של `CLUSTER_SPEC`

משתנה הסביבה CLUSTER_SPEC הוא מחרוזת JSON בפורמט הבא:

מפתח	תיאור
`"cluster"`	תיאור האשכול למאגר התגים המותאם אישית. בדומה ל-`TF_CONFIG`, האובייקט הזה מעוצב כמפרט של אשכול TensorFlow, ואפשר להעביר אותו ל-constructor של tf.train.ClusterSpec. תיאור האשכול מכיל רשימה של שמות העותקים לכל מאגר עובדים שציינתם.
	`"workerpool0"`	לכל משימות האימון המבוזרות יש רפליקה ראשית אחת במאגר הראשון של העובדים.
	`"workerpool1"`	מאגר העובדים הזה מכיל עותקים משוכפלים של עובדים, אם ציינתם אותם כשאתם יוצרים את המשימה.
	`"workerpool2"`	מאגר העובדים הזה מכיל שרתי פרמטרים, אם ציינתם אותם כשאתם יוצרים את המשימה.
	`"workerpool3"`	מאגר העובדים הזה מכיל בודקים, אם ציינתם אותם כשאתם יוצרים את המשימה.
`"environment"`	המחרוזת `cloud`.
`"task"`	תיאור המשימה של הצומת הספציפי שבו הקוד פועל. אתם יכולים להשתמש במידע הזה כדי לכתוב קוד לעובדים ספציפיים במשימה מבוזרת. הרשומה הזו היא מילון עם המפתחות הבאים:
	`"type"`	סוג מאגר העובדים שבו המשימה פועלת. לדוגמה, `"workerpool0"` מתייחס לרפליקה הראשית.
	`"index"`	האינדקס של המשימה, כשהספירה מתחילה מ-0. לדוגמה, אם משימת האימון כוללת שני עובדים, הערך הזה מוגדר כ-`0` אצל אחד מהם וכ-`1` אצל השני.
	`"trial"`	המזהה של ניסוי כוונון ההיפר-פרמטרים שפועל כרגע. כשמגדירים כוונון של היפר-פרמטרים למשימה, מגדירים מספר ניסיונות לאימון. הערך הזה מאפשר לכם להבדיל בקוד בין תקופות ניסיון פעילות. המזהה הוא ערך מחרוזת שמכיל את מספר הניסיון, החל מ-1.
`job`	‫`CustomJobSpec` שסיפקתם כדי ליצור את משימת האימון הנוכחית, שמיוצגת כמילון.

`CLUSTER_SPEC` דוגמה

ערך לדוגמה:


{
   "cluster":{
      "workerpool0":[
         "cmle-training-workerpool0-ab-0:2222"
      ],
      "workerpool1":[
         "cmle-training-workerpool1-ab-0:2222",
         "cmle-training-workerpool1-ab-1:2222"
      ],
      "workerpool2":[
         "cmle-training-workerpool2-ab-0:2222",
         "cmle-training-workerpool2-ab-1:2222"
      ],
      "workerpool3":[
         "cmle-training-workerpool3-ab-0:2222",
         "cmle-training-workerpool3-ab-1:2222",
         "cmle-training-workerpool3-ab-2:2222"
      ]
   },
   "environment":"cloud",
   "task":{
      "type":"workerpool0",
      "index":0,
      "trial":"TRIAL_ID"
   },
   "job": {
      ...
   }
}

הפורמט של `TF_CONFIG`

בנוסף ל-CLUSTER_SPEC, ‏ Vertex AI מגדיר את משתנה הסביבה TF_CONFIG בכל רפליקה של כל משימות האימון המבוזרות. ‫Vertex AI לא מגדיר את TF_CONFIG למשימות אימון עם עותק יחיד.

לפרמטרים CLUSTER_SPEC ו-TF_CONFIG יש ערכים משותפים, אבל הם בפורמטים שונים. שני משתני הסביבה כוללים שדות נוספים מעבר למה שנדרש ב-TensorFlow.

אימון מבוזר באמצעות TensorFlow פועל באותו אופן כשמשתמשים בקונטיינרים מותאמים אישית וכשמשתמשים בקונטיינר מוכן מראש.

משתנה הסביבה TF_CONFIG הוא מחרוזת JSON בפורמט הבא:

TF_CONFIG שדות

cluster

תיאור אשכול TensorFlow. מילון שממפה שם משימה אחד או יותר (chief,‏ worker,‏ ps או master) לרשימות של כתובות רשת שבהן המשימות האלה פועלות. בכל משימת אימון, המילון הזה זהה בכל מכונה וירטואלית.

זהו הארגומנט הראשון התקין עבור בנאי tf.train.ClusterSpec. שימו לב שהמילון הזה אף פעם לא מכיל את evaluator כמפתח, כי בודקים לא נחשבים לחלק מאשכול ההדרכה, גם אם אתם משתמשים בהם בעבודה.

task

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

המילון הזה כולל את צמדי המפתח/ערך הבאים:

`task` שדות
`type`	סוג המשימה שהמכונה הווירטואלית מבצעת. הערך הזה מוגדר כ-`worker` בעובדים, כ-`ps` בשרתי פרמטרים וכ-`evaluator` במעריכים. במאסטר של העובד של המשימה, הערך מוגדר כ-`chief` או כ-`master`.
`index`	האינדקס של המשימה, כשהספירה מתחילה מ-0. לדוגמה, אם משימת האימון כוללת שני עובדים, הערך הזה מוגדר כ-`0` אצל אחד מהם וכ-`1` אצל השני.
`trial`	המזהה של ניסוי כוונון ההיפרפרמטרים שפועל כרגע במכונה הווירטואלית הזו. השדה הזה מוגדר רק אם משימת האימון הנוכחית היא משימת כוונון היפר-פרמטרים. במשימות של כוונון היפר-פרמטרים, מערכת Vertex AI מריצה את קוד האימון שלכם שוב ושוב בניסויים רבים עם היפר-פרמטרים שונים בכל פעם. השדה הזה מכיל את מספר הניסיון הנוכחי, החל מ-`1` בניסיון הראשון.
`cloud`	מזהה שנמצא בשימוש פנימי ב-Vertex AI. אפשר להתעלם מהשדה הזה.

job

‫CustomJobSpec שסיפקתם כדי ליצור את משימת האימון הנוכחית, שמיוצגת כמילון.

environment

המחרוזת cloud.

`TF_CONFIG` דוגמה

בדוגמת הקוד הבאה, משתנה הסביבה TF_CONFIG מודפס ביומני האימון:

import json
import os

tf_config_str = os.environ.get('TF_CONFIG')
tf_config_dict  = json.loads(tf_config_str)

# Convert back to string just for pretty printing
print(json.dumps(tf_config_dict, indent=2))

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

{
  "cluster": {
    "chief": [
      "training-workerpool0-[ID_STRING_1]-0:2222"
    ],
    "ps": [
      "training-workerpool2-[ID_STRING_1]-0:2222"
    ],
    "worker": [
      "training-workerpool1-[ID_STRING_1]-0:2222",
      "training-workerpool1-[ID_STRING_1]-1:2222"
    ]
  },
  "environment": "cloud",
  "job": {
    ...
  },
  "task": {
    "cloud": "[ID_STRING_2]",
    "index": 0,
    "trial": "1",
    "type": "worker"
  }
}

מתי כדאי להשתמש ב-`TF_CONFIG`

השדה TF_CONFIG מוגדר רק למשימות אימון מבוזרות.

ברוב המקרים, לא צריך לבצע אינטראקציה ישירה עם משתנה הסביבה TF_CONFIG בקוד האימון. אפשר לגשת למשתנה הסביבה TF_CONFIG רק אם אסטרטגיות ההפצה של TensorFlow ותהליך העבודה הסטנדרטי של Vertex AI להתאמת היפרפרמטרים, שמתוארים בקטעים הבאים, לא מתאימים לעבודה שלכם.