פתרון בעיות בשירותי למידת מכונה

בדף הזה מתוארים שלבים לפתרון בעיות שיכולים לעזור לכם אם נתקלתם בבעיות במהלך השימוש בשירותי למידת מכונה ב-Gemini Enterprise Agent Platform.

כדי לסנן את התוכן בדף הזה, לוחצים על אחד מהנושאים:

פתרון בעיות באמצעות Cloud Assist Investigations

כשמחברים את Agent Platform למוצרים אחרים של Cloud de Confiance , אפשר להיעזר ב-Cloud Assist Investigations כדי לפתור בעיות מורכבות בשילוב.

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

מודלים של AutoML

בקטע הזה מתוארים שלבים לפתרון בעיות שיכולים לעזור לכם אם נתקלתם בבעיות ב-AutoML.

חסרות תוויות בקבוצת הנתונים לבדיקה, לאימות או לאימון

הבעיה

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

הפתרון

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

‫Agent Studio ב-Gemini Enterprise Agent Platform

כשעובדים עם Agent Studio, יכול להיות שיופיעו השגיאות הבאות:

ניסיון לכוונן מודל מחזיר את השגיאה Internal error encountered

הבעיה

מופיעה השגיאה Internal error encountered כשמנסים לכוונן מודל.

הפתרון

מריצים את פקודת ה-curl הבאה כדי ליצור קבוצת נתונים ריקה ב-Gemini Enterprise Agent Platform. חשוב להגדיר את מזהה הפרויקט בפקודה.

PROJECT_ID=PROJECT_ID

curl \
-X POST \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
https://europe-west4-aiplatform.googleapis.com/ui/projects/$PROJECT_ID/locations/europe-west4/datasets \
-d '{
    "display_name": "test-name1",
    "metadata_schema_uri": "gs://google-cloud-aiplatform/schema/dataset/metadata/image_1.0.0.yaml",
    "saved_queries": [{"display_name": "saved_query_name", "problem_type": "IMAGE_CLASSIFICATION_MULTI_LABEL"}]
}'

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

קוד שגיאה: 429

הבעיה

מופיעה השגיאה הבאה:

429: The online prediction request quota is exceeded for
PUBLIC_BASE_MODEL_NAME.

הפתרון

נסו שוב מאוחר יותר עם השהיה. אם עדיין יש שגיאות, פנו לתמיכה של Gemini Enterprise Agent Platform.

קוד שגיאה: 410

הבעיה

מופיעה השגיאה הבאה:

410: The request is missing the required authentication credential. Expected
OAuth 2.0 access token, login cookie, or other valid authentication credential.

הפתרון

למידע נוסף, קראו את הסקירה הכללית על אימות.

קוד שגיאה: 403

הבעיה

מופיעה השגיאה הבאה:

403: Permission denied.

הפתרון

מוודאים שלחשבון שניגש ל-API יש את ההרשאות המתאימות.

Agent Platform Pipelines

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

אין לך הרשאה לפעול כחשבון שירות

הבעיה

כשמריצים את תהליך העבודה של Gemini Enterprise Agent Platform Pipelines, יכול להיות שתופיע הודעת השגיאה הבאה:

You do not have permission to act as service account: SERVICE_ACCOUNT. (or it may not exist).

הפתרון

השגיאה הזו מציינת שלחשבון השירות שמריץ את תהליך העבודה אין גישה למשאבים שהוא צריך להשתמש בהם.

כדי לפתור את הבעיה, צריך לתת למשתמש את ההרשאה iam.serviceAccounts.actAs בחשבון השירות.

שגיאה: ערכי ה-hash של חבילת Python לא תואמים ברכיב Pipelines של Gemini Enterprise Agent Platform

הבעיה

כשמריצים את תהליך העבודה של Gemini Enterprise Agent Platform Pipelines, יכול להיות שתופיע השגיאה הבאה:

ERROR: THESE PACKAGES DO NOT MATCH THE HASHES FROM THE REQUIREMENTS FILE. If you have updated the package versions, please update the hashes. Otherwise, examine the package contents carefully; someone may have tampered with them.

הסיבה לכך היא התנגשויות בין הגרסאות של ספריות Python בתמונת הבסיס של רכיב הצינורות של Gemini Enterprise Agent Platform לבין אלה שהצינור מנסה להתקין.

הפתרון

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

שגיאה Internal error happened

הבעיה

אם הצינור נכשל ומוצגת ההודעה Internal error happened, חפשו את שם הצינור ב-Logs Explorer. יכול להיות שתופיע הודעת שגיאה כמו זו:

