"तुम्ही तुमच्या कोडच्या रनिंग मिलिसेकंदांसाठीच पैसे देता" हा सर्व्हरलेसचा (serverless) समज AWS Lambda वर AI agent चालवण्याचा प्रयत्न करताना मोडीत निघतो. व्यवहारात, सर्वात मोठे खर्च हे Lambda-compute चार्जेस नसून cold-start latency, retry loops आणि त्या लूप्समुळे निर्माण होणारा token usage हे असतात.

सामान्य सर्व्हरलेस चित्र AI agents ला कसे दिशाभूल करते

बहुतेक डेव्हलपर्स Lambda फंक्शनला केवळ एक शुद्ध compute sandbox मानतात: हँडलर (handler) वेगवान ठेवा, मेमरी साईज मध्यम ठेवा आणि बिल स्थिर राहील याची खात्री करा. हे साध्या HTTP endpoints साठी काम करते, परंतु एखादा agent जो लँग्वेज मॉडेलला कॉल करतो, प्रतिसादाचे मूल्यमापन करतो आणि शक्य असल्यास संपूर्ण सायकल पुन्हा प्रयत्न (retry) करतो, तो एका सिंगल Lambda invocation शी थेट जुळत नाही. Agent चा अंतर्गत वर्कफ्लो मॉडेल कॉल्सची संख्या वाढवतो, आणि प्रत्येक अतिरिक्त कॉलमुळे टोकन खर्च वाढतो जो compute charge पेक्षा कितीतरी जास्त असू शकतो.

Cold starts हा छुपा खर्च आहे

जेव्हा Lambda कंटेनर पहिल्यांदा प्रोव्हिजन (provision) केला जातो, तेव्हा त्याला डिप्लॉयमेंट पॅकेज अनपॅक करावे लागते. संबंधित agent मोठ्या प्रमाणात Python libraries वापरतो, त्यामुळे इमेजचा आकार मोठा असू शकतो. केवळ स्थानिक चाचणीसाठी वापरल्या जाणाऱ्या ब्राउझर ऑटोमेशन लायब्ररीसारखी डेव्हलपमेंट-ओन्ली टूल्स काढून टाकल्यास इमेजचा आकार कमी होतो, ज्यामुळे अनपॅक होण्याचा वेळ कमी होतो. पॅकेज जितके हलके असेल, तितके फंक्शन विनंती (request) हाताळण्यासाठी वेगाने तयार होईल, ज्यामुळे कंटेनर वॉर्म-अप (warm up) होण्याची प्रतीक्षा करण्याचा वेळ कमी होईल.

दुसरा महत्त्वाचा घटक म्हणजे इनिशियलायझेशन कोड (initialization code) कुठे आहे. Agent चा ग्राफ मॉड्यूल इम्पोर्ट (module import) वेळी तयार केल्यास, प्रत्येक रिक्वेस्टवर काम करण्याऐवजी कंटेनर सुरू झाल्यावर एकदाच हे जड काम पूर्ण होते. त्यानंतर 'warm invocations' मध्ये हे काम पूर्णपणे वगळले जाते. याचा तोटा म्हणजे थोडा जास्त cold start वेळ, परंतु फायदा असा की कंटेनर वॉर्म झाल्यानंतर प्रत्येक रिक्वेस्टसाठी सेटअप वेळ जवळजवळ शून्य होतो.

मेमरी हा लेटन्सी (latency) नियंत्रित करण्याचा पर्याय आहे

Lambda वर तुम्ही किती मेमरी वाटप करता, यावरून फंक्शनला मिळणारा CPU चा हिस्सा देखील ठरतो. फंक्शनला 1 GB मेमरी सेट केल्यास त्याला पूर्ण व्हर्च्युअल CPU कोअर (virtual CPU core) मिळतो. अतिरिक्त CPU मुळे लायब्ररी इम्पोर्ट करणे आणि agent graph तयार करणे वेगवान होते, ज्यामुळे cold-start आणि warm-up latency दोन्ही कमी होतात.

लूप खर्च: retries मुळे टोकन खर्च वाढतो

Agent एका worker-evaluator लूपचे अनुसरण करतो. Worker प्रतिसाद तयार करतो, evaluator त्याची तपासणी करतो, आणि जर evaluator ने त्रुटी (error) दर्शवली, तर ती टास्क पुन्हा worker कडे पाठवली जाते. हार मानण्यापूर्वी हे लूप पाच वेळापर्यंत पुन्हा होऊ शकते. याचा अर्थ असा की एका सिंगल एक्सटर्नल रिक्वेस्टमुळे खालील गोष्टी घडू शकतात:

  • worker मॉडेलला पाच वेळापर्यंत कॉल्स
  • evaluator मॉडेलला पाच वेळापर्यंत कॉल्स
  • agent ने ठरवलेले कितीही tool calls

Lambda बिल अंदाजित राहते कारण AWS एक्झिक्यूशनच्या मिलिसेकंदांसाठी शुल्क आकारते, परंतु किती retries आवश्यक आहेत यावर टोकन बिल मोठ्या प्रमाणात बदलू शकते.

टाइमआउटचा सापळा: API Gateway vs. Lambda

API Gateway त्याच्या समोर येणाऱ्या HTTP रिक्वेस्टवर २९ सेकंदांची कडक टाइमआउट (timeout) मर्यादा घालते. जरी मूळ Lambda फंक्शन पाच मिनिटांच्या एक्झिक्यूशन विंडोसाठी कॉन्फिगर केलेले असले, तरी पाच टर्नचा agent loop सहजपणे ही मर्यादा ओलांडू शकतो. Lambda Function URLs वापरून API Gateway बायपास केल्यास २९ सेकंदांची ही मर्यादा निघून जाते, ज्यामुळे फंक्शन न थांबता आपला लूप पूर्ण करू शकते.

डेव्हलपर्सनी कशासाठी बजेट ठरवले पाहिजे

धडा साधा आहे: सर्व्हरलेस AI agent साठी बजेट ठरवताना केवळ Lambda runtime च्या मिलिसेकंदांची बेरीज करून चालणार नाही. तुम्हाला खालील गोष्टींचा विचार करावा लागेल:

  • डिप्लॉयमेंट पॅकेजचा आकार आणि परिणामी होणारा cold-start latency
  • मेमरी सेटिंग जे CPU आणि त्यामुळे इम्पोर्ट स्पीड ठरवते
  • worker-evaluator लूपमधील अपेक्षित retries ची संख्या, जी थेट टोकन वापराला चालना देते
  • अकाली टाइमआउट टाळण्यासाठी फ्रंट-एंडची निवड (API Gateway vs. Function URL)

यापैकी कोणत्याही व्हेरिएबलकडे दुर्लक्ष केल्यास तुमचे बिल तुमच्या अंदाजानुसार नसेल.