הכנת קוד האימון

אתם יכולים לבצע אימון בלי שרת (serverless) ב-Gemini Enterprise Agent Platform כדי להריץ קוד אימון משלכם ללמידת מכונה (ML) בענן, במקום להשתמש ב-AutoML. במאמר הזה מתוארות שיטות מומלצות שכדאי להביא בחשבון כשכותבים קוד אימון.

בחירת מבנה קוד האימון

קודם כל, צריך להחליט מה יהיה המבנה של קוד האימון של ה-ML. אתם יכולים לספק קוד אימון ל-Agent Platform באחת מהדרכים הבאות:

  • סקריפט Python לשימוש עם קונטיינר מוגדר מראש. משתמשים ב-Agent Platform SDK כדי ליצור משימה ייעודית. בשיטה הזו, אתם יכולים לספק את אפליקציית האימון כסקריפט Python אחד.

  • אפליקציית אימון ב-Python לשימוש עם קונטיינר מוגדר מראש. יוצרים הפצה של קוד מקור ב-Python עם קוד שמאמן מודל ML ומייצא אותו ל-Cloud Storage. אפליקציית האימון הזו יכולה להשתמש בכל אחד מיחסי התלות שכלולים בקונטיינר שהוגדר מראש, שבו אתם מתכננים להשתמש.

    האפשרות הזו מתאימה אם אחד מהקונטיינרים המוגדרים מראש לאימון של Agent Platform כולל את כל יחסי התלות שאתם צריכים לאימון. לדוגמה, אם אתם רוצים לאמן באמצעות PyTorch,‏ scikit-learn,‏ TensorFlow או XGBoost, סביר להניח שזו האפשרות הטובה יותר.

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

  • קובץ אימג' של קונטיינר בהתאמה אישית. יוצרים קובץ אימג' של קונטיינר Docker עם קוד שמאמן מודל ML ומייצא אותו ל-Cloud Storage. כללו בקובץ האימג' של הקונטיינר את כל יחסי התלות שהקוד שלכם דורש.

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

    במדריך יצירת קובץ אימג' של קונטיינר בהתאמה אישית מפורטות השיטות המומלצות הספציפיות לאפשרות הזו.

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

שיטות מומלצות לכל קוד אימון ללא שרת (serverless)

כשאתם כותבים קוד אימון בלי שרת (serverless) ל-Agent Platform, חשוב לזכור שהקוד יפעל במכונה וירטואלית (VM) אחת או יותר שמנוהלת על ידיGoogle Cloud. בקטע הזה מתוארות שיטות מומלצות שרלוונטיות לכל קוד אימון בהתאמה אישית.

גישה לשירותי Google Cloud בקוד

בחלק מהקטעים הבאים מתוארת גישה לשירותי Google Cloudאחרים מהקוד שלכם. כדי לגשת לשירותי Google Cloud , צריך לכתוב את קוד האימון כך שישתמש ב-Application Default Credentials (‏ADC). הרבה Google Cloud ספריות לקוח מבצעות אימות באמצעות ADC כברירת מחדל. אתם לא צריכים להגדיר משתני סביבה. Agent Platform מגדירה באופן אוטומטי את ADC לאימות בתור סוכן השירות של Gemini Enterprise Agent Platform Custom Code בפרויקט (כברירת מחדל) או בתור חשבון שירות בהתאמה אישית (אם הגדרתם אחד כזה).

עם זאת, כשמשתמשים ב Google Cloud ספריית לקוח בקוד, יכול להיות ש-Agent Platform לא תמיד תתחבר כברירת מחדל לGoogle Cloud הפרויקט הנכון. אם נתקלתם בשגיאות שקשורות להרשאות, יכול להיות שהבעיה היא שהתחברתם לפרויקט הלא נכון.

הבעיה הזו מתרחשת כי פלטפורמת הסוכנים לא מריצה את הקוד ישירות בפרויקט Google Cloud . במקום זאת, פלטפורמת Agent מריצה את הקוד באחד מכמה פרויקטים נפרדים שמנוהלים על ידי Google. פלטפורמת Agent משתמשת בפרויקטים האלה רק לפעולות שקשורות לפרויקט שלכם. לכן, אל תנסו להסיק את מזהה הפרויקט מהסביבה בקוד האימון או ההסקה, אלא ציינו את מזהי הפרויקטים באופן מפורש.

אם אתם לא רוצים להוסיף מזהה פרויקט באופן ידני לקוד האימון, אתם יכולים להפנות למשתנה הסביבה CLOUD_ML_PROJECT_ID: פלטפורמת Agent מגדירה את משתנה הסביבה הזה בכל קונטיינר אימון ללא שרת, כך שיכיל את מספר הפרויקט שבו התחלתם את האימון ללא שרת. בהרבה כלים של Google Cloud אפשר להשתמש במספר הפרויקט במקום במזהה הפרויקט.

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

בחירת פרויקט משתמעת

from google.cloud import bigquery

client = bigquery.Client()

במקום זאת, השתמשו בקוד שבוחר פרויקט באופן מפורש:

בחירת פרויקט מפורש

import os

from google.cloud import bigquery

project_number = os.environ["CLOUD_ML_PROJECT_ID"]

client = bigquery.Client(project=project_number)

אם נתקלתם בשגיאות הרשאה אחרי שהגדרתם את הקוד בדרך הזו, קראו את הקטע הבא בנושא לאילו משאבים הקוד יכול לגשת כדי לשנות את ההרשאות שזמינות לקוד האימון.

לאילו משאבים הקוד יכול לגשת

כברירת מחדל, לאפליקציית האימון יש גישה לכל המשאבים של Google Cloud סוכן השירות של Gemini Enterprise Agent Platform Custom Code Service Agent (CCSA) בפרויקט. כדי לתת ל-CCSA, וכתוצאה מכך גם לאפליקציית האימון, גישה למספר מוגבל של משאבים אחרים, פועלים לפי ההוראות במאמר מתן גישה לסוכני שירות של Gemini Enterprise Agent Platform למשאבים אחרים. אם אפליקציית האימון שלכם צריכה יותר מגישה ברמת קריאה למשאבי Google Cloudשלא מופיעים בדף הזה, היא צריכה לקבל אסימון גישה מסוג OAuth 2.0 עם ההיקף https://www.googleapis.com/auth/cloud-platform, שאפשר לעשות רק באמצעות חשבון שירות בהתאמה אישית.

לדוגמה, נניח שקוד האימון שלכם ניגש למשאבים של Cloud Storage:

כברירת מחדל, ל-Agent Platform יש גישה לכל קטגוריה של Cloud Storage בפרויקט ב- Google Cloud שבו אתם מבצעים אימון ללא שרת (serverless). אתם יכולים גם לתת ל-Agent Platform גישה לקטגוריות של Cloud Storage בפרויקטים אחרים, או להשתמש בחשבון שירות בהתאמה אישית כדי להתאים אישית את הקטגוריות שאליהן יש גישה למשימה ספציפית.

קריאה וכתיבה של קובצי Cloud Storage באמצעות Cloud Storage FUSE

בכל משימות האימון ללא שרת (serverless), פלטפורמת Agent טוענת קטגוריות של Cloud Storage שיש לכם גישה אליהן בספרייה /gcs/ של מערכת הקבצים של כל צומת אימון. כחלופה נוחה לשימוש בלקוח Python ל-Cloud Storage או בספרייה אחרת כדי לגשת ל-Cloud Storage, אתם יכולים לקרוא ולכתוב ישירות במערכת הקבצים המקומית כדי לקרוא נתונים מ-Cloud Storage או לכתוב נתונים ב-Cloud Storage. לדוגמה, כדי לטעון נתונים מ-gs://BUCKET/data.csv, אפשר להשתמש בקוד Python הבא:

file = open('/gcs/BUCKET/data.csv', 'r')

פלטפורמת הסוכנים משתמשת ב-Cloud Storage FUSE כדי לטעון את קטגוריות האחסון. שימו לב שספריות שנטענות על ידי Cloud Storage FUSE לא תואמות ל-POSIX.

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

טעינת נתוני הקלט

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

אתם יכולים לטעון נתונים מקבוצת נתונים שמנוהלת ב-Agent Platform או לכתוב קוד משלכם כדי לטעון נתונים ממקור מחוץ ל-Agent Platform, כמו BigQuery או Cloud Storage.

כדי להשיג את הביצועים הטובים ביותר כשאתם טוענים נתונים מ-Cloud Storage, השתמשו בקטגוריה באזור שבו אתם מבצעים אימון ללא שרת (serverless). במאמרים יצירת קטגוריות אחסון והעלאת אובייקטים מוסבר איך לאחסן נתונים ב-Cloud Storage.

כדי לדעת מאילו קטגוריות של Cloud Storage אפשר לטעון נתונים, קראו את החלק הקודם בנושא לאילו משאבים הקוד יכול לגשת.

כדי לטעון נתונים מ-Cloud Storage בקוד האימון, אתם יכולים להשתמש בתכונה Cloud Storage FUSE שמתוארת בקטע הקודם או בכל ספרייה שתומכת ב-ADC. לא צריך לספק במפורש פרטי כניסה לאימות בקוד.

לדוגמה, אתם יכולים להשתמש באחת מספריות הלקוח שמוצגות במדריך של Cloud Storage בנושא הורדת אובייקטים. לקוח Python ל-Cloud Storage, בפרט, כלול בקונטיינרים מוגדרים מראש. גם הכיתה tf.io.gfile.GFile של TensorFlow תומכת ב-ADC.

טעינה של מערך נתונים גדול

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

אם אתם צריכים לקרוא נתונים שגדולים מדי בשביל הזיכרון, אתם יכולים להעביר אותם בסטרימינג או לקרוא אותם באופן מצטבר. לכל מסגרת של למידת מכונה יש שיטות מומלצות שונות לביצוע הפעולה הזו. לדוגמה, הכיתה tf.data.Dataset של TensorFlow יכולה להעביר נתוני TFRecord או נתוני טקסט בסטרימינג מ-Cloud Storage.

דרך נוספת לצמצם את כמות הנתונים שכל מכונה וירטואלית טוענת לזיכרון היא לבצע אימון בלי שרת (serverless) בכמה מכונות וירטואליות עם מקביליות נתונים. כתיבת קוד לאימון מבוזר

ייצוא של מודל ML מאומן

בדרך כלל, קוד ML מייצא מודל מאומן בסוף האימון בצורה של פריט מידע שנוצר בתהליך פיתוח (Artifact) אחד או יותר שנוצר על ידי המודל. לאחר מכן תוכלו להשתמש בארטיפקטים של המודל כדי לקבל הסקות.

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

מומלץ לייצא פריטי מידע שנוצרו בתהליך הפיתוח (Artifact) של המודל לקטגוריה של Cloud Storage. כמו שמוסבר בקטע הקודם, לאילו משאבים הקוד יכול לגשת, ל-Agent Platform יש גישה לכל קטגוריה של Cloud Storage בפרויקט ב- Google Cloud שבו אתם מבצעים אימון ללא שרת. משתמשים בספרייה שתומכת ב-ADC כדי לייצא את פריטי המידע שנוצרו מהמודל. לדוגמה, ממשקי ה-API של TensorFlow לשמירת מודלים של Keras יכולים לייצא פריטי מידע שנוצרו בתהליך הפיתוח (Artifact) ישירות לנתיב של Cloud Storage.

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

משתני סביבה לספריות מיוחדות ב-Cloud Storage

אם מציינים את השדה baseOutputDirectory ב-API, ‏Agent Platform מגדיר את משתני הסביבה הבאים כשהוא מריץ את קוד האימון:

הערכים של משתני הסביבה האלה שונים מעט בהתאם לשימוש בכוונון היפר-פרמטרים. מידע נוסף זמין במאמרי העזרה של ה-API של baseOutputDirectory.

השימוש במשתני הסביבה האלה מאפשר לעשות שימוש חוזר באותו קוד אימון כמה פעמים – למשל עם אפשרויות שונות של נתונים או הגדרות – ולשמור פריטי מידע שנוצרו בתהליך הפיתוח (artifact) ונקודות ביקורת של המודל במיקומים שונים, רק על ידי שינוי השדה baseOutputDirectory ב-API. עם זאת, אתם לא חייבים להשתמש במשתני הסביבה בקוד אם אתם לא רוצים. לדוגמה, אפשר להגדיר בקוד את המיקומים לשמירת נקודות הבקרה ולייצוא פריטי המידע שנוצרו על ידי המודל.

בנוסף, אם אתם משתמשים ב-TrainingPipeline לאימון בהתאמה אישית ולא מציינים את השדה modelToUpload.artifactUri, פלטפורמת Agent משתמשת בערך של משתנה הסביבה AIP_MODEL_DIR בשביל modelToUpload.artifactUri. (לכוונון של היפר-פרמטרים, פלטפורמת Agent משתמשת בערך של משתנה הסביבה AIP_MODEL_DIR מהניסיון הכי טוב).

עמידות בהפעלות מחדש

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

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

  • כדאי לייצא את התקדמות האימון ל-Cloud Storage לעיתים קרובות, לפחות פעם בארבע שעות, כדי לא לאבד את ההתקדמות אם המכונות הווירטואליות יופעלו מחדש.

  • בתחילת קוד האימון, בודקים אם כבר קיימת התקדמות באימון במיקום הייצוא. במקרה כזה, טוענים את מצב האימון השמור במקום להתחיל את האימון מההתחלה.

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

האופן שבו מבצעים את הפעולות האלה תלוי במסגרת ה-ML שבה משתמשים. לדוגמה, אם אתם משתמשים ב-TensorFlow Keras, כאן מוסבר איך להשתמש בקריאה החוזרת (callback) של ModelCheckpoint למטרה הזו.

למידע נוסף על האופן שבו Agent Platform מנהלת מכונות וירטואליות, קראו את המאמר הסבר על שירות האימון בהתאמה אישית.

שיטות מומלצות לשימוש בתכונות האופציונליות של אימון בלי שרת (serverless)

אם אתם רוצים להשתמש בתכונות אופציונליות מסוימות של אימון ללא שרת, יכול להיות שתצטרכו לבצע שינויים נוספים בקוד האימון. בקטע הזה מתוארות שיטות מומלצות לכתיבת קוד לכוונון היפר-פרמטרים, ליחידות GPU, לאימון מבוזר ול-Vertex AI TensorBoard.

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

אתם יכולים להפעיל רישום אוטומטי ביומן באמצעות Agent Platform SDK ל-Python כדי לתעד באופן אוטומטי פרמטרים ומדדים לבדיקת ביצועים כשאתם שולחים את המשימה הייעודית. למידע נוסף, ראו הפעלת משימת אימון עם מעקב אחרי ניסויים.

כתיבת קוד להחזרת יומני קונטיינרים

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

רוב המפתחים צפויים לכתוב יומנים באמצעות פלט סטנדרטי (stdout) ושגיאה סטנדרטית (stderr).

יומני הקונטיינרים שנכתבים במיקומים הנתמכים האלה משויכים באופן אוטומטי לשירות, לגרסה ולמיקום של האימון ללא שרת (serverless) ב-Gemini Enterprise Agent Platform, או למשימת האימון ללא שרת (serverless). חריגות שכלולות ביומנים האלה מתועדות ומדווחות ב-Error Reporting.

שימוש בטקסט פשוט לעומת JSON מובנה ביומנים

כשכותבים יומנים, אפשר לשלוח מחרוזת טקסט פשוט או שורה אחת של JSON שעבר סריאליזציה, שנקרא גם נתונים "מובְנים". ההודעה נאספת ומנותחת על ידי Cloud Logging, ומוצבת ב-jsonPayload. לעומת זאת, ההודעה בטקסט פשוט ממוקמת ב-textPayload.

כתיבת יומנים מובְנים

יש כמה דרכים להעביר יומני JSON מובְנים. הדרכים הנפוצות ביותר הן באמצעות ספריית הרישום ביומן של Python או באמצעות העברת נתוני JSON גולמיים באמצעות print.

ספריית רישום ביומן של Python

import json
import logging
from pythonjsonlogger import jsonlogger

class CustomJsonFormatter(jsonlogger.JsonFormatter):
 """Formats log lines in JSON."""
  def process_log_record(self, log_record):
    """Modifies fields in the log_record to match Cloud Logging's expectations."""
    log_record['severity'] = log_record['levelname']
    log_record['timestampSeconds'] = int(log_record['created'])
    log_record['timestampNanos'] = int(
        (log_record['created'] % 1) * 1000 * 1000 * 1000)

    return log_record

def configure_logger():
  """Configures python logger to format logs as JSON."""
  formatter = CustomJsonFormatter(
        '%(name)s|%(levelname)s|%(message)s|%(created)f'
        '|%(lineno)d|%(pathname)s', '%Y-%m-%dT%H:%M:%S')
  root_logger = logging.getLogger()
  handler = logging.StreamHandler()
  handler.setFormatter(formatter)
  root_logger.addHandler(handler)
  root_logger.setLevel(logging.WARNING)

logging.warning("This is a warning log")

‫JSON גולמי

import json

def log(severity, message):
  global_extras = {"debug_key": "debug_value"}
  structured_log = {"severity": severity, "message": message, **global_extras}
  print(json.dumps(structured_log))

def main(args):
  log("DEBUG", "Debugging the application.")
  log("INFO", "Info.")
  log("WARNING", "Warning.")
  log("ERROR", "Error.")
  log("CRITICAL", "Critical.")

שדות JSON מיוחדים בהודעות

כשמספקים יומן מובנה כמילון JSON, חלק מהשדות המיוחדים מוסרים מ-jsonPayload ונכתבים בשדה התואם ב-LogEntry שנוצר, כפי שמתואר במסמכי התיעוד של השדות המיוחדים.

לדוגמה, אם קובץ ה-JSON כולל מאפיין severity, הוא יוסר מ-jsonPayload ויופיע במקום זאת בתור severity של רשומת היומן. אם המאפיין message קיים, הוא משמש כטקסט התצוגה הראשי של רשומת היומן.

קישור בין יומני הקונטיינר ליומן הבקשות (שירותים בלבד)

ב-Logs Explorer, אפשר לראות את היומנים שקשורים לאותו trace בפורמט "הורה-צאצא": כשלוחצים על סמל המשולש שמימין לרשומת יומן הבקשות, יומני הקונטיינרים שקשורים לבקשה הזו מופיעים כשהם מוטמעים מתחת ליומן הבקשות.

יומני קונטיינרים לא משויכים באופן אוטומטי ליומני בקשות, אלא אם משתמשים בספריית לקוח של Cloud Logging. כדי לקשר בין יומני קונטיינרים ליומני בקשות בלי להשתמש בספריית לקוח, אתם יכולים להשתמש בשורת יומן מובנית בפורמט JSON שמכילה את השדה logging.googleapis.com/trace עם מזהה המעקב שחולץ מהכותרת X-Cloud-Trace-Context.

צפייה ביומנים

כדי להציג את יומני הקונטיינר במסוף Google Cloud :

  1. במסוף Google Cloud , נכנסים לדף משימות ייעודיות של Gemini Enterprise Agent Platform.

    כניסה לדף Custom jobs

  2. לוחצים על השם של המשימה המותאמת אישית שרוצים לראות את היומנים שלה.

  3. לוחצים על הצגת יומנים.

כתיבת קוד לכוונון היפר-פרמטרים

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

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

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

  • מדווחים לסירוגין על מדד כוונון ההיפר-פרמטרים ל-Agent Platform.

ניתוח ארגומנטים של שורת הפקודה

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

מומלץ להשתמש בספרייה argparse של Python כדי לנתח ארגומנטים של שורת הפקודה.

דיווח על מדד כוונון ההיפר-פרמטרים

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

משתמשים בספריית Python של cloudml-hypertune כדי לדווח על מדד כוונון ההיפר-פרמטרים. הספרייה הזו כלולה בכל הקונטיינרים המוגדרים מראש לאימון, ואפשר להשתמש ב-pip כדי להתקין אותה בקונטיינר בהתאמה אישית.

כדי ללמוד איך להתקין את הספרייה הזו ולהשתמש בה, קראו את המאגר של cloudml-hypertune ב-GitHub או את ה-Codelab בנושא Agent Platform: Hyperparameter Tuning.

כתיבת קוד ל-GPU

אתם יכולים לבחור מכונות וירטואליות עם יחידות עיבוד גרפיות (GPU) כדי להריץ את קוד האימון בהתאמה אישית. איך מגדירים אימון ללא שרת (serverless) לשימוש במכונות וירטואליות עם GPU

אם אתם רוצים לאמן באמצעות GPUs, ודאו שקוד האימון שלכם יכול לנצל אותם. בהתאם למסגרת ה-ML שבה אתם משתמשים, יכול להיות שתצטרכו לשנות את הקוד. לדוגמה, אם אתם משתמשים ב-TensorFlow Keras, אתם צריכים לשנות את הקוד רק אם אתם רוצים להשתמש ביותר מ-GPU אחד. בחלק ממסגרות ה-ML אי אפשר להשתמש ב-GPU בכלל.

בנוסף, ודאו שהקונטיינר תומך במעבדי GPU: בחרו קונטיינר מובנה לאימון שתומך במעבדי GPU, או התקינו את NVIDIA CUDA Toolkit ואת NVIDIA cuDNN בקונטיינר בהתאמה אישית. אפשר לעשות את זה באמצעות קובץ אימג' בסיסי ממאגר Docker של nvidia/cuda, או להשתמש במכונה של קונטיינרים של למידה עמוקה (Deep Learning) כקובץ אימג' בסיסי.

כתיבת קוד לאימון מבוזר

כדי לאמן על מערכי נתונים גדולים, אתם יכולים להריץ את הקוד בכמה מכונות וירטואליות באשכול מבוזר שמנוהל על ידי Agent Platform. איך מגדירים כמה מכונות וירטואליות לאימון

בחלק ממסגרות ה-ML, כמו TensorFlow ו-PyTorch, אפשר להריץ קוד אימון זהה בכמה מכונות, שמתאמות באופן אוטומטי את חלוקת העבודה על סמך משתני סביבה שמוגדרים בכל מכונה. כדאי לבדוק אם Agent Platform מגדירה משתני סביבה כדי לאפשר את זה למסגרת ה-ML.

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

מעקב אחרי ניסויים של אימון מודלים בלי שרת (serverless) והצגה שלהם באמצעות Vertex AI TensorBoard

‫Vertex AI TensorBoard הוא גרסה מנוהלת של TensorBoard, פרויקט קוד פתוח של Google להצגה חזותית של ניסויים בלמידת מכונה. בעזרת Vertex AI TensorBoard אתם יכולים לעקוב אחרי ניסויים בלמידת מכונה, להציג אותם חזותית, להשוות ביניהם ולשתף אותם עם הצוות. אתם יכולים גם להשתמש ב-Cloud Profiler כדי לאתר ולתקן צווארי בקבוק בביצועים, וכך לאמן מודלים מהר יותר ובעלות נמוכה יותר.

כדי להשתמש ב-Vertex AI TensorBoard עם אימון ללא שרת (serverless), צריך לבצע את הפעולות הבאות:

  • יוצרים מכונה של Vertex AI TensorBoard בפרויקט כדי לאחסן את הניסויים (ראו יצירת מכונה של TensorBoard).

  • מגדירים חשבון שירות כדי להריץ את משימת האימון ללא שרת עם ההרשאות המתאימות.

  • משנים את קוד האימון ללא שרת (serverless) כדי לכתוב יומנים שתואמים ל-TensorBoard ב-Cloud Storage (ראו שינויים בסקריפט האימון).

במדריך המפורט שימוש ב-Vertex AI TensorBoard עם אימון ללא שרת (serverless) מוסבר איך עושים את זה.

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