במדריך הזה נסביר איך לפרוס ולהפעיל את המודל Qwen3-30B-A3B (Qwen/Qwen3-30B-A3B-FP8), שהוא מודל שילוב מומחים (MoE), ב-Google Kubernetes Engine (GKE). הפריסה משתמשת במאיצי TPU v6e (Trillium) עם כמה מארחים ובמסגרת להצגת מודלים של vLLM TPU עם TorchTPU (torchtpu) ופירוק של מילוי מראש ופענוח (PD).
בהגדרת הפריסה שמתוארת במדריך הזה, אתם מקצים שני מאגרי צמתים של ct6e-standard-4t עם כמה מארחים, שכל אחד מהם מסודר בטופולוגיה של 2x4 (שמונה שבבי TPU v6e בשני צמתים לכל מאגר צמתים, סה"כ 16 שבבי TPU v6e). אתם משתמשים ב-Kubernetes JobSet API וב-Ray כדי:
- מריצים שרתי מילוי מראש ופענוח מרובי-מארחים מפורקים בפרוסות TPU v6e נפרדות, כשמקביליות הנתונים ומקביליות המומחים מופעלות.
- הבקשות מנותבות דרך שרת proxy לביטול צבירת נתונים.
כדי להריץ תהליך עבודה דומה של הצגת מודל vLLM TorchTPU עם כמה מארחים במאיצי TPU7x (Ironwood) עם המודל הגדול יותר Qwen3.5-397B, קראו את המאמר הצגת Qwen3.5-397B ב-GKE עם vLLM TorchTPU עם כמה מארחים במאיצי TPU7x.
מטרות
- מגדירים את אשכול GKE ואת מאגרי הצמתים של TPU v6e עם כמה מארחים.
- מעבירים את משקלי המודל לקטגוריה של Cloud Storage.
- פורסים את שרתי ה-proxy, המילוי מראש והפענוח של vLLM TorchTPU עם מספר מארחים באמצעות JobSet.
- להריץ עומס עבודה להשוואה של הצגת מודעות ולנתח את התוצאות.
- מנקים.
עלויות
במסמך הזה משתמשים ברכיבים הבאים שלGoogle Cloud, והשימוש בהם כרוך בתשלום:
כדי להעריך את העלויות בהתאם לשימוש הצפוי, אתם יכולים להשתמש במחשבון העלויות.
כשמסיימים את המשימות שמתוארות במסמך הזה אפשר למחוק את המשאבים שיצרתם כדי להימנע מחיובים נוספים. מידע נוסף זמין בקטע הסרת המשאבים.
לפני שמתחילים
מגדירים את הסביבה למדריך:
מפעילים את Kubernetes Engine API בפרויקט ב- Google Cloud :
מתקינים ומפעילים את Google Cloud CLI, ומתקינים את
kubectl. אם אתם משתמשים ב-Cloud Shell, שני הכלים מותקנים מראש.מוודאים שבפרויקט יש מספיק מכסת SSD ומכסת כתובות IP חיצוניות באזור שבו נמצאת קיבולת ה-TPU:
במסוף Google Cloud , נכנסים לדף Quotas & System Limits.
מסננים לפי Persistent Disk SSD (GB) ומוודאים שיש מספיק מכסת SSD זמינה באזור היעד.
מסננים לפי In-use regional external IPv4 addresses ומוודאים שיש לכם מספיק מכסה של כתובות IP באזור היעד.
איך מקבלים טוקן גישה ל-Hugging Face
כדי להשתמש במדריך הזה, אתם צריכים טוקן גישה ל-Hugging Face. אפשר להירשם לחשבון בחינם ב-Hugging Face. אחרי שיוצרים חשבון, יוצרים אסימון גישה:
- בדף Welcome to Hugging Face, לוחצים על הדמות של החשבון ובוחרים באפשרות טוקן גישה.
- בדף טוקני גישה, לוחצים על Create new token.
- בוחרים את סוג הטוקן Read ומזינים שם לטוקן.
- טוקן הגישה שלכם יוצג. שומרים את הטוקן במקום בטוח.
התפקידים הנדרשים
כדי לקבל את ההרשאות שדרושות להשלמת המדריך, בקשו מהאדמין להקצות לכם את התפקידים הבאים ב-IAM בפרויקט:
- אדמין ב-Kubernetes Engine (
roles/container.admin) - אדמין ב-Compute (
roles/compute.admin) - אדמין באחסון (
roles/storage.admin) - משתמש בחשבון שירות (
roles/iam.serviceAccountUser)
להסבר על מתן תפקידים, ראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.
יכול להיות שאפשר לקבל את ההרשאות הנדרשות גם באמצעות תפקידים בהתאמה אישית או תפקידים מוגדרים מראש.
הגדרת משתני הסביבה
כדי להגדיר את משתני הסביבה:
מגדירים את האימות:
מייצאים את משתני הסביבה שבהם משתמשים במדריך הזה:
מחליפים את מה שכתוב בשדות הבאים:
-
YOUR_PROJECT_ID: מזהה הפרויקט ב-Google Cloud . -
YOUR_REGION: האזור שבו רוצים לפרוס את האשכול, למשלus-central1. -
YOUR_ZONE: האזור שבו רוצים לפרוס את מאגרי הצמתים של TPU v6e, למשלus-central1-c. -
YOUR_CLUSTER_NAME: השם של אשכול GKE. -
YOUR_RESERVATION_NAME: אם אתם משתמשים בהזמנה, השם של ההזמנה של TPU v6e. -
YOUR_GCS_BUCKET: השם של הקטגוריה של Cloud Storage שבה אתם משתמשים כדי לאחסן נתונים במחסן ביניים (Stage) את משקלי המודל. -
YOUR_HF_TOKEN: טוקן הגישה שלכם ל-Hugging Face.
אם אתם משתמשים בקובץ אימג' של קונטיינר vLLM TorchTPU בהתאמה אישית, החליפו את ה-URI של קובץ האימג' שמוגדר כברירת מחדל (
vllm/vllm-torchtpu) במשתנהVLLM_IMAGEב-URI של קובץ האימג' שלכם. תמונות ציבוריות זמינות במאגר vLLM TorchTPU.-
יצירת אשכול GKE
כדי ליצור אשכול GKE במצב Standard ולצרף שני מאגרי צמתים של TPU v6e עם כמה מארחים להפרדה של מילוי מראש ופענוח, מבצעים את השלבים הבאים:
יוצרים אשכול GKE אזורי עם איחוד זהויות של עומסי עבודה ל-GKE:
הפלט אמור להיראות כך:
NAME LOCATION MASTER_VERSION MASTER_IP MACHINE_TYPE NODE_VERSION NUM_NODES STATUS STACK_TYPE asq-v6e us-central1 1.35.7-gke.1027000 35.226.172.84 e2-standard-4 1.35.7-gke.1027000 3 RUNNING IPV4יוצרים שני מאגרי צמתים של TPU v6e עם כמה מארחים, שכל אחד מהם מכיל שני צמתים של
ct6e-standard-4t(שמונה שבבי TPU v6e בטופולוגיה של2x4לכל מאגר צמתים, ובסך הכול 16 שבבי TPU v6e):במדריך הזה משתמשים בקיבולת של Spot (
--spot). יכול להיות שייקח זמן ליצור מכונות שמשתמשות בקיבולת של Spot אחרי שיוצרים את מאגר הצמתים, ויכול להיות שהן יופקעו במהלך הרצת עומסי העבודה. אפשר גם ליצור את מאגרי הצמתים באמצעות מקום שמור או Flex-start VM, על ידי העברת הדגלים הבאים:Specific reservation: יצירת מאגר הצמתים באמצעות בקשה ספציפית לשמירת מקום:
מידע נוסף על הקצאות של TPU זמין במאמר מידע על הקצאות של Cloud TPU.
Flex-start VMs: הקצאת מאגר הצמתים באמצעות אפשרות הצריכה Flex-start:
מידע נוסף זמין במאמר הרצת עומס עבודה קטן של אצווה באמצעות יחידות TPU ומכונות וירטואליות מסוג Flex-start.
הפלט של כל מאגר צמתים אמור להיראות כך:
NAME MACHINE_TYPE DISK_SIZE_GB NODE_VERSION np-0 ct6e-standard-4t 100 1.35.7-gke.1027000מגדירים את פרטי הכניסה של
kubectlכדי לתקשר עם האשכול:
העברת משקלי המודל ל-Cloud Storage
מכינים את משקלי המודל בקטגוריה של Cloud Storage להרצת עומסי העבודה:
יוצרים קטגוריה של Cloud Storage עם הרשאות גישה אחידות ברמת הקטגוריה:
נותנים הרשאות לניהול זהויות והרשאות גישה (IAM) בקטגוריה לחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine ולחשבון השירות שמוגדר כברירת מחדל ב-Kubernetes:
יוצרים סוד של Kubernetes בשם
hf-secretכדי לאחסן את טוקן הגישה של Hugging Face:מאחזרים את המניפסט של
download_qwen3_30b.yaml:אפשר גם ליצור קובץ בשם
download_qwen3_30b.yamlעם התוכן הבא:מורידים את משקלי המודל של
Qwen/Qwen3-30B-A3B-FP8לנפח ה-staging ומעבירים אותם לקטגוריה של Cloud Storage:השלב הזה נמשך כ-5 עד 10 דקות.
מחכים עד שה-Pod יתחיל ועוקבים אחרי יומני ה-Job של ההורדה:
אחרי שהמשימה מסתיימת, מוודאים שכל 16 החלקים של
.safetensorsנמצאים בקטגוריה של Cloud Storage:מוחקים את משימת ההכנה שהושלמה:
פריסת שרת vLLM TorchTPU עם כמה מארחים
המניפסט של עומס העבודה (v6e_qwen3_server_multihost_slice.yaml) מגדיר משאב JobSet של Kubernetes (vllm-qwen3-30b-pd-disagg-v6e) עם שלוש משימות משוכפלות שמתאמות בין מילוי מראש מבוזר לבין פענוח של הצגת מודעות בשני מאגרי הצמתים של 2x4 TPU v6e:
שרת מילוי מראש (
prefill): מפעיל שתי רפליקות במאגר צמתים אחד של2x4TPU v6e (שני צמתים שלct6e-standard-4tעם ארבעה צ'יפים לכל מארח, סה"כ שמונה ליבות TPU). ה-Pods יוצרים אשכול Ray עם שני צמתים ומפעילים את vLLM TorchTPU ביציאה8000עבורQwen/Qwen3-30B-A3B-FP8. השרת משתמש ב-TPURaidenConnectorשמוגדר כ-kv_producerעם הדגלים הבאים:--data-parallel-size=8--tensor-parallel-size=1--enable-expert-parallel--load-format=runai_streamer
שרת פענוח (
decode): מריץ שתי רפליקות במאגר הצמתים השני של2x4TPU v6e (סה"כ שמונה ליבות TPU). ה-JobSet משתמש בכללי קרבה ואי-קרבה של Pod בתוויתcloud.google.com/gke-nodepoolכדי לבודד את המילוי מראש והפענוח למאגרי צמתים נפרדים. ה-Pods יוצרים אשכול Ray עם שני צמתים ומפעילים את vLLM TorchTPU ביציאה7200, כאשרTPURaidenConnectorמוגדר כ-kv_consumer.שרת proxy להפרדה (
proxy): מריץ את הסקריפטtoy_proxy_server.pyביציאה10000כדי לתאם את ניתוב הבקשות ואת העברת המטמון של KV בין שרת המילוי מראש (יציאה8000) לבין שרת הפענוח (יציאה7200).
כדי לפרוס את שרתי ה-vLLM המבוזרים ולעקוב אחריהם:
מתקינים באשכול את ה-CustomResourceDefinition והבקר של Kubernetes JobSet:
אחזור המניפסט של השרת:
אפשר גם ליצור קובץ בשם
v6e_qwen3_server_multihost_slice.yamlעם התוכן הבא:מחליפים את שם הקטגוריה של Cloud Storage ואת קובץ האימג' של הקונטיינר בקובץ
v6e_qwen3_server_multihost_slice.yaml, ומחילים את המניפסט:ההגדרה הזו משתמשת בפרוסה אחת של
2x4TPU v6e (שני צמתים) למילוי מראש ובפרוסה אחת של2x4TPU v6e (שני צמתים) לפענוח. כדי לשנות את מספר הצמתים בכל אחד מהמאגרים, מעדכנים את השדהreplicas(replicas: NUM_NODES). מחליפים אתNUM_NODESבמספר הצמתים שרוצים להשתמש בהם.עוקבים אחרי יומני ה-Pod של המילוי מראש והפענוח עד שהאפליקציה מסיימת את ההפעלה:
הטעינה וההידור הראשוניים של המודל נמשכים כ-15 עד 25 דקות בהפעלה הראשונה.
אם אתם משתמשים בקיבולת שניתנת להפסקה לפני הזמן, כמו קיבולת של Spot או מכונות וירטואליות מסוג Flex-start, יכול להיות שייקח יותר זמן ליצור את הצמתים של פרוסות ה-TPU אחרי שתיצרו את מאגר הצמתים, ויכול להיות שהם יופסקו לפני הזמן במהלך הרצת עומסי העבודה. מידע נוסף מופיע במאמר מכונות VM זמניות. כדי לבדוק אם נוצרו צומתי פרוסות ה-TPU, עיינו בקטע בדיקת הסטטוס והתנאים של הצומת.
לפני שמריצים את עומס העבודה להשוואה, מחכים עד שביומני השרת של המילוי מראש והפענוח מדווח הערך
Application startup complete:(APIServer pid=1) INFO: Started server process [1] (APIServer pid=1) INFO: Waiting for application startup. (APIServer pid=1) INFO: Application startup complete.
הרצת עומס עבודה להערכת ביצועים
כדי להשוות בין מודל Qwen3-30B-A3B שנפרס באמצעות עומס עבודה של קלט של 8,192 טוקנים ופלט של 1,024 טוקנים (8k/1k) לבין שרת ה-proxy להפרדה, מבצעים את השלבים הבאים:
אחזור המניפסט של הערכת הביצועים:
אפשר גם ליצור קובץ בשם
v6e_qwen3_benchmark_multihost_slice.yamlעם התוכן הבא:מפעילים את המניפסט של משימת ההשוואה לשוק:
מחכים שה-Pod של נקודת ההשוואה יהיה מוכן, ועוקבים אחרי היומנים של משימת נקודת ההשוואה:
אחרי שהבדיקה מסתיימת, מחפשים פלט שמכיל מדדים כמו:
Output token throughputTotal token throughputTTFTTPOT
הסרת המשאבים
כדי להימנע מחיובים בחשבון Google Cloud על המשאבים שבהם השתמשתם במדריך הזה, אתם צריכים למחוק את עומסי העבודה ב-Kubernetes, את מאגרי הצמתים של TPU v6e, את אשכול GKE ואת הקטגוריה של Cloud Storage:
מוחקים את עומסי העבודה של Kubernetes:
מוחקים את מאגרי הצמתים של TPU v6e ואת אשכול GKE:
מוחקים את הקטגוריה של Cloud Storage שבה מאוחסנים משקלי המודל שהועלו. אם רוצים לשמור את משקלי המודל, מדלגים על השלב הזה או מעתיקים אותם למיקום הרצוי: