במדריך הזה מוסבר איך לפרוס ולהציג את Qwen3.8-2.4T (nvidia/Qwen3.8-2.4T-A95B-NVFP4), מודל שילוב מומחים (MoE) עם 2.4 טריליון פרמטרים ו-95 מיליארד פרמטרים פעילים שעברו קוונטיזציה ל-NVFP4, ב-Google Kubernetes Engine (GKE) ב-Google Cloud. הפריסה משתמשת ב-Cluster Toolkit, בארבע מכונות וירטואליות (VM) מסוג A4 (a4-highgpu-8g) עם מספר מארחים ו-32 מעבדי GPU מסוג NVIDIA B200, ב-NVIDIA Dynamo ובמסגרת להצגת מודעות SGLang עם הפרדה של מילוי מראש ופענוח (PD).
בהגדרת הפריסה שמתוארת במדריך הזה, משתמשים ב-Cluster Toolkit כדי להקצות אשכול GKE במצב Standard. האשכול מכיל ארבעה צומתי a4-highgpu-8g שמחוברים באמצעות רשת GPUDirect Remote Direct Memory Access (RDMA). אחרי זה מתקינים את KAI Scheduler ואת פלטפורמת NVIDIA Dynamo עם Grove gang scheduling, ומעבירים את משקלי המודל ל-Cloud Storage. בשלב הבא, פורסים משאב מותאם אישית של DynamoGraphDeployment שמחבר את הקטגוריה באמצעות Cloud Storage FUSE ומפריד בין המילוי מראש לבין הפענוח בשני מאגרי Worker עם מספר מארחים ו-16 יחידות GPU, עם מקביליות של טנזורים, מקביליות של מומחים ומטמון KV של FP8.
מטרות
- מתקינים את Cluster Toolkit ומקצים אשכול GKE עם כמה מארחים מסוג A4 במצב רגיל.
- מתקינים באשכול את פלטפורמת KAI Scheduler ו-NVIDIA Dynamo עם תזמון Grove gang.
- מעבירים את משקלי המודל Qwen3.8-2.4T לקטגוריה של Cloud Storage.
- פריסת שרת להסקת מסקנות של SGLang עם כמה מארחים ו-PD מבוזר בארבעה צומתי A4, עם 32 מעבדי GPU מסוג NVIDIA B200 בסך הכול.
- שליחת בקשה להשלמת צ'אט לנתב החזיתי של Dynamo.
- מריצים עומס עבודה להערכת ביצועים של מילוי בקשות.
- מחיקת המשאבים שנפרסו.
עלויות
במסמך הזה משתמשים ברכיבים הבאים שלGoogle Cloud, והשימוש בהם כרוך בתשלום:
כדי להעריך את העלויות בהתאם לשימוש הצפוי, אתם יכולים להשתמש במחשבון העלויות.
לפני שמתחילים
מגדירים את הסביבה למדריך:
- מתקינים ומאתחלים את Google Cloud CLI, ומתקינים את
kubectlואת Helm (גרסה 3.10 ואילך). אם אתם משתמשים ב-Cloud Shell, הכלים האלה מותקנים מראש. - אם אתם מריצים את המדריך הזה מתחנת עבודה של Linux או macOS ולא מ-Cloud Shell, תצטרכו להתקין את יחסי התלות הנדרשים של Cluster Toolkit, כמו Terraform ו-Git.
מפעילים את ממשקי ה-API הבאים בפרויקט ב- Google Cloud : Kubernetes Engine API, Compute Engine API, Cloud Storage API, ניהול זהויות והרשאות גישה (IAM) API, Cloud Resource Manager API ו-Service Usage API.
איך מקבלים טוקן גישה ל-Hugging Face
כדי להשתמש במדריך הזה, צריך טוקן גישה ל-Hugging Face. אפשר להירשם לחשבון בחינם ב-Hugging Face. אחרי שיוצרים חשבון, יוצרים אסימון גישה:
- בדף Welcome to Hugging Face, לוחצים על הדמות של החשבון ובוחרים באפשרות טוקן גישה.
- בדף טוקני גישה, לוחצים על יצירת טוקן חדש.
- בוחרים את סוג הטוקן Read ומזינים שם לטוקן.
- טוקן הגישה שלכם יוצג. שומרים את הטוקן במקום בטוח.
התפקידים הנדרשים
כדי לקבל את ההרשאות שדרושות להשלמת המדריך, בקשו מהאדמין להקצות לכם את התפקידים הבאים ב-IAM בפרויקט:
- אדמין ב-Kubernetes Engine (
roles/container.admin) - אדמין ב-Compute (
roles/compute.admin) - אדמין באחסון (
roles/storage.admin) - אדמין IAM בפרויקט (
roles/resourcemanager.projectIamAdmin) - אדמין בחשבון שירות (
roles/iam.serviceAccountAdmin) - משתמש בחשבון שירות (
roles/iam.serviceAccountUser) - Service Usage Consumer (
roles/serviceusage.serviceUsageConsumer)
להסבר על מתן תפקידים, ראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.
יכול להיות שאפשר לקבל את ההרשאות הנדרשות גם באמצעות תפקידים בהתאמה אישית או תפקידים מוגדרים מראש.
הגדרת משתני הסביבה
מייצאים את משתני הסביבה שבהם משתמשים במדריך הזה:
מחליפים את מה שכתוב בשדות הבאים:
-
YOUR_PROJECT_ID: מזהה הפרויקט ב- Google Cloud. -
YOUR_REGION: האזור שבו נמצאת הקיבולת של A4 ושבו רוצים לפרוס את האשכול, למשלus-central1. -
YOUR_ZONE: האזור שבו נמצאת הקיבולת של A4, למשלus-central1-b. -
YOUR_CLUSTER_NAME: השם של אשכול GKE ושל פריסת Cluster Toolkit. השתמשו בשם באורך של עד 20 תווים, כדי שמזהה חשבון השירות של מאגר הצמתים שנוצר (YOUR_CLUSTER_NAME-gke-np-sa) לא יחרוג מהמגבלה של 30 תווים בניהול הזהויות והרשאות הגישה (IAM). -
YOUR_RESERVATION_NAME: השם של ההזמנה שלכם ל-A4, או הנתיב של בלוק ההזמנה המורחב בפורמטRESERVATION_NAME/reservationBlocks/RESERVATION_BLOCK_NAME. -
YOUR_BUCKET_NAME: שם ייחודי גלובלי לקטגוריה של Cloud Storage שבה מאוחסנים המצב של Terraform ל-Cluster Toolkit ומשקלי המודל של Qwen3.8-2.4T בשלב הביניים. -
YOUR_HF_TOKEN: טוקן הגישה שלכם ל-Hugging Face.
יצירת אשכול GKE
מורידים את Cluster Toolkit ומקצים אשכול GKE במצב רגיל עם ארבעה צומתי a4-highgpu-8g, רשת GPUDirect RDMA ותמיכה ב-DRA:
נכנסים ל-Google Cloud CLI ויוצרים Application Default Credentials ל-Terraform:
מורידים ומחלצים את חבילת Cluster Toolkit שנוצרה מראש לגרסה שצוינה ב-
CLUSTER_TOOLKIT_VERSION(v1.104.0):אם אתם מריצים את הפקודה הזו ב-macOS או בתחנת עבודה של
arm64, צריך להגדיר אתOS="mac"או אתARCH="arm64"בהתאם לפלטפורמה.כדי לאחסן את המצב של Terraform לפריסה של Cluster Toolkit ואת משקלי המודל בשלבים, יוצרים קטגוריה של Cloud Storage באותו אזור של המקום השמור של A4, עם הרשאות גישה מאוחדות ברמת הקטגוריה (UBLA) וניהול גרסאות של אובייקטים:
יוצרים את קובץ התצורה של הפריסה
cluster-toolkit/examples/gke-a4/gke-a4-deployment.yamlלארבעה צומתיa4-highgpu-8g:כברירת מחדל, קובץ הפריסה מוגדר לצרוך הזמנה ספציפית. אם אין לכם מקום שמור ספציפי, לפני פריסת האשכול אתם יכולים לעדכן את
cluster-toolkit/examples/gke-a4/gke-a4-deployment.yamlכדי להשתמש באפשרות צריכה חלופית, כמו VM במודל Spot או Flex-start VM. הוראות להגדרה מופיעות במאמר אפשרויות צריכה של GKE.עוברים לספרייה
cluster-toolkit, פורסים את אשכול GKE באמצעות הפקודהgcluster deployוחוזרים לספריית העבודה:יצירת האשכול נמשכת כ-20 עד 30 דקות. אם מריצים את
./gcluster deployבלי הדגל--auto-approve, כדי להחיל את השינויים המוצעים צריך להזיןaכשמוצגת בקשה לעשות זאת.מגדירים את פרטי הכניסה של
kubectlכדי לתקשר עם האשכול:
התקנת KAI Scheduler ו-NVIDIA Dynamo
מכינים את האשכול על ידי יצירת סוד של Hugging Face והתקנת KAI Scheduler ופלטפורמת NVIDIA Dynamo עם תזמון קבוצתי של Grove:
יוצרים סוד של Kubernetes בשם
hf-secretכדי לאחסן את טוקן הגישה של Hugging Face:מורידים את תרשים ה-Helm של פלטפורמת NVIDIA Dynamo (
v1.5.0), מתקינים את KAI Scheduler ומתקינים את פלטפורמת Dynamo עם Grove:
העברת משקלי המודל ל-Cloud Storage
מעבירים את נקודת הבדיקה של nvidia/Qwen3.8-2.4T-A95B-NVFP4 לקטגוריה של Cloud Storage באזור (gs://${GCS_BUCKET}), כדי ש-Pods של ה-worker להסקת מסקנות יוכלו לטעון את המשקלים באמצעות Cloud Storage FUSE במקום להוריד אותם מ-Hugging Face בכל הפעלה קרה:
מקצים את התפקיד Storage Object User (
roles/storage.objectUser) בקטגוריהgs://${GCS_BUCKET}שיצרתם ביצירת אשכול GKE לחשבון השירות של Google שמקושר לחשבון השירותworkload-identity-k8s-saשל Kubernetes:מורידים את המניפסטים של
qwen3.8-2.4t-nvfp4-stage-weights-job.yamlו-qwen3.8-2.4t-nvfp4-multihost-a4-gcsfuse.yaml:אפשר גם ליצור קובץ בשם
qwen3.8-2.4t-nvfp4-stage-weights-job.yamlעם התוכן הבא. ה-Indexed Job הזה מריץ ארבעה Pods במקביל בארבעת צומתי ה-A4. כל Pod מוריד חלק בגודל מאוזן של נקודת הבדיקה שלnvidia/Qwen3.8-2.4T-A95B-NVFP4ל-NVMe SSD המקומי של הצומת, ומעלה אותו ל-gs://${GCS_BUCKET}/hf_models/models--nvidia--qwen3_8-2_4t-a95b-nvfp4באמצעותgcloud storage rsync:מחליפים את שם הקטגוריה של Cloud Storage ב-
qwen3.8-2.4t-nvfp4-stage-weights-job.yaml, מפעילים את משימת ה-staging, מחכים שכל ארבעת ה-Pods יסיימו להעלות את המשקלים ואז מוחקים את המשימה שהושלמה:הורדת משקלי המודל ל-SSD מקומי של NVMe והעלאה שלהם ל-Cloud Storage נמשכת כ-25 דקות.
אופציונלי: בזמן שה-Job של ה-Staging פועל, אפשר להעביר בסטרימינג את היומנים של Pod של Staging בסשן טרמינל שני כדי לעקוב אחרי התקדמות ההורדה:
מחליפים את
YOUR_POD_NAMEבשם של אחד מהפודים שלqwen3-8-2-4t-stage-weightsמ-kubectl get pods.
פריסת שרת SGLang מבוזר עם כמה מארחים
המניפסט של עומס העבודה (qwen3.8-2.4t-nvfp4-multihost-a4-gcsfuse.yaml) מגדיר את Kubernetes ResourceClaimTemplate (all-mrdma), שמקצה את מכשירי ה-RDMA עם multi-NIC של הצומת (mrdma.google.com) דרך DRA, משאבי Role ו-RoleBinding לחשבון השירות workload-identity-k8s-sa, ו-NVIDIA Dynamo DynamoGraphDeployment (qwen3-8-2-4t-a4-disagg) עם תזמון קבוצתי של Grove מופעל. הפריסה כוללת את הרכיבים הבאים:
רכיב קצה קדמי (
Frontend): מריץ רפליקה אחת של נתב שמקבלת בקשות מהלקוח, מגלה את ה-workers הרשומים למילוי מראש ולפענוח, ומתאמת את הניתוב של הבקשות המפורקות.Prefill worker (
Prefill): מפעיל מאגר של שני צומתי וורקרים בשני צומתיa4-highgpu-8gעם 16 מעבדי NVIDIA B200 GPU בסך הכול. כל Pod טוען את המשקולות שלnvidia/Qwen3.8-2.4T-A95B-NVFP4שהועלו לקטגוריה של Cloud Storage ב-/model-weightsבאמצעות מנהל ההתקן של ה-CSI של Cloud Storage FUSE (gcsfuse.csi.storage.gke.io) עם מטמון קבצים מקומי של NVMe SSD, מקורות לסביבת NCCL/gIB ומפעיל אתpython3 -m dynamo.sglangב---disaggregation-mode prefillעם הדגלים הבאים:--served-model-name "nvidia/Qwen3.8-2.4T-A95B-NVFP4"--tensor-parallel-size 16--ep-size 16--nnodes 2--moe-runner-backend flashinfer_trtllm--attention-backend triton--kv-cache-dtype fp8_e4m3--disable-flashinfer-autotune
Decode worker (
Decode): מריץ מאגר של שני צומתי וורקר בשני הצמתים הנותרים שלa4-highgpu-8g, עם 16 מעבדי NVIDIA B200 GPU בסך הכול. כל Pod טוען את משקולות המודל שהועלו מ-Cloud Storage ב-/model-weightsדרך מנהל התקן ה-CSI של Cloud Storage FUSE, ומפעיל אתpython3 -m dynamo.sglangב---disaggregation-mode decodeעם הדגלים הבאים:--served-model-name "nvidia/Qwen3.8-2.4T-A95B-NVFP4"--tensor-parallel-size 16--ep-size 16--nnodes 2--moe-runner-backend flashinfer_trtllm--attention-backend triton--kv-cache-dtype fp8_e4m3
פורסים את שרת ההסקה המבוזר ועוקבים אחריו:
בודקים את מניפסט עומס העבודה
qwen3.8-2.4t-nvfp4-multihost-a4-gcsfuse.yamlשהורדתם קודם, או יוצרים קובץ בשםqwen3.8-2.4t-nvfp4-multihost-a4-gcsfuse.yamlעם התוכן הבא:מחליפים את שם הקטגוריה של Cloud Storage ב-
qwen3.8-2.4t-nvfp4-multihost-a4-gcsfuse.yamlומחילים את המניפסט של עומס העבודה על האשכול:כדי לעקוב אחרי טעינת המשקלים והאתחול של השרת, מציגים את ה-Pods באשכול ומעבירים בסטרימינג את היומנים של ה-Pod הראשי למילוי מראש ושל ה-Pod הראשי לפענוח:
מחליפים את
YOUR_POD_NAMEבשם של pod המילוי מראש הראשי או pod הפענוח הראשי מהפלט שלkubectl get pods.בהפעלה קרה, נדרשות כ-4 עד 5 דקות כדי להעביר בסטרימינג את משקלי המודל של 2,400,000,000,000 NVFP4 (כ-1.44TB ב-200 פיצולים) מ-Cloud Storage דרך Cloud Storage FUSE, ולהפעיל את שרתי SGLang עם כמה מארחים. לפני ששולחים בקשות, צריך לחכות עד שיופיע הערך
1/1ב-Pods של ממשק המשתמש, והערך2/2ב-Pods של המילוי מראש והפענוח בעמודהREADYשלkubectl get pods:NAME READY STATUS RESTARTS AGE qwen3-8-2-4t-a4-disagg-0-decode-0-decode-ldr-wz92h 2/2 Running 0 5m qwen3-8-2-4t-a4-disagg-0-decode-0-decode-wkr-fb8g6 2/2 Running 0 5m qwen3-8-2-4t-a4-disagg-0-frontend-jrx4s 1/1 Running 0 5m qwen3-8-2-4t-a4-disagg-0-prefill-0-prefill-ldr-7nz25 2/2 Running 0 5m qwen3-8-2-4t-a4-disagg-0-prefill-0-prefill-wkr-7d5cw 2/2 Running 0 5m
שליחת בקשות להסקת מסקנות
שולחים בקשה להשלמת צ'אט לשירות Qwen3.8-2.4T שנפרס:
מעבירים את היציאה המקומית
8000לשירותqwen3-8-2-4t-a4-disagg-frontend:משאירים את העברה ליציאה אחרת פועלת בסשן הטרמינל הזה, או מריצים את הפקודה ברקע.
בסשן שני של הטרמינל, שולחים בקשה להשלמת צ'אט לנקודת הקצה (endpoint) של
/v1/chat/completions:
הרצת עומס עבודה להערכת ביצועים
מריצים את sglang.bench_serving עם הגדרה של 1,024 אסימוני קלט, 1,024 אסימוני פלט (1k/1k), 256 הנחיות ו-128 בקשות בו-זמניות לכל היותר, כדי לבדוק את הביצועים של שרת Qwen3.8-2.4T שנפרס מ-Dynamo frontend Pod:
אחרי שהבדיקה מסתיימת, מחפשים פלט שמכיל מדדים כמו:
Output token throughputTotal Token throughputTTFTTPOT
הסרת המשאבים
כדי להימנע מחיובים שוטפים נוספים בחשבון Google Cloud על המשאבים שבהם השתמשתם במדריך הזה, אתם צריכים למחוק את עומסי העבודה ב-Kubernetes, את אשכול GKE ואת הקטגוריה של Cloud Storage:
מוחקים את המשאבים DynamoGraphDeployment ו-ResourceClaimTemplate:
מסירים את גרסאות ה-Helm של פלטפורמת NVIDIA Dynamo ושל KAI Scheduler:
מוחקים את הסוד של Hugging Face ב-Kubernetes:
בספרייה
cluster-toolkit, משמידים את אשכול GKE ואת התשתית שמשויכת אליו באמצעות הפקודהgcluster destroy:מוחקים את הקטגוריה של Cloud Storage שבה מאוחסנים משקלי המודל שהועברו ל-Staging ומצב Terraform:
gcloud storage rm --recursive "gs://${GCS_BUCKET}"