פריסת אפליקציית AI אקטיבי ב-GKE באמצעות ערכה לפיתוח סוכנים (ADK) ומודל LLM באירוח עצמי

במדריך הזה נדגים איך לפרוס ולנהל אפליקציות של סוכני AI/ML בקונטיינרים באמצעות Google Kubernetes Engine ‏ (GKE). שילוב של ערכת פיתוח סוכנים (ADK) של Google עם מודל שפה גדול (LLM) באירוח עצמי כמו Llama 3.1 שמופעל על ידי vLLM, מאפשר להפעיל סוכני AI ביעילות ובקנה מידה גדול, תוך שמירה על שליטה מלאה במערך המודלים. במדריך הזה נסביר את התהליך מקצה לקצה של העברת סוכן מבוסס Python משלב הפיתוח לשלב הפריסה בסביבת הייצור באשכול GKE Autopilot עם האצת GPU.

המדריך הזה מיועד למהנדסי למידת מכונה (ML), למפתחים ולאדריכלי ענן שרוצים להשתמש ביכולות של Kubernetes לארגון קונטיינרים כדי להפעיל אפליקציות של AI/ML מבוססות-סוכנים. כדי לקרוא מידע נוסף על תפקידים נפוצים ועל משימות לדוגמה שאנחנו מתייחסים אליהן בתוכן, אפשר לעיין במאמר תפקידים נפוצים של משתמשים ומשימות ב-GKE. Google Cloud

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

רקע

בקטע הזה מתוארות הטכנולוגיות העיקריות שבהן נעשה שימוש במדריך הזה.

ערכה לפיתוח סוכנים (ADK)

הערכה לפיתוח סוכנים (ADK) היא מסגרת גמישה ומודולרית לפיתוח ולפריסה של סוכני AI. הערכה מותאמת ל-Gemini ולסביבת Google, אבל לא מחייבת שימוש במודל או בפריסה ספציפיים, והיא תוכננה כך שתהיה תואמת למסגרות אחרות. ה-ADK נועד להפוך את פיתוח הסוכנים לתהליך שדומה יותר לפיתוח תוכנה, כדי להקל על מפתחים ליצור, לפרוס ולתזמן ארכיטקטורות של סוכנים, ממשימות בסיסיות ועד לתהליכי עבודה מורכבים.

מידע נוסף מופיע במאמרי העזרה בנושא ADK.

שירות Kubernetes מנוהל של GKE

Google Cloud מציעה מגוון שירותים, כולל GKE, שמתאים מאוד לפריסה ולניהול של עומסי עבודה של AI/ML. ‫GKE הוא שירות Kubernetes מנוהל שמפשט את הפריסה, ההרחבה והניהול של אפליקציות בקונטיינרים. ‫GKE מספק את התשתית הנדרשת – כולל משאבים ניתנים להרחבה, מחשוב מבוזר ורשת יעילה – כדי לעמוד בדרישות החישוב של מודלי LLM.

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

vLLM

‫vLLM הוא פריימוורק קוד פתוח לאירוח מודלים גדולים של שפה (LLM) שעבר אופטימיזציה גבוהה, ויכול לשפר את קצב העברת הנתונים של אירוח מודלים ביחידות GPU. הוא כולל תכונות כמו:

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

מידע נוסף מופיע במאמרי העזרה בנושא vLLM.

מטרות

במדריך הזה מוסבר איך:

  1. מגדירים את סביבת Google Cloud .
  2. הקצאת אשכול GKE עם GPU.
  3. פריסת מודל Llama 3.1 באמצעות שרת ההיקשים vLLM.
  4. יוצרים קובץ אימג' של קונטיינר לסוכן שמבוסס על ADK.
  5. פורסים את הסוכן באשכול GKE ומחברים אותו ל-LLM באירוח עצמי.
  6. בודקים את הסוכן שפרסתם.

ארכיטקטורה

במדריך הזה מוצגת ארכיטקטורה ניתנת להרחבה לפריסת אפליקציות AI אקטיבי ב-GKE. אפליקציית הסוכן ADK פועלת במאגר צמתים רגיל של CPU, ומודל ה-LLM באירוח עצמי (Llama 3.1 ב-vLLM) פועל במאגר צמתים עם GPU, שניהם באותו אשכול GKE. הארכיטקטורה הזו מפרידה את הלוגיקה של האפליקציה של הסוכן מעומס העבודה של ההסקה של מודל ה-LLM, וכך מאפשרת לשנות את גודל כל רכיב ולנהל אותו בנפרד.

