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

במאמר הזה נסביר איך לפרוס את 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 משפר את שער Google Kubernetes Engine כדי לייעל את ההכניסה לשימוש בסביבת הי��צור של אפליקציות ועומסי עבודה של AI גנרטיבי ב-GKE. הוא מאפשר ניהול יעיל של עומסי עבודה של AI והתאמה שלהם לצרכים, מאפשר הגדרת יעדי ביצועים ספציפיים לעומס העבודה, כמו זמן אחזור, ומשפר את ניצול המשאבים, את יכולת הצפייה ואת הבטיחות של ה-AI.

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

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

• מפעילים את ממשק Google Kubernetes Engine API.
הפעלת 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 ו-Model Armor API אם צריך.

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

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

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

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

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

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

דרישות של GKE Gateway Controller

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

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

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

• ��ין תמיכה בשערי Multi-cluster Gateways.
• ‫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 Inference כדי לקבל מניפסטים של פריסה שהוגדרו מראש ונבדקו, על סמך המאיץ, המודל ודרישות הביצועים שבחרתם.

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 ואתם רוצים להשתמש ב-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
   

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 באמצעות 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 שנוצר.

יצירת HTTPRoute

משאב HTTPRoute מגדיר איך GKE Gateway מנתב בקשות 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).

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

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

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

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

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

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

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

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