Horizontal Scaling של AI Agents — אלפי Agents במקביל

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

לגדול מ-10 סוכנים במקביל ל-10,000 לא קורה רק על ידי הוספת שרתים. מדריך ל-Horizontal Scaling של AI Agents: Statelessness, Load Balancing, Rate Limits ומחיר אמיתי בקנה מידה.

מערכת AI שמטפלת ב-50 בקשות במקביל עובדת מצוין. אותה מערכת, בדיוק אותו קוד, מתחילה לקרוס כשמגיעים ל-2,000 בקשות במקביל - לא בגלל שהקוד גרוע, אלא בגלל שההנחות שהתאימו בקנה מידה קטן פשוט לא מחזיקות מים בקנה מידה גדול. Horizontal Scaling - הוספת עוד instances שרצים במקביל במקום להגדיל instance בודד (Vertical Scaling) - היא הדרך הסטנדרטית להתמודד עם עומס, אבל עבור AI Agents יש שכבת מורכבות נוספת: Rate Limits חיצוניים שלא גדלים ביחד עם התשתית שלכם, עלות שגדלה ליניארית עם כל instance נוסף, ומצב פנימי שקשה יותר לפזר מאשר בשרת web רגיל.

התנאי הראשון: הסוכן חייב להיות Stateless

הבסיס לכל scaling אופקי הוא שכל instance יהיה בר-החלפה (Interchangeable) - אין הבדל אם בקשה מסוימת טופלה על instance מספר 3 או מספר 47. זה דורש שהסוכן לא יחזיק מצב מקומי (In-Memory State) שקריטי להמשך התהליך - כל היסטוריית שיחה, תוצאות ביניים, ומצב כלים שהופעלו חייבים להישמר במאגר חיצוני משותף (Redis, בסיס נתונים), לא בזיכרון הפנימי של ה-process. זו בדיוק ההבחנה שמפורטת ב-Stateless מול Stateful AI Architecture: מערכת שמתוכננת stateful מלכתחילה תתקשה מאוד ב-scale אופקי בלי refactoring משמעותי.

Load Balancing עבור עומסי AI: לא כמו לאזן תעבורת HTTP רגילה

אלגוריתם איזון עומסים רגיל (Round Robin, Least Connections) מניח שכל בקשה עולה בערך אותו זמן ואותו מחיר. עבור AI Agents ההנחה הזו שגויה: בקשה אחת יכולה להיות סיווג פשוט שלוקח חצי שנייה, ובקשה שנייה יכולה להיות workflow מורכב שלוקח שתי דקות ומריץ עשרות קריאות כלים. איזון עומסים נאיבי לפי מספר בקשות בלבד יכול לגרום למצב שבו instance אחד "נתקע" עם כמה בקשות כבדות בזמן שאחרים חופשיים לגמרי. הפתרון הנפוץ: איזון לפי עומס בפועל (מספר בקשות פעילות, זמן עיבוד ממוצע), לא לפי ספירה גולמית, ולעיתים הפרדת תורים נפרדים למשימות קלות וכבדות - כפי שמפורט גם ב-Queues + AI Agents.

Rate Limits חיצוניים: הצוואר בקבוק שאתם לא שולטים בו

זו נקודה שקל להתעלם ממנה עד שהיא הופכת לבעיה מרכזית: אפשר להוסיף אלף instances חדשים, אבל אם כולם קוראים לאותו ספק מודל תחת אותו מפתח API, מגבלת ה-Rate Limit של הספק (בקשות לדקה, טוקנים לדקה) לא זזה. ה-scaling של השכבה שלכם לא עוזר אם הצוואר בקבוק האמיתי נמצא במקום אחר לגמרי. פתרונות: פיזור בין כמה מפתחות API או חשבונות ספק (כשמדיניות הספק מתירה זאת), תעדוף בקשות (ראו AI Workload Scheduling), ותכנון עם ה-rate limit כמשתנה קבוע במערכת, לא הפתעה שמתגלה בפרודקשן.

autoscaling_policy:
  metric: active_requests_per_instance
  target: 15
  min_instances: 3
  max_instances: 200
  scale_up_cooldown: 30s
  scale_down_cooldown: 300s   # slower scale-down avoids flapping
  external_constraint:
    provider_rate_limit_tpm: 2_000_000  # hard ceiling regardless of instances

Autoscaling: מתי להוסיף instances, ומתי לא

Autoscaling נאיבי לפי CPU לא עובד היטב עבור AI Agents, כי רוב זמן העיבוד הוא המתנה לתשובה מ-API חיצוני (I/O Wait), לא חישוב מקומי - כך שה-CPU יכול להיראות פנוי לגמרי בזמן שהמערכת כבר עמוסה מבחינת מספר בקשות מקבילות. מדד טוב יותר הוא מספר בקשות פעילות לכל instance או זמן תגובה ממוצע שמתחיל לעלות. חשוב גם להגדיר Cooldown שונה לגידול (מהיר, כדי להגיב לעומס) ולצמצום (איטי יותר, כדי למנוע "פרפור" - scale up וscale down חוזרים תוך דקות שגורמים לחוסר יציבות ולעלות מיותרת מהפעלה וכיבוי תדיר של instances).

