למה Inference לא אוהב הפתעות - גם טובות

בעולמות הפיתוח, שיפור הוא כמעט תמיד חדשות טובות. יותר מהר, פחות זמן, יותר throughput.

אבל ב-Inference, דווקא שיפור פתאומי - גם אם הוא “חיובי” - יכול להפוך לסיכון.

כי Inference לא מחפש שיאים. הוא מחפש יציבות.

למה שיפור יכול להיות בעיה?

Inference הוא מערכת חיה:

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

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

שום דבר לא “שגוי”. אבל הכול משתנה.

שינויים שמאיצים חלקית

זה התרחיש הקלאסי:

• המודל רץ מהר יותר
• שלב preprocessing נשאר אותו דבר
• הרשת לא השתנתה
• מנגנון התזמון לא עודכן

התוצאה: החישוב מתקצר - אבל ההמתנה מתארכת במקום אחר.

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

לא בגלל עומס חדש - בגלל שינוי קצב פנימי.

למה “נהיה יותר מהירים” יכול להזיק?

כי Latency איננו סכום של זמנים בלבד. הוא תוצאה של אינטראקציה.

שיפור נקודתי יכול:

• לשבור הנחות תזמון
• להגדיל jitter
• ליצור head-of-line effects חדשים
• להגביר תנודתיות

ולפתע:

• P99 גרוע יותר
• התנהגות פחות צפויה
• ויותר מקרי קצה

המערכת אולי “מהירה יותר בממוצע”, אבל פחות נשלטת.

המשל: כביש עם מקטע מהיר במיוחד

דמיינו כביש שבו:

• רוב הדרך במהירות קבועה
• אבל מקטע אחד שודרג למהירות כפולה

התוצאה איננה זרימה טובה יותר - אלא עומס בכניסה וביציאה מהמקטע.

לא בגלל איטיות - בגלל חוסר אחידות.

Inference מגיב בדיוק כך.

יציבות כערך עליון

ב-Inference, הצלחה איננה “כמה מהר אפשר לרוץ”, אלא “כמה צפוי המערכת מתנהגת לאורך זמן”.

לכן:

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

מערכת שמופתעת מעצמה היא מערכת מסוכנת.

מחשבה אדריכלית

כל שינוי ב-Inference - גם שיפור - הוא ניסוי.

מערכת יציבה שואלת:

• מה עוד מושפע מהשינוי הזה?
• אילו הנחות נשברו?
• ואיפה יופיע האפקט השניוני?

לא כל האצה היא התקדמות. לעיתים היא רק שינוי קצב שהמערכת לא ביקשה.

סיכום

Inference לא אוהב הפתעות. לא כי הוא שמרן - אלא כי הוא רגיש.

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

במערכות Inference, הצלחה אמיתית נמדדת לא במהירות השיא - אלא בשקט שבו הכול ממשיך לעבוד.