כימות דינמי ב-SageMaker מוזיל את המודל, לא את האחריות ההנדסית
כימות דינמי ב-SageMaker הוא קודם כל מבחן למשמעת ההנדסית של הארגון, ורק אחר כך תרגיל בחיסכון בענן. נתון של כ-80% פחות בעלות לשעה נראה כמו אישור מיידי לעבור למכונה קטנה, אבל עלות נמוכה של נקודת קצה אינה מבטיחה עלות נמוכה לבקשה תקינה. תבנית צ'אט שגויה, הקשר ארוך או התרחבות איטית יכולים למחוק את החיסכון בלי לשנות אפילו משקולת אחת.
כימות דינמי חוסך זיכרון באמצעות אי שוויון מכוון
מודל בן 8 מיליארד פרמטרים בדיוק של 16 ביט דורש כ-16 ג'יגה-בייט רק עבור המשקולות. בכימות אחיד כל השכבות נדחסות לאותה רמת דיוק, אף שהרגישות שלהן לשגיאות מספריות שונה. בכימות הדינמי של Unsloth כל שכבה נבחנת בנפרד: שכבות שבהן עיגול המשקולות פוגע באופן חריף בפלט נשארות ב-16 ביט, ואחרות יורדות ל-4 ביט. החיסכון נוצר משום שפחות ביטים נשמרים ומועברים מזיכרון המאיץ בכל שלב יצירה. לפי תוצאות Unsloth, גודל המודל עשוי לרדת ב-86% לצד ירידה של 14% בדיוק. היחס הזה אינו מובטח לכל מודל או משימה, ולכן הבחירה ברמת הכימות היא החלטת איכות, לא הגדרת תשתית בלבד.
פריסת SageMaker עלולה להיכשל בגלל המעטפת ולא בגלל המשקולות
נניח שצוות שירות פורס את Qwen3-VL-8B-Instruct כדי לקרוא תמונות של מוצרים פגומים ולנסח תשובה ללקוח. הגרסה המכומתת Q4_K_XL רצה על ml.g5.xlarge בעלות של כ-1.41 דולר לשעה, לעומת כ-7.09 דולר לגרסה המלאה על ml.g5.12xlarge. בבקשה בודדת התוצאה נראית מצוינת. בעומס של 20 בקשות מקבילות מתגלות תשובות קטועות, משום שהקונטיינר משתמש בתבנית צ'אט שונה מזו ששימשה באימון. כאשר מצורפות גם תמונות והיסטוריית שיחה ארוכה, זיכרון מטמון הקשב גדל אף שהמשקולות מכומתות, וזמן ההשהיה בקצה ההתפלגות מזנק. תיקון התבנית, הגבלת אורך ההקשר ובדיקת עומס משנים את התוצאה יותר ממעבר בין שתי דרגות כימות סמוכות.
בדיקה מקצועית חייבת למדוד את תמונת הפריסה המלאה: זמן אתחול, זמן השהיה באחוזון 95, קצב טוקנים ושיעור תשובות שמתקבלות בבקרת איכות. קובץ המודל צריך להישמר ב-Amazon S3 ולהיטען משרשרת אספקה נשלטת. הורדה ממקור חיצוני בזמן עליית נקודת הקצה מוסיפה תלות תפעולית ועלולה להפוך אירוע autoscaling לכשל שירות. גם ממשקי ping ו-invocations, מדיניות IAM והתנהגות הקונטיינר תחת עומס שייכים לבנצ'מרק.
אפשר לטעון שהדיוק ההנדסי הזה מיותר בפיילוט, ושמספיק להעלות קובץ GGUF למכונת EC2 קטנה ולמדוד חיסכון. לטובת הטענה עומדת מהירות הניסוי, והיא אכן מתאימה לשלב אימות ראשוני. הקושי מתחיל כשהתוצאה משמשת לאישור תקציב ייצור. בדיקה ללא מקביליות, הקשרים מייצגים ותבנית צ'אט זהה מודדת את הקובץ, לא את השירות שהארגון עומד להפעיל.
עלות inference ב-AWS נמדדת לבקשה תקינה
המסלול הנכון מתחיל בהשוואת כמה קובצי GGUF על EC2 עם אותה תבנית צ'אט ואותו מערך בדיקה עסקי. אחר כך יש לנעול את הקובץ שנבחר ב-S3 ולפרוס אותו בקונטיינר SageMaker עם הגדרות זהות. בשלב הבא מריצים מטריצה של ארבעה עומסים לפחות, המשלבת אורכי הקשר ורמות מקביליות שונות, ומשווים עלות לכל תשובה שעברה בדיקת איכות. לבסוף דוגמים תשובות אנושית ומפנים לבדיקה מלאה רק חריגים בעלי סיכון גבוה, במקום להצמיד אדם לכל בקשה. בחירה במכונה הקטנה ביותר שהצליחה במטריצה הזו מממשת את החיסכון של Unsloth בלי להפוך מספר מרשים בדוח לבעיה תפעולית בייצור.