java.lang.IllegalStateException: Failed to validate vpc
network projects/PROJECT_ID/global/networks/VPC_NETWORK.

APPLICATION_ERROR;google.cloud.servicenetworking.v1/ServicePeeringManagerV1.GetConsumerConfig;Reserved
range: 'RANGE_NAME' not found for consumer project:
'PROJECT_ID' network: 'VPC_NETWORK'.
com.google.api.tenant.error.TenantManagerException: Reserved range:
'RANGE_NAME' not found for consumer project

המשמעות היא שקישור VPC בין רשתות מקבילות של Agent Platform כולל טווח כתובות IP שנמחק.

הפתרון

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

היקף ההרשאות של OAuth או הקהל של טוקן המזהה שצוינו לא תקינים

הבעיה

כשמריצים את תהליך העבודה של Gemini Enterprise Agent Platform Pipelines, מופיעה הודעת השגיאה הבאה:

google.auth.exceptions.RefreshError: ('invalid_scope: Invalid OAuth scope
or ID token audience provided.', {'error': 'invalid_scope',
'error_description': 'Invalid OAuth scope or ID token audience provided.'})

הפתרון

המשמעות היא שלא סיפקתם פרטי כניסה באחד מרכיבי הצינור, או שלא השתמשתם ב-ai_platform.init() כדי להגדיר פרטי כניסה.

כדי לפתור את הבעיה, צריך להגדיר את פרטי הכניסה לרכיב הרלוונטי של צינור עיבוד הנתונים, או להגדיר את פרטי הכניסה לסביבה ולהשתמש ב-ai_platform.init() בתחילת הקוד.

os.environ['GOOGLE_APPLICATION_CREDENTIALS'] = PATH_TO_JSON_KEY

רכיבי Agent Platform Pipelines דורשים יותר מ-100GB מקום בכונן

הבעיה

כברירת מחדל, המקום בכונן שמוקצה לרכיבים של Agent Platform Pipelines הוא 100GB, ואי אפשר להגדיל אותו. למידע נוסף על הבעיה, אפשר לעיין בIssue Tracker הציבורי.

הפתרון

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

דוגמה לשימוש באופרטור הזה מופיעה בקטע Convert the component to an Agent Platform Custom Job במאמר Agent Platform Pipelines: Custom training with prebuilt Pipeline Components Cloud de Confiance by S3NS .

בעיות ברשת ב-Agent Platform

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

gcloud services vpc-peerings get-vpc-service-controls \
  --network YOUR_NETWORK

עומסי עבודה לא יכולים לגשת לנקודות קצה ברשת ה-VPC כשמשתמשים בטווחי כתובות IP ציבוריות בשימוש פרטי ב-Gemini Enterprise Agent Platform

הבעיה

כברירת מחדל, טווחי כתובות IP ציבוריות בשימוש פרטי לא מיובאים.

הפתרון

כדי להשתמש בטווחי כתובות IP ציבוריות בשימוש פרטי, צריך להפעיל ייבוא של טווחי כתובות IP ציבוריות בשימוש פרטי

com.google.api.tenant.error.TenantManagerException: Reserved range: nnn not found for consumer project

הבעיה

אתם מקבלים שגיאות בפורמט com.google.api.tenant.error.TenantManagerException: Reserved range: nnn not found for consumer project כשאתם מריצים עומסי עבודה או פורסים נקודות קצה.

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

הפתרון

מריצים את gcloud services vpc-peerings update עבור servicenetworking אחרי שמעדכנים את ההקצאות של הגישה לשירותים פרטיים.

לצינור עיבוד הנתונים או למשימה אין גישה לנקודות קצה (endpoints) ברשת ה-VPC המקושרת לרשתות שכנות

הבעיה

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

הפתרון

כדי לפתור את הבעיה, נסו את הפתרונות הבאים:

  • מוודאים שביצעתם את כל השלבים שמפורטים במאמר הגדרה של קישור בין רשתות VPC שכנות (peering).

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

    כניסה לדף VPC Network Peering

  • חשוב לוודא שיש לכם כלל של חומת אש שמאפשר חיבורים מהטווח הזה ליעד ברשת שלכם.

  • אם חיבור ה-peering לא מייבא מסלולים בזמן שהמשימה פועלת, סימן שהגדרת הרשת של השירות לא בשימוש. סביר להניח שהסיבה לכך היא שהשלמתם את הגדרת ה-peering עם רשת שאינה רשת ברירת המחדל. במקרה כזה, חשוב לציין את הרשת כשמפעילים משימה. צריך להשתמש בשם המלא של הרשת בפורמט הבא: projects/$PROJECT_ID/global/networks/$NETWORK_NAME.

    מידע נוסף זמין בסקירה הכללית על Routes.

הצינור או המשימה לא יכולים לגשת לנקודות קצה ברשתות אחרות מחוץ לרשת שלכם.

הבעיה

הצינור או המשימה לא יכולים לגשת לנקודות קצה ברשתות מחוץ לרשת שלכם.

הפתרון

כברירת מחדל, הגדרת ה-peering מייצאת רק נתיבים לרשתות המשנה המקומיות ב-VPC.

בנוסף, אין תמיכה בקישור מעבר בין רשתות שכנות (peering), ומתאפשרת תקשורת רק בין רשתות שכנות שיש ביניהן קישור ישיר (direct peering).

  • כדי לאפשר ל-Gemini Enterprise Agent Platform להתחבר דרך הרשת שלכם ולהגיע לנקודות קצה ברשתות אחרות, אתם צריכים לייצא את נתיבי הרשת לחיבור ה-peering. עורכים את ההגדרות של רשת ה-VPC המקושרת ומפעילים את האפשרות Export custom routes.

כניסה לדף VPC Network Peering

בגלל שאין תמיכה בהעברת קישור בין רשתות שכנות (peering), פלטפורמת Gemini Enterprise Agent לא לומדת נתיבים לרשתות ולשירותים אחרים שמקושרים, גם אם Export Custom Routes מופעל. במאמר הרחבת יכולת ההגעה של Agent Platform Pipelines ברשת מוסבר איך לעקוף את הבעיה.

‫No route to host בלי התנגשויות בין נתיבים שמופיעות במסוף Cloud de Confiance

הבעיה

המסלולים היחידים שמופיעים במסוף Cloud de Confiance הם אלה שמוגדרים ב-VPC שלכם, וגם הטווחים ששמורים כשמשלימים את ההגדרה של קישור (peering) בין רשתות VPC שכנות.

במקרים נדירים, יכול להיות שתתקבל תלונה על no route to host במשימה של Gemini Enterprise Agent Platform כשמנסים להגיע לכתובת IP שה-VPC מייצא לרשת של Gemini Enterprise Agent Platform.

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

בתנאים האלה, עומס העבודה מנסה להתחבר לכתובת ה-IP במרחב השמות של הרשת שלו, ואם הוא לא מצליח להגיע אליה, הוא מחזיר את השגיאה.

הפתרון

צריך להגדיר את עומס העבודה כך שיחזיר את כתובות ה-IP של מרחב השמות המקומי שלו, ולוודא שאין התנגשות עם נתיבים שמייצאים דרך חיבור ה-peering. אם יש התנגשות, צריך להעביר רשימה של reservedIpRanges[] בפרמטרים של המשימה שלא חופפים לטווחים כלשהם ברשת ה-VPC. המשימה משתמשת בטווחים האלה לכתובות ה-IP הפנימיות של עומס העבודה.

RANGES_EXHAUSTED, RANGES_NOT_RESERVED

הבעיה

שגיאות מהסוג RANGES_EXHAUSTED,‏ RANGES_NOT_RESERVED ו-RANGES_DELETED_LATER מצביעות על בעיה בהגדרה הבסיסית של קישור בין רשתות VPC שכנות (peering). אלה שגיאות בחיבור לרשת ולא שגיאות בשירות Agent Platform עצמו.

הפתרון

כשנתקלים בשגיאה RANGES_EXHAUSTED, קודם צריך לבדוק אם התלונה מוצדקת.

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

  • במסוף Cloud, נכנסים ל-Network Analyzer ומחפשים תובנות בפורמט "Summary of כתובת IP allocation" ברשת ה-VPC. אם לפי המדדים האלה ההקצאה היא 100% או קרובה ל-100%, אתם יכולים לבצע אחת מהפעולות הבאות:

    • מוסיפים טווח חדש להזמנה או מרחיבים את הטווח הקיים. חשוב לזכור שכל הטווחים חייבים להיות רציפים.
    • אם יש לכם טווחי IP לא רציפים שהוקצו אבל לא נמצאים בשימוש, אתם יכולים להפעיל עומסי עבודה חדשים של Gemini Enterprise Agent Platform באזור אחר.

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

מידע נוסף זמין במאמר שגיאות אימות של Service Infrastructure.

אם השגיאה נמשכת, פנו לתמיכה.

Router status is temporarily unavailable

הבעיה

כשמפעילים את Agent Platform Pipelines, מופיעה הודעת שגיאה דומה לזו:

Router status is temporarily unavailable. Please try again later

הפתרון

הודעת השגיאה מציינת שמדובר במצב זמני. נסו להפעיל שוב את Agent Platform Pipelines.

אם השגיאה נמשכת, פנו לתמיכה.

עומסי העבודה לא יכולים לזהות את שמות המארחים של דומיינים של DNS ב-VPC

הבעיה

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

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

הפתרון

  • מוודאים שהגדרתם קישור בין רשתות VPC שכנות (peering) ל-Gemini Enterprise Agent Platform ברשת ה-VPC.

  • מבצעים את השלבים כדי לשתף את תחום ה-DNS הפרטי עם רשת היצרן של Gemini Enterprise Agent Platform. שימו לב שהתהליך תלוי בתרחיש לדוגמה:

  • חשוב לוודא שעומסי העבודה של Gemini Enterprise Agent Platform מופעלים עם הדגל --network שמציין את רשת ה-VPC. כך הם יכולים לפעול ברשת שמנוהלת על ידי Google ולגשת לתחומי ה-DNS ששיתפתם.

  • מפעילים את רישום ה-DNS ביומן במדיניות של שרת ה-DNS, משחזרים את הבעיה ומריצים בדיקה נוספת. אם תגובת ה-DNS של עומס העבודה תקינה, מסנן של Cloud Logging ל-resource.type="dns_query" יציג רשומות בפורמט הזה:

    "resource": {
  "type": "dns_query",
  "labels": {
    "location": REGION,
    "project_id": PROJECT_ID,
    "source_type": "peering-zone",
    "target_name": "QUERY_TARGET,
    "target_type": "forwarding-zone"
  }
}

  • מוודאים ששאילתת DNS ממכונה באותה רשת משנה (same) יכולה לפתור שמות מארחים באמצעות שרת ה-DNS.

  • אם שרת ה-DNS לא נמצא ב- Cloud de Confiance, צריך לוודא שכללי חומת האש המרוחקת מאפשרים חיבורים מ-35.199.192.0/19.

  • מריצים בדיקת קישוריות מהמכונה לבדיקה אל היציאה 53/UDP בכתובת ה-IP של שרת ה-DNS. לדוגמה, אם הנתיב מוביל לכלל העברה, ודאו ש:

    • אם זה כלל העברה אזורי, הוא צריך להיות באותו אזור כמו הלקוח.
    • הוא מקבל חיבורים ב-53/UDP ומעביר אותם לשרת ה-DNS הנכון.

בעיות בקישוריות שנגרמות בגלל התנהגויות בצד הלקוח

אם אתם נתקלים בבעיות בקישוריות כשאתם מנסים להשתמש בממשקי ה-API של Cloud de Confiance by S3NS, יכול להיות ששורש הבעיה הוא בצד הלקוח. בקטע הזה מוצעים פתרונות בצד הלקוח שיכולים לשפר את חוויית השימוש.

איפוסים של החיבור וחבילות נתונים שנמחקו

הבעיה

כשמנסים להשתמש בממשקי API של Cloud de Confiance , מתרחשים איפוסים של החיבור ואיבוד מנות.

הפתרון

כדי לפתור את הבעיה, כדאי לבדוק את הדברים הבאים:

  • אם יש לכם נפח תנועה גבוה של עסקאות עם דרישות של זמן אחזור נמוך, כדאי לבדוק אם יש בעיות ידועות בכרטיסי הקו של הלקוחות המקומיים שעלולות לגרום לאיפוס של חיבורי TCP או לאובדן חבילות.
  • בדקו אם שירותים בצד הלקוח בנתיב הבקשה משתמשים ב-iptables. אלה יכולים להיות אשכולות של Kubernetes או חומות אש עם שמירת מצב ומכשירי NAT. כברירת מחדל, תת-המערכת למעקב אחרי חיבורים (conntrack) של Linux תפעל בהתאם למפרטים של פרוטוקול TCP, ולדוגמה, תבטל חבילות TCP שלא לפי הסדר. כדי להשבית את ההתנהגות הזו, מפעילים את הפרמטר net.netfilter.nf_conntrack_tcp_be_liberal של ליבת Linux או את המקבילה שלו.

חיבורים חלקיים

הבעיה

כשמנסים להשתמש בממשקי API של Cloud de Confiance , החיבורים לא מושלמים.

הפתרון

כדי לפתור את הבעיה, כדאי לבדוק את הדברים הבאים:

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

בעיות אחרות בחיבור שלא קשורות ל-API

כדי לפתור בעיות בחיבורים שלא קשורים ל-API, כדאי לבדוק את הדברים הבאים:

  • אם יש שרתי proxy בנתיב הבקשה, כדאי לבדוק אם הם יכולים לגרום לבעיות שבהן נתקלתם. כדאי לעיין במסמכי התיעוד ולפתור בעיות בשרת ה-Proxy כשנתקלים בבעיות כמו זמן אחזור לא מוסבר, חיבורים שנכשלו, שינויים ב-DNS, חסימות ממקורות שונים ובעיות דומות אחרות.
  • במיוחד כשמטפלים בתגובות 429 מממשקי API של Cloud de Confiance , לוגיקה בצד הלקוח שמנסה מיד שוב את החיבור יכולה להחמיר את הבעיה. חשוב להבין ולהטמיע השהיה מעריכית לפני ניסיון חוזר (exponential backoff) כשמטמיעים ניסיונות חוזרים.

הסקת מסקנות ב-Agent Platform

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

שגיאה: חריגה ממכסת הבקשות באצווה

הבעיה

כשמריצים משימות הסקה באצווה, מופיעה שגיאה כמו זו:

Quota exhausted. Please reach out to ai-platform-unified-feedback@google.com for
batch prediction quota increase.

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

שגיאה: חריגה ממספר הניסיונות החוזרים

הבעיה

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