בתרשים הזה מוצגת ארכיטקטורה ניתנת להרחבה לפריסת אפליקציות של AI אקטיבי ב-GKE, שבה לוגיקת האפליקציה של הסוכן מופרדת מעומס העבודה של ההסקה של מודל השפה הגדול (LLM), כדי לאפשר ניהול והרחבה עצמאיים. הארכיטקטורה מורכבת משני רכיבי ליבה: אפליקציית הסוכן ADK שפועלת במאגר צמתים רגיל של CPU, ומודל LLM באירוח עצמי (Llama 3.1 ב-vLLM) שפועל במאגר צמתים עם GPU, שניהם באותו אשכול GKE.
איור 1: ארכיטקטורה ניתנת להרחבה לפריסת AI אקטיבי ב-GKE.

לארכיטקטורה יש שני רכיבי ליבה, כל אחד בפריסת GKE משלו:

  • אפליקציית סוכן ADK: הלוגיקה העסקית והכלים (כמו get_weather) של הסוכן שנוצרו בהתאמה אישית נמצאים בקובץ אימג' של קונטיינר. התמונה פועלת במאגר צמתים רגיל של CPU ומתקשרת עם ה-LLM באמצעות שירות Kubernetes פנימי.

  • מודל LLM באירוח עצמי (Llama 3.1 ב-vLLM): המודל Llama 3.1 פועל בשרת vLLM ייעודי במאגר צמתים עם GPU. הפריסה הזו משתמשת בקובץ אימג' ציבורי של קונטיינר (vllm/vllm-openai:v0.8.5) שמוגדר להורדה ולהצגה של המודל שצוין מ-Hugging Face כשהקונטיינר מופעל. הסוכן מתקשר עם השרת הזה באמצעות API בארכיטקטורת REST שנחשף על ידי שירות Kubernetes‏ vllm-llama3-service.

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

עלויות

במדריך הזה השתמשנו ברכיבים הבאים של Google Cloud, והשימוש בהם כרוך בתשלום:

כדאי לעיין בתמחור של כל שירות כדי להבין את העלויות הפוטנציאליות.

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

  • נכנסים לחשבון Google Cloud . אם אתם משתמשים חדשים ב- Google Cloud, צרו חשבון כדי שתוכלו להעריך את הביצועים של המוצרים שלנו בתרחישים מהעולם האמיתי. לקוחות חדשים מקבלים בחינם גם קרדיט בשווי 300$ להרצה, לבדיקה ולפריסה של עומסי העבודה.

  • In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  • Verify that billing is enabled for your Google Cloud project.

  • Enable the required APIs.

    Roles required to enable APIs

    To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

    Enable the APIs

  • In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  • Verify that billing is enabled for your Google Cloud project.

  • Enable the required APIs.

    Roles required to enable APIs

    To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

    Enable the APIs

    •

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

    בדיקת התפקידים

    1. נכנסים לדף IAM במסוף Google Cloud .

      כניסה לדף IAM
    2. בוחרים את הפרויקט.

    3. בעמודה Principal (חשבון המשתמש), מוצאים את כל השורות שבהן מופיע השם שלכם או של קבוצה שאתם נכללים בה. כדי לברר באילו קבוצות אתם נכללים, פנו לאדמין.

    4. בודקים את העמודה Role בכל השורות שבהן מצוין או מופיע השם שלכם, כדי לראות אם רשימת התפקידים כוללת את התפקידים הנדרשים.

    מתן התפקידים

    1. נכנסים לדף IAM במסוף Google Cloud .

      כניסה לדף IAM
    2. בוחרים את הפרויקט.
    3. לוחצים על Grant access.

    4. בשדה New principals, מזינים את מזהה המשתמש. ‫ בדרך כלל מזהה המשתמש הוא כתובת האימייל של חשבון Google.

      ‫
    5. לוחצים על Select a role ומחפשים את התפקיד.
    6. כדי לתת עוד תפקידים, לוחצים על Add another role ומוסיפים אותם.
    7. לוחצים על Save.
  • כדי להוריד את מודל Llama, צריך לקבל מ-Hugging Face אסימון גישה לקריאה. צריך גם לבקש גישה למודל Llama 3.1.

