סמן וייעל פריסת נקודות קצה באמזון SageMaker JumpStart | שירותי האינטרנט של אמזון

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

פוסט זה בוחן את מערכות היחסים הללו באמצעות מידוד מקיף של LLMs הזמינים באמזון SageMaker JumpStart, כולל גרסאות Llama 2, Falcon ומיסטרל. עם SageMaker JumpStart, מתרגלי ML יכולים לבחור מתוך מבחר רחב של מודלים של בסיס זמינים לציבור לפריסה עבור ייעודיים אמזון SageMaker מופעים בתוך סביבה מבודדת רשת. אנו מספקים עקרונות תיאורטיים לגבי האופן שבו מפרטי מאיץ משפיעים על מידוד LLM. אנו גם מדגימים את ההשפעה של פריסת מופעים מרובים מאחורי נקודת קצה אחת. לבסוף, אנו מספקים המלצות מעשיות להתאמת תהליך הפריסה של SageMaker JumpStart כך שיתאים לדרישות שלך לגבי חביון, תפוקה, עלות ומגבלות על סוגי מופעים זמינים. כל תוצאות ההשוואה כמו גם ההמלצות מבוססות על תכליתי מחברה שתוכל להתאים למקרה השימוש שלך.

הפריסה של benchmarking של נקודות קצה

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

ערכי השהיה ותפוקה אלו תואמים לעומסים עם 256 אסימוני קלט ו-256 אסימוני פלט. תצורת ההשהיה הנמוכה ביותר מגבילה את הגשת המודל לבקשה אחת במקביל, ותצורת התפוקה הגבוהה ביותר ממקסמת את המספר האפשרי של בקשות במקביל. כפי שאנו יכולים לראות בהשוואה שלנו, הגדלת בקשות במקביל מגדילה באופן מונוטוני את התפוקה עם שיפור הולך ופוחת עבור בקשות במקביל גדולות. בנוסף, הדגמים מרוסקים במלואם במופע הנתמך. לדוגמה, מכיוון שלמופע ml.g5.48xlarge יש 8 GPUs, כל דגמי SageMaker JumpStart המשתמשים במופע זה מנותקים באמצעות מקביליות טנזור בכל שמונת המאיצים הזמינים.

אנו יכולים לציין כמה נקודות מוצא מהנתון הזה. ראשית, לא כל הדגמים נתמכים בכל המופעים; חלק מהדגמים הקטנים יותר, כגון Falcon 7B, אינם תומכים בפיצוץ דגמים, בעוד לדגמים גדולים יותר דרישות משאבי מחשוב גבוהות יותר. שנית, ככל שהריסוק גדל, הביצועים בדרך כלל משתפרים, אך לא בהכרח משתפרים עבור דגמים קטנים. הסיבה לכך היא שדגמים קטנים כמו 7B ו-13B כרוכים בתקורת תקשורת משמעותית כאשר הם נפצלים על פני יותר מדי מאיצים. נדון בזה יותר לעומק בהמשך. לבסוף, מופעים של ml.p4d.24xlarge נוטים לקבל תפוקה טובה יותר באופן משמעותי עקב שיפורי רוחב הפס של הזיכרון של A100 על פני A10G GPUs. כפי שנדון בהמשך, ההחלטה להשתמש בסוג מופע מסוים תלויה בדרישות הפריסה שלך, לרבות אילוצי חביון, תפוקה ומגבלות עלויות.

כיצד תוכל להשיג את ערכי תצורת האחזור הנמוכים ביותר והתפוקה הגבוהה ביותר? נתחיל בהתוויית זמן השהייה לעומת תפוקה עבור נקודת קצה של Llama 2 7B במופע ml.g5.12xlarge עבור מטען עם 256 אסימוני קלט ו-256 אסימוני פלט, כפי שניתן לראות בעקומה הבאה. עקומה דומה קיימת עבור כל נקודת קצה LLM פרוסה.

