מידע על GKE Inference Gateway שמופעל באמצעות llm-d

בדף הזה מוסברים המושגים והתכונות העיקריים של Google Kubernetes Engine ‏ (GKE) Inference Gateway, תוסף ל-GKE Gateway שמאפשר להציג אפליקציות של AI גנרטיבי בצורה אופטימלית.

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

• תזמור של AI/ML ב-GKE
• טרמינולוגיה של AI גנרטיבי
• מושגים של רשתות GKE, כולל שירותים ו-GKE Gateway API
• איזון עומסים ב- Cloud de Confiance, במיוחד האינטראקציה של מאזני העומסים עם GKE

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

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

סקירה כללית

‫GKE Inference Gateway הוא תוסף ל-GKE Gateway שמספק ניתוב אופטימלי ואיזון עומסים להפעלת עומסי עבודה של בינה מלאכותית (AI) גנרטיבית. הוא מפשט את הפריסה, הניהול והתצפית של עומסי עבודה (workloads) של הסקת מסקנות מ-AI. ‫GKE Inference Gateway זמין ללא עלות נוספת. אתם משלמים רק על המשאבים הבסיסיים של Cloud de Confiance by S3NS שבהם אתם משתמשים.

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

תכונות ויתרונות

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

• מדדים נתמכים:
  • ‫KV cache hits: מספר החיפושים המוצלחים במטמון של ערכי המפתח (KV).
  • ניצול GPU או TPU: אחוז הזמן שבו ה-GPU או ה-TPU מעבדים באופן פעיל.
  • אורך תור הבקשות: מספר הבקשות שממתינות לעיבוד.
• איזון עומסים אופטימלי להסקת מסקנות: חלוקת הבקשות כדי לשפר את הביצועים של פרסום מודל ה-AI. הוא משתמש במדדים משרתי מודלים, כמו KV cache hits ו-queue length of pending requests, כדי לצרוך מאיצים (כמו GPUs ו-TPUs) בצורה יעילה יותר לעומסי עבודה של AI גנרטיבי. כך מפעילים את התכונה Prefix-Cache Aware Routing, ששולחת בקשות עם הקשר משותף, שזוהה על ידי ניתוח גוף הבקשה, לאותו עותק של המודל על ידי הגדלת מספר המציאות במטמון (cache hits). הגישה הזו מפחיתה באופן משמעותי את החישובים המיותרים ומשפרת את הזמן עד לקבלת הטוקן הראשון (TTFT), מה שהופך אותה ליעילה מאוד ב-AI בממשק שיחה, ב-Retrieval-Augmented Generation‏ (RAG) ובעומסי עבודה אחרים של AI גנרטיבי שמבוססים על תבניות.
• פרסום מודלים דינמיים שעברו כוונון באמצעות LoRA: תמיכה בפרסום מודלים דינמיים שעברו כוונון באמצעות LoRA במאיץ נפוץ. כך אפשר להפחית את מספר יחידות ה-GPU וה-TPU שנדרשות להצגת מודלים, על ידי ריבוב של כמה מודלים שעברו כוונון מדויק של LoRA במודל בסיס ובמאיץ משותפים.
• התאמה אופטימלית לעומס (scaling) להסקת מסקנות: הכלי Horizontal Pod Autoscaler‏ (HPA) של GKE משתמש במדדים של שרת המודל כדי להתאים את העומס, וכך עוזר להבטיח שימוש יעיל במשאבי המחשוב וביצועים אופטימליים של הסקת המסקנות.
• ניתוב מודע-מודל: ניתוב בקשות להסקת מסקנות על סמך שמות המודלים שמוגדרים במפרטים של OpenAI API באשכול GKE. אתם יכולים להגדיר מדיניות ניתוב של Gateway, כמו חלוקת התנועה ושיקוף בקשות, כדי לנהל גרסאות שונות של מודלים ולפשט את ההשקה של המודלים. לדוגמה, אתם יכולים לנתב בקשות לשם של מודל ספציפי לאובייקטים שונים של InferencePool, שכל אחד מהם מציג גרסה שונה של המודל. מידע נוסף על הגדרת האפשרות הזו זמין במאמר הגדרת ניתוב לפי גוף ההודעה.
• אמצעי בטיחות משולבים של AI וסינון תוכן: GKE Inference Gateway משתלב עם Cloud de Confiance Model Armor כדי להחיל בדיקות בטיחות של AI וסינון תוכן על הנחיות ותשובות בשער. אפשר גם להשתמש ב-NVIDIA NeMo Guardrails. הכלי "הגנה מוגברת על המודל" מספק יומנים של בקשות, תגובות ועיבוד לצורך ניתוח רטרוספקטיבי ואופטימיזציה. הממשקים הפתוחים של GKE Inference Gateway מאפשרים לספקים ולמפתחים של צד שלישי לשלב שירותים בהתאמה אישית בתהליך של בקשת ההסקה.
• הצגה ספציפית למודל Priority: מאפשרת לציין את ההצגה Priority של מודלים של AI. תעדוף בקשות שרגישות לזמן אחזור על פני משימות של הסקת מסקנות באצווה שסובלות זמן אחזור. לדוגמה, אתם יכולים לתת עדיפות לבקשות מאפליקציות שרגישות לזמן אחזור, ולבטל משימות פחות רגישות לזמן כשהמשאבים מוגבלים.
• ניתוב חזוי שמבוסס על זמן אחזור: ניתוב של בקשות להסקת מסקנות באמצעות מודל XGBoost שעובר אימון באופן רציף על תנועה בזמן אמת, תוך אופטימיזציה של יעדי הזמן עד לקבלת הטוקן הראשון (TTFT) והזמן לכל טוקן פלט (TPOT) לכל בקשה. יותר מדויק מהיוריסטיקה הסטטית בעומסי עבודה עם שונות גבוהה. אפשר לקרוא על שימוש בניתוב מבוסס-חביון חזוי עם GKE Inference Gateway.
• ניראות של הסקת מסקנות: מספקת מדדי ניראות לבקשות להסקת מסקנות, כמו קצב הבקשות, זמן האחזור, שגיאות ורוויה. מעקב אחרי הביצועים וההתנהגות של שירותי ההסקה באמצעות Cloud Monitoring ו-Cloud Logging, תוך שימוש במרכזי בקרה ייעודיים מוכנים מראש לקבלת תובנות מפורטות. מידע נוסף זמין במאמר הצגת לוח הבקרה של GKE Inference Gateway.
• הגדרות CORS: תמיכה בשיתוף משאבים ממקורות שונים (CORS) במשאבי HTTPRoute. מנגנון CORS עוזר לאפליקציות אינטרנט שפועלות בדומיינים שונים לגשת באופן מאובטח לנקודות הקצה להסקת מסקנות. יש תמיכה ב-CORS בשערי כניסה (Gateways) של אשכול יחיד.
• ניהול מתקדם של API באמצעות Apigee: שילוב עם Apigee כדי לשפר את שער ההסקה באמצעות תכונות כמו אבטחת API, הגבלת קצב ומכסות. הוראות מפורטות זמינות במאמר הגדרת Apigee לאימות ולניהול ממשקי API.
• יכולת הרחבה: מבוסס על תוסף להסקת מסקנות של Kubernetes Gateway API בקוד פתוח, שתומך באלגוריתם llm-d Endpoint Picker (EPP)‎ בניהול המשתמש, שמופעל על ידי llm-d. האלגוריתם llm-d Endpoint Picker (EPP)‎, שמבוסס על llm-d, מספק את יכולות הניתוב העיקריות של התוסף הזה.
• תמיכה בכמה יציאות: תמיכה בשרתי מודלים שחושפים כמה יציאות, שחיונית לתרחישי הצגה מתקדמים כמו Data Parallel attention.
• מגבלות על קבוצות של נקודות קצה ברשת (NEG): מגבלה של 50 קבוצות של נקודות קצה ברשת לכל שירות לקצה העורפי שלCloud de Confiance by S3NS . כשמשתמשים ב-InferencePool עם כמה יציאות, כל יציאה בכל אזור יוצרת NEG ייעודי. לדוגמה, InferencePool עם שמונה יציאות באשכול אזורי אופייני (שלושה אזורים) יוצר 24 קבוצות NEG. לכן, שער עם כמה אשכולות יכול לצבור InferencePool כזה רק משני אשכולות לכל היותר (שני אשכולות × 24 קבוצות NEG‏ = 48 קבוצות NEG) לפני שהוא מגיע למגבלה של 50 קבוצות NEG.

