האצת Llama 2 70B עם NVIDIA H100

השאיפה לביצועים במנוע התשובות של Perplexity מניעה אותנו לאמץ את הטכנולוגיה העדכנית ביותר שיש ל-NVIDIA ול-AWS להציע. בבלוג זה, אנו שמחים לשתף את תוצאות הניסויים האחרונים שלנו: השוואה של הסקת מסקנות (Inference) עבור Llama 2 70B על פני הגדרות חומרה ותוכנה שונות.

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

מהו שיפור הביצועים הגולמי הנובע מהעברת המאיצים הגרפיים (GPUs) שלנו מ-NVIDIA A100 ל-NVIDIA H100, כאשר כל שאר ההגדרות נשארות ללא שינוי?

מהו שיפור היעילות של קוונטיזציה (כימות) בנקודה צפה של 8 סיביות (fp8), שעבורה מוסיפה H100 תמיכה מובנית? מהו מחיר הדיוק של קוונטיזציה זו?

כיצד מקביליות טנزور (tensor parallelism) וגודל האצווה (batch size) משפיעים על השהיה (latency) ועל קצב העברת הטוקנים (throughput)?

בהתחשב באמור לעיל, איזו תצורה מביאה לאיזון הניתן להתרחבות הטוב ביותר בין ביצועים לחסכונות בעלויות?

הרצנו את הניסוי הבא כסדרה של מבחני ביצועים (benchmarks) מקומיים כדי להימנע מהשהיית רשת.

השהיה (Latency): הזמן הכולל שלוקח לשרת הסקת המסקנות לייצר את מלוא התגובה.

קצב תפוקה (Throughput): מספר טוקני הפלט, בשנייה, לכל מעבד גרפי (GPU), ששרת הסקת המסקנות יכול לייצר על פני כל המשתמשים והבקשות.

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

הביצועים גדלים בהתאם לגודל מודל השפה הגדול (LLM). פרמטרים נוספים דורשים חיובים חישוביים רבים יותר המביאים להסקת מסקנות איטית יותר. לדוגמה, Llama 2 13B מהיר יותר מ-Llama 2 70B כאשר שאר ההגדרות שוות. אנו דבקים ב-Llama 2 70B בניסוי זה מכיוון שאנו רוצים לבצע אופטימיזציה להגשת מודל הקוד הפתוח היכולתני ביותר.

כמות טוקני הקלט והפלט בכל זוג בקשה/תגובה לדוגמה יכולה להשפיע על מדידות הביצועים. באופן כללי, יצירת טוקני פלט שולטת בזמן התגובה הכולל. כאשר דגימת נתונים משרה רק תגובות של "כן/לא" ממודל השפה הגדול, התגובה מהירה יותר בהשוואה לדגימות המבקשות ממודל השפה הגדול לכתוב חיבורים. מערכת הנתונים שלנו מורכבת מבקשות סינתטיות עם 1024 טוקני קלט המשרים 512 טוקני פלט. התפלגות זו נבחרה כדי להתאים להתפלגות התעבורה הנצפית בפריסה הציבורית שלנו של Llama2 70B.

NVIDIA TensorRT-LLM (גרסה v0.5.0) היא ספריית קוד פתוח לאופטימיזציה של הסקת מסקנות במודלי שפה גדולים. היא שוחררה בסוף 2023, מסנתזת את אופטימיזציות הסקת המסקנות הרבות של NVIDIA ומספקת שכבת התאמה אישית גמישה עבור הפרמטרים המרכזיים של ניסוי זה: גודל אצווה, קוונטיזציה ומקביליות טנزور.

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

ארכיטקטורת ה-GPU של הדור התשיעי Hopper (H100-HBM3-80GB / p5.48xlarge) כוללת רשימה עצומה של תכונות בהשוואה לקודמתה, Ampere (A100-SXM4-80GB / p4de.24xlarge), כולל קצבי חיוב של פי 2 עד פי 6 ורוחב פס זיכרון GPU של כמעט פי 2. רוחב פס זיכרון ה-GPU הוא מדד קריטי להסקת מסקנות מכיוון שצוואר בקבוק השהיה עיקרי של מכפלות מטריצות בהסקת מסקנות נוبع מטעינת גיגה-בייט של נתוני מודל מזיכרון ה-GPU לאוכפי החישוב. בהBased על נתונים סטטיסטיים אלה, העלינו השערה שהשוואה ישירה (apples-to-apples) בין NVIDIA H100 ל-A100 תציג שיפור של פי 2 הן בהשהיה והן בקצב התפוקה.