עלות: Scaling אופקי לא זול כמו שנדמה

בניגוד לשרת web רגיל, שבו instance נוסף עולה סכום קבוע וצפוי, עבור AI Agent כל בקשה נוספת גם עולה כסף על עצם הקריאה למודל - כך שגידול בכמות ה-instances לרוב מלווה בגידול ליניארי, ולעיתים סופר-ליניארי (אם יש retries), בעלות התפעול השוטפת. זה שונה מהותית מ-scaling מסורתי, ולכן autoscaling policy חייב לכלול לא רק "כמה עומס יש" אלא גם "כמה זה עולה" - תקרת עלות (Budget Ceiling) שמונעת ממערכת שמגיבה לעומס בלתי צפוי (או לבאג שגורם ללולאה) "להתפוצץ" כלכלית לפני שמישהו שם לב. הרחבה ב-AI Cost Engineering.

Graceful Shutdown: כשמצמצמים instances באמצע עבודה

כש-instance מסומן לכיבוי בזמן scale-down, יש לוודא שהוא לא "נהרג" באמצע טיפול בבקשה שנמצאת בעיצומו של workflow ארוך. תבנית נכונה: ה-instance מפסיק לקבל בקשות חדשות (Draining), אבל ממשיך לעבד את מה שכבר בטיפולו עד שזה מסתיים או עד ל-timeout מוגדר, ורק אז נסגר. בלי מנגנון כזה, scale-down עלול לגרום לאובדן משימות שכבר היו כמעט שלמות - בזבוז כפול: גם עלות שכבר הושקעה, וגם צורך להתחיל את המשימה מחדש.

דוגמה מהשטח: מערכת מיון תוכן בזמן קמפיין

פלטפורמת מדיה חברתית מפעילה סוכן AI שמסווג תוכן שמועלה בזמן אמת. בימי שגרה מספיקים 20 instances. בזמן אירוע ויראלי, נפח ההעלאות קופץ פי 30 תוך דקות. autoscaling policy מגיב תוך שניות ומעלה instances חדשים, אבל בפועל התפוקה עדיין מוגבלת על ידי rate limit של ספק המודל - כך שהמערכת מפעילה תור priority (תוכן שמסומן כרגיש עולה קודם) ומחזירה תשובת "בבדיקה" זמנית לתוכן בעדיפות נמוכה, במקום לתת לכל הבקשות להיתקע יחד באותו תור.

עקומת עלות מול תפוקה: מתי scaling מפסיק להשתלם

עוד מונח שקל להתעלם ממנו: scaling אופקי לא תמיד לינארי - מעבר לנקודה מסוימת, כל instance נוסף מוסיף פחות תפוקה יחסית, כי משאבים משותפים (בסיס נתונים, rate limit חיצוני, רוחב פס רשת) הופכים לצוואר בקבוק לפני שהחישוב עצמו מוצה. זיהוי הנקודה הזו - שבה הוספת instances נוספים כבר לא משפרת ביצועים משמעותית - חוסך עלות מיותרת ומכוון את מאמצי האופטימיזציה למקום הנכון: לפעמים הפתרון האמיתי הוא לא עוד instances, אלא הרחבת צוואר הבקבוק המשותף עצמו, כמו הגדלת quota מול ספק חיצוני או שדרוג בסיס הנתונים.

Health Checks ו-Readiness: מתי instance באמת מוכן לעבודה

לא מספיק שinstance "רץ" - הוא צריך להיות באמת מוכן לקבל תעבורה, וזה לא תמיד אותו רגע. סוכן AI שזה עתה עלה עדיין צריך לטעון קונפיגורציה, לפתוח חיבורים למאגרי נתונים, ולפעמים לחמם cache מקומי - וכל זה לוקח זמן. Readiness Probe נפרד מ-Liveness Probe קלאסי: liveness בודק שה-process בכלל חי, readiness בודק שהוא מוכן לענות תשובות איכותיות. שליחת תעבורה ל-instance שעדיין "מתחמם" גורמת לתשובות איטיות או שגויות דווקא ברגע שהמערכת הכי צריכה שה-scaling יעבוד חלק. הגדרת readiness probe מדויקת - שבודקת בפועל שכל התלויות הקריטיות זמינות, לא רק שה-HTTP server מגיב - היא הבדל משמעותי בין scale-up שמשפר ביצועים מיידית לבין scale-up שמוסיף instances "עיוורים" לכמה שניות ראשונות.

Connection Pooling וניהול חיבורים בקנה מידה גדול

כשיש מאות או אלפי instances, כל אחד מחזיק חיבורים משלו למאגרי הנתונים, לתורים, ולספקי המודל - וריבוי חיבורים כזה יכול בעצמו להפוך לצוואר בקבוק, ולעיתים אף לגרום לבסיס הנתונים או לספק ה-API לחסום חיבורים חדשים. Connection Pooling - שכבת ביניים שמנהלת מספר מוגבל של חיבורים משותפים במקום שכל instance יפתח חיבור עצמאי - הופכת חיוני בקנה מידה גדול. חשוב גם להגדיר timeout סביר על כל חיבור ומספר חיבורים מקסימלי לכל instance, כדי שגידול פתאומי במספר ה-instances לא יגרום להצפה של החיבורים במאגר המשותף.

Multi-Region Scaling: כשמכפילים את המערכת לאזורים שונים

כשמערכת גדלה מעבר לאזור גיאוגרפי בודד, נוסף ממד scaling נוסף: לא רק "כמה instances" אלא "באיזה אזור". חלוקת עומס בין אזורים משרתת שתי מטרות בו-זמנית - latency נמוך יותר למשתמשים בכל אזור, ועמידות: אם אזור שלם נופל (תקלת ספק ענן, בעיית רשת אזורית), התעבורה מנותבת אוטומטית לאזורים אחרים. האתגר המרכזי הוא שכל החלטה על scaling רב-אזורי כרוכה גם בהחלטה על מיקום הנתונים - האם מאגר המצב המשותף (זיכרון סוכנים, היסטוריית שיחה) משוכפל בין אזורים, וכיצד מתמודדים עם הפער הזמני שנוצר בשכפול הזה. פתרון נפוץ הוא toleration למידה מסוימת של eventual consistency בין אזורים, בדומה לעקרונות שמפורטים ב-Distributed AI Systems, עם ניתוב משתמש קבוע לאזור "הבית" שלו כברירת מחדל, ומעבר לאזור אחר רק בעת כשל.

בדיקות עומס: לוודא ש-Scaling אכן עובד לפני שהעומס האמיתי מגיע

הדרך היחידה לדעת בוודאות שמדיניות ה-autoscaling עובדת כמצופה היא לבדוק אותה תחת עומס מבוקר, לפני שעומס אמיתי בלתי צפוי בודק אותה במקומכם. Load Testing ייעודי לעומסי AI צריך לדמות לא רק נפח בקשות, אלא גם את השונות במשך העיבוד (חלק קצרות, חלק ארוכות) ואת ההתנהגות מול rate limit חיצוני - כולל תרחיש שבו הספק מתחיל להחזיר 429 באמצע הבדיקה, כדי לוודא שהמערכת מגיבה נכון (backoff, לא ניסיון חוזר אגרסיבי שמחמיר את המצב). בדיקה כזו חושפת גם bottlenecks נסתרים - כמו connection pool קטן מדי - הרבה לפני שהם הופכים לתקלת פרודקשן.

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

  • עיצוב stateful "כי זה יעבוד לעכשיו" - הופך לחסם משמעותי כשמגיע צורך אמיתי ב-scale.
  • Autoscaling לפי CPU בלבד - לא משקף את העומס האמיתי במערכת שמבוססת בעיקר על I/O wait.
  • התעלמות מ-rate limit חיצוני כגורם מגביל - מוביל להשקעה ב-scaling של השכבה הלא נכונה.
  • אין תקרת עלות באוטוסקיילינג - עומס בלתי צפוי (או באג) יכול לגרום להוצאה חריגה לפני שמישהו שם לב.

שאלות נפוצות

כמה instances צריך להתחיל איתם?

אין מספר קבוע - תלוי בעומס הבסיסי ובזמן שלוקח ל-instance חדש "להתחמם" ולהיות זמין. עדיף להתחיל שמרני ולתת ל-autoscaling לגדול, עם מדד ברור שמפעיל את הגידול.

איך מתמודדים עם Rate Limit של ספק מודל כשה-scaling כבר לא עוזר?

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

מה ההבדל בין Horizontal ל-Vertical Scaling עבור AI Agents?

Vertical Scaling מגדיל את המשאבים של מכונה בודדת (יותר CPU/זיכרון) - פשוט אבל מוגבל בתקרה ויוצר נקודת כשל בודדת. Horizontal Scaling מוסיף עוד מכונות עצמאיות - מורכב יותר לתכנן אך כמעט חסר תקרה וגם עמיד יותר לכשלים.

איך יודעים שהמערכת מוכנה ל-scale אופקי אמיתי?

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

סיכום

Scaling אופקי אמיתי של AI Agents דורש הפרדה נכונה בין הסוכן (stateless, בר-החלפה) לזיכרון שלו (persistent, משותף), מדיניות autoscaling שמבינה I/O wait ולא רק CPU, ותכנון סביב Rate Limits חיצוניים כמגבלה אמיתית, לא רק תיאורטית. אם המערכת שלכם צריכה לתמוך בהרבה יותר משתמשים בעתיד, בתשתית פרודקשן של מדיה דיל נבנה את זה נכון מהיסוד - דברו איתנו בוואטסאפ.

תגיות: Horizontal Scaling · AI Agents · Autoscaling · Load Balancing · Rate Limits · Stateless Architecture · Scale

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