הסבר על מושגי מפתח

‫GKE Inference Gateway משפר את GKE Gateway הקיים שמשתמש באובייקטים של GatewayClass. ב-GKE Inference Gateway יש הגדרות חדשות של משאבים בהתאמה אישית (CRD) ל-Gateway API, שתואמות לתוסף של OSS Kubernetes Gateway API להסקה:

• אובייקט InferencePool: מייצג קבוצה של Pods (קונטיינרים) שחולקים את אותה הגדרת מחשוב, סוג מאיץ, מודל שפה בסיסי ושרת מודל. כך אפשר לקבץ ולנהל באופן לוגי את המשאבים של פרסום מודל AI. אובייקט InferencePool יחיד יכול לכלול כמה פודים בכמה צמתי GKE שונים, ומספק יכולת הרחבה וזמינות גבוהה. אפשר לציין עד שמונה targetPorts במשאב InferencePool כדי לתמוך בשרתי מודלים שנדרשים להם כמה יציאות.
• אובייקט InferenceObjective: מציין את שם המודל להצגת מודעות מ-InferencePool בהתאם למפרט של OpenAI API. האובייקט InferenceObjective גם מציין את מאפייני הצגת המודעות של המודל, כמו Priority של מודל ה-AI. ‫GKE Inference Gateway נותן עדיפות לעומסי עבודה עם ערך עדיפות גבוה יותר. כך אפשר לבצע ריבוב של עומסי עבודה של AI שרגישים לזמן אחזור ועומסי עבודה של AI שלא רגישים לזמן אחזור באשכול GKE. אפשר גם להגדיר את האובייקט InferenceObjective כדי להפעיל מודלים שעברו כוונון עדין של LoRA.

הדיאגרמה הבאה ממחישה את GKE Inference Gateway ואת השילוב שלו עם אבטחת AI, ניראות (observability) ופרסום המודל באשכול GKE.

בתרשים הבא מוצג מודל המשאבים שמתמקד בשתי פרסונות חדשות שמתמקדות בהסקה ובמשאבים שהן מנהלות.

נתב llm-d

הנתב llm-d הוא רכיב ניתוב הבקשות החכם שמשמש את Inference Gateway כדי לקבל החלטות לגבי נקודות קצה לכל בקשה. הוא מורכב משני רכיבי משנה:

מצב שער

‫GKE Inference Gateway הוא llm-d Router שפועל במצב Gateway. במצב Gateway, שרת ה-Proxy הוא שער Kubernetes רשמי שמוקצה ומנוהל בנפרד משירות ה-EPP. השער קורא ל-EPP דרך ext-proc כדי לקבל החלטות לגבי ניתוב, ואז מעביר את הבקשה ישירות אל ה-Pod של שרת המודל שנבחר.

ההפרדה הזו בין השער (מישור הנתונים) לבין ה-EPP (מודיעין הניתוב) מאפשרת:

• תשתית משותפת: שער GKE יחיד משרת כמה InferencePools לצד שירותי Kubernetes רגילים.
• ניהול מתקדם של תעבורת נתונים: כללי המדיניות של HTTPRoute תומכים בפיצול משוקלל, בהשקות הדרגתיות ובשיקוף בקשות.
• שינוי קנה מידה עצמאי: שירות ה-EPP משנה את קנה המידה שלו באופן עצמאי מהשער.
• שילוב מבוסס-ענן: פועל עם בקר ה-Gateway המנוהל של GKE, עם Cloud Load Balancing ועם כלי התצפית הקיימים.

איך פועל GKE Inference Gateway

‫GKE Inference Gateway משתמש בתוספים של Gateway API ובלוגיקת ניתוב ספציפית למודל כדי לטפל בבקשות של לקוחות למודל AI. השלבים הבאים מתארים את תהליך הבקשה.

איך פועל תהליך הבקשה

‫GKE Inference Gateway מנתב את בקשות הלקוח מהבקשה הראשונית למכונה של המודל. בקטע הזה מוסבר איך GKE Inference Gateway מטפל בבקשות. תהליך הבקשה הזה משותף לכל הלקוחות.

1. הלקוח שולח בקשה בפורמט שמתואר במפרט של OpenAI API למודל שפועל ב-GKE.

2. ‫GKE Inference Gateway מעבד את הבקשה באמצעות תוספי ההסקה הבאים:

   1. תוסף ניתוב מבוסס-גוף: מחלץ את מזהה המודל מגוף הבקשה של הלקוח ושולח אותו אל GKE Inference Gateway. לאחר מכן, GKE Inference Gateway משתמש במזהה הזה כדי לנתב את הבקשה על סמך כללים שמוגדרים באובייקט HTTPRoute Gateway API. ניתוב לפי גוף הבקשה דומה לניתוב לפי נתיב כתובת ה-URL. ההבדל הוא שבניתוב של גוף הבקשה נעשה שימוש בנתונים מגוף הבקשה.
   2. תוסף אבטחה: משתמש ב-Model Armor, ב-NVIDIA NeMo Guardrails או בפתרונות נתמכים של צד שלישי כדי לאכוף מדיניות אבטחה ספציפית למודל, כולל סינון תוכן, זיהוי איומים, הסרת תוכן זדוני או רגיש ורישום ביומן. תוסף האבטחה מחיל את המדיניות הזו על נתיבי העיבוד של הבקשות והתשובות.
   3. ‫llm-d Endpoint Picker (EPP): עוקב אחרי מדדים מרכזיים משרתי המודלים ב-InferencePool ומנתב את הבקשה לרפליקה האופטימלית של המודל. מידע נוסף זמין במאמר נתב llm-d.

3. ‫GKE Inference Gateway מנתב את הבקשה לרפליקה של המודל שהוחזרה על ידי התוסף לבחירת נקודת קצה.

הדיאגרמה הבאה ממחישה את זרימת הבקשה מלקוח למכונה של מודל דרך GKE Inference Gateway.

איך חלוקת התנועה פועלת

‫GKE Inference Gateway מחלק באופן דינמי בקשות הסקה לשרתי מודלים באובייקט InferencePool. כך אפשר לשפר את ניצול המשאבים ולשמור על רמת הביצועים בתנאי עומס משתנים. ‫GKE Inference Gateway משתמש בשני המנגנונים הבאים כדי לנהל את חלוקת התנועה:

• בחירת נקודת קצה: בחירה דינמית של שרת המודל המתאים ביותר לטיפול בבקשת הסקה. הוא עוקב אחרי עומס השרתים והזמינות שלהם, ואז מחשב score לכל שרת כדי לקבל החלטות אופטימליות לגבי ניתוב. החישוב מבוסס על שילוב של מספר היוריסטיקות לאופטימיזציה:

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

• הוספה לתור והסרה: ניהול של זרימת הבקשות ומניעת עומס תנועה. GKE Inference Gateway מאחסן בקשות נכנסות בתור ומדרג את הבקשות לפי העדיפות שהוגדרה.

GKE Inference Gateway משתמש במערכת מספרית Priority, שנקראת גם Criticality, כדי לנהל את זרימת הבקשות ולמנוע עומס יתר. השדה Priority הוא שדה אופציונלי של מספר שלם שמוגדר על ידי המשתמש לכל InferenceObjective. ערך גבוה יותר מציין בקשה חשובה יותר. כשהמערכת נמצאת בעומס, בקשות עם Priority נמוך מ-0 נחשבות בעדיפות נמוכה יותר והן נפסלות ראשונות, ומוחזרת שגיאה 429 כדי להגן על עומסי עבודה קריטיים יותר. ערך ברירת המחדל של Priority הוא 0. בקשות נפסלות בגלל עדיפות רק אם הערך של Priority מוגדר במפורש כערך נמוך מ-0. המערכת הזו מאפשרת לתת עדיפות לתנועת נתונים של הסקת מסקנות אונליין שרגישה לזמן אחזור, על פני משימות אצווה שפחות רגישות לזמן.

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

דוגמאות לאפליקציות

בקטע הזה מפורטות דוגמאות לשימוש ב-GKE Inference Gateway בתרחישים שונים של אפליקציות AI גנרטיבי.

דוגמה 1: הצגת כמה מודלים של AI גנרטיבי באשכול GKE

חברה רוצה לפרוס כמה מודלים גדולים של שפה (LLM) כדי לטפל בעומסי עבודה שונים. לדוגמה, יכול להיות שהם ירצו לפרוס מודל Gemma3 לממשק של צ'אט בוט ומודל DeepSeek לאפליקציה של המלצות. החברה צריכה להבטיח ביצועי הצגה אופטימליים למודלי ה-LLM האלה.

באמצעות GKE Inference Gateway, אתם יכולים לפרוס את ה-LLM האלה באשכול GKE עם הגדרת המאיץ שבחרתם ב-InferencePool. אחר כך תוכלו לנתב בקשות על סמך שם המודל (למשל chatbot ו-recommender) והמאפיין Priority.

בתרשים הבא מוצג אופן הניתוב של בקשות על ידי GKE Inference Gateway למודלים שונים על סמך שם המודל ו-Priority.

בתרשים הזה מוצג אופן הטיפול בבקשה לשירות AI גנרטיבי ב-example.com/completions על ידי GKE Inference Gateway. הבקשה מגיעה קודם ל-Gateway במרחב השמות Infra. ה-Gateway הזה מעביר את הבקשה ל-HTTPRoute במרחב השמות GenAI Inference, שמוגדר לטפל בבקשות למודלים של צ'אט בוט וניתוח סנטימנט. במודל של הצ'אטבוט, HTTPRoute מפצל את התנועה: 90% מופנים ל-InferencePool שמריץ את גרסת המודל הנוכחית (שנבחרה על ידי {pool: gemma}), ו-10% מופנים למאגר עם גרסה חדשה יותר ({pool: gemma-new}), בדרך כלל לבדיקת קנרית. שני המאגרים מקושרים ל-InferenceObjective שמקצה Priority של 10 לבקשות למודל של הצ'אט בוט, כדי לוודא שהבקשות האלה יטופלו בעדיפות גבוהה.

דוגמה 2: הצגת מתאמי LoRA במאיץ משותף

חברה רוצה להציג מודלים גדולים של שפה (LLM) לניתוח מסמכים, ומתמקדת בקהלים בכמה שפות, כמו אנגלית וספרדית. יש להם מודלים שעברו כוונון עדין לכל שפה, אבל הם צריכים להשתמש ביכולות ה-GPU וה-TPU שלהם בצורה יעילה. אתם יכולים להשתמש ב-GKE Inference Gateway כדי לפרוס מתאמים דינמיים שעברו כוונון באמצעות LoRA לכל שפה (לדוגמה, english-bot ו-spanish-bot) במודל בסיס משותף (לדוגמה, llm-base) ובמאיץ. כך אפשר לצמצם את מספר המאיצים הנדרשים על ידי אריזה צפופה של כמה מודלים במאיץ משותף.

בתרשים הבא אפשר לראות איך GKE Inference Gateway מפעיל כמה מתאמי LoRA במאיץ משותף.

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

• פריסה של GKE Inference Gateway
• התאמה אישית של ההגדרות של GKE Inference Gateway
• הצגת מודל LLM באמצעות GKE Inference Gateway
• שימוש בניתוב מבוסס-זמן אחזור חזוי באמצעות GKE Inference Gateway(תצוגה מקדימה)