שפר את הביצועים של דגמי Falcon עם Amazon SageMaker | שירותי האינטרנט של אמזון

מהי המסגרת והתצורה האופטימלית לאירוח מודלים של שפה גדולה (LLMs) עבור יישומי AI מחוללים לייצור טקסט? למרות שפע האפשרויות לשרת LLM, זו שאלה שקשה לענות עליה בשל גודל הדגמים, ארכיטקטורות מודלים משתנות, דרישות ביצועים של אפליקציות ועוד. ה אמזון SageMaker מיכל דגם גדול (LMI). עושה את זה פשוט לשרת LLMs על ידי חיבור שורה של מסגרות וטכניקות שונות המייעלות את הפריסה של LLMs. למיכל LMI יש ערימת הגשה עוצמתית הנקראת הגשת DJL זה אגנוסטי ל-LLM הבסיסי. הוא מספק פרמטרים של תצורה ברמת המערכת שניתן לכוונן לצורך מיצוי הביצועים הטובים ביותר של תשתית האירוח עבור LLM נתון. יש לו גם תמיכה באופטימיזציות אחרונות כמו אצווה מתמשכת, הידועה גם בשם אצווה איטרטיבית או אצווה מתגלגלת, המספקת שיפורים משמעותיים בתפוקה.

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

יסודות הסקת הסקת טקסט עבור לימודי LLM

בואו נסתכל תחילה על כמה עקרונות בסיסיים כיצד לבצע הסקה עבור LLMs ליצירת טקסט.

העברה קדימה, הפעלות ומטמון KV

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

יצירת טקסט עם מודלים של שפה כמו Falcon או GPT הם autoregressive. המשמעות היא שהמודל מייצר אסימון אחד בכל פעם תוך התניה על האסימונים שנוצרו קודם לכן. במילים אחרות, בכל איטרציה, המודל לוקח את הטקסט שנוצר קודם לכן כקלט ומנבא את האסימון הבא בהתבסס על ההקשר הזה. כפי שהוזכר ב vLLM: הגשת LLM קלה, מהירה וזולה עם PagedAttention, בתהליך הפענוח האוטורגרסיבי הזה, כל אסימוני הקלט ל-LLM מייצרים את טנסורי מפתח הקשב והערך שלהם, והטנסורים הללו נשמרים בזיכרון ה-GPU כדי ליצור את האסימונים הבאים. טנזורי המפתח והערכים האלו מכונה לעתים קרובות ה- KV cache.

מילוי מראש ופענוח שלבים

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

שלב המילוי המוקדם כולל את הדברים הבאים:

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

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

שלב הפענוח כולל את הדברים הבאים:

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

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

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

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

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

• max_batch_delay = 100 - ההשהיה המקסימלית לצבירה של אצווה באלפיות שניות. ערך ברירת המחדל הוא 100 מילישניות.
• גודל_ אצווה = 32 - גודל האצווה הדינמי. ברירת המחדל היא 1.

זה בעצם מראה ש-DJLServing יעמיד בתור בקשות למשך 100 מילישניות בכל פעם, או אם מספר הבקשות שנמצאות בתור מגיע ל-batch_size שצוין, האצווה תתזמן לפעול ל-backend להסקת הסקה. זה ידוע בשם dynamic batching. זה דינמי מכיוון שגודל האצווה עשוי להשתנות בין אצווה בהתאם למספר הבקשות שנוספו במהלך הזמן הזה. עם זאת, מכיוון שלבקשות עשויות להיות מאפיינים שונים, (לדוגמה, בקשות מסוימות עשויות להיות בצורת 20 אסימוני קלט ו-500 אסימוני פלט, בעוד שאחרות עשויות להיות הפוכות, עם 500 אסימוני קלט אך רק 20 עבור פלט), חלק מהבקשות עשויות עיבוד מלא מהר יותר מאחרים באותה אצווה. זה עלול לגרום לחוסר ניצול של ה-GPU בזמן ההמתנה לכל הבקשות בטיסה באצווה כדי להשלים את שלב הפענוח שלה, גם אם יש בקשות נוספות הממתינות לעיבוד בתור. התרשים הבא ממחיש תהליך זה.

אופטימיזציה של תפוקה באמצעות אצווה רציפה

עם continuous batching, ידוע גם כ iterative or rolling אצווה, אנו מנצלים את ההבדלים בין שלבי המילוי המוקדם לפענוח. כדי להפעיל אצווה רציפה, DJServing מספק את התצורות הנוספות הבאות לפי serving.properties:

• מנוע=MPI - אנו ממליצים להשתמש במנוע MPI עבור אצווה רציפה.
• option.rolling_batch=auto או lmi-dist - אנו ממליצים להשתמש באוטו מכיוון שהוא יבחר אוטומטית את אלגוריתם האצווה המתגלגל המתאים ביותר יחד עם אופטימיזציות אחרות בעתיד.
• option.max_rolling_batch_size=32 - זה מגביל את מספר הבקשות במקביל. ברירת המחדל היא 32.

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

ניתן להגדיר את גודל המטמון עם האפשרות הבאה:

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

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

חיבור הכל ביחד: איך לחשוב על ניצול זיכרון של GPUs

מומלץ לטעון את המודל שלך כדי לראות איזו תצורה היא החסכונית ביותר עבור מקרה השימוש העסקי שלך. כדי לבנות הבנה, בואו נראה את טביעת הרגל של הזיכרון של ה-GPUs בזמן שהדגם נטען וכאשר בקשות עוקבות מעובדות באצווה מתגלגלת. עבור פוסט זה, נניח שאנו טוענים את דגם Falcon-40B על אחד ממופעי המופעים של G5 שמותקנים עם NVIDIA A10G GPUs, כל אחד עם 24 GB של זיכרון. שים לב שהבנה דומה חלה על סוגי המופעים p3, p4 ו-p5, המגיעים עם סדרת ה-V100, A100 ו-H100 GPU.

להלן סקירה כללית של קבלת ערך משוער של הזיכרון הכולל הנדרש לשרת Falcon-40B:

• גודל דגם = מספר פרמטרי הדגם (40 מיליארד עבור Falcon-40B) x 4 בתים לפרמטר (עבור FP32) = 160 GB
• הזיכרון הכולל המשוער הנדרש לטעינת Falcon-40B להסקת מסקנות = גודל דגם (=160 GB) + מטמון KV (מטמון תשומת לב) (=*20 GB) + תקורה נוספת של זיכרון על ידי ML ​​Frameworks (בערך 2 GB)

עבור Falcon-40B, אם נדחוס את המודל על ידי כימת המודל לסוג הנתונים bfloat16 (2 בתים), גודל המודל יהפוך ל-80 GB לערך. כפי שאתה יכול לראות, זה עדיין גדול יותר מהזיכרון שנתמך על ידי התקן מאיץ אחד, אז אנחנו צריכים לאמץ טכניקת חלוקה (ריסוק) מודלים עם מכשיר מיוחד מקביליות טנזור (TP) מתקרבים ומרסקים את המודל על פני התקני מאיץ מרובים. נניח שבחרנו ב-g5.24xlarge, שיש לו 4 מכשירי A10G GPU. אם אנו מגדירים את DJLServing (serving.properties) עם הדברים הבאים, אנו יכולים לצפות ש-80 GB של משקלי הדגם יתחלקו שווה בשווה על פני כל 4 ה-GPUs:

עם tensor_parallel_degree מוגדר ל-4, כ-20 GB מזיכרון ה-GPU של 24 GB (כ-84%) כבר מנוצלים עוד לפני שעובדה בקשה בודדת. שאר ה-16% של ה-GPU ישמשו עבור מטמון KV עבור הבקשות הנכנסות. ייתכן שלתרחיש העסקי שלך ודרישות האחזור והתפוקה שלו, 2-3 GB מהזיכרון שנותר זה די והותר. אם לא, אתה יכול להגדיל את גודל המופע ל-g5.48xlarge, שיש לו 8 GPUs ומשתמש ב-tensor_parallel_degree שהוגדר ל-8. במקרה כזה, רק כ-10 GB מהזיכרון הזמין של 24 GB של כל GPU מנוצל עבור משקלי הדגם. יש בערך 60% מה-GPU הנותר עבור ההפעלה והמטמון KV. באופן אינטואיטיבי, אנו יכולים לראות שתצורה זו עשויה לאפשר לנו תפוקה גבוהה יותר. בנוסף, מכיוון שיש לנו חיץ גדול יותר כעת, אנו יכולים להגדיל את max_rolling_batch_prefill_tokens ו גודל_גלגול_מקסימום פרמטרים כדי לייעל עוד יותר את התפוקה. יחד, שני הפרמטרים הללו ישלטו בהקצאות המוקדמות של מילויי ההפעלה וה-KV מטמון עבור הדגם. מספר גדול יותר עבור שני הפרמטרים הללו יתחבר לתפוקה גדולה יותר, בהנחה שיש לך מספיק מאגר עבור מטמון KV בזיכרון ה-GPU.

אצווה רציפה עם PagedAttention

PagedAttention הוא אלגוריתם אופטימיזציה חדש שפותח על ידי UC Berkeley המשפר את תהליך האצווה הרציף על ידי מתן אפשרות למטמון הקשב (KV cache) להיות לא רציף על ידי הקצאת זיכרון בדפים או בלוקים בגודל קבוע. זה בהשראת זיכרון וירטואלי ומושגי החלפה המשמשים מערכות הפעלה.

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

השוואה בין ביצועים

כדי להבטיח בדיקת עומס יעילה של תצורת הפריסה שלך, מומלץ להתחיל בהתחשב בתרחיש העסקי ולהגדיר בבירור את המאפיינים של הקלט והפלט עבור היישום מבוסס LLM. לדוגמה, אם אתה עובד על מקרה שימוש לסיכום מוקד טלפוני, הקלט יכול להיות מורכב מטקסט גדול יותר, כגון תמלול צ'אט של 500 אסימונים בין סוכן שירות לקוחות ללקוח, אבל הפלט עשוי להיות קטן יותר יחסית, בסביבות 100 אסימונים, המייצגים סיכום של התמליל. מצד שני, אם אתה עובד על תרחיש יצירת קוד, הקלט יכול להיות קצר עד 15 אסימונים, כמו "כתוב יישום יעיל ב-Python לתיאור כל משאבי EC2, כולל עימוד", אבל הפלט יכול להיות הרבה גדול יותר, מגיע ל-500 אסימונים. חשוב גם לשקול אם השגת זמן אחזור נמוך יותר או מיקסום התפוקה הם העדיפות העליונה עבור התרחיש הספציפי שלך.

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

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

אצווה דינמית	אצווה רציפה	אצווה רציפה עם PagedAttention
מנוע=Python option.model_id=tiiuae/falcon-40b option.tensor_parallel_degree=8 option.dtype=fp16 batch_size=4 max_batch_delay=100 option.trust_remote_code = true	מנוע = MPI option.model_id = {{s3_url}} option.trust_remote_code = true option.tensor_parallel_degree = 8 option.max_rolling_batch_size = 32 option.rolling_batch = אוטומטי option.dtype = fp16 option.max_rolling_batch_prefill_tokens = 1024 option.paged_attention = שקר	מנוע = MPI option.model_id = {{s3_url}} option.trust_remote_code = true option.tensor_parallel_degree = 8 option.max_rolling_batch_size = 32 option.rolling_batch = אוטומטי option.dtype = fp16 option.max_rolling_batch_prefill_tokens = 1024 option.paged_attention = נכון

שתי התצורות סומנו עבור Falcon-40B עם סוג הנתונים FP16 שנפרס על ml.g5.48xlarge בכמה תרחישים שונים המייצגים יישומים בעולם האמיתי:

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

אסטרטגיית אצווה	תפוקה (אסימונים/שנייה)	חביון p90 (שניות)
אצווה דינמית	5.53	58.34
אצווה רציפה	56.04	4.74
אצווה רציפה עם PagedAttention	59.18	4.76

• קלט גדול עם מספר קטן של אסימונים שנוצרים - כאן, אנו קובעים את מספר אסימוני הקלט ל-256 ומבקשים מה-LLM לסכם את הקלט ל-32 אסימונים

אסטרטגיית אצווה	תפוקה (אסימונים/שנייה)	חביון p90 (שניות)
אצווה דינמית	19.96	59.31
אצווה רציפה	46.69	3.88
אצווה רציפה עם PagedAttention	44.75	2.67

אנו יכולים לראות כי אצווה מתמשכת עם PagedAttention מספקת שיפור תפוקה של פי 10 בתרחיש 1 ופי 2.3 בתרחיש 2 בהשוואה לשימוש באצווה דינמית ב- SageMaker תוך שימוש במיכל LMI.

סיכום

בפוסט זה, בדקנו כיצד LLMs משתמשים בזיכרון והסברנו כיצד אצווה רציפה משפרת את התפוקה באמצעות מיכל LMI ב- SageMaker. הדגמנו את היתרונות של אצווה רציפה עבור Falcon-40B באמצעות מיכל LMI ב- SageMaker על ידי הצגת תוצאות בנצ'מרק. אתה יכול למצוא את הקוד ב- GitHub ריפו.

---

על הכותבים

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

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

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

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

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

• הפצת תוכן ויחסי ציבור מופעל על ידי SEO. קבל הגברה היום.
• PlatoData.Network Vertical Generative Ai. העצים את עצמך. גישה כאן.
• PlatoAiStream. Web3 Intelligence. הידע מוגבר. גישה כאן.
• PlatoESG. פחמן, קלינטק, אנרגיה, סביבה, שמש, ניהול פסולת. גישה כאן.
• PlatoHealth. מודיעין ביוטכנולוגיה וניסויים קליניים. גישה כאן.
• מקור: https://aws.amazon.com/blogs/machine-learning/improve-performance-of-falcon-models-with-amazon-sagemaker/