בחירת אסטרטגיית איזון עומסים להסקת מסקנות של מודלים של 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 עם מדדים מותאמים אישית, שמשתמשת ב מאזני עומסים של אפליקציות. האפשרות הזו מספקת בקרה לשימוש כללי ומאפשרת לכם להגדיר את חלוקת התנועה על סמך מדדים ספציפיים לדרישות של האפליקציה או התשתית שלכם.

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

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

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

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

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

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

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

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

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

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

תכונה GKE Inference Gateway GKE Gateway עם מדדים מותאמים אישית (באמצעות Application Load Balancers)
תרחיש ראשי לדוגמה מבצע אופטימיזציה של עומסי עבודה של 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 שקשורה למשקולות של נקודות קצה בתוך אזור מסוים.
מדדים נתמכים הכלי משתמש בחבילה של מדדים מקוריים שספציפיים ל-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 באמצעות 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, תוך שמירה על אפשרויות להתאמה אישית עתידית באמצעות בסיס ה-API של GKE Gateway שניתן להרחבה.

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

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

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

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