מידע על Agent Substrate ב-GKE

‫Agent Substrate מריץ עומסי עבודה (workloads) של סוכנים בהיקף גדול באשכולות Kubernetes. הוא פותר בעיה נפוצה של חוסר יעילות בשימוש במשאבים: סוכנים אינטראקטיביים (כמו עוזרים אישיים וסוכני קידוד) מבלים לרוב את רוב הזמן בהמתנה לקלט מהמשתמש או להפעלות חיצוניות. השארת הסוכנים הלא פעילים האלה במצב פעיל באופן רציף גורמת לשימוש במעבד ובזיכרון שאפשר להקצות לעומסי עבודה פעילים.

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

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

פריסות רגילות של Kubernetes (כולל Agent Sandbox) משייכות כל עומס עבודה של סוכן ל-Pod ייעודי. למרות ש-Kubernetes הוא פתרון בעל יכולת הרחבה גבוהה, הוא מוגבל על ידי נפח התפוקה של התזמון וזמן האחזור של הפעלת ה-Pods. בנוסף, Kubernetes לא תומך במצב תנומה של Pods, ושמירה של מיליוני סוכנים בלי פעילות באשכול תגרום למיצוי של מגבלות ה-Pod ולמיצוי הזיכרון של מישור הבקרה. כדי להימנע מתשלום על משאבי מחשוב בלי פעילות, צריך להשבית את ה-Pods ולנהל את מצב הסוכן באחסון חיצוני. ‫Agent Substrate פותר את מגבלות ההתאמה האלה על ידי הפרדה בין מצב הסוכן לבין ה-Pods הבסיסיים: הוא מאחסן מיליוני תמונות מצב של סוכנים מושעים באחסון ומשחזר אותן לפי דרישה במאגר משותף של עובדים פעילים.

‫Agent Substrate היא מערכת בקוד פתוח שפורסים ישירות באשכולות GKE Standard. למרות שהפרויקט המרכזי מפותח בקוד פתוח במאגר Agent Substrate,‏ Google מספקת כלים וסקריפטים לפריסה שעברו אופטימיזציה ל-GKE במאגר substrate-gke, ללקוחות שעומדים בדרישות Google Cloud .

היתרונות של Agent Substrate

אפשר להשתמש ב-Agent Substrate כדי להשיג את המטרות הבאות:

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

תרחישים לדוגמה

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

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

איך פועל Agent Substrate

