כותרת: הבאג היה ציר אחד
באג נסתר במימוש ה-chunked-scan של PyTorch מאפשר למודלים היברידיים מסוימים להציץ בטוקנים עתידיים בכל פעם שחסרים fast fused kernels, מה שמערער את האמינות של צ'קפוינטים (checkpoints) כמו Zamba2-1.2B ו-Nemotron-H-8B. התקלה נובעת מפעולת reduction בודדת המבוצעת לאורך הציר הלא נכון, והיא מופיעה בנתיב ההרצה שבו מסתמכים רוב צינורות ה-CI והרצות ה-CPU.
למה הבאג הזה חשוב
מודלים היברידיים ומודלים של state-space כבר אינם תלויים אך ורק ב-attention; הם משתמשים גם ברקורסיות ליניאריות, scans וקונבולוציות. פעולת מיסוך (masking) שחוסמת טוקנים עתידיים במטריצת ה-attention אינה מבטיחה באופן אוטומטי סיבתיות (causality) עבור אותן פעולות נוספות. כאשר חסרים ה-fast fused kernels שבדרך כלל היו מטפלים ב-scan בצורה נכונה, PyTorch חוזר (falls back) לנתיב chunked-scan ב-pure-Python. נתיב הגיבוי הזה מכיל את ה-axis-mixup, המאפשר למידע ממיקומים מאוחרים יותר לזרום לאחור במהלך ה-inference.
הדליפה היא שקטה. היא לא גורמת לקריסת המודל ולא מעלה שגיאה ברורה. במקום זאת, היא גורמת לערכי ה-loss וה-perplexity להיראות נמוכים באופן מלאכותי, מכיוון שהמודל למעשה "מרמה" – הוא רואה בדיוק את הטוקנים שהוא אמור לחזות. לכן, כל הערכה (evaluation) downstream שסומכת על המדדים הללו נבנית על בסיס שבור.
כיצד נחשפה הבעיה
חוקרים השוו שני מעברי forward דרך אותו מודל:
- רצף טוקנים אקראי.
- הרצף הזהה עם טוקן אחד שונה.
הם מדדו את ההבדל ב-hidden states שכבה אחר שכבה. בדיקת ה-mask לא העלתה דבר, אך ביקורת (audit) שכבתית שכללה הזרקת שגיאות (fault injection) זיהתה 192 מתוך 192 שגיאות שהוזרקו, מה שאישר את קיומה של הדליפה.
סקר מהיר של ספריית transformers חשף:
- Zamba2-1.2B דולף כאשר ה-chunk size מוגדר ל-256.
- Nemotron-H-8B דולף ב-chunk size של 128.
- רוב הצ'קפוינטים האחרים לא הראו דליפה בתנאים דומים.
הפגם נמצא בנתיב קוד ה-chunked-scan שרץ בכל פעם שחסרים fused kernels אופציונליים. זה כולל:
- כל הרצת CPU.
- סביבות GPU ללא חבילות ה-fused-kernel הספציפיות.
- התקנות PyTorch סטנדרטיות שאינן כוללות תלויות (dependencies) נוספות.
מכיוון שהבאג מופיע רק כאשר ה-kernels הללו חסרים, הוא יכול להופיע בסביבות CI ובמחשבי CPU.
מי נמצא בסיכון ומה המחיר
כל צוות שמאמן, מבצע fine-tuning או מעריך מודלים היברידיים ללא ה-fused kernels נמצא בסיכון לפרסום נתוני ביצועים מנופחים. השיפור לכאורה ב-loss או ב-perplexity הוא אשלייתי; המודל למעשה "הציץ קדימה". עבור קבוצות מחקר, הדבר עלול להוביל לטענות מטעות לגבי תוצאות state-of-the-art. עבור פריסות מסחריות, זה עלול לגרום לשגיאות downstream במשימות גנרציה (generation) שלמעשה מעולם לא נלמדו כראוי.
הטיעון הנגדי
מפתחים מסוימים טוענים ששימוש נכון ב-causal mask מספיק כדי למנוע דליפת טוקנים עתידיים. הבאג מפריך את התפיסה הזו: scans, קונבולוציות ושכבות נורמליזציה מסוימות יכולות לעקוף את ה-mask לחלוטין. ה-axis-mixup ב-chunked scan מראה שיש לאכוף סיבתיות (causality) בכל מקום שבו המידע זורם, ולא רק במטריצת ה-attention.
מה כדאי לעקוב אחריו בהמשך
- היגיינת תלויות (Dependency hygiene): התקינו את חבילות ה-fast fused-kernel בכל צמתי האימון וה-inference, במיוחד בצינורות CI.
- סקריפטים לביקורת (Audit scripts): פעלו לפי הביקורת הדו-שלבית המומלצת על ידי המגלהים:
- הזרקו שגיאה ידועה לצ'קפוינט שאתם בודקים כבקרת חיובית (positive control).
- הריצו רצפים ארוכים יותר מה-chunk size או מה-window size של המודל; רצפים קצרים לעולם לא יחשפו את הדליפה.
הרצת הביקורת על כל צ'קפוינט היברידי או state-space עם אורך רצף העולה על ה-chunk size תחשוף האם המודל עדיין פגיע.
שורה תחתונה: אפילו מודל שעובר כל בדיקה סטנדרטית יכול לרמות בשקט כאשר נתיב ההרצה חוזר למימוש עם באג. אימות נוכחותם של fast fused kernels — ובדיקה מפורשת של דליפות מעבר ל-attention masks — הם כעת צעדים חיוניים לפני שניתן לסמוך על המדדים של מודל היברידי כלשהו.