הצגת מודל LLM באמצעות GKE Inference Gateway

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

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

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

• מידע על GKE Inference Gateway
• תזמור של AI/ML ב-GKE.
• מילון מונחים של AI גנרטיבי.
• איזון עומסים ב-Google Cloud, ובמיוחד איך מאזני עומסים פועלים עם GKE.
• GKE Service Extensions. מידע נוסף זמין במאמרי העזרה בנושא בקר GKE Gateway.
• התאמה אישית של תעבורת נתונים ב-GKE Gateway באמצעות Service Extensions

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

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

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

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

• מפעילים את Compute Engine API,‏ Kubernetes Engine API,‏ Network Services API ו-API של הגנה מוגברת על המודל אם צריך.

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

• צריך לוודא שיש לכם בפרויקט את התפקידים הבאים: roles/container.admin, roles/iam.serviceAccountAdmin.

• מוודאים שיש בפרויקט מכסה מספקת לשימוש במעבדי H100 GPU. מידע נוסף זמין במאמרים בנושא תכנון מכסת GPU ומכסות הקצאה.

• אם עדיין אין לכם חשבון, יוצרים חשבון ב-Hugging Face. תצטרכו את זה כדי לגשת למשאבי המודל במדריך הזה.

• מבקשים גישה למודל Llama 3.1 ויוצרים אסימון גישה. כדי לגשת למודל הזה צריך לשלוח בקשה מאושרת ב-Hugging Face. אם הגישה לא אושרה, הפריסה תיכשל.

  • חתימה על הסכם ההסכמה לרישיון: כדי להשתמש במודל Llama 3.1, צריך לחתום על הסכם ההסכמה. עוברים לדף של המודל ב-Hugging Face, מאמתים את החשבון ומאשרים את התנאים.
  • יצירת אסימון גישה: כדי לגשת למודל, צריך אסימון של Hugging Face. בחשבון Hugging Face, עוברים אל Your Profile > Settings > Access Tokens (הפרופיל שלך > הגדרות > טוקנים של גישה), יוצרים טוקן חדש עם הרשאות קריאה לפחות ומעתיקים אותו ללוח.

• הגדרת רשת משנה (subnet) ל-proxy בלבד עבור רשת ה-VPC. בקר Gateway דורש תת-רשת פעילה של שרת proxy בלבד באזור כדי להקצות את מאזן העומסים של האפליקציה.

דרישות של בקר GKE Gateway

• ‫GKE בגרסה 1.32.3 ואילך.
• ‫Google Cloud CLI בגרסה 407.0.0 ואילך.
• ‫Gateway API נתמך רק באשכולות מקוריים של VPC.
• התוסף HttpLoadBalancing צריך להיות מופעל באשכול.
• אם אתם משתמשים ב-Istio, אתם צריכים לשדרג את Istio לאחת מהגרסאות הבאות:
  • גרסה 1.15.2 ואילך
  • ‫1.14.5 ואילך
  • גרסה 1.13.9 ואילך
• אם משתמשים ב-VPC משותף, צריך להקצות את התפקיד Compute Network User לחשבון השירות של GKE בפרויקט המארח עבור פרויקט השירות.

הגבלות ומגבלות

ההגבלות והמגבלות הבאות חלות:

• ‫GKE Inference Gateway נתמך רק במשאבי gke-l7-regional-external-managed ו-gke-l7-rilb GatewayClass.
• אין תמיכה במאזני עומסים פנימיים של אפליקציות (ALB) בין אזורים.
• ב-InferencePool יכולים להיות עד שמונה targetPorts.

הגדרת GKE Inference Gateway

כדי להגדיר את GKE Inference Gateway, אפשר להיעזר בדוגמה הזו. צוות מריץ מודלים של vLLM ושל Llama3 ומבצע ניסויים פעילים עם שני מתאמ��ם שונים של LoRA שעברו כוונון עדין: food-review ו-cad-fabricator.

תהליך העבודה הכללי להגדרת GKE Inference Gateway הוא כדלקמן:

1. הכנת הסביבה: הגדרת התשתית והרכיבים הנדרשים.
2. יצירת מאגר הסקה: הגדרה של מאגר שרתי מודלים באמצעות המשאב המותאם אישית InferencePool.
3. מציינים יעדי הסקה: מציינים יעדי הסקה באמצעות InferenceObjective Custom Resource
4. יצירת שער: חשיפת שירות ההסקה באמצעות Gateway API.
5. יוצרים את HTTPRoute: מגדירים איך תעבורת HTTP מנותבת לשירות ההסקה.
6. שליחת בקשות הסקה: שליחת בקשות למודל שנפרס.

יצירת השער

משאב השער הוא נקודת הכניסה של תעבורה חיצונית לאשכול Kubernetes. הגדרה של מאזינים שמקבלים חיבורים נכנסים.

‫GKE Inference Gateway פועל עם Gateway Classes הבאים:

• ‫gke-l7-rilb: למאזני עומסים פנימיים אזוריים של אפליקציות (ALB).
• ‫gke-l7-regional-external-managed: למאזני עומסים חיצוניים אזוריים של אפליקציות (ALB).

מידע נוסף זמין במאמר בנושא Gateway Classes.

כדי ליצור שער:

1. שומרים את קובץ המניפסט לדוגמה הבא בשם gateway.yaml:

   apiVersion: gateway.networking.k8s.io/v1
   kind: Gateway
   metadata:
     name: GATEWAY_NAME
   spec:
     gatewayClassName: GATEWAY_CLASS
     listeners:
       - protocol: HTTP
         port: 80
         name: http
   

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

   • ‫GATEWAY_NAME: שם ייחודי למשאב Gateway. לדוגמה, inference-gateway.
   • ‫GATEWAY_CLASS: Gateway Class שרוצים להשתמש בו. לדוגמה, gke-l7-regional-external-managed.

2. מחילים את המניפסט על האשכול:

   kubectl apply -f gateway.yaml
   

הערה: מידע נוסף על הגדרת TLS כדי לאבטח את השער באמצעות HTTPS זמין במסמכי התיעוד של GKE בנושא הגדרת TLS.

הכנת הסביבה

1. מתקינים את Helm.

2. יוצרים אשכול GKE:

   • יוצרים אשכול GKE Autopilot או Standard בגרסה 1.32.3 ואילך. cluster-toolkit gke-a3-highgpuדוגמה להגדרה של פריסה בלחיצה אחת
   • מגדירים את הצמתים עם משפחת המחשוב והמאיץ המועדפים.
   • אפשר להשתמש בהפעלה מהירה של הסקת מסקנות ב-GKE כדי לקבל מניפסטים של פריסה שהוגדרו מראש ונבדקו, על סמך המאיץ, המודל ודרישות הביצועים שבחרתם.

3. מתקינים את ההגדרות הדרושות של משאבים מותאמים אישית (CRD) באשכול GKE:

   • בגרסאות GKE‏ 1.34.0-gke.1626000 ואילך, ה-CRD‏ InferencePool נכלל כברירת מחדל. לכן, מתקינים רק את ה-CRD של אלפא InferenceObjective:

     kubectl apply -f https://github.com/kubernetes-sigs/gateway-api-inference-extension/raw/v1.5.0/config/crd/bases/inference.networking.x-k8s.io_inferenceobjectives.yaml
     

   • בגרסאות GKE קודמות ל-1.34.0-gke.1626000, צריך להתקין גם את v1 InferencePool וגם את CRD אלפא InferenceObjective:

     kubectl apply -f  https://github.com/kubernetes-sigs/gateway-api-inference-extension/releases/download/v1.5.0/manifests.yaml
     

     מידע נוסף זמין בטבלת התאימות.

4. אם אתם משתמשים בגרסה מוקדמת יותר מ-v1.32.2-gke.1182001 של GKE ואתם רוצים להשתמש בהגנה מוגברת על המודל עם GKE Inference Gateway, אתם צריכים להתקין את ה-CRD של תוסף תעבורת הנתונים והניתוב:

   kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-gateway-api/refs/heads/main/config/crd/networking.gke.io_gcptrafficextensions.yaml
   kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-gateway-api/refs/heads/main/config/crd/networking.gke.io_gcproutingextensions.yaml
   

5. מגדירים את משתני הסביבה הבאים:

   export GAIE_VERSION=v1.5.0
   export GUIDE_NAME="optimized-baseline"
   export NAMESPACE=llm-d-optimized-baseline
   export INFRA_PROVIDER=gke   # gke | base
   

