ניטור השהיה בהסקת AI: הגדרת מדדים והתראות

ניטור השהיה של AI: היכן מתבזבז זמן התגובה של המודל

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

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

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

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

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

מה נותנת נראות מקצה לקצה של האינפרנס בפועל

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

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

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

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

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

דרכים לאיסוף מטריקות זמן תגובה: השוואת גישות

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

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

שלבי הטמעת ניטור: מביקורת ועד מסירה

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

1. ביקורת של המדידות הנוכחיות — מה נמדד עכשיו, באיזו דיוק, היכן הממוצע מסתיר את זנב ההתפלגות, והיכן המדידה נמצאת לא בקטע הנכון של נתיב הבקשה.
2. סכמת איסוף טלמטריה — נקודות מדידה בכניסה לשירות ובשרת האינפרנס, הרכב המטריקות: משך מלא, זמן עד הטוקן הראשון, אורך התור, שיעור הכשלים. פילוח לפי מודל, גרסה וסוג בקשה.
3. מדדי יעד — לכל מסלול קובעים נורמה לפי אחוזונים, ולא לפי ממוצע: בקשות זרימה ובקשות אצווה משווים בנפרד.
4. הגדרת ספי התראות — שתי רמות, אזהרה ואות קריטי, עם חלון תצפית ודרישה לכמה הפעלות רצופות. זה מסיר קריאות שווא לתורן על זינוקים בודדים.
5. בדיקה בעומס אמיתי — הרצת פרופיל קרוב לזה העובד: גידול מדורג, זינוקים, הידרדרות מודל. מוודאים שהאות מגיע לפני שהבעיה נעשית גלויה למשתמש.
6. הדרכת תורנים — סדר פעולות לכל אות: איך למקם את צוואר הבקבוק, מתי להחזיר גרסת מודל, ואיך להעביר תעבורה למסלול גיבוי.
7. מסירת נהלים — פאנלי ניטור, כללים וספים כקונפיגורציה, הוראות לתורנים, מטריצת אחריות. מכאן והלאה הצוות מנהל את הניטור בעצמו.

מה מוסרים לידיים: קונפיגורציות, סכמות ונהלים

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

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

מקרה בוחן: איך הסרנו זינוקים בזמן התגובה של המודל

לפני ההתערבות שירות החיזויים עבד דרך מסלול אחד, והניטור של השהיה הצטמצם לזמן תגובה ממוצע. בשעות שקטות הוא נראה תקין, אבל בשעות שיא זנב ההתפלגות נסק למעלה: האחוזון ה-95 גדל פי 6-8, ושיעור הבקשות שנקטעו בגלל timeout הגיע ל-4%.

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

מה מצאנו במטריקות ומה שינינו

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

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

אחרי: האחוזון ה-99 הצטמצם פי שלושה, הפער בין הממוצע לזנב — מפי שמונה לפי שניים, ושיעור ה-timeouts ירד מ-4% לעשיריות האחוז. סוג הכשל «המודל לא ענה בזמן» הפסיק להופיע בניתוחים.

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

במה שונה מדידה בצד השירות ממדידה בצד הלקוח?

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

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

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

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

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

ספקות נפוצים: רעש התראות והפעלות שווא

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

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

איסוף מטריקות יאט את האינפרנס עצמו?

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

כמה זמן לשמור היסטוריית תצפיות?

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

מי אחראי לספים ולתורנות?

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

נדון במשימה: נפרק את הקונטור שלכם ונחזור עם תוכנית

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

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

לסיכום הדיון נשלח:

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

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