('Post request fails. Cannot get predictions. Error: Exceeded retries: Non-OK
result 504 (upstream request timeout) from server, retry=3, elapsed=600.04s.', 16)

זה יכול לקרות כששירות ההסקה של Agent Platform נרשם לשירות Google Front End, שמשמש כשרת proxy לחיבורים מהלקוח ל-Agent Platform Inference API.

אם שירות Google Front End לא מקבל תגובה מה-API תוך 10 דקות, הוא מסיים את החיבור ומחזיר ללקוח קוד תגובה 500 HTTP.

הפתרון

כדי לפתור את הבעיה, אתם יכולים לנסות את הפתרונות הבאים:

  • מגדילים את מספר צומתי המחשוב או משנים את סוג המכונה.
  • צריך ליצור את מאגר ההסקה כך שישלח קודי תגובה תקופתיים מסוג 102 HTTP. הפעולה הזו מאפסת את הטיימר של 10 הדקות בשירות של ממשק הקצה של Google.

הפרויקט כבר מקושר ל-VPC

הבעיה

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

Currently only one VPC network per user project is supported. Your project is
already linked to
"projects/YOUR_SHARED_VPC_HOST_PROJECT/global/networks/YOUR_SHARED_VPC_NETWORK".
To change the VPC network, please undeploy all Agent Platform deployment
resources, delete all endpoint resources, and then retry creating resources in
30 mins.

הפתרון

כדי לפתור את הבעיה, נסו להריץ את הפקודה הזו ב-Cloud Shell.

gcloud services vpc-peerings delete \
    --service=servicenetworking.googleapis.com \
    --network=YOUR_SHARED_VPC_NETWORK \
    --project=YOUR_SHARED_VPC_HOST_PROJECT

הפעולה הזו מנתקת באופן ידני את רשת ה-VPC הישנה מרשת ה-VPC של Service Networking.

פריסה שנכשלה או נקודת קצה שנמחקה באופן בלתי צפוי

הבעיה

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

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

הפתרון

כדי לפתור את הבעיה, אתם יכולים לנסות את הפתרונות הבאים:

למידע נוסף על שאלות בנושא חיוב

בעיות בחשבון שירות בהתאמה אישית ב-Agent Platform

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

פריסת המודל נכשלה עם השגיאה "חשבון שירות serviceAccountAdmin"

הבעיה

פריסת המודל נכשלת ומופיעה שגיאה כמו:

Failed to deploy model MODEL_NAME to endpoint ENDPOINT_NAME due to the error: Failed to add IAM policy binding. Please grant SERVICE_ACC_NAME@gcp-sa-aiplatform.s3ns-system.iam.gserviceaccount.com the iam.serviceAccountAdmin role on service account vertex-prediction-role@PROJECT_INFO.s3ns.iam.gserviceaccount.com

הפתרון

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

לא ניתן לאחזר אסימון זהות כשמשתמשים בחשבון שירות בהתאמה אישית

הבעיה

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

תופיע שגיאה דומה לזו:

Failed to refresh jwt, retry number 0: ("Failed to retrieve http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=...&format=full
from the Google Compute Engine Metadata service. Status: 404 Response:
\nb'Not Found\n'", <google.auth.transport.requests._Response object at
0x7fb19f058c50>)

הפתרון

כדי לאחזר את אסימון הזהות באמצעות חשבון שירות בהתאמה אישית, צריך להשתמש ב-iamcredentials.googleapis.com.

מודלים עם אימון בהתאמה אישית

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

בעיות באימון בהתאמה אישית

הבעיות הבאות יכולות להתרחש במהלך אימון בהתאמה אישית. הבעיות רלוונטיות למשאבים מסוג CustomJob ו-HyperparameterTuningJob, כולל אלה שנוצרו על ידי משאבים מסוג TrainingPipeline.

קוד שגיאה: 400

הבעיה

מופיעה השגיאה הבאה:

400 Machine type MACHINE_TYPE is not supported.

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

הפתרון

משתמשים רק בסוגי מכונות זמינים באזורים המתאימים.

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

הבעיה

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

הפתרון

כדי לבדוק את דוח הקריסות של ה-worker, צפו ביומני האימון בהתאמה אישית במסוףCloud de Confiance .

כדי לתקן שגיאות נפוצות, אפשר לעיין בנושאים האחרים לפתרון בעיות ואז ליצור משאב חדש מסוג CustomJob, ‏ HyperparameterTuningJob או TrainingPipeline. במקרים רבים, קודי השגיאה נגרמים בגלל בעיות בקוד האימון, ולא בגלל שירות Agent Platform. כדי לבדוק אם זה המצב, אתם יכולים להריץ את קוד האימון במכונה המקומית או ב-Compute Engine.

נגמר הזיכרון ברפליקה

הבעיה

שגיאה יכולה להתרחש אם נגמר הזיכרון במכונה וירטואלית (VM) לאימון במהלך האימון.

הפתרון

אפשר לראות את השימוש בזיכרון של המכונות הווירטואליות לאימון במסוף Cloud de Confiance .

גם אם קיבלתם את השגיאה הזו, יכול להיות שלא תראו 100% שימוש בזיכרון במכונה הווירטואלית, כי שירותים אחרים שפועלים במכונה הווירטואלית, מלבד אפליקציית האימון, צורכים גם הם משאבים. בסוגי מכונות עם פחות זיכרון, יכול להיות ששירותים אחרים יצרכו אחוז גדול יחסית של זיכרון. לדוגמה, במכונה וירטואלית של n1-standard-4, השירותים יכולים לצרוך עד 40% מהזיכרון.

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

אין מספיק משאבים באזור

הבעיה

נתקלתם בבעיה של חוסר במלאי באזור מסוים.

הפתרון

פלטפורמת Agent מאמנת את המודלים שלכם באמצעות משאבים של Compute Engine. פלטפורמת הסוכנים לא יכולה לתזמן את עומס העבודה אם הקיבולת של Compute Engine מלאה למעבד (CPU) או למעבד גרפי (GPU) מסוים באזור. הבעיה הזו לא קשורה למכסה של הפרויקט.

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

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

שגיאת הרשאה כשניגשים לשירות אחר של Cloud de Confiance

אם נתקלתם בשגיאת הרשאה כשניסיתם לגשת לשירות אחר של Cloud de Confianceמקוד האימון (לדוגמה: google.api_core.exceptions.PermissionDenied: 403), יכול להיות שנתקלתם באחת מהבעיות הבאות:

בעיות בביצועים כשמשתמשים ב-Cloud Storage FUSE

הבעיה

משימות Cloud Storage FUSE פועלות לאט.

הפתרון

אפשר לקרוא את הקטע "הנחיות לאופטימיזציה של הביצועים" במאמר שימוש ב-Cloud Storage כמערכת קבצים נטענת.

הפעולה pip install נכשלת כשמשתמשים ב-KFP עם VPC Service Controls

הבעיה

מופיעה השגיאה הבאה:

ModuleNotFoundError: No module named MODULE_NAME. WARNING: Retrying (Retry(total=0, connect=None, read=None, redirect=None, status=None)) after connection broken by 'ConnectTimeoutError(&lt;pip._vendor.urllib3.connection.HTTPSConnection object at 0x7f70250bac10&gt;, 'Connection to pypi.org timed out. (connect timeout=15)')': /simple/nltk/

הפתרון

גבולות הגזרה לשירות של VPC Service Controls חוסמים את הגישה מ-Agent Platform לממשקי API ולשירותים של צד שלישי באינטרנט. כדי להתקין את החבילות, משתמשים ב-packageUris כדי להתקין את יחסי התלות מקטגוריות של Cloud Storage. לדיון כללי על השימוש בשיטה הזו, ראו "שימוש בקונטיינרים בהתאמה אישית" במאמר VPC Service Controls עם Agent Platform.

שגיאה פנימית

הבעיה

האימון נכשל בגלל שגיאת מערכת.

הפתרון

יכול להיות שהבעיה זמנית. נסו לשלוח מחדש את CustomJob, HyperparameterTuningJob או TrainingPipeline. אם השגיאה נמשכת, פנו לתמיכה.

קוד שגיאה 500 כשמשתמשים בקובץ אימג' של קונטיינר בהתאמה אישית

הבעיה

מופיעה שגיאה 500 ביומנים.

הפתרון

סביר להניח ששגיאה מהסוג הזה היא בעיה בקובץ האימג' של הקונטיינר בהתאמה אישית, ולא שגיאה ב-Agent Platform.

לחשבון השירות אין גישה לקטגוריה של Cloud Storage בזמן פריסה לנקודת קצה (endpoint)

הבעיה

אם אתם מנסים לפרוס מודל בנקודת קצה (endpoint) ולחשבון השירות שלכם אין גישה מסוג storage.objects.list לקטגוריה הרלוונטית ב-Cloud Storage, יכול להיות שתופיע השגיאה הבאה:

custom-online-prediction@TENANT_PROJECT_ID.s3ns.iam.gserviceaccount.com
does not have storage.objects.list access to the Cloud Storage bucket.

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

הפתרון

כדי לפתור את הבעיה, אתם יכולים לנסות את הפתרונות הבאים:

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

  • מעתיקים את הקובץ לקונטיינר כחלק מתהליך היצירה של הקונטיינר.

  • מציינים חשבון שירות בהתאמה אישית.

‫Agent Platform Neural Architecture Search

בעיות מוכרות

  • אחרי שמבטלים את משימת ה-NAS, המשימה הראשית (ההורה) נעצרת, אבל בחלק מהניסויים הצאצאים עדיין מוצג הסטטוס Running. במקרה כזה, התעלמו מהסטטוס Running של ניסוי הצאצא. הניסויים הופסקו, אבל בממשק המשתמש עדיין מוצג הסטטוס Running. כל עוד המשימה הראשית הופסקה, לא תחויבו בעלויות נוספות.
  • אחרי דיווח על תגמולים ב-trainer, ממתינים (sleep) במשך 10 דקות לפני היציאה ממשימות הניסיון.

  • כשמשתמשים ב-Cloud Shell כדי להריץ את TensorBoard, יכול להיות שהקישור לפלט שנוצר לא יעבוד. במקרה כזה, רושמים את מספר היציאה, משתמשים בכלי Web Preview ובוחרים את מספר היציאה הנכון כדי להציג את התרשימים.

    איך פותחים את הכלי Web Preview:

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

  • אם ביומני האימון מופיעות הודעות שגיאה כמו אלה:

    gcsfuse errors: fuse: writeMessage: no such file or directory [16 0 0 0 218 255 255 255 242 25 111 1 0 0 0 0]

    להשתמש במכונה עם יותר זיכרון RAM, כי השגיאה הזו נגרמת בגלל מצב של מחסור בזיכרון (OOM).

  • אם המאמן בהתאמה אישית לא מצליח למצוא את הדגל job-dir של ספריית המשימות, צריך לייבא את job_dir עם קו תחתון במקום מקף. ההסבר לכך מופיע בהערה ב-tutorial-1.

  • שגיאת NaN במהלך האימון יכול להיות שיהיו שגיאות NaN במשימת האימון, כמו NaN : Tensor had NaN values. יכול להיות שקצב הלמידה גדול מדי לארכיטקטורה המוצעת. מידע נוסף זמין במאמר שגיאות שקשורות לזיכרון לא מספיק (OOM) ולקצב הלמידה.

  • שגיאת OOM במהלך האימון יכול להיות שיהיו שגיאות OOM (אין מספיק זיכרון) במשימת האימון. יכול להיות שגודל האצווה גדול מדי לזיכרון של המאיץ. מידע נוסף זמין במאמר שגיאות שקשורות לזיכרון לא מספיק (OOM) ולקצב הלמידה.

  • משימת הבקר לבחירת מודל של משימת פרוקסי נכשלת במקרים נדירים שבהם משימת הבקר לבחירת מודל של משימת פרוקסי נכשלת, אתם יכולים להמשיך את המשימה לפי השלבים האלה.

  • משימת בקר החיפוש של משימת ה-proxy נכשלת במקרים נדירים שבהם משימת בקר החיפוש של משימת ה-proxy נכשלת, אפשר להמשיך את המשימה לפי השלבים האלה.

  • לחשבון השירות אין הרשאת גישה ל-Artifact Registry או לקטגוריה. אם מופיעה שגיאה כמו Agent Platform Service Agent service-123456789@gcp-sa-aiplatform-cc.s3ns-system.iam.gserviceaccount.com does not have permission to access Artifact Registry repository projects/my-project/locations/my-region/repositories/nas או שגיאה דומה לגבי גישה לקטגוריה, צריך לתת לחשבון השירות הזה תפקיד של עריכת אחסון בפרויקט.

Agent Platform Feature Store

בקטע הזה מוסבר איך פותרים בעיות שעלולות לקרות כשמשתמשים ב-Feature Store ב-Gemini Enterprise Agent Platform.

שגיאת Resource not found בשליחת בקשה להטמעת עדכונים בזמן אמת או למילוי בקשה באופן מיידי

הבעיה

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

הפתרון

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

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

הבעיה

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

הפתרון

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

ניצול המעבד (CPU) גבוה בצומת של מילוי בקשה באופן מיידי

הבעיה

ניצול המעבד (CPU) של צומת למילוי בקשות אונליין גבוה.

הפתרון

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

ניצול המעבד (CPU) גבוה בצומת הפעיל ביותר למילוי בקשות באופן מיידי

הבעיה

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

הפתרון

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

זמן האחזור של מילוי בקשה באופן מיידי גבוה כש-QPS נמוך

הבעיה

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

הפתרון

כדי לצמצם את הבעיה, צריך לשמור על החיבור פעיל על ידי שליחת תעבורת נתונים מלאכותית של לפחות 5 QPS למאגר הפיצ'רים.

משימת הטמעת נתונים באצווה נכשלת אחרי שש שעות

הבעיה

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

הפתרון

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

שגיאת Resource exceeded בייצוא של ערכי מאפיינים

הבעיה

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

הפתרון

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

‫Agent Platform Vizier

כשמשתמשים ב-Agent Platform Vizier, יכול להיות שתיתקלו בבעיות הבאות.

שגיאה פנימית

הבעיה

השגיאה הפנימית מתרחשת כשיש שגיאת מערכת.

הפתרון

יכול להיות שהיא זמנית. נסו לשלוח שוב את הבקשה, ואם השגיאה נמשכת, פנו לתמיכה.

שגיאות הרשאה כשמשתמשים בתפקידים של חשבון שירות עם Agent Platform

הבעיה

אם משתמשים בתפקידים של חשבון שירות ב-Agent Platform, מקבלים שגיאות כלליות של הרשאות.

השגיאות האלה יכולות להופיע ב-Cloud Logging ביומני הרכיבים של המוצר או ביומני הביקורת. הם יכולים להופיע גם בכל שילוב של הפרויקטים המושפעים.

הבעיות האלה יכולות להיגרם מאחת מהסיבות הבאות או משתיהן:

  • שימוש בתפקיד Service Account Token Creator במקום בתפקיד Service Account User, או להיפך. התפקידים האלה נותנים הרשאות שונות בחשבון השירות, ואי אפשר להחליף ביניהם. למידע על ההבדלים בין התפקידים Service Account Token Creator ו-Service Account User, קראו את המאמר תפקידים של חשבונות שירות.

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

הפתרון

כדי לפתור את הבעיה, נסו את הפתרונות הבאים:

  • מחליטים אם צריך את התפקיד Service Account Token Creator או Service Account User. למידע נוסף, קראו את מסמכי התיעוד של IAM לשירותי Agent Platform שבהם אתם משתמשים, וגם את כל שילובי המוצרים האחרים שבהם אתם משתמשים.

  • אם נתתם לחשבון שירות הרשאות בכמה פרויקטים, אתם יכולים לאפשר צירוף של חשבונות שירות בין פרויקטים. כדי לעשות את זה, צריך לוודא ש-iam.disableCrossProjectServiceAccountUsage. לא נאכף. כדי לוודא שהמדיניות iam.disableCrossProjectServiceAccountUsage לא נאכפת, מריצים את הפקודה הבאה:

    gcloud resource-manager org-policies disable-enforce \
  iam.disableCrossProjectServiceAccountUsage \
  --project=PROJECT_ID