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

שנה קודמת כלומר, 2023 הייתה ללא ספק שנה בולטת מבחינת התקדמות בתחום תחום הבינה המלאכותית. באופן מסורתי תמיד הרגישו שכדי להפיק את המרב מ-AI צריך השקעה חזקה בתשתית ובתמיכה. זה מעולם לא היה ברור כמו בשנה שעברה, בגלל כניסתו של AI Generative. רוב טכנולוגיית הבינה המלאכותית המסורתית שלפני ה-Gen AI פעלה בצורה סבירה בקומץ של GPUs ו-RAM. כל זה השתנה לאחר שחרורו של GPT-3 על ידי Open AI ושחרור נוסף של מספר רב של דגמי קוד פתוח. דגמי השפה הגדולים הללו היו גדולים בכל מובן, הם נזקקו למשאבי חישוב מסיביים בצורה של GPUs בעלי ביצועים גבוהים וזיכרון גדול במונחים של זיכרון RAM. מגזר השירותים הפיננסיים בפרט מוכר כמרוויח העליון מטכנולוגיה זו. ניתן לייעל במידה רבה את מספר המשאבים המשמשים במגזר זה בניתוח ועיבוד נתונים, במיוחד נתונים טקסטואליים באמצעות LLMs. למעשה, ה-LLMs הפתוח הם שמצאו את התועלת הגדולה ביותר במגזר זה. יש לכך מספר סיבות

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

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

זה די ברור שהישימות של LLM בקוד פתוח במגזר הפיננסי הולכת וגוברת אך במקביל יש אתגרים רבים ביישום בסיסי של פתרון LLM. המספר העצום של המשאבים הנדרשים הן מבחינת יכולת החישוב והן מבחינת הזיכרון הוא יקר וקשה לתמוך בו. קח את המקרה של אבן דרך לאחרונה בחשיפת פרויקט Big Science של BLOOM, מודל עם 176 מיליארד פרמטרים המסוגל לתמוך ב-46 שפות טבעיות ו-13 שפות תכנות. בעוד שהנגישות הציבורית של מודלים אלה של 100B+ פרמטרים הקלה על השימוש בהם, האתגרים הנלווים של זיכרון ועלויות חישוב גבוהות נמשכים. יש לציין כי דגמים כמו OPT-175B ו-BLOOM-176B דורשים יותר מ-350 GB של זיכרון מאיץ להסקת מסקנות, ואפילו יותר עבור כוונון עדין. כתוצאה מכך, השימוש המעשי של LLMs כאלה מחייב לעתים קרובות מספר רב של GPUs מתקדמים או אשכולות מרובי צמתים, אשר בשל העלויות הגבוהות שלהם, מגביל את הנגישות עבור חוקרים ועוסקים רבים.

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

לקוח – גישת שרת 

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

עיצוב ו סקירה טכנית

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

• מסקנות של מודלים בקנה מידה של מיליארדים: בתהליך יצירת האסימונים, לקוח מאחסן באופן מקומי את הטמעות האסימונים של הדגם, המהווים בדרך כלל חלק קטן מספירת הפרמטרים הכוללת ומשתלבים בנוחות בזיכרון ה-RAM של רוב המחשבים הניידים, השרתים ותחנות העבודה המודרניים. הלקוח מסתמך על שרתים לביצוע בלוקים של Transformer, כאשר כל שרת מארח מספר בלוקים עוקבים, שמספרם נקבע על ידי זיכרון ה-GPU הזמין. לפני כל מפגש מסקנות, הלקוח מקים שרשרת של שרתים שמקיפים ביחד את כל שכבות המודל. במהלך הפגישה הפעילה, הלקוח משתמש בשכבת ההטמעה המקומית כדי לאחזר וקטורי הטבעה עבור אסימוני קידומת, משדר וקטורים אלה לשרתים וקבלת ייצוגים מעודכנים. לאחר השגת התפוקות של הבלוק הסופי, הלקוח מחשב את הסתברויות האסימון הבא וחוזר על תהליך זה. שרתים שומרים על מפתחות תשומת לב וערכים מתשומות לקוח קודמות עבור שלבי הסקת מסקנות עוקבים, ולקוחות מאחסנים קלטים קודמים לכל שרת כדי להקל על החלפה מהירה אם שרת נכשל או לא מקוון.
• הדרכה למשימות במורד הזרם: בעוד שמודלים של שפה גדולה (LLMs) מצטיינים בבעיות רבות עם הנדסה מהירה פשוטה, השגת תוצאות אופטימליות דורשת לעתים קרובות הכשרה. אסטרטגיות כוונון עדין מסורתיות, הכוללות עדכון של כל פרמטרי הדגם עבור המשימה במורד הזרם, הופכות לבלתי מעשיות עבור דגמים גדולים מאוד עקב דרישות חומרה נרחבות. לדוגמה, כוונון עדין של BLOOM-176B ידרוש כמעט 3 TB של זיכרון GPU כדי להתאים למצבי מודל, שיפועים ואופטימיזציה. כדי להתמודד עם אתגר זה, קהילת ה-NLP הגתה שיטות כוונון עדין יעילות פרמטרים המשמרות את רוב פרמטרי המודל המאומנים מראש. גישות מסוימות בוחרות תת-קבוצה של פרמטרים קיימים, בעוד שאחרות מגדילות את המודל עם משקלים נוספים שניתן לאמן. למרות דרישות זיכרון נמוכות יותר, גישות יעילות פרמטרים אלו מתחרות לעתים קרובות לטובה עם כוונון עדין של מודל מלא ויכולות להתעלות עליו בתרחישים עם נתונים נמוכים.
• כוונון עדין מבוזר: הרעיון הבסיסי מאחורי כוונון עדין ברשת מבוזרת הוא שללקוחות יש פרמטרים מאומנים, בעוד שהשרתים מארחים את השכבות המקוריות שהוכשרו מראש. שרתים יכולים להריץ התפשטות לאחור דרך השכבות שלהם, ולהחזיר גרדיאנטים הנוגעים להפעלות, אבל הם לא מעדכנים פרמטרים בצד השרת. זה מאפשר ללקוחות לבצע בו-זמנית משימות הדרכה שונות על אותה סט של שרתים ללא הפרעות.

