‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

פריסת GKE Inference Gateway שמבוסס על llm-d

Autopilot Standard

במאמר הזה נסביר איך לפרוס את GKE Inference Gateway.

המסמך הזה מיועד למומחי רשתות שאחראים לניהול התשתית של GKE, ולאדמינים של פלטפורמות שמנהלים עומסי עבודה של AI.

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

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

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

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

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

מפעילים את Google Kubernetes Engine API.

הפעלת Google Kubernetes Engine API

כדי להשתמש ב-Google Cloud CLI למשימה הזו, מתקינים ואז מאתחלים את ה-CLI של gcloud. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא יתמכו בהרצת הפקודות שמופיעות במסמך הזה.
הערה: אם כבר התקנתם את ה-CLI של gcloud, הקפידו להגדיר את compute/region המאפיין. אם אתם משתמשים בעיקר באשכולות אזוריים, הגדירו במקום זאת את compute/zone. אם מגדירים מיקום ברירת מחדל, אפשר להימנע משגיאות ב-CLI של gcloud כמו One of [--zone, --region] must be supplied: Please specify location. יכול להיות שתצטרכו לציין את המיקום בפקודות מסוימות אם המיקום של האשכול שונה מברירת המחדל שהגדרתם.

מפעילים את Compute Engine API, את Kubernetes Engine API, את Network Services API ואת Model Armor 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:

הכנת הסביבה: הגדרת התשתית והרכיבים הנדרשים.
יצירת מאגר הסקה: הגדרה של מאגר שרתי מודלים באמצעות משאב מותאם אישית מסוג InferencePool.
הגדרת יעדי הסקה: מגדירים יעדי הסקה באמצעות המשאב המותאם אישית InferenceObjective
יצירת השער: חשיפת שירות ההסקה באמצעות Gateway API.
יוצרים את HTTPRoute: מגדירים איך תעבורת HTTP מנותבת לשירות ההסקה.
שליחת בקשות הסקה: שליחת בקשות למודל שנפרס.

יצירת השער

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

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

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

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

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

שומרים את קובץ המניפסט לדוגמה הבא בשם 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.
מחילים את המניפסט על האשכול:
```
kubectl apply -f gateway.yaml
```

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

הכנת הסביבה

מתקינים את Helm.
יוצרים אשכול GKE:
- יוצרים אשכול GKE Autopilot או Standard בגרסה 1.32.3 ואילך. בדוגמה הזו של cluster-toolkit gke-a3-highgpu תוכלו לראות הגדרה לדוגמה של פריסה בלחיצה אחת.
- מגדירים את הצמתים עם משפחת המחשוב והמאיץ המועדפים.
- אפשר להשתמש במדריך לתחילת העבודה עם GKE Inference כדי לקבל מניפסטים של פריסה שהוגדרו מראש ונבדקו, על סמך המאיץ, המודל ודרישות הביצועים שבחרתם.
מתקינים את ההגדרות הדרושות של משאבים מותאמים אישית (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
```
  מידע נוסף זמין בטבלת התאימות.

אם אתם משתמשים בגרסה של GKE שקודמת ל-v1.32.2-gke.1182001 ואתם רוצים להשתמש ב-Model Armor עם 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

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

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

מתקינים את ההגדרות של משאבים מותאמים אישית (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}"
```
יוצרים את מרחב השמות של היעד:
```
kubectl create namespace ${NAMESPACE}
```

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

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

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

יוצרים סוד של Kubernetes כדי לאחסן את האסימון של Hugging Face. הטוקן הזה משמש לגישה למודל הבסיסי ולמתאמי ה-LoRA:
```
kubectl create secret generic hf-token --from-literal=token=HF_TOKEN
```
מחליפים את HF_TOKEN באסימון של Hugging Face.
פורסים את שרת המודלים של 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

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

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

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

דוגמה ל-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 ממאגר llm-d ב-GitHub. חובה לבצע את השלב הזה:

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, משנים את השדה הבא כך שיתאים לתווית של ה-Deployment 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. בנוסף, נוצר פריסה של בורר נקודות הקצה (Endpoint Picker) בשם app:vllm-llama3-8b-instruct-epp עבור ה-InferencePool שנוצר.

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

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

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

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

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

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

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

פורסים את 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 chart של 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.

מצרפים את ה-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 נפרדות של Pods עם קבוצות ה-NEG האזוריות הרשומות.

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

יצירת `HTTPRoute`

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

כדי ליצור 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.
מחילים את המניפסט על האשכול:

‫
```
kubectl apply -f httproute.yaml
```
הערה: כדי להגדיר שיתוף משאבים בין מקורות (CORS) לנקודות הקצה של ההסקה באמצעות מסנן CORS ב-HTTPRoute, אפשר לעיין במאמר הגדרת שיתוף משאבים בין מקורות (CORS).

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

המשאב המותאם אישית 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, פועלים לפי השלבים הבאים:

שומרים את המניפסט הבא בתור 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

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

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

מגדירים את משתני הסביבה הבאים:
```
export GATEWAY_NAME=GATEWAY_NAME
export PORT_NUMBER=PORT_NUMBER # Use 80 for HTTP
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫GATEWAY_NAME: השם של משאב השער.
- ‫PORT_NUMBER: מספר היציאה שהגדרתם בשער.

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

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}

כדי לשלוח בקשה לנקודת הקצה /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).

מטריצת תאימות

בטבלה הבאה מפורטת מטריצת התאימות והתמיכה של הגדרות המשאבים בהתאמה אישית (CRD) של Gateway API Inference Extension. במאמר מפורטות הגרסאות של CustomResourceDefinition שנתמכות על ידי GKE בהשוואה לפרויקט התוסף של Gateway API Inference בקוד פתוח (OSS), כולל דרישות ספציפיות לגבי גרסאות והערות לגבי התקנה.

שם של CustomResourceDefinition	גרסת ה-API של CustomResourceDefinition	GKE Managed Support	תמיכה ב-OSS (Gateway API Inference Extension)
V1 InferencePool	inference.networking.k8s.io/v1	נתמך ב-GKE 1.32.3 ואילך, וב-CustomResourceDefinition שמותקן כברירת מחדל ב-GKE 1.34.0-gke.1626000 ואילך	נתמך החל מ-Gateway API Inference Extension v1.0.0
‫Alpha InferencePool (מומלץ למשתמשים להתחיל עם InferencePool בגרסה 1, כי גרסת האלפא של InferencePool הוצאה משימוש)	inference.networking.x-k8s.io/v1alpha2	נתמך ב-GKE 1.32.3 ואילך. עם זאת, CustomResourceDefinition לא מותקן כברירת מחדל ב-GKE. המשתמשים צריכים להתקין באופן ידני את CustomResourceDefinition מ-Gateway API Inference Extension.	נתמך החל מ-Gateway API Inference Extension v0.2.0
Alpha InferenceObjective	inference.networking.x-k8s.io/v1alpha2	‫GKE לא מנהל את InferenceObjective	נתמך החל מ-Gateway API Inference Extension v1.0.0
‫Alpha InferenceModel (מומלץ למשתמשים להתחיל עם InferenceObjective כי InferenceModel הוצא משימוש)	inference.networking.x-k8s.io/v1alpha2	‫GKE לא מנהל את InferenceModel	נתמך החל מגרסה 0.2.0 של Gateway API Inference Extension.

אבטחת העורף האחורי של ההסקה באמצעות TLS בעורף האחורי

ה-TLS של ה-Backend מאפשר למאזן העומסים של GKE Gateway לאמת את הזהות של ה-Backend של ההסקה שהוא מתחבר אליו. פרוטוקול TLS לקצה העורפי מוסיף שלב אימות מפורש במהלך לחיצת היד בפרוטוקול TLS בין השער לבין ה-Pod של הקצה העורפי. האימות הזה עוזר לוודא שהשער מתקשר רק עם שרתי מודל מהימנים.

כדי להגדיר TLS בקצה העורפי לעומסי העבודה של ההסקות, צריך לצרף BackendTLSPolicy למשאב InferencePool או GCPInferencePoolImport.

מידע נוסף זמין במאמר בנושא הגדרת TLS בשרת העורפי.

פריסת GKE Inference Gateway שמבוסס על llm-d קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

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

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

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

הגדרת GKE Inference Gateway

יצירת השער

הכנת הסביבה

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

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

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

דוגמה ל-InferencePool עם כמה יציאות

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

יצירת HTTPRoute

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

אימות הפריסה

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

מטריצת תאימות

אבטחת העורף האחורי של ההסקה באמצעות TLS בעורף האחורי

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

פריסת GKE Inference Gateway שמבוסס על llm-d

יצירת `HTTPRoute`