במדריך הזה תלמדו איך לתזמן סביבת אימון מבוזרת ללמידת חיזוק (RL) ב-Google Kubernetes Engine (GKE). אתם יכולים להשתמש ב-Ray ובמסגרת NVIDIA NeMo RL כדי להגדיר סביבת אימון מבוזרת לצורך כוונון עדין של מודל.
המדריך הזה מתמקד בצינור עיבוד הנתונים לאימון של Group Relative Policy Optimization (GRPO) ב-GKE עם Ray ו-NeMo RL. GRPO הוא אלגוריתם ללמידה עם חיזוקים שנועד לשפר את יכולת ההסקה של מודל. האלגוריתם הזה חוסך בזיכרון ומפשט את תהליך ה-RL על ידי ביטול של רכיב ה-Critic, או מודל הערך, ושימוש בחישוב יחסי שמבוסס על קבוצה במקום זאת.
לפני שמריצים את המדריך הזה, צריך להשלים את המדריך Fine-tune and scale reinforcement learning with verl on GKE. במדריך הזה נעשה שימוש באותה הגדרת אשכול ובתצורה כמו במדריך בנושא כוונון עדין ושינוי קנה מידה של RL עם verl.
רקע
בקטעים הבאים מופיעה סקירה כללית קצרה של המושגים שבהם נעשה שימוש במדריך הזה.
למידת חיזוקים (RL)
ב-RL, המודלים לומדים מתוך ניסיון, מחקר ומשוב, ולא מתוך חיקוי סטטי. במהלך האימון המוקדם, המודל לומד מה לומר, אבל במהלך למידה ממשוב אנושי (RLHF), הוא לומד איך להיות מועיל, בטוח והגיוני. RL משמש כגשר בין מודל בסיסי לבין מודל מכוונן לשימוש ספציפי.
מידע נוסף זמין במאמר מה זה למידת חיזוק?
אופטימיזציה של מדיניות יחסית לקבוצה (GRPO)
GRPO, אלגוריתם שזכה לפופולריות בזכות DeepSeek, מציע חלופה חסכונית בזיכרון ל-Proximal Policy Optimization (PPO) להתאמת LLM, על ידי הסרת מודל ה-Critic. במקום רשת מבקרת, GRPO יוצרת קבוצת תגובות לאותה הנחיה ומשתמשת בתגמול הממוצע של הקבוצה הזו כנקודת בסיס.
מידע נוסף זמין במאמר בנושא GRPO.
NVIDIA NeMo RL
NeMo RL היא ספרייה של NVIDIA בקוד פתוח שנועדה להרחבת RL אחרי אימון. NeMo RL הוא חלק ממערכת NeMo הרחבה, והוא מאפשר ניסויים בקנה מידה קטן ב-GPU יחיד ופריסות מרובות צמתים באלפי GPU.
מידע נוסף זמין במאמר בנושא NVIDIA NeMo RL.
מערך הנתונים GSM8k
במדריך הזה משתמשים במערך הנתונים GSM8k, שמכיל 8,500 בעיות מילוליות במתמטיקה ברמה של בית ספר יסודי, באיכות גבוהה ובמגוון לשוני.
באמצעות GSM8k ו-GRPO, המודל יוצר קבוצה של n תשובות שונות לאותה בעיה. המדד GRPO משווה את התשובות האלה לממוצע של הקבוצה. המודל מקבל תגמול גבוה יותר על נתיבים שהם נכונים ועקביים מבחינה לוגית בהשוואה לשאר הקבוצה. עם הזמן, המודל לומד שהדרך הכי אמינה למקסם את התגמול היא להסביר את השלבים בצורה ברורה, וכך הוא מצמצם את התגמול על תשובות עם ביצועים נמוכים.
מידע נוסף זמין במאמר בנושא GSM8k.
מטרות
במדריך הזה מוסבר איך להגדיר RL ב-GKE באמצעות NeMo RL. לשם כך, צריך לבצע את השלבים הבאים:
- מכינים את הסביבה.
- הגדרת אשכול GKE עם מעבדי GPU מסוג B200 או H200.
- הגדרת KubeRay לניהול אשכול Ray מבוזר.
- משתמשים ב-Managed Lustre לאחסון עם ביצועים גבוהים.
- מריצים משימת אימון של GRPO באמצעות NeMo RL.
לפני שמתחילים
-
התקינו את ה-CLI של Google Cloud.
-
הגדירו שה-CLI של gcloud ישתמש בזהות המאוחדת שלכם.
-
כדי לאתחל את ה-CLI של gcloud, הריצו את הפקודה הבאה:
gcloud init -
יוצרים או בוחרים Google Cloud פרויקט.
תפקידים שנדרשים כדי לבחור או ליצור פרויקט
- Select a project (בחירת פרויקט): כדי לבחור פרויקט לא צריך תפקיד IAM ספציפי – אפשר לבחור כל פרויקט שהוקצה לכם בו תפקיד.
-
יצירת פרויקט: כדי ליצור פרויקט, צריך את התפקיד Project Creator (יצירת פרויקטים) (
roles/resourcemanager.projectCreator), שכולל את ההרשאהresourcemanager.projects.create. איך מקצים תפקידים
-
יוצרים Google Cloud פרויקט:
gcloud projects create PROJECT_ID
מחליפים את
PROJECT_IDבשם של פרויקט Google Cloud שיוצרים. -
בוחרים את הפרויקט שיצרתם: Google Cloud
gcloud config set project PROJECT_ID
מחליפים את
PROJECT_IDבשם הפרויקט ב- Google Cloud .
מפעילים את ממשקי ה-API הנדרשים:
תפקידים שנדרשים להפעלת ממשקי API
כדי להפעיל ממשקי API, נדרשת ההרשאה
serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד 'בעלים' (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד 'אדמין של Service Usage' (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידיםgcloud services enable container.googleapis.com
storage.googleapis.com compute.googleapis.com -
מעניקים תפקידים לחשבון המשתמש. מריצים את הפקודה הבאה לכל אחד מהתפקידים הבאים ב-IAM:
roles/container.admin, roles/iam.serviceAccountAdmin, roles/storage.admingcloud projects add-iam-policy-binding PROJECT_ID --member="user:USER_IDENTIFIER" --role=ROLE
מחליפים את מה שכתוב בשדות הבאים:
-
PROJECT_ID: מזהה הפרויקט. -
USER_IDENTIFIER: המזהה של חשבון המשתמש חשבון. דוגמאות מופיעות במאמר ייצוג המשתמשים במאגרי כוח עבודה בכללי מדיניות IAM. -
ROLE: תפקיד ה-IAM שאתם מקצים לחשבון המשתמש.
-
- יוצרים חשבון ב-Hugging Face, אם עדיין אין לכם חשבון.
- מוודאים שיש לכם טוקן של Hugging Face עם
read access. - אם אין לכם חשבון, אתם צריכים ליצור חשבון Weights & Biases (Wandb).
- יוצרים מפתח Wandb API.
- מוודאים שלפרויקט יש מכסה מספקת עבור מעבדי GPU מסוג B200 ו-H200. Google Cloud מידע נוסף זמין במאמרים תכנון מכסת GPU ומכסת GPU.
הכנת הסביבה
במדריך הזה משתמשים ב-Cloud Shell.
עוברים אל Google Cloud המסוף.
בחלק העליון של Google Cloud חלון המסוף, לוחצים על הלחצן Activate Cloud Shell (הפעלת Cloud Shell).
מגדירים את משתני הסביבה הבאים:
מחליפים את הערכים הבאים:
-
YOUR_REGION: האזור ב-Compute Engine של מישור הבקרה של אשכול GKE. -
YOUR_NODE_ZONE: האזור של הצמתים. בוחרים אזור שבו זמינים מעבדי GPU מסוג NVIDIA B200 או H200. -
YOUR_CLUSTER_NAME: השם של אשכול GKE. -
YOUR_GPU_TYPE: המאיץ שהזמנתם בהזמנת הקיבולת של Compute Engine. הערך חייב להיות אחד מהערכים הבאים:-
nvidia-b200: NVIDIA B200 (180 GB) -
nvidia-h200-141gb: NVIDIA H200 (141 GB)
-
-
YOUR_MACHINE_TYPE: סוג המכונה לשימוש:- עבור יחידות GPU של NVIDIA B200 (180 GB), צריך להשתמש בגרסה
a4-highgpu-8gואילך. - למעבדי GPU מסוג NVIDIA H200 (141 GB), צריך להשתמש בגרסה
a3-ultragpu-8gואילך.
- עבור יחידות GPU של NVIDIA B200 (180 GB), צריך להשתמש בגרסה
-
YOUR_RESERVATION_NAME: השם של הזמנת ה-GPU. -
CHOSEN_LUSTRE_NAME: השם של מופע Lustre. -
YOUR_HF_TOKEN: האסימון שלכם ב-Hugging Face. -
YOUR_WANDB_API_KEY: מפתח ה-API של Wandb.
-
יוצרים את משתני הסביבה הבאים לרשת:
מחליפים את הערכים הבאים:
-
NETWORK_NAME: שם הרשת ב-GKE. -
GVNIC_NAME: הקידומת של שם רשת gVNIC. אפשר להשתמש בכל קידומת שרוצים. -
RDMA_NAME: הקידומת של רשת הגישה הישירה לזיכרון (RDMA) מרחוק. אפשר להשתמש בכל קידומת שרוצים.
-
הגדרת התשתית
בקטע הזה יוצרים רשתות VPC ואשכול GKE.
יצירת רשת VPC
יוצרים רשת VPC לממשק gVNIC:
יוצרים רשת VPC ורשתות משנה ל-RDMA שכוללות שמונה רשתות משנה לשמונה יחידות GPU:
יצירת אשכול GKE
אפשר להגדיר את NeMo RL באשכול GKE Standard.
יצירת אשכול רגיל:
קבלת פרטי הכניסה לאשכול:
יוצרים את מאגר הצמתים של ה-GPU:
מתקינים את NCCL RDMA installer:
הגדרת מיפויי רשת
שומרים את קובץ המניפסט הבא בשם
network-mapping.yaml:החלת המניפסט:
הכנת האחסון
בקטע הזה תיצרו מכונה של Managed Lustre, שמקצה את נפח האחסון הנדרש לביצועים גבוהים עבור עומס העבודה של RL.
הקצאת טווח של כתובות IP לגישה לשירותים פרטיים:
מחברים את ה-peering:
יצירת מכונה של Managed Lustre:
גישה למכונה קיימת ב-Managed Lustre באמצעות מנהל התקן ה-CSI של Managed Lustre.
מחפשים את כתובת ה-IP של מכונת Managed Lustre.
בדיקת המניפסט של
lustre-pv.yaml.החלת המניפסט:
בדיקת המניפסט של
lustre-pvc.yaml.החלת המניפסט:
פריסת RayCluster
בקטע הזה משכפלים את מאגר הדוגמאות, מכינים את קובצי המניפסט ומפריסים את אשכול Ray:
משכפלים את המאגר לדוגמה:
עוברים לספריית העבודה:
בודקים את קובץ המניפסט
values.yaml:מחליפים את
NCCL_TUNER_CONFIG_PATHבאחד מהערכים הבאים, בהתאם למאיץ שבו משתמשים במדריך הזה:- NVIDIA B200 (180 GB):
/usr/local/gib/configs/tuner_config_a4.txtpb - NVIDIA H200 (141 GB):
/usr/local/gib/configs/tuner_config_a3u.txtpb
במניפסט הזה, צומת הראש מנהל את העבודה ומארח את לוח הבקרה של Ray. צמתי העובדים מריצים את משימות האימון.
- NVIDIA B200 (180 GB):
פורסים את אשכול Ray:
במדריך הזה משתמשים בשני צמתי עובדים. כדי לשנות את מספר צמתי העובדים, משנים את הערך של
REPLICA_COUNT.מוודאים שצומתי העובד והראש פועלים:
הפלט אמור להיראות כך:
NAME READY STATUS RESTARTS AGE ray-cluster-kuberay-head-sw7dp 2/2 Running 0 33h ray-cluster-kuberay-worker-grp-0-worker-gkbxw 2/2 Running 0 33h ray-cluster-kuberay-worker-grp-0-worker-kdg62 2/2 Running 0 33hמוודאים שאשכול Ray פועל:
הפלט אמור להיראות כך:
NAME NAMESPACE DESIRED WORKERS AVAILABLE WORKERS CPUS GPUS TPUS MEMORY CONDITION STATUS AGE ray-cluster-kuberay default 2 2 618 17 0 1573741824k RayClusterProvisioned ready 33h
הפעלת משימת GRPO
אחרי שקלאסטר Ray מוכן, אפשר לשלוח Ray Job לקלאסטר Ray שפועל ב-GKE. המודל יורד אוטומטית במהלך ההרצה של משימת אימון ה-RL.
כדי לשלוח Ray Job, צריך להתחיל סשן אינטראקטיבי כדי להריץ את ה-Job.
כדי ליצור חיבור מקומי לאשכול Ray, מריצים את הפקודה הבאה:
הפקודה הזו מפעילה העברת יציאות בין המכונה המקומית לבין צומת הראש של Ray באשכול GKE. שימו לב: הטרמינל יהיה תפוס בזמן שהסשן פעיל. כדי להמשיך, צריך לפתוח מופע נפרד של הטרמינל.
בטרמינל נפרד, עוברים אל
kubernetes-engine-samples/ai-ml/nemo-rl-on-gke/nemoRL/gemma3-27b-itועורכים את הקובץgemma3-27b-gsm8k.sh:מחליפים את הערכים הבאים בקובץ
gemma3-27b-gsm8k.sh:-
YOUR_WANDB_API_KEY: מפתח ה-API של WandB. -
YOUR_HF_TOKEN: האסימון שלכם ב-Hugging Face.
בקובץ הזה אפשר לראות את ההגדרה להפעלת משימה עם מודל gemma3-27b-it במערך הנתונים GSM8k. כדי להשלים את צינור ההדרכה של GRPO, הסקריפט הזה מגדיר את הפרמטרים הבאים:
-
num_prompts_per_step: 16ו-num_generations_per_prompt: 32: מודל Gemma3-27b-it יוצר קבוצה גדולה של תשובות לכל הנחיה. במקרה כזה, המודל יפיק 512 תשובות (16 × 32 = 512). -
policy.generation.colocated.enabled=False: הפרמטר הזה משבית את התכונה של יצירת תוכן במיקום משותף, כלומר המודל לא יוצר תגובות באותו צומת כמו תהליך האימון. ב-RL רגיל, אותם מעבדי GPU מטפלים גם באימון וגם ביצירה. בהגדרה הזו של NeMo RL, מקצים צמתים ספציפיים (שמנוהלים באמצעות הפרמטרpolicy.generation.colocated.resources) רק להסקת מסקנות של vLLM, בעוד ששאר האשכול מתמקד במתמטיקה של האימון. הפרדה בין עומסי העבודה האלה מונעת תחרות על משאבים בין מאגרי האימון שדורשים הרבה זיכרון לבין עומסי העבודה של ההסקה שדורשים הרבה משאבי מחשוב.
-
כדי לשלוח את המשימה, מריצים את הפקודה הבאה:
במהלך הפעלת המשימה, הפלט מציג את תוצאות האימון, התזמון ומדדי הביצועים.
מעקב אחר תקינות משימת ה-GRPO
אחרי ש-Ray מסיים את העבודה, NeMo RL שומר את נקודות הבדיקה בנתיב שהוגדר.
כדי לבדוק את הפלט של עבודת ה-GRPO, יוצרים סשן SSH לקונטיינר
ray-head:מתקינים את כלי העץ apt בטרמינל של מאגר התגים
ray-head:מציגים את מבנה הספרייה של מאגר
ray-head:הפלט אמור להיראות כך:
root@ray-cluster-kuberay-worker-grp-0-worker-gkbxw:/opt/nemo-rl# tree /data/nemo_rl_gemma3_27b_3_17/ /data/nemo_rl_gemma3_27b_3_17/ `-- step_10 |-- config.yaml |-- policy | |-- optimizer | | |-- __0_0.distcp | | |-- __10_0.distcp | | |-- __11_0.distcp | | |-- __12_0.distcp | | |-- __13_0.distcp | | |-- __14_0.distcp | | |-- __15_0.distcp | | |-- __1_0.distcp | | |-- __2_0.distcp | | |-- __3_0.distcp | | |-- __4_0.distcp | | |-- __5_0.distcp | | |-- __6_0.distcp | | |-- __7_0.distcp | | |-- __8_0.distcp | | `-- __9_0.distcp | |-- tokenizer | | |-- chat_template.jinja | | |-- special_tokens_map.json | | |-- tokenizer.json | | `-- tokenizer_config.json | `-- weights | |-- __0_0.distcp | |-- __10_0.distcp | |-- __11_0.distcp | |-- __12_0.distcp | |-- __13_0.distcp | |-- __14_0.distcp | |-- __15_0.distcp | |-- __1_0.distcp | |-- __2_0.distcp | |-- __3_0.distcp | |-- __4_0.distcp | |-- __5_0.distcp | |-- __6_0.distcp | |-- __7_0.distcp | |-- __8_0.distcp | `-- __9_0.distcp |-- train_dataloader.pt `-- training_info.json 6 directories, 39 files
הסרת המשאבים
כדי להימנע מחיובים בחשבון Google Cloud על המשאבים שבהם השתמשתם במדריך הזה, אתם יכולים למחוק את המשאבים הספציפיים או את הפרויקט שמכיל אותם.
מחיקת המשאבים
מחיקת אשכול Slurm:
מחיקת אשכול GKE:
מחיקת מערכת הקבצים של Lustre:
מחיקת קישור בין רשתות VPC שכנות (peering):
מוחקים את טווח כתובות ה-IP הפרטיות של Lustre:
מחיקת תת-רשתות של RDMA ו-gVNIC:
מחיקת הכללים של חומת האש והרשתות:
מחיקת פרויקט
כדי למחוק פרויקט Google Cloud :
gcloud projects delete PROJECT_ID