יצירת קונטיינר והרצת קוד אימון באופן מקומי

אתם יכולים להשתמש בפקודה gcloud ai custom-jobs local-run כדי ליצור קובץ אימג' של קונטיינר Docker על סמך קוד האימון, ולהריץ את קובץ האימג' כקונטיינר במחשב המקומי. לתכונה הזו יש כמה יתרונות:

  • אתם יכולים ליצור קובץ אימג' של קונטיינר עם ידע מינימלי ב-Docker. אתם לא צריכים לכתוב קובץ Dockerfile משלכם. בהמשך תוכלו להעביר את קובץ האימג' הזה בדחיפה אל Artifact Registry ולהשתמש בו לאימון מותאם אישית של קונטיינרים.

    בתרחישי שימוש מתקדמים, יכול להיות שעדיין תרצו לכתוב קובץ Dockerfile משלכם.

  • קובץ האימג' של הקונטיינר יכול להריץ אפליקציית אימון של Python או סקריפט Bash.

    אתם יכולים להשתמש בסקריפט Bash כדי להריץ קוד אימון שנכתב בשפת תכנות אחרת (בתנאי שאתם מציינים גם קובץ אימג' בסיסי של קונטיינר שתומך בשפה האחרת).

  • הפעלת קונטיינר באופן מקומי מריצה את קוד האימון באופן דומה לאופן שבו הוא מורץ ב-Agent Platform.

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

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

  1. הגדרת סביבת הפיתוח של Agent Platform

  2. מתקינים את Docker Engine.

  3. אם אתם משתמשים ב-Linux, צריך להגדיר את Docker כך שאפשר יהיה להריץ אותו בלי sudo.

    כדי להשתמש ב-Docker, צריך להגדיר את ההגדרה הזו בפקודה local-run.

משתמשים בפקודה local-run

מריצים את הפקודה הבאה כדי ליצור קובץ אימג' של קונטיינר על סמך קוד האימון ולהריץ קונטיינר באופן מקומי:

gcloud ai custom-jobs local-run \
  --executor-image-uri=BASE_IMAGE_URI \
  --local-package-path=WORKING_DIRECTORY \
  --script=SCRIPT_PATH \
  --output-image-uri=OUTPUT_IMAGE_NAME

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

  • ‫BASE_IMAGE_URI: ה-URI של קובץ אימג' של Docker שמשמש כבסיס לקונטיינר. בוחרים תמונת בסיס שכוללת את יחסי התלות שנדרשים לקוד האימון.

    אפשר להשתמש ב-URI של קובץ אימג' של קונטיינר אימון מוכן מראש או בכל ערך אחר שתקף עבור הוראה בקובץ Dockerfile‏ FROM. לדוגמה, קובץ אימג' של Docker שזמין לציבור או קובץ אימג' של Docker ב-Artifact Registry שיש לכם גישה אליו.

  • ‫WORKING_DIRECTORY: הספרייה ברמה הנמוכה ביותר במערכת הקבצים שמכילה את כל קוד האימון והתלות המקומית שצריך להשתמש בהם לאימון.

    כברירת מחדל, הפקודה מעתיקה רק את ספריית האם של הקובץ שצוין באמצעות הדגל --script (ראו את הפריט הבא ברשימה) אל קובץ אימג' של Docker שמתקבל. קובץ אימג' של Docker לא כולל בהכרח את כל הקבצים ב-WORKING_DIRECTORY. כדי להתאים אישית את הקבצים שייכללו, אפשר לעיין בקטע במאמר העזרה הזה בנושא הכללת תלות.

    אם לא מציינים את הדגל --local-package-path (ואת ה-placeholder הזה), הפקודה local-run משתמשת בספריית העבודה הנוכחית בשביל הערך הזה.

  • ‫SCRIPT_PATH: הנתיב, ביחס ל-WORKING_DIRECTORY במערכת הקבצים המקומית, לסקריפט שמשמש כנקודת הכניסה לקוד האימון. זה יכול להיות סקריפט Python (שמסתיים ב-.py) או סקריפט Bash.

    לדוגמה, אם רוצים להריץ את /hello-world/trainer/task.py והערך של WORKING_DIRECTORY הוא /hello-world, צריך להשתמש ב-trainer/task.py בשביל הערך הזה.

    אם מציינים סקריפט Python, תמונת הבסיס צריכה לכלול את Python. אם מציינים סקריפט Bash, תמונת הבסיס צריכה לכלול את Bash. (כל קונטיינרי האימון המוכנים מראש וקובצי אימג' רבים אחרים של Docker שזמינים לציבור כוללים את שני התלות האלה).

    במקום --script, צריך להשתמש ב---python-module

    אם משמיטים את האפשרות --script (ואת SCRIPT_PATH), צריך להשתמש באפשרות --python-module כדי לציין את השם של מודול Python ב-WORKING_DIRECTORY להרצה כנקודת הכניסה לאימון. לדוגמה, במקום --script=trainer/task.py, אפשר לציין --python-module=trainer.task.

    במקרה כזה, קובץ ה-Docker שנוצר טוען את הקוד שלכם כמודול ולא כסקריפט. כדאי להשתמש באפשרות הזו אם סקריפט נקודת הכניסה מייבא מודולים אחרים של Python ב-WORKING_DIRECTORY.

  • ‫OUTPUT_IMAGE_NAME: שם של קובץ אימג' של Docker שנוצר על ידי הפקודה. אפשר להשתמש בכל ערך שמתקבל על ידי הדגל -t של docker build.

    אם אתם מתכננים להעלות את התמונה ל-Artifact Registry בהמשך, כדאי להשתמש בשם תמונה שעומד בדרישות של Artifact Registry. (אפשר גם לתייג את התמונה בשמות נוספים בהמשך).

    אם לא מציינים את הדגל --output-image-uri (ואת הפלייס הולדר הזה), הפקודה local-run מתייגת את התמונה בשם שמבוסס על השעה הנוכחית ועל שם הקובץ של סקריפט נקודת הכניסה.

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

A training image is built.
Starting to run ...

הפקודה משתמשת מיד בקובץ האימג' של הקונטיינר כדי להפעיל קונטיינר במחשב המקומי. כשהקונטיינר יוצא, הפקודה מדפיסה את הפלט הבא:

A local run is finished successfully using custom image: OUTPUT_IMAGE_NAME

אפשרויות נוספות

בקטעים הבאים מפורטות אפשרויות נוספות שבהן אפשר להשתמש כדי להתאים אישית את ההתנהגות של הפקודה local-run.

התקנת יחסי תלות

קוד האימון יכול להסתמך על יחסי תלות כלשהם שהותקנו בתמונת הבסיס (לדוגמה, תמונות של קונטיינר אימון מוכן מראש כוללות ספריות Python רבות ללמידת מכונה), וגם על קבצים שכללתם בקובץ אימג' של Docker שנוצר על ידי הפקודה local-run.

כשמציינים סקריפט עם הדגל --script או הדגל --python-module, הפקודה מעתיקה את ספריית האב של הסקריפט (ואת ספריות המשנה שלה) לקובץ אימג' של Docker. לדוגמה, אם מציינים --local-package-path=/hello-world ו---script=trainer/task.py, הפקודה מעתיקה את /hello-world/trainer/ אל קובץ האימג' של Docker.

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

התקנה של יחסי תלות נוספים ב-Python

יש כמה דרכים לכלול תלות נוספת ב-Python בקובץ אימג' של Docker:

שימוש בקובץ requirements.txt

אם יש קובץ בשם requirements.txt בספריית העבודה, הפקודה local-run מתייחסת אליו כאל קובץ דרישות של pip ומשתמשת בו כדי להתקין תלות של Python בקובץ האימג' של Docker.

שימוש בקובץ setup.py

אם יש קובץ בשם setup.py בספריית העבודה, הפקודה local-run מתייחסת אליו כאל קובץ setup.py של Python, מעתיקה את הקובץ לקובץ האימג' של Docker ומריצה את הפקודה pip install בספרייה בקובץ האימג' של Docker שמכילה את הקובץ הזה.

לדוגמה, אפשר להוסיף install_requires ארגומנט ל-setup.py כדי להתקין תלות של Python בקובץ אימג' של Docker.

ציון יחסי תלות ספציפיים ב-PyPI

אפשר להשתמש בדגל --requirements כדי להתקין יחסי תלות ספציפיים מ-PyPI בקובץ האימג' של Docker. לדוגמה:

gcloud ai custom-jobs local-run \
  --executor-image-uri=BASE_IMAGE_URI \
  --local-package-path=WORKING_DIRECTORY \
  --script=SCRIPT_PATH \
  --output-image-uri=OUTPUT_IMAGE_NAME \
  --requirements=REQUIREMENTS

מחליפים את REQUIREMENTS ברשימה מופרדת בפסיקים של מגדירי דרישות של Python.

ציון יחסי תלות מקומיים נוספים של Python

אפשר להשתמש בדגל --extra-packages כדי להתקין תלות מקומית ספציפית של Python. יחסי התלות האלה של Python צריכים להיות בספריית העבודה, וכל יחס תלות צריך להיות בפורמט ש-pip install תומך בו. לדוגמה, קובץ wheel או הפצה של מקור Python.

לדוגמה:

gcloud ai custom-jobs local-run \
  --executor-image-uri=BASE_IMAGE_URI \
  --local-package-path=WORKING_DIRECTORY \
  --script=SCRIPT_PATH \
  --output-image-uri=OUTPUT_IMAGE_NAME \
  --extra-packages=LOCAL_DEPENDENCIES

מחליפים את LOCAL_DEPENDENCIES ברשימה מופרדת בפסיקים של נתיבי קבצים מקומיים, שמוצגים ביחס לספריית העבודה.

הוספת קבצים אחרים

כדי להעתיק ספריות נוספות לקובץ אימג' של Docker (בלי להתקין אותן כתלות ב-Python), אפשר להשתמש בדגל --extra-dirs. אפשר לציין רק ספריות מתחת לספריית העבודה. לדוגמה:

gcloud ai custom-jobs local-run \
  --executor-image-uri=BASE_IMAGE_URI \
  --local-package-path=WORKING_DIRECTORY \
  --script=SCRIPT_PATH \
  --output-image-uri=OUTPUT_IMAGE_NAME \
  --extra-dirs=EXTRA_DIRECTORIES

מחליפים את EXTRA_DIRECTORIES ברשימה מופרדת בפסיקים של ספריות מקומיות, שמוצגות ביחס לספריית העבודה.

טיעונים לאימון אפליקציות

אם סקריפט נקודת הכניסה של אפליקציית האימון מצפה לארגומנטים של שורת הפקודה, אפשר לציין אותם כשמריצים את הפקודה local-run. הארגומנטים האלה לא נשמרים בקובץ האימג' של Docker, אלא מועברים כארגומנטים כשהאימג' מופעל כקונטיינר.

כדי להעביר ארגומנטים לסקריפט של נקודת הכניסה, מעבירים את הארגומנט -- ואחריו את הארגומנטים של הסקריפט לפקודה local-run אחרי כל הדגלים האחרים של הפקודה.

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

python /hello-world/trainer/task.py \
  --learning_rate=0.1 \
  --input_data=gs://BUCKET/small-dataset/

כשמשתמשים בפקודה local-run, אפשר להשתמש בדגלים הבאים כדי להריץ את הסקריפט במאגר עם אותם ארגומנטים:

gcloud ai custom-jobs local-run \\
  --executor-image-uri=BASE_IMAGE_URI \
  --local-package-path=/hello-world \
  --script=/trainer/task.py \
  --output-image-uri=OUTPUT_IMAGE_NAME \
  -- \
  --learning_rate=0.1 \
  --input_data=gs://BUCKET/small-dataset/

האצת אימון המודלים באמצעות יחידות GPU

אם אתם רוצים בסופו של דבר לפרוס את קובץ האימג' של Docker שנוצר באמצעות הפקודה local-run ב-Agent Platform ולהשתמש במעבדי GPU לאימון, הקפידו לכתוב קוד אימון שמנצל את מעבדי ה-GPU ולהשתמש בקובץ אימג' של Docker עם מעבד GPU בתור הערך של הדגל --executor-image-uri. לדוגמה, אפשר להשתמש באחת מתמונות הקונטיינר לאימון שנוצר מראש שתומכות ב-GPU.

אם במחשב המקומי שלכם מותקנת מערכת Linux ויש בו כרטיסי GPU, אתם יכולים גם להגדיר את הפקודה local-run כך שתשתמש בכרטיסי ה-GPU כשמריצים קונטיינר באופן מקומי. השלב הזה הוא אופציונלי, אבל הוא יכול להיות שימושי אם רוצים לבדוק איך קוד האימון פועל עם מעבדים גרפיים. צריך לבצע את הפעולות הבאות:

  1. אם עדיין לא עשיתם זאת, מתקינים את NVIDIA Container Toolkit (nvidia-docker) במחשב המקומי.

  2. מציינים את הדגל --gpu כשמריצים את הפקודה local-run. לדוגמה:

    gcloud ai custom-jobs local-run \
  --executor-image-uri=BASE_IMAGE_URI \
  --local-package-path=WORKING_DIRECTORY \
  --script=SCRIPT_PATH \
  --output-image-uri=OUTPUT_IMAGE_NAME \
  --gpu

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

כברירת מחדל, כשמריצים את פקודת local-run כדי להפעיל את קוד האימון במאגר מקומי, פרטי הכניסה שזמינים בסביבה המקומית מועברים למאגר באמצעות Application Default Credentials (ADC), כדי שקוד האימון יוכל להשתמש ב-ADC לאימות עם אותם פרטי כניסה. Google Cloud במילים אחרות, פרטי הכניסה שזמינים ל-ADC במעטפת המקומית שלכם זמינים גם ל-ADC בקוד שלכם כשמריצים את הפקודה local-run.

אתם יכולים להשתמש בפקודה gcloud auth application-default login כדי להשתמש בחשבון המשתמש שלכם ל-ADC, או להגדיר משתנה סביבה במעטפת כדי להשתמש בחשבון שירות ל-ADC.

אם רוצים שהקונטיינר יפעל עם פרטי כניסה שונים מאלה שזמינים באמצעות ADC במעטפת המקומית, צריך לבצע את הפעולות הבאות: Google Cloud

  1. יוצרים או בוחרים חשבון שירות עם ההרשאות שרוצים שלקוד האימון תהיה גישה אליהן.

  2. מורידים מפתח של חשבון שירות לחשבון השירות הזה למחשב המקומי.

  3. כשמריצים את הפקודה local-run, מציינים את הדגל --service-account-key-file. לדוגמה:

    gcloud ai custom-jobs local-run \
  --executor-image-uri=BASE_IMAGE_URI \
  --local-package-path=WORKING_DIRECTORY \
  --script=SCRIPT_PATH \
  --output-image-uri=OUTPUT_IMAGE_NAME \
  --service-account-key-file=KEY_PATH

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

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

השוואה לאימון ב-Agent Platform

כשמבצעים אימון ללא שרת ב-Agent Platform,‏ Agent Platform משתמש בסוכן של שירות קוד בהתאמה אישית של Gemini Enterprise Agent Platform עבור הפרויקט כברירת מחדל כדי להריץ את הקוד. אפשר גם לצרף חשבון שירות אחר לאימון ללא שרת.

כשמשתמשים בפקודה local-run, אי אפשר לבצע אימות כסוכן שירות של שירות הקוד בהתאמה אישית של Gemini Enterprise Agent Platform, אבל אפשר ליצור חשבון שירות עם הרשאות דומות ולהשתמש בו באופן מקומי.

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