By ד"ר מריו מייקל קרל, מנהיג למידת מכונות ראשי ב- Graphcore & מאטי קוסק, מומחה ליישומי AI ב- Graphcore

תמונה מאת המחבר.

 

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

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

הצגנו את האלגוריתם היעיל ביותר של ריבועי היסטוגרמה לאריזה היסטוגרפית (או NNLSHP) של Graphcore וכן את אלגוריתם ה- BERT שלנו המיושם על רצפים ארוזים בנייר חדש [1].

פסולת חישובית ב- NLP עקב ריפוד רצף

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

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

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

לרצפים יש וריאציה גדולה של אורך משתי סיבות:

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

מילוי האורך עד האורך המרבי של 512 גורם לכך ש -50% מכלל האסימונים יהיו אסימוני ריפוד. החלפת 50% הריפוד בנתונים אמיתיים עלולה לגרום לעיבוד של 50% יותר נתונים באותו מאמץ חישובי וכך פי 2 מהירות בתנאים אופטימליים.

איור 1: הפצות נתונים של ויקיפדיה. תמונה מאת המחבר.

 

האם זה ספציפי לוויקיפדיה? לא.

ובכן, אז האם זה ספציפי לשפה? לא.

למעשה, התפלגויות אורך מוטות נמצאות בכל מקום: בשפה, גנומיקה וקיפול חלבונים. איורים 2 ו -3 מראים הפצות עבור מערך הנתונים SQuAD 1.1 ומערכות נתונים GLUE.

איור 2: SQuAD 1.1 BERT היסטוגרמה באורך רצף מערכי נתונים לפני הכשרת אורך רצף מקסימלי של 384. תמונה מאת המחבר.

 


איור 3: היסטוגרמות באורך רצף הנתונים של GLUE באורך רצף מרבי של 128. תמונה מאת המחבר.

 

כיצד נוכל להתמודד עם האורכים השונים תוך הימנעות מהפסולת החישובית?

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

גישה זו דורשת שלושה מרכיבים מרכזיים:

1. אלגוריתם יעיל להחליט אילו דגימות יש להרכיב כדי שיהיה להם מעט ריפוד שנותר ככל האפשר
2. התאמת מודל BERT לעיבוד חבילות במקום רצפים
3. והתאמת ההפרפרמטרים

אֲרִיזָה

 
 
בהתחלה נראה שלא סביר שתצליח לארוז מערך נתונים גדול כמו ויקיפדיה ביעילות רבה. בעיה זו ידועה בכינוי אריזת פחים. גם כאשר האריזה מוגבלת לשלושה רצפים או פחות, הבעיה המתקבלת עדיין תהיה מלאה ב- NP, ללא פתרון אלגוריתמי יעיל. אלגוריתמי האריזה הקיימים הקיימים לא היו מבטיחים כיוון שהמורכבות שלהם הייתה לפחות O(n יומן(n)), איפה n הוא מספר הרצפים (~ 16M לוויקיפדיה). התעניינו בגישות שישתלבו היטב למיליוני רצפים.

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

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

אורך הרצף המקסימלי שלנו היה 512. לכן, המעבר להיסטוגרמה הפחית את הממד והמורכבות מ -16 מיליון רצפים ל -512 ספירות אורך. מתן מקסימום של שלושה רצפים בחבילה הפחית את מספר שילובי האורך המותרים ל -22K. זה כבר כלל את הטריק לדרוש את מיון הרצפים לפי האורך בחבילה. אז למה שלא תנסו 4 רצפים? זה הגדיל את מספר השילובים מ 22K ל 940K, וזה היה יותר מדי לגישת הדוגמנות הראשונה שלנו. בנוסף, עומק 3 כבר השיג יעילות אריזה גבוהה להפליא.

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

אריזה היסטוגרמית של ריבועים לפחות לא שליליים (NNLSHP)

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

החלק המסובך היה מטריצת האסטרטגיה. לכל טור יש סכום מקסימלי של שלושה ומקודד אילו רצפים ארוזים יחד כך שיתאימו בדיוק לאורך הכולל הרצוי; 512 במקרה שלנו. השורות מקודדות כל אחד מהצירופים הפוטנציאליים כדי להגיע לאורך לאורך האורך הכולל. וקטור האסטרטגיה x הוא מה שחיפשנו, המתאר את התדירות שבה אנו בוחרים את אחד משילובי 20k. מעניין לציין כי רק כ -600 שילובים נבחרו בסוף. כדי לקבל פתרון מדויק, האסטרטגיה נחשבת x יצטרכו להיות מספרים שלמים חיוביים, אבל הבנו שפתרון מעוגל משוער עם רק לא שלילי x היה מספיק. לקבלת פתרון משוער, ניתן להשתמש בפותר פשוט מהקופסא כדי לקבל תוצאה תוך 30 שניות.

איור 4: דוגמה למטריצת אסטרטגיה עבור אורך רצף 8 ועומק אריזה 3. השורות מייצגות את רצפי האורך 1-8 הנאספים יחד והעמודות עומדות על כל שילובי האורך האפשריים בחבילה ללא הזמנה מיוחדת. תמונה מאת המחבר.

 

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

אריזת היסטוגרמה הקצרה ביותר

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

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

ישנם ארבעה מרכיבים לאלגוריתם הראשון שלנו, אריזה היסטוגרמית הקצרה ביותר (SPFHP):

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

