הפעלת מודלים בני טריליון פרמטרים ב-AWS EFA

ב-Perplexity, אנחנו משתמשים במודלים הטובים ביותר עבור המוצר שלנו, ממשקי ה-API שלנו וצוותי המחקר שלנו. מודלי Mixture-of-Experts גדולים בקוד פתוח, כגון Kimi-K2, מציבים אתגרים ייחודיים, שכן הצמתים הגדולים ביותר להרצת הסקה עם 8x NVIDIA H200 GPUs אינם יכולים להכיל אותם ביעילות, מה שמחייב פריסות רב-צומתיות. אנו מציגים סט של kernels עבור parallelism של מומחים, שמגיעים להשהיות מהטובות ביותר ב-ConnectX-7, ועולים בביצועים על DeepEP. אותם kernels הם גם הראשונים להשיג השהיות ישימות ב-AWS Elastic Fabric Adapter (EFA), ומאפשרים פריסות של מודלים עם טריליון פרמטרים.

נסו את הקרנלים שלנו ב-GitHub וקראו את מאמר המחקר המלא ב-arXiv.

ארכיטקטורת Mixture-of-Experts (MoE) התבססה כארכיטקטורת הסטנדרט עבור סקיילינג (התאמת בקנה מידה) למאות מיליארדים או טריליונים של פרמטרים, תוך שהיא מציעה גם השהייה סבירה בזמן הסקה. מודלי MoE מחליפים את השכבה הצפופה (dense layer) של טרנספורמר בקבוצה של מומחים ובשכבת ניתוב ליניארית קטנה המחליטה עם איזה מומחה יש לבצע כפל טוקן. על ידי קיבוץ הטוקנים המשויכים לאותו מומחה, הבעיה הופכת למדללת (sparse) וניתנת למקבילות בצורה טריוויאלית, שכן כעת ניתן לארח מומחים שונים על גבי יחידות GPU שונות המפולגות על פני צמתים מרובים.

בניגוד לצורות אחרות של מקבילות, כגון מקבילות טנזור (Tensor Parallelism - TP) ומקבילות נתונים (Data Parallelism - DP), הניתנות ליישום בקלות באמצעות ספריות תקשורת קולקטיביות כמו torch.distributed ו-NCCL, ניתוב MoE כרוך בתקשורת עמית-לעמית (peer-to-peer) מדללת. קרנל שיגור חייב לפצל את קבוצת הטוקנים הנכנסים ולשגר אותם לדרגות המארחות את המומחים, בעוד שבעיית הדואל שלה, קרנל המיזוג (combine kernel), חייב לקבל את המקבילים המעובדים שלהם ולחשב את הממוצע המשוקלל שלהם. העברות אלו אינן ממופות לקולקטיבים ודורשות קרנלים מותאמים אישית כדי להשיג השהייה נמוכה.

ב-Perplexity, פיתחנו הן קרנלים ניידים בין צמתים והן קרנלים ייעודיים בתוך הצומת, והצגנו את עבודתנו לעומק במאמר קודם בנושא תקשורת MoE. כמו כן, הראנו בפוסט בבלוג אחר שפריסה מרובת צמתים יכולה להביא להשהייה נמוכה יותר ולתפוקה גבוהה יותר עבור מודלי MoE גדולים.

במאמר זה, אנו צוללים לעומק היישום של קרנלי בין-הצמתים החדשים שלנו, אשר משפרים משמעותית את הביצועים של העבודה הקודמת שלנו מבוססת-NVSHMEM. מלבד הצגת תוצאות מובילות בתחום ב-ConnectX-7, אנו גם מדגימים שבמסגרת זמן הריצה של ההסקה שלנו, ניתן להשתמש בקרנלים כדי לשרת ביעילות את המודל הגדול ביותר בקוד פתוח.

מקבילות טנזור ומקבילות מומחים יכולות לעבור סקיילינג ביעילות בתוך צומת יחיד, מכיוון ש-NVLink מציעה תפוקה גבוהה (900GB/s) בהשהיה של מיקרו-שניות. בעוד שמערכות NVIDIA GB200 ו-GB300 מצוידות בזיכרון מספיק כדי להחזיק את המשקלים ומטמוני ה-KV של מודלים בני טריליון פרמטרים, פריסות במופע AWS p5en עם עד 8 יחידות GPU מסוג H200 מוגבלות ל-1120GB של HBM, אשר חייבים להתחלק בין משקלי המודל לבין מטמוני ה-KV. כתוצאה מכך, מודלים מסוימים מחייבים פריסות בין-צמתים מעל InfiniBand.

אף על פי ש-InfiniBand עדיין מהיר באופן מדהים, הוא מציע תפוקה של 400Gbps (50GB/s) בלבד, המוסיפה עשרות עד מאות מיקרו-שניות של השהייה לניתוב MoE. למרבה המזל, ניתן להסתיר את ההשהיות הנוספות באמצעות שימוש במומחים משותפים, מיקרו-בצ'ינג וחפיפת חישוב-תקשורת כדי לספק תפוקה ברת-קיימא בעלות תחרותית. DeepSeek הובילה טכניקות אלו באמצעות DeepSeek-R1, הפרוס באשכולות של יחידות GPU מסוג H800 ומותאמי NVIDIA ConnectX-7 InfiniBand.

באשכולות AWS, המצב שונה עקב השימוש ב-Elastic Fabric Adapters (EFA) המותאמים אישית שלהם. על אף שאלה מספקים תפוקה שיא של 400Gbps בקולקטיבים המשמשים בדרך כלל בעומסי עבודה של אימון, הם נופלים במעט מ-ConnectX-7 בגדלי ההודעות המוחלפות במהלך שיגור ומיזוג MoE. בנוסף, EFA אינו תומך ב-GPUDirect Async, ודורש שרשור פרוקסי של מעבד (CPU) המגשר בין ה-GPU ל-NIC על מנת ליזם העברות. מלבד המורכבות הנוספת, פעולות ה-PCIe הנוספות מוסיפות עומס (overhead) בשווי מיקרו-שניות לכל ההעברות. מסגרות עבודה כגון NVSHMEM מאפשרות לכותבי קרנלים לספק יישומים בלתי תלויים בהתקן, אך ה-API הגנריים מייצרים עומסים ההופכים פריסות לבלתי יעילות מבחינת עלות והשהייה כאחד.

הקרנלים הקודמים שלנו הפשטו את יישום התעבורה הבסיסי באמצעות NVSHMEM. הם הסתמכו על nvshmemx_putmem_signal_nbi_warp כדי להעביר טוקנים אחד-אחד, תוך שימוש במונים אטומיים כדי לסנכרן עמיתים. בעוד שדבר זה הציע ביצועים סבירים ב-NICs מסוג ConnectX-7 עם IBGDA, יישום ה-IBRC המבוסס על פרוקסי של ConnectX-7 היה איטי משמעותית, בעוד שיישום ה-EFA נכשל לספק השהיות מתחת למיקרו-שניה אחת.

השתמשנו ב-kernels כ-testbed עבור החומרה הבסיסית, ובמקביל גם קבענו מהו הממשק המתאים ביותר לחשוף למודלים שלנו. שיערנו שהעברות ואינטראקציות תכופות בין ה-kernels לבין ה-NICs או שרשורי ה-proxy פוגעות בביצועים. בנוסף, המימוש שלנו לא הסתמך על שום הבטחה מהחומרה מלבד אמינות, מה שמרמז שנוכל להאיץ את הדברים על ידי צמצום התקורה של פרימיטיבי סנכרון.

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

תקשורת היברידית של RDMA ו-NVLink עם פרוקסי מארח, המציגה דרגות יוזמות ומקבלות, עובדי פרוקסי וכרטיסי NIC.

הקרנלים החדשים עוקבים אחר ארכיטקטורת CPU-GPU היברידית, שבה קרנלי GPU מקיימים אינטראקציה עם המודל בהתקן ושרשור פרוקסי הפועל על מעבד המארח (Host CPU) מטפל באינטראקציות עם ה-NIC. הקרנלים החדשים עושים שימוש חוזר באותו TransferEngine שבנינו עבור העברות מטמון KV.

ניתוב MoE מתבצע על ידי קרנל שיגור (dispatch kernel), המקבל מהמודל את הטוקנים ואת המומחים לכל טוקן שאליהם יש לנתב אותם, ושולח אותם דרך הרשת אל הדרגות המארחות את המומחים. לאחר שקרנלי ה-GEMM הממוקצים מכפילים את הטוקנים עם משקלי המומחים, קרנל המיזוג מעביר את הטוקנים לדרגות המקור שלהם ומחשב את הממוצע המשוקלל שלהם לפני החזרתם למודל.

גם קרנלי השיגור וגם קרנלי המיזוג מפוצלים למחצית שולח ומחצית מקבל כדי לאפשר חפיפה ומיקרו-בצ'ינג. השולח מערבב את הטוקנים לתוך מאגרי שליחה כך שניתן יהיה לכתוב אותם לעמיתים באמצעות פעולת כתיבת RDMA בודדת. לאחר ביצוע השולח, ה-GPU יכול לבצע עבודה אחרת (כגון כפל מומחים משותף) בזמן שההעברות ברשת ממתינות ברקע. קרנלי הקבלה נחסמים עד לקבלת כל ההעברות. ברקע, שרשור עובד בצד המארח מטפל בהעברות: הוא מקבל איתות מה-GPU כאשר מאגרי השליחה אוכלסו, ולאחר מכן הוא משגר את כתיבות ה-RDMA. ברגע שה-NIC מאותת על השלמה, הוא משחרר את החסימה של המקבל, המחזיר את הטוקנים למודל.

ה-kernels מהודקים היטב ל-host, ומתקשרים זה עם זה באמצעות both unified memory ו-GDRCopy. CUDA unified memory מאפשרת למפות זיכרון device או host אל מרחבי הכתובות של שניהם, תוך טיפול שקוף בתקשורת דרך PCIe.

בעוד שזיכרון מאוחד מתאים להעברות בכמות גדולה (bulk transfers), סקרור (polling) בהשהייה נמוכה מתבצע באמצעות GDRCopy. ‏GDRCopy משתמש ב-GPUDirect RDMA כדי לקרוא מזיכרון ה-GPU ולכתוב אליו בהשהיה של מיקרו-שניות.

בנוסף ל-RDMA, בתוך צומת הקרנלים מנצלים גם את NVLink כדי להחליף טוקנים. פעולה זו יכולה לפרוק חלק משמעותי מהתעבורה, עד רבע עבור EP32 ועד שמינית עבור EP64, ובכך להשיג השהיות נמוכות יותר בסך הכל.

העיצוב של מאגרי השליחה עבור קרנל השיגור הוא קריטי להשגת השהיות ברות-קיימא הכוללות את פרוקסי המארח. אם ישנן N דרגות שכל אחת מהן משגרת T טוקנים, כאשר כל אחת מנותבת ל-R מומחים מתוך E, דרגה יכולה לקבל עד N * T * max(R, E / N) טוקנים בתרחיש הגרוע ביותר האפשרי, אם כולם מנותבים אליה. יתרה מכך, ניתן להשיג גבול מינימלי זה רק כאשר השולחים ממקמים את הכתיבות שלהם ברצף (contiguously), שכן מאגרי קבלה פרטיים יצרכו יותר מדי זיכרון. על מנת ששולחים יוכלו למקם את הכתיבות שלהם ברצף ללא התנגשויות, יש להפיץ לכל דרגה ידע מלא על מידע הניתוב. כתוצאה מכך, קרנלי השיגור שלנו מחליפים תחילה ספירות טוקנים לכל מומחה, ולאחר מכן כל אחד מהם יכול לקבוע לאן הולכות הכתיבות שלהם ומאיזה היסט (offset) הם מקבלים טוקנים מכל דרגה.

פשוט החלפת מידע ניתוב הייתה גורמת להשהיות גבוהות שלא לצורך, מכיוון שכל rank היה צריך להמתין שהכתיבות יגיעו לפני שישלח כל כתיבה משלו. במקום זאת, אנו מקצים כמות קטנה של מרחב פרטי לכל-שולח בכל rank מקבל ושולחים חלק מהטוקנים יחד עם הכתיבות של מידע הניתוב. כך מובטלת ניצולת רוחב פס מלאה לאורך רוב תהליך השליחה. לאחר שהנתיבים מוחלפים, הטוקנים הנותרים מועברים באמצעות כתיבה אחת לכל peer מרוחק. החלפת מידע הניתוב וה-buffers הקבועים בגודלם, יחד עם ההעברות שממלאות אותם, מוצגות באיור שלמטה.

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

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

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

האיורים שלהלן מפרטים את התזמון ואת האינטראקציות בין ה-GPU, ה-CPU וה-NIC, ומציגים איטרציה אחת של שיגור ומיזוג משולבים לסירוגין עם הקרנלים של המודל.

העבודה מתחילה בשיגור שליחה (dispatch send), כאשר הקרנל מאגד את מידע הניתוב ומחשב ספירות טוקנים לכל מומחה באמצעות צבירה אטומית בזיכרון משותף בתוך בלוק יחיד. ברגע שספירות הטוקנים זמינות, הן מועתקות לזיכרון המארח והפרוקסי מקבל הודעה מיידית להתחיל בשיגור מידע הניתוב לכל שאר דרגות העמיתים. במקביל, השיגור ממשיך לחשב את הסכום המצטבר של ספירות הטוקנים, ומזהה את ההיסטים הנדרשים לאריזת טוקנים במאגרי שליחה רציפים לכל דרגה. ברגע שההיסטים זמינים, כל הטוקנים לשליחה באמצעות EFA נארזים במאגרי השליחה. הפרוקסי מקבל הודעה לפרסם את הכתיבות לתוך מאגרי השליחה של עמיתים בין-צמתיים. בתוך הצומת (Intra-node), הקרנלים גם דוחפים מיד טוקנים לתוך מאגרים פרטיים באותו צומת דרך NVLink.

תזמון ותיאום עבור הפצת MoE, המציגים פעולות GPU, CPU ו-NIC בשלבים ואת הסנכרון ביניהן.

תזמון ותיאום עבור שילוב MoE, המציגים פעולות GPU, CPU ו-NIC ואת הסנכרון ביניהן.

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

בצד המקבל, ה-kernel קודם מושך טוקנים מאותו node שנמצאים מעבר לקיבולת של buffers פרטיים דרך NVLink. לאחר מכן הוא נחסם עד שה-host proxy מאותת על השלמת כל ההעברות. לאחר קבלת האות, הטוקנים ממוספרים מחדש מ-buffers הקליטה אל תוך Tensor הפלט שהועבר ל-group GEMM. מאחר שה-buffers משמשים מחדש בין dispatch ל-combine, גם מחסומי NVLink וגם מחסומי RDMA מבטיחים ש-buffers של המקבל נקראו לפני שהם מאפשרים ל-kernel הבא לדרוס אותם.

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

כדי ליצור אב טיפוס ליישום שלנו, עשינו תחילה שימוש חוזר ב-TransferEngine שנבנה עבור מילוי מוקדם (prefill) ופענוח (decode) מפורקים על מנת להנפיק ולעקוב אחר כתיבות RDMA. עם זאת, בניגוד לפענוח מפורק שבו כל צומת מפרסם מספר רב של כתיבות לאותו עמית, שיגור MoE מפרסם העברות קטנות לכל העמיתים בפעולה אחת. מהקופסה, הביצועים לא היו מיטביים והיישום שלנו פיגר מאחורי DeepEP ב-ConnectX-7 בכ-20 מיקרו-שניות. כתוצאה מכך, התאמנו את ה-TransferEngine כך שיתמוך בשתי פעולות, scatter ו-barrier, כדי לבצע אופטימיזציה לאינטראקציות עם מספר רב של עמיתים.

פעולות ה-scatter וה-barrier כאחד חושפות קבוצות עמיתים שניתן לרשום מראש כדי לאכלס מראש את מבני הנתונים המשמשים את יישום התעבורה הבסיסי (תבניות בקשת עבודה - Work Request (WR) templating). פעולת Scatter מעתיקה פרוסות שונות מאותו מאגר מקור להיסטים שונים בכל חברי קבוצת העמיתים. Barrier מאותת לכל העמיתים באמצעות איתות מיידי (immediate). תור (enqueuing) וטיפול בפעולות אלו בכמות גדולה חוסכים מיקרו-שניות יקרות בנתיב הקריטי. ב-EFA, שבו שני NICs של 200Gbps מתאגדים כדי לספק רוחב פס של 400Gbps, אנו מחלקים עמיתי קבוצה על פני שני ה-NICs במקום לחלק את הבייטים של כל העברה.

אף על פי שבתחילה פיתחנו את ה-TransferEngine אך ורק על EFA תוך שימוש ב-libfabric, קרנלי ה-MoE עובדים על ConnectX-7 מבלי לשנות שורת קוד אחת לאחר הוספת תמיכה ב-ConnectX-7 ב-TransferEngine תוך שימוש ב-libibverbs. בהשוואה ל-EFA מבוסס Scalable Reliable Datagram (SRD),‏ ConnectX-7 דורש עבודה נוספת עבור הגדרת חיבור וניהול עמיתים. אנו משתמשים בזוג תורים של Unreliable Datagram (UD) כדי לאתחל Reliable Connection (RC). אנו יוצרים שני זוגי תורים עבור כל עמית מרוחק, אחד עבור SEND/RECV דו-כיווני ואחד עבור WRITE_IMM חד-כיווני, מכיוון שגם RECV וגם WRITE_IMM צורכים פעולת RECV לפי סדר בעוד ששתי הפעולות דורשות גדלי מאגר שונים. חוץ מזה, אנו משחררים את סדר פעולות ה-PCIe בין ConnectX-7 לזיכרון ה-GPU. בדומה ל-EFA, אנו מיישמים את אופטימיזציית תבניות ה-WR. בנוסף, בעת שליחת הודעות קטנות מרובות לאותו עמית, אנו משתמשים בשרשור WR כדי לשפר את קצב ההודעות.

מכיוון שעבודת צד ה-GPU זהה בשלל המתאמים, דחפנו את יישום התעבורה הבסיסי אל הגבולות שלו כדי לעלות על הביצועים של DeepEP וכדי להדגיש שהפער בין ניתוב MoE של EFA לבין ConnectX-7 נקבע על ידי היכולות של חומרת הבסיס.

הערכנו את השהיות השיגור והמיזוג במערכות H200 המצוידות במתאמי ConnectX-7 ו-EFA בתצורת DeepSeek-V3 ו-Kimi-K2 הסטנדרטית עם ממד נסתר של 7168, שיגור fp8 המותאם לפי בלוקים ומיזוג bf16. אנו בוחנים גודל אצווה (batch size) של 128 לשיגור ו-4096 למיזוג. ב-ConnectX-7, אנו השוואנו מול DeepEP ו-pplx-kernels קודמים מבוססי NVSHMEM שלנו, תוך שימוש גם ב-GPUDirect Async (IBGDA) וגם בפרוקסי מארח (IBRC). אנו משיגים השהיות משולבות של 459us, 582us ו-692us ב-EP16, EP32 ו-EP64, בהתאמה. אנו עולים בביצועינו על קרנלים אחרים מבוססי EFA המסתמכים על פרוקסי גנריים, כגון UCCL-EP, המשיגים 519us, 966us ו-1159us.

השהיה של הפצה ושילוב עבור פענוח MoE ב-EP64, המשווה בין המימושים ונתיבי התקשורת המוצגים.

בפענוח, על אף שהקרנלים שלנו איטיים בכמה מיקרו-שניות מ-DeepEP, אנו משיגים השהיות נמוכות יותר בסך הכל מכיוון שקרנלי המיזוג שלנו מהירים משמעותית. למרות שאנו משתמשים בפרוקסי מארח, עקב ההעברות בכמות גדולה שלנו אנו עולים על הביצועים של כל היישומים ללא פרוקסי מבוססי IBGDA. אנו מראים גם שיישום הפרוקסי משנה, שכן הפרוקסי המותאם במיוחד שלנו מהיר בסדר גודל מהיישום הגנרי של NVSHMEM. למרות העובדה ש-EFA איטי פי שניים מ-ConnectX-7 בעת העברת מנות של 256KB, הקרובות לגודל המאפיין המוחחל על ידי ניתוב MoE, הפער בין שני המתאמים הוא בסך הכל פחות מהותי.

השהיה של הפצה ושילוב עבור Prefill של MoE ב-EP64, המשווה בין נתיבי התקשורת של pplx ו-DeepEP.

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

כדי להוכיח את היתכנות הקרנלים שלנו, אנו מריצים בנצ'מרק לביצועי מקצה לקצה של מנוע ההסקה הפנימי שלנו המשרת את DeepSeek-V3 (671B פרמטרים) ו-Kimi-K2 (1T פרמטרים) על גבי מופעי p5en מרובים המצוידים ב-Elastic Fabric Adapters (EFA) וביחידות GPU מסוג H200. אנו מריצים את המודל במצב אימות טיוטה (draft verification mode) ומדווחים על השהייה בהנחת שיעור קבלה של 80% תוך שימוש בשכבת MTP בודדת.

ב-DeepSeek-V3, אנו משווים מול קו בסיס פנים-צמתי של EP=8 המריץ קרנלי שיגור ומיזוג יעילים המבוססים על NVLink בלבד. פריסות בין-צמתיות תואמות או עולות בסך הכל על ביצועי הפריסה בצומת יחיד, במיוחד באצווה בגודל בינוני, מה שמוכיח שביצוע סקיילינג על פני צמתים מביא אכן שיפורים לתפוקה הכללית.

ב-Kimi-K2, הקרנלים מאפשרים מתן שירות. בשל גודלו, המודל אינו יכול להיכנס באותו צומת תוך שימוש במקבילות נתונים (DP) על גבי צומת H200, ולכן נדרשת פריסה בין-צמתית כדי לשרת את המודל. מכיוון שלמודל יש פחות ראשי קשב (attention heads), אנו משיגים השהיות טובות יותר מאשר ב-DeepSeek-V3 ואנו יכולים לשרת את המודל ב-EFA בהשהייה ברת-קיימא.

התפוקה לכל GPU של DeepSeek-V3 לעומת מהירות הפלט עבור תצורות EP32, EP16 ו-EP8.

התפוקה לכל GPU של Kimi-K2 לעומת מהירות הפלט עבור תצורות EP32 ו-EP16.

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

אנו עובדים בשיתוף פעולה הדוק עם מהנדסי AWS כדי לשפר את הביצועים ב-EFA. מצידנו, נעקוב אחר עדכונים ל-libfabric אשר יפחיתו את עומס נתיב הנתונים. בנוסף, נבצע ניסויים עם efa-direct כדי להפחית עוד יותר את עומסי מרחב המשתמש (userspace) ולתקשר ישירות עם החומרה.

דוח טכני של DeepSeek R1

דוח טכני של Kimi K2

DeepEP

UCCL-EP

שיפור ביצועי הרשת של מערכות HPC באמצעות NVIDIA Magnum IO NVSHMEM ו-GPUDirect Async

BibTeX

@online{perplexity2025EnablingTrillionParameterModelsOnAwsEfa,
  author = {{Perplexity} and Nandor Licker and Kevin Hu and Vladimir Zaytsev and Lequn Chen},
  title = {{Enabling trillion-parameter models on AWS EFA}},
  date = {2025-11-04},
  url = {https://www.perplexity.ai/hub/blog/enabling-trillion-parameter-models-on-aws-efa}
}

מבוא

הסקה מעל InfiniBand

pplx-kernels מבוססי NVSHMEM

MoE all-to-all מעל EFA

מאגרי שליחה וקבלה

שיגור ומיזוג

TransferEngine עבור ניתוב MoE

הערכה

השהיית שיגור/מיזוג

תפוקת Kimi-K2 / DeepSeek-V3

עבודה עתידית

הפניות

ציטוט