אירוח Qwen על גבי Blackwell
כיצד אנו מפעילים את Qwen3 235B על מארזי NVIDIA GB200 NVL72, חותכים את עלות ההסקה תוך שמירה על דיוק המודל.
מארזי NVIDIA GB200 NVL72 עם מעבדי GPU מסוג NVIDIA Blackwell המקושרים באמצעות NVLink בעל 72 ערוצים מתאימים באופן ייחודי לפריסת מודלים גדולים של תערובת מומחים (MoE). בפוסט זה בבלוג, אנו מתארים את הגדרת ההסקה המשרתת את מודלי Qwen3 235B המאומנים לאחר אימון (post-trained) התומכים בחלק מתעבורת הנתונים של Perplexity. אנו מציגים כיצד התאמנו את מנוע ההסקה הפנימי שלנו כדי לנצל את ליבות הטנסור המתקדמות ואת הקישוריות המהירה של מעבדי ה-GPU מסוג NVIDIA Blackwell. בעזרת חומרה זו, אנו מטפלים ביותר תעבורה בעלות נמוכה יותר מבלי להתפשר על דיוק המודלים הבסיסיים.
פריסה על גבי GB200 NVL72
מארזי GB200 NVL72 מורכבים מ-18 צמתים הכוללים 2 מעבדי NVIDIA Grace מבוססי ARM ו-4 מעבדי GPU מבוססי Blackwell, כאשר כל אחד מהם מצויד ב-180GB של HBM. 72 מעבדי ה-GPU מקושרים באמצעות NVLink ו-18 רכיבי ASIC של מתגי NVLink, המספקים רוחב פס של 1800 GB/s בין כל שני צמתים וממלאים זיכרון מספיק לאירוח מודלים בעלי טריליון פרמטרים. בנוסף, מתאמי ConnectX-7 InfiniBand מספקים רוחב פס נוסף של 400 Gb/s הן בתוך צמתי המארז והן בין מארזים סמוכים.
כדי להתמודד עם התעבורה, בחרנו לבצע אימון המשך (post-train) ולהפעיל מודלי Qwen. בפוסט זה בבלוג, אנו מתמקדים ב-Qwen3 235B, אך טכניקות ההפעלה ומאפייני הביצועים הרבים הנדונים דומים לאלו של מודלי Qwen3.5 397B ו-122B החדשים שאליהם אנו עוברים. מבחינת מקביליות, קשב ליניארי (linear attention) דומה לקשב עצמי מלא (full self attention), וניתן להתאים בקלות את יישום שכבת ה-MoE הקיימת כדי להכיל את תנאי השער החדשים. כדי לשמור על קצב פענוח עקבי תוך מקסימום התפוקה (throughput), בחרנו להפריד את שלב הטעינה המקדימה (prefill) משלב הפענוח (decode), תוך פריסת אסטרטגיות מקביליות שונות עבור שני סוגי הצמתים. התקשורת בין מעבד הטעינה המקדימה לפענוח מתבצעת על גבי InfiniBand, בעוד שרוחב הפס של NVLink שמור לתקשורת בתוך מעבדי הטעינה המקדימה והפענוח. מאפייני הביצועים של התקני Blackwell בעת ביצוע כפל מטריצות ותקשורת בין-התקנית, הנחקרים בפוסט זה בבלוג, קובעים את אסטרטגיות החלוקה (sharding) שבהן נעשה שימוש. בהשוואה למעבדי GPU מסוג NVIDIA Hopper, אנו רואים שיפורים מליבה לליבה הודות למספר גבוה יותר של מעבדים רב-ערוציים זורמים (streaming multiprocessors), רוחב פס מוגדל בזיכרון והשהיות נמוכות יותר בין עמיתים (peer-to-peer).
מנוע ה-TransferEngine שלנו, המיישם טעינה מקדימה מופרדת, טיפל בחלוקה שרירותית ואולי לא תואמת בין מעבדי הטעינה המקדימה והפענוח. מטמוני ה-KV מסודרים בזיכרון בסדר HND, כאשר הראשיים בממד המוביל והאסימונים (tokens) נשמרים רציפים, כדי לאפשר למטמון KV מפורק במעבד טעינה מקדימה להתפצל עוד יותר או להתחבר מחדש תוך כדי תנועה במהלך ההעברה לצומת הפענוח.
מעבדי טעינה מקדימה (Prefillers)
צמתי הטעינה המקדימה מקבלים את אסימוני הקלט של בקשה, ממלאים את מטמוני ה-KV ומעבירים אותם למעבדי הפענוח כדי להמשיך ביצירת הטקסט. שלב הטעינה המקדימה דורש חישוב רב, שכן אלפי אסימונים השייכים לרצף מעובדים בו-זמנית.
כתוצאה מכך, מצאנו כי פריסה מקבילית מסוג tensor parallel מתאימה, כאשר המודל מחולק ל־4 GPUs בתוך צומת GB200 יחיד, וההקרנות והמומחים מחולקים (TP=4, EP=4). מאחר שגם attention וגם MLPs מוגבלים על ידי חישוב, שניהם נהנים ממקביליות, כאשר המומחים וראשי ה־attention מופצים בין ranks נפרדים. מקביליות נוספת הייתה מניבה תשואה פוחתת, שכן השיפור בתפוקה מהפעלת פחות מומחים בכל rank (16 לעומת 32) לא היה מפצה על העלות הנוספת של all-reduce בעל 8 כיוונים ועל התקורה של פיצול הקוד בצד המארח בין שני צמתים, דבר שהיה דורש תקשורת דרך Ethernet.
ל־Qwen3 235B יש רק 4 heads של key-value, ולכן נדרשת שכפול של ההקרנות k ו־v על פני זוגות של ranks אם משתמשים ב־8 התקנים. היינו יכולים לשקול sharding אגרסיבי יותר כדי להפחית את כמות הזיכרון הנדרשת לאחסון המשקולות בכל rank, ובכך לפנות מקום ליותר tokens ב־KV cache. עם זאת, מצאנו שפריסה רחבה יותר אינה משתלמת.
בהנחה שאורך הקלט הוא סביב 6000 אסימונים, לכל אחד מ-128 המומחים יש סביב 6000 * 8 / 128 = 375 אסימונים המנותבים אליו, מה שמבטיח בעיה צפופה עבור חישובי MoE GEMM. מכיוון שזה כבר ממצה את תפוקת החישוב של ההתקן, מקביליות נתונים אינה נדרשת לשלב הטעינה המקדימה.
למרות העלות הגדלה בריבוע של מנגנון הקשב, מעבדי הטעינה המקדימה מספקים תפוקה עקבית, המאפשרת הערכה גסה של מספר אסימוני הקלט שניתן לעבד על ידי צומת בשנייה. בהסתמך על מדדים העוקבים אחר המספר הכולל של אסימוני קלט מבקשות, ניתן להגדיל את מספר צמתי הטעינה המקדימה כדי להבטיח שתפוקת הטעינה המקדימה הכוללת מותאמת בהתאם. על מנת להימנע מתורים, מספר העותקים של מעבדי הטעינה המקדימה מותאם למספר הכולל של אסימוני הקלט המתקבלים.
מעבדי פענוח (Decoders)
צמתי הפענוח מקבלים את מטמוני ה-KV ממעבדי הטעינה המקדימה ומייצרים אסימונים אחד-אחד. פענוח מוגבל בדרך כלל על ידי הזיכרון: עם מעט אסימוני קלט, כפל מטריצות מוגבל לחלוטין על ידי עלות טעינת המשקלים מ-HBM לתוך ליבות הטנסור. מלבד שימוש באסטרטגיית חלוקה שונה, יש להתאים מספר גרעינים (kernels) כדי למקבל טוב יותר חישובים וגישות לזיכרון.
בניגוד ל־prefill, sharding של attention כבר אינו מועיל: פיצול ראשי attention על פני כמה התקנים היה משמעו שיש פחות הזדמנויות למקביליות בתוך התקן יחיד. כתוצאה מכך, נעשה שימוש רק ב־data parallelism וב־expert parallelism: המומחים מחולקים על פני כמה התקנים, אך כל התקן מנהל את KV caches ואת הבקשות שלו. ללא tensor parallelism, גודל ה־KV cache לכל token בהתקן גדול יותר. עם זאת, מתפנה מקום בזיכרון על ידי הצבת פחות מומחים על צומת יחיד. בניגוד ל־Hopper, שבו הגבלנו tensor parallelism בתוך תחום NVLink יחיד בצומת של 8 GPUs, ב־Blackwell מצאנו שהרחבה על פני כמה צמתים בתוך תחום, תוך שימוש בעד 16 התקנים, מועילה.
על מנת למקסם את התפוקה, מעבדי הפענוח מעבדים מספר גדול יותר של בקשות בו-זמנית. אף על פי שקשות נוספות גוררות עלות נלווה מינימלית בשכבות MoE ובהיטלים אחרים, הן אכן מגדילות באופן לא פרופורציונלי את עלות מנגנון הקשב. כדי לשמור על מהירות פענוח מינימלית סבירה, מספר צמתי הפענוח מותאם כך שגדלי האצווה (batch sizes) לכל מעבד פענוח יישארו מתחת לסף מסוים.
בדומה לפריסות Hopper קודמות, אנו משתמשים בפענוח ספקולטיבי (speculative decoding) עם שכבות MTP שעברו אימון פנימי כדי להגביר את קצבי הפענוח. למרבה המזל, חומרה בסיסית ומסגרות תכנות דומות מספיק כדי לשתף במלואו את היישום בין שתי הארכיטקטורות.
תקשורת תוך-צמתית ובין-צמתית (Intra-node and Inter-node Communication)
ההבדל העיקרי בין GB200 NVL72 לצמתי Hopper קודמים הוא תחום ה-NVLink הגדול, המאפשר תקשורת עמית-לעמית מעבר לגבול הקודם של 8 התקנים. אף על פי שהתקני Blackwell נפרסו בצמתי 8-GPU, יש ערך רב בהתרחבות על פני צמתים מרובים מעל NVLink בהשוואה לרשת InfiniBand האיטית יותר.
בצמתי הטעינה המקדימה, אנו מסתמכים על תקשורת all-reduce בתוך שכבות הקשב ועל הפחתה מקבילית של מומחים הדומה מאוד ל-all-reduce. על פני 4 מעבדי GPU, אנו מנצלים גם את NVLink וגם את NVIDIA SHARP (פרוטוקול צבירה והפחתה היררכי ניתן להרחבה): בנוסף לרוחב הפס של עמית-לעמית, אנו מנצלים גם הפחתות במתגי NVLink כדי להקטין עוד יותר את ההשהיות וליישם שידורים מהירים (broadcasts). בצמתי הפענוח, נעשה שימוש ביישום מותאם אישית של הפצה ושילוב (dispatch and combine) מסוג all-to-all מעל NVLink. הגרעינים הוטמעו באופן פנימי באמצעות מיפויים של CuTeDSL ו-cuMem או מיפויי multicast.
All-Reduce
מעבדי הטעינה המקדימה מבצעים פעולת all-reduce בהיטל הפלט של שכבת הקשב, ומסכמים את התרומות של הראשיים המקוצצים (sharded) על פני הדרגות המשתתפות. מקביליות טנסור יעילה רק כאשר עלות ההוצאה הנלווית של all-reduce מקוזזת על ידי השהייה מוקטנת של בעיות כפל מטריצות קטנות יותר. הנחה זו תקפה בדרך כלל עבור טעינה מקדימה.
במערכות ברמת מרכז נתונים מסוג NVIDIA HGX H200 ו-GB200 NVL72, מעבדי GPU מחוברים בדרך כלל באמצעות מתגי NVLink. מלבד ניתוב, המתקים יכולים לבצע פעולות הפחתה על פני התקנים מחוברים באמצעות SHARP. לאחר יצירת מיפויי זיכרון ורישום שלהם לקבוצת multicast באמצעות ממשקי ה-API של CUDA, גרעינים יכולים להשתמש ב-multicast.ld_reduce וב-multicast.st כדי לצבור ולשדר ערכים דרך המתגים. על מנת ליצור בסיס ורכיבים לשימוש חוזר שניתן לשלב בגרעינים אחרים, אנו מתחזקים פנימית גרעין all-reduce מסוג CuTeDSL באמצעות פרימיטיבים אלו.
במערכת עם N מעבדי GPU המבצעים הפחתה על B בתים, יישום פשוט יכלול עמית שטוען ערכים מכל שאר העמיתים, עבור סך כולל של N * (N - 1) * B בתים של תעבורת קריאה. יישום יעיל יותר יחלק את הנתונים שעוברים הפחתה על פני עמיתים, כאשר כל אחד מפחית מקטע של הקלט, ואז משדר אותו לשאר. הדבר מוביל ל-(N - 1) * (B / N) בתים הנקראים לעמית ומשודרים לשאר, עבור סך כולל של (N - 1) * B * 2 קריאות וכתיבות, מה שמפחית את התעבורה מעל המתגים.
באמצעות SHARP, ניתן לבצע את ההפחתה והשידור ביעילות רבה יותר: במקום לקרוא (N - 1) * (B / N) בתים לתוך התקן לצורך צבירה מקומית, רק B / N מועברים מהמתק, מכיוון שהוא מבצע את ההפחתה בעצמו תוך שימוש בנתונים מהעמיתים. עבור שידור, יש שיפור דומה, שכן מספר הטרנזאקציות בין מעבד GPU למתק על פני ערוצי NVLink מופחת מאוד. ללא SHARP, ההתקן הצובר היה מבצע (N - 1) * (B / N) טרנזאקציות מעל NVLink עם המתק, כאשר המתק קורא את אותה כמות נתונים מהעמיתים, עבור סך של 2 * (N - 1) * (B / N) טרנזאקציות. עם SHARP, מבוצעות B / N טרנזאקציות בין מעבד ה-GPU למתק, ועוד (N - 1) * (B / N) עם העמיתים, עבור סך כולל של B טרנזאקציות.
בשל פשטותו, SHARP הוא כלי בעל ערך, שכן הוא מספק יישום חומרה פשוט לאלגוריתם. אף על פי שההעברות מופחתות בשבר תיאורטי של N / (2 * (N - 1)) (ששווה ל-33% עם 4 עמיתים), בפועל אנו צופים שיפור של 10% בהשהיות של טעינה מקדימה ופענוח כאחד במערכות H200 ו-GB200 NVL72.
הפצה ושילוב של MoE (MoE Dispatch - Combine)
במודלים של MoE, kernels של dispatch ו־combine מעבירים ומקבצים tokens עבור בעיות ה־MoE GEMM הבאות בין peers, ומבצעים לאחר מכן צבירה משוקללת ב־combine. התאמדנו את kernels הקיימים שלנו של Dispatch ו־Combine ל־Blackwell, על ידי porting שלהם ל־CuTeDSL, כיוונון allocations של הבלוקים והתאמה אגרסיבית שלהם בין prefill ל־decode.
מקביליות מומחים (Expert Parallel)
גרעין מקביליות המומחים (EP) נמצא בשימוש במעבדי הטעינה המקדימה. מכיוון שהקלט שלו משוכפל על פני כל הדרגות, גרעין ההפצה צריך פשוט לבחור את האסימונים המנותבים למומחים בדרגה הנוכחית. הוא צובר מידע ניתוב ומכין אסימונים לתוך באפרים המשמשים כקלט ל-MoE GEMM. גרעין השילוב מבצע תחילה צבירה מקומית בין התרומות של אסימונים המנותבים למומחים בדרגה הנוכחית, ואז הוא מבצע פעולת all-reduce על פני כל הדרגות.
עבור פענוח, הגרעין כולו מתמזג לאחד. גרעין הטעינה המקדימה מפוצל לגרעינים מרובים, שכן הניתוב ופעולת ה-all-reduce דורשים פחות בלוקים מאשר שלב השילוב המקומי. בעזרת CuTeDSL, יכולנו לבנות ספרייה גנרית הן עבור SHARP ו-NVLink all-reduce והן עבור סנכרון עמית-לעמית, תוך שילוב שלה הן בגרעיני ה-all-reduce והן בגרעיני מקביליות המומחים.
מבחינת ביצועים, אנו הבחנו ש-Blackwell מהיר משמעותית מ-Hopper, הודות למהירויות העברה משופרות, רוחב פס זיכרון גבוה יותר ותפוקה חישובית טובה יותר. כאשר הם מחולקים על פני 8 התקנים וצמתים מרובים במערכות GB200 (EP=8), הגרעינים הופכים מהירים יותר מכיוון שהצבירה המקומית רצה על הרבה פחות אסימונים בכל התקן, ובעזרת SHARP, עלות ההפחתה על פני יותר דרגות מתרחבת טוב יותר. עם זאת, בפועל, אנו מגבילים את המקביליות ל-4 התקנים, שכן האצות אלו אינן אוניברסליות בכל הגרעינים.
מקביליות נתונים ומקביליות מומחים (Data Parallel and Expert Parallel)
גרעין מקביליות הנתונים ומקביליות המומחים (DP-EP) נמצא בשימוש במעבדי הפענוח המקביליים לנתונים. הוא משדר אסימונים שונים מכל הדרגות למומחים, מעביר את התוצאות לדרגות המקור ומבצע בהן צבירה. מכיוון שהוא מממש בעיית all-to-all דלילה, הוא מסתמך אך ורק על NVLink.
ב-Hopper, גרעין זה מוגבל ל-8 התקנים בתוך תחום ה-NVLink של צומת יחיד. עם זאת, במערכות GB200 אנו יכולים להרחיב אותו על פני מארז שלם. רוב הקוד נמצא בשימוש חוזר. ההבדל היחיד הוא השימוש בידיעות fabric כדי להחליף מידע עמיתים מעל IMEX עבור ההגדרה הראשונית.
מכיוון שגדלי ההעברה הנוצרים במהלך הפענוח קטנים, הם רחוקים ממיצויי רוחב הפס של NVLink ובמקום זאת מוגבלים על ידי השהייה. ההשהיות הן בסדר גודל של עשרות מיקרו-שניות ונשארות יציבות יחסית ככל שמספר העמיתים גדל, מה שמאפשר לנו לפרוס מערכת על פני מספר גדול יותר של התקנים מבלי לגרור השהייה נוספת משמעותית.
MoE GEMM
מודלי MoE נהנים ממקביליות מומחים, מכיוון שניתן למקבל בקלות את עלות הכפל של כל האסימונים עם כל המומחים על פני התקנים מרובים. עם מקביליות טנסור במעבדי טעינה מקדימה, בבעיות צפופות היתרון די ישיר, שכן כל דרגה צריכה כעת לבצע פחות חישובים. במקרה של פענוח, מקביליות נתונים מספקת ירון נוסף מעל מקביליות מומחים, שכן המספר הגדול יותר של בקשות מקביליות מנתב יותר אסימונים לכל מומחה, ובכך דוחס את הבעיות.
ביישום שלנו, אנו מסתמכים כיום על גרעיני CUTLASS CUDA/C++ עבור כפל מטריצות. ביצענו עבורם בנצ'מרק על קלטי פענוח דלילים עם סכמות קוונטיזציה שונות ורמות מקביליות שונות על מנת להחליט על אסטרטגיית החלוקה האופטימלית למעבדי הפענוח. בבנצ'מרקים שלהלן, כל המומחים מופעלים עם אסימון יחיד.
מצאנו שהרחבת 128 מומחים על פני יותר מ-16 דרגות מניבה תמורות פוחתות עם CUTLASS, שכן העלות של הכפלת 2 מומחים אינה נמוכה משמעותית מהכפלת 4. יש שיפור ברור ב-Blackwell על פני Hopper, אפילו באסטרטגיית אימון הבלוקים התת-אופטימלית. מכיוון שעליית ההשהייה של כ-5 מיקרו-שניות בין EP=8 ל-EP=16 של הפצה/שילוב מקוזזת על ידי ירידה של יותר מ-10 מיקרו-שניות בעלות ה-GEMM, במערכות GB200, חלוקת מעבדי פענוח על פני 16 דרגות מוצדקת, כפי שמאושר גם על ידי בנצ'מרקים מקצה לקצה.
קוונטיזציה (Quantization)
Blackwell מציגה תמיכת חומרה עבור סכמות קוונטיזציה חדשות של 8-סיביות ו-4-סיביות. בניגוד ל-Hopper, שהסתמכה על גורמי קנה מידה (scaling factors) לפי טנסור או לפי בלוק, Blackwell דורשת מיקרו-סקיילינג (microscaling) כדי להשיג את תפוקת הטעינה המקדימה והפענוח הטובה ביותר. בעוד שאסטרטגיית קנה המידה של הבלוקים המשמשת עבור מודלים כמו DeepSeek או Kimi זמינה, מיקרו-סקיילינג יעילה יותר.
פרסנו את Qwen3 235B עם סכמת הקוונטיזציה MXFP8, כשהמרנו את המשקלים באופן סטטי לאחר כוונון עדין של המודל. השפעת הדיוק הייתה דומה להשפעת סקיילינג בלוקים עם קוונטיזציה סטוכסטית, אך הביצועים שסיפקה היו משופרים הרבה יותר, כפי שמודגם על ידי מיקרו-בנצ'מרקים של MoE GEMM. שקלנו גם את סכמות הקוונטיזציה MXFP4 ו-NVFP4, אם כי השפעת הדיוק ללא אימון מודע לקוונטיזציה (Quantization-Aware Training) הייתה משמעותית מדי עבור המעבר הראשוני מ-Hopper ל-Blackwell. אנו מתכננים לחקור פורמטים אלו באופן יסודי יותר בעבודות עתידיות.
ביצועים מקצה לקצה (End-to-End performance)
ערכנו בנצ'מרק למעבדי הפענוח של פריסות Blackwell Qwen3 235B והשוונו אותם לפריסות Hopper הקודמות שלנו. בהגדרה זו, שקלנו סקיילינג בלוקים על פני שתי הפריסות על מנת להתמקד בהשפעת המקביליות. מעבדי טעינה מקדימה TP=4 הופרדו עבור שתי הארכיטקטורות כדי לבודד את ביצועי הפענוח. האיור להלן ממחיש את תפוקת הפענוח בהנחה של קצב אישור טיוטה ריאלי המסופק על ידי שכבות ה-MTP שלנו.
ב-Hopper, חלוקת הפריסה על פני יותר מ-8 מעבדי GPU אינה בת-ביצוע, שכן ההשהיות מעל InfiniBand, במיוחד במתאמי EFA, איטיות משמעותית. עם זאת, ב-Blackwell, אנו משיגים תפוקה גבוהה משמעותית, הודות לתחומי NVLink הגדולים יותר.
השגנו יישום ראשוני של Blackwell על ידי הכללת גרעיני Hopper קיימים ודחיפת הביצועים של הגרעינים מבוססי ה-NVLink. נמשיך לצמצם את עלות ההפעלה של Qwen על ידי שיפור הקוונטיזציה וכוונון עדין של ביצועי הפענוח ותפוקת הטעינה המקדימה של הגרעינים האחרים בצינור העיבוד.
מקורות והפניות
פוסט בבלוג על מנוע ההעברה (Transfer Engine)
פוסט בבלוג על טעינה מקדימה מופרדת (Prefill-Disagg)
ציטוט
@online{perplexity2026HostingQwenOnBlackwell,
author = {{Perplexity} and Nandor Licker and Kevin Hu and Bex Brooker and Erin McKnight},
title = {{Hosting Qwen on Blackwell}},
date = {2026-05-12},
url = {https://www.perplexity.ai/hub/blog/hosting-qwen-on-blackwell}
}