בחירת אסטרטגיית איזון עומסים להסקת מסקנות של מודלים של AI/ML ב-GKE

בדף הזה מוסבר איך לבחור את אסטרטגיית איזון העומסים המתאימה לעומסי עבודה של הסקת מסקנות ממודלים של AI/ML ב-Google Kubernetes Engine‏ (GKE).

הדף הזה מיועד לאנשים עם הפרופילים הבאים:

  • מהנדסי למידת מכונה (ML), אדמינים ומפעילים של פלטפורמות ומומחים לנתונים ול-AI שמעוניינים להשתמש ביכולות של Kubernetes לארגון קונטיינרים כדי להציג עומסי עבודה של AI/ML.
  • אדריכלי ענן ומומחי רשתות שיוצרים אינטראקציה עם רשתות Kubernetes.

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

לפני שקוראים את הדף הזה, חשוב לוודא שמכירים את הנושאים הבאים:

כשפורסים עומסי עבודה של הסקת מסקנות במודלים של AI/ML ב-GKE, חשוב לבחור את אסטרטגיית איזון העומסים הנכונה כדי לבצע אופטימיזציה של הביצועים, יכולת ההתאמה והעלות-תועלת:

  • בוחרים באפשרות GKE Inference Gateway כדי לבצע ניתוב אופטימלי ואיזון עומסים להצגת עומסי עבודה של AI/ML.
  • בוחרים באפשרות GKE Gateway עם מדדים מותאמים אישית, שמשתמשת ב מאזני עומסים של אפליקציות. האפשרות הזו מספקת בקרה לשימוש כללי ומאפשרת לכם להגדיר את חלוקת התנועה על סמך מדדים שספציפיים לדרישות של האפליקציה או התשתית שלכם.

סקירה כללית על GKE Inference Gateway

GKE Inference Gateway מבצע אופטימיזציה של עומסי עבודה תובעניים של AI גנרטיבי (GenAI) והסקת מסקנות מורכבת של מודלים גדולים של שפה (LLM), ומנהל אותם. הוא מרחיב את GKE Gateway API ומציע כמה יתרונות מרכזיים:

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

    • ניצול מטמון KV של שרת המודל
    • אורך תור הבקשות בהמתנה
    • ניצול כולל של GPU/TPU
    • זמינות של מתאמי LoRA
    • העלות החישובית של בקשות בודדות. על סמך המדדים האלה, שער הכניסה מחלק את התנועה בצורה חכמה בין העותקים של שרת המודל שהכי מתאימים ושהעומס עליהם הכי נמוך.

  • תעדוף בקשות: השער מספק מנגנונים לתעדוף בקשות.

  • שינוי קנה מידה אוטומטי אופטימלי: השער מציע מנגנונים אופטימליים לשינוי קנה מידה אוטומטי של שרתי מודלים.

סקירה כללית של GKE Gateway עם מדדים מותאמים אישית

‫Cloud de Confiance מציע משאבים של מאזן עומסים של אפליקציות שתומכים בהיקפים כמו חיצוני גלובלי וחיצוני אזורי. מאזני העומסים לשימוש כללי האלה מפזרים את התנועה על סמך מדדים מותאמים אישית שמדווחים על ידי שירותי ה-Backend. הגישה הזו מאפשרת שליטה מדויקת בחלוקת העומס, כך שתוכלו לבסס אותה על מדדי ביצועים ספציפיים לאפליקציה.

השוואה בין GKE Inference Gateway ו-GKE Gateway עם מדדים מותאמים אישית

הטבלה הבאה מאפשרת להשוות בין התכונות של GKE Inference Gateway ו-GKE Gateway עם מדדים מותאמים אישית, ולבחור את הפתרון המתאים לאיזון עומסים עבור עומסי העבודה של מסקנות AI/ML ב-GKE.

