SageMaker AI: תוצאות Benchmark זורמות ל-MLflow

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

AWS מכריזה היום על שתי עדכונים משמעותיים ל-Amazon SageMaker AI שמטרתם לפתור בדיוק את הכאב הזה: אינטגרציה מקורית עם MLflow לזרימת תוצאות benchmark ו-recommendation בזמן אמת, ותמיכה חדשה בניטור מודלים דיסקרימינטיביים (סיווג ורגרסיה) עם ספריית Evidently.

מה בעצם קרה כאן?

שתי ההכרזות נוגעות לאותו עניין מרכזי: הפיכת SageMaker AI לפלטפורמה שמנהלת את כל מחזור החיים של הניסויים והפריסה — מה-benchmark הראשון ועד לניטור שוטף בייצור.

זרימת תוצאות בזמן אמת ל-MLflow

האינטגרציה הראשונה מאפשרת לצוותים לשלוח תוצאות של שני סוגי ג'ובים ב-SageMaker AI ישירות ל-MLflow:

• AI Benchmark Job — מעריך endpoint קיים עם עומס עבודה מוגדר
• AI Recommendation Job — מעריך קונפיגורציות פריסה שונות ומחזיר דירוג של אפשרויות מיטביות

כשאתם מגישים את הג'וב, אתם פשוט מוסיפים שדה MlflowConfig ל-OutputConfig עם ה-ARN של אפליקציית MLflow שלכם, שם הניסוי, ושם ה-run. SageMaker מתחילה לזרום מטריקות, פרמטרים וגרפים ישירות ל-MLflow בזמן אמת — בלי שתצטרכו לחכות שהג'וב יסתיים.

למה זה משנה בפועל?

• ביטול איחוד ידני של נתונים: כל ה-runs מאותה סדרת ניסויים נכנסים אוטומטית לאותו ניסוי ב-MLflow. אתם יכולים להשוות בלחיצה אחת איך סוג ה-instance, גודל ה-batch, או שימוש ב-speculative decoding משפיעים על ביצועים.
• ניטור בזמן אמת: ג'ובי benchmark יכולים לקחת שעות. במקום לחכות בחושך, אתם רואים מטריקות מתעדכנות live — latency, throughput, ועוד — ויכולים לעצור מוקדם אם משהו לא נראה תקין.
• מסלול ביקורת מלא: כל run תופס את ההקשר המלא — פרמטרים, חותמות זמן, מטריקות ב-checkpoints, ו-artifacts. הכול נשמר לשחזור עתידי.
• שיתוף פעולה טוב יותר: ניסוי MLflow משותף הופך למקור האמת היחיד. חברי צוות יכולים לראות מה נוסה, מה עבד, ומה לא — בלי להריץ דברים פעמיים.

דוגמה טכנית קצרה: נניח שאתם מפרקים Qwen2-0.5B-Instruct על ml.g6.12xlarge ורוצים לדעת אם לעבור ל-ml.p4d.24xlarge. אתם מגישים benchmark job ו-recommendation job לאותו ניסוי MLflow, ובתום ההרצה רואים השוואה צד-צד של throughput, latency, ומשך ה-benchmark — בלי לייצא CSVים או לכתוב סקריפטים מאחדים.

מגבלות שכדאי לדעת

• האינטגרציה עובדת רק עם SageMaker MLflow Apps — לא עם שרת MLflow self-hosted שלכם.
• אתם צריכים tooling.version 0.8.0 ומעלה כדי לקבל תמיכה ב-nested runs.
• ה-execution role חייב הרשאות ספציפיות ל-MLflow, S3, ו-invocation של endpoints.
• דלי ה-S3 חייב להיות באותו אזור כמו הג'וב.

ניטור מודלים דיסקרימינטיביים: Evidently + SageMaker AI + MLflow

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

AWS מציעה פתרון שמשלב את ספריית הקוד הפתוח Evidently עם SageMaker AI ו-MLflow לחישוב שני סוגי סטיות:

Data Drift

שינויים במאפיינים הסטטיסטיים של הקלט. יכול להיות פשוט כמו שינוי בפורמט של עמודה מ-int ל-float, או מורכב כמו קווי מוצרים חדשים שהמודל לא ראה באימון. מחשבים סטטיסטיקות baseline על סט האימון ומשווים אותן לנתונים בייצור.

Model Drift

שינויים בדיוק התחזיות כי הדפוסים שהמודל למד כבר לא מתאימים לנתונים החדשים. אפשר למדוד על ידי איסוף ground truth labels וחישוב מטריקות איכות מול מטריקות האימון.

איך זה עובד בפועל?

הפתרון מציע שתי ארכיטקטורות בהתאם לסוג הפריסה:

Batch Inference

1. אימון: מריצים job אימון על נתוני S3, שומרים מטריקות ב-MLflow, ומאחסנים את סט הבסיס בנפרד לניטור עתידי.
2. Inference: מריצים batch transform על עומסי עבודה בייצור, שומרים תוצאות ב-S3.
3. ניטור: processing job מחשב data drift ו-model quality באמצעות Evidently presets (כמו DataDriftPreset ו-ClassificationPreset).
4. תזמון: אפשר לכרוך את ה-batch transform וה-processing job ב-pipeline עם Amazon EventBridge Scheduler.
5. התראות: אם מזוהה drift, אפשר לשלוח התראות דרך Amazon SNS.

Real-time Endpoints

ההבדל המרכזי: ה-endpoint צריך data capture מופעל, מה שמתעד inputs ו-outputs ב-S3. במקום processing job, הארכיטקטורה משתמשת ב-AWS Lambda functions שמריצות את קוד הניטור. אפשר להפעיל אותן בלוח זמנים קבוע או כשהנתונים מגיעים ל-S3.

הפתרון עובד גם עם Amazon SageMaker Hyperpod — clusters ייעודיים לאימון ו-inference — עם data capture ברמת ה-endpoint, ה-load balancer, או ה-pod.

למה Evidently?

Evidently היא ספריית Python בקוד פתוח שמספקת presets מוכנים לניטור:

• DataDriftPreset ו-DataSummaryPreset לבדיקת סטיות בנתונים
• ClassificationPreset לחישוב accuracy, precision, recall, F1 score ועוד
• תמיכה בדוחות מותאמים אישית למקרים שבהם מטריקות סטנדרטיות פחות רלוונטיות (למשל, כשיש חוסר איזון ב-labels)

הדוחות נשמרים כ-artifacts ב-MLflow, והמטריקות הבודדות נשלפות ל-MLflow metrics להשוואה קלה בין runs.

דוגמה מהשטח: הדוגמה ב-documentation משתמשת ב-Bank Marketing dataset מ-UCI — סט נתונים פורטוגלי לשיווק טלפוני עם מטרת חיזוי הרשמה לפיקדון. בגלל חוסר איזון ב-labels, accuracy פחות רלוונטי מ-precision, recall ו-AUC.

איפה זה מתחבר לעולם שלכם?

אם אתם עובדים בצוות ML בארגון, אתם כנראה מכירים את הכאב:

• עשרות קונפיגורציות שצריך לבדוק לפני פריסה
• מעקב ידני אחרי מה עובד ומה לא
• מודלים בייצור שמאבדים דיוק בלי התרעה
• קושי בשחזור תוצאות כשמישהו שואל "למה בחרנו את הקונפיגורציה הזו?"

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

• מקור אמת אחד לכל הניסויים — מה-benchmark הראשון דרך הניטור השוטף
• ניטור בזמן אמת שחוסך compute costs כי אפשר לעצור מוקדם
• שחזור מלא של ההחלטות שלכם חודשים קדימה
• אינטגרציה עם כלים קיימים — MLflow הוא סטנדרט בתעשייה, ורוב הצוותים כבר מכירים אותו

מה צריך כדי להתחיל?

ל-benchmark ו-recommendation:

1. אפליקציית MLflow ב-SageMaker Studio
2. הרשאות מתאימות ל-execution role (sagemaker-mlflow:*, sagemaker:InvokeEndpoint)
3. הוספת MlflowConfig ל-OutputConfig של הג'וב

לניטור מודלים:

1. אפליקציית MLflow ב-SageMaker Studio
2. JupyterLab space ב-SageMaker Studio
3. מודל מאומן עם סט baseline מאוחסן ב-S3
4. הגדרת pipeline עם EventBridge לתזמון (אופציונלי)

שורה תחתונה

AWS הופכת את SageMaker AI לפלטפורמה יותר שלמה למחזור החיים של ML. לא צריך יותר לחבר ידנית תוצאות ממקומות שונים, לא צריך לנחש מה קרה בניסויים של שעות, ולא צריך לגלות שהמודל בייצור התחיל להזות רק כשהלקוחות מתלוננים.

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