Batching: האופטימיזציה שהורסת Latency אם לא מבינים אותה

במערכות חישוב מודרניות, במיוחד בעולמות של Inference, Batching נחשב לאחת האופטימיזציות הבסיסיות והמתבקשות ביותר. הוא מופיע כמעט בכל מדריך ביצועים, בכל Benchmark, ובכל שקף על Throughput. אבל במערכות אינטראקטיביות - אותו Batching בדיוק עלול להפוך מאופטימיזציה חכמה לגורם המרכזי ל-Latency גבוה ולא צפוי.

הבעיה אינה ב-Batching עצמו. הבעיה היא בהנחה ש-Throughput ו-Latency משתפרים יחד.

למה Batching עובד מצוין בבנצ’מרקים

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

בתנאי מדידה, התנאים כמעט מושלמים:

• זרם קבוע של בקשות
• אין משתמש שממתין לתשובה
• המדד המרכזי הוא בקשות לשנייה

במצב כזה, Batching:

• מצמצם overhead
• ממלא את המאיץ בעבודה רציפה
• מעלה Throughput בצורה דרמטית

על הנייר - הכול נראה מושלם.

למה זה נשבר במערכות אינטראקטיביות

במערכת אינטראקטיבית, בקשה לא “קיימת” רק כדי להתווסף לסטטיסטיקה. יש מאחוריה משתמש שממתין.

כאן נכנס המחיר הסמוי של Batching: כדי למלא batch - צריך להמתין.

הבקשה הראשונה שמגיעה ל-batch:

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

ככל שה-batch גדול יותר, כך זמן ההמתנה גדל. ה-Latency של הבקשה נקבע לא לפי זמן החישוב, אלא לפי זמן האגירה.

Throughput עולה - אבל Latency מתנפח.

הזנב נוצר גם כשיש כוח חישוב פנוי

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

המאיץ פנוי. ה-CPU משועמם. ועדיין - בקשות ממתינות.

למה?

כי המדיניות אומרת: “לא מעבדים עד שה-batch מלא”.

זו לא בעיית ביצועים - זו בעיית מדיניות.

המשל

דמיינו אוטובוס עירוני.

אם מחכים שכל המושבים יתמלאו לפני היציאה:

• יעילות הנסיעה גבוהה
• מספר הנוסעים לשעה מרשים

אבל הנוסע הראשון:

• לא מתעכב בגלל פקק
• לא בגלל תקלה
• אלא בגלל שיטת ההפעלה

Batching עובד בדיוק כך.

Batch size הוא לא קבוע - הוא החלטה מערכתית

הטעות הנפוצה היא לבחור batch size “אופטימלי” ולהטמיע אותו כקבוע.

במערכת חיה:

• העומס משתנה
• סוגי הבקשות משתנים
• רגישות ה-Latency משתנה

Batch size צריך להיות:

• דינמי
• תלוי עומס
• ולעיתים - תלוי זמן, לא כמות

זו מדיניות, לא מספר.

השורה התחתונה

Batching הוא כלי חזק - אבל חד-צדדי. הוא מגדיל Throughput על חשבון Latency, לא במקביל אליו.

במערכות אינטראקטיביות, השאלה איננה: “מה ה-batch הכי גדול שאפשר להריץ?”

אלא: “מתי מותר לי לחכות - ומתי אסור.”

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