כדי להשתמש בקונטיינר בהתאמה אישית להסקת מסקנות ממודל באימון מותאם אישית, צריך לספק ל-Gemini Enterprise Agent Platform קובץ אימג' של קונטיינר Docker שמריץ שרת HTTP. במאמר הזה מפורטות הדרישות שקובץ אימג' של קונטיינר צריך לעמוד בהן כדי להתאים ל-Gemini Enterprise Agent Platform. בנוסף, מתואר איך Agent Platform פועלת עם הקונטיינר בהתאמה אישית אחרי שהיא מתחילה לפעול. במילים אחרות, במאמר הזה מוסבר מה צריך להביא בחשבון כשמתכננים קובץ אימג' של קונטיינר לשימוש עם Agent Platform.
במאמר שימוש בקונטיינר בהתאמה אישית מוסבר איך משתמשים בקובץ אימג' של קונטיינר בהתאמה אישית כדי להציג הסקות.
הדרישות לגבי קובצי אימג' של קונטיינרים
כשקובץ האימג' של הקונטיינר של Docker פועל כקונטיינר, הקונטיינר צריך להריץ שרת HTTP. באופן ספציפי, הקונטיינר צריך להאזין ולהגיב לבדיקות תקינות, לבדיקות פעילות ולבקשות להסקת מסקנות. בסעיפי המשנה הבאים מפורטות הדרישות האלה.
אתם יכולים להטמיע את שרת ה-HTTP בכל דרך ובכל שפת תכנות, כל עוד הוא עומד בדרישות שמפורטות בקטע הזה. לדוגמה, אתם יכולים לכתוב שרת HTTP בהתאמה אישית באמצעות מסגרת אינטרנט כמו Flask, או להשתמש בתוכנה להצגת מודעות שמבוססת על למידת מכונה (ML) ומפעילה שרת HTTP, כמו TensorFlow Serving, TorchServe או KServe Python Server.
מפעילים את שרת ה-HTTP
כדי להריץ שרת HTTP, אפשר להשתמש בהוראה ENTRYPOINT, בהוראה CMD או בשתיהן בקובץ ה-Dockerfile שמשמש ליצירת קובץ האימג' של הקונטיינר. מידע על האינטראקציה בין CMD לבין ENTRYPOINT.
לחלופין, אפשר לציין את השדות containerSpec.command ו-containerSpec.args כשיוצרים את המשאב Model, כדי לשנות את ENTRYPOINT ו-CMD של קובץ האימג' של הקונטיינר, בהתאמה. אם מציינים את אחד מהשדות האלה, אפשר להשתמש בקובץ אימג' של קונטיינר שלא עומד בדרישות בגלל ENTRYPOINT או CMD לא תואמים (או לא קיימים).
לא משנה איך אתם קובעים איזו פקודה הקונטיינר יריץ כשהוא יתחיל לפעול, ודאו שההוראה ENTRYPOINT הזו תרוץ ללא הגבלת זמן. לדוגמה, אל תריצו פקודה שמפעילה שרת HTTP ברקע ואז יוצאת. אם תעשו את זה, המאגר ייצא מיד אחרי שהוא יתחיל לפעול.
שרת ה-HTTP צריך להאזין לבקשות ב-0.0.0.0, ביציאה לבחירתכם. כשאתם יוצרים Model, ציינו את היציאה הזו בשדה containerSpec.ports.
כדי ללמוד איך הקונטיינר יכול לגשת לערך הזה, קראו את הקטע במסמך הזה שעוסק במשתנה הסביבה AIP_HTTP_PORT.
בדיקות מצב הפעילות (liveness)
כשהקונטיינר מופעל, Agent Platform מבצעת בדיקת פעילות כדי לוודא שהשרת פועל. כשפורסים מודל באימון מותאם אישית במשאב Endpoint, פלטפורמת Agent משתמשת בבדיקת תקינות של TCP כדי לנסות ליצור חיבור TCP לקונטיינר ביציאה שהוגדרה. הבדיקה מנסה ליצור חיבור עד 4 פעמים, וממתינה 10 שניות אחרי כל כישלון. אם הבדיקה עדיין לא יצרה חיבור בשלב הזה, פלטפורמת הסוכן תפעיל מחדש את הקונטיינר.
שרת ה-HTTP לא צריך לבצע פעולה מיוחדת כדי לטפל בבדיקות האלה. כל עוד הוא מאזין לבקשות ביציאה שהוגדרה, בדיקת החיות יכולה ליצור חיבור.
בדיקות תקינות
אפשר לציין startup_probe או health_probe.
בדיקת ההפעלה בודקת אם אפליקציית הקונטיינר הופעלה. אם לא מספקים בדיקת סטארט-אפ, אין בדיקת סטארט-אפ ובדיקות התקינות מתחילות מיד. אם מספקים בדיקת הפעלה, בדיקות התקינות לא מתבצעות עד שבדיקת ההפעלה מצליחה.
באפליקציות מדור קודם, שבהן יכול להיות שיידרש זמן הפעלה נוסף באתחול הראשון, צריך להגדיר בדיקת הפעלה. לדוגמה, אם האפליקציה צריכה להעתיק את פריטי המידע שנוצרו בתהליך הפיתוח של המודל ממקור חיצוני, צריך להגדיר בדיקת סטארט-אפ שתחזיר הצלחה כשההפעלה תושלם.
בדיקת התקינות בודקת אם מאגר מוכן לקבל תנועה. אם לא תספקו בדיקת תקינות, פלטפורמת הסוכנים תשתמש בבדיקות התקינות שמוגדרות כברירת מחדל, כמו שמתואר בקטע בדיקות תקינות שמוגדרות כברירת מחדל.
באפליקציות מדור קודם שלא מחזירות את הערך 200 OK כדי לציין שהמודל נטען ומוכן לקבל תנועה, צריך להגדיר בדיקת תקינות. לדוגמה, יכול להיות שאפליקציה תחזיר את הערך 200 OK כדי לציין הצלחה, למרות שסטטוס הטעינה של המודל שמופיע בגוף התגובה מציין שהמודל לא נטען, ולכן לא מוכן לקבל תנועה. במקרה כזה, צריך להגדיר בדיקת תקינות שתחזיר הצלחה רק כשהמודל נטען ומוכן לשרת תנועה.
כדי לבצע בדיקה, Agent Platform מריץ את הפקודה exec שצוינה בקונטיינר היעד. אם הפקודה מצליחה, היא מחזירה 0 והקונטיינר נחשב לפעיל ותקין.
בדיקות תקינות שמוגדרות כברירת מחדל
כברירת מחדל, פלטפורמת Agent מבצעת בדיקות תקינות מדי פעם בשרת ה-HTTP בזמן שהוא פועל, כדי לוודא שהוא מוכן לטפל בבקשות להסקת מסקנות.
השירות משתמש בבדיקת תקינות כדי לשלוח בקשות HTTP GET לנתיב בדיקת תקינות שניתן להגדרה בשרת. ציינו את הנתיב הזה בשדה containerSpec.healthRoute כשאתם יוצרים Model. כדי ללמוד איך הקונטיינר יכול לגשת לערך הזה, קראו את הקטע במסמך הזה שעוסק במשתנה הסביבה AIP_HEALTH_ROUTE.
מגדירים את שרת ה-HTTP כך שיגיב לכל בקשה של בדיקת תקינות באופן הבא:
אם השרת מוכן לטפל בבקשות להסקת מסקנות, צריך להשיב לבקשה לבדיקת תקינות תוך 10 שניות עם קוד הסטטוס
200 OK. התוכן של גוף התגובה לא משנה, כי Agent Platform מתעלמת ממנו.התגובה הזו מציינת שהשרת תקין.
אם השרת לא מוכן לטפל בבקשות להסקת מסקנות, אל תגיבו לבקשה לבדיקת תקינות תוך 10 שניות, או תגיבו עם קוד סטטוס כלשהו חוץ מ-
200 OK. לדוגמה, להחזיר את קוד הסטטוס503 Service Unavailable.התגובה הזו (או היעדר התגובה) מצביעה על כך שהשרת לא תקין.
אם בדיקת התקינות מקבלת תגובה לא תקינה מהשרת (כולל מצב שבו לא מתקבלת תגובה תוך 10 שניות), היא שולחת עד 3 בדיקות תקינות נוספות במרווחים של 10 שניות. במהלך התקופה הזו, Agent Platform עדיין מחשיבה את השרת כתקין. אם הבדיקה מקבלת תגובה תקינה לאחת מהבדיקות האלה, היא חוזרת מיד ללוח הזמנים של בדיקות התקינות לסירוגין. עם זאת, אם הבדיקה מקבלת 4 תשובות לא תקינות ברצף, Agent Platform מפסיקה לנתב את תנועת ההסקה למאגר. (אם המשאב DeployedModel מוגדל כדי להשתמש בכמה צומתי הסקה, פלטפורמת Agent מנתבת את בקשות ההסקה למאגרים תקינים אחרים).
פלטפורמת הסוכנים לא מפעילה מחדש את הקונטיינר, אלא בדיקת התקינות ממשיכה לשלוח בקשות לבדיקת תקינות לסירוגין לשרת הלא תקין. אם מתקבלת תגובה תקינה, הוא מסמן את הקונטיינר כתקין ומתחיל שוב לנתב אליו תנועת הסקה.
הנחיות מעשיות
במקרים מסוימים, מספיק ששרת ה-HTTP בקונטיינר תמיד יגיב לבדיקות תקינות עם קוד הסטטוס 200 OK. אם המאגר טוען משאבים לפני הפעלת השרת, המאגר לא תקין במהלך תקופת ההפעלה ובמהלך כל התקופות שבהן שרת ה-HTTP נכשל. בכל שאר הזמן, הוא מגיב כ"תקין".
כדי ליצור הגדרה מתוחכמת יותר, אפשר לתכנן את שרת ה-HTTP כך שיגיב לבדיקות תקינות בסטטוס לא תקין בזמנים מסוימים. לדוגמה, יכול להיות שתרצו לחסום את תנועת ההסקה לצומת למשך זמן מסוים כדי שהקונטיינר יוכל לבצע תחזוקה.
בקשות להסקת מסקנות
יש שתי תבניות להגדרת נתיבים לשרת המודל. אחד שמוגדר על ידי Gemini Enterprise Agent Platform (/predict), והשני שמאפשר התאמה אישית מלאה כדי שתוכלו פשוט להוסיף את שרת המודל שבחרתם (/invoke).
המסלול /predict שמוגדר ב-Vertex
כשלקוח שולח בקשת projects.locations.endpoints.predict ל-Agent Platform API, פלטפורמת Agent מעבירה את הבקשה הזו כבקשת HTTP POST לנתיב הסקה (inference) שניתן להגדרה בשרת שלכם. ציינו את הנתיב הזה בשדה containerSpec.predictRoute כשאתם יוצרים Model. כדי ללמוד איך הקונטיינר יכול לגשת לערך הזה, קראו את הקטע במסמך הזה שעוסק במשתנה הסביבה AIP_PREDICT_ROUTE.
דרישות לגבי הבקשה
אם המודל נפרס בנקודת קצה ציבורית משותפת, כל בקשת הסקה צריכה להיות בגודל של עד 1.5MB. שרת ה-HTTP צריך לקבל בקשות להסקת מסקנות שכוללות את כותרת ה-HTTP Content-Type: application/json וגופי JSON בפורמט הבא:
{
"instances": INSTANCES,
"parameters": PARAMETERS
}
בבקשות האלה:
INSTANCES הוא מערך של ערך JSON אחד או יותר מכל סוג. כל ערך מייצג מופע שאתם מספקים לו הסקה.
PARAMETERS הוא אובייקט JSON שמכיל את כל הפרמטרים שהקונטיינר צריך כדי להציג הסקות על המכונות. השדה
parametersהוא אופציונלי ב-Agent Platform, אז אתם יכולים להגדיר את הקונטיינר כך שהשדה יהיה חובה, להשתמש בו רק כשהוא מסופק או להתעלם ממנו.
מידע נוסף על הדרישות לגבי גוף הבקשה
דרישות לגבי התשובות
אם המודל נפרס בנקודת קצה ציבורית משותפת, כל תגובת הסקה צריכה להיות בגודל של עד 1.5MB. שרת ה-HTTP צריך לשלוח תגובות עם גופי JSON שעומדים בפורמט הבא:
{
"predictions": INFERENCES
}
בתגובות האלה, מחליפים את INFERENCES במערך של ערכי JSON שמייצגים את ההסקות שהקונטיינר יצר לכל אחד מהערכים של INSTANCES בבקשה התואמת.
אחרי ששרת ה-HTTP שולח את התגובה הזו, פלטפורמת הנציג מוסיפה לתגובה את השדה deployedModelId לפני שהיא מחזירה אותה ללקוח. בשדה הזה מצוין איזה DeployedModel ב-Endpoint שולח את התגובה. מידע נוסף על הפורמט של גוף התגובה
נתיבי הסקה בהתאמה אישית
אם שרת המודל מטמיע כמה נתיבי הסקה, מומלץ להשתמש ב-invoke API כדי לגשת לכמה נתיבי הסקה. כדי להפעיל את Invoke API, צריך להגדיר את השדה Model.containerSpec.invokeRoutePrefix לערך "/*" בזמן העלאת המודל. אחרי הפריסה, בקשת HTTP לנתיב /invoke/foo/bar תועבר לנתיב /foo/bar של שרת המודל. למידע נוסף, קראו את המאמר שימוש בנתיבים מותאמים אישית שרירותיים.
דרישות לפרסום קובצי אימג' של קונטיינרים
כדי להשתמש בקובץ האימג' של הקונטיינר ב-Agent Platform, צריך להעביר אותו בדחיפה ל-Artifact Registry. איך מעבירים קובץ אימג' של קונטיינר ל-Artifact Registry
באופן ספציפי, קובץ האימג' של הקונטיינר והמאגר צריכים לעמוד בדרישות הבאות לגבי מיקום, פורמט URI והרשאות.
מיקום
כשמשתמשים ב-Artifact Registry, המאגר צריך להשתמש באזור שתואם לנקודת הקצה מבוססת-המיקום שבה מתכננים ליצור Model.
לדוגמה, אם אתם מתכננים ליצור Model בנקודת הקצה us-central1-aiplatform.googleapis.com, השם המלא של קובץ האימג' של הקונטיינר חייב להתחיל ב-us-central1-docker.pkg.dev/. אל תשתמשו במאגר בכמה אזורים בשביל קובץ האימג' של הקונטיינר.
פורמט ה-URI של התמונה
כשיוצרים Model, מציינים את containerSpec.imageUri באחד מהפורמטים הבאים:
- לפי תקציר:
LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY/IMAGE@sha256:DIGEST - לפי תג:
LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY/IMAGE:TAG - בלי תג או תקציר (ברירת המחדל היא
:latest):LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY/IMAGE
אל תכללו גם תג וגם תקציר באותו URI (לדוגמה, IMAGE:TAG@sha256:DIGEST). פלטפורמת Agent דוחה מזהי URI של תמונות שמשלבים תג ותקציר במהלך העלאת המודל.
הרשאות
ל-Agent Platform צריכה להיות הרשאה לשלוף את קובץ האימג' של הקונטיינר כשיוצרים Model. באופן ספציפי, לסוכן השירות של פלטפורמת הסוכנים בפרויקט צריכות להיות ההרשאות של התפקיד "קריאה מ-Artifact Registry" (roles/artifactregistry.reader) במאגר של קובץ האימג' של הקונטיינר.
פלטפורמת הסוכנים משתמשת בסוכן השירות של פלטפורמת הסוכנים בפרויקט שלכם כדי לתקשר עם שירותי Google Cloud אחרים. כתובת האימייל של חשבון השירות הזה היא service-PROJECT_NUMBER@gcp-sa-aiplatform.iam.gserviceaccount.com, כאשר PROJECT_NUMBER מוחלף במספר הפרויקט של הפרויקט ב-Agent Platform.
אם העברתם את קובץ האימג' של הקונטיינר לאותו פרויקט ב- Google Cloud שבו אתם משתמשים ב-Agent Platform, אתם לא צריכים להגדיר הרשאות. הרשאות ברירת המחדל שניתנות לסוכן השירות של Agent Platform מספיקות.
לעומת זאת, אם העברתם את קובץ האימג' של הקונטיינר לפרויקט ב-Google Cloud שהוא לא הפרויקט שבו אתם משתמשים ב-Agent Platform, אתם צריכים לתת לסוכן השירות של Agent Platform את התפקיד "קורא של Artifact Registry" במאגר של Artifact Registry.
גישה לפריטי מידע שנוצרים בתהליך פיתוח (Artifact) של מודלים
כשיוצרים Model באימון בהתאמה אישית בלי קונטיינר בהתאמה אישית, צריך לציין את ה-URI של ספריית Cloud Storage עם פריטי מידע שנוצרו בתהליך הפיתוח (Artifact) של המודל בתור השדה artifactUri. כשיוצרים Model עם קונטיינר בהתאמה אישית, לא חובה לספק פריטי מידע שנוצרו על ידי המודל ב-Cloud Storage.
אם קובץ האימג' של הקונטיינר כולל את פריטי המידע שנוצרו בתהליך של המודל שדרושים להסקת מסקנות, אין צורך לטעון קבצים מ-Cloud Storage.
עם זאת, אם אתם מספקים פריטי מידע שנוצרו במודל על ידי ציון השדה artifactUri, הקונטיינר צריך לטעון את פריטי המידע האלה כשהוא מתחיל לפעול.
כשפלטפורמת הסוכנים מפעילה את הקונטיינר, היא מגדירה את משתנה הסביבה AIP_STORAGE_URI ל-URI של Cloud Storage שמתחיל ב-gs://.
ההוראה ENTRYPOINT של הקונטיינר יכולה להוריד את הספרייה שצוינה על ידי ה-URI הזה כדי לגשת לארטיפקטים של המודל.
שימו לב שהערך של משתנה הסביבה AIP_STORAGE_URI לא זהה ל-URI של Cloud Storage שציינתם בשדה artifactUri כשאתם יוצרים את ה-Model. במקום זאת, AIP_STORAGE_URI מפנה לעותק של ספריית פריטי המידע שנוצרו מהמודל בקטגוריה אחרת של Cloud Storage, שמנוהלת על ידי Agent Platform.
הספרייה הזו מתמלאת על ידי Agent Platform כשיוצרים Model.
אי אפשר לעדכן את התוכן של הספרייה. כדי להשתמש בארטיפקטים חדשים של מודלים, צריך ליצור Model חדש.
לחשבון השירות שבו משתמשים בקונטיינר כברירת מחדל יש הרשאה לקרוא מה-URI הזה.
לעומת זאת, אם אתם מציינים חשבון שירות בהתאמה אישית כשאתם פורסים את Model ב-Endpoint, פלטפורמת Agent נותנת לחשבון השירות שציינתם את התפקיד 'צפייה באובייקט אחסון' (roles/storage.objectViewer) בקטגוריה של Cloud Storage של ה-URI.
כדי לטעון את פריטי המידע שנוצרו במודל, אתם יכולים להשתמש בכל ספרייה שתומכת ב-Application Default Credentials (ADC). אין צורך להגדיר אימות באופן מפורש.
משתני סביבה שזמינים בקונטיינר
בזמן הריצה, ההוראה ENTRYPOINT של הקונטיינר יכולה להפנות למשתני סביבה שהגדרתם ידנית, וגם למשתני סביבה שמוגדרים אוטומטית על ידי Agent Platform. בקטע הזה מוסבר איך אפשר להגדיר משתני סביבה, ומפורטים המשתנים שמוגדרים באופן אוטומטי על ידי Agent Platform.
משתנים שמוגדרים בקובץ האימג' של הקונטיינר
כדי להגדיר משתני סביבה בקובץ האימג' של הקונטיינר כשיוצרים אותו, משתמשים בהוראה ENV של Docker.
אל תגדירו משתני סביבה שמתחילים בקידומת AIP_.
ההוראה ENTRYPOINT של הקונטיינר יכולה להשתמש במשתני הסביבה האלה, אבל אי אפשר להפנות אליהם באף אחד משדות ה-API של Model.
משתנים שמוגדרים על ידי Agent Platform
כשהקונטיינר מתחיל לפעול ב-Agent Platform, משתני הסביבה הבאים מוגדרים בסביבת הקונטיינר. כל משתנה מתחיל בקידומת AIP_. אל תגדירו באופן ידני משתני סביבה שמשתמשים בקידומת הזו.
ההוראה ENTRYPOINT של מאגר התגים יכולה לגשת למשתנים האלה. כדי לדעת אילו שדות ב-Agent Platform API יכולים להפנות למשתנים האלה, קראו את מאמרי העזרה של ה-API של ModelContainerSpec.
| שם המשתנה | ערך ברירת המחדל | איך מגדירים ערך | פרטים |
|---|---|---|---|
| AIP_ACCELERATOR_TYPE | ביטול הגדרות | כשפורסים Model בתור DeployedModel במשאב Endpoint, צריך להגדיר את השדה dedicatedResources.machineSpec.acceleratorType. |
אם רלוונטי, המשתנה הזה מציין את סוג המאיץ שבו משתמשת המכונה הווירטואלית (VM) שבה פועל הקונטיינר. |
| AIP_DEPLOYED_MODEL_ID | מחרוזת של ספרות שמזהה את DeployedModel שאליו נפרס Model של מאגר התגים הזה. |
לא ניתן להגדרה | הערך הזה הוא השדה id של DeployedModel. |
| AIP_ENDPOINT_ID | מחרוזת של ספרות שמזהה את ה-Endpoint שבו נפרס ה-Model של מאגר התגים. |
לא ניתן להגדרה | הערך הזה הוא החלק האחרון של השדה name של Endpoint (אחרי endpoints/). |
| AIP_FRAMEWORK | CUSTOM_CONTAINER |
לא ניתן להגדרה | |
| AIP_HEALTH_ROUTE | /v1/endpoints/ENDPOINT/deployedModels/DEPLOYED_MODELבמחרוזת הזו, מחליפים את ENDPOINT בערך של המשתנה AIP_ENDPOINT_ID ואת DEPLOYED_MODEL בערך של המשתנה AIP_DEPLOYED_MODEL_ID. |
כשיוצרים Model, מגדירים את השדה containerSpec.healthRoute. |
המשתנה הזה מציין את נתיב ה-HTTP בקונטיינר שאליו Agent Platform שולחת בדיקות תקינות. |
| AIP_HTTP_PORT | 8080 |
כשיוצרים Model, מגדירים את השדה containerSpec.ports. הרשומה הראשונה בשדה הזה הופכת לערך של AIP_HTTP_PORT. |
פלטפורמת הסוכנים שולחת בדיקות תקינות, בדיקות פעילות ובקשות להסקת מסקנות ליציאה הזו בקונטיינר. שרת ה-HTTP של הקונטיינר צריך להאזין לבקשות ביציאה הזו. |
| AIP_MACHINE_TYPE | אין ברירת מחדל, צריך להגדיר את המדיניות | כשפורסים Model בתור DeployedModel במשאב Endpoint, צריך להגדיר את השדה dedicatedResources.machineSpec.machineType. |
המשתנה הזה מציין את סוג ה-VM שהקונטיינר פועל בו. |
| AIP_MODE | PREDICTION |
לא ניתן להגדרה | המשתנה הזה מציין שהקונטיינר פועל ב-Agent Platform כדי להציג הסקות אונליין. אתם יכולים להשתמש במשתנה הסביבה הזה כדי להוסיף לוגיקה בהתאמה אישית לקונטיינר, כך שהוא יוכל לפעול בכמה סביבות מחשוב אבל להשתמש רק בנתיבי קוד מסוימים כשהוא פועל ב-Agent Platform. |
| AIP_MODE_VERSION | 1.0.0 |
לא ניתן להגדרה | המשתנה הזה מציין את גרסת הדרישות של הקונטיינר בהתאמה אישית (המסמך הזה) שפלטפורמת Agent מצפה שהקונטיינר יעמוד בהן. המסמך הזה מתעדכן בהתאם לניהול גרסאות סמנטי. |
| AIP_MODEL_NAME | הערך של המשתנה AIP_ENDPOINT_ID |
לא ניתן להגדרה | מעיינים בשורה AIP_ENDPOINT_ID. המשתנה הזה קיים מטעמי תאימות. |
| AIP_PREDICT_ROUTE | /v1/endpoints/ENDPOINT/deployedModels/DEPLOYED_MODEL:predictבמחרוזת הזו, מחליפים את ENDPOINT בערך של המשתנה AIP_ENDPOINT_ID ואת DEPLOYED_MODEL בערך של המשתנה AIP_DEPLOYED_MODEL_ID. |
כשיוצרים Model, מגדירים את השדה containerSpec.predictRoute. |
המשתנה הזה מציין את נתיב ה-HTTP במאגר שאליו Agent Platform מעבירה בקשות להסקת מסקנות. |
| AIP_PROJECT_NUMBER | מספר הפרויקט ב- Google Cloud שבו משתמשים ב-Agent Platform | לא ניתן להגדרה | |
| AIP_STORAGE_URI |
|
לא ניתן להגדרה | המשתנה הזה מציין את הספרייה שמכילה עותק של פריטי המידע שנוצרו בתהליך הפיתוח (Artifact) של המודל, אם רלוונטי. |
| AIP_VERSION_NAME | הערך של המשתנה AIP_DEPLOYED_MODEL_ID |
לא ניתן להגדרה | מעיינים בשורה AIP_DEPLOYED_MODEL_ID. המשתנה הזה קיים
מסיבות של תאימות. |
משתנים שמוגדרים במשאב Model
כשיוצרים Model, אפשר להגדיר משתני סביבה נוספים בשדה containerSpec.env.
ההוראה ENTRYPOINT של מאגר התגים יכולה לגשת למשתנים האלה. כדי לדעת אילו שדות ב-Agent Platform API יכולים להפנות למשתנים האלה, קראו את מאמרי העזרה של ה-API של ModelContainerSpec.
המאמרים הבאים
- מידע נוסף על הצגת הסקות באמצעות קונטיינר בהתאמה אישית, כולל איך לציין שדות API שקשורים לקונטיינר כשמייבאים מודל.