מידע על Agent Substrate ב-GKE

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

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

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

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

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

היתרונות של Agent Substrate ב-GKE

אתם יכולים להשתמש ב-Agent Substrate ב-GKE כדי:

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

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

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

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

איך Agent Substrate פועל ב-GKE

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

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

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

מחזור חיים אופייני של נציג כולל את השלבים הבאים:

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

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

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

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

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

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

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