במדריך הזה נסביר איך לכוונן מודל שפה גדול (LLM) של Gemma 4 באשכול Google Kubernetes Engine (GKE) עם כמה יחידות GPU במארח יחיד ב- Google Cloud. האשכול הזה משתמש במכונה וירטואלית (VM) אחת מסוג A4, שמחוברים אליה 8 מעבדי GPU מסוג NVIDIA B200.
שני התהליכים העיקריים שמתוארים במדריך הזה הם:
- פריסת אשכול GKE עם ביצועים גבוהים באמצעות GKE Autopilot. כחלק מהפריסה הזו, אתם משתמשים ב-Cloud Build כדי ליצור קובץ אימג' של קונטיינר בהתאמה אישית, עם התוכנה הנדרשת שמותקנת מראש.
- אחרי פריסת האשכול, אתם מריצים משימת כוונון שמשתמשת ב-Fully Sharded Data Parallel (FSDP) כדי לפצל את המודל בין כל שמונת ה-GPU של צומת A4 (
a4-highgpu-8g) יחיד. העבודה משתמשת בקבוצת הסקריפטים שמצורפת למדריך הזה, ומסתמכת על ספריית Hugging Face Accelerate.
המדריך הזה מיועד למהנדסי למידת מכונה (ML), לחוקרים, לאדמינים ולמפעילים של פלטפורמות ולמומחים בתחום הנתונים וה-AI שרוצים לפרוס אשכולות GKE ב- Google Cloud כדי לאמן מודלים גדולים של שפה (LLM).
מטרות
אתם יכולים לגשת למודל Gemma 4 באמצעות Hugging Face.
מכינים את הסביבה.
יצירה ופריסה של אשכול GKE מסוג A4.
כוונון עדין של מודל Gemma 4 באמצעות ספריית Hugging Face Accelerate עם מקביליות נתונים מפוצלת לחלוטין (FSDP).
עוקבים אחרי המשימה.
לפנות מקום.
עלויות
במסמך הזה משתמשים ברכיבים הבאים של Google Cloud, והשימוש בהם כרוך בתשלום:
- Compute Engine
- Google Kubernetes Engine (GKE)
- Artifact Registry
- Cloud Build
- Cloud Storage
- Cloud Logging
כדי ליצור הערכת עלויות בהתאם לשימוש החזוי, אתם יכולים להשתמש במחשבון התמחור.
לפני שמתחילים
מפעילים את ממשקי ה-API הנדרשים, אם יש כאלה שלא מופעלים כבר:
התפקידים שנדרשים כדי להפעיל ממשקי API
כדי להפעיל ממשקי API, צריך את ההרשאה
serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד 'בעלים' (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד 'אדמין בממשק Service Usage' (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידיםgcloud services enable compute.googleapis.com
container.googleapis.com artifactregistry.googleapis.com cloudbuild.googleapis.com logging.googleapis.com cloudresourcemanager.googleapis.com servicenetworking.googleapis.com מפעילים את חשבון השירות שמוגדר כברירת מחדל עבור Google Cloud הפרויקט:
export PROJECT_NUMBER="$(gcloud projects describe "YOUR_PROJECT_ID" --format "value(project_number)")" gcloud iam service-accounts enable "${PROJECT_NUMBER}-compute@developer.gserviceaccount.com" \ --project=YOUR_PROJECT_ID
מקצים את התפקידים שחשבון השירות שמוגדר כברירת מחדל צריך כדי להריץ את עומס העבודה של הכוונון העדין:
ROLES=("roles/artifactregistry.writer" "roles/cloudbuild.builds.builder" "roles/logging.logWriter" "roles/monitoring.metricWriter" "roles/monitoring.viewer" "roles/stackdriver.resourceMetadata.writer" "roles/storage.objectViewer") for role in "${ROLES[@]}"; do gcloud projects add-iam-policy-binding YOUR_PROJECT_ID \ --member="serviceAccount:${PROJECT_NUMBER}-compute@developer.gserviceaccount.com" \ --role="${role}" 1>/dev/null done unset ROLES
כדי לוודא שהתפקידים הוקצו, מריצים את הפקודה הבאה:
gcloud projects get-iam-policy YOUR_PROJECT_ID \ --flatten="bindings[].members" \ --filter="bindings.members:serviceAccount:${PROJECT_NUMBER}-compute@developer.gserviceaccount.com" \ --format="table(bindings.role)"יצירת פרטי כניסה לאימות מקומי בחשבון המשתמש:
gcloud auth application-default login
מפעילים את OS Login בפרויקט:
gcloud compute project-info add-metadata \ --metadata=enable-oslogin=TRUE \ --project=YOUR_PROJECT_ID
כדי לקבל את ההרשאות שדרושות להשלמת המדריך, בקשו מהאדמין להקצות לכם את התפקידים הבאים ב-IAM בפרויקט:
- אדמין ב-Kubernetes Engine (
roles/container.admin) - אדמין ב-Compute (
roles/compute.admin) - אדמין באחסון (
roles/storage.admin) - אדמין של Artifact Registry (
roles/artifactregistry.admin) - עריכה ב-Cloud Build (
roles/cloudbuild.builds.editor) - משתמש בחשבון שירות (
roles/iam.serviceAccountUser) - אדמין בחשבון שירות (
roles/iam.serviceAccountAdmin) - אדמין IAM בפרויקט (
roles/resourcemanager.projectIamAdmin) - אדמין ב-Service Usage (
roles/serviceusage.serviceUsageAdmin)
להסבר על מתן תפקידים, ראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.
יכול להיות שאפשר לקבל את ההרשאות הנדרשות גם באמצעות תפקידים בהתאמה אישית או תפקידים מוגדרים מראש.
איך משתמשים ב-Gemma 4 באמצעות Hugging Face
כדי להשתמש ב-Hugging Face כדי לגשת ל-Gemma 4:
- כניסה ל-Hugging Face
- יוצרים טוקן גישה ל-Hugging Face
write.
לוחצים על Your Profile > Settings > Access tokens > +Create new token (הפרופיל שלך > הגדרות > טוקני גישה > +יצירת טוקן חדש). - מעתיקים ושומרים את ערך האסימון של
write access. תשתמשו בו בהמשך המדריך.
הכנת הסביבה
כדי להכין את הסביבה, מגדירים את הפרטים הבאים:
מחליפים את מה שכתוב בשדות הבאים:
YOUR_PROJECT_ID: המזהה של Google Cloud הפרויקט שבו רוצים ליצור את אשכול GKE.
YOUR_CLUSTER_NAME: השם של אשכול GKE שרוצים ליצור.
YOUR_REGION: האזור שבו רוצים ליצור את אשכול GKE. אפשר ליצור את האשכול רק באזור שבו נמצאת ההזמנה.
YOUR_RESERVATION_NAME: המזהה של הקיבולת השמורה.
YOUR_HF_TOKEN: טוקן הגישה ל-Hugging Face שיצרתם בקטע הקודם.
YOUR_ARTIFACT_REGISTRY_LOCATION: Google Cloud האזור שבו רוצים ליצור את מאגר Artifact Registry. כדי לצמצם את זמן האחזור של שליפת התמונות, מומלץ להשתמש באותו אזור שבו השתמשתם בשביל YOUR_REGION.
יצירת אשכול GKE במצב אוטומטי
כדי ליצור אשכול GKE במצב אוטומטי, מריצים את הפקודה הבאה:
יצירת אשכול GKE עשויה להימשך זמן מה. כדי לוודא ש- Google Cloud סיים ליצור את האשכול, נכנסים לדף Kubernetes clusters במסוף Google Cloud .
יצירת סוד ב-Kubernetes לפרטי הכניסה של Hugging Face
כדי ליצור סוד של Kubernetes לפרטי הכניסה של Hugging Face:
מגדירים את
kubectlלתקשורת עם אשכול GKE:יוצרים סוד של Kubernetes לאחסון הטוקן של Hugging Face:
הכנת עומס העבודה
כדי להכין את עומס העבודה, מבצעים את הפעולות הבאות:
יצירת סקריפטים של עומסי עבודה
כדי ליצור את הסקריפטים שבהם משתמש עומס העבודה של הכוונון, מבצעים את הפעולות הבאות:
יוצרים ספרייה לסקריפטים של עומס העבודה. משתמשים בספרייה הזו בתור ספריית העבודה.
יוצרים את הקובץ
cloudbuild.yamlכדי להשתמש ב-Google Cloud Build. הקובץ הזה יוצר את הקונטיינר של עומס העבודה ומאחסן אותו ב-Artifact Registry:יוצרים קובץ
Dockerfileכדי להפעיל את משימת הכוונון העדין:יוצרים את הקובץ
accel_fsdp_gemma4_config.yaml. קובץ התצורה הזה מורה ל-Hugging Face Accelerate לפצל את משימת הכוונון בין שמונת המעבדים הגרפיים המקומיים במארח היחיד באמצעות FSDP:יוצרים את הקובץ
finetune.yaml:יוצרים את הקובץ
finetune.py:
שימוש ב-Docker וב-Cloud Build ליצירת קונטיינר לכוונון עדין
יוצרים מאגר Docker ב-Artifact Registry:
בספרייה
llm-finetuning-gemmaשיצרתם בשלב קודם, מריצים את הפקודה הבאה כדי ליצור את קובץ האימג' לכוונון ולהעביר אותו ל-Artifact Registry.מייצאים את כתובת ה-URL של התמונה. תשתמשו בו בשלב מאוחר יותר במדריך הזה:
התחלת עומס העבודה של הכוונון
כדי להתחיל את עומס העבודה של הכוונון העדין:
מחילים את המניפסט של הכוונון כדי ליצור את משימת הכוונון:
בגלל שאתם משתמשים באשכולות במצב GKE Autopilot, יכול להיות שיעברו כמה דקות עד שהצומת עם ה-GPU יתחיל לפעול.
מריצים את הפקודה הבאה כדי לעקוב אחרי המשימה:
אחרי שה-pods פועלים, בודקים את היומנים של המשימה:
משאב המשימה מוריד את נתוני המודל ואז מכוונן את המודל בכל שמונת ה-GPU. ההורדה נמשכת כחמש דקות. אחרי שההורדה מסתיימת, תהליך הכוונון נמשך כ-45 דקות. בכל 20 שלבים, העבודה שומרת נקודת ביקורת ומעבירה את מתאם Low-Rank Adaptation (LoRA) שעבר כוונון עדין למאגר פרטי ב-Hugging Face בשם
gemma-31b-text-to-sql.אחרי שהמשימה מסתיימת, פותחים בדפדפן את כתובת ה-URL של המודל שעבר כוונון ב-Hugging Face:
מעקב אחרי עומס העבודה
אתם יכולים לעקוב אחרי השימוש ביחידות ה-GPU באשכול GKE כדי לוודא שמשימת הכוונון פועלת ביעילות. כדי לעשות זאת, פותחים את הקישור הבא בדפדפן:
כשעוקבים אחרי עומס העבודה, אפשר לראות את הפרטים הבאים:
- השימוש ביחידות GPU: כדי שהאימון יהיה תקין, צפוי שהשימוש בכל 8 יחידות ה-GPU יעלה ויתייצב ברמה גבוהה לאורך כל האימון.
- משך המשימה: המשימה אמורה להימשך כ-45 דקות באשכול A4 שצוין.
הסרת המשאבים
כדי להימנע מחיובים נוספים, מוחקים את המשאבים שנוצרו במהלך המדריך הזה.
איך מוחקים את המשאבים
כדי למחוק את משימת הכוונון, מריצים את הפקודה הבאה:
כדי למחוק את אשכול GKE, מריצים את הפקודה הבאה:
כדי למחוק את המאגר ב-Artifact Registry, מריצים את הפקודה הבאה: