המיתוס של ה-serverless ש"משלמים רק על המילישניות שבהן הקוד רץ" מתפרק כשמנסים להריץ AI agent על AWS Lambda. בפועל, הסעיפים הגדולים ביותר בחשבון אינם עלות המחשוב של Lambda, אלא השיהוי של ה-cold-start, לולאות ניסיונות חוזרים (retry loops) ושימוש בטוקנים (tokens) שהלולאות הללו מייצרות.

למה התמונה הרגילה של serverless מטעה כשמדובר ב-AI agents

רוב המפתחים מתייחסים לפונקציית Lambda כאל sandbox של מחשוב טהור: שומרים על ה-handler מהיר, מגדירים נפח זיכרון צנוע, ומקווים שהחשבון יישאר יציב. זה עובד עבור HTTP endpoints פשוטים, אך agent שקורא למודל שפה, מעריך את התגובה, ואולי מנסה שוב את כל המחזור, אינו תואם באופן של אחד-לאחד להפעלה (invocation) בודדת של Lambda. תזרים העבודה הפנימי של ה-agent מכפיל את מספר הקריאות למודל, וכל קריאה נוספת מוסיפה עלות טוקנים שיכולה להאפיל על עלות המחשוב.

Cold starts הם התג מחיר הנסתר

כאשר container של Lambda מוקצה בפעם הראשונה, עליו לפרוק את חבילת הפריסה (deployment package). ה-agent המדובר טוען סט גדול של ספריות Python, ולכן ה-image יכול להיות גדול למדי. הסרת כלי פיתוח בלבד — כמו ספריית אוטומציה של דפדפן המשמשת רק לבדיקות מקומיות — מקטינה את גודל ה-image, מה שמקצר בתורו את זמן הפריקה. חבילה רזה יותר פירושה שהפונקציה תהיה מוכנה לטפל בבקשה מהר יותר, מה שמפחית את הזמן המושקע בהמתנה לחימום ה-container.

מנוף שני הוא המקום שבו נמצא קוד האתחול (initialization code). על ידי בניית הגרף של ה-agent בזמן ייבוא המודול (module import time), העבודה הכבדה מתבצעת פעם אחת בכל הפעלת container, במקום בכל בקשה. הפעלות "חמות" (warm invocations) מדלגות על העבודה הזו לחלוטין. הפשרה היא cold start ארוך מעט יותר, אך התמורה היא זמן הגדרה (setup time) של כמעט אפס לכל בקשה לאחר שה-container התחמם.

הזיכרון משמש גם ככפתור שליטה בשיהוי (latency)

ב-Lambda, כמות הזיכרון שאתם מקצים קובעת גם את חלק ה-CPU שהפונקציה מקבלת. הגדרת הפונקציה ל-1 GB של זיכרון מעניקה לה ליבת CPU וירטואלית מלאה. ה-CPU הנוסף מאיץ את ייבוא הספריות ואת יצירת הגרף של ה-agent, מה שמצמצם הן את ה-cold-start והן את השיהוי של ה-warm-up.

עלות הלולאה: ניסיונות חוזרים מכפילים את הוצאת הטוקנים

ה-agent פועל בלולאת worker-evaluator. ה-worker מייצר תגובה, ה-evaluator בודק אותה, ואם ה-evaluator מזהה שגיאה, המשימה נשלחת חזרה ל-worker. הלולאה יכולה לחזור על עצמה עד חמש פעמים לפני שהיא מוותרת. המשמעות היא שבקשה חיצונית אחת יכולה להפעיל:

  • עד חמש קריאות למודל ה-worker
  • עד חמש קריאות למודל ה-evaluator
  • כל מספר של קריאות לכלים (tool calls) שה-agent מחליט לבצע

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

מלכודת ה-timeout: API Gateway מול Lambda

API Gateway מטיל timeout קשיח של 29 שניות על בקשת ה-HTTP שהוא משרת. לולאת agent של חמישה סבבים יכולה בקלות לחרוג מהמגבלה הזו, גם אם פונקציית ה-Lambda שבבסיס מוגדרת לחלון הרצה של חמש דקות. עקיפת API Gateway באמצעות Lambda Function URLs מסירה את תקרת ה-29 שניות, ומאפשרת לפונקציה לסיים את הלולאה שלה מבלי שתיקטע.

על מה מפתחים צריכים לתקצב

הלקח הוא פשוט: תקצוב עבור AI agent ב-serverless דורש יותר מאשר חיבור של מילישניות של זמן ריצה ב-Lambda. עליכם לקחת בחשבון:

  • את גודל חבילת הפריסה (deployment package) ואת השיהוי של ה-cold-start הנובע ממנה
  • את הגדרת הזיכרון שקובעת את ה-CPU ובעקבות זאת את מהירות הייבוא
  • את מספר הניסיונות החוזרים הצפוי בלולאת ה-worker-evaluator, אשר מניע ישירות את השימוש בטוקנים
  • את בחירת ה-front-end (API Gateway מול Function URL) כדי למנוע timeouts מוקדמים

התעלמות מכל אחד מהמשתנים הללו עלולה להשאיר אתכם עם חשבון שנראה שונה לחלוטין מזה שתכננתם.