למה Inference טוב לא מנסה להיות גנרי

כשמתחילים לבנות מערכת Inference, יש שאיפה טבעית לבנות משהו “אחד שמתאים לכולם”:

כל מודל, כל סוג קלט, כל עומס, וכל לקוח.

על הנייר - זה נשמע יעיל. בפועל - זו אחת הבחירות הכי מסוכנות שאפשר לעשות.

למה בכלל גנריות מפתה?

כי היא מבטיחה:

• פחות מערכות
• פחות קוד
• ופחות החלטות מוקדמות

אם הכול גנרי, נדמה שאפשר “להחליט אחר כך”. אבל ב-Inference, דחיית החלטות היא כמעט תמיד בעיה.

Inference לא באמת אחיד

Inference אף פעם לא נראה אותו דבר:

• מודל אחד רגיש מאוד ל-latency
• אחר מרוויח מ-batching
• יש מודלים עם קצב קבוע
• ויש כאלה שמגיעים בגלים (bursts)

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

לא כי משהו “לא עובד”, אלא כי ההנחות לא מחזיקות.

איפה זה פוגש את הקוד?

כאן נמצא שורש ההבדל.

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

כלומר, הקוד עצמו מלא בצמתים של החלטה. הוא כל הזמן “חושב”.

לעומת זאת, ב-Inference מותאם (specialized), רבות מההחלטות האלו נלקחות מראש, בזמן התכנון.

הקוד נכתב מתוך ידיעה: זה המודל. זה הקצב. זו העדיפות.

ולכן הזרימה פשוטה יותר, קבועה יותר, צפויה יותר.

ההבדל אינו בכמה הקוד “חכם” - אלא בכמה מעט הוא צריך להחליט בזמן אמת.

למה גנריות פוגעת ביציבות?

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

עוד abstraction, עוד תנאי, עוד “אם זה - אז ככה”.

כל שכבה כזו:

• מקשה על חיזוי
• מוסיפה מצבי קצה
• ומגדילה אי-ודאות

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

וב-Inference, חוסר יציבות הוא מחיר גבוה מאוד.

סיכום

Inference טוב לא מנסה להיות גנרי. הוא מנסה להיות מתאים.

כי Inference הוא תמיד מפגש בין:

• מודל
• מערכת
• ותבנית שימוש

והמפגש הזה תמיד תלוי הקשר.

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