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

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

הדף הזה מיועד לדמויות הבאות:

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

כדי לקבל מידע נוסף על תפקידים נפוצים ועל משימות לדוגמה שאנחנו מתייחסים אליהם בGoogle Cloud תוכן, אפשר לעיין במאמר תפקידים נפוצים של משתמשי GKE ומשימות.

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

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

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

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

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

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

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

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

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

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

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

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

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

תכונה GKE Inference Gateway GKE Gateway עם מדדים מותאמים אישית (דרך מאזני עומסים של אפליקציות)
תרחיש ראשי לדוגמה מבצע אופטימיזציה של עומסי עבודה של AI גנרטיבי והסקת מסקנות של למידת מכונה ב-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) load reporting. המנגנון הזה תומך במדדים סטנדרטיים כמו מעבד (CPU) וזיכרון, וגם במדדים עם שמות בהתאמה אישית למשאבים מוגבלים ספציפיים לאפליקציה.
טיפול בבקשות הוא נועד לטפל בעומסי עבודה עם עלויות בקשה לא אחידות, שכיחות במודלים גדולים של שפה בגלל מורכבות משתנה של הנחיות. הוא תומך ברמות קריטיות של בקשות, ומאפשר לתת עדיפות לסוגים שונים של בקשות הסקה. הכי מתאים לעומסי עבודה שבהם עלויות העיבוד של בקשות בודדות הן יחסית אחידות. הפתרון הזה לא כולל יכולות מובנות של תעדוף בקשות.
תמיכה במתאם LoRa השירות מציע ניתוב מובנה שמבוסס על קרבה לשרתי קצה שמצוידים במתאמי LoRa ספציפיים, וכך עוזר לוודא שהבקשות מופנות למשאבים המתאימים. לא מספקת תמיכה מובנית במתאמי LoRa או בניתוב מבוסס-זיקה על סמך הגדרות LoRa.
שילוב של התאמה אוטומטית לעומס מבצע אופטימיזציה של שינוי הגודל האוטומטי של שרתים של מודלים באמצעות מדדים ספציפיים ל-AI, כמו ניצול מטמון KV, כדי לקבל החלטות מושכלות יותר לגבי שינוי הגודל. משולב עם Horizontal Pod Autoscaler‏ (HPA) באמצעות מדדים מותאמים אישית ומדדים חיצוניים. המדדים האלה מדווחים למאזן העומסים של האפליקציה ומשמשים באופן כללי להתאמת קנה המידה, על סמך אותות העומס המדווחים.
הגדרה וקביעת תצורה להגדיר אותו באמצעות GKE Gateway API. ה-API הרגיל מורחב באמצעות הגדרות מותאמות אישית של משאבים (CRD) של InferencePool ושל InferenceModel כדי להפעיל את התכונות מבוססות-AI שלו. מגדירים את הפתרון הזה באמצעות המשאבים הרגילים של GKE Gateway API. האפליקציה צריכה להטמיע מנגנון מבוסס-כותרות HTTP, כמו Open Request Cost Aggregation‏ (ORCA), כדי לדווח על מדדים בהתאמה אישית לאיזון עומסים.
אבטחה הפתרון הזה כולל סינון תוכן שנוצר על ידי AI באמצעות Model Armor ברמת השער. הוא גם משתמש בתכונות אבטחה בסיסיות של 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, כדי לקבל החלטות מושכלות יותר לגבי שינוי הגודל.
  • שימוש בשילוב של Model Armor: צריך להשתמש ב-Model Armor לבדיקות בטיחות של AI ברמת השער.
  • קבלת ניראות מוכנה לשימוש: אתם צריכים ניראות מובנית למדדים קריטיים שספציפיים ל-AI, כולל ניצול GPU או TPU, פגיעות במטמון KV ואורך תור הבקשות.
  • רוצים לפשט את הפריסות של AI גנרטיבי: אתם מעדיפים פתרון ייעודי שמפשט דפוסי פריסה נפוצים של AI גנרטיבי ב-GKE, תוך שמירה על אפשרויות להתאמה אישית בעתיד באמצעות GKE Gateway API, שניתן להרחבה.

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

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

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

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