תפסיק לבזבז עלויות GPU! מדריך האופטימיזציה של שנאי תלת-שלבי

חשבונות GPU יכולים לצמוח מבחירות קטנות בזרימת עבודה של Transformer. אני עשוי להשתמש בדגם גדול, לשלוח כניסות מרופדות, להריץ מתמטיקה בדיוק מלא ולהשאיר את ה-GPU ממתין בין בקשות. כל בחירה מוסיפה עלות מבלי תמיד לשפר את התפוקה. אני משתמש בשלושה שלבים מעשיים כדי להפחית בזבוז תוך שמירה על איכות הדגם בבדיקה. ## שלב 1: הקטנת ריפוד ואורך רצף בקרה רובוטריקים מעבדים כל אסימון בצורת הקלט. אם לבקשה אחת יש 80 אסימונים ולאחרת יש 900, ריפוד שניהם ל-900 אסימונים גורם לבקשה הקצרה יותר להשתמש בזיכרון GPU יותר מהנדרש. אני מקבץ בקשות באורכים דומים ומגדיר מגבלת אסימון שימושי. python from transformers import AutoTokenizer tokenizer = AutoTokenizer.from_pretrained("bert-base-uncased") batch = tokenizer( texts, padding=True, truncation=True, max_length=512, return_tensors="pt" ) כל התאמה דינמית קבועה היא לרוב התאמה דינמית קבועה. לסיווג טקסט, אני עשוי לבדוק מגבלות כגון 128, 256 ו-512 אסימונים. ההגדרה הטובה ביותר תלויה בנתונים. ייתכן שצוות תמיכה המעבד הודעות קצרות של לקוחות לא יזדקק להגבלת 512 אסימונים. מודל מסמך משפטי עשוי להזדקק לתשומות ארוכות יותר, אך הוא עדיין יכול להסיר שטח לא בשימוש באמצעות אצווה מבוססת אורך. אני עוקב אחר שלושה מספרים במהלך הבדיקה: - אורך קלט ממוצע - שימוש בזיכרון GPU - איכות דגם על ערכת אימות קבועה מגבלת אסימון נמוכה יותר יכולה להפחית את העלות, אבל היא עשויה להסיר הקשר שימושי. אני מתייחס לגבול כבחירה מדודה ולא כאל ניחוש. ## שלב 2: השתמש בדייקנות מעורבת לאחר בדיקת פלט של דגם GPUs מודרניים רבים יכולים להריץ פעולות שנבחרות שנבחרו עם FP16 או BF16. פורמטים אלה משתמשים בפחות זיכרון מ-FP32 ועשויים לשפר את התפוקה. להסקת מסקנות לגבי PyTorch, אני יכול לבדוק שידור אוטומטי בצורה הבאה: python import torch model.eval() with torch.no_grad(): with torch.autocast( device_type="cuda", dtype=torch.float16 ): output = model(**batch) BF16 יכולה להיות אפשרות טובה ב-FPnumeric טווח רחב מחומרה נתמכת. python with torch.no_grad(): with torch.autocast( device_type="cuda", dtype=torch.bfloat16 ): output = model(**batch) אני לא מחליף דיוק מבלי לבדוק את התוצאות. אני משווה דיוק, ציון F1, איכות תגובה, שיעורי שגיאות והשהייה מול קו בסיס FP32. מסווג טקסט עשוי להראות כמעט ללא שינוי באיכות לאחר המעבר ל-FP16. מודל עם פעולות מספריות רגישות עשוי להזדקק לבדיקות נוספות. החומרה גם חשובה, אז אני רושם את סוג ה-GPU וגרסאות התוכנה במהלך כל בדיקה. שלב זה עובד בצורה הטובה ביותר כאשר הדגם, הגדרת CUDA וגרסת PyTorch תומכים בסוג הנתונים הנבחר. ## שלב 3: השאר את ה-GPU עסוק באצווה ושימוש חוזר. GPU יכול לעבד כמה בקשות יחד ביעילות רבה יותר מאשר הרבה בקשות קטנות שנשלחות אחת אחת. קבוצות קטנות עלולות להשאיר חלק מהמכשיר פעיל, בעוד קבוצות גדולות מאוד עלולות לגרום ללחץ בזיכרון. אני בודק גדלי אצווה כגון 4, 8, 16 ו-32. עבור כל גודל, אני מודד: - בקשות מעובדות בשנייה - זמן תגובה ממוצע - זיכרון GPU שיא - פסק זמן או שיעור שגיאות שירות מעשי עשוי להשתמש בחלון אצווה קצר. בקשות המגיעות בחלון זה מקובצות לאצווה אחת. החלון צריך להישאר קטן מספיק לזמן התגובה הצפוי. עבור טקסט חוזר, אני גם עושה שימוש חוזר בעבודה שבה התוצאה בטוחה לאחסון במטמון. שירות חיפוש מוצר עשוי לקבל את אותן תוויות קטגוריות או שאילתות קצרות פעמים רבות. שמירה במטמון של תוצאות אלה יכולה להפחית שיחות חוזרות ונשנות של מודל. עבור מודלים של שפות מפענח בלבד, מטמון ה-KV יכול להפחית עבודת קשב חוזרת ונשנית במהלך יצירת אסימונים. כלי הגשה כגון vLLM ו-Huging Face Text Generation Inference תכונות תומכות המסייעות בניהול עומסי עבודה בדור. אני עדיין בודק את השימוש בזיכרון וזמן התגובה על התעבורה שלי מכיוון שהתוצאות משתנות לפי הדגם ואורך הבקשה. טבלת ניטור פשוטה עוזרת לי להימנע מהחלטות המבוססות על שימוש ב-GPU בלבד: | מבחן | גודל אצווה | דיוק | אסימונים/בקשה | חביון | זיכרון GPU | איכות | |---|---:|---|---:|---:|---:|---:| | א | 1 | FP32 | 256 | שיא | שיא | קו בסיס | | ב | 8 | FP16 | 256 | שיא | שיא | השווה | | ג | 16 | FP16 | 128 | שיא | שיא | השווה | אני בוחר את ההגדרה שעומדת ביעד השירות באיכות מקובלת. קריאת הזיכרון הנמוכה ביותר היא לא תמיד האפשרות הטובה ביותר אם היא יוצרת תגובות איטיות או יותר בקשות שנכשלו. הלקח העיקרי הוא פשוט: צמצם אסימונים שאינם בשימוש, בדוק מתמטיקה ברמת דיוק נמוכה יותר, ושלח עבודה ל-GPU באצוות מתאימות. אני מבצע שינוי אחד בכל פעם, שומר על אותו ערכת בדיקה ומשווה את העלות והאיכות של הדגם. תוכנית התחלה שימושית נראית כך: 1. מדוד את אורך האסימון הנוכחי, חביון, שימוש בזיכרון ושעות GPU. 2. הוסף ריפוד דינמי ובדוק מגבלת אסימון קטנה יותר. 3. בדוק את FP16 או BF16 מול הדיוק הנוכחי. 4. בדוק גדלי אצווה עם תעבורה דמוית ייצור. 5. שמור על ההגדרות שמפחיתות את השימוש ב-GPU מבלי לפגוע ביעד השירות. שלבים אלה אינם מסירים את הצורך בבדיקה. הם נותנים לי דרך ברורה למצוא מחשוב מבוזבז לפני מעבר למעבד גרפי גדול יותר או שינוי הדגם.

חשבונות GPU יכולים לגדול מהר יותר מאיכות הדגם. ראיתי צוותים מוסיפים כרטיסים גדולים יותר כאשר הבעיה האמיתית הייתה זיכרון לא בשימוש, אסימונים מרופדים או גודל אצווה שלא תאם את עומס העבודה. רובאי אינו זקוק ל-GPU היקר ביותר כברירת מחדל. אני מתחיל עם שלוש בדיקות: למדוד את עומס העבודה, להפחית חישוב מבוזבז, ולבחור נתיב ביצוע בעלות נמוכה יותר. ## שלב 1: מדוד במה המודל באמת משתמש. אני לא משנה את ה-GPU לפני איסוף נתונים בסיסיים. מסלול: - שימוש בזיכרון GPU - ניצול GPU - אסימונים מעובדים בשנייה - בקשת השהיה - גודל אצווה - אורך רצף קלט - זמן שהושקע בטעינת נתונים ועיבוד מוקדם ייתכן ש-GPU שנשאר ב-35% ניצול לא יזדקק ליותר זיכרון או כרטיס חדש יותר. הדגם יכול להמתין למעבד, לקבל בקשות אחת אחת, או לעבד תשומות מרופדות בכבדות. עבור מסווג מבוסס BERT, השווה שתי אצוות: - 16 טקסטים מרופדים ל-512 אסימונים - 16 טקסטים מרופדים לטקסט הארוך ביותר באותה אצווה האצווה השנייה עשויה להכיל הרבה פחות אסימוני ריפוד. הרווח המדויק תלוי בנתונים, בדגם ובחומרה, אז אני מודד אותו עם אותה ערכת בדיקה ודפוס בקשה. כלים שימושיים כוללים: bash nvidia-smi עבור עומסי עבודה של PyTorch, אני גם מתעד זיכרון וזמן ביצוע: python start = torch.cuda.Event(enable_timing=True) end = torch.cuda.Event(enable_timing=True) start.chor(inference) start.ch(inference) עם פלט =(r**inference) end.record() torch.cuda.synchronize() print(f"{start.elapsed_time(end):.2f} ms") print(torch.cuda.memory_allocated() / 1024**2, "MB") ריצה מהירה אחת עלולה להטעות אותי. אני משתמש בבקשות חימום ומדווח על זמן אחזור חציוני לאורך מספר ריצות. ## שלב 2: הסר אסימונים מבוזבזים ועבודה מיותרת לאורך הרצף יש השפעה ישירה על עלות השנאי. כניסות ארוכות יכולות לצרוך זיכרון גם כאשר רוב האסימונים מוסיפים ערך קטן. אני משתמש בריפוד דינמי: python tokenizer( texts, padding=True, truncation=True, max_length=256, return_tensors="pt" ) הערך max_length אמור להגיע מהמשימה. סיווג כרטיס תמיכה עשוי לעבוד היטב עם 128 או 256 אסימונים, בעוד שמודל מסמך עשוי להזדקק להקשר רב יותר. אני בודק איכות לאחר כל שינוי במקום להניח שקלט קצר יותר בטוח. לצורך הסקה, אני גם מאפשר מצב הערכה: python model.eval() עם torch.inference_mode(): output = model(**inputs) זה מונע מאחסנת עבודה הקשורה לאימון במהלך חיזוי. אצווה צריך מגבלה מעשית. אצווה גדולה יותר יכולה לשפר את התפוקה, אך היא עשויה להעלות את זמן ההשהיה ואת השימוש בזיכרון. אני בודק מספר גדלים, כגון 1, 8, 16 ו-32, ואז בוחר נקודה שמתאימה ליעד השירות. ## שלב 3: השתמש בהסקת מסקנות ברמת דיוק נמוכה יותר עם בדיקות איכות עבודות רבות של מסקנות שנאי יכולות להשתמש ב-FP16 או BF16 במעבדי GPU נתמכים. python with torch.inference_mode(), torch.autocast("cuda", dtype=torch.float16): output = model(**inputs) BF16 עשוי להתאים יותר לחומרה שתומכת בו, במיוחד כאשר FP16 יוצר בעיות מספריות. אני משווה: - דיוק או ציון F1 - השהייה חציונית ואחוזון גבוה - אסימונים לשנייה - שיא ​​זיכרון GPU - מקרי שגיאה קוונטיזציה היא אפשרות נוספת להסקת מסקנות. מודל של 8 סיביות או 4 סיביות יכול להפחית את צרכי הזיכרון, אם כי התוצאה תלויה בספרייה, ארכיטקטורת המודל, ה-GPU ועומס העבודה. אני מאמת את המודל המקוונטי על נתונים מייצגים לפני העברתו לשירות. נתיב מעשי נראה כך: 1. פרופיל המודל והתנועה הנוכחיים. 2. צמצם ריפוד והגדר מגבלת רצף שנבדק. 3. אפשר מצב הסקה וכוון את גודל האצווה. 4. בדוק את FP16 או BF16. 5. מדוד קוונטיזציה רק ​​לאחר הבנת השינויים המוקדמים יותר. הלקח העיקרי שלי הוא פשוט: עלות GPU לרוב משקפת ביצוע לא יעיל ולא גודל הדגם בלבד. קלט קטן יותר, אצווה טובה יותר והגדרת דיוק מדודה יכולים לעזור לשנאי להשתמש בחומרה הנוכחית שלו בצורה יעילה יותר. כאשר עומס העבודה עדיין חורג מהיעד לאחר בדיקות אלו, שדרוג ה-GPU הופך להחלטה טכנית ברורה יותר במקום ניחוש.

מסקנות שנאי עשויות להיות יקרות לפני שלמוצר יש משתמשים רבים. מודל עשוי לענות היטב בבדיקה, אך להאט כאשר מספר בקשות מגיעות יחד. זיכרון ה-GPU מתמלא, הנחיות ארוכות מעלות את זמן ההשהיה, וכל אסימון שנוצר מוסיף לחשבון. גיליתי שהסקת שנאי מהירה וזולה יותר מגיעה בדרך כלל משלושה שינויים מעשיים: 1. השתמש בדגם ובדיוק התואמים את המשימה. 2. הנחיות בקרה, אורך רצף ואצווה של בקשה. 3. הפעל את הדגם עם מנוע הסקה שמשתמש היטב בחומרה. הסדר הנכון תלוי במערכת, אך תהליך המדידה נשאר זהה. רשום זמן אחזור, אסימונים לשנייה, שימוש בזיכרון ועלות לכל בקשה לפני שינוי משהו. 1. צמצם את העבודה הדרושה לכל בקשה דגם גדול לא תמיד מתאים למשימה ממוקדת. אם בוט תמיכה רק מסווג כרטיסים או מחלץ שמות מוצרים, דגם קטן יותר עשוי לספק את אותה תוצאה עסקית עם פחות זיכרון והשהייה נמוכה יותר. בדרך כלל אני בודק שלוש שאלות: - האם המשימה מצריכה יצירה פתוחה? - האם המודל צריך חלון הקשר ארוך? - האם הדיוק הנוסף מדגם גדול יותר מועיל למשתמש? עבור משימות סיווג טקסט רבות, מודל מקודד קומפקטי יכול להספיק. עבור הדור, דגם קטן יותר מכוון הוראות עשוי לעבוד כאשר ההנחיה ברורה ופורמט הפלט מוגבל. קוונטיזציה יכולה להפחית את מספר הביטים המשמשים למשקולות מודל. מעבר מ-FP16 ל-INT8 או פורמט 4 סיביות נתמך יכול להפחית את השימוש בזיכרון ולאפשר יותר בקשות ב-GPU אחד. ההשפעה תלויה בדגם, בחומרה, בספרייה ובעומס העבודה. חלק מהדגמים מאבדים איכות מועטה, בעוד שאחרים מראים שינויים גלויים בכתיבה ארוכת צורה או קריאות לכלי. אני לא מתייחס לקוונטיזציה כעל הגברת מהירות חופשית. אני בודק אותו עם אותו ערכת הערכה המשמשת למודל הדיוק המלא. אני משווה: - דיוק משימה - איכות פלט - זמן עד האסימון הראשון - אסימונים שנוצרים בשנייה - שימוש בזיכרון GPU - עלות לכל 1,000 בקשות דוגמה מעשית היא מערכת תמיכת לקוחות המשתמשת במודל שפה 7B או 8B לתשובות קצרות. הצוות עשוי לבדוק גרסאות FP16, INT8 ו-4 סיביות על אותו GPU. אם מודל 4 הסיביות שומר על איכות התשובה הנדרשת ומשתמש בפחות זיכרון, המערכת עשויה לטפל בבקשות במקביל מבלי להוסיף מכונה נוספת. את התוצאה הזו יש למדוד, לא להניח. 2. שמור על הנחיות וקבוצות בשליטה הנחיות ארוכות משפיעות על מסקנות שנאי בשתי דרכים. המערכת משקיעה יותר זמן בקריאת הקלט, והמטמון של ערך מפתח גדל ככל שהמודל מעבד יותר אסימונים. היסטוריית צ'אט שנראית קטנה בממשק משתמש יכולה להפוך לגדולה לאחר סיבובים רבים. אני מצמצם הקשר מיותר על ידי: - הסרת הוראות מערכת חוזרות ונשנות - חיתוך הודעות צ'אט ישנות - סיכום קטעי שיחה ישנים יותר - שליחת רק את המסמכים הדרושים לשאלה הנוכחית - הגדרת מגבלת אסימון פלט מעשי - הימנעות מדוגמאות גדולות כאשר מדריך פורמט קצר עובד הנחייה קצרה יותר יכולה לשפר את השהיה מבלי לשנות את המודל. זה יכול גם להפחית את חיובי אסימון הקלט כאשר ספק השירות מחייב באמצעות אסימונים. אצווה היא מנוף שימושי נוסף. אצווה משלבת מספר בקשות בפעולת GPU אחת. זה יכול להעלות את התפוקה, במיוחד עבור עבודות לא מקוונות כגון תיוג מסמכים או יצירת הטבעה. יישומים מקוונים זקוקים לטיפול רב יותר מכיוון שהמתנה לכמות מלאה יכולה להגדיל את זמן התגובה. עבור צ'אט בוט חי, אני מודד: - זמן עד האסימון הראשון - זמן תגובה כולל - בקשות שהושלמו בשנייה - זמן המתנה לתור - ביצועים בגדלים שונים של אצווה גודל אצווה של שמונה עלול לשפר את התפוקה עבור עומס עבודה אחד וליצור המתנה רבה מדי לאחרת. ההגדרה הטובה ביותר נמצאת בדרך כלל באמצעות בדיקת עומס קטן, לא באמצעות כלל קבוע. אצווה דינמית יכולה לקבץ בקשות שמגיעות קרוב זו לזו. כלים כגון vLLM ו-NVIDIA TensorRT-LLM שיטות תמיכה שיכולות לשפר את השימוש ב-GPU עבור דגמים נתמכים. התצורה עדיין חשובה. לשירות צריך להיות מגבלת תור, זמן המתנה מרבי ויעד זמן תגובה. 3. השתמש בזמן ריצה מסקנות שמתאים למודל קריאת מודל Python גולמית עשויה להיות שימושית לבדיקה מוקדמת. מסקנות ייצור זקוקות לרוב לשליטה רבה יותר על זיכרון, תזמון וגרעיני GPU. האפשרויות הנפוצות כוללות: - vLLM לשרת בקשות רבות של מודל שפה - TensorRT-LLM עבור פריסות של NVIDIA GPU - ONNX Runtime עבור דגמי שנאים נתמכים - Hugging Face Optimum ליצוא מודלים וביצוע ספציפי לחומרה כלים אלו אינם ניתנים להחלפה עבור כל דגם. אני בודק תמיכת מודלים, תמיכת קוונטיזציה, התנהגות סטרימינג, תכונות אצווה ודרישות פריסה לפני שינוי זמן הריצה. המטמון של ערך מפתח ראוי לתשומת לב ביצירת אוטורגרסיבית. המודל מאחסן נתוני קשב ביניים כך שהוא לא מחשב מחדש את השיחה המלאה עבור כל אסימון חדש. המטמון הזה מאיץ את היצירה, ובכל זאת הוא משתמש בזיכרון. כניסות ארוכות, יציאות ארוכות ומשתמשים רבים במקביל יכולים להפוך את המטמון למגבלה העיקרית. תשומת לב בדיפ וגיבוש רציף יכולים לעזור לחלק מעומסי העבודה המשרתים להשתמש בזיכרון המטמון בצורה יעילה יותר. הם לא מסירים את הצורך להציב גבולות. אני עדיין מגדיר אסימוני קלט מקסימליים, אסימוני פלט מקסימליים וטווח מקביליות שהחומרה יכולה להתמודד איתו. אמת מידה פשוטה צריכה להשתמש בנתונים דמויי ייצור: ```מודל טקסט: אותו נקודת ביקורת המשמשת את האפליקציה קלט: הנחיות קצרות, בינוניות וארוכות פלט: מגבלת האסימון הרגילה במקביל: 1, 4, 8, 16, ועוד בעת הצורך מדדים: השהייה, תפוקה, זיכרון, שגיאות ועלות `` אני מריץ כל בדיקה יותר מפעם אחת. הבקשה הראשונה עשויה לכלול טעינת דגם או הגדרת זיכרון, ולכן אין לערבב אותה עם תוצאות במצב יציב. צוות אחד עשוי לגלות ששינוי בזמן ריצה מקצר את זמן התגובה הממוצע, בעוד שצוות אחר רואה תועלת מועטה מכיוון שהבעיה האמיתית היא הנחיות גדולות מדי. לכן הפרופיל חשוב יותר מאשר העתקת הגדרה מפרויקט אחר. האופטימיזציה השימושית ביותר היא לרוב הפחות דרמטית: צמצם הנחיה מ-12,000 אסימונים ל-3,000, הגדר מגבלת פלט ברורה והפסק לשלוח בקשות שאינן מצריכות יצירה. לאחר מכן, קוונטיזציה, אצווה ומנוע הסקה טוב יותר יכולים לספק יותר מקום. אני מתייחס להסקת שנאי כבעיית מדידה. התחל עם הדגם הקטן ביותר העונה על דרישות המשימה. שמור הנחיות בטווח שימושי. בדוק שינויי דיוק עם נתוני הערכה אמיתיים. כוונן אצווה עבור יעד התגובה, לא רק עבור תפוקה מקסימלית. בחר זמן ריצה המתאים לדגם ולחומרה. גישה זו אינה מבטיחה את אותה תוצאה עבור כל פריסה. זה נותן לי דרך ברורה למצוא את צוואר הבקבוק האמיתי, להפחית את השימוש במחשב הנמנע ולשפר את מהירות ההסקה מבלי להקריב את האיכות שהמשתמשים באמת צריכים.

דגמי שנאים יכולים לספק תוצאות חזקות, אך חשבונות GPU יכולים לעלות במהירות כאשר כל בקשה משתמשת בדיוק מלא, תשומות ארוכות ודגם גדול מדי. ראיתי שצוותים מוציאים יותר על קיבולת GPU סרק מאשר על עומסי עבודה פעילים. החדשות הטובות הן שחסכון רב נובע משינויים הנדסיים קטנים ולא מבנייה מחדש של דגם מלא. הנה שלוש דרכים מעשיות שהייתי מפחית את השימוש ב-GPU תוך שמירה על איכות הדגם בשליטה. 1. השתמש בדיוק מעורב במקום בו המודל תומך בו עומסי עבודה רבים של שנאים אינם זקוקים לכל חישוב כדי להשתמש במספרי נקודה צפה של 32 סיביות. דיוק מעורב מאפשר לפעולות נבחרות לפעול עם FP16 או BF16 תוך שמירה על חישובים רגישים בדיוק בטוח יותר. זה יכול להפחית את השימוש בזיכרון ולשפר את התפוקה במעבדי GPU התומכים בפורמטים אלה. שימוש נמוך בזיכרון עשוי גם לאפשר גודל אצווה גדול יותר, מה שעוזר ל-GPU לעבד יותר בקשות במהלך כל הפעלה. דוגמה בסיסית של PyTorch נראית כך: python with torch.autocast(device_type="cuda", dtype=torch.float16): outputs = model(**inputs) עבור GPUs של מרכז הנתונים החדשים יותר, BF16 יכול להיות אפשרות שימושית: python with torch.autocast="device", dfloat=="device): model(**inputs) הייתי בודק את המודל על ערכת אימות קטנה לפני העברת דיוק מעורב לייצור. בדוק את הדיוק, איכות התגובה, ערכי האובדן ושיעורי השגיאות. דגמים מסוימים עובדים עם FP16 או BF16 עם מעט שינוי. דגמים אחרים עשויים להראות תפוקות לא יציבות, במיוחד במהלך האימון. תהליך בדיקה שימושי הוא פשוט: - הפעל סט קבוע של דגימות הערכה בדיוק מלא. - הפעל את אותן דגימות בדיוק מעורב. - השווה איכות וזמן חביון. - שימו לב לגלישה, ערכי 'NaN' או שינויים בטקסט שנוצר. - שמור על הפורמט שעומד ביעד המוצר שלך. דיוק מעורב הוא לעתים קרובות נקודת התחלה בסיכון נמוך מכיוון שהוא משנה את הדרך שבה חישובים פועלים מבלי לשנות את ארכיטקטורת המודל. 2. צמצם אסימונים מבוזבזים ושפר אצווה שנאי מוציא מחשוב על אסימונים. הנחיות ארוכות, הוראות חוזרות, ריפוד ושטח פלט שאינו בשימוש, כולם מגדילים את עומס העבודה. לעתים קרובות אני מתחיל במדידת ארבעה ערכים: - אורך קלט ממוצע - אורך פלט ממוצע - אחוז האסימונים המרופדים - בקשות מעובדות לכל אצווה נתונים אלה יכולים לחשוף בעיה פשוטה. לדוגמה, צ'אטבוט תמיכה עשוי לקבל מגבלה של 4,096 אסימונים למרות שרוב השיחות משתמשות בפחות מ-900 אסימונים. הקיבולת הלא מנוצלת עדיין משפיעה על תכנון הזיכרון ויכולה להגביל את מספר הבקשות ש-GPU מטפל יחד. מספר שינויים יכולים לעזור: קצץ תוכן הנחיות חוזר ונשנה. שמור על מיקוד הוראות המערכת. אחסן חומר עזר יציב מחוץ להנחיה כאשר היישום יכול לאחזר רק את הסעיפים הרלוונטיים. קבץ בקשות לפי אורך. אצווה המכילה בקשה אחת של 2,000 אסימונים וכמה בקשות של 200 אסימונים עשויה ליצור כמות גדולה של ריפוד. בקשות דליית באורך דומה יכולות לשפר את ניצול ה-GPU. הגדר מגבלות פלט על סמך המשימה. תגובת סיווג קצרה אינה זקוקה לאותה מגבלת יצירה כמו כלי כתיבת דוחות. השתמש באצווה דינמית להסקת מסקנות. תור בקשות יכול לאסוף בקשות קרובות ולשלוח אותן לדגם כאצווה אחת. חלון האצווה צריך להישאר במסגרת יעד האחזור שלך. לדוגמה, צוות המשרת סיווג טקסט עשוי לגלות שבקשות מגיעות במרווחי זמן לא אחידים. הפעלת כל בקשה לבדה מותירה חלק מה-GPU ללא שימוש. אצווה דינמית קטנה יכולה להעלות את התפוקה מבלי לשנות את הדגם. ההגדרה הנכונה תלויה בתנועה. אצוות גדולות יותר יכולות לשפר את התפוקה, אך הן עשויות להגדיל את זמן ההמתנה ואת השימוש בזיכרון. הייתי מודד גם עלות לבקשה וגם זמן אחזור תגובה במקום לבצע אופטימיזציה של מספר אחד. 3. החל קוונטיזציה או השתמש במודל קטן יותר למשימה הנכונה קוונטיזציה מאחסנת משקלי מודל עם פחות ביטים. דגם המשתמש במשקלים של 16 סיביות עשוי להיות מומר לפורמטים של 8 סיביות או 4 סיביות לצורך הסקה, בהתאם לחומרה, מחסנית התוכנה ויעד האיכות. האפשרויות הנפוצות כוללות: - קוונטיזציה של 8 סיביות לאיזון בין שימוש ואיכות בזיכרון - קוונטיזציה של 4 סיביות כאשר לחץ הזיכרון גבוה - קוונטיזציה במשקל בלבד לעומסי עבודה נבחרים - זיקוק ידע לאימון דגם קטן יותר מדגם גדול יותר. זה לא מבטיח את אותה מהירות או איכות פלט בכל הגדרה, ולכן הבדיקה חשובה. הייתי משווה את המודלים המקוריים והמכומתים על נתונים המשקפים בקשות משתמשים בפועל. עבור מודל תמיכת לקוחות, ערכת הבדיקה צריכה לכלול שאלות קצרות, שיחות ארוכות, שמות מוצרים, שגיאות כתיב ובקשות הדורשות סירוב זהיר או הסלמה. מעקב: - דיוק משימות - ציוני סקירה אנושית - זמן השהיית תגובה - שימוש בזיכרון GPU - שיעורי שגיאות וחזרה - עלות לכל 1,000 בקשות מודל קטן יותר עשוי להיות בחירה טובה יותר למשימות פשוטות כגון זיהוי כוונות, ניתוח סנטימנטים או ניתוב מסמכים. דגם גדול יכול להישאר זמין למקרים מורכבים. גישת ניתוב מודל זו מונעת מכל בקשה להשתמש באפשרות היקרה ביותר. לא הייתי דוחס דגם רק בגלל שטביעת הזיכרון שלו נראית גדולה. אם האיכות יורדת, עבודת תמיכה נוספת ובקשות שנכשלו יכולות להסיר את החיסכון הצפוי. בקרת עלויות GPU עובדת בצורה הטובה ביותר כתהליך מדידה. התחל עם דיוק מעורב, הסר אסימונים מיותרים, שפר אצווה, ואז בדוק קוונטיזציה או ניתוב מודלים. הקפידו על בדיקת איכות בכל שלב. חשבון נמוך יותר שימושי רק כאשר השירות עדיין עונה על צרכי המשתמשים שלו. אמת מידה קטנה יכולה להנחות את ההחלטה: ```טקסט פורמט דגם: FP32 GPU זיכרון: 18 GB חביון: 210 ms ציון איכות: 92 פורמט דגם: BF16 GPU זיכרון: 11 GB חביון: 145 ms ציון איכות: 91 פורמט דגם: זיכרון GPU 8 סיביות: 8 GB 29 ms ציון איכות אלו: 13 ציוני איכות: 13 ציוני איכות: הבטחה לכל דגם. התעבורה שלך, החומרה, האורך המהיר ודרישות האיכות שלך יקבעו את התוצאה.

