שימוש בניתוב מבוסס-חביון חזוי באמצעות GKE Inference Gateway

במסמך הזה מוסבר איך להפעיל את הניתוב מבוסס-החביון החזוי שמוצע על ידי llm-d ב-GKE Inference Gateway ואיך להשתמש בו. כברירת מחדל, GKE Inference Gateway מעביר בקשות באמצעות שילוב של אותות עומס והיוריסטיקות של זיקה למטמון של קידומות. ניתוב מבוסס-חביון חזוי מחליף את המשקלים ההיוריסטיים הסטטיים במודל XGBoost שאומן באופן רציף על תנועה פעילה, וכך מאפשר לקבל החלטות ניתוב מדויקות יותר ככל שדפוסי העומס משתנים.

מתי כדאי להשתמש בניתוב מבוסס-חביון חזוי

התכונה הזו הכי יעילה כשעומדים בתנאים הבאים לגבי עומס העבודה שלכם:

• שונות גבוהה באורך ההנחיה וההשלמה: עומק התור לבדו הוא מדד לא טוב לעומס השרת, כשגדלי הבקשות משתנים באופן משמעותי. הכלי לחיזוי זמן האחזור מתחשב בעלות בפועל של מילוי מראש ופענוח לכל בקשה.
• הסכמי רמת שירות (SLO) של זמן אחזור לכל בקשה: כשמציינים באפליקציות יעדים של זמן עד לטוקן הראשון (TTFT) או זמן לכל טוקן פלט (TPOT) בבקשות ספציפיות, המתזמן אוכף את היעדים האלה במהלך הניתוב. הוא עושה זאת על ידי חישוב המרווח (החביון החזוי פחות יעד ה-SLO) לכל Pod מועמד.
• כוונון סטטי רגיש של משקלים: אם אתם מכווננים מחדש לעיתים קרובות את האיזון בין זיקה למטמון לבין אותות עומס כשתבניות התנועה משתנות, המודל שאומן אונליין יסתגל אוטומטית.

איך פועל ניתוב מבוסס-חביון חזוי

בקטע הזה מפורטים הארכיטקטורה וצינור התזמון שמשמשים להפניה על סמך זמן אחזור צפוי.

ארכיטקטורה

תזמון מבוסס-חביון (latency) חזוי פורס שני קונטיינרים נוספים מסוג sidecar בתוך ה-Pod של EPP, לצד ה-EPP עצמו:

llm-d EPP scheduling pipeline

כשהתזמון מבוסס-חביון מופעל, ה-EPP מעבד כל בקשה באמצעות הרצף הבא של תוספים שניתנים להרכבה:

1. ‫predicted-latency-producer: קוראת לשרת החיזוי כדי לקבל הערכות של TTFT ו-TPOT לכל Pod מועמד ב-InferencePool, בהתאם לניצול הנוכחי של מטמון KV בכל Pod, עומק התור, ציון ההתאמה של מטמון הקידומת והתכונות של הבקשה הנכנסת. אחרי שהתגובה מוחזרת ללקוח, המפיק שולח את ה-TTFT שנצפה ואת זמן האחזור בין הטוקנים בחזרה לשרת האימון כדוגמה חדשה לאימון.

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

2. ‫prefix-cache-affinity-filter: המסנן הזה מצמצם את קבוצת המועמדים ל-Pods שחוממו מראש במטמון, אם ציון ההתאמה של מטמון הקידומת של Pod כלשהו חורג מסף הזיקה (ברירת מחדל של 0.80). הסף הזה מפריד בין שתי אוכלוסיות שנצפו בסביבת הייצור: בין תרמילים שכבר יש להם היסטוריית שיחות במטמון מסיבובים קודמים, לבין תרמילים שאין להם היסטוריית שיחות במטמון. המסנן הזה מיישם אסטרטגיית ניצול וחיפוש של אפסילון-חמדנות:

   • ‫Exploit (נתיב ברירת המחדל): הנתיב הזה מוביל אל Pods של חימום מטמון, כך שהניקוד מתמקד בשימוש חוזר במטמון.

   • Explore (small probability): הנתיב הזה עוקף את המסנן לחלוטין בחלק קטן של הבקשות שניתן להגדרה, כדי לאכלס רשומות במטמון ב-Pods קרים ולמנוע פיצול של המטמון.

   • TTFT load gate: גם בנתיב הניצול, אם זמן הטעינה עד הפעם הראשונה שהתוכן מוצג (TTFT) של ה-Pod הטוב ביותר עם מטמון חם חורג מזמן הטעינה עד הפעם הראשונה שהתוכן מוצג (TTFT) של ה-Pod הטוב ביותר הכולל ביותר מסף שניתן להגדרה (ברירת מחדל של 5,000 אלפיות השנייה), הקשר נשבר ונעשה שימוש בכל קבוצת המועמדים.

3. ‫slo-headroom-tier-filter (בקשות SLO בלבד): כשהבקשה כוללת כותרות SLO, מפוצלות יחידות ה-Pod המועמדות לשכבה חיובית (שצפוי שיעמדו ביעד למדידת רמת השירות) ולשכבה שלילית (שצפוי שיפרו את היעד למדידת רמת השירות).

4. ‫latency-scorer: נותן ניקוד ל-Pods מועמדים. בלי כותרות SLO, נבחר ה-Pod עם זמן האחזור הנמוך ביותר שחזוי. כשמשתמשים בכותרות SLO, הציון מבוסס על מרווח הביטחון (SLO פחות זמן האחזור הצפוי) באמצעות headroomSelectionStrategy:

   • ‫least (ברירת מחדל): Bin-pack. המסלולים אל ה-Pod עם המרווח החיובי הקטן ביותר, כדי למקסם את הניצול ולשמור על Pods עם עומס נמוך יותר פנויים לפרצי תנועה עתידיים.
   • ‫most: המרחק. מסלולים אל ה-Pod עם המרווח החיובי הגדול ביותר, כך שיש יותר מרווח לשיאים לא צפויים בעומס.

5. ‫latency-slo-admitter (בקשות SLO בלבד): דחיית בקשות שניתנות להסרה (העדיפות נמוכה מ-0) כשלא צפוי שום Pod מועמד לעמוד ביעד ה-SLO, במקום לצרוך קיבולת בבקשה שלא צפוי שתעמוד ביעד שלה. למסנן הזה אין השפעה כשאין כותרות SLO או כשקיים Pod שעומד בדרישות ה-SLO.

6. ‫weighted-random-picker: בוחר את הפוד הסופי באמצעות בחירה אקראית משוקללת על סמך הניקוד. כך אפשר לפזר את העומס ועדיין להעדיף Pods עם ניקוד טוב יותר.

מצב סטרימינג

הפלאגין predicted-latency-producer תומך בשני מצבי אימון, שמוגדרים באמצעות הפרמטר streamingMode:

• ‫streamingMode: false (ברירת מחדל): מתאמן על זמן אחזור של בקשות מקצה לקצה (E2E). כדאי להשתמש במצב הזה אם בעומס העבודה יש שילוב של תגובות בסטרימינג ותגובות שלא בסטרימינג, או אם אתם צריכים ניתוב עם מודעות לזמן האחזור בלי אכיפה של SLO לכל בקשה.
• ‫streamingMode: true: מאמן מודלים נפרדים של TTFT ו-TPOT. הערך של TTFT נרשם בחלק הראשון של הנתונים שמוזרמים, והערך של TPOT נדגם בטוקנים הבאים. כדאי להשתמש במצב הזה אם עומס העבודה שלכם מבוסס על סטרימינג מלא ואתם צריכים אכיפה משמעותית של x-slo-ttft-ms / x-slo-tpot-ms.

לפני שמתחילים

לפני שמתחילים, חשוב לוודא שביצעתם את הפעולות הבאות:

• מפעילים את ממשק Google Kubernetes Engine API.
הפעלת Google Kubernetes Engine API
• אם רוצים להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז להפעיל את ה-CLI של gcloud. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא יתמכו בהרצת הפקודות שמופיעות במסמך הזה.

• אם צריך, מפעילים את Compute Engine API, את Network Services API ואת Model Armor API.

  עוברים אל הפעלת גישה לממשקי API ופועלים לפי ההוראות.

• מוודאים שיש פריסה תקינה של GKE Inference Gateway. פריסת GKE Inference Gateway

• חשוב לוודא ש-InferencePool משתמש במערכת הומוגנית של Pods – סוג GPU זהה, משקלי מודל ותצורת הגשה.

• מוודאים שאשכול GKE הוא בגרסה 1.32.3 ואילך.

• מתקינים את Helm. אפשר לעיין במדריך ההתקנה של Helm.

הפעלת תזמון מבוסס-חביון חזוי

השלבים הבאים מתארים איך להפעיל תזמון מבוסס-חביון חזוי בפריסת GKE Inference Gateway.

שלב 1: התקנה או שדרוג של InferencePool עם הפעלת חיזוי של זמן האחזור

הדגל latencyPredictor.enabled=true פורס את ה-sidecar של שרת האימון ושל שרת החיזוי בתוך ה-Pod של EPP ומחבר את צינור הנתונים המלא של תוסף התזמון:

helm upgrade --install INFERENCE_POOL_NAME \
  --set inferencePool.modelServers.matchLabels.app=MODEL_SERVER_LABEL \
  --set provider.name=gke \
  --set inferenceExtension.monitoring.gke.enabled=true \
  --set inferenceExtension.latencyPredictor.enabled=true \
  --version LLM_D_VERSION \
  oci://LLM_D_REGISTRY_PATH

מחליפים את מה שכתוב בשדות הבאים:

• ‫INFERENCE_POOL_NAME: השם של InferencePool, לדוגמה vllm-llama3-8b-instruct.
• ‫MODEL_SERVER_LABEL: מפתח התווית שמשמש לבחירת ה-Pods של שרת המודל.
• ‫LLM_D_VERSION: גרסת תרשים ה-Helm של llm-d שבה רוצים להשתמש.
• ‫LLM_D_REGISTRY_PATH: הנתיב למאגר OCI של llm-d.

שלב 2: בדיקת הפריסה

מוודאים ש-EPP Pod פועל וכל קונטיינרי ה-sidecar מוכנים:

kubectl get pods -l app=INFERENCE_POOL_NAME-epp

בתרמיל EPP אמורים להופיע כל הקונטיינרים במצב Running או Ready: ה-EPP עצמו, שרת האימון ושרת חיזוי אחד או יותר.

שלב 3: שליחת בקשה ראשונית

שולחים בקשת הסקה רגילה כדי לוודא שהניתוב פועל לפני שמפעילים את כותרות ה-SLO:

curl -i -X POST GATEWAY_IP:PORT/v1/completions \
 -H 'Content-Type: application/json' \
 -H 'Authorization: Bearer $(gcloud auth print-access-token)' \
 -H 'x-prediction-based-scheduling: true' \
 -d '{
    "model": "MODEL_NAME",
    "prompt": "PROMPT_TEXT",
    "max_tokens": MAX_TOKENS,
    "temperature": "0"
 }'

מחליפים את מה שכתוב בשדות הבאים:

• ‫GATEWAY_IP: כתובת ה-IP של שירות השער.
• ‫PORT: מספר היציאה של שירות השער.
• ‫MODEL_NAME: השם של המודל שבו רוצים להשתמש להסקת מסקנות.
• ‫PROMPT_TEXT: הנחיית הקלט.
• ‫MAX_TOKENS: המספר המקסימלי של האסימונים שייווצרו.

הכותרת x-prediction-based-scheduling: true מאפשרת להוסיף את הבקשה הזו לצינור התזמון של זמן האחזור הצפוי. במהלך תקופת ההרצה של כלי החיזוי, ה-EPP חוזר לניתוב היוריסטי.

שלב 4: שליחת בקשות עם מודעות להסכם רמת שירות (אופציונלי)

כדי להפעיל אכיפה של SLO לכל בקשה, מוסיפים כותרות של יעדי חביון TTFT ו-TPOT:

curl -i -X POST GATEWAY_IP:PORT/v1/completions \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer $(gcloud auth print-access-token)' \
  -H 'x-prediction-based-scheduling: true' \
  -H 'x-slo-ttft-ms: 500' \
  -H 'x-slo-tpot-ms: 50' \
  -d '{
    "model": "MODEL_NAME",
    "prompt": "PROMPT_TEXT",
    "max_tokens": MAX_TOKENS,
    "temperature": "0",
    "stream": true
  }'

מחליפים את מה שכתוב בשדות הבאים:

• ‫GATEWAY_IP: כתובת ה-IP של שירות השער.
• ‫PORT: מספר היציאה של שירות השער.
• ‫MODEL_NAME: השם של המודל שבו רוצים להשתמש להסקת מסקנות.
• ‫PROMPT_TEXT: הנחיית הקלט.
• ‫MAX_TOKENS: המספר המקסימלי של האסימונים שייווצרו.

כותרות הבקשה:

• ‫x-prediction-based-scheduling: true: צינור התזמון של זמן האחזור החזוי.
• ‫x-slo-ttft-ms: משך הזמן המקסימלי שנסבל עד לקבלת האסימון הראשון, באלפיות השנייה.
• ‫x-slo-tpot-ms: הזמן המקסימלי המקובל לכל אסימון פלט באלפיות השנייה.

מעקב אחרי תזמון של זמן האחזור הצפוי

כשהתכונה 'חיזוי זמן האחזור' מופעלת, ה-EPP חושף מדדים נוספים דרך Cloud Monitoring.

שינוי קנה המידה של שרת החיזוי

ה-EPP מבצע קריאת חיזוי אחת לכל Pod מועמד לכל בקשה נכנסת. כל מופע של שרת חיזוי יכול לתמוך בערך ב-300 שאילתות לשנייה של עבודת חיזוי.

הנחיות משוערות לגבי מספר המופעים של Prediction Server:

כדי להוסיף מופעים של שרת חיזוי, צריך לעדכן את הערך latencyPredictor.predictionServerCount ב-Helm.

מגבלות

• נדרש InferencePool הומוגני: לא ניתן להשתמש בסוגים מעורבים של GPU, בווריאציות של מודלים או בהגדרות של שרתים במאגר אחד.
• תקופת הרצה ראשונית: כדי שהתחזיות יהיו מדויקות, מודל XGBoost צריך לקבל מספיק דוגמאות של תנועה בזמן אמת.
• אכיפת SLO: האכיפה מתבצעת רק בשכבת הניתוב. שרת המודל לא מפסיק בקשות שחורגות מיעד ה-SLO אחרי הבחירה.
• סטטוס: התכונה הזו נמצאת בגרסת טרום-השקה. לא מומלץ להשתמש בו לעומסי עבודה בסביבת ייצור עם דרישות מחמירות של הסכם רמת שירות (SLA) בלי לבצע בדיקות יסודיות.

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

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