פורמטים של כימות LLM: INT8, INT4, GPTQ, AWQ, GGUF — מה לבחור?

מדוע כימות LLM שובר את איכות התשובות

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

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

הראשונים להיפגע הם סוגי בקשות צפויים: חילוץ שדות מחוזים, אריתמטיקה על טבלאות, יצירת קוד בהסתמך על קריאות נדירות, הוראות מרובות שלבים ועבודה עם הקשר ארוך ближе לסופו. פורמט התשובה נשמר ברזולוציה נמוכה — המודל מחזיר בביטחון את המבנה הנדרש, אך העובדות בתוכו מוחלפות באמינות לכאורה.

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

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

מה נותן כיווץ משקולות: מהירות תגובה ונפח זיכרון

משקל המודל תופס את רוב הזיכרון בעת עבודתו בהסקה — ומכווץ ראשון. מעבר מדיוק מלא ל-INT8 מקטין אותו בערך בחצי, ל-INT4 — פי שלושה עד ארבעה. הנפח שהתפנה מוקדש למטמון ההקשר ולגודל מוגדל של אצוות בקשות: החיסכון בזיכרון הופך לרזרבה שבדרך כלל חסרה בעומס שיא.

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

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

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

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

בעת כיווץ אגרסיבי ללא כיול בדומיין שלך, איכות התשובות עלולה לרדת, לכן את הפורמט — GPTQ, AWQ, GGUF — בוחרים לפי המשימה ופרופיל התעבורה, ולא לפי העיקרון "כמה שפחות ביטים, כך טוב יותר".

השוואה בין פורמטים של כיווץ משקולות: דיוק ומגבלות

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

להלן אלטרנטיבות אמיתיות, שביניהן בוחרים בעמדת הבדיקה.

בפועל מחזיקים שתיים-שלוש בניות: אחת עם רזרבה בדיוק למשימות מורכבות, שנייה — מכווצת יותר, לבקשות המוניות. קריטריון הבחירה אינו מדד ממוצע, אלא הפער בין התשובות לבין המודל המלא על מערך המשימות שלך. מערכי כיול ותיאורי שיטות נוח לקחת ב-Hugging Face — שם גם רואים על איזה נתונים נבדק הפורמט.

כיצד מתבצעת ההטמעה: ביקורת, סכמה, בדיקה, מסירה

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

1. ביקורת מודל. מתעדים מדדי בסיס בדיוק מלא: שיעור התשובות הנכונות על מערך הבקשות שלך, זמן תגובה, צריכת זיכרון. בנפרד מסמנים תרחישים שבהם שגיאה יקרה במיוחד — הם יהיו בקרתיים.
2. בחירת מצב כיווץ. משווים בין דרישות האיכות למשאבים הזמינים: INT8 — אפשרות זהירה, INT4 עם כימות קבוצתי (GPTQ, AWQ) — כשהזיכרון חשוב יותר, GGUF — להרצה מקומית.
3. הגדרת כיווץ. אוספים מערך כיול מבקשות אמיתיות, קובעים גודל קבוצה ומשאירים שכבות רגישות בדיוק מוגבר — זה זול יותר מאשר לאבד איכות על כל הטווח.
4. בדיקת איכות. מריצים את הגרסה המכווצת על תרחישי בקרה ומשווים לבסיס: שיעור התאמות, קוהרנטיות התשובות, התנהגות בהקשר ארוך. פער מעל לסף — חוזרים להגדרה, ולא תולים זאת במאפייני הכיווץ.
5. הגנה וחזרה לאחור. שומרים עותק מלא ומגרסאים את המשקולות, כדי שהחזרה לגרסה הקודמת תימשך דקות.
6. מסירת הפתרון. מוסרים משקולות, קונפיגורציות, סקריפטים לבנייה ותקנון: כיצד לעדכן את המודל, במה למדוד איכות, לפי אילו מדדים לחזור לאחור. המהנדסים שלך משחזרים את הבנייה בלעדינו.

את כל המדידות והפרמטרים הנבחרים מתעדים בדוח — נראה מדוע מצב הכיווץ הזה התאים ומה ישתנה במעבר לאחר.

רשימת ארטיפקטים: קונפיגורציות, סכמות, תקנונים

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

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

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

מקרה בוחן: צמצמנו את צי הציוד ללא אובדן איכות

כיצד מדדנו ומה קרה

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

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

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

מה לא עבד בפעם הראשונה

הריצה הראשונה הייתה INT4 אחיד על כל הרשת: בשאלות קצרות לא ראו הבדל, אבל בהקשרים ארוכים המודל איבד תנאים מאמצע הדיאלוג והתבלבל בסעיפי התקנון. הערכת תשובות על ידי סימון מפעילים ירדה מ-91% ל-82% — בולט יותר ומהר יותר מהירידה במהירות.

חזרנו לסכמה מעורבת: כיול לכימות קבוצתי נאסף מפניות אמיתיות במשך חודש, שכבות קריטיות הושארו ב-INT8 והוכנס מערך רגרסיה שמורץ לפני כל עדכון משקולות. בפלט — 90% התאמה לתשובות המודל המלא עם רוחב פס גבוה פי 2.6 מהמקורי.

במה שונה כימות LLM לשירות ולמכשיר?

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

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

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

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

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

ספקות טכניים נפוצים לפני ההתחלה

לפני ההתחלה עולים אותם שאלות: האם איכות התשובות תיפגע, מה לעשות בעת עדכון המודל, האם הגרסה המכווצת תעמוד בעומס שיא. פורמט המשקולות — INT8, INT4, GPTQ, AWQ או GGUF — משנה את שיטת הכיווץ, אבל הספקות עצמם נשארים משותפים.

את התשובות להלן אנו בודקים על הנתונים שלך, ולא על מדדים ממוצעים.

מה קורה בעת עדכון המודל?

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

כיצד מתנהג המודל המכווץ תחת עומס שיא?

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

כבר פרוסה גרסה מלאה — האם יהיה צורך להכל מחדש?

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

נדון במשימה ונחזור עם הערכה ותוכנית

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

בתגובה אנו מחזירים:

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

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