תכונה GKE Inference Gateway GKE Gateway עם מדדים מותאמים אישית (דרך מאזני עומסים של אפליקציות)
תרחיש ראשי לדוגמה מבצע אופטימיזציה של עומסי עבודה של בינה מלאכותית גנרטיבית ושל למידת מכונה ב-Kubernetes, כולל הפעלת מודלים גדולים של שפה (LLM). הוא מבטיח גישה הוגנת למשאבי מודלים ומבצע אופטימיזציה לעומסי עבודה של מודלים גדולים של שפה (LLM) שמבוססים על GPU או TPU, שבהם זמן האחזור הוא גורם חשוב. מספק איזון עומסים ל-HTTP(S) לשימוש כללי, ומפיץ את התנועה על סמך מדדים מותאמים אישית שמדווחים על ידי האפליקציה. איזון עומסים כזה מתאים במיוחד לשירותים שרגישים לזמן אחזור, כמו שרתים של משחקים בזמן אמת או פלטפורמות של מסחר בתדירות גבוהה, שמדווחים על נתוני שימוש בהתאמה אישית.
ניתוב בסיסי תומך בניתוח סטנדרטי של HTTP(S) על סמך מארח ונתיב, ומרחיב את GKE Gateway API. תמיכה בניווט רגיל ב-HTTP(S) על סמך המארח והנתיב. ההגדרה מתבצעת באמצעות המשאבים הרגילים של GKE Gateway API.
לוגיקת ניתוב מתקדמת הוא מספק יכולות מתקדמות כמו ניתוב מודע-מודל, פיצול תנועה, שיקוף והחלת רמות עדיפות ורמות קריטיות על בקשות. מאזן את התנועה על סמך מדדים מותאמים אישית שמדווחים על ידי האפליקציה באמצעות התקן Open Request Cost Aggregation (ORCA). כך אפשר להפעיל מדיניות כמו WEIGHTED_ROUND_ROBIN לשקלול נקודות קצה (endpoint) בתוך אזור.
מדדים נתמכים הכלי משתמש בחבילה של מדדים מקוריים שספציפיים ל-AI, כמו שימוש ב-GPU או ב-TPU, פגיעות במטמון KV ואורך תור הבקשות. אפשר גם להגדיר אותו כך שישתמש במדדים שמדווחים על ידי האפליקציה באמצעות מנגנון סטנדרטי של כותרות HTTP. הדיווח מתבסס על מדדים שדווחו על ידי האפליקציה באמצעות מנגנון כותרות HTTP סטנדרטי, במיוחד Open Request Cost Aggregation (ORCA). המנגנון הזה תומך במדדים סטנדרטיים כמו מעבד (CPU) וזיכרון, וגם במדדים עם שמות מותאמים אישית למשאבים מוגבלים שספציפיים לאפליקציה.
טיפול בבקשות הוא נועד לטפל בעומסי עבודה עם עלויות לא אחידות של בקשות, שכיחות במודלים גדולים של שפה (LLM) בגלל מורכבות משתנה של הנחיות. הוא תומך ברמות קריטיות של בקשות, ומאפשר לתעדף סוגים שונים של בקשות הסקה. הכי מתאים לעומסי עבודה שבהם עלויות העיבוד של בקשות בודדות הן יחסית אחידות. הפתרון הזה לא כולל יכולות מובנות של תעדוף בקשות.
תמיכה במתאם LoRa השירות מציע ניתוב מובנה שמבוסס על קרבה לשרתי קצה שמצוידים במתאמי LoRa ספציפיים, כדי להבטיח שהבקשות יופנו למשאבים המתאימים. לא מספק תמיכה מובנית במתאמי LoRa או בניתוב מבוסס-זיקה על סמך הגדרות LoRa.
שילוב של התאמה אוטומטית לעומס מבצע אופטימיזציה של התאמה אוטומטית לעומס של שרתים של מודלים על ידי שימוש במדדים ספציפיים ל-AI, כמו ניצול מטמון KV, כדי לקבל החלטות מושכלות יותר לגבי שינוי הגודל. משולב עם Horizontal Pod Autoscaler‏ (HPA) באמצעות מדדים מותאמים אישית. המדדים האלה מדווחים למאזן העומסים של האפליקציה ומשמשים באופן כללי לצורך שינוי גודל, על סמך אותות העומס המדווחים.
הגדרה וקביעת תצורה להגדיר אותו באמצעות GKE Gateway API. הרחבת ה-API הרגיל באמצעות InferencePool ו-InferenceModel Custom Resource Definitions (CRDs) מיוחדים כדי להפעיל את התכונות שמבוססות על AI. מגדירים את הפתרון הזה באמצעות המשאבים הרגילים של GKE Gateway API. האפליקציה צריכה להטמיע מנגנון מבוסס-כותרות HTTP, כמו Open Request Cost Aggregation ‏ (ORCA), כדי לדווח על מדדים מותאמים אישית לאיזון עומסים.
אבטחה הפתרון הזה כולל סינון תוכן שנוצר על ידי AI באמצעות הגנה מוגברת על המודל ברמת השער. הוא גם משתמש בתכונות אבטחה בסיסיות של GKE, כמו TLS, ניהול זהויות והרשאות גישה (IAM), בקרת גישה שמבוססת על תפקידים (RBAC) ומרחבי שמות. הפתרון הזה משתמש בחבילת האבטחה הרגילה של Application Load Balancer, שכוללת את Google Cloud Armor, סיום TLS ו-IAM. כדי להפעיל סינון תוכן מבוסס-AI, אפשר לשלב את Google Cloud Armor כהרחבת שירות.
ניראות (observability) השירות מציע יכולת מובנית של ניטור מדדים ספציפיים ל-AI, כולל ניצול GPU או TPU, פגיעות במטמון KV, אורך תור הבקשות וחביון המודל. התכונה 'יכולת צפייה' מסתמכת על מדדים מותאמים אישית שהאפליקציה מוגדרת לדווח עליהם. אפשר לראות את המדדים האלה ב-Cloud Monitoring. הם יכולים לכלול מדדים רגילים או מדדים עם שמות בהתאמה אישית.
יכולת הרחבה הוא מבוסס על פלטפורמת קוד פתוח שניתנת להרחבה, ומאפשרת שימוש באלגוריתם לבחירת נקודות קצה שמנוהל על ידי המשתמש. הוא מרחיב את GKE Gateway API עם [הגדרות מותאמות אישית של משאבים (CRD)](/kubernetes-engine/docs/how-to/deploy-gke-inference-gateway) מיוחדות, כמו InferencePool ו-InferenceModel, כדי לפשט תרחישי שימוש נפוצים ב-AI. הוא מתוכנן להיות גמיש, ומאפשר להרחיב את איזון העומסים באמצעות [מדד מותאם אישית (אות עומס)](/load-balancing/docs/https/applb-custom-metrics) שהאפליקציה מדווחת עליו באמצעות תקן ORCA.
שלב ההשקה GA GA

מתי כדאי להשתמש ב-GKE Inference Gateway

בוחרים באפשרות GKE Inference Gateway כדי לבצע אופטימיזציה של עומסי עבודה מתוחכמים של AI והסקת מסקנות של למידת מכונה ב-GKE, במיוחד עבור מודלים גדולים של שפה (LLM). אנחנו ממליצים על הפתרון הזה במצבים הבאים:

  • הפעלת מודלי שפה גדולים: כשמשתמשים בשרתי מודלים כמו vLLM, צריך לקבל החלטות לגבי ניתוב על סמך מצבים ספציפיים של מודלי שפה גדולים, כמו ניצול מטמון KV או אורך תור הבקשות.
  • פריסת מודלים עם מתאמי LoRa: נדרש ניתוב חכם שמבוסס על קרבה לשרתי קצה שמצוידים במתאמי LoRa הנכונים והזמינים.
  • טיפול בבקשות להסקת מסקנות עם עלויות עיבוד שמשתנות מאוד: לדוגמה, גדלים או מורכבות דינמיים של הנחיות מחייבים שימוש במאזן עומסים שמתחשב בעלויות.
  • הטמעה של תעדוף בקשות: צריך לתעדף סוגים שונים של תנועת הסקת מסקנות, כמו בקשות קריטיות, רגילות או כאלה שאפשר להשליך.
  • אופטימיזציה של התאמה אוטומטית לעומס: אתם רוצים מנגנון התאמה אוטומטית לעומס שמשולב באופן הדוק עם מדדי ביצועים ספציפיים של שרתים של מודלים של AI גנרטיבי (GenAI), כמו ניצול מטמון KV, כדי לקבל החלטות מושכלות יותר לגבי התאמה אוטומטית לעומס.
  • שימוש בשילוב של הגנה מוגברת על המודל: צריך להשתמש בהגנה מוגברת על המודל לבדיקות בטיחות של AI ברמת השער.
  • קבלת ניראות מוכנה לשימוש: אתם צריכים ניראות מובנית למדדים קריטיים שספציפיים ל-AI, כולל ניצול GPU או TPU, פגיעות במטמון KV ואורך תור הבקשות.
  • רוצים לפשט את הפריסות של AI גנרטיבי: אתם מעדיפים פתרון ייעודי שמפשט דפוסי פריסה נפוצים של AI גנרטיבי ב-GKE, תוך שמירה על אפשרויות להתאמה אישית עתידית באמצעות בסיס ה-API של GKE Gateway שניתן להרחבה.

מתי כדאי להשתמש ב-GKE Gateway עם מדדים מותאמים אישית

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

  • עומס העבודה כולל נפח תנועה גבוה עם עלויות עיבוד אחידות יחסית לכל בקשה.
  • אפשר לנהל את חלוקת העומס בצורה יעילה באמצעות מדד מותאם אישית ספציפי אחד או שניים שמדווחים על ידי האפליקציה, בדרך כלל באמצעות כותרות של תגובות HTTP, לפי תקן הדיווח על עומס Open Request Cost Aggregation ‏ (ORCA).
  • הדרישות שלכם לאיזון עומסים לא תלויות בתכונות ספציפיות של AI גנרטיבי או של מודלים גדולים של שפה (LLM).
  • המודל התפעולי שלכם לא דורש את היכולות המיוחדות של ה-AI ש-GKE Inference Gateway מספק, וכך נמנעת מורכבות ארכיטקטונית מיותרת.
  • חשוב לנו לשמור על עקביות עם פריסות קיימות של Application Load Balancer, והפריסות האלה עומדות בדרישות איזון העומסים של שירות ההסקה.

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