ככל שהמקבילות גדלה, התפוקה והשהייה גם גדלים באופן מונוטוני. לכן, נקודת האחזור הנמוכה ביותר מתרחשת בערך בקשות בו-זמנית של 1, ואתה יכול להגדיל בצורה חסכונית את תפוקת המערכת על ידי הגדלת בקשות במקביל. קיימת "ברך" ברורה בעקומה הזו, שבה ברור שרווחי התפוקה הקשורים במקביליות נוספת אינם עולים על העלייה הקשורה בהשהיה. המיקום המדויק של הברך הוא ספציפי לשימוש במקרה; מתרגלים מסוימים עשויים להגדיר את הברך בנקודה שבה חריגה מדרישת השהייה שצוינה מראש (לדוגמה, 100 ms/token), בעוד שאחרים עשויים להשתמש במדדי בדיקת עומס ובשיטות תיאוריית תורים כמו כלל חצי השהייה, ואחרים עשויים להשתמש מפרטי מאיץ תיאורטיים.

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

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

אנו רואים כמה דפוסים נוספים בנתונים אלה. כאשר מגדילים את גודל ההקשר, השהיה עולה והתפוקה פוחתת. לדוגמה, ב-ml.g5.2xlarge עם מקיפות של 1, התפוקה היא 30 אסימונים/שנייה כאשר מספר האסימונים הכולל הוא 512, לעומת 20 אסימונים/שנייה אם מספר האסימונים הכולל הוא 4,096. הסיבה לכך היא שלוקח יותר זמן לעבד את הקלט הגדול יותר. אנו יכולים גם לראות שהגדלת יכולת ה-GPU והפיצול משפיעים על התפוקה המקסימלית ועל הבקשות המקסימליות הנתמכות במקביל. הטבלה מראה כי ל-Llama 2 7B יש ערכי תפוקה מקסימליים שונים במיוחד עבור סוגי מופעים שונים, וערכי התפוקה המקסימלית הללו מתרחשים בערכים שונים של בקשות במקביל. מאפיינים אלו יגרמו למטפל ב-ML להצדיק את העלות של מקרה אחד על פני אחר. לדוגמה, בהינתן דרישת השהייה נמוכה, המתרגל עשוי לבחור מופע ml.g5.12xlarge (4 A10G GPUs) על פני מופע ml.g5.2xlarge (1 A10G GPU). אם ניתנת דרישת תפוקה גבוהה, השימוש במופע ml.p4d.24xlarge (8 A100 GPUs) עם ריסוק מלא יהיה מוצדק רק בהתמדה גבוהה. עם זאת, שים לב שלעיתים קרובות מועיל במקום לטעון מספר רכיבי הסקה של דגם 7B על מופע יחיד של ml.p4d.24xlarge; תמיכה כזו מרובת דגמים נדון בהמשך הפוסט הזה.

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

הגיוני מפרטי מאיץ

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

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

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

קבץ קבצים במטמון וזיכרון המכשיר

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

בנוסחה זו, B הוא גודל אצווה ו-N הוא מספר המאיצים. לדוגמה, דגם Llama 2 7B ב-FP16 (2 בתים/פרמטר) המוגש על A10G GPU (24 GB DRAM) צורך כ-14 GB, ומשאיר 10 GB למטמון KV. חיבור של אורך ההקשר המלא של המודל (N = 4096) והפרמטרים הנותרים (n_layers=32, n_kv_attention_heads=32, ו-d_attention_head=128), ביטוי זה מראה שאנו מוגבלים לשרת אצווה של ארבעה משתמשים במקביל עקב אילוצי DRAM . אם אתה צופה במדדים המקבילים בטבלה הקודמת, זהו קירוב טוב לברך הנצפית בעקומת חביון-תפוקה זו. שיטות כגון תשומת לב שאילתה מקובצת (GQA) יכול להקטין את גודל המטמון של KV, במקרה של GQA באותו גורם זה מקטין את מספר ראשי ה-KV.

עוצמה אריתמטית ורוחב פס של זיכרון המכשיר

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

השמיים עוצמה אריתמטית, או היחס בין פעולות מחשוב לגישה לזיכרון, עבור פעולה קובעת אם היא מוגבלת על ידי רוחב הפס של הזיכרון או קיבולת המחשוב בחומרה שנבחרה. לדוגמה, A10G GPU (משפחת מופעים מסוג g5) עם 70 TFLOPS FP16 ורוחב פס של 600 GB/sek יכול לחשב כ-116 פעולות/בתים. A100 GPU (משפחת מופעים מסוג p4d) יכול לחשב כ-208 אופציות/בתים. אם העוצמה האריתמטית של מודל שנאי היא מתחת לערך הזה, היא קשורה לזיכרון; אם זה למעלה, זה קשור למחשב. מנגנון הקשב עבור Llama 2 7B דורש 62 פעולות/בתים עבור גודל אצווה 1 (להסבר, ראה מדריך להסקת LLM וביצועים), מה שאומר שהוא קשור בזיכרון. כאשר מנגנון הקשב קשור לזיכרון, FLOPS יקרים נותרים ללא שימוש.

ישנן שתי דרכים לנצל טוב יותר את המאיץ ולהגביר את העוצמה האריתמטית: להפחית את הגישה לזיכרון הנדרשת עבור הפעולה (זה מה FlashAttention מתמקד ב) או להגדיל את גודל האצווה. עם זאת, ייתכן שלא נוכל להגדיל את גודל האצווה שלנו מספיק כדי להגיע למשטר הקשור למחשוב אם ה-DRAM שלנו קטן מכדי להחזיק את מטמון ה-KV המתאים. קירוב גולמי של גודל האצווה הקריטי B* המפריד בין משטרי חישוב מחושב לזיכרון עבור הסקת מפענח GPT סטנדרטית מתואר על ידי הביטוי הבא, כאשר A_mb הוא רוחב הפס של זיכרון המאיץ, A_f הוא המאיץ FLOPS ו-N הוא המספר של מאיצים. גודל אצווה קריטי זה יכול להיגזר על ידי מציאת היכן זמן הגישה לזיכרון שווה לזמן חישוב. מתייחס לכתוב בלוג זה להבין את משוואה 2 ואת הנחותיה בפירוט רב יותר.

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

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

כדי להשוות מאיצי ML על סמך המפרט שלהם, אנו ממליצים על הדברים הבאים. ראשית, חשב את גודל האצווה הקריטי המשוער עבור כל סוג מאיץ לפי המשוואה השנייה ואת גודל המטמון KV עבור גודל האצווה הקריטי לפי המשוואה הראשונה. לאחר מכן תוכל להשתמש ב-DRAM הזמין במאיץ כדי לחשב את המספר המינימלי של מאיצים הנדרשים כדי להתאים לפרמטרים של KV cache ופרמטרים של הדגם. אם תחליט בין מספר מאיצים, תעדוף מאיצים לפי סדר העלות הנמוכה ביותר ל-GB/שנייה של רוחב פס זיכרון. לבסוף, בדוק את התצורות הללו ובדוק מהי העלות/אסימון הטובים ביותר עבור הגבול העליון של זמן האחזור הרצוי.

בחר תצורת פריסת נקודת קצה

LLMs רבים המופצים על ידי SageMaker JumpStart משתמשים ב- טקסט-דור-מסק (TGI) מיכל SageMaker להגשת דגם. הטבלה הבאה דנה כיצד להתאים מגוון פרמטרים של הגשת מודלים כדי להשפיע על הגשת המודל שמשפיעה על עקומת החביון-תפוקה או להגן על נקודת הקצה מפני בקשות שיעמיסו על נקודת הקצה. אלו הם הפרמטרים העיקריים שבהם אתה יכול להשתמש כדי להגדיר את פריסת נקודות הקצה שלך עבור מקרה השימוש שלך. אלא אם צוין אחרת, אנו משתמשים בברירת מחדל פרמטרי מטען של יצירת טקסט ו משתני סביבת TGI.

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

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

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

