നിങ്ങളുടെ കോഡ് പ്രവർത്തിക്കുന്ന മില്ലിസെക്കൻഡുകൾക്ക് മാത്രമേ നിങ്ങൾ പണം നൽകേണ്ടതുള്ളൂ എന്ന സെർവർലെസ്സ് മിത്ത് (myth), AWS Lambda-യിൽ ഒരു AI ഏജന്റ് പ്രവർത്തിപ്പിക്കാൻ ശ്രമിക്കുമ്പോൾ തകർന്നടിയുന്നു. പ്രായോഗികമായി നോക്കിയാൽ, ഏറ്റവും വലിയ ചിലവ് Lambda-compute ചാർജല്ല, മറിച്ച് cold-start latency, retry loops, ആ ലൂപ്പുകൾ മൂലമുണ്ടാകുന്ന token usage എന്നിവയാണ്.

സാധാരണ സെർവർലെസ്സ് കാഴ്ചപ്പാട് AI ഏജന്റുകളെ എങ്ങനെ തെറ്റിദ്ധരിപ്പിക്കുന്നു

മിക്ക ഡെവലപ്പർമാരും ഒരു Lambda ഫംഗ്ഷനെ വെറുമൊരു കമ്പ്യൂട്ട് സാൻഡ്ബോക്സ് (compute sandbox) ആയിട്ടാണ് കാണുന്നത്: ഹാൻഡ്‌ലർ (handler) വേഗത്തിൽ പ്രവർത്തിപ്പിക്കുക, മിതമായ മെമ്മറി സൈസ് നിശ്ചയിക്കുക, അതുവഴി ബില്ല് കുറഞ്ഞ നിലയിൽ നിലനിർത്തുക. ഇത് ലളിതമായ HTTP എൻഡ്പോയിന്റുകൾക്ക് (endpoints) അനുയോജ്യമാണ്, എന്നാൽ ഒരു ലാംഗ്വേജ് മോഡലിനെ വിളിക്കുകയും, അതിന്റെ മറുപടി വിലയിരുത്തുകയും, ആവശ്യമെങ്കിൽ ആ പ്രക്രിയ വീണ്ടും ആവർത്തിക്കുകയും (retry) ചെയ്യുന്ന ഒരു ഏജന്റ് ഒരു സിംഗിൾ Lambda invocation-മായി നേരിട്ട് താരതമ്യം ചെയ്യാൻ കഴിയില്ല. ഏജന്റിന്റെ ആന്തരിക പ്രവർത്തനരീതി (internal workflow) മോഡൽ കോളുകളുടെ എണ്ണം വർദ്ധിപ്പിക്കുന്നു, കൂടാതെ ഓരോ അധിക കോളും കമ്പ്യൂട്ട് ചാർജിനേക്കാൾ വലിയ ടോക്കൺ ചിലവ് (token cost) ഉണ്ടാക്കിയേക്കാം.

Cold starts ആണ് മറഞ്ഞിരിക്കുന്ന ചിലവ്

ഒരു Lambda കണ്ടെയ്നർ ആദ്യമായി പ്രൊവിഷൻ ചെയ്യുമ്പോൾ (provisioned), അതിന് ഡിപ്ലോയ്‌മെന്റ് പാക്കേജ് (deployment package) അൺപാക്ക് ചെയ്യേണ്ടതുണ്ട്. ഏജന്റ് ഉപയോഗിക്കുന്ന വലിയൊരു കൂട്ടം Python ലൈബ്രറികൾ ഇതിലുണ്ട്, അതിനാൽ ഇമേജ് വലുതായിരിക്കാം. ലോക്കൽ ടെസ്റ്റിംഗിന് മാത്രം ഉപയോഗിക്കുന്ന ബ്രൗസർ ഓട്ടോമേഷൻ ലൈബ്രറി പോലുള്ള ഡെവലപ്‌മെന്റ് ടൂളുകൾ ഒഴിവാക്കുന്നത് ഇമേജ് സൈസ് കുറയ്ക്കാൻ സഹായിക്കും, ഇത് അൺപാക്കിംഗ് സമയം കുറയ്ക്കുകയും ചെയ്യും. കുറഞ്ഞ വലിപ്പമുള്ള പാക്കേജ് എന്നാൽ ഫംഗ്ഷൻ വേഗത്തിൽ റിക്വസ്റ്റുകൾ കൈകാര്യം ചെയ്യാൻ തയ്യാറാകും, ഇത് കണ്ടെയ്നർ വാം അപ്പ് (warm up) ആകാൻ കാത്തുനിൽക്കുന്ന സമയം കുറയ്ക്കുന്നു.

രണ്ടാമത്തെ കാര്യം ഇനീഷ്യലൈസേഷൻ കോഡ് (initialization code) എവിടെ ഇരിക്കുന്നു എന്നതാണ്. ഏജന്റിന്റെ ഗ്രാഫ് (graph) മോഡ്യൂൾ ഇംപോർട്ട് സമയത്ത് നിർമ്മിക്കുന്നതിലൂടെ, ഓരോ റിക്വസ്റ്റിനും പകരം കണ്ടെയ്നർ സ്റ്റാർട്ട് ചെയ്യുമ്പോൾ ഒരു തവണ മാത്രം കഠിനമായ ജോലികൾ (heavy lifting) നടക്കുന്നു. തുടർന്ന് വരുന്ന 'warm invocations' ഈ ജോലി പൂർണ്ണമായും ഒഴിവാക്കുന്നു. ഇതിന്റെ പോരായ്മ അല്പം കൂടിയ cold start ആണ്, എന്നാൽ കണ്ടെയ്നർ വാം ആയതിന് ശേഷം ഓരോ റിക്വസ്റ്റിനും സെറ്റപ്പ് സമയം ഏതാണ്ട് പൂജ്യമായിരിക്കും എന്നതാണ് ഇതിന്റെ ഗുണം.

മെമ്മറി ഒരു ലേറ്റൻസി നിയന്ത്രണമായും (latency knob) പ്രവർത്തിക്കുന്നു

Lambda-യിൽ നിങ്ങൾ അനുവദിക്കുന്ന മെമ്മറിയുടെ അളവ് ആ ഫംഗ്ഷന് ലഭിക്കുന്ന CPU-യുടെ പങ്കും നിർണ്ണയിക്കുന്നു. ഫംഗ്ഷന് 1 GB മെമ്മറി നൽകുന്നത് അതിന് ഒരു ഫുൾ വെർച്വൽ CPU കോർ (virtual CPU core) നൽകുന്നു. അധികമായി ലഭിക്കുന്ന CPU ലൈബ്രറികളുടെ ഇംപോർട്ടും ഏജന്റ് ഗ്രാഫ് നിർമ്മാണവും വേഗത്തിലാക്കുന്നു, ഇത് cold-start ലേറ്റൻസിയും warm-up ലേറ്റൻസിയും കുറയ്ക്കുന്നു.

ലൂപ്പ് ചിലവ്: റീട്രൈകൾ ടോക്കൺ ചിലവ് വർദ്ധിപ്പിക്കുന്നു

ഏജന്റ് ഒരു worker-evaluator ലൂപ്പ് പിന്തുടരുന്നു. വർക്കർ ഒരു മറുപടി നൽകുന്നു, ഇവാലുവേറ്റർ (evaluator) അത് പരിശോധിക്കുന്നു, ഇവാലുവേറ്റർ ഒരു പിശക് കണ്ടെത്തിയാൽ ആ ടാസ്ക് വീണ്ടും വർക്കറിലേക്ക് അയക്കുന്നു. ഈ ലൂപ്പ് അഞ്ച് തവണ വരെ ആവർത്തിച്ചേക്കാം. ഇതിനർത്ഥം ഒരു സിംഗിൾ എക്സ്റ്റേണൽ റിക്വസ്റ്റ് താഴെ പറയുന്നവയ്ക്ക് കാരണമായേക്കാം:

  • വർക്കർ മോഡലിലേക്കുള്ള അഞ്ച് കോളുകൾ വരെ
  • ഇവാലുവേറ്റർ മോഡലിലേക്കുള്ള അഞ്ച് കോളുകൾ വരെ
  • ഏജന്റ് തീരുമാനിക്കുന്ന എണ്ണം ടൂൾ കോളുകൾ (tool calls)

AWS എക്സിക്യൂഷന്റെ മില്ലിസെക്കൻഡുകൾക്ക് ചാർജ് ചെയ്യുന്നതിനാൽ Lambda ബില്ല് പ്രവചിക്കാവുന്നതാണ്, എന്നാൽ എത്ര തവണ റീട്രൈ ചെയ്യേണ്ടി വരുന്നു എന്നതിനെ ആശ്രയിച്ച് ടോക്കൺ ബില്ലിൽ വലിയ വ്യത്യാസങ്ങൾ വരാം.

ടൈമൗട്ട് കെണി: API Gateway vs. Lambda

API Gateway അതിന്റെ കീഴിലുള്ള HTTP റിക്വസ്റ്റുകൾക്ക് 29 സെക്കൻഡ് ടൈമൗട്ട് നിബന്ധന ഏർപ്പെടുത്തുന്നു. അണ്ടർലൈയിംഗ് Lambda ഫംഗ്ഷൻ അഞ്ച് മിനിറ്റ് എക്സിക്യൂഷൻ വിൻഡോയ്ക്കായി ക്രമീകരിച്ചിട്ടുണ്ടെങ്കിൽ പോലും, അഞ്ച് ഘട്ടങ്ങളുള്ള ഒരു ഏജന്റ് ലൂപ്പ് ഈ പരിധി എളുപ്പത്തിൽ മറികടന്നേക്കാം. Lambda Function URLs ഉപയോഗിച്ച് API Gateway ഒഴിവാക്കുന്നത് 29 സെക്കൻഡ് പരിധി നീക്കം ചെയ്യുന്നു, ഇത് ഫംഗ്ഷന് അതിന്റെ ലൂപ്പ് പൂർത്തിയാക്കാൻ അനുവദിക്കുന്നു.

ഡെവലപ്പർമാർ എന്തിനുവേണ്ടിയാണ് ബജറ്റ് തയ്യാറാക്കേണ്ടത്

പാഠം ലളിതമാണ്: ഒരു സെർവർലെസ്സ് AI ഏജന്റിനായി ബജറ്റ് തയ്യാറാക്കുമ്പോൾ Lambda റൺടൈം മില്ലിസെക്കൻഡുകൾ മാത്രം കൂട്ടിയാൽ പോരാ. നിങ്ങൾ താഴെ പറയുന്നവ കൂടി കണക്കിലെടുക്കണം:

  • ഡിപ്ലോയ്‌മെന്റ് പാക്കേജിന്റെ വലിപ്പവും അതുമൂലമുണ്ടാകുന്ന cold-start ലേറ്റൻസിയും
  • CPU-യെയും ഇംപോർട്ട് വേഗതയെയും നിർണ്ണയിക്കുന്ന മെമ്മറി സെറ്റിംഗ്സ്
  • വർക്കർ-ഇവാലുവേറ്റർ ലൂപ്പിലെ പ്രതീക്ഷിക്കാവുന്ന റീട്രൈകളുടെ എണ്ണം, ഇത് നേരിട്ട് ടോക്കൺ ഉപയോഗത്തെ സ്വാധീനിക്കുന്നു
  • ടൈമൗട്ടുകൾ ഒഴിവാക്കാൻ ഫ്രണ്ട്-എൻഡ് തിരഞ്ഞെടുപ്പ് (API Gateway vs. Function URL)

ഇതിൽ ഏതെങ്കിലും ഒരു ഘടകത്തെ അവഗണിച്ചാൽ, നിങ്ങൾ കണക്കാക്കിയതിൽ നിന്നും തികച്ചും വ്യത്യസ്തമായ ഒരു ബില്ല് ലഭിച്ചേക്കാം.