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

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

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

שיקולים בבחירת פתרון אחסון

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

דרישות הפלטפורמה

הערכת הדרישות התפעוליות והארכיטקטוניות הבאות של הפלטפורמה:

  • היקף הפלטפורמה ותדירות הנטישה של הסוכנים (מישור הבקרה): מספר הסוכנים בו-זמנית, ומספר הסוכנים שנוצרו, הושעו, הופעלו מחדש ונמחקו בכל דקה. פלטפורמות שיוצרות אלפי סוכנים בדקה או שמשהות סוכנים לא פעילים צריכות אחסון עם פעולות צירוף והרכבה של נפח אחסון עם השהיה נמוכה בקנה מידה משמעותי (לדוגמה, הרכבה של Filestore מהירה יותר מצירוף של Hyperdisk).
  • גודל מערך הנתונים וזמן האחזור של הטעינה (מישור הנתונים): סוכנים שטוענים מערכי נתונים של כמה גיגה-בייט או ספריות כבדות (כמו חבילות Node.js או Python) במהלך ההפעלה דורשים ביצועים גבוהים של קלט/פלט באחסון כדי לקרוא את הנתונים תוך שניות (לדוגמה, Hyperdisk מציע תפוקת קריאה גבוהה לכל דיסק).
  • זמן הטעינה של הפעלה מההתחלה (cold startup) והשהיית הפעלה מחדש של סוכן: זמן האחזור הצפוי, למשל פחות משנייה או כמה שניות. כדי להשיג זמן טעינה של פחות משנייה, צריך להשתמש ב-GKE Agent Sandbox Warm Pools. בדרך כלל, שימוש ביצירת ארגז חול ישירה גורם לעיכוב של כמה שניות בהפעלה של Pod ובצירוף דינמי של דיסק.
  • גודל האחסון לכל סוכן: בהתאם לשירות שנבחר, צריך להתאים את מגבלות ההקצאה, כמו גודל מינימלי של 4 GiB ל-Google Cloud Hyperdisk או מינימום של 10 GiB לשיתוף יחיד של Filestore.
  • מצבי גישה לנתונים ובידוד: איך הפלטפורמה צריכה לתמוך בבידוד של סביבת העבודה ובסביבות עבודה שיתופיות. ההגדרה הזו קובעת אם הסוכנים שלכם יצטרכו סביבות עבודה פרטיות ומבודדות (ReadWriteOnce), סביבות עבודה שיתופיות (ReadWriteMany) או סביבות עבודה של הסתעפות לחיפושים (תבנית לקריאה בלבד עם לוח שרטוט שאפשר לכתוב בו).
  • עמידות: אם הסוכנים שלכם דורשים עמידות אזורית ספציפית, Filestore Multishares for GKE (Enterprise) היא הבחירה המתאימה.
  • עלות האחסון: יש הבדלים משמעותיים במחירים של שירותי אחסון. למשל, Hyperdisk Balanced הוא אפשרות חסכונית יותר בהשוואה ל-Filestore Multishares.

דפוסי מחזור החיים של נתוני הסוכן

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

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

מצבי גישה לנתונים של סוכנים

אם הסוכנים צריכים לגשת לאחסון באחד ממצבי הגישה לנתונים הבאים, צריך לבחור שירות אחסון שתומך בצרכים שלהם:

  • סביבת עבודה פרטית ומבודדת: סוכן מופעל עם ספריית אחסון פרטית ומבודדת שיש לו גישת קריאה וכתיבה בלעדית אליה.
  • סביבת עבודה שיתופית: כמה סוכנים מתואמים מטמיעים את אותה ספרייה משותפת בדיוק במצב קריאה-כתיבה (RW) כדי לעדכן קבצים בשיתוף פעולה בזמן אמת.
  • סביבת עבודה של הסתעפות לחיפוש: הסוכן ניגש לקבצי תבנית בסיס במצב קריאה בלבד (RO) כדי למנוע שינוי בתבנית, ומבצע כתיבות חדשות על ידי ניתוב שלהן ללוח שרטוט מקומי נפרד emptyDir או לנתיב פרטי מתמשך, או על ידי העתקת קבצי התבנית ישירות לסביבת עבודה פרטית שניתנת לכתיבה בעת ההפעלה.

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

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

  • משתמשים ב-Hyperdisk Balanced לאחסון חסכוני של סוכנים שסובלים השהיית הפעלה של כמה שניות ומשתמשים בסביבת עבודה פרטית ומבודדת עם מצב גישה ReadWriteOnce ‏ (RWO).
  • משתמשים ב-Filestore Multishares ל-GKE ‏ (Enterprise) לסוכנים שזקוקים לסביבת עבודה שיתופית או לחוסן אזורי.

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

תכונה Hyperdisk Balanced Filestore Multishares for GKE (Enterprise)
מתאים במיוחד ל
  • סביבות עבודה נפרדות עם מצב גישה ReadWriteOnce ‏ (RWO)
  • עומסי עבודה שסובלים חביון של כמה שניות בצירוף אחסון
  • עלות-תועלת
  • יצירה ישירה של ארגז חול
  • סביבות עבודה שיתופיות עם מצב גישה ReadWriteMany ‏ (RWX)
  • עומסי עבודה שדורשים זמן טעינה קצר מאוד לחיבור האחסון
  • חוסן אזורי
מצבי גישה ReadWriteOnce (RWO)‎

הערה: כדי להשתמש במצב ReadOnlyMany (ROX), צריך להשתמש ב-Hyperdisk ML.
ReadWriteMany ‏ (RWX)
הפעלה של סביבת ארגז חול לסוכנים תוך פחות משנייה (מאגרי סוכנים חמים)
  • סביבת עבודה זמנית: אפשר לצרף מראש נפח אחסון ריק בזמן היצירה, והוא נמחק אחרי שהסשן הפעיל מסתיים.
  • שחזור של סביבת עבודה עם שמירת מצב או שחזור לנקודת זמן מסוימת: נדרש סקריפט בהתאמה אישית ו-DaemonSet לקישור דינמי של נפח (דוגמה ב-GitHub).
  • סביבת עבודה זמנית: אפשר לצרף מראש נפח אחסון ריק בזמן היצירה, והוא נמחק אחרי שהסשן הפעיל מסתיים.
  • שחזור של סביבת עבודה עם שמירת מצב או שחזור לנקודת זמן מסוימת: נדרש סקריפט בהתאמה אישית ו-DaemonSet לאיגוד דינמי של נפח (דוגמה ב-GitHub).
זמן האחזור של הקצאת נפח אחסון כמה שניות לכל כרך
  • שש דקות ליצירת מופע עם עד 80 שיתופים
  • אפשר ליצור כמה מופעים במקביל
זמן האחזור של צירוף והרכבה של נתיב פעיל כמה שניות לצירוף דיסק פחות משנייה לטעינת Network NFS
תפוקת קריאה מקסימלית
  • ‫2,400 MiB/s לכל דיסק
  • התפוקה מוגבלת על ידי המגבלה של החומרה הפיזית של המכשיר המחובר
  • ‫120 MiB/s לכל 1 TiB של קיבולת שהוקצתה
  • התפוקה מוגבלת ל-1,200 MiB/s במקרה של מכונת multishares בנפח מקסימלי של 10 TiB
IOPS ‫3,000 עד 160,000, בהתאם לגודל ולתצורה של נפח האחסון
  • קריאות IOPS: 12,000 קריאות IOPS לכל 1 TiB של קיבולת מופע (מקסימום 120,000 קריאות IOPS)
  • Write IOPS: 4,000 Write IOPS לכל 1 TiB של קיבולת המופע (מקסימום 40,000 Write IOPS)
מגבלות גודל
  • לכל דיסק: מינימום 4 GiB, מקסימום 64 TiB (128 TiB ב-C4)
  • Per node: maximum 247 TiB for fewer than 32 vCPUs, or 512 TiB for 32 or more vCPUs
מגבלות על התאמה לעומס
  • לכל צומת: אין מגבלות על קבצים מצורפים
  • לכל מופע של שיתוף מרובה: מקסימום 80 שיתופים, ועד 20,000 חיבורים (2,000 לכל 1 TiB, עם הגדלה במרווחים של 500)
כיוון שינוי הקיבולת הגדלה בלבד הגדלה או הקטנה של המידות
תמיכה ב-CSI VolumeSnapshot נתמך לא נתמך (אין תמיכה בתמונות מצב לכל שיתוף)
מחיר תמחור של Persistent Disk ו-Google Cloud Hyperdisk תמחור של Filestore

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