Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

ביצועים של מאיץ AI והשוואה לשוק

כדי להעריך חומרה של AI לשימוש עם מודלים גדולים של שפה (LLM) כעומס העבודה העיקרי, צריך להשתמש בגישה עקבית וניטרלית לספקים. במדריך הזה מתוארת מתודולוגיה להשוואה בין ביצועים של שבבי האצת AI מספקים שונים, כמו NVIDIA,‏ AMD, ‏ Googleו-AWS. העקרונות והמתודולוגיה ניתנים להתאמה לכל שבב AI או עומס עבודה, אבל הדוגמאות מתמקדות בשילוב נפוץ בתעשייה של יחידות עיבוד גרפי (GPU) של NVIDIA ויחידות עיבוד טנסור (TPU) שמריצות עומסי עבודה של LLM. Google

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

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

ממדי הביצועים

כדי ליצור הבנה הוליסטית יותר של מערכת מאיצים נתונה, אנחנו מציעים למעריכים לחשוב על הביצועים בשלושה ממדים:

מיקרו-בנצ'מרקינג: אם יש לכם את מפרטי החומרה הכי גבוהים, זה לא אומר שהאפליקציות יכולות להשתמש במפרטים האלה בפועל. אתם יכולים להשתמש במיקרו-בנצ'מרקינג כדי להעריך איך פעולות נקודה צפה לשנייה (FLOPS), זיכרון ברוחב פס גבוה (HBM) ורוחב פס של הרשת משפיעים על מה שאפשר להשיג בעומסי עבודה בעולם האמיתי.
ניתוח Roofline: יכול להיות שרוחב פס הזיכרון או מהירות החישוב יגבילו את השימוש האופטימלי בחומרה. אתם יכולים להשתמש במודל של קו הגג ובאינטנסיביות התפעולית (OI) של רכיבי מערכת שונים כדי לראות עד כמה החומרה ועומסי העבודה מתאימים זה לזה. שילוב של מיקרו-בנצ'מרקים וקווי גג מספק הערכה תיאורטית של מה שחומרה נבחרת יכולה להשיג עבור סוגים שונים של עומסי עבודה.
השוואה בין מודלים: השוואה בין עומסי עבודה של אימון והסקת מסקנות כדי למדוד את מספר הטוקנים לשנייה לכל שבב (TPS/chip) מאפשרת להעריך את אותו מודל בפלטפורמות שונות. אם התוצאות הראשוניות שונות מהתוצאות של המיקרו-בנצ'מרקינג וניתוח הגבול העליון, זה סימן שצריך לבצע עבודת תוכנה נוספת כדי להגיע לגבולות העליונים שזוהו קודם. לדוגמה, העבודה הזו עשויה לכלול שינוי של אסטרטגיות חלוקה או שימוש בקרנלים מותאמים אישית.

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

עיצוב משותף של הדגם והחומרה

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

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

דוגמה: האתגר של `gpt-oss-120B`

טעות נפוצה בהשוואה בין מודלים היא הערכה של מודל בחומרה שהוא לא תוכנן עבורה. gpt-oss-120B מודל עם משקלים פתוחים מבית OpenAI הוא דוגמה שממחישה למה צריך למפות את ארכיטקטורת המודל בצורה מדויקת לסיליקון היעד. בדוגמה הבאה אפשר לראות שתכנון משותף של המודל הוא קריטי וצריך להתבצע בשלב מוקדם בתהליך.

מודל gpt-oss-120B משתמש בממד של 64 לראש תשומת הלב. אומנם זהו תקן עבור הרבה מודלים שעברו אופטימיזציה ל-GPU, אבל הוא יוצר חוסר התאמה ארכיטקטוני למאיצי TPU. מערכות TPU כמו Trillium ו-Ironwood עברו אופטימיזציה לממדי מטריצה שהם כפולות של 256, כדי להגיע לרוויה מלאה של יחידות הכפלת המטריצות (MXU). מכיוון שהגודל של הראש, 64, לא מותאם ל-TPU, הרצת gpt-oss-120B במערכת TPU מובילה לשיעור נמוך יותר של טוקנים לשנייה (TPS) ושל ניצול FLOPS של המודל (MFU). החומרה מבזבזת למעשה מחזורי שעון ומשתמשת בתוספת הספק כדי למלא את השטח שנותר באפסים, כדי להתאים לרשתות הביצוע שלה בגודל 256x256.

שימוש ב-gpt-oss-120B כנקודת השוואה ל-TPU עלול להצביע באופן שגוי על יכולות חומרה נמוכות, כשבפועל הוא משקף חוסר התאמה בארכיטקטורת התוכנה. כדי להעריך בצורה מדויקת את ה'תקרה' של מאיץ, צריך לבדוק אותו באמצעות מודלים שתוכננו במשותף עבור הגיאומטריה הספציפית שלו. לדוגמה, מודלים עם 128 או 256 ממדי ראש כמו Gemma 4. אפשר לשפר את הביצועים של המודל הזה באמצעות ליבות מותאמות אישית שלא משתמשות בריפוד של אפסים, אלא ממלאות את ה-MXU. זה דורש מומחיות ולא משיג את אותה רמת ביצועים כמו ב-GPU. אפשר גם לשנות את המידות של הראש כדי לבצע אופטימיזציה טובה יותר ל-TPU, אבל השינוי הזה מבטל את המשקלים הקיימים של המודל, ולכן צריך לאמן אותו מחדש.

עקרונות השוואה לשוק

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

התמקדות בביצועים לכל דולר: חלק מהספקים מתמקדים בביצועים גולמיים של שבב יחיד, אבל הביצועים ברמת המערכת לכל דולר מייצגים טוב יותר את העלות הכוללת של הבעלות (TCO) והערך. אם שבב א' יעיל ב-20% יותר משבב ב' ועולה ב-50% יותר משבב ב', המעריכים צריכים להכיר בשיפורים בביצועים של שבב ב' ביחס לעלות. כדאי גם לשקול את הביצועים לוואט כחלק מהעלות.
ייצוג של עומסי עבודה מודרניים של AI: התמקדות במודלים פופולריים מבוססי-טרנספורמציה, באשכולות גדולים ובמסגרות העבודה העדכניות ביותר, תוך התחשבות במגמות בתעשייה. לדוגמה, המעבר בתעשייה למודלים של תערובת דלילה של מומחים (MoE) מקשה על ביצוע אופטימיזציה מלאה של FLOPS, ודורש רוחב פס גבוה יותר של חציית הגרף מהרשתות.
תמיכה רחבה בדרישות המפתחים: חשוב לבדוק את הביצועים, הגמישות והיכולת להרחבה במגוון עומסי עבודה: אימון, כוונון עדין והצגה במגוון מודלים גדולים של שפה (LLM) ומודלים אחרים.
בחירה של מודלים וכלים שלא תלויים בספק: בחירה של מודלים ומנועים שפועלים במאיצים כדי להקל על ביצוע הערכות בין מאיצים. לדוגמה, אפשר להשתמש במודלים פתוחים כמו Qwen ו-Gemma, וגם במנועי היקש בקוד פתוח שפועלים ביחידות GPU ו-TPU, כמו vLLM. מומלץ להימנע ממערכי PyTorch/CUDA ספציפיים לחומרה. לצורך השוואה בין מודלים, המסגרות הספציפיות לספקים (כמו MaxText ל-TPU ו-Megatron ל-GPU) הן הכי שימושיות כשמשתמשים באותם מודלים בפלטפורמות שונות.
תכנון משותף של מודלים: משתמשים מנוסים מתכננים ביחד את המודלים שלהם כדי להפיק את המרב מפלטפורמת החומרה. אל תצפו שמודל שאומן על שבב א' יציג ביצועים טובים "מחוץ לקופסה" על שבב ב'.
כדאי לבדוק את כל מערכת החומרה: חלק מהמאיצים יכולים להציג ביצועים גבוהים בתחום אחד, כמו FLOPS. אבל צווארי בקבוק בתחומים אחרים, כמו רוחב פס של הזיכרון, יכולים להגביל באופן משמעותי את היכולות של המאיץ. היבטים נוספים במערכת שכדאי לקחת בחשבון הם מפרטי השבב, רשת השבבים והארכיטקטורה של הרחבת הקיבולת.
מהימנות של חומרה ותוכנה: שיבושים במהלך אימון בקנה מידה גדול או פעולות הסקה קריטיות עלולים להיות יקרים מאוד. באופן דומה, מאיץ AI שימושי רק אם יש תוכנה שפועלת עליו. כדי למקסם את הערך, נדרשת חבילת תוכנה בוגרת ואמינה, שנבדקה בהיקף גדול.

מיקרו-מדדים

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

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

כדי לבצע מיקרו-בנצ'מרקינג יעיל של מאיצים, צריך להעריך את הדברים הבאים:

השוואה	הסבר
ניצול כפל מטריצות כלליות צפופות (GEMM)	הפעלת ליבות GEMM שעברו אופטימיזציה גבוהה ברמות דיוק שונות כדי למדוד את כוח העיבוד המתמטי הגולמי והמתמשך של יחידות המחשוב המרכזיות של המאיץ.
סטרימינג של זיכרון ברוחב פס גבוה (HBM)	מריצים מיקרו-בנצ'מרקים של רוחב פס של הזיכרון כדי למדוד את מהירויות הקריאה, הכתיבה וההעתקה המתמשכות של הזיכרון המובנה של המאיץ. ארכיטקטורות ששומרות על יחס תקין בין בייט ל-FLOP מונעות ממערכות הליבה של המחשוב להיות במצב המתנה.
קולקטיבים מבוזרים (all-reduce ו-all-gather)	להריץ בדיקות תקניות של תקשורת קולקטיבית באלפי שבבים כדי למדוד את מידת הפגיעה ברוחב הפס ובזמן האחזור של הרשת ככל שהאשכול גדל.
קצב ההעברה ממארח למכשיר (H2D) וממכשיר למארח (D2H)	העברת זרמים גדולים ורציפים של נתונים בין זיכרון המערכת של המעבד המארח לבין המאיץ, כדי למדוד את קצב ההעברה דרך אפיק ה-PCIe או דרך חיבור מותאם אישית.
ויסות נתונים (throttle) תרמי מתמשך וצריכת חשמל	מריצים לולאת GEMM עם ניצול מקסימלי באופן רציף במשך 48 שעות, תוך מעקב אחר צריכת החשמל ברמת המתלה, כדי להעריך את היציבות התרמיתית הממושכת ואת יעילות החשמל בעולם האמיתי.

דוגמה להשוואה בין מיקרו-בנצ'מרקים

הנה השוואה להמחשה בין שני שבבים, שבה שבב היפותטי א' עשוי להיראות טוב יותר משבב היפותטי ב', אבל בפועל הביצועים שלו גרועים יותר:

שם נקודת ההשוואה	תוצאה שנבדקה של שבב A	מפרט צ'יפ A	יחס הבדיקה / המפרט	תוצאת הבדיקה של שבב B	מפרט של שבב ב'	יחס הבדיקה / המפרט
תקשורת רשת בין צ'יפים	‫800GBps	‫1,000 GBps	‫80.0%	‫850 GBps	‫900GBps	94.4%
gemm/peakTOPS	‫1,800 TFLOPS	‫2,500 TFLOPS	72.0%	‫1,800 TFLOPS	‫2,000 TFLOPS	90.0%
רוחב פס של זיכרון	‫6,000GBps	‫8,000GBps	75.0%	‫6,500GBps	‫7,500GBps	86.7%
ממארח למכשיר	‫58GBps/chip	‫70GBps/chip	‫82.9%	‫60GBps/chip	‫65GBps/chip	92.3%
ממכשיר למארח	‫55GBps/chip	‫70GBps/chip	‫78.6%	‫55GBps/chip	‫65GBps/chip	84.6%

ניתוח קו הגג

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

התפוקה של שבב להאצת AI מוגבלת על ידי שלושה גורמים עיקריים:

קיבולת חישוב: תפוקת השיא המתמטית של השבב (FLOPS).
רוחב פס של הזיכרון: הקצב שבו אפשר להעביר נתונים אל הזיכרון המקומי של רוחב הפס הגבוה (HBM) של השבב או ממנו.
רוחב פס של הרשת: הקצב שבו אפשר לשתף נתונים בין כמה שבבים באמצעות רשת השבבים במהלך אימון או הסקה מבוזרים. לדוגמה, קצב ההעברה של ICI (עבור TPU) או NVLink (עבור GPU).

מידע נוסף על קווי גג זמין במאמר All About Rooflines.

תרשים קו הגג הסטנדרטי מורכב משני צירים:

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

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

החלק העליון של הגרף נוצר משני קווים מצטלבים שמייצגים את המקסימום של החומרה:

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

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

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

דוגמאות לעומסי עבודה עם רמות נמוכות וגבוהות של OI

עומס עבודה בעוצמת הפעלה נמוכה של HBM (מוגבל על ידי זיכרון): עומסי עבודה כמו פעולות ברמת הרכיב (פונקציות הפעלה כמו ReLU או GeLU), נורמליזציה של שכבות ופענוח אוטומטי רגרסיבי (גודל אצווה = 1 הסקה).
עוצמת פעולה גבוהה של HBM (מוגבלת על ידי חישוב): עומסי עבודה כמו GEMM או רשתות עצביות קונבולוציוניות של אצווה גדולה. בכפל מטריצות נעשה שימוש חוזר בנתונים שנשלפו הרבה פעמים (כפל שורות בעמודות), ולכן ה-OI גבוה מאוד ועומסי העבודה נמצאים מתחת לתקרת החישוב השטוחה.

השוואה לשוק של מודלים

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

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

תובנה	עומסי עבודה של אימון	עומסי עבודה של הסקה
להתכונן להתרחבות	בדרך כלל מדובר בבדיקות בקנה מידה גדול יותר (10,000 שבבים ומעלה, עד 100,000 ומעלה במודלים הגדולים ביותר). תובנות לגבי עומסי עבודה מבוזרים, תקורה של תקשורת ומגבלות של רשתות ברמת האשכול.	בדרך כלל מדובר בבדיקות קטנות יותר (1-64+ שבבים). הדוח מספק תובנות לגבי האופן שבו הפלטפורמה מטפלת במשתמשים בו-זמנית ובהגדלה מהירה של נפח הפעילות בעומס.
ביצועים	לרוב, הביצועים שלהם מוגבלים יותר על ידי כוח המחשוב. מדידת טוקנים שעברו עיבוד לשנייה לכל שבב וניצול FLOPS של המודל (MFU).	רגישות לזמן האחזור. המדד הזה מודד את הזמן עד לטוקן הראשון (TTFT), את זמן האחזור בין הטוקנים ואת מספר הטוקנים הכולל שנוצר לשנייה לכל משתמש.
זמן אחזור	זמן אחזור של קלט/פלט ושל קישוריות הדדית שמבליט צווארי בקבוק באחסון כשמטעינים מערכי נתונים גדולים, וזמן אחזור ברשת בין צמתים במהלך עדכוני גרדיאנט סינכרוניים.	השהיית התגובה מקצה לקצה שמדגישה עיכובים בתור, השהיית נקודת הקצה וזמני המתנה שמוצגים למשתמש.

השוואה בין אימונים

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

כדי לנרמל את הביצועים עם העלות של המאיצים, מחלקים את ה-TPS/chip בעלות של כל שבב כדי לקבל TPS/chip/$‎, שמשמש כנקודת השוואה נוספת.

לכל מודל שמשווים, צריך להעריך את הדברים הבאים:

השוואה	הסבר
מדידת TPS/chip ו-TPS/chip/$‎	מריצים את מודל היעד באשכול הקטן ביותר שמתאים לכך. מתעדים את קצב העיבוד (throughput) של האימון הגלובלי (מספר הטוקנים הכולל שעובד בשנייה) ומחלקים במספר השבבים כדי לקבוע את קצב העיבוד הבסיסי (TPS) לכל שבב. מחלקים בעלות המאיץ כדי לקבל את הערך של TPS/chip/$. אפשרות נוספת היא לבחון את ניצול ה-FLOPs של המודל (MFU) במהלך האימון כדי למדוד את היחס בין התפוקה שנצפתה לבין המקסימום התיאורטי. הנתון הזה שימושי כדי להבין עד כמה הביצועים של החומרה קרובים לביצועים של בדיקת ההשוואה. עם זאת, הוא לא מספק השוואה שימושית בין שבבים כמו TPS/שבב.
הערכת הירידה בביצועים של שינוי הגודל	מגדילים את קנה המידה של האשכול ל-256, ל-1,024 ול-4,096 שבבים, ומריצים את אותו מודל בדיוק. מחשבים מחדש את ה-TPS/chip בכל קנה מידה.
חשבון התפוקה	הנתון 'TPS גולמי' או 'שבב בלבד' חשוב רק אם המודל לומד בפועל. חישוב של קצב העברת נתונים יעיל כדי למדוד את קצב החישוב השימושי שמקדם ישירות את מצב האימון של מודל LLM, לא כולל במפורש זמן ואנרגיה שבוזבזו על תקלות בחומרה, על עצירות ברשת או על שחזורים של נקודות ביקורת. כשמעריכים מאיצי AI בהיקף גדול, מדד ה-goodput מספק תמונה מציאותית יותר של החזר ההשקעה בהשוואה לתפוקה תיאורטית גולמית, כי הוא חושף את היעילות של שמירת הביצועים על ידי החומרה באשכולות בעולם האמיתי שמועדים לשגיאות.

השוואה

הסבר

מדידת TPS/chip ו-TPS/chip/$‎

מריצים את מודל היעד באשכול הקטן ביותר שמתאים לכך. מתעדים את קצב העיבוד (throughput) של האימון הגלובלי (מספר הטוקנים הכולל שעובד בשנייה) ומחלקים במספר השבבים כדי לקבוע את קצב העיבוד הבסיסי (TPS) לכל שבב. מחלקים בעלות המאיץ כדי לקבל את הערך של TPS/chip/$.

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

הערכת הירידה בביצועים של שינוי הגודל

מגדילים את קנה המידה של האשכול ל-256, ל-1,024 ול-4,096 שבבים, ומריצים את אותו מודל בדיוק. מחשבים מחדש את ה-TPS/chip בכל קנה מידה.

חשבון התפוקה

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

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

בטבלה הבאה מפורטים מודלים מומלצים להשוואה לצורך אימון:

גודל	ארכיטקטורה	דגם	הסבר
קטן (8 מיליארד)	צפוף	‫Llama 3.1 8B	‫Llama 3 הוא מודל סטנדרטי ופופולרי בקרב סטנדרטים להשוואה כמו MLPerf במשך כמה שנים.
בינוני (70B)	צפוף	‫Llama 3.1 70B	‫Llama 3 הוא מודל סטנדרטי ופופולרי בקרב סטנדרטים להשוואה כמו MLPerf במשך כמה שנים.
גדול (671B)	MoE	DeepSeek-V3 671B	‫DeepSeek-V3 הציב בשנת 2025 סטנדרט חדש של גודל וביצועים, והוא מותאם היטב להרבה פלטפורמות מרובות שבבים.

דוגמה: נרמול לביצועים לכל דולר

נניח שאתם רוצים להשוות בין Chip_A, ‏ Chip_B ו-Chip_C, והפעלתם השוואות ביצועים של אימון למודלים נפוצים כדי לראות את הביצועים ב-TPS. לאחר מכן בודקים את היחס בין הביצועים של Chip_A לבין הביצועים של Chip_B ו-Chip_C באותו מודל:

השוואה	החלק היחסי של Chip_A TPS מתוך Chip_B TPS	ה-TPS של Chip_A כחלק מה-TPS של Chip_C
קטן וצפוף: Llama 3.1 8B	0.82	0.62
MoE: Mixtral 8x7B	0.72	0.55
גדול וצפוף: Llama 3.1 405B	0.77	0.61
מודל MoE גדול: DeepSeek-V3	0.85	0.62
ערך ממוצע	0.79	0.60

על סמך הנתונים בטבלה הקודמת, הביצועים הממוצעים של Chip_A הם 0.79 מביצועי Chip_B ו-0.60 מביצועי Chip_C. ללא מידע נוסף, המסקנה תהיה ש-Chip_C עדיף.

לעומת זאת, אם עלות שבב א' היא 100$, עלות שבב ב' היא 180 $ועלות שבב ג' היא 200$, אז נרמול הביצועים לפי דולר (perf/$) משנה את התוצאה:

השוואה	ביצועים של Chip_A/$ כשבר מתוך ביצועים של Chip_B/$	ביצועים של Chip_A/$ כשבר מתוך הביצועים של Chip_C/$
קטן וצפוף: Llama 3.1 8B	1.48	‫1.24
MoE: Mixtral 8x7B	‫1.30	‫1.10
גדול וצפוף: Llama 3.1 405B	1.39	1.22
מודל MoE גדול: DeepSeek-V3	‫1.53	‫1.24
ערך ממוצע	1.42	1.20

כשמשתמשים בביצועים חלקי עלות כנקודת השוואה, שבב א' עולה על שבב ב' ב-42% בממוצע, ועל שבב ג' ב-20% בממוצע.

השוואה לשוק של הסקת מסקנות

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

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

כשמשווים בין מסקנות, צריך לנרמל את הביצועים על ידי חישוב של TPS/chip/$:

השוואה	הסבר
הגדרת הסכם רמת שירות (SLA) לזמן האחזור	קודם כול, מגדירים הסכם רמת שירות (SLA) מחמיר לחוויית המשתמש. לדוגמה, זמן אחזור צפוי (P99) של 100 אלפיות השנייה. כדי למדוד את חוויית המשתמש של מהירות התגובה, אפשר להשתמש במדד TTFT (פחות מ-500 אלפיות השנייה) ובמדד Time Per Output Token (TPOT).
הגדלת גודל האצווה	הגדלה הדרגתית של מספר הבקשות בו-זמנית (גודל האצווה) אל החומרה. ככל שגודל האצווה גדל, התפוקה עולה, אבל בסופו של דבר זמן האחזור מתארך.
הקלטה של מספר העסקאות המקסימלי לשנייה (TPS) או מספר העסקאות המקסימלי לשנייה לכל שבב (TPS/chip)	אם הציוד לא עומד בהסכם רמת השירות (SLA) של זמן האחזור P99, צריך להפסיק. מתעדים את התפוקה הכוללת של המערכת בגודל האצווה המדויק הזה, ומחלקים במספר השבבים. זהו הערך שלכם ל-TPS/chip. חשוב לשים לב: חלק מהמאיצים לשימוש כללי מתקשים להתמודד עם 'חביון זנב' (עליות חדות אקראיות בזמן העיבוד) בעומסי אצווה גבוהים, ולכן המפעילים נאלצים להשתמש בהם ברמות ניצול נמוכות יותר כדי שהמשתמשים יהיו מרוצים. חשוב למדוד את הביצועים בשני השלבים הנפרדים של מילוי אוטומטי מראש (מוגבל על ידי חישוב) ופענוח (מוגבל על ידי רוחב פס של זיכרון)
חישוב העלות הכוללת של הבעלות (TCO) לכל אלף או מיליון טוקנים	מחלקים את העלות המופחתת של ההון ושל האנרגיה של שבב אחד במספר העסקאות המקסימלי לשנייה (TPS) לשבב. המדד הזה מתרגם את נקודת ההשוואה הטכנית למדד פיננסי, ומציג את העלות האמיתית.

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

גודל	ארכיטקטורה	דגם	הסבר
קטן (8 מיליארד)	צפוף	‫Llama 3.1 8B	‫Llama 3 הוא מודל סטנדרטי ופופולרי בקרב סטנדרטים להשוואה כמו MLPerf במשך כמה שנים.
בינוני (70B)	צפוף	‫Llama 3.1 70B	‫Llama 3 הוא מודל סטנדרטי ופופולרי בקרב סטנדרטים להשוואה כמו MLPerf כבר כמה שנים.
גדול (480B)	MoE	Qwen3 Coder 480B	‫Qwen3 480B הוא מודל מוביל של OSS לתכנות.