ה-Agent Substrate מבוסס על Kubernetes, אבל לא צריך להבין את Kubernetes כדי להשתמש בו. אלה המושגים המרכזיים של Agent Substrate:

  • סוכן: מופע יחיד של סוכן שפועל.
  • ‫ActorTemplate: תוכנית בסיס להגדרות (שמגדירה קובצי אימג' של קונטיינרים, משתני סביבה ומשאבי מחשוב) שמשמשת ליצירת מופעים של Actors.
  • Worker: ארגז חול מאובטח שבו פועל Actor פעיל.
  • ‫WorkerPool: קבוצה של עובדים שהופעלו מראש, לא פעילים ומוכנים לקבל Actor.

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

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

  1. ניתוב: כל בקשת API נכנסת מהאפליקציה מציינת את שחקן היעד שלה. לדוגמה, כשמשתמש מקליד הנחיה חדשה בממשק צ'אט, האפליקציה שולחת בקשה שמכוונת לשחקן הספציפי שמנהל את הסשן של המשתמש.
  2. הפעלה מחדש: אם הבקשה היא עבור Actor מושעה, המערכת תטען Worker חם מ-WorkerPool ותשחזר את תמונת המצב של ה-Actor ב-Worker הזה.
  3. ביצוע: המערכת מעבירה את הבקשה אל Worker חדש ופעיל, והשחקן מעבד את המשימה.
  4. השהיה: כשהשחקן מסיים את העבודה שלו והופך ללא פעיל, המערכת מצלמת תמונה חדשה של הזיכרון והקבצים של השחקן, שומרת את התמונה באחסון ומשחררת את העובד הריק בחזרה למאגר.

בידוד של עומסי עבודה ו-GKE Sandbox

‫Agent Substrate משתמש ב-gVisor או ב-Cloud Hypervisor כדי להריץ כל עומס עבודה בארגז חול שמבודד את קוד האפליקציה מליבת המארח. ההתקנה של Agent Substrate כוללת זמן ריצה של gVisor עבור Workers, כך שלא צריך להגדיר GKE Sandbox בצמתי GKE הבסיסיים.

מגבלות ודרישות

הדרישות והמגבלות של Agent Substrate:

  • גרסת האשכול וממשקי API בגרסת בטא: Agent Substrate נתמך באשכולות GKE Standard בגרסה 1.36 (עם הפעלת דגלי בטא) או בגרסה 1.37 ואילך. אין תמיכה בגרסאות קודמות ל-1.36. בנוסף, כדי להשתמש ב-GKE צריך להפעיל ממשקי API בגרסת בטא (podcertificaterequests ו-clustertrustbundles) בזמן יצירת האשכול. אי אפשר להפעיל את ממשקי ה-API האלה באשכול קיים, והפעולה תיכשל.
  • איחוד זהויות של עומסי עבודה ל-GKE: צריך להפעיל באשכולות GKE את התכונה איחוד זהויות של עומסי עבודה ל-GKE. הסוכן Agent Substrate משתמש באיחוד שירותי אימות הזהות של עומסי עבודה ל-GKE כדי לבצע אימות ל-Google Cloud APIs, כמו Cloud Storage לשמירת תמונות מצב של הסוכן.
  • VM families:
    • ארכיטקטורות מעבד מעורבות: Agent Substrate לא תומך בסדרות מכונות לשימוש כללי שפועלות בארכיטקטורות מעבד מעורבות (כמו סוגי מכונות E2) בגלל בעיה מוכרת ב-gVisor.
    • סוגי מכונות וירטואליות אחידים לכל תבנית של שחקן: אי אפשר לשלב סוגים שונים של מכונות וירטואליות בתוך ActorTemplate אחד (תוכנית ההגדרה שמשמשת ליצירת שחקנים). לדוגמה, אם באשכול יש שתי קבוצות של צמתים שמשתמשות במכונות וירטואליות מסוג C4 ו-N2, צריך לכלול ב-ActorTemplate בורר צמתים שמציין סוג אחד של מכונה וירטואלית (כמו C4), כדי למנוע פיצול של השחקנים בתבנית הזו בין סוגים שונים של מכונות.
  • תמיכה ב-GPU: אין תמיכה בהעברת GPU דרך קונטיינרים של Actor. אם מציינים רק nvidia.com/gpu,‏ Pods ממוקמים בצמתים עם GPU, אבל מכשיר ה-GPU לא מועבר למאגר של Actor. בנוסף, gVisor לא יכול ליצור תמונת מצב של הקשרים פעילים של CUDA.
  • רשת:
    • מדיניות יציאה: לא נתמכים כללים של EgressPolicy (אמצעי בקרה ברשת לפי שם מארח וכתובת IP), כולל היכולות הבאות:
      • כללי ברירת המחדל לדחייה
      • כללים שמבוססים על שם המארח
      • החדרת פרטי כניסה
    • חיבורים פתוחים: חיבורים פתוחים לרשת (כמו סשנים של מסדי נתונים או חיבורים לשרתי MCP) לא נשמרים כשסוכן משעה את הפעילות. קוד הסוכן צריך לטפל בחיבור מחדש לשירותים חיצוניים כשהסוכן חוזר לפעולה.
  • ‫Observability ו-Managed OpenTelemetry: ל-Managed OpenTelemetry for GKE יש את המגבלות הבאות:
    • ‫Managed OpenTelemetry for GKE נמצא בגרסת Preview.
    • אין תמיכה במחברים של כלי איסוף, ולכן צריך להשתמש במדד פרוקסי חיצוני להשוואה של נתוני טלמטריה.
    • פריסות של אוספים גוררות תקורה של מטמון בזיכרון שגדלה באופן לינארי עם מספר ה-Pods באשכולות גדולים.
    • אין תמיכה ב-TLS ב-Managed OpenTelemetry for GKE.
  • אחסון: המערכת דורשת Cloud Storage כדי לשמור את התמונות של הסוכנים.
  • סביבת ההתקנה: אי אפשר להתקין את Agent Substrate ב-Cloud Shell. ל-Cloud Shell יש מגבלת אחסון של 5 GB בדיסק מתמיד (persistent disk), שלא מספקת מספיק נפח אחסון להתקנה. צריך להתקין את Agent Substrate מתחנת עבודה מקומית או ממכונה וירטואלית (VM) עם מספיק מקום בדיסק.

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