הבדל מרכזי נוסף בין NVIDIA H100 ל-A100 הוא שליבת ה-Tensor של ה-H100 מוסיפה באופן מובנה תמיכה לפקודות נקודה צפה של 8 סיביות (fp8), מה שפותח את הדלת לאופטימיזציות נוספות המפורטות להלן. זו הסיבה שאנו משתמשים ב-fp8 וב-fp16 במיוחד עבור ה-H100.

כדי לשמור על זיכרון לכל מעבד גרפי עקבי בניסוי זה, דבקנו בצמתים עם זיכרון GPU של 8x80GB עבור מעבדי ה-A100 וגם ה-H100 שלנו. בנוסף לאפשרות של גדלי אצווה גבוהים יותר, זיכרון ה-GPU חשוב מכיוון שפרמטרים של המודל נטענים לזיכרון ה-GPU במהלך הפעלת השרת לגישה מהירה. לדוגמה, אם כל אחד מ-70 מיליארד הפרמטרים במודל שלנו הוא מספר נקודה צפה של 16 סיביות, אזי גודל המודל הוא בסביבות 140GB, מה שאינו מתאים על מעבד גרפי יחיד. מכאן הצורך במקביליות טנزور, אותה נסביר להלן.

מקביליות טנزور מתייחסת למספר התקני ה-GPU הנצרכים כדי להפעיל את שרת הסקת המסקנות. כאשר אנו מקצים מספר מעבדים גרפיים, TensorRT-LLM מאגדת את המשאבים שלהם יחד כדי לעזור לנו להגיע לתקציב הזיכרון המינימלי הנדרש להפעלת Llama2 70B. ההשערה שלנו היא שמקביליות טנزور נמוכה יותר תביא להשהיה גבוהה יותר (בשל פחות מששאבים נצרכים כדי לספק כל אצווה) אך לקצב תפוקה גבוה יותר לכל GPU (בשל ניצול טוב יותר) בהשוואה למקביליות טנزور גבוהה יותר.

קוונטיזציה היא הפחתת הדיוק במשקלים ובהפעלה שבהם מששתמשות רשתות עצביות. אנו משתמשים בטכניקה זו כדי לחצות את צריכת זיכרון ה-GPU כאשר אנו עוברים מ-fp16 ל-fp8. הדבר מאפשר להפעיל את אותו מודל עם שימוש נמוך יותר בסך זיכרון ה-GPU, מה שמאפשר מקביליות טנزور נמוכה יותר, המעלה את קצב התפוקה.

יישומי קוונטיזציה עלולים לפגוע בדיוק. לפיכך, הערכנו את הדיוק עבור דיוקים שונים על ידי השוואת מדד הפרפלקסיטי (perplexity) שלהם, מדד לאופן שבו מודל השפה הגדול חזה כל טוקן הבא במשפט, על קורפוס WikiText. עבור נקודה צפה של 8 סיביות ומשקל 8 סיביות עם הפעלה של 8 סיביות ו-SmoothQuant (w8a8 SQ), לא חל שינוי משמעותי בפרפלקסיטי (< 1%) בהשוואה ל-fp16 ב-WikiText, כך שהרגשנו בטוחים להמשיך. עם זאת, w4a16 הציג שינוי מהותי של 7% בפרפלקסיטי, ככל הנראה ניתן לייחוס לדיוק הנמוך עוד יותר ולהמרות דינמיות הכרחיות בין int4 ל-fp16.

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

במקרה של Llama 2 70B (שלו 80 שכבות), fp16 עם גודל אצווה 32 עבור גודל הקשר 4096, גודל מטמון ה-KV מגיע ל-40 GB משמעותיים. הדבר מונע בסופו של דבר מ-Llama 2 70B fp16, שמשקליו לבדם תופסים 140GB, להשתלב בנוחות בזיכרון ה-GPU של 160GB הזמין במקביליות טנزور 2 (TP-2).

סרקנו שילובים תואמים של 4 המשתנים של הניסוי ומציגים את המגמות המאירות ביותר להלן.

איור 1 – ההשהיה של בקשות עם גדלי אצווה משתנים על פני חמש תצורות שונות, כולן עם מקביליות טנزور 8, המניבה את ההשהיה הטובה ביותר עם 8 מעבדים גרפיים זמינים. בתוך כל תצורה, ההשהיה בדרך כלל מכפילה את עצמה בעת הגדלת גודל האצווה מ-1 ← 32, ומכפילה את עצמה שוב מ-32 ← 128. בגדלי אצווה גדולים דיו, H100 מקצץ בערך בחצי את ההשהיה בהשוואה ל-A100. A100 משתמש בדיוק מעורב מכיוון שלאדריכלות אין תמיכה מובנית ב-fp8. w8a8 עם SmoothQuant (SQ) נועד להידמות ל-fp8.

שיפור ההשהיה של קוונטיזציה הוא בסביבות 10% בעת השוואת H100 fp16 → fp8 ו-A100 fp16 → w8a8 עם SmoothQuant. עם זאת, הדיוק המעורב w4a16 מתפקד למעשה טוב יותר בגדלי אצווה נמוכים וגרוע יותר בגדלי אצווה גבוהים בהשוואה ל-fp16. הדבר עשוי לנבוע ממספר גורמים, כולל ליבות חיוב מותאמות פחות, זמן הטלה בין int4 ל-fp16, והעובדה ש-w4a16 עדיין משתמש בנקודות צפות של 16 סיביות להפעלות, מה שמוביל לאפס חיסכון בממדי מטמון ה-KV. מכיוון ש-w4a16 הדגים גם דיוק נמוך יותר, אנו מסיקים שעלינו לדבוק ב-w8a8 SQ עבור A100 ו-fp8 עבור H100.

איור 2 – קצב התפוקה על פני תצורות TP-8 עם ארכיטקטורה, קוונטיזציה וגודל אצווה שונים. עבור כל ארכיטקטורה וקוונטיזציה, גודל האצווה נבחר כגדול ביותר שעמד בדרישת השהיה של 25600ms (20 טוקנים לשנייה עבור 512 טוקנים), כך שאנו משווים תצורות בעלות השהיה דומה. תחת דרישה זו, H100 עם BS-128 מגיע ל-228% קצב תפוקה בהשוואה ל-A100 BS-64 המשתמש באותה קוונטיזציה (fp16) ואפילו בעל השהיית תגובה נמוכה יותר למרות גודל האצווה המוכפל. קוונטיזציה עם fp8 משפרת גורם זה ל-251%.

בשני האיורים הראשונים שלנו, אנו מציגים רק תצורות של TP-8. H100 משיג 54% השהיה ו-184% קצב תפוקה בהשוואה ל-A100 כאשר שניהם משתמשים ב-fp16 / BS-128 / TP-8, המשתפר ל-49% השהיה ו-202% קצב תפוקה בעת שימוש ב-fp8 ב-H100. שיפור זה בביצועים יכול להיות מיוחס לעלייה בכוח החישוב וברוחב פס הזיכרון בין H100 ל-A100. ראוי לציין שההבדל בולט פחות תחת גדלי אצווה נמוכים שבהם הניצול עשוי להיות נמוך יותר.

כאשר אנו בונים את הפלטפורמה שלנו, אנו רוצים לעמוד בדרישות השהיה מסוימות עבור המשתמשים שלנו תוך מקסימיזציה של קצב התפוקה. לפיכך, במקום להשוות A100 מול H100 באותו גודל אצווה, הגיוני יותר עבורנו להשוות את קצב התפוקה שלהם רק תחת תצורות שבהן הם עומדים בדרישת השהיה. הגדרנו סף בהשהיה של 25600ms להשלמת 512 טוקני הפלט ומצאנו ש-H100 / TP-8 / fp8 / BS-128 מניב קצב תפוקה של 251% בהשוואה ל-A100 / TP-8 / fp16 / BS-64, מכיוון שהוא מסוגל לעבד כפול גודל אצווה בהשהיה נמוכה יותר. בהינתן שקוונטיזציה מספקת חיסכון בזיכרון GPU, עלינו כעת להעריך כיצד מקביליות טנزور יכולה להוסיף שכבת אופטימיזציה נוספת.

איור 3 – ההשהיה על פני גדלי אצווה משתנים ומקביליות טנزور עבור H100 fp8. ההשהיה בדרך כלל מכפילה את עצמה בעת הגדלת גודל האצווה מ-1 ← 32, ומכפילה את עצמה שוב מ-32 ← 128. TP-2 איטי בעקביות בערך פי שניים מ-TP-8 כאשר גדלי האצווה שווים. הכפלת מקביליות הטנزور תוך הכפלת גודל האצווה שומרת על השהיה יציבה יחסית שכן מספר האצוות המעובדות לכל GPU נותר שוויוני.

כשמדובר בקוונטיזציה ובארכיטקטורה, ישנם מנצחים ברורים: H100 שולט ב-A100 וקוונטיזציה מופחתת דיוק משפרת את ניצול הזיכרון, ההשהיה وقצב התפוקה. עם זאת, גודל אצווה ומקביליות טנزور מציגים פשרה במדדים המרכזיים שלנו. גודל אצווה גדול יותר מבצע אופטימיזציה לקצב תפוקה על חשבון השהיה מוגברת וצריכת זיכרון. מצד שני, מקביליות טנزور גבוהה יותר מגדילה את מאגר הזיכרון הזמין הכולל ומבצעת אופטימיזציה להשהיה, אך מציגה פשרה מול קצב התפוקה בשל עלויות סנכרון של כפל מטריצות מבוזר ובאמצעות נעילת משאבי GPU נוספים.

איור 4 – קצב התפוקה על פני גדלי אצווה משתנים ומקביליות טנزور עבור H100 fp8. קצב התפוקה הגבוה ביותר מגיע מ-TP-2 BS-128, ב-460% בהשוואה לקו בסיס של A100/TP-8/fp16/BS-64. עם זאת, TP-2 BS-128 היא גם התוצאה האיטית ביותר באיור 3.

התצורה הממקסמת את קצב התפוקה של הניסוי שלנו היא H100 / fp8 / TP-2 / BS-128, ב-767 טוקני פלט בשנייה לכל GPU. זהו שיפור של 460% על פני A100 / fp16 / TP-8 / BS-64. עם זאת, הדבר מגיע במחיר של השהיה כפולה - קרוב ל-42000ms עבור 512 טוקני פלט - כך שהוא עשוי להיות לא מתאים כתצורת ייצור. התוצאות של TP-4 BS-128 (626 טוק/שנייה/GPU בזמן תגובה של 26188ms) ו-TP-2 BS-32 (435 טוק/שנייה/GPU בזמן תגובה של 18821ms) עשויות לייצג פשרות טובות יותר במדדים המרכזיים שלנו.

התוצאות שלנו מראות ש:

אנו מגיעים ל-54% השהיה ו-184% קצב תפוקה באמצעות H100 בהשוואה ל-A100 בהינתן אותה תצורה, המשתפרת ל-49% ו-202% בהתאמה כאשר H100 מנצל את התמיכה המובנית שלו ב-fp8.

בעת מיקסום קצב התפוקה בכפוף למגבלת השהיה, H100 / fp8 / TP-8 / BS-128 מניב 251% קצב תפוקה בהשוואה ל-A100 / fp16 / TP-8 / BS-64, שכן הוא יכול לעבד אצווה כפולה במהירות מהירה יותר.

ניצול H100 עם TP-2 עם fp8, אנו יכולים להשיג 373% מקצב התפוקה של A100 / fp16 / TP-8 / BS-128, עם עלייה של פחות מ-10% בהשהיה.

גודל אצווה ומקביליות טנزور מציגים פשרה בין קצב תפוקה להשהיה עבור מפעיל מערכת הסקת מסקנות של LLM.

תוצאות אלו גורמות לנו להרגיש בטוחים לגבי מעבר מלא למעבדים גרפיים H100 במערך החالحורה המבוסס A100 הקודם שלנו. אנו שמחים להיות מסוגלים לאשר את שיפורי הביצועים שפורסמו על ידי NVIDIA ומצפים לפריצות הדרך הבאות שלהם בחומרה מואצת.

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

בטווח הקצר, pplx-api תסיר את מגבלות הקצב ותציע מודלי שפה גדולים מותאמים אישית נוספים של Perplexity, כולל מודל שפה גדול המופעל באמצעות אינטרנט עם עיגון (grounding) לעובדות.

הירשם ל-Perplexity Pro בכתובת perplexity.ai/pro. קבל גישה ל-pplx-api החדשני שלנו, ונצל את היכולות המתקדמות הללו בפרויקטים שלך. גלה עוד על pplx-api בבלוג שלנו.

מעוניין לעצב את עתיד הבינה המלאכותית? אנחנו מגייסים! היה חלק מצוות המניע תשתית מודלי שפה גדולים גנרטיבית בהיקף עצום. גלה הזדמנויות ב-Perplexity Careers.

אראש היידארי, גריגורי אלکسیيف, קווין הו, דניס יארاتס

הגדרת הניסוי

מדדים מרכזיים:

קבועים:

מודל בינה מלאכותית

ערכת נתונים של טוקני קלט/פלט

גרסת תוכנה

משתנים

ארכיטקטורת מעבד גרפי (GPU)

מקביליות טנزور

קוונטיזציה (כימות)

גודל אצווה

תוצאות

סיכום

מה הלאה

מחברים: