קוונטיזציה מודעת-רגישות מוסברת: כיצד OrcaSAQ מחליט אילו משקלים מקבלים יותר ביטים

קוונטיזציה מודעת-רגישות היא הנוהג של השקעת תקציב הביטים שלך במקום שבו זה חשוב: הטנזורים שהקוונטיזציה פוגעת בהם ביותר מקבלים יותר ביטים, וכל יתר הטנזורים נשארים ברוחב בסיס נמוך יותר. מאמר זה מסביר כיצד OrcaSAQ — השיטה שלנו לדיוק מעורב, נטולת כיול ומודעת ארכיטקטורה, ששוחררה עם GLM-5.3-Flash, משפחת הקוונטיזציה, orcarouter/GLM-5.3-Flash-MLX — מחליטה אילו מבין 37,338 הטנזורים במודל תערובת-מומחים בעל 320 מיליארד פרמטרים ראויים לביטים נוספים, באופן מלא ללא מערך נתוני כיול. הלקח שניתן להעביר לכל מי שמכמת MoE אחר: מומחים משותפים והיטלים למטה זוכים לביטים הנוספים, וניתן למצוא אותם באמצעות מטא-נתוני הקוונטיזציה של המהדורה הקודמת עצמה בלבד.

התשובה הקצרה

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

מה שזה קונה לך הוא פייפליין מהיר, דטרמיניסטי וללא כיול. אין קורפוס כיול שצריך להרכיב, אין חיפוש רגישות לכל שכבה, ואין כוונון חוזר לכל מודל, כך שאותו מתכון עובר לארכיטקטורה חדשה ביום שבו המשקולות שלה משוחררות. מה שהוא מוותר עליו הוא התאמה: שיטה מונעת כיול כמו GPTQ או AWQ מסתכלת על התפלגות האקטיבציות בפועל של המודל שלך והנתונים שלך, ובדרך כלל היא תסחוט יותר איכות מאותו רוחב סיביות ממוצע. ההימור של OrcaSAQ הוא שעבור מודלים מסוג Mixture-of-Experts, התפקיד של טנזור אומר לך את רוב מה שהרצת כיול הייתה אומרת, בשבריר מהעלות.

שתי דרכים למציאת המשקלים הרגישים

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

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

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

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

המדיניות: אילו טנזורים מקבלים יותר ביטים

מדיניות הקצאת הסיביות של OrcaSAQ מצוינת בכרטיס המודל עבור orcarouter/GLM-5.3-Flash-MLX, והיא מסתכמת בשלושה כללים ועוד חריג אחד. הבסיס הוא זה שדיוקו הוא הבנייה שאתה מבצע — 6, 4, 3, או 2 ביטים —, והמדיניות מעלה תפקידי טנזור ספציפיים מעליו:

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

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

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

• לא עבר קוונטיזציה, נשמר ב-BF16: 34 שכבות הקשב הליניאריות, האינדקסר הדליל המאומן, מערכי ההיפר-חיבור, הנורמות, embed_tokens, lm_head, ומגדל הראייה כולו. אלה לא היו FP8 במהדורת ה-upstream, והם נשארים בדיוק מלא.

ביטים מתעגלים כלפי מעלה לרוחב הנתמך על ידי MLX הקרוב ביותר, {2,3,4,5,6,8}. באופן קונקרטי, על GLM-5.3-Flash — 320B סה״כ / 18B פעילים, 288 מנותבים ועוד מומחה משותף אחד עם ניתוב top-8, 45 שכבות — הגרסה של 4 ביטים נותנת למומחה המשותף 6 ביטים, לכל היטל down 5 ביטים, ולהיטלי gate ו-up 4 ביטים. הגרסה של 6 ביטים מעגלת את היטלי ה-down כלפי מעלה ל-8 ביטים. גודל הקבוצה הוא 64 עבור גרסאות ה-4 וה-6 ביטים, 32 עבור 2 ו-3 ביטים, והמומחה המשותף תמיד משתמש ב-64.

האם כלל המומחה המשותף שווה את זה? בבסיס 2-bit המומחה המשותף יושב על 4 סיביות ובבסיס 6-bit הוא יושב על 8 — בשני המקרים שתי הסיביות הנוספות עולות בזיכרון שהמומחים המנותבים יכלו אחרת להשתמש בו, והמספרים של כרטיס המודל עצמו, שנדונים להלן, מרמזים שהעסקה משתלמת. זה אותו היגיון שהופך את בניית ה-2bit-lite לשווה משלוח בכלל: המומחה הפעיל תמיד הוא המקום היחיד שבו קצת דיוק נוסף קונה הכי הרבה.

כלל הבחירה: _scale_inv כאות רגישות חופשית

מדיניות הקצאת הביטים מניחה שאתה כבר יודע אילו טנסורים הם מועמדים. בחירת הקבוצה הזו היא המקום שבו OrcaSAQ הוא הכי חכם, כי הכלל הוא מכני ואינו דורש נתונים: טנסור עובר קוונטיזציה מחדש אם ורק אם מהדורת ה-FP8 כללה אותו עם מלווה _scale_inv.

למה זה עובד: הבסיס של GLM-5.3-Flash במעלה הזרם הוא FP8 — לפי בלוקים e4m3, בלוקים של 128×128, עם מנגנון אקטיבציה דינמי. קוונטיזציית FP8 לפי בלוקים מאחסנת סקלה לכל בלוק ואת ההופכי שלה לצד המשקל; נוכחות של _scale_inv בצ'קפוינט היא סמן עמיד לכך שהטנזור עבר במסלול הקוונטיזציה במעלה הזרם. המהדורה במעלה הזרם כבר אמרה לך אילו טנזורים בטוחים לקוונטיזציה — אין הסיאן, אין קורפוס כיול, אין מעברים קדימה.

עבור GLM-5.3-Flash, קבוצה זו כוללת את השכבות הליניאריות של MoE ושל dense-MLP, וכן את ארבע ההטלות של כל deepseek_sparse_attentionבלוק — q_a_proj, q_b_proj, kv_a_proj_with_mqa, ו-o_proj — על פני 11 השכבות הדלילות בעומקים 3, 7, 11 … 43, יחד עם בלוק ה-MTP, כלומר 12 × 4 = 48 טנסורים. כל השאר מעולם לא נשא את הסמן ונשאר ב-BF16: 34 linear_attention שכבות, האינדקסר הדליל ומגדל הראייה. שכבת ה-MTP — שכבה 45 — כלולה בתוך המשקלים המכומתים במקום להיות מיוצאת כמודול נפרד.

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

המלכוד: הגדרות ברמת מודול, לא ביטים ברמה העליונה

אם אתה כותב קוונטייזר MLX משלך — וזה קהל היעד של החלק הזה — הדבר השימושי ביותר בכרטיס המודל הוא אזהרה: ברמה העליונה, bits ו-group_size ב-config.json אינם מספיקים.

בסך הכול, 37,338 טנזורים עברו קוונטיזציה. ההקצאה מתועדת ב-config.json → קוונטיזציה כביטולים לפי מודול של {group_size, bits} הממופתחים לפי נתיב מודול MLX — לדוגמה model.layers.3.mlp.switch_mlp.down_proj. כיוון ש-MLX מאחד את המומחים המנותבים של שכבה למודול switch_mlp אחד, 173 ערכים מכסים את כל 37,338 הטנזורים.

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

האם המדיניות משלמת על עצמה?

הראיות הן שלנו, נמדדו על מודל אחד: GLM-5.3-Flash, כל build עבר דה-קוונטיזציה והורץ דרך אותו glm5_next קדימה, כך שהמשתנה היחיד הוא הקוונטיזציה. המספרים שלהלן הם מכרטיס המודל, והם אינם אמות מידה של ספק או נתונים של צד שלישי — התייחסו אליהם כנקודת נתונים בודדת, לא כחוק.

פרפלקסיטי, לעומת ערך הייחוס של FP8 שעומד על 2.7797: 6-bit 2.7864 (0.24%+), 4-bit 2.8620 (2.96%+), 3-bit 3.0566 (9.96%+), 2-bit 4.3622 (56.9%+).

• התאמת הטוקן ברמת Top-1 לייחוס, באותו סדר: 97.76%, 96.13%, 92.06%, 86.56%.

הקריאה תואמת בדיוק למה שהמדיניות מנבאת. הכל עד 3-bit מתדרדר בעדינות — זהו חתימתו של תקציב ביטים שהושקע בטנסורים הנכונים — ו-2-bit הוא מצוק, כי מתחת לנקודה מסוימת ההעלאות מבוססות התפקיד מפסיקות לכסות את הנזק. ב-4-bit, +2.96% פרפלקסיטי עבור build הקטן בכ-38% מהייחוס FP8 הוא פשרה טובה באמת, וזוהי אותה מדיניות, מיושמת באגרסיביות רבה יותר, שמאפשרת ל-build של 102 GB בגרסת 2bit-lite להיטען בכלל. מתרגלים עצמאיים שמכמתים את אותו הבסיס מדווחים על אותו הסדר — המדרגות העליונות קרובות לרצפת הרעש, 4-bit אמיתי אך מתון — עם מספרים מוחלטים שונים מקורפוס הערכה שונה.

מה עובר ל-MoE שלך

החשיבה לשימוש חוזר, עבור מודל שאינו שלנו:

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

• מצא את צווארי הבקבוק השיוריים.ההיטל שכותב לזרם השיורי (בדרך כלל היטל ההמטה של כל בלוק MLP) מקבל בסיס +1. השגיאה שם נראית בכל שכבה עמוקה יותר.

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

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

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

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

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

כאשר OrcaSAQ היא הבחירה הלא נכונה

זהו הקטע שאמור לשמור על יושרת השיטה, כי העסקה ללא כיול היא אמיתית.

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

• מודלים צפופים שאינם MoE. פריור התפקיד — מומחה משותף, gate/up/down — אינו קיים, ולכן המדיניות מאבדת את המבנה שהופך אותה לאמינה. מה שנשאר לך הוא "כל מה שמקוונטט במעלה הזרם נשאר מקוונטט", וזו טענה חלשה יותר.

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

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

• יעדים מתחת ל-3 ביט. המדיניות לא מצילה אותך. ברמת 2 ביט, המודל מצוי ב-perplexity של +56.9% ללא קשר לאן הלכו הביטים הנוספים; בניית ה-2bit-lite קיימת לשם התאמה, לא איכות.

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

השורה התחתונה

קוונטיזציה מודעת לרגישות היא הפרקטיקה; OrcaSAQ הוא אחד מהמתכונים הדטרמיניסטיים וללא כיול עבורה. הלקחים העמידים הם ההעלאות של shared-expert ו-down-projection, המכני _scale_inv כלל הבחירה, והקונפיגורציה הפר-מודולרית שהטוען באמת קורא. עבור MoE עם 320 מיליארד פרמטרים כמו GLM-5.3-Flash, מתכון זה מייצר build של MLX עם 4 סיביות ב-+2.96% perplexity — וה-orcarouter/GLM-5.3-Flash-MLX repo מציע את אותה מדיניות ב-2, 3, 4 ו-6 סיביות, עם build נפרד של 2bit-lite למכונות של 128 GB. שלנו GLM-5.3-Flash-MLX walkthrough מכסה איזה build להריץ על איזו מכונה, שלב אחר שלב.

אם העדיפות שלך היא להפיק את מקסימום האיכות בגודל קבוע ואתה יכול להרכיב קורפוס כיול, השתמש בכלים מבוססי הכיול ותן להם להסתגל. אם העדיפות שלך היא קוונטיזציה ניתנת לשחזור, מהירה, ללא נתונים, שעוברת לארכיטקטורה הבאה — או שאתה פשוט לא רוצה לבנות צינור נתונים כלל — מדיניות מבוססת-תפקידים היא ברירת מחדל שניתן להגן עליה. ואם אתה מעדיף לא לכמת מלכתחילה, גרסת הדיוק המלא של GLM-5.3-Flash מוגשת דרך OrcaRouter בשם z-ai/glm-5.3-flash. הבחירה היא לגבי היקף צינור הנתונים שאתה מוכן להריץ, לא לגבי האם קוונטיזציה שמודעת לרגישות כדאי לבצע.

מעדיף לא לבצע קוונטיזציה בכלל? z-ai/glm-5.3-flash הוא המודל בדיוק מלא שמוגש ב-OrcaRouter במחיר ספק, 0% תוספת.