AI Workload Scheduling — ניהול משימות לפי Priority, Cost ו-GPU

מאת צוות מדיה דיל · 09.08.2026 · Technology · 10 דק׳

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

מערכת שמריצה בו-זמנית שלוש קטגוריות עבודה שונות לגמרי: בקשת משתמש שממתין לתשובה עכשיו, אצווה לילית של עיבוד דוחות שאין לה לחץ זמן, ומשימת אימון מודל שדורשת GPU ייעודי לשעות ארוכות. אם כולן מתחרות על אותו pool משאבים בלי סדר עדיפויות ברור, הבקשה הדחופה של המשתמש עלולה להמתין מאחורי אצווה שיכולה לחכות בנחת עד הבוקר. AI Workload Scheduling הוא השכבה שמחליטה מה רץ, מתי, ועל איזה משאב - וההחלטות האלה, בניגוד לתזמון עבודה קלאסי, צריכות לקחת בחשבון שלושה משתנים שלא תמיד קיימים יחד בעולם אחר: דחיפות אמיתית, עלות שמשתנה משמעותית בין סוגי משימות, וזמינות חומרה ייעודית (GPU) שהיא לרוב המשאב הכי מוגבל והכי יקר במערכת.

שלושת הצירים של תזמון עומסי AI

תזמון טוב מתחיל בסיווג ברור של כל משימה על פני שלושה צירים. Priority - כמה דחוף לענות (משתמש שממתין בזמן אמת מול עיבוד רקע שיכול לחכות). Cost - כמה עולה להריץ את המשימה הזו (מודל גדול מול קטן, מספר טוקנים, מספר קריאות כלים). Resource Affinity - איזה חומרה נדרשת בפועל (GPU ספציפי לאימון, או שדי בהסקה על CPU רגיל). משימה בודדת יכולה להיות דחופה אבל זולה (סיווג פשוט בזמן אמת), או לא-דחופה אבל יקרה מאוד (אצווה גדולה של יצירת תוכן). תזמון שמסתכל על ציר אחד בלבד תמיד ייכשל במקרה כלשהו.

Priority Levels: יותר משני מצבים

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

priority_tiers:
  realtime:      # user is actively waiting
    capacity_share: 50%
    max_wait_ms: 2000
  standard:      # async, user expects result within minutes
    capacity_share: 30%
    max_wait_ms: 120000
  batch:         # background, no real deadline
    capacity_share: 15%
    max_wait_ms: unbounded
  best_effort:   # opportunistic, runs only on spare capacity
    capacity_share: 5%
    preemptible: true

שימו לב לרמה האחרונה - Preemptible - משימות שיכולות "להיעצר" ולפנות מקום למשימה דחופה יותר, ולהמשיך מאוחר יותר. זה שימושי במיוחד למשימות batch ארוכות שלא קריטי מתי בדיוק הן מסתיימות, בתנאי שיש להן מנגנון checkpoint שמאפשר להמשיך במקום שבו הופסקו - ראו Agent Checkpoints.

תזמון לפי עלות: לא כל משימה צריכה את המודל היקר

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

חשוב גם להגדיר תקציב לפי צריכה (Budget Enforcement) - לא רק לתעדף לפי עלות, אלא לאכוף תקרות בפועל. משימה או משתמש שחורגים מתקציב מוגדר לתקופת זמן צריכים להיחסם או לרדת לרמת שירות נמוכה יותר, לא להמשיך לצרוך משאבים בלי הגבלה. הרחבה ב-AI Cost Engineering.

תזמון סביב GPU: המשאב הכי מוגבל במערכת

עבור עומסים שדורשים GPU ייעודי - הרצת מודלים מקומיים, fine-tuning, או אינפרנס בנפח גבוה שלא כדאי לשלוח ל-API חיצוני - GPU הוא לרוב המשאב הכי יקר והכי מוגבל בכמות. תזמון GPU דורש מודעות למספר גורמים ייחודיים: זיכרון GPU (VRAM) שמגביל כמה משימות יכולות לרוץ במקביל על אותה כרטיס, זמן חימום (Warm-up) של טעינת מודל לזיכרון שיכול לקחת עשרות שניות ולכן משתלם לשמור מודל "טעון" בין בקשות במקום לטעון ולפרוק שוב ושוב, ו-Batching - קיבוץ כמה בקשות יחד להרצה משותפת על אותו GPU במקום הרצה בודדת אחר בודדת, שמעלה משמעותית את התפוקה הכוללת במחיר עיכוב קל לכל בקשה בודדת (Latency-Throughput Tradeoff).

Fairness: כשכמה לקוחות/צוותים חולקים אותם משאבים

במערכת רב-דיירים (Multi-Tenant), תזמון נאיבי לפי FIFO עלול לאפשר לדייר בודד עם עומס גבוה "להשתלט" על כל הקיבולת ולהרעיב את כל השאר. פתרונות נפוצים: Fair Share Scheduling - הקצאת מכסת קיבולת יחסית לכל דייר, ו-Weighted Priority - שילוב בין עדיפות המשימה לזהות הדייר, כדי שאף לקוח בודד (גם אם משלם יותר) לא יוכל לחסום לחלוטין את כל השאר בזמן עומס שיא. זה נושא קריטי במיוחד עבור פלטפורמות SaaS שמריצות AI כשירות עבור כמה לקוחות במקביל.

מדדים לתזמון: מה בכלל מודדים כדי לדעת אם זה עובד

• Queue Wait Time לפי Priority Tier - האם משימות דחופות באמת מקבלות מענה מהיר, לא רק תיאורטית.
• Utilization - אחוז הזמן שמשאבי GPU/compute בפועל בשימוש, לא יושבים בטלה.
• Cost per Task Category - מעקב אחר עלות בפועל מול צפי, לפי סוג משימה.
• Starvation Rate - כמה משימות ברמת עדיפות נמוכה ממתינות מעבר לסף סביר, סימן ל-imbalance בהקצאת קיבולת.

מדדים אלה משתלבים עם שכבת ה-observability הכללית של המערכת - מפורט ב-AI Infrastructure Monitoring.

דוגמה מהשטח: פלטפורמת ניתוח מסמכים ארגונית

שירות B2B שמריץ ניתוח מסמכים לכמה לקוחות ארגוניים. משתמש שמעלה מסמך ומחכה לתוצאה מקבל עדיפות realtime. עיבוד אצווה לילי של אלפי מסמכים שמצטברים במהלך היום רץ ב-batch, ומתוזמן להתחיל בשעות שפל כשעלות ה-compute נמוכה יותר. אימון מודל מותאם-ללקוח (fine-tuning) שדורש GPU ייעודי מתוזמן כ-best_effort, ורץ רק כשיש קיבולת פנויה שלא נדרשת למשימות הדחופות - כך שהוא לא מתחרה כלל עם עומס הלקוחות בזמן אמת.

אכיפת קיבולת בפועל: Admission Control

לפני שמשימה בכלל נכנסת למערכת התזמון, יש ערך רב בשכבת Admission Control שבודקת מראש אם יש בכלל סיכוי סביר לעמוד ביעד הזמן שלה, לפני שהיא תופסת מקום בתור ומבזבזת משאבי תזמון על משהו שממילא ייכשל. אם המערכת כבר עמוסה מעבר ליכולתה לעמוד ב-SLA של רמת עדיפות מסוימת, עדיף לדחות בקשה חדשה מיידית עם הודעה ברורה, מאשר לקבל אותה, להכניס אותה לתור, ולאכזב את המשתמש רק אחרי המתנה ארוכה. admission control כזה דורש הערכה מהירה של קיבולת פנויה בפועל - לא מדויקת לחלוטין, אבל טובה מספיק כדי למנוע קבלת עומס שהמערכת כבר יודעת שהיא לא תוכל לעמוד בו.

Deadline-Aware Scheduling: תזמון לפי מועד יעד, לא רק סדר הגעה

גישה מתקדמת יותר מתעדוף סטטי היא תזמון שמתחשב במועד יעד (Deadline) שכל משימה נושאת - לא "דחוף/לא דחוף" קבוע, אלא זמן קונקרטי שעד אליו התוצאה נדרשת. משימה עם deadline רחוק יכולה להמתין בשקט גם אם היא "נכנסה" מוקדם יותר לתור, בעוד משימה עם deadline קרוב מקבלת עדיפות אוטומטית ככל שהזמן שנותר לה מתקצר. זו גישה גמישה יותר מתעדוף בינארי, אבל דורשת שה-scheduler יחשב מחדש סדרי עדיפויות באופן דינמי, לא רק פעם אחת בכניסה לתור - מה שמוסיף מורכבות חישובית שמשתלמת בעיקר במערכות עם עומס גבוה ומגוון רחב של דרישות זמן.

SLA לפי דייר: תזמון כחלק מהסכם השירות

עבור פלטפורמות שמוכרות רמות שירות שונות ללקוחות שונים (חבילת Basic מול Enterprise), תזמון העומסים הוא לא רק שיקול טכני אלא ביטוי ישיר של הבטחת שירות עסקית. לקוח Enterprise שמצפה לתגובה תוך שניות בודדות צריך לקבל עדיפות שמעוגנת ב-scheduler עצמו, לא רק בכוונה טובה בקוד. זה אומר שההגדרה של priority tiers צריכה להיות מקושרת ישירות למודל התמחור והSLA החוזי, ושחריגה מ-SLA צריכה להיות ניתנת למדידה ולדיווח - לא רק הרגשה סובייקטיבית ש"המערכת עמוסה". תכנון כזה ממיר את שכבת התזמון מרכיב תשתיתי פנימי בלבד לרכיב שיש לו השפעה עסקית ישירה ומדידה.

שילוב בין תזמון לניתוב מודל: החלטה דו-ממדית

בפועל, "היכן להריץ" ו"איזה מודל להשתמש" הן שתי החלטות שמשתלבות זו בזו. משימה שמתוזמנת ל-realtime tier לא בהכרח צריכה גם את המודל היקר ביותר - לפעמים ההפך: כדי לעמוד ב-SLA זמן קפדני, עדיף מודל מהיר וזול יותר גם אם קצת פחות מדויק, במקום מודל איטי שחורג מהחלון הזמין. scheduler בשל מקבל את שתי ההחלטות יחד, ולא מטפל בהן כשתי מערכות נפרדות שלא מדברות זו עם זו - כי הבחירה במודל משפיעה ישירות על זמן העיבוד הצפוי, שהוא בדיוק הקלט שה-scheduler צריך כדי לתעדף נכון. שילוב כזה גם מאפשר תגובה דינמית לעומס שיא: כשקיבולת ה-GPU או ה-realtime tier מתמלאת, המערכת יכולה להחליט להוריד זמנית לרמת מודל קלה יותר עבור משימות בעדיפות בינונית, במקום לתת להן להמתין זמן ארוך מדי מאחורי עומס שלא צפוי.

טעויות נפוצות

• עדיפות בינארית בלבד - לא מספיקה כשיש טווח רחב של סוגי דחיפות, ומובילה או לרעב או להקצאה לא יעילה.
• תזמון לפי זמן הגעה בלבד (FIFO טהור) - מתעלם לגמרי מעלות ומדחיפות אמיתית.
• אין תקרת תקציב - משימה או דייר בודד יכולים לצרוך משאבים בלי הגבלה עד שמישהו שם לב לחשבון.
• התעלמות מ-warm-up time של GPU - טעינה וכיבוי חוזרים של מודלים גדולים מבזבזים זמן ומשאבים שהיו יכולים לשרת בקשות.

שאלות נפוצות

איך קובעים כמה רמות עדיפות צריך במערכת?

מתחילים בשתיים-שלוש (realtime, standard, batch) ומוסיפים רמות נוספות רק כשמזהים דפוס עבודה שלא מתאים לאף אחת מהקיימות. יותר מדי רמות מסבך את הניהול בלי תועלת ברורה.

מה עדיף - Preemption או פשוט לחכות שהמשימה תסתיים?

Preemption עדיף כשהמשימה הנמוכה-עדיפות ארוכה ותומכת ב-checkpoint. עבור משימות קצרות, לרוב פשוט יותר ובעל overhead נמוך יותר לתת להן להסתיים ולתעדף רק את הבאה בתור.

איך מונעים מלקוח בודד "לגנוב" את כל קיבולת ה-GPU?

הקצאת מכסה יחסית (Fair Share) לכל דייר, עם אכיפה בפועל ברמת ה-scheduler, לא רק המלצה - כולל חסימה או ירידה לתור batch כשמכסה מוצתה.

האם צריך scheduler ייעודי, או שאפשר להסתפק בתור עדיפות פשוט?

לעומסים פשוטים עם רמת עדיפות אחת-שתיים, תור priority פשוט מספיק. ברגע שיש שילוב של עדיפות, עלות, ומשאב ייעודי (GPU) יחד, נדרש scheduler ייעודי שמסוגל לשקלל את שלושתם בהחלטה אחת.

סיכום

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

תגיות: Workload Scheduling · AI Infrastructure · GPU Scheduling · Priority Queue · Cost Optimization · Fair Share · Batching

← חזרה לבלוג · צור קשר