Cold-Start Latency בסוכני AI — למה הריצה הראשונה איטית ואיך פותרים
מאת צוות מדיה דיל · 12.08.2026 · Model Economics · 6 דק׳
הבקשה הראשונה אחרי שקט לוקחת 8 שניות, השנייה לוקחת 1.2. מדריך למקורות ה-cold start בסוכני AI — טעינת כלים, cache ריק, handshake ל-MCP — ואיך לצמצם אותם.
צוות מוצר שהריץ בדיקות latency על סוכן AI פנימי גילה תבנית עקבית: הבקשה הראשונה בכל בוקר, אחרי הלילה שבו אין תעבורה, לוקחת בממוצע 7.8 שניות. הבקשה השנייה, שלישית ורביעית לוקחות בין 1.1 ל-1.4 שניות. שום דבר לא השתנה בקוד או בפרומפט בין הבקשות — ההבדל היחיד הוא שהראשונה הייתה cold start. זו לא תופעה חדשה בהנדסת תוכנה — serverless functions סובלות מאותה בעיה כבר שנים — אבל בסוכני AI היא חמורה יותר, כי יש הרבה יותר שכבות שצריך "לחמם": container, חיבור למודל, טעינת tool definitions, ולפעמים גם handshake מול שרתי MCP חיצוניים. כל שכבה כזו מוסיפה עוד מאות מילישניות עד שניות שלמות לריצה הראשונה, וכולן נעלמות ברגע שהמערכת כבר "חמה".
ארבעה מקורות נפרדים של cold start
cold start בסוכן AI הוא לא תופעה אחת אלא צירוף של כמה עיכובים נפרדים שקורים בדרך כלל ברצף:
- אתחול container/runtime — אם השכבה שמריצה את לוגיקת ה-orchestration פרוסה כ-serverless (Lambda, Cloud Run וכדומה), יש עלות אתחול תהליך שממתינה לבקשה הראשונה אחרי תקופת חוסר פעילות.
- טעינת tool definitions וסכימות — סוכן עם עשרות כלים זמינים צריך לטעון, לבדוק ולעיתים לבנות מחדש סכימות JSON עבור כל כלי, במיוחד אם הן נבנות דינמית ולא נטענות ממטמון מוכן מראש.
- Handshake מול שרתי MCP או כלים חיצוניים — פרוטוקולים כמו MCP דורשים סבב תקשורת ראשוני להכרת היכולות הזמינות (capability discovery) לפני שאפשר להשתמש בכלי בפועל, וזה קורה מחדש בכל חיבור קר.
- Cache ריק — prefix caching של system prompt וכלים, שבו נעזרים ל-Prompt Caching, לא קיים עדיין בריצה הראשונה, כך שכל הפרומפט מעובד מאפס בלי החיסכון שנצבר בקריאות חוזרות.
כל אחד מהמקורות האלה תורם עשרות עד מאות מילישניות, וביחד הם יכולים בקלות להסביר פער של פי 5-6 בין ריצה קרה לריצה חמה — בדיוק הפער שנצפה בדוגמה מהפתיחה.
למה זה יותר גרוע בסוכני AI מאשר בשירות רגיל
בשירות backend רגיל, cold start בדרך כלל אומר אתחול runtime בלבד — פרק זמן קבוע יחסית ומדיד. בסוכן AI, cold start נערם על גבי latency שכבר גבוהה מלכתחילה בגלל זמן ה-inference עצמו, ולכן כל תוספת מרגישה יחסית משמעותית יותר למשתמש. בנוסף, מערכות agentic עם ריבוי כלים סובלות מ-cold start "מדורג": גם אחרי שה-container חם, כל כלי ספציפי שלא נעשה בו שימוש לאחרונה יכול לסבול מ-cold start משלו — למשל חיבור למסד נתונים חיצוני שנסגר אחרי חוסר פעילות, או שרת MCP שנרדם. זה יוצר תופעה שבה גם "משתמש ותיק" של המערכת חווה עיכוב בלתי צפוי כשהוא פתאום משתמש בכלי שלא הופעל בשעה האחרונה.
תופעה קרובה שכדאי להכיר: פריסת גרסה חדשה של skill או plugin לסוכן יוצרת cold start מלאכותי, גם אם התשתית עצמה הייתה חמה. ברגע שגרסה חדשה עולה, כל מטמון prefix, כל connection pool וכל capability discovery שנצברו סביב הגרסה הקודמת מתאפסים, והמערכת חוזרת זמנית להתנהגות של ריצה קרה עד שהיא "מתחממת" מחדש סביב הגרסה החדשה. זו סיבה נוספת לתכנן פריסות בזהירות ולא רק מבחינת תקינות פונקציונלית — נושא שמפורט ב-Skill Versioning ו-Rollback.
ארבע טכניקות להקטנת cold start בפועל
אין פתרון קסם יחיד, אבל כמה טכניקות משלימות מצמצמות משמעותית את הבעיה:
- Provisioned concurrency / warm pools — שמירה על מספר מינימלי של instances חמים כל הזמן, גם ללא תעבורה, כדי שהבקשה הראשונה לא תיתקל בcontainer קר. עולה כסף על תקופות שקטות, אבל משתלם כשעקביות latency קריטית.
- Pre-warming יזום — שליחת בקשת "חימום" מלאכותית לפני שעות שיא צפויות (למשל תחילת יום עבודה), כדי שה-cache וה-connections יהיו מוכנים מראש בלי לחכות למשתמש אמיתי שיגלה את העיכוב.
- Cache persistence ברמת ה-prompt — שמירת prefix caching פעיל ברקע גם בין בקשות רחוקות, כך שהחיסכון שמתואר ב-Prompt Caching לא מתאפס כל פעם שיש הפסקה קצרה בתעבורה.
- Lazy discovery עם fallback מוכן מראש — במקום לבצע handshake מול כלי MCP רק כשמישהו זקוק לו לראשונה, לבצע capability discovery ברקע מיד עם עליית השירות, כך שהמידע כבר קיים כשמגיעה בקשה אמיתית.
שילוב של הטכניקות האלה, לא רק אחת מהן, הוא מה שמצמצם את פער ה-cold start מפי 5-6 לפי 1.5-2 לכל היותר, שהוא בדרך כלל טווח סביר להרגשה של המשתמש.
שווה לתעדף את הטכניקות לפי עלות מול תועלת: pre-warming יזום ו-lazy discovery ברקע כמעט תמיד משתלמים כי הם זולים ליישום ולא דורשים תשתית נוספת, בעוד provisioned concurrency הוא הטכניקה היקרה ביותר מבין הארבע ולכן כדאי לשמור אותה למקרים שבהם עקביות latency היא דרישת מוצר קשיחה, לא נחמדה-להיות.
מתי בכלל שווה להשקיע בפתרון הבעיה
לא כל מערכת agentic זקוקה לכל הטכניקות האלה. מערכת batch שרצה פעם ביום על עומס גדול לא מרגישה cold start בכלל — היא ממילא לוקחת זמן ומריצה מספיק בקשות כדי "להתחמם" תוך דקות ספורות. הבעיה חריפה במיוחד במערכות עם תעבורה ספוראדית — כלי פנימי שמשמש רק כמה עשרות פעמים ביום, או מוצר עם תנועה מרוכזת בשעות מסוימות — כי שם כל בקשה שנייה עלולה לחוות עיכוב קר. שווה למדוד את פיזור העומס בפועל (מרווח זמן ממוצע בין בקשות) לפני שמשקיעים בתשתית warm pool קבועה, כי היא לא זולה: החזקת instances חמים 24/7 היא עלות תפעולית מתמשכת, ולעיתים משתלם יותר לקבל latency גבוה בריצה הראשונה בבוקר מאשר לשלם על זמינות מלאה כל הלילה. הכרעה כזו קשורה ישירות לעקרונות שמתוארים ב-Model Failover Architecture, שבה גם שם צריך לאזן בין זמינות תמידית לבין עלות של החזקת קיבולת רזרבית.
המדד המעשי לקבלת ההחלטה הזו הוא פשוט: מודדים את אחוז הבקשות שבפועל חוות cold start (לא רק הבקשה הראשונה בבוקר, אלא כל בקשה שמגיעה אחרי פער זמן ארוך מספיק מהקודמת), ואת ההשפעה שלהן על מדדי חוויית משתמש כמו נטישה או תלונות. רק כשהיחס הזה עובר סף משמעותי, ההשקעה בפתרון קבוע ומורכב באמת מצדיקה את עצמה.
תגיות: Cold Start · Latency · MCP · Warm Pools · Model Economics