‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

אימון מבוזר

בדף הזה מוסבר איך להריץ משימות אימון מבוזרות בפלטפורמת Agent.

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

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

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

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

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

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

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

אפשר להגדיר כל משימת אימון ללא שרת בפלטפורמת הסוכנים של Gemini Enterprise כמשימת אימון מבוזרת על ידי הגדרת כמה מאגרי עובדים. אפשר גם להריץ אימון מבוזר בפייפליין של אימון או במשימה של כוונון היפרפרמטרים.

כדי להגדיר משימת אימון מבוזרת, צריך להגדיר את רשימת מאגרי העובדים (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
     {}
   ]
   ...
}

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

כשמבצעים אימון של מודל גדול ללמידת מכונה באמצעות כמה צמתים, תקשורת הגרדיאנטים בין הצמתים יכולה להוביל לזמן אחזור משמעותי. שרת ההפחתה הוא אלגוריתם של הפחתה כוללת שיכול להגדיל את קצב העברת הנתונים ולהפחית את זמן האחזור באימון מבוזר. Agent Platform מאפשרת להשתמש בשרת ההפחתה בקובץ אימג' של קונטיינר Docker, שאפשר להשתמש בו באחד ממאגרי ה-worker במהלך אימון מבוזר.

כדי לקבל מידע על אופן הפעולה של Reduction Server, אפשר לעיין במאמר Faster distributed GPU training with Reduction Server on Agent Platform (אימון מהיר יותר של GPU מבוזר באמצעות Reduction Server בפלטפורמת Agent).

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

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

אתם מבצעים אימון מבוזר עם עובדי 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
```

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

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

מציינים אחד ממזהי ה-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 לצמתים של שרת ההפחתה. כדי לקבל מידע על רוחב הפס המקסימלי שזמין בכל צומת במאגר ה-worker השלישי, אפשר לעיין בעמודות 'רוחב פס מקסימלי של תעבורת נתונים יוצאת (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. כדי לצמצם את מספר החיבורים במארח של העובד, צריך להשתמש בסוג מכונה עם רוחב הפס הכי גבוה ברשת עבור המארח של ה-reducer.

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

רוחב הפס הכולל של יציאת הנתונים של העובדים והמצמצמים צריך להיות זהה. לדוגמה, אם אתם משתמשים ב-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 תומך בהודעות אצווה כ-"gradient bucketing". מגדירים את הפרמטר bucket_cap_mb בבונה DistributedDataParallel כדי לשלוט בגודל של קטגוריות האצווה. גודל ברירת המחדל הוא 25 MB.

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

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

Agent Platform מאכלסת משתנה סביבה, CLUSTER_SPEC, בכל רפליקה כדי לתאר את ההגדרה של האשכול כולו. בדומה ל-TensorFlow TF_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"`	לכל משימות האימון המבוזרות יש רפליקה ראשית אחת ב-worker pool הראשון.
	`"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, Agent Platform מגדירה את משתנה הסביבה TF_CONFIG בכל רפליקה של כל משימות האימון המבוזרות. פלטפורמת Agent לא מגדירה את 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` במעריכים. ב-master worker של העבודה, הערך מוגדר כ-`chief` או כ-`master`.
`index`	האינדקס של המשימה, כשהספירה מתחילה מ-0. לדוגמה, אם משימת האימון כוללת שני עובדים, הערך הזה מוגדר כ-`0` אצל אחד מהם וכ-`1` אצל השני.
`trial`	המזהה של ניסוי כוונון ההיפרפרמטרים שפועל כרגע במכונה הווירטואלית הזו. השדה הזה מוגדר רק אם משימת האימון הנוכחית היא משימת כוונון היפר-פרמטרים. במשימות של כוונון היפרפרמטרים, Agent Platform מריץ את קוד האימון שוב ושוב בניסויים רבים עם היפרפרמטרים שונים בכל פעם. השדה הזה מכיל את מספר הניסיון הנוכחי, החל מ-`1` בניסיון הראשון.
`cloud`	מזהה שמשמש באופן פנימי את Agent Platform. אפשר להתעלם מהשדה הזה.

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 ותהליך העבודה הסטנדרטי של Agent Platform לכוונון היפרפרמטרים, שניהם מתוארים בקטעים הבאים, לא מתאימים לעבודה שלכם.