צמצם את זמן האחזור

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

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

from sagemaker.jumpstart.model import JumpStartModel model = JumpStartModel( model_id="meta-textgeneration-llama-2-7b", model_version="3.*", instance_type="ml.g5.12xlarge", env={ "MAX_CONCURRENT_REQUESTS": "1", "MAX_INPUT_TOKENS": "256", "MAX_TOTAL_TOKENS": "512", },
)
predictor = model.deploy(accept_eula=False) # Change EULA acceptance to True

שים לב שמספרי ההשהיה משתנים בהתאם למספר אסימוני הקלט והפלט. עם זאת, תהליך הפריסה נשאר זהה למעט משתני הסביבה MAX_INPUT_TOKENS ו MAX_TOTAL_TOKENS. כאן, משתני סביבה אלה מוגדרים לסייע להבטיח דרישות השהייה של נקודות קצה מכיוון שרצפי קלט גדולים יותר עשויים להפר את דרישת ההשהיה. שימו לב ש- SageMaker JumpStart כבר מספק את משתני הסביבה האופטימליים האחרים בעת בחירת סוג המופע; לדוגמה, שימוש ב-ml.g5.12xlarge יקבע SM_NUM_GPUS עד 4 בסביבת המודל.

מקסימום תפוקה

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

כדי להשיג תפוקה מקסימלית עבור דגם, אתה יכול להשתמש בקוד הבא:

from sagemaker.jumpstart.model import JumpStartModel model = JumpStartModel( model_id="meta-textgeneration-llama-2-7b", model_version="3.*", instance_type="ml.g5.12xlarge", env={ "MAX_CONCURRENT_REQUESTS": "128", # For your application, identify it from the benchmarking table with the maximum feasible concurrent requests. "MAX_INPUT_TOKENS": "256", "MAX_TOTAL_TOKENS": "512", },
)
predictor = model.deploy(accept_eula=False) # Change EULA acceptance to True

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

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

מזעור עלות

האפשרות הראשונה למזער עלות כוללת מזעור עלות לשעה. בעזרת זה, אתה יכול לפרוס דגם נבחר במופע SageMaker בעלות הנמוכה ביותר לשעה. לתמחור בזמן אמת של מופעי SageMaker, עיין ב תמחור אמזון SageMaker. באופן כללי, סוג המופע המוגדר כברירת מחדל עבור SageMaker JumpStart LLMs הוא אפשרות הפריסה בעלות הנמוכה ביותר.

האפשרות השנייה למזער את העלות כוללת צמצום העלות ליצירת 1 מיליון אסימונים. זהו טרנספורמציה פשוטה של ​​הטבלה שדיברנו עליה קודם כדי למקסם את התפוקה, שבה אתה יכול לחשב תחילה את הזמן שלוקח בשעות כדי ליצור מיליון אסימונים (1e1 / תפוקה / 6). לאחר מכן תוכל להכפיל את הזמן הזה כדי ליצור מיליון אסימונים עם המחיר לשעה של מופע SageMaker שצוין.

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

פשרה מקבילה לטנזור לעומת ריבוי דגמים

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

כאן, אנו פורסים נקודות קצה של Llama 2 7B ו-13B במופעים ml.p4d.24xlarge עם דרגות מקבילות לטנזור (TP) של 1, 2, 4 ו-8. למען הבהירות בהתנהגות המודל, כל אחת מנקודות הקצה הללו טוענת רק מודל בודד.

הניתוחים הקודמים שלנו כבר הראו יתרונות תפוקה משמעותיים במופעי ml.p4d.24xlarge, מה שמתורגם לרוב לביצועים טובים יותר מבחינת עלות ליצירת מיליון אסימונים על פני משפחת המופעים של g1 בתנאי עומס גבוהים של בקשות במקביל. ניתוח זה מדגים בבירור שעליך לשקול את ההחלפה בין פיצול מודל לשכפול מודל בתוך מופע אחד; כלומר, מודל מפורק לחלוטין אינו בדרך כלל השימוש הטוב ביותר במשאבי מחשוב ml.p5d.4xlarge עבור משפחות מודלים 24B ו-7B. למעשה, עבור משפחת דגמי ה-13B, אתה משיג את התפוקה הטובה ביותר עבור העתק של דגם בודד עם דרגת מקבילית טנזור של 7 במקום 4.

מכאן, אתה יכול להסיק שתצורת התפוקה הגבוהה ביותר עבור מודל 7B כוללת דרגת טנזור מקבילה של 1 עם שמונה העתקים של דגמים, ותצורת התפוקה הגבוהה ביותר עבור מודל 13B היא ככל הנראה דרגת מקביל טנזור של 2 עם ארבעה העתקים של דגמים. למידע נוסף על איך להשיג זאת, עיין ב הפחת את עלויות פריסת המודל ב-50% בממוצע באמצעות התכונות העדכניות ביותר של Amazon SageMaker, המדגים את השימוש בנקודות קצה מבוססות רכיבי הסקה. עקב טכניקות איזון עומסים, ניתוב שרת ושיתוף משאבי מעבד, ייתכן שלא תשיג באופן מלא שיפורי תפוקה השווים בדיוק למספר העתקים כפול התפוקה עבור עותק בודד.

קנה מידה אופקי

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

model = JumpStartModel( model_id="meta-textgeneration-llama-2-7b", model_version="3.*", instance_type="ml.g5.2xlarge",
)
predictor = model.deploy( accept_eula=False, # Change EULA acceptance to True initial_instance_count = 3,
)

הטבלה הבאה מציגה את רווח התפוקה כגורם של מספר המקרים עבור דגם Llama 2 7B.

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

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

הפעל את נקודת הקצה עם בקשות במקביל

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

payload = { "inputs": "I believe the meaning of life is to ", "parameters": {"max_new_tokens": 100, "details": True},
}
total_requests = 1000
payloads = [payload,] * total_requests

בעת שליחת מספר רב של בקשות לממשק ה-API של SageMaker בזמן ריצה, אתה עלול להיתקל בשגיאות מצערת. כדי למתן את זה, אתה יכול ליצור לקוח זמן ריצה מותאם אישית של SageMaker שמגדיל את מספר ניסיונות הניסיון החוזר. אתה יכול לספק את אובייקט ההפעלה של SageMaker שהתקבל לאחד מה- JumpStartModel קונסטרוקטור או sagemaker.predictor.retrieve_default אם תרצה לצרף מנבא חדש לנקודת קצה שכבר נפרסה. בקוד הבא, אנו משתמשים באובייקט הפעלה זה בעת פריסת מודל Llama 2 עם תצורות ברירת מחדל של SageMaker JumpStart:

import boto3
from botocore.config import Config
from sagemaker.session import Session
from sagemaker.jumpstart.model import JumpStartModel sagemaker_session = Session( sagemaker_runtime_client=boto3.client( "sagemaker-runtime", config=Config(connect_timeout=10, retries={"mode": "standard", "total_max_attempts": 20}), )
)
model = JumpStartModel( model_id="meta-textgeneration-llama-2-7b", model_version="3.*", sagemaker_session=sagemaker_session
)
predictor = model.deploy(accept_eula=False) # Change EULA acceptance to True

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

import time
from concurrent import futures concurrent_requests = 128 time_start = time.time()
with futures.ThreadPoolExecutor(max_workers=concurrent_requests) as executor: responses = list(executor.map(predictor.predict, payloads)) total_tokens = sum([response[0]["details"]["generated_tokens"] for response in responses])
token_throughput = total_tokens / (time.time() - time_start)

התוצאה היא יצירת 100,000 אסימונים בסך הכל עם תפוקה של 1255 אסימונים/שנייה במופע יחיד של ml.g5.2xlarge. תהליך זה לוקח בערך 80 שניות לעיבוד.

שימו לב שערך התפוקה הזה שונה באופן ניכר מהתפוקה המקסימלית עבור Llama 2 7B ב-ml.g5.2xlarge בטבלאות הקודמות של פוסט זה (486 אסימונים/שנייה ב-64 בקשות במקביל). הסיבה לכך היא שמטען הקלט משתמש ב-8 אסימונים במקום 256, ספירת אסימוני הפלט היא 100 במקום 256, וספירת האסימונים הקטנה יותר מאפשרת 128 בקשות במקביל. זוהי תזכורת אחרונה לכך שכל מספרי האחזור והתפוקה תלויים במטען! שינוי ספירת אסימוני מטען ישפיע על תהליכי אצווה במהלך הגשת המודל, אשר בתורו ישפיע על זמני המילוי המוקדמים, הפענוח והתור של היישום שלך.

סיכום

בפוסט זה, הצגנו בנצ'מרקינג של SageMaker JumpStart LLMs, כולל Llama 2, Mistral ו-Falcon. הצגנו גם מדריך למיטוב זמן האחזור, התפוקה והעלות עבור תצורת פריסת נקודות הקצה שלך. אתה יכול להתחיל על ידי הפעלת ה מחברת משויכת כדי למדוד את מקרה השימוש שלך.

על הכותבים

 ד"ר קייל אולריך הוא מדען יישומי בצוות אמזון SageMaker JumpStart. תחומי המחקר שלו כוללים אלגוריתמים של למידת מכונה ניתנים להרחבה, ראייה ממוחשבת, סדרות זמן, אי-פרמטריות בייסיאניות ותהליכי גאוס. הדוקטורט שלו הוא מאוניברסיטת דיוק והוא פרסם מאמרים ב-NeurIPS, Cell, and Neuron.

Dr. Vivek Madan הוא מדען יישומי בצוות אמזון SageMaker JumpStart. הוא קיבל את הדוקטורט שלו מאוניברסיטת אילינוי באורבנה-שמפיין והיה חוקר פוסט דוקטורט בג'ורג'יה טק. הוא חוקר פעיל בלמידת מכונה ועיצוב אלגוריתמים ופרסם מאמרים בכנסים של EMNLP, ICLR, COLT, FOCS ו-SODA.

ד"ר אשיש חתן הוא מדען יישומי בכיר עם Amazon SageMaker JumpStart ומסייע בפיתוח אלגוריתמים של למידת מכונה. הוא קיבל את הדוקטורט שלו מאוניברסיטת אילינוי אורבנה-שמפיין. הוא חוקר פעיל בלמידת מכונה והסקה סטטיסטית, ופרסם מאמרים רבים בכנסים NeurIPS, ICML, ICLR, JMLR, ACL ו-EMNLP.

ז'ואאו מורה הוא ארכיטקט פתרונות מומחה בינה מלאכותית/ML בכיר ב-AWS. João עוזר ללקוחות AWS - החל מסטארט-אפים קטנים ועד ארגונים גדולים - לאמן ולפרוס מודלים גדולים ביעילות, ובאופן רחב יותר לבנות פלטפורמות ML ב-AWS.

• הפצת תוכן ויחסי ציבור מופעל על ידי SEO. קבל הגברה היום.
• PlatoData.Network Vertical Generative Ai. העצים את עצמך. גישה כאן.
• PlatoAiStream. Web3 Intelligence. הידע מוגבר. גישה כאן.
• PlatoESG. פחמן, קלינטק, אנרגיה, סביבה, שמש, ניהול פסולת. גישה כאן.
• PlatoHealth. מודיעין ביוטכנולוגיה וניסויים קליניים. גישה כאן.
• מקור: https://aws.amazon.com/blogs/machine-learning/benchmark-and-optimize-endpoint-deployment-in-amazon-sagemaker-jumpstart/