הכנת הסביבה

במדריך הזה משתמשים ב-Cloud Shell כדי לנהל משאבים שמתארחים ב- Google Cloud. ב-Cloud Shell מותקנת מראש התוכנה שדרושה למדריך הזה, כולל kubectl,‏ terraform ו-Google Cloud CLI.

כדי להגדיר את הסביבה באמצעות Cloud Shell:

  1. במסוף Google Cloud , מפעילים סשן של Cloud Shell ולוחצים על Activate Cloud Shell.סמל ההפעלה של Cloud Shell הפעולה הזו מפעילה סשן בחלונית של מסוף Google Cloud .

  2. מגדירים את משתני הסביבה שמוגדרים כברירת מחדל:

    gcloud config set project PROJECT_ID
export GOOGLE_CLOUD_REGION=REGION
export PROJECT_ID=PROJECT_ID

    מחליפים את הערכים הבאים:

    • ‫PROJECT_ID: Google Cloud מזהה הפרויקט.
    • ‫REGION: ה Google Cloud אזור (לדוגמה, us-east4) להקצאת אשכול GKE,‏ Artifact Registry ומשאבים אזוריים אחרים. חשוב לציין אזור שתומך במכונות וירטואליות מסוג L4 GPU וסוג מכונה G2. כדי לבדוק את הזמינות של אזור מסוים, אפשר לעיין במאמר אזורים ותחומים של GPU במאמרי העזרה של Compute Engine.

שכפול פרויקט לדוגמה

  1. בטרמינל Cloud Shell, משכפלים את מאגר המקורות של הקוד לדוגמה של המדריך:

    git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples.git

  2. עוברים לספריית המדריך:

    cd kubernetes-engine-samples/ai-ml/adk-vllm

יצירה והגדרה של Google Cloud משאבים

כדי לפרוס את הסוכן, קודם צריך להקצות את המשאבים הדרושים Google Cloud. אפשר ליצור את אשכול GKE ואת מאגר Artifact Registry באמצעות ה-CLI של gcloud או Terraform.

gcloud

בקטע הזה מובאות פקודות של ה-CLI של gcloud להגדרת אשכול GKE ו-Artifact Registry.

  1. יצירת אשכול GKE: אפשר לפרוס את האפליקציה של הסוכן שמופעלת בקונטיינר באשכול GKE Autopilot או באשכול רגיל. כדי ליהנות מחוויית Kubernetes מנוהלת לחלוטין, אפשר להשתמש באשכול Autopilot. כדי לבחור את מצב הפעולה של GKE שהכי מתאים לעומסי העבודה שלכם, אפשר לעיין במאמר מידע על מצבי הפעולה של GKE.

    טייס אוטומטי

    ב-Cloud Shell, מריצים את הפקודה הבאה:

    gcloud container clusters create-auto CLUSTER_NAME \
    --location=$GOOGLE_CLOUD_REGION

    מחליפים את CLUSTER_NAME בשם של אשכול GKE.

    במצב Autopilot, ‏ GKE מקצה באופן אוטומטי צמתים על סמך בקשות המשאבים של עומס העבודה. ה-GPU שנדרש ל-LLM מוגדר במניפסט deploy-llm.yaml באמצעות nodeSelector.

    כדי להוסיף nodeSelector ולבקש את ה-GPU‏ nvidia-l4, פועלים לפי השלבים הבאים:

    1. פותחים את kubernetes-engine-samples/ai-ml/adk-vllm/deploy-llm/deploy-llm.yaml בעורך.

    2. מוסיפים את nodeSelector הבא לקטע spec.template.spec:

      nodeSelector:
cloud.google.com/gke-accelerator: nvidia-l4

    רגילה

    1. ב-Cloud Shell, יוצרים אשכול רגיל על ידי הרצת הפקודה הבאה:

      gcloud container clusters create CLUSTER_NAME \
    --location=$GOOGLE_CLOUD_REGION

      מחליפים את CLUSTER_NAME בשם של אשכול GKE.

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

      gcloud container node-pools create gpu-node-pool \
    --cluster=CLUSTER_NAME \
    --location=$GOOGLE_CLOUD_REGION \
    --machine-type=g2-standard-8 \
    --accelerator=type=nvidia-l4,count=1 \
    --enable-gvnic

      קובץ deploy-llm.yaml מציין GPU מסוג nvidia-l4, שזמין בסדרת המכונות G2. מידע נוסף על סוג המכונה הזה זמין במאמר סוגי מכונות עם GPU במסמכי העזרה של Compute Engine.

  2. יוצרים מאגר ב-Artifact Registry: יוצרים מאגר ב-Artifact Registry כדי לאחסן ולנהל בצורה מאובטחת את קובץ האימג' של קונטיינר Docker של הסוכן.

    gcloud artifacts repositories create REPO_NAME \
    --repository-format=docker \
    --location=$GOOGLE_CLOUD_REGION

    מחליפים את REPO_NAME בשם של מאגר Artifact Registry שרוצים להשתמש בו (לדוגמה, adk-repo).

  3. קבלת כתובת ה-URL של המאגר: כדי לאמת את הנתיב המלא למאגר, מריצים את הפקודה הבאה. תשתמשו בפורמט הזה כדי לתייג את קובץ האימג' של Docker כשתיצרו את קובץ האימג' של הסוכן.

    gcloud artifacts repositories describe REPO_NAME \
    --location $GOOGLE_CLOUD_REGION

Terraform

בקטע הזה מוסבר איך להשתמש בהגדרת Terraform שכלולה במאגר הדוגמאות כדי להקצות את המשאבים שלכם ב- Google Cloud באופן אוטומטי.

  1. עוברים לספרייה של Terraform: הספרייה \terraform מכילה את כל קובצי התצורה שנדרשים ליצירת אשכול GKE ומשאבים נדרשים אחרים.

    cd terraform

  2. יוצרים קובץ משתנים של Terraform: מעתיקים את קובץ המשתנים לדוגמה (example_vars.tfvars) שמופיע כאן כדי ליצור קובץ vars.tfvars משלכם.

    cp example_vars.tfvars vars.tfvars

    פותחים את הקובץ vars.tfvars בעורך ומחליפים את הערכים הזמניים לשמירת מקום בהגדרות הספציפיות שלכם. לפחות צריך להחליף את PROJECT_ID ב Google Cloud מזהה הפרויקט ואת CLUSTER_NAME בשם של אשכול GKE.

  3. מפעילים את Terraform: כדי להוריד את הפלאגינים הדרושים של ספק השירות עבור Google Cloud, מריצים את הפקודה הזו.

    terraform init

  4. בודקים את תוכנית הביצוע: הפקודה הזו מציגה את השינויים בתשתית ש-Terraform תבצע.

    terraform plan -var-file=vars.tfvars

  5. החלת ההגדרות: כדי ליצור את המשאבים בפרויקט Google Cloud , מריצים את תוכנית Terraform. מאשרים באמצעות yes כשמוצגת הבקשה.

    terraform apply -var-file=vars.tfvars

אחרי שמריצים את הפקודות האלה, Terraform מקצה את אשכול GKE ואת מאגר Artifact Registry, ומגדיר את תפקידי ה-IAM ואת חשבונות השירות הנדרשים, כולל איחוד שירותי אימות הזהות של עומסי עבודה ב-GKE.

מידע נוסף על שימוש ב-Terraform זמין במאמר הקצאת משאבי GKE באמצעות Terraform.

הגדרה של kubectl לתקשורת עם האשכול

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

gcloud container clusters get-credentials CLUSTER_NAME \
    --location=${GOOGLE_CLOUD_REGION}

מחליפים את CLUSTER_NAME בשם של אשכול GKE.

יצירת תמונה של הסוכן

אחרי שיוצרים את התשתית באמצעות ה-CLI של gcloud או Terraform, מבצעים את השלבים הבאים כדי ליצור את אפליקציית הסוכן.

  1. נותנים את תפקיד ה-IAM הנדרש ל-Cloud Build: לשירות Cloud Build נדרשות הרשאות כדי להעביר בדחיפה את קובץ האימג' של הסוכן ל-Artifact Registry. נותנים את התפקיד roles/artifactregistry.writer לחשבון השירות שמשמש כברירת המחדל של Compute Engine, שמשמש את Cloud Build.

    1. יוצרים את כתובת האימייל של חשבון השירות של Compute Engine שמוגדר כברירת מחדל:

      export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format="value(projectNumber)")
export COMPUTE_SA_EMAIL=${PROJECT_NUMBER}-compute@developer.gserviceaccount.com

    2. מקצים לחשבון השירות את התפקיד roles/artifactregistry.writer:

      gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member=serviceAccount:${COMPUTE_SA_EMAIL} \
    --role=roles/artifactregistry.writer

  2. יוצרים את קובץ האימג' של הקונטיינר של הסוכן ומעבירים אותו בדחיפה: מתיקיית הבסיס של הפרויקט (adk/llama/vllm), מריצים את הפקודות הבאות כדי ליצור את קובץ האימג' של Docker ולהעביר אותו בדחיפה ל-Artifact Registry.

    export IMAGE_URL="${GOOGLE_CLOUD_REGION}-docker.pkg.dev/${PROJECT_ID}/REPO_NAME/adk-agent:latest"
gcloud builds submit --tag $IMAGE_URL

  3. מוודאים שקובץ האימג' של הקונטיינר הועבר: אחרי שתהליך ה-build מסתיים בהצלחה, מוודאים שקובץ האימג' של הקונטיינר של הסוכן הועבר ל-Artifact Registry. לשם כך, מציגים את רשימת התמונות במאגר.

    gcloud artifacts docker images list ${GOOGLE_CLOUD_REGION}-docker.pkg.dev/${PROJECT_ID}/REPO_NAME

    הפלט אמור לכלול את התמונה שדחפתם ותייגתם כ-latest.

פריסת המודל

אחרי שמגדירים את אשכול GKE ויוצרים את תמונת הסוכן, השלב הבא הוא לפרוס את מודל Llama 3.1 באירוח עצמי באשכול. כדי לעשות את זה, פורסים שרת הסקה (inference) של vLLM שהוגדר מראש, ששולף את המודל מ-Hugging Face ומפרסם אותו באופן פנימי בתוך האשכול.

  1. יצירת סוד של Kubernetes עבור פרטי הכניסה ל-Hugging Face: כדי לאפשר לאשכול GKE להוריד את מודל Llama 3.1 המוגבל, צריך לספק את האסימון של Hugging Face כסוד של Kubernetes. המניפסט של deploy-llm.yaml מוגדר להשתמש בסוד הזה לאימות.

    kubectl create secret generic hf-secret \
    --from-literal=hf-token-secret=HUGGING_FACE_TOKEN

    מחליפים את HUGGING_FACE_TOKEN באסימון שלכם.

  2. צפייה במניפסט: בספריית השורש של הפרויקט (adk/llama/vllm), עוברים לספרייה /deploy-llm שמכילה את מניפסט הפריסה של המודל.

    cd deploy-llm

  3. החלת המניפסט: מריצים את הפקודה הבאה כדי להחיל את המניפסט deploy-llm.yaml על האשכול.

    kubectl apply -f deploy-llm.yaml

    הפקודה יוצרת שלושה משאבי Kubernetes:

    • פריסה שמריצה את שרת vLLM, שמוגדר להשתמש במודל meta-llama/Llama-3.1-8B-Instruct.
    • שירות בשם vllm-llama3-service שחושף את שרת vLLM בכתובת IP של אשכול פנימי, ומאפשר לסוכן ADK לתקשר איתו.
    • ‫ConfigMap שמכיל תבנית צ'אט של Jinja שנדרשת על ידי מודל Llama 3.1.

  4. מאמתים את פריסת המודל: שרת vLLM מושך את קובצי המודל מ-Hugging Face. התהליך הזה יכול להימשך כמה דקות. אפשר לעקוב אחרי הסטטוס של ה-Pod כדי לוודא שהוא מוכן.

    1. ממתינים עד שהפריסה תהיה זמינה.

      kubectl wait --for=condition=available --timeout=600s deployment/vllm-llama3-deployment

    2. בודקים את היומנים מה-Pod הפועל כדי לוודא שהשרת הופעל.

      export LLM_POD=$(kubectl get pods -l app=vllm-llama3 -o jsonpath='{.items[0].metadata.name}')
kubectl logs -f $LLM_POD

      הפריסה מוכנה כשמוצג פלט של יומן דומה לזה שבהמשך, שמציין שהשרת של מודל ה-LLM הופעל ונתיבי ה-API זמינים:

      INFO 07-16 14:15:16 api_server.py:129] Uvicorn running on http://0.0.0.0:8000 (Press CTRL+C to quit)

    3. שליחת בקשה ישירות לשרת המודל כדי לוודא שה-LLM מוכן. כדי לעשות זאת, פותחים טרמינל חדש ב-Cloud Shell ומריצים את הפקודה הבאה כדי להעביר את vllm-llama3-service למחשב המקומי:

      kubectl port-forward service/vllm-llama3-service 8000:8000

    4. בטרמינל אחר, שולחים בקשה לדוגמה לנקודת קצה ל-API של המודל באמצעות curl. לדוגמה:

      curl -X POST http://localhost:8000/v1/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "meta-llama/Llama-3.1-8B-Instruct",
    "prompt": "Hello!",
    "max_tokens": 10
  }'

      אם הפקודה מחזירה תגובת JSON מוצלחת, מודל ה-LLM מוכן. עכשיו אפשר לסיים את תהליך העברת הפורטים. לשם כך, חוזרים לחלון המסוף שלו, לוחצים על Ctrl+C וממשיכים לפריסת הסוכן.

פריסת אפליקציית הסוכן

השלב הבא הוא פריסת אפליקציית הסוכן שמבוססת על ADK.

  1. עוברים לספרייה /deploy-agent: מספריית השורש של הפרויקט (adk/llama/vllm), עוברים לספרייה /deploy-agent שמכילה את קוד המקור של הסוכן ואת מניפסט הפריסה.

    cd ../deploy-agent

  2. עדכון מניפסט הפריסה של הסוכן:

    1. קובץ המניפסט לדוגמה deploy-agent.yaml מכיל פלייסהולדר למזהה הפרויקט בכתובת ה-URL של קובץ אימג' של קונטיינר. צריך להחליף את ה-placeholder במזהה הפרויקט. Google Cloud 

      image: us-central1-docker.pkg.dev/PROJECT_ID/adk-repo/adk-agent:latest

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

      sed -i "s/<PROJECT_ID>/$PROJECT_ID/g" deploy-agent.yaml

    2. מוודאים שהנתיב readinessProbe מוגדר ל-/ ולא ל-/dev-ui. כדי לבצע את ההחלפה במקום, אפשר להריץ את הפקודה הבאה:

      sed -i "s|path: /dev-ui/|path: /|g" deploy-agent.yaml

  3. החלת המניפסט: מריצים את הפקודה הבאה כדי להחיל את המניפסט deploy-agent.yaml על האשכול.

    kubectl apply -f deploy-agent.yaml

    הפקודה הזו יוצרת שני משאבי Kubernetes:

    • פריסת Deployment בשם adk-agent שמריצה קובץ אימג' של קונטיינר של סוכן שנוצר בהתאמה אישית.
    • שירות בשם adk-agent מסוג NodePort שחושף את אפליקציית הסוכן כדי שאפשר יהיה לגשת אליה לצורך בדיקה.

  4. מאמתים את הפריסה של הסוכן: בודקים את הסטטוס של ה-Pod כדי לוודא שהוא פועל בצורה תקינה.

    1. מחכים שהפריסה תהיה זמינה:

      kubectl wait --for=condition=available --timeout=300s deployment/adk-agent

    2. צופים ביומנים מ-Pod של סוכן פעיל:

      export AGENT_POD=$(kubectl get pods -l app=adk-agent -o jsonpath='{.items[0].metadata.name}')
kubectl logs -f $AGENT_POD

הפריסה מצליחה כשרואים פלט של יומן שדומה לזה שבהמשך, שמציין שהשרת Uvicorn פועל ומוכן לקבל בקשות:

INFO:     Uvicorn running on http://0.0.0.0:8001 (Press CTRL+C to quit)

בדיקה של הסוכן הפעיל

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

  1. העברת השירות של הסוכן למחשב המקומי: השירות adk-agent הוא מסוג NodePort, אבל הדרך הכי ישירה לגשת אליו מסביבת מעטפת Cloud Shell היא באמצעות הפקודה kubectl port-forward. כדי ליצור מנהרה מאובטחת ל-Pod של הסוכן, מריצים את הפקודה הבאה.

    kubectl port-forward $AGENT_POD 8001:8001

  2. גישה לממשק המשתמש האינטרנטי של הנציג: ב-Cloud Shell, לוחצים על הלחצן Web Preview (תצוגה מקדימה באינטרנט) ובוחרים באפשרות Preview on port 8001 (תצוגה מקדימה ביציאה 8001). תיפתח כרטיסייה חדשה בדפדפן עם ממשק הצ'אט של נציג התמיכה.

  3. אינטראקציה עם הסוכן: שואלים את הסוכן שאלה שתפעיל את הכלי get_weather שלו. לדוגמה:

    What's the weather like in Tokyo?

    הסוכן יפעיל קודם את ה-LLM כדי להבין את הכוונה ולזהות את הצורך להשתמש בכלי get_weather. לאחר מכן, הכלי יופעל עם הפרמטר Tokyo. לבסוף, הוא ישתמש בפלט של הכלי כדי ליצור תשובה. אמורה להתקבל תגובה שדומה לזו:

      The weather in Tokyo is 25°C and sunny.

  4. (אופציונלי) אימות הקריאה לכלי ביומנים: אפשר לראות את האינטראקציה של הסוכן עם מודל ה-LLM ואת ההרצה של הכלי על ידי צפייה ביומנים של ה-Pods המתאימים.

    1. יומני Agent Pod: בטרמינל חדש, צופים ביומנים של ה-Pod‏ adk-agent. תוכלו לראות את הקריאה לכלי ואת התוצאה שלה.

      kubectl logs -f $AGENT_POD

      בפלט מוצגת קריאה לכלי ועיבוד התוצאה.

    2. יומנים של LLM Pod: אפשר להציג את היומנים של vllm-llama3-deployment Pod כדי לראות את הבקשה הנכנסת מהסוכן.

      kubectl logs -f $LLM_POD

      ביומנים מוצגת ההנחיה המלאה שנשלחה על ידי הסוכן ל-LLM, כולל הודעת המערכת, השאילתה שלכם וההגדרה של כלי get_weather.

אחרי שמסיימים את הבדיקה, אפשר להפסיק את התהליך port-forward על ידי חזרה לחלון המסוף שלו והקשה על Ctrl+C.

הסרת המשאבים

כדי להימנע מחיובים בחשבון Google Cloud בגלל השימוש במשאבים שנעשה במסגרת המדריך הזה, אפשר למחוק את הפרויקט שמכיל את המשאבים, או להשאיר את הפרויקט ולמחוק את המשאבים בנפרד.

מחיקת המשאבים שנפרסו

כדי להימנע מחיובים בחשבון Google Cloud על המשאבים שיצרתם במדריך הזה, מריצים את הפקודות הבאות:

gcloud

אם השתמשתם ב-CLI של gcloud כדי ליצור את המשאבים, מריצים את הפקודות הבאות כדי למחוק את אשכול GKE ואת מאגר Artifact Registry, ולהחזיר את ההרשאות של חשבון השירות למצב המקורי.

gcloud container clusters delete CLUSTER_NAME \
    --location=$GOOGLE_CLOUD_REGION

gcloud artifacts repositories delete REPO_NAME \
    --location=$GOOGLE_CLOUD_REGION

gcloud projects remove-iam-policy-binding $PROJECT_ID \
    --member=serviceAccount:${COMPUTE_SA_EMAIL} \
    --role=roles/artifactregistry.writer

Terraform

אם השתמשתם ב-Terraform כדי להקצות את התשתית, תוכלו להרוס את כל המשאבים על ידי הרצת פקודה אחת מתוך הספרייה /terraform.

  1. מתיקיית השורש של הפרויקט (adk/llama/vllm), עוברים לספרייה /terraform:

    cd terraform

  2. מריצים את הפקודה הזו כדי להסיר את כל המשאבים שהוגדרו בקובצי ההגדרות של Terraform:

    terraform destroy

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

  • כך מגדירים את Horizontal Pod Autoscaler‏ (HPA) כדי להתאים באופן אוטומטי את משאבי הסוכן לפי דרישה.
  • כאן מוסבר איך להגדיר שרת proxy לאימות זהויות (IAP) לאפליקציות האינטרנט שפועלות ב- Google Cloud, כדי לספק הרשאה מרכזית לגישה לממשק המשתמש של הסוכן.
  • איך משתמשים ב-Cloud Logging וב-Cloud Monitoring כדי לקבל תובנות לגבי הביצועים והתקינות של הסוכן באשכול GKE.
  • אתם יכולים לעיין בדוגמאות ניסיוניות ב-GKE AI Labs שיעזרו לכם להשתמש ב-GKE כדי להאיץ את היוזמות שלכם בתחום ה-AI האקטיבי.