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

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

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

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

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

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

סקירה כללית

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

כדי לבחור את אסטרטגיית איזון העומסים האופטימלית לעומסי העבודה של 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, כדי לצרוך מאיצים (כמו מעבדי GPU ו-TPU) בצורה יעילה יותר עבור עומסי עבודה של AI גנרטיבי. ההגדרה הזו מפעילה את ניתוב מודע למטמון של קידומות, תכונה מרכזית ששולחת בקשות עם הקשר משותף, שזוהה על ידי ניתוח גוף הבקשה, לאותו עותק של המודל על ידי הגדלת מספר הפעמים שבהן נתונים נמצאים במטמון. הגישה הזו מקטינה באופן משמעותי את החישובים המיותרים ומשפרת את הזמן עד לטוקן הראשון, ולכן היא יעילה מאוד ל-AI שיכול לנהל שיחה, ל-Retrieval-Augmented Generation ‏ (RAG) ולעומסי עבודה אחרים של AI גנרטיבי שמבוססים על תבניות.
• הצגת מודלים דינמיים שעברו כוונון עדין של LoRA: תמיכה בהצגת מודלים דינמיים שעברו כוונון עדין של LoRA במאיץ משותף. השיטה הזו מצמצמת את מספר המעבדים הגרפיים (GPU) ומעבדי ה-Tensor (TPU) שנדרשים להפעלת מודלים, על ידי ריבוב של כמה מודלים שעברו כוונון עדין של LoRA על מודל בסיס משותף ומאיץ.
• התאמה אוטומטית לעומס (autoscaling) שעברה אופטימיזציה להסקת מסקנות: התאמה אוטומטית אופקית של Pod ב-GKE‏ (HPA) מתבססת על מדדים של שרת המודל כדי להתאים את העומס באופן אוטומטי. כך היא עוזרת להבטיח שימוש יעיל במשאבי מחשוב וביצועים אופטימליים של הסקת מסקנות.
• ניתוב מודע-מודל: בקשות להסקת מסקנות מנותבות על סמך שמות המודלים שמוגדרים במפרטים של OpenAI APIבאשכול GKE. אתם יכולים להגדיר מדיניות ניתוב של שערים, כמו פיצול תנועה ושיקוף בקשות, כדי לנהל גרסאות שונות של מודלים ולפשט את השקת המודלים. לדוגמה, אתם יכולים להפנות בקשות לשם מודל ספציפי לאובייקטים שונים של InferencePool, שכל אחד מהם משרת גרסה שונה של המודל. מידע נוסף על הגדרת האפשרות הזו זמין במאמר הגדרת ניתוב לפי גוף ההודעה.
• סינון תוכן ואמצעי בטיחות משולבים של AI: GKE Inference Gateway משולב עם Cloud de Confiance Model Armor כדי להחיל בדיקות בטיחות של AI וסינון תוכן על הנחיות ותשובות בשער. אפשר גם להשתמש ב-NVIDIA NeMo Guardrails. ‫Model Armor מספק יומנים של בקשות, תגובות ועיבוד לניתוח רטרוספקטיבי ולאופטימיזציה. הממשקים הפתוחים של GKE Inference Gateway מאפשרים לספקי צד שלישי ולמפתחים לשלב שירותים בהתאמה אישית בתהליך של בקשת ההסקה.
• פרסום מודלים ספציפיים Priority: מאפשר לציין את הפרסום Priority של מודלים של AI. תעדוף בקשות שרגישות לזמן אחזור על פני משימות באצווה של הסקת מסקנות שסובלות זמן אחזור. לדוגמה, אתם יכולים לתת עדיפות לבקשות מאפליקציות שרגישות לזמן האחזור, ולבטל משימות שפחות רגישות לזמן האחזור כשיש מגבלות על המשאבים.
• ניתוב מבוסס-חביון צפוי: ניתוב בקשות להסקת מסקנות באמצעות מודל XGBoost שאומן באופן רציף על תעבורה פעילה, עם אופטימיזציה של זמן עד לאסימון הראשון (TTFT) וזמן לכל אסימון פלט (TPOT) לכל בקשה. יותר מדויק מהיוריסטיקה הסטטית בעומסי עבודה עם שונות גבוהה. מידע נוסף זמין במאמר בנושא שימוש בניתוב מבוסס-חביון חזוי עם GKE Inference Gateway.
• יכולת מעקב אחר הסקת מסקנות: מספקת מדדי מעקב אחר בקשות להסקת מסקנות, כמו קצב בקשות, זמן אחזור, שגיאות ורוויה. מעקב אחרי הביצועים וההתנהגות של שירותי ההסקה באמצעות Cloud Monitoring ו-Cloud Logging, תוך שימוש בלוחות בקרה מיוחדים שנוצרו מראש כדי לקבל תובנות מפורטות. מידע נוסף זמין במאמר בנושא הצגת לוח הבקרה של GKE Inference Gateway.
• ניהול מתקדם של API באמצעות Apigee: שילוב עם Apigee כדי לשפר את שער ההסקה באמצעות תכונות כמו אבטחת API, הגבלת קצב ומכסות. הוראות מפורטות זמינות במאמר הגדרת Apigee לאימות ולניהול API.
• יכולת הרחבה: המערכת מבוססת על תוסף של Gateway API Inference ב-Kubernetes עם קוד פתוח, שאפשר להרחיב אותו. התוסף תומך באלגוריתם llm-d Endpoint Picker (EPP) שמנוהל על ידי המשתמש, ומבוסס על llm-d. אלגוריתם הכלי לבחירת נקודות קצה (EPP) llm-d, שמבוסס על llm-d, מספק את יכולות הניתוב העיקריות של התוסף הזה.
• תמיכה בכמה יציאות: תמיכה בשרתי מודלים שחושפים כמה יציאות, וזה חיוני לתרחישי הגשה מתקדמים כמו תשומת לב מקבילה לנתונים.
• מגבלות על קבוצות של נקודות קצה ברשת (NEG): יש מגבלה של 50 קבוצות של נקודות קצה ברשת לכלCloud de Confiance by S3NS שירות קצה עורפי. כשמשתמשים ב-InferencePool עם כמה יציאות, כל יציאה בכל אזור יוצרת NEG ייעודי. לדוגמה, ב-InferencePool עם שמונה יציאות באשכול אזורי טיפוסי (שלושה אזורים) נוצרים 24 קבוצות NEG. לכן, שער רשת רב-אשכולי יכול לצבור רק מאגר מסקנות כזה מ-2 אשכולות לכל היותר (2 אשכולות × 24 קבוצות NEG = 48 קבוצות NEG) לפני שמגיעים למגבלה של 50 קבוצות NEG.

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

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

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

בתרשים הבא מוצג GKE Inference Gateway והשילוב שלו עם AI Safety, יכולת צפייה והצגת מודלים באשכול GKE.

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

llm-d Router

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

מצב שער

‫GKE Inference Gateway הוא llm-d Router שפועל במצב Gateway. במצב Gateway, ה-Proxy הוא שער Kubernetes רשמי שמוקצה ומנוהל בנפרד משירות ה-EPP. ה-Gateway קורא ל-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 Router.

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

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

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

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

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

  • ניתוב עם מודעות למטמון של קידומות: שער ההסקה של GKE עוקב אחרי אינדקסים זמינים של מטמון קידומות בכל שרת מודל, ונותן ניקוד גבוה יותר לשרת עם התאמה ארוכה יותר של מטמון קידומות.
  • ניתוב מודע לעומס: GKE Inference Gateway עוקב אחרי עומס השרת (ניצול מטמון KV ועומק התור בהמתנה), ונותן ניקוד גבוה יותר לשרת עם עומס נמוך יותר.
  • ‫LoRA aware routing: כשמופעלת הקצאת 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(תצוגה מקדימה)