מבנה פנימי ואופטימיזציות

שיקולי ביצועים הם מכריעים להסקה מבוזרת, הכוללים שלושה היבטים מרכזיים: מהירות חישוב (השוואה של GPU למשחקים בן 5 שנים עם GPU חדש של מרכז נתונים), עיכוב בתקשורת עקב מרחק הצומת (בין יבשתי לעומת מקומי), ורוחב פס המושרה עיכוב תקשורת (10 Mbit/s מול 10 Gbit/s). בעוד שאפילו מעבדים גרפיים ברמה צרכנית כמו GeForce RTX 3070 מתהדרים ביכולת לבצע שלב מסקנות שלם של BLOOM-176B תוך פחות משנייה, האתגר טמון באילוצי הזיכרון של ה-GPU, המחייבים פתרונות יעילים. אחת הדרכים להתמודד עם זה היא באמצעות קוונטיזציה לאחסון פרמטרים אופטימלי ותעדוף שרתים דינמי למהירות תקשורת משופרת.

• שימוש ב-GPUs לצרכן: בהתחשב בעובדה שלכל שרת יש לפחות 16 ג'יגה-בייט של זיכרון RAM של מעבד ו-8 ג'יגה-בייט של זיכרון GPU, המטרה העיקרית היא למזער את טביעת הזיכרון של הדגם, ולאפשר לכל מכשיר להכיל יותר בלוקים של רובוטריקים. עבור BLOOM עם פרמטרים של 176B, הדורשים 352 GB של זיכרון GPU בדיוק של 16 סיביות, נוכל לייעל זאת על ידי דחיסת מצבים נסתרים באמצעות קוונטיזציה דינמית בלוק והפחתת המשקולות לדיוק של 8 סיביות באמצעות פירוק מטריצה ​​מעורבת. זה מביא להפחתה משמעותית במספר הצמתים הנדרש, למעשה מפחית את זמן ההשהיה במחצית וממזער את הסבירות לכשל.
• כְּבִישָׁה תקשורת חוצצים:
  אנו יכולים להשתמש בקונטיזציה Dynamic Blockwise במצבים נסתרים לפני תקשורת מקבילה לצינור, ולצמצם בחצי את דרישות רוחב הפס מבלי לפגוע באיכות הייצור. 
• דחיסת משקולות דגם: שימוש בפירוק מטריצה ​​מעורבת של 8 סיביות להכפלת מטריצה, מקטין את טביעת הרגל של הזיכרון בערך בחצי מבלי להקריב את האיכות.
• שיתוף פעולה דרך האינטרנט: על מנת להבטיח מסקנות ואימון אמינים למרות צמתים שמצטרפים, עוזבים או נכשלים. אנו יכולים להשתמש בספריית hivemind להדרכה מבוזרת ולפרוטוקולים מותאמים אישית סובלני תקלות עבור שרתים ולקוחות.

דמוקרטיזציה ודאגות לפרטיות

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

סיכום

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

• הפצת תוכן ויחסי ציבור מופעל על ידי SEO. קבל הגברה היום.
• PlatoData.Network Vertical Generative Ai. העצים את עצמך. גישה כאן.
• PlatoAiStream. Web3 Intelligence. הידע מוגבר. גישה כאן.
• PlatoESG. פחמן, קלינטק, אנרגיה, סביבה, שמש, ניהול פסולת. גישה כאן.
• PlatoHealth. מודיעין ביוטכנולוגיה וניסויים קליניים. גישה כאן.
• מקור: https://www.finextra.com/blogposting/25469/a-case-for-distributed-computing-for-llms-in-fintech?utm_medium=rssfinextra&utm_source=finextrablogs