גישה זו הייתה הפשוטה ביותר ליישום וארכה 0.02 שניות בלבד.

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

כיצד עובדת האריזה ההיסטוגרמית הקצרה ביותר. אנימציה מאת המחבר.

 

ויקיפדיה, SQuAD 1.1, תוצאות אריזה של GLUE

 
 
טבלה 1, 2 ו -3 מציגות את תוצאות האריזה של שני האלגוריתמים המוצעים שלנו. עומק האריזה מתאר את המספר המרבי של רצפים ארוזים. עומק האריזה 1 הוא יישום ה- BERT הבסיסי. עומק האריזה המרבי המתרחש, כאשר אין הגבלה מוגדרת מסומן עם "מקסימום" נוסף. ה מספר חבילות מתאר את אורך מערך הנתונים החדש. יְעִילוּת הוא אחוז האסימונים האמיתיים במערך הנתונים הארוז. ה גורם אריזה מתאר את המהירות הפוטנציאלית המתקבלת בהשוואה לעומק האריזה 1.

היו לנו ארבע תצפיות עיקריות:

1. ככל שהפצה מוטה יותר, כך יתרונות האריזה גבוהים יותר.
2. כל מערכי הנתונים נהנים מאריזה. חלקם אפילו יותר מפקטור 2.
3. SPFHP מתייעל כאשר עומק האריזה אינו מוגבל.
4. למספר מרבי של 3 רצפים ארוזים, ככל שה- NNLSHP מורכב יותר כך הוא יעיל יותר (99.75 לעומת 89.44).

טבלה 1: תוצאות ביצועי מפתח של אלגוריתמי האריזה המוצעים (SPFHP ו- NNLSHP) בויקיפדיה. תמונה מאת המחבר.

 


טבלה 2: תוצאות הביצועים של אלגוריתמי האריזה המוצעים עבור הכשרה מוקדמת SQUaD 1.1 BERT. תמונה מאת המחבר.

 


טבלה 3: תוצאות הביצועים של אלגוריתמי האריזה המוצעים עבור מערך הנתונים של GLUE. מוצגים רק הבסיס ותוצאות האריזה של SPFHP מבלי להגביל את עומק האריזה. תמונה מאת המחבר.

 

התאמת עיבוד BERT

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

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

דוגמת קוד מסכת תשומת לב.

 


איור 5: דוגמה לאפס אחת מסכה

 

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

לגבי אובדן ה- MLM, הקוד נראה כך:

מדגם קוד חישוב הפסד.

 

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

אומדן תקורה והערכה של ויקיפדיה

 
 
עם השינוי שלנו ב- BERT, היו לנו שתי שאלות:

1. כמה תקורות זה מביא איתו?
2. עד כמה התקורה תלויה במספר הרצפים המרבי שחוברים לחבילה?

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

טבלה 4: הערכת השוואת מהירות משוערת של אלגוריתמי האריזה המוצעים (SPFHP ו- NNLSHP) בויקיפדיה. תמונה מאת המחבר.

 

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

התאמות Hyperparameter

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

איור 6: השוואה בין עקומות למידה לעיבוד ארוז ובלתי ארוז גודל אצווה מופחת לגישה הצפופה. תמונות מאת המחבר.

 

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

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

איור 7: השוואה בין עקומות למידה לעיבוד ארוז ובלתי ארוז heuristics הוחל. תמונות מאת המחבר.

 

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

עכשיו השאלה היא אם בתרחיש המעשי, האם אנחנו באמת מקבלים את המהירות הצפויה?

איור 8: השוואה בין עקומות למידה לעיבוד ארוז ובלתי ארוז ב התקנה מותאמת. תמונות מאת המחבר.

 

כן אנחנו כן! השגנו מהירות נוספת מכיוון שדחסנו את העברת הנתונים.

סיכום

 
 
אריזה של משפטים יחד יכולה לחסוך מאמץ חישובי וסביבה. ניתן ליישם טכניקה זו בכל מסגרת כולל PyTorch ו- TensorFlow. השגנו מהירות מהירה של 2x ובדרך הרחבנו את המצב החדשני באלגוריתמים לאריזה.

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

קרא את העיתון

גש לקוד ב- GitHub

תודה רבה לך

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

הפניות

 
 
[1] מ 'קוסק, ס' פו, מ"מ קרל, אריזה: לקראת 2x האצת NLP BERT (2021), arXiv

 
ד"ר מריו מייקל קרל הינה מנהלת לימוד מכונה ראשית ב- Graphcore. מריו חוקר ומפתח אלגוריתמים של למידת מכונה במשך יותר מ 12 שנים, ויצר תוכנות לתעשיות מגוונות כמו רובוטיקה, רכב, תקשורת ובריאות. ב- Graphcore, הוא תרם למרשים שלנו הגשות MLPerf ויש לו תשוקה להאיץ דגמים לא סטנדרטיים חדשים כמו חישוב משוער של Bayesian לניתוח נתונים סטטיסטיים של COVID-19.

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

מְקוֹרִי. פורסם מחדש באישור.

מידע נוסף:

• בניית גרף ידע לחיפוש עבודה באמצעות BERT
• כיצד לאמן דגם BERT מאפס
• הבנת BERT עם פנים מחבקות