מידע על Agent Substrate ב-GKE

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

הפלטפורמה 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: קבוצה של Worker שהופעלו מראש ונמצאים במצב המתנה, ומוכנים לקבל Actor.

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

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

  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 האלה באשכול קיים שמריץ גרסה 1.36, צריך גם להחליף את הצמתים הקיימים כדי שהקרנת אישורים של Pod תופעל בהם. בגרסה 1.37 ואילך, אין צורך להחליף צמתים קיימים.
  • איחוד זהויות של עומסי עבודה ל-GKE: באשכולות GKE צריך להפעיל את התכונה איחוד זהויות של עומסי עבודה ל-GKE. ה-Agent Substrate משתמש באיחוד זהויות של עומסי עבודה ל-GKE כדי לבצע אימות ל- Google Cloud APIs, כמו Cloud Storage, כדי לשמור תמונות מצב של הסוכן.
  • משפחות של מכונות וירטואליות:
    • ארכיטקטורות מעבדים מעורבות: Agent Substrate לא תומך בסדרות מכונות לשימוש כללי שפועלות על ארכיטקטורות מעבדים מעורבות (כמו סוגי מכונות E2) בגלל בעיה מוכרת ב-gVisor.
    • סוגי מכונות וירטואליות אחידים לכל תבנית של Actor: אי אפשר לשלב סוגים שונים של מכונות וירטואליות ב-ActorTemplate אחד (תוכנית הבסיס להגדרות שמשמשת ליצירת Actors). לדוגמה, אם באשכול שלכם יש שני מאגרי צמתים שמשתמשים במכונות וירטואליות מסוג C4 ו-N2, תבנית ActorTemplate צריכה לכלול בורר צמתים שמציין סוג אחד של מכונה וירטואלית (למשל C4), כדי למנוע פיצול של רכיבי Actor בתבנית בין סוגים שונים של מכונות.
  • תמיכה ב-GPU: אין תמיכה בהעברת GPU דרך קונטיינרים של Actor. הגדרה של nvidia.com/gpu רק ממקמת את ה-Pods בצמתים עם GPU, אבל לא מעבירה את מכשיר ה-GPU למאגר של ה-Actor. בנוסף, gVisor לא יכול ליצור תמונת מצב של הקשרים פעילים של CUDA.
  • רשת:
    • מדיניות יציאה: לא נתמכים כללים של EgressPolicy (אמצעי בקרה ברשת לפי שם מארח וכתובת IP), כולל היכולות הבאות:
      • כללי דחייה שמוגדרים כברירת מחדל
      • כללים שמבוססים על שם המארח
      • החדרת פרטי כניסה
    • חיבורים פתוחים: חיבורים פתוחים לרשת (כמו סשנים של מסדי נתונים או חיבורים לשרתי MCP) לא נשמרים כשסוכן משעה את הפעילות. קוד הסוכן צריך לטפל בחיבור מחדש לשירותים חיצוניים כשהסוכן חוזר לפעולה.
  • ‫Observability ו-Managed OpenTelemetry: ל-Managed OpenTelemetry for GKE יש את המגבלות הבאות:
    • ‫OpenTelemetry מנוהל ל-GKE נמצא בגרסת Preview.
    • אין תמיכה במחברים של כלי איסוף, ולכן צריך להשתמש במדד פרוקסי חיצוני להשוואה של נתוני טלמטריה.
    • פריסות של Collector כרוכות בתקורה של מטמון בזיכרון, שגדלה באופן לינארי עם מספר ה-Pods באשכולות גדולים.
    • אין תמיכה ב-TLS ב-Managed OpenTelemetry for GKE.
  • אחסון: המערכת דורשת Cloud Storage כדי לשמור את התמונות של הסוכנים.
  • סביבת התקנה: אי אפשר להתקין את Agent Substrate ב-Cloud Shell. ב-Cloud Shell יש מגבלת אחסון של 5 GB בדיסק מתמיד, שלא מספקת מספיק מקום בדיסק להתקנה. צריך להתקין את Agent Substrate מתחנת עבודה מקומית או ממכונה וירטואלית (VM) עם מספיק מקום בדיסק.

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