מושגים במודלי שפה, בלי להסתבך
לא צריך להיות חוקרי ML כדי לבחור איך להריץ מודל. כאן מסבירים את המונחים, ומה כדאי לבדוק כשבוחרים מודל וסביבת הרצה.
בעמוד הזה
מנוע הרצה: התוכנה שמריצה את המודל
המודל כולל את המשקלים שנלמדו ואת ההגדרה של החישובים. מנוע ההרצה, serving engine, הוא התוכנה שטוענת אותו, מבצעת את החישובים על החומרה ומטפלת בבקשות. השרת שסביבו בדרך כלל מספק API שאפשר לפנות אליו מהאפליקציה.
Inference הוא הרצה של מודל מאומן כדי לקבל פלט, למשל תשובה לשאלה. זה שונה מאימון, שבו משנים את הפרמטרים שנלמדו. מנוע ההרצה, החומרה והגדרות הבקשה יכולים להשפיע על צריכת הזיכרון ועל זמני התגובה. שם המודל לבדו לא מתאר את סביבת ההרצה.
Tokens וחלון ההקשר: כמה טקסט המודל מעבד
Token הוא יחידת טקסט שהמודל עובד איתה. זו יכולה להיות מילה, חלק ממילה, סימן פיסוק או קטע טקסט אחר. ה־tokenizer הוא הרכיב שמחלק את הטקסט ל־tokens. אותו משפט יכול להתפצל אחרת במודלים שונים, וגם לשפה יש השפעה על מספר ה־tokens.
Prompt הוא הקלט שנותנים למודל: הוראות, שאלה ומידע שיכול לעזור לו לענות. שינוי ה־prompt משנה את הקלט, ולא מאמן את המודל.
חלון ההקשר, context window, הוא מגבלת ה־tokens שהמודל יכול לעבוד איתם בבקשה. ההוראות, היסטוריית השיחה, המסמכים, תוצאות הכלים והתשובה שנוצרת צריכים להיכנס במגבלה הרלוונטית. חלון גדול לא מבטיח שהמודל ישתמש נכון בכל פרט שנמצא בו.
מה כדאי לשאול: האם הקלטים והתשובות שלנו נכנסים במגבלה? והאם המודל עדיין עונה נכון כשהפרט החשוב נמצא עמוק בתוך קלט ארוך?
Streaming: רואים את התשובה בזמן שהיא נוצרת
ב־streaming, חלקי התשובה נשלחים לאפליקציה תוך כדי שהמודל מייצר אותם. המשתמש יכול להתחיל לקרוא עוד לפני שהתשובה הושלמה. בלי streaming, האפליקציה מחכה לתשובה המלאה.
זו דרך להעביר את התשובה, והיא לא מאיצה כשלעצמה את יצירת הטקסט במודל. האפליקציה צריכה גם לדעת לטפל בטקסט חלקי, בתשובה שנקטעה ובשגיאות.
זמני תגובה וקצב עבודה: מה בדיוק מודדים?
- Latency
- הזמן שעובר מתחילת הבקשה עד לנקודה שמודדים. צריך לציין אם זו תחילת התשובה, התשובה המלאה או השלמת המשימה באפליקציה.
- TTFT
- קיצור של Time to first token: הזמן עד שהלקוח מקבל את ה־token הראשון שנוצר. ההמתנה בתור, עיבוד הקלט והעברת התשובה ברשת יכולים כולם להשפיע עליו.
- קצב יצירת הטקסט
- כמה מהר מגיעים tokens אחרי שהמודל התחיל לייצר תשובה. נהוג למדוד ב־tokens לשנייה. המדד לא כולל את כל ההמתנה שלפני ה־token הראשון.
- Throughput
- כמות העבודה שהמערכת מסיימת לאורך זמן, על פני הבקשות השונות. שרת יכול לטפל ביותר בקשות בסך הכול, ובו בזמן לגרום לכל משתמש לחכות יותר.
מה כדאי לשאול: מה נמדד, באילו אורכי קלט ותשובה, וכמה בקשות רצו במקביל? כדי להשוות תוצאות צריך למדוד את אותו הדבר.
Fine-tuning: אימון נוסף למשימה מסוימת
ב־fine-tuning מתחילים ממודל קיים ומאמנים אותו על דוגמאות שנבחרו למשימה. המטרה יכולה להיות שינוי באופן שבו הוא מבצע משימה, שימוש במונחים מקצועיים או הקפדה על פורמט פלט. בהתאם לשיטה, מעדכנים את משקלי המודל או קבוצות קטנות של פרמטרים נוספים שנקראות adapters.
זה שונה מהוספת הוראות או מסמכים ל־prompt. למידע שמתעדכן לעיתים קרובות, שליפת מסמכים רלוונטיים בזמן הבקשה עשויה להתאים יותר. לפני שמאמנים, כדאי להשוות ל־prompt טוב ולבדוק את התוצאה על דוגמאות שלא נכללו באימון.
Frontier models: המודלים המובילים, לפי ההקשר
Frontier models הוא כינוי למודלים שנמצאים בחזית היכולות בתקופה מסוימת. ההגדרה משתנה לפי ההקשר, והמודלים המובילים מתחלפים. הכינוי לבדו לא אומר שמודל מתאים למשימה שלכם, שכדאי כלכלית להריץ אותו או שהרישיון שלו מתאים לשימוש שלכם.
מה כדאי לשאול: באיזה מודל ובאיזו גרסה מדובר, ועל איזו משימה בדקו אותו? אלה פרטים מועילים יותר מהכינוי כשצריך לבחור מה להריץ.
Speculative decoding: מציעים המשך, והמודל בודק
ביצירת טקסט רגילה המודל מתקדם token אחרי token. ב־speculative decoding, תהליך זול יותר מציע כמה tokens להמשך, והמודל הראשי בודק אותם יחד. הצעות שהתקבלו יכולות לחסוך עבודה, אבל גם בדיקת הצעות שנדחו עולה זמן. התועלת תלויה במודל, בתוכנה ובסוג הבקשות.
Draft agreement מתאר עד כמה ה־tokens שהוצעו תואמים לאלה של המודל הראשי או מתקבלים אצלו, בהתאם לשיטת המדידה. המדד עוזר להבין אם ההצעות מועילות להאצה. הוא לא אומר שהתשובה נכונה עובדתית או שהקוד שנוצר עובד.
אלגוריתמים מדויקים של speculative decoding נועדו לשמור על התפלגות הפלט של המודל הראשי כשהם ממומשים נכון. כלומר, לא לשנות את הסיכויים של המודל לבחור בפלט מסוים. גם את התכונה הזאת צריך לוודא במערכת שרצה בפועל, לצד מדידת המהירות.
Pruning: הסרה של חלקים מהמודל
Pruning הוא הסרה או איפוס של משקלים נבחרים או קבוצות רכיבים במודל. ב־quantization, לעומת זאת, שומרים את הערכים בדיוק מספרי נמוך יותר. שתי השיטות יכולות לחסוך משאבים, אבל הן משנות את המודל בדרכים שונות.
איפוס ערכים לבדו לא מבטיח קובץ קטן יותר או הרצה מהירה יותר. פורמט האחסון והתוכנה צריכים לדעת לנצל את מה שהוסר. כמו ב־quantization, בודקים מחדש את איכות התשובות ואת הביצועים אחרי השינוי.