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

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

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

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

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

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

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

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

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

  1. הגדרת סביבת הפיתוח של Vertex AI

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

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

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

משתמשים בפקודה 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 שנוצר על ידי הפקודה. אפשר להשתמש בכל ערך שמתקבל על ידי הדגל docker build's -t.

    אם אתם מתכננים להעביר את התמונה ל-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 ב-Vertex AI ולהשתמש ב-GPU לאימון, צריך לוודא שכותבים קוד אימון שמנצל את ה-GPU ומשתמשים בקובץ אימג' של Docker עם GPU לערך של הדגל --executor-image-uri. לדוגמה, אפשר להשתמש באחת מתמונות הקונטיינר לאימון שנוצר מראש שתומכות ב-GPU.

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

השוואה לאימון ב-Vertex AI

כשמבצעים אימון בלי שרת (serverless) ב-Vertex AI, מערכת Vertex AI משתמשת כברירת מחדל בסוכן שירות של קוד בהתאמה אישית של Vertex AI עבור הפרויקט כדי להריץ את הקוד. אפשר גם לצרף חשבון שירות אחר לאימון ללא שרת.

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

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