דגמי שנאים יכולים להתייקר הרבה לפני שה-GPU מגיע למגבלת החישוב המלאה שלו. תעבורת זיכרון, רצפי קלט ארוכים, טעינה חוזרת ונשנית של מודלים ואצווה חלשה יוצרים לעתים קרובות את צוואר הבקבוק האמיתי. ראיתי צוותים מוסיפים חומרה כאשר שינוי קטן יותר היה יכול להפחית את אותו הלחץ: כניסות קצרות יותר, דיוק נמוך יותר, שמירה טובה יותר במטמון או מערך הגשה נקי יותר. המטרה היא לא להסיר כל שכבה או לדחוף כל הגדרה לערך הנמוך ביותר שלה. המטרה היא למצוא היכן המודל מבלה זמן וזיכרון, ואז להפחית את העלות מבלי לפגוע באיכות הפלט שהמשתמשים שלך צריכים. מדוד את עומס העבודה הנוכחי אני מתחיל עם ערכת מבחנים קטנה שמשקפת את השימוש בפועל. זה צריך לכלול בקשות קצרות וארוכות, הנחיות נפוצות, שיעורי שיא של בקשות ואורך הפלט הרגיל של הדגם. אני רושם: - זמן השהייה ממוצע ו-p95 - אסימונים מעובדים בשנייה - שימוש בזיכרון GPU - ספירת אסימוני קלט ופלט - גודל אצווה - שיעור שגיאות - איכות פלט בערכת הערכה קבועה שלב זה מונע ניחושים. מודל עשוי להראות שימוש נמוך במחשוב בזמן המתנה לגישה לזיכרון. דגם אחר עשוי להשתמש ברוב ה-GPU מכיוון שאורך הרצף גדול מדי. התיקון יהיה שונה. פרופיל פשוט יכול לחשוף האם העלות העיקרית מגיעה מ: - כפל מטריקס - תשומת לב על פני רצפים ארוכים - צמיחת מטמון מפתח-ערך - העברת נתונים בין CPU ו-GPU - Tokenization - טעינת מודל - אצווה קטנה אני שומר על תנאי הבדיקה יציבים תוך כדי שינוי הגדרה אחת בכל פעם. זה עושה את התוצאה קלה יותר לסמוך. צמצם בזבוז אסימונים כל אסימון קלט גוזל זיכרון וזמן עיבוד. יישומים רבים שולחים הוראות חוזרות, היסטוריית צ'אט ארוכה, קטעי מסמכים שאינם בשימוש או מטא נתונים משוכפלים. אני בודק את הבקשה המלאה לפני שהיא מגיעה למודל: - הסר טקסט מערכת חוזר במקום שבו עיצוב ההגשה מאפשר זאת - חתוך סיבובי שיחה ישנים - אחסן מסמכים ארוכים מחוץ להנחיה ואחזר רק קטעים שימושיים - הסרת שדות ריקים ועיצוב חוזר - הגדר מגבלת פלט מעשית - השתמש בתבנית בקשה קטנה יותר. השליפה יכולה להפחית את הקלט תוך שמירה על הקטעים הרלוונטיים. שינוי זה עולה לעתים קרובות פחות מניתוח מודל. זה גם מונע אובדן איכות הנגרם על ידי דחיסה אגרסיבית. השתמש בדיוק נמוך יותר דגמי שנאים רבים מאומנים או מוגשים עם משקולות של 16 סיביות. פורמטים בעלי דיוק נמוך יותר יכולים להפחית את השימוש בזיכרון ועשויים לשפר את התפוקה בחומרה התומכת בהם. האפשרויות הנפוצות כוללות: - FP16 או BF16 לתמיכה רחבה - INT8 לכימות משקל או הפעלה - INT4 לשימוש בזיכרון נמוך יותר - GPTQ או AWQ עבור כמה מודלים של שפות גדולות קוונטיזציה משנה את האופן שבו ערכי מודל נשמרים. ייצוג קטן יותר יכול להפחית את תעבורת הזיכרון, אך ההשפעה תלויה בדגם, בחומרה, בזמן הריצה ובעומס העבודה. אני בודק גרסאות כמותיות מול אותו מערך הערכה. אני בודק תשובות עובדתיות, דיוק סיווג, פלט קוד, התנהגות סירוב וסגנון תגובה כאשר התכונות הללו חשובות למוצר. דפוס שימושי הוא לשמור על שכבות רגישות ברמת דיוק גבוהה יותר תוך כימות שכבות אחרות. הטמעת שכבות, ראשי פלט ובלוקי קשב עשויים להגיב אחרת. ההגדרה הטובה ביותר היא לעתים קרובות פשרה מדודה ולא רוחב הסיביות הנמוך ביותר הזמין. ספריות כגון bitsandbytes, llama.cpp, TensorRT-LLM ו-ONNX Runtime מספקות נתיבי קוונטיזציה שונים. התוצאות שלהם אינן ניתנות להחלפה, אז אני מסמן את זמן הריצה המדויק בשימוש בייצור. הסר עבודה שאינה משפיעה על התוצאה גיזום מפחית משקלים או מבנים נבחרים ברשת. גיזום לא מובנה יכול ליצור ערכי אפס רבים, אך ייתכן שהחומרה לא תשתמש בהם ביעילות. גיזום מובנה מסיר ערוצים מלאים, ראשים או בלוקים ויכול להיות קל יותר לביצוע של זמן ריצה. התהליך נראה כך: 1. צור קו בסיס איכותי. 2. זהה שכבות או ראשים עם השפעה נמוכה. 3. יש למרוח מפלס גיזום קטן. 4. כוונן בעת ​​הצורך. 5. מדדו שוב איכות, חביון וזיכרון. 6. שמור את השינוי רק כאשר ערימת ההגשה יכולה להשתמש בו. גיזום אינו אוטומטית שיפור מהירות. מודל עם הרבה משקלי אפס עשוי לפעול באותה מהירות אם הגרעין מתייחס למטריצה ​​כצפופה. לשינויים מובנים יש דרך ברורה יותר להורדת החישוב, אך הם יכולים לגרום לאובדן איכות רב יותר. זקק את המודל למשימות שגרתיות זיקוק ידע מכשיר מודל תלמיד קטן יותר שיתאים למורה גדול יותר. זה עובד היטב כאשר למשימה יש היקף ברור, כגון סיווג רגשות, זיהוי כוונות, תיוג מסמכים או תמיכה בתשובות קצרות. לדוגמה, DistilBERT נוצרה כגרסה קטנה יותר של BERT באמצעות זיקוק ושיטות אימון נלוות. ייתכן שצוות שרק צריך סיווג כרטיסים לא צריך מודל שפה כללי גדול לכל בקשה. אני מגדיר את התלמיד סביב המשימה בפועל: - אילו תשומות הוא מקבל? - אילו תוויות או פלטים הוא מייצר? - אילו טעויות עולות ביוקר? - כמה הקשר צריך? - האם זה צריך דור פתוח? דגם קטן יותר יכול להיות מהיר וזול יותר באותו GPU. יכול להיות שזה לא יתאים למורה בהיגיון רחב או בבקשות חריגות, אז אני מנתב אליו רק משימות מתאימות. עיצוב פרקטי משתמש בדגם קטן לבקשות נפוצות וצרות ושולח מקרים לא ודאיים לדגם גדול יותר. יש לבדוק את כלל הניתוב עם דגימות תעבורה אמיתיות ולא על סמך גודל הדגם בלבד. שפר את האצווה הגשת בקשה אחת בכל פעם מותירה את החומרה במצב לא פעיל כאשר בקשות מגיעות קרוב זו לזו. אצווה משלבת עבודה לשלב ביצוע אחד. אצווה סטטית מחכה לקבוצה קבועה. אצווה דינמית אוספת בקשות לחלון קצר. אצווה רציפה מעדכנת את הקבוצה עם סיום הרצפים, מה שיכול לעבוד היטב עבור יצירת טקסט. קל לפספס את ההחלפה. חלון המתנה ארוך יותר עשוי לשפר את התפוקה תוך הגדלת זמן האחזור של התגובה. אני מגדיר זמן המתנה מקסימלי ומודד את שני הערכים. אני גם מפרידה עומסי עבודה כשהצורות שלהם שונות. אצווה המכילה הנחיה אחת ארוכה מאוד והנחיות קצרות רבות עלולה לבזבז זיכרון ולדחות בקשות קצרות. קיבוץ בקשות לפי אורך קלט משוער יכול לייצר ביצועים יציבים יותר. כלי הגשה כגון vLLM, TensorRT-LLM ו-Huging Face TGI תומכים באסטרטגיות אצווה ואסטרטגיות מטמון שונות. הבחירה הנכונה תלויה בארכיטקטורת הדגם ובדור ה-GPU. נהל את מטמון המפתח-ערך הדור האוטורגרסיב מאחסן מצבי מפתח וערכים מאסימונים קודמים. מטמון זה מונע מהמודל לחשב מחדש את ההיסטוריה המלאה עבור כל אסימון חדש, אם כי הוא גדל עם אורך ההקשר, ספירת השכבות וגודל האצווה. אני שולט בצמיחת המטמון על ידי: - הגדרת מגבלת הקשר התואמת את צורכי המוצר - הגבלת אסימוני פלט מקסימליים - שימוש חוזר בקידומת משותפת כאשר זמן הריצה תומך בה - פינוי היסטוריית צ'אט ישנה - שימוש בתשומת לב מדפדת או ניהול זיכרון דומה - בדיקת דיוק מטמון כאשר שיחות ארוכות נתמכות יכולות לצרוך יותר זיכרון ממשקל הדגם. מודל שמתאים במהלך מבחן קצר עלול להיכשל כאשר מספר משתמשים שולחים היסטוריות ארוכות בו-זמנית. שמירת קידומת במטמון יכולה לעזור כאשר בקשות רבות חולקות את אותה הנחיה מערכת או קידומת מסמך. היתרון תלוי בתדירות שבה הקידומת חוזרת וכיצד זמן הריצה מאחסן אותה. השתמש בתשומת לב ובגרעינים אופטימליים ​​ביצועי תשומת הלב תלויים באורך הרצף ובפרטי היישום. גרעינים כגון FlashAttention מפחיתים תנועת זיכרון מיותרת על ידי שינוי אופן חישוב ואחסון הקשב. פלט הדגם מתוכנן להישאר קרוב לתשומת הלב הסטנדרטית, אך התמיכה המדויקת משתנה בהתאם לארכיטקטורה ולמחסנית התוכנה. כלי מהדר יכולים למזג מספר פעולות לגרעין אחד. תכונות הידור של ONNX Runtime, TensorRT ו- PyTorch עשויות להפחית את תקורה ההשקה עבור עומסי עבודה יציבים. אני נמנע מהפעלת כל אופטימיזציה בבת אחת. שינוי גרעין יכול לשפר צורת קלט אחת ולבצע ביצועים גרועים באחרת. אני בודק הנחיות קצרות, הנחיות ארוכות, אצוות קטנות ורמת המקבילות שבה משתמש היישום. שמור את הדגם על המכשיר במידת האפשר העברת טנסורים בין מעבד ו-GPU יוצרת עיכוב. העברות תכופות יכולות להסיר את הערך של דגם קטן יותר. אני בודק: - היכן נטענים משקלי הדגם - היכן פועל האסימון - היכן מועתקים קלט - האם טנסור ביניים נע בין התקנים - האם המסגרת טוענת מחדש או מקצה מחדש זיכרון - האם מספר תהליכים מתחרים על אותו פריקת מעבד GPU יכול לעזור לדגם להשתלב בזיכרון, אבל זה עשוי להפחית את מהירות התגובה. יש להתייחס אליו כאל אפשרות קיבולת, לא כתיקון ביצועים מובטח. גם טעינת הדגם חשובה. שירות המעמיס משקלים עבור כל בקשה משלם עלות גדולה לפני תחילת היצור. שמירה על חום של עובד יכולה למנוע עבודה חוזרת ונשנית זו, בעוד שמגבלות הזיכרון עדיין מצריכות ניטור. בחר את הדגם הקטן ביותר שעומד ביעד גודל הדגם הוא רק חלק אחד מההחלטה. מודל גדול יותר עם קוונטיזציה ואצווה טובה עשוי לשרת עומס עבודה בצורה חלקה יותר מדגם קטן יותר עם בקרת קלט גרועה. דגם קטן עלול להיכשל לעתים קרובות מדי וליצור עבודת סקירה נוספת. אני משווה מודלים מועמדים באמצעות אותו הדבר: - הנחיות הערכה - טווח אורך קלט - מגבלת אורך פלט - חומרה - זמן ריצה - מדיניות אצווה - סף איכות עבור מסווג תמיכת לקוחות, קטגוריות דיוק ושגיאות עשויות להיות חשובות יותר מאשר שטף פתוח. עבור עוזר קידוד, תוקף התחביר ותוצאות הבדיקה עשויות להיות חשובות יותר מזמן תגובה ממוצע קצר. נתיב הפעלה מעשי אני משתמש בהזמנה זו עבור רוב הפרויקטים: 1. צור פרופיל של המערכת הנוכחית. 2. חותכים אסימונים חוזרים ומיותרים. 3. הגדר גבולות קלט ופלט הגיוניים. 4. אפשר אצווה מתאימה. 5. בדוק אפשרויות FP16, BF16, INT8 או INT4. 6. הוסף תשומת לב אופטימלית או גרעינים מהודרים. 7. סקור את השימוש במטמון והעברות מכשירים. 8. בדוק דגם קטן יותר או מזוקק. 9. הוסף גיזום רק כאשר זמן הריצה יכול להשתמש בו. 10. מעקב אחר איכות והשהייה לאחר הפריסה. רצף זה מתחיל בשינויים שקל להפוך אותם. זה גם עוזר להפריד פסולת תוכנה מגודל הדגם. צוות לא תמיד צריך GPU נוסף כדי לשרת היטב דגם שנאי. הנתיב הטוב יותר עשוי להיות הנחיה קצרה יותר, מחסום כמותי, מודל סטודנט קטן יותר או שכבת הגשה שמעסיקה את ה-GPU. אני מתייחס לכל שינוי כאל ניסוי מדוד: שומר על יעד האיכות הפונה למשתמש קבוע, משנה מנוע עלות אחד ומשווה את התוצאה מול אותו עומס עבודה. לכל שאלה בנוגע לתוכן מאמר זה, אנא צור קשר עם איימי וו: amy.wu@ihuagroup.com/WhatsApp +8613612662976.

Vaswani, Ashish, et al. 2017, Attention Is All You Need Micikevicius, Paulius, et al. 2018, Mixed Precision Training Sanh, Victor, et al. 2019, DistilBERT: גרסה מזוקקת של BERT Frantar, Elias, et al. 2022, GPTQ: קוונטיזציה מדויקת לאחר אימון עבור רובוטריקים שהוכשרו מראש Dao, Tri, et al. 2022, FlashAttention: תשומת לב מדויקת מהירה וחסכונית בזיכרון עם IO-Awareness Kwon, Woosuk, et al. 2023, ניהול זיכרון יעיל להגשה של מודל שפה גדול עם PagedAttention