6. מתקינים את ההגדרות של משאבים מותאמים אישית (CRD) של Gateway API Inference Extension שנדרשות על ידי הכלי לבחירת נקודות קצה (EPP) של llm-d:

   kubectl apply -k \
     "https://github.com/kubernetes-sigs/gateway-api-inference-extension/config/crd?ref=${GAIE_VERSION}"
   

7. יוצרים את מרחב השמות של היעד:

   kubectl create namespace ${NAMESPACE}
   

יצירת שרת מודלים ופריסת מודלים

בקטע הזה מוסבר איך פורסים שרת מודלים ומודל. בדוגמה הזו נעשה שימוש בשרת מודלים vLLM עם מודל Llama3. הפריסה מסומנת בתווית app:vllm-llama3-8b-instruct. בפריסה הזו נעשה שימוש גם בשני מתאמי LoRA בשם food-review ו-cad-fabricator מ-Hugging Face.

אפשר להתאים את הדוגמה הזו לקונטיינר של שרת המודל ולמודל שלכם, ליציאת ההגשה ולשם הפריסה. אפשר גם להגדיר מתאמי LoRA בפריסה, או לפרוס את מודל הבסיס. בשלבים הבאים מוסבר איך ליצור את משאבי Kubernetes הנדרשים.

1. יוצרים סוד של Kubernetes כדי לאחסן את האסימון של Hugging Face. האסימון הזה משמש לגישה למודל הבסיסי ולמתאמי LoRA:

   kubectl create secret generic hf-token --from-literal=token=HF_TOKEN
   

   מחליפים את HF_TOKEN באסימון של Hugging Face.

2. פורסים את שרת המודלים של vLLM באמצעות שכבת העל הספציפית ל-GKE של Kustomize מהמדריך llm-d optimized-baseline. ההגדרה INFRA_PROVIDER=gke חלה על הגדרות ספציפיות ל-GKE, כולל שילוב עם Cloud Monitoring:

   kubectl apply -n ${NAMESPACE} \
     -k guides/${GUIDE_NAME}/modelserver/gpu/vllm/${INFRA_PROVIDER}/
   

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

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

דוגמה לפריסה של כמה יציאות

apiVersion: apps/v1
kind: Deployment
metadata:
  name: multiport-model-server
spec:
  replicas: 3
  selector:
    matchLabels:
      app: multiport-model-server
  template:
    metadata:
      labels:
        app: multiport-model-server
    spec:
      containers:
      - name: model-server
        image: your-model-server-image
        ports:
        - containerPort: 8080
        - containerPort: 8081
        - containerPort: 9000

יצירת מאגר הסקה

המשאב המותאם אישית InferencePool Kubernetes מגדיר קבוצה של Pod עם מודל שפה גדול (LLM) בסיסי משותף והגדרת מחשוב. השדה selector מציין אילו פודים שייכים למאגר הזה. התוויות בכלי הבחירה הזה צריכות להיות זהות לתוויות שמוחלות על ה-Pods של שרת המודל. השדה targetPorts מגדיר את היציאות ששרת המודל משתמש בהן בתוך קבוצות ה-Pod. אפשר לציין עד שמונה יציאות. השדה extensionRef מפנה ��שירות הרחבה שמספק יכולת נוספת למאגר ההסקה. ‫InferencePool מאפשר ל-GKE Inference Gateway להפנות תנועה ל-Pods של שרת המודל.

במניפסט הבא של InferencePool מפורטים כמה targetPorts שתואמים ליציאות שנחשפות על ידי הפריסה של שרת המודל:

דוגמה ל-Multiport InferencePool

apiVersion: inference.networking.k8s.io/v1
kind: InferencePool
metadata:
  name: my-multiport-pool
  namespace: default
spec:
  selector:
    matchLabels:
      app: multiport-model-server
  targetPorts:
    - number: 8080
    - number: 8081
    - number: 9000

לפני שיוצרים את InferencePool, צריך לוודא שפודים של שרת המודל שנבחרו על ידי InferencePool כבר פועלים.

משכפלים את המתכונים וההמלצות עבור InferencePool ממאגר GitHub של llm-d. חובה לבצע את השלב הזה:

git clone https://github.com/llm-d/llm-d -b v0.7.0 && cd llm-d

כדי ליצור InferencePool ו-Endpoint Picker באמצעות Helm, מבצעים את השלבים הבאים:

helm install ${GUIDE_NAME} \
  -f guides/recipes/scheduler/base.values.yaml \
  -f guides/${GUIDE_NAME}/scheduler/${GUIDE_NAME}.values.yaml \
  --set provider.name=gke \
  --set inferenceExtension.monitoring.gke.enabled=true \
  -n ${NAMESPACE} \
  --version ${GAIE_VERSION} \
  oci://LLM_D_REGISTRY_PATH

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

• ‫GAIE_VERSION: הגרסה של תרשים Helm. לדוגמה, v1.5.0.
• ‫LLM_D_REGISTRY_PATH: הנתיב של מאגר OCI לתרשים Helm. לדוגמה, registry.k8s.io/gateway-api-inference-extension/charts/inferencepool.

בקובץ guides/recipes/scheduler/base.values.yaml, משנים את השדה הבא כך שיתאים לתווית של ה-Pod של פריסת המודל:

• ‫inferencePool.modelServers.matchLabels: המפתח והערך של התווית שמשמשת לבחירת ה-Pods של שרת המודל.

  הערה: המפתח והערך תואמים לדוגמה במדריך optimized-baseline, לכן אנחנו מחליפים אותם כך שיתאימו לתוויות של Deployment Pod.

לצורך מעקב, גישה למדדים בשירות המנוהל של Google Cloud ל-Prometheus מופעלת כברירת מחדל.

• כדי להשבית את התכונה הזו, מוסיפים את הדגל --set inferenceExtension.monitoring.prometheus.enabled=false לפקודה.
• אם אתם משתמשים ��ניטור ברירת המחדל באשכול GKE Autopilot, אתם צריכים להוסיף גם את הדגל --set provider.gke.autopilot=true.

ההתקנה של Helm מתקינה באופן אוטומטי את מדיניות הזמן הקצוב לתפוגה הנדרשת, את הכלי לבחירת נקודות קצה ואת ה-Pods שנדרשים לצורך יכולת התבוננות.

הפעולה הזו יוצרת אובייקט InferencePool: ‏ vllm-llama3-8b-instruct שמפנה לשירותי נקודות הקצה של המודל בתוך קבוצות ה-Pod. נוצר גם פריסה של הכלי לבחירת נקודות קצה בשם app:vllm-llama3-8b-instruct-epp עבור ה-InferencePool שנוצר.

פריסת הכלי לבחירת נקודות קצה עם זמינות גבוהה

פריסת Endpoint Picker ‏ (EPP) עם קצה עורפי מועדף מאפשרת טופולוגיית ניתוב פעילה-פסיבית שמגובה על ידי Cloud Load Balancing.

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

• עקביות המצב: Cloud Load Balancing מפנה 100% מהתנועה במצב יציב ext_proc אל העותק המשוכפל הראשי של Endpoint Picker ‏ (epp-0), תוך שמירה על מצב המטמון של מפתח/ערך (KV) ועל הקשר של תזמון הבקשות.
• מעבר לגיבוי ללא השבתה: אם ה-Endpoint Picker Pod הראשי קורס או עובר תחזוקה, Cloud Load Balancing מזהה את הכשל באמצעות בדיקות תקינות פעילות של gRPC ומנתב באופן מיידי את התנועה לרפליקה במצב המתנה (epp-1).
• עמידות במצב של כשל פתוח: בשילוב עם failureMode: FailOpen, כשלים חולפים בניתוב עוקפים את הכלי לבחירת נקודות קצה ומאפשרים להעביר בקשות ישירות לשרתי המודלים בלי להפיל בקשות של משתמשים.

כשמפעילים את התכונה 'עורפי חזית מועדפים',‏ GKE משנה את הארכיטקטורה ואת הניתוב בדרכים הבאות:

• ארכיטקטורת Endpoint Picker StatefulSet: Endpoint Picker נפרס כ-StatefulSet במקום כ-Deployment. מספרי ה-Pod מציינים את תפקידי העותקים: מספר epp-0 משמש כעותק הראשי שמוצמד לשכבת ה-Backend PREFERRED, ומספר epp-1 משמש כעותק ההמתנה שמוצמד לשכבת DEFAULT.
• מצב הניתוב נשאר מרכזי: תנועת נתונים במצב יציב ext_proc מנותבת באופן בלעדי לרפליקה הראשית של Endpoint Picker‏ (epp-0) כדי לשמור על מעקב אחר מטמון של זוגות מפתח/ערך (KV) ועל מצב תזמון הבקשות באופן מרכזי. אם epp-0 לא תקין, Cloud Load Balancing מעביר את התעבורה אל העותק המשוכפל במצב המתנה (epp-1).
• ארכיטקטורת Dual-Service: תרשים ה-Helm יוצר שירות ראשי (Service/${GUIDE_NAME}-epp) ושירות גיבוי בהמתנה (Service/${GUIDE_NAME}-epp-backup). המשאב InferencePool מכוון באופן הצהרתי לשירות הגיבוי בהמתנה. הצמדת הבעלות על Gateway הצהרתית לשירות במצב המתנה מבטיחה שלולאות התיאום של בקר GKE Gateway לא ינתקו את קבוצות נקודות הקצה הראשיות ברשת (NEGs) שמצורפות לשירות העורפי.

כדי ליצור InferencePool ו-Endpoint Picker עם זמינות גבוהה באמצעות Helm, מבצעים את השלבים הבאים:

1. פורסים את InferencePool ואת Endpoint Picker עם קצוות עורפיים מועדפים באמצעות Helm:‏

   helm install ${GUIDE_NAME} \
     -f guides/recipes/scheduler/base.values.yaml \
     -f guides/${GUIDE_NAME}/scheduler/${GUIDE_NAME}.values.yaml \
     --set provider.name=gke \
     --set inferenceExtension.monitoring.gke.enabled=true \
     --set provider.gke.preferredBackends.enabled=true \
     --set provider.gke.preferredBackends.preferredReplicas=1 \
     --set provider.gke.preferredBackends.defaultReplicas=1 \
     -n ${NAMESPACE} \
     --version ${GAIE_VERSION} \
     oci://LLM_D_REGISTRY_PATH
   

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

   • ‫GAIE_VERSION: הגרסה של תרשים ה-Helm של Gateway API Inference Extension‏ (GAIE). לדוגמה, v1.5.0. כדי להשתמש בקצוות עורפיים מועדפים, נדרשת גרסת תרשים Helm‏ v1.5.0 ואילך.
   • ‫LLM_D_REGISTRY_PATH: הנתיב למאגר OCI של תרשים Helm. לדוגמה, registry.k8s.io/gateway-api-inference-extension/charts/inferencepool.

   רשימה מלאה של הפרמטרים מופיעה במאמר values.yaml.

2. מצרפים את ה-NEG הראשי ל-BackendService:

   export PROJECT_ID=PROJECT_ID
   export REGION=REGION
   
   export BACKEND_SERVICE=$(gcloud compute backend-services list --project=${PROJECT_ID} --format="value(name)" | grep "${GUIDE_NAME}-epp")
   
   export PRIMARY_NEG=$(kubectl get svc ${GUIDE_NAME}-epp -n ${NAMESPACE} -o jsonpath='{.metadata.annotations.cloud\.google\.com/neg-status}' | jq -r '.network_endpoint_groups["9002"]')
   
   for ZONE in $(kubectl get svc ${GUIDE_NAME}-epp -n ${NAMESPACE} -o jsonpath='{.metadata.annotations.cloud\.google\.com/neg-status}' | jq -r '.zones[]'); do
     gcloud compute backend-services add-backend ${BACKEND_SERVICE} \
       --network-endpoint-group=${PRIMARY_NEG} \
       --network-endpoint-group-zone=${ZONE} \
       --region=${REGION} \
       --project=${PROJECT_ID} \
       --balancing-mode=RATE \
       --max-rate-per-endpoint=100 \
       --preference=PREFERRED
     sleep 15
   done
   

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

   • ‫PROJECT_ID: ��זהה הפרויקט ב- Google Cloud .
   • ‫REGION: Google Cloud האזור של האשכול ושל שירות לקצה העורפי.

אחרי שמצרפים NEGs אזוריים ל- Google Cloud BackendService, לא צריך להריץ שוב פקודות gcloud כדי לשנות את מספר העותקים המשוכפלים (preferredReplicas או defaultReplicas) או להפעיל מחדש את ה-Pods. בקר ה-NEG של GKE מסנכרן באופן אוטומטי כתובות IP של פודים בודדים ל-NEGs האזוריים הרשומים.

אם מוחקים ויוצרים מחדש את משאב האב Gateway או InferencePool, בקר GKE Gateway יוצר מחדש את Google Cloud BackendService הבסיסי עם מזהה ענן חדש. במקרה כזה, מריצים את תהליך העבודה של הצירוף שצוין למעלה כדי לצרף NEGs ראשיים אזוריים ל-BackendService שנוצר לאחרונה.

יצירת HTTPRoute

משאב HTTPRoute מגדיר איך שער GKE מנתב בקשות HTTP נכנסות לשירותי קצה עורפיים, כמו InferencePool. המשאב HTTPRoute מציין כללי התאמה (לדוגמה, כותרות או נתיבים) ואת השרת העורפי שאליו התנועה צריכה להיות מועברת.

1. כדי ליצור HTTPRoute, שומרים את קובץ המניפסט לדוגמה הבא בתור httproute.yaml:

   apiVersion: gateway.networking.k8s.io/v1
   kind: HTTPRoute
   metadata:
     name: HTTPROUTE_NAME
   spec:
     parentRefs:
     - name: GATEWAY_NAME
     rules:
     - matches:
       - path:
           type: PathPrefix
           value: PATH_PREFIX
       backendRefs:
       - name: INFERENCE_POOL_NAME
         group: "inference.networking.k8s.io"
         kind: InferencePool
   

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

   • ‫HTTPROUTE_NAME: שם ייחודי של משאב HTTPRoute. לדוגמה, my-route.
   • ‫GATEWAY_NAME: השם של משאב Gateway שיצרתם. לדוגמה, inference-gateway.
   • ‫PATH_PREFIX: תחילית הנתיב שמשמשת להתאמת בקשות נכנסות. לדוגמה, / כדי להתאים לכולם.
   • ‫INFERENCE_POOL_NAME: השם של משאב InferencePool שאליו רוצים לה��נות את התנועה. לדוגמה, vllm-llama3-8b-instruct.

2. מחילים את המניפסט על האשכול:

   ‫

   kubectl apply -f httproute.yaml
   

ציון יעדי ההסקה

המשאב המותאם אישית InferenceObjective מאפשר לציין את העדיפות של הבקשות.

השדה metadata.name של משאב InferenceObjective מציין את השם של יעד ההסקות, השדה Priority מציין את רמת הקריטיות של ההגשה והשדה poolRef מציין את InferencePool שבו המודל מוגש.

apiVersion: inference.networking.x-k8s.io/v1alpha2
kind: InferenceObjective
metadata:
  name: NAME
spec:
  priority: VALUE
  poolRef:
    name: INFERENCE_POOL_NAME
    group: "inference.networking.k8s.io"

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

• ‫NAME: השם של יעד ההסקה. לדוגמה, food-review.
• ‫VALUE: העדיפות של יעד ההסקה. זהו מספר שלם, וככל שהערך גבוה יותר הבקשה קריטית יותר. לדוגמה, 10.
• ‫INFERENCE_POOL_NAME: השם של InferencePool שיצרתם בשלב הקודם. לדוגמה, vllm-llama3-8b-instruct.

כדי ליצור InferenceObjective, פועלים לפי השלבים הבאים:

1. שומרים את קובץ המניפסט הבא בשם inference-objectives.yaml. קובץ המניפסט הזה יוצר שני משאבים של InferenceObjective. ההגדרה הראשונה קובעת את food-review Inference Objective ב-vllm-llama3-8b-instruct InferencePool עם עדיפות של 10. ההגדרה השנייה קובעת שהיעד llama3-base-model Inference יקבל עדיפות גבוהה יותר של 20.

   apiVersion: inference.networking.x-k8s.io/v1alpha2
   kind: InferenceObjective
   metadata:
     name: food-review
   spec:
     priority: 10
     poolRef:
       name: vllm-llama3-8b-instruct
       group: "inference.networking.k8s.io"
   ---
   apiVersion: inference.networking.x-k8s.io/v1alpha2
   kind: InferenceObjective
   metadata:
     name: llama3-base-model
   spec:
     priority: 20 # Higher priority
     poolRef:
       name: vllm-llama3-8b-instruct
   

2. מחילים את קובץ המניפסט לדוגמה על האשכול:

   kubectl apply -f inference-objectives.yaml
   

אימות הפריסה

כדי לוודא שכל הרכיבים פועלים, מריצים את הפקודות הבאות:

kubectl get inferencepool
kubectl get inferenceobjective
kubectl get pods -l app=vllm-llama3-8b-instruct-epp

שליחת בקשת הסקה

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

כדי לשלוח בקשות להסקת מסקנות:

1. מגדירים את משתני הסביבה הבאים:

   export GATEWAY_NAME=GATEWAY_NAME
   export PORT_NUMBER=PORT_NUMBER # Use 80 for HTTP
   

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

   • ‫GATEWAY_NAME: השם של משאב ה-Gateway.
   • ‫PORT_NUMBER: מספר היציאה שהגדרתם ב-Gateway.

2. כדי לקבל את נקודת הקצה של שער הגישה, מריצים את הפקודה הבאה:

   echo "Waiting for the Gateway IP address..."
   IP=""
   while [ -z "$IP" ]; do
     IP=$(kubectl get gateway/${GATEWAY_NAME} -o jsonpath='{.status.addresses[0].value}' 2>/dev/null)
     if [ -z "$IP" ]; then
       echo "Gateway IP not found, waiting 5 seconds..."
       sleep 5
     fi
   done
   
   echo "Gateway IP address is: $IP"
   PORT=${PORT_NUMBER}
   

3. כדי לשלוח בקשה לנקודת הקצה /v1/completions באמצעות curl, מריצים את הפקודה הבאה:

   curl -i -X POST ${IP}:${PORT}/v1/completions \
   -H 'Content-Type: application/json' \
   -H 'Authorization: Bearer $(gcloud auth application-default print-access-token)' \
   -d '{
       "model": "MODEL_NAME",
       "prompt": "PROMPT_TEXT",
       "max_tokens": MAX_TOKENS,
       "temperature": "TEMPERATURE"
   }'
   

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

   • ‫MODEL_NAME: השם של המודל או של מתאם LoRA שרוצים להשתמש בהם.
   • ‫PROMPT_TEXT: הנחיית הקלט למודל.
   • ‫MAX_TOKENS: המספר המקסימלי של טוקנים שייווצרו בתגובה.
   • ‫TEMPERATURE: קובע את רמת האקראיות של הפלט. כדי לקבל פלט דטרמיניסטי, משתמשים בערך 0. כדי לקבל פלט יצירתי יותר, משתמשים במספר גבוה יותר.

בדוגמה הבאה אפשר לראות איך לשלוח בקשת דוגמה ל-GKE Inference Gateway:

curl -i -X POST ${IP}:${PORT}/v1/completions -H 'Content-Type: application/json' -H 'Authorization: Bearer $(gcloud auth application-default print-access-token)' -d '{
    "model": "food-review-1",
    "prompt": "What is the best pizza in the world?",
    "max_tokens": 2048,
    "temperature": 0
}'

חשוב לשים לב להתנהגויות הבאות:

• גוף הבקשה: גוף הבקשה יכול לכלול פרמטרים נוספים כמו stop ו-top_p. רשימה מלאה של האפשרויות מופיעה במפרט של OpenAI API.
• טיפול בשגיאות: צריך להטמיע טיפול מתאים בשגיאות בקוד הלקוח כדי לטפל בשגיאות אפשריות בתגובה. לדוגמה, בודקים את קוד הסטטוס של HTTP בcurlתגובה. קוד סטטוס שאינו 200 בדרך כלל מציין שגיאה.
• אימות והרשאה: עבור פריסות בסביבת ייצור, מאבטחים את נקודת הקצה ל-API באמצעות מנגנוני אימות והרשאה. הבקשות צריכות לכלול את הכותרות המתאימות (לדוגמה, Authorization).

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

• מידע על GKE Inference Gateway
• מידע על פריסת GKE Inference Gateway