"તમે ફક્ત તમારા કોડના ચાલતા મિલીસેકન્ડ્સ માટે જ ચૂકવણી કરો છો" એ સર્વરલેસનો દાવો ત્યારે ખોટો સાબિત થાય છે જ્યારે તમે AWS Lambda પર AI એજન્ટ ચલાવવાનો પ્રયાસ કરો છો. વ્યવહારમાં, સૌથી મોટો ખર્ચ Lambda-compute ચાર્જ નથી, પરંતુ કોલ્ડ-સ્ટાર્ટ લેટન્સી (cold-start latency), રીટ્રાય લૂપ્સ (retry loops) અને તે લૂપ્સ દ્વારા વપરાતા ટોકન્સ (token usage) છે.

શા માટે સામાન્ય સર્વરલેસ ચિત્ર AI એજન્ટોને ગેરમાર્ગે દોરે છે

મોટાભાગના ડેવલપર્સ Lambda ફંક્શનને શુદ્ધ કમ્પ્યુટ સેન્ડબોક્સ (compute sandbox) તરીકે જુએ છે: હેન્ડલરને ઝડપી રાખો, મધ્યમ મેમરી સાઈઝ સેટ કરો, અને બિલ સ્થિર રહે તે જુઓ. તે સાદા HTTP એન્ડપોઈન્ટ્સ માટે કામ કરે છે, પરંતુ એક એજન્ટ જે લેંગ્વેજ મોડલને કોલ કરે છે, પ્રતિસાદનું મૂલ્યાંકન કરે છે, અને સંભવિતપણે આખા ચક્રને ફરીથી પ્રયાસ (retry) કરે છે, તે એક સિંગલ Lambda ઇનવોકેશન (invocation) સાથે સીધો સંબંધ ધરાવતો નથી. એજન્ટનો આંતરિક વર્કફ્લો મોડલ કોલ્સની સંખ્યામાં વધારો કરે છે, અને દરેક વધારાનો કોલ ટોકન ખર્ચ વધારે છે જે કમ્પ્યુટ ચાર્જ કરતા પણ ઘણો વધારે હોઈ શકે છે.

કોલ્ડ સ્ટાર્ટ્સ (Cold starts) એ છુપો ખર્ચ છે

જ્યારે Lambda કન્ટેનર પ્રથમ વખત પ્રોવિઝન કરવામાં આવે છે, ત્યારે તેણે ડિપ્લોયમેન્ટ પેકેજ અનપેક કરવું પડે છે. જે એજન્ટની વાત થઈ રહી છે તે Python લાઇબ્રેરીઓનો મોટો સેટ ખેંચે છે, તેથી ઇમેજ મોટી હોઈ શકે છે. ડેવલપમેન્ટ-માત્ર ઉપયોગમાં લેવાતા સાધનો—જેમ કે લોકલ ટેસ્ટિંગ માટે વપરાતી બ્રાઉઝર ઓટોમેશન લાઇબ્રેરી—તેને દૂર કરવાથી ઇમેજનું કદ ઘટે છે, જેનાથી અનપેક કરવાનો સમય પણ ઘટે છે. નાનું પેકેજ એટલે ફંક્શન વિનંતી (request) હેન્ડલ કરવા માટે ઝડપથી તૈયાર થઈ જાય છે, જેનાથી કન્ટેનર વોર્મ-અપ થવાની રાહ જોવામાં વિતાવેલો સમય ઘટે છે.

બીજો ઉપાય એ છે કે ઇનિશિયલાઇઝેશન કોડ (initialization code) ક્યાં રહે છે. મોડ્યુલ ઇમ્પોર્ટ સમયે એજન્ટનું ગ્રાફ બનાવવાથી, ભારે કામ દરેક વિનંતી પર કરવાને બદલે કન્ટેનરના દરેક સ્ટાર્ટ વખતે માત્ર એક જ વાર થાય છે. ત્યારબાદ વોર્મ ઇનવોકેશનમાં (warm invocations) તે કામ કરવાની જરૂર પડતી નથી. આમાં થોડો લાંબો કોલ્ડ સ્ટાર્ટ સમય લાગે છે, પરંતુ ફાયદો એ છે કે કન્ટેનર વોર્મ થયા પછી પ્રતિ-વિનંતી સેટઅપ સમય લગભગ શૂન્ય થઈ જાય છે.

મેમરી લેટન્સી કંટ્રોલર તરીકે પણ કામ કરે છે

Lambda પર તમે જે મેમરી ફાળવો છો તે ફંક્શનને મળતા CPU ના હિસ્સાને પણ નક્કી કરે છે. ફંક્શનને 1 GB મેમરી સેટ કરવાથી તેને સંપૂર્ણ વર્ચ્યુઅલ CPU કોર મળે છે. વધારાનો CPU લાઇબ્રેરીઓના ઇમ્પોર્ટ અને એજન્ટ ગ્રાફના નિર્માણને ઝડપી બનાવે છે, જેનાથી કોલ્ડ-સ્ટાર્ટ અને વોર્મ-અપ લેટન્સી બંને ઘટે છે.

લૂપ ખર્ચ: રીટ્રાય્સ ટોકન ખર્ચમાં વધારો કરે છે

એજન્ટ વર્કર-ઇવેલ્યુએટર (worker-evaluator) લૂપ અનુસરે છે. વર્કર પ્રતિસાદ જનરેટ કરે છે, ઇવેલ્યુએટર તેની તપાસ કરે છે, અને જો ઇવેલ્યુએટર ભૂલ દર્શાવે તો કાર્ય ફરીથી વર્કરને મોકલવામાં આવે છે. લૂપ હાર માનતા પહેલા પાંચ વખત સુધી પુનરાવર્તિત થઈ શકે છે. તેનો અર્થ એ છે કે એક સિંગલ એક્સટર્નલ વિનંતી નીચે મુજબના કોલ્સ ટ્રિગર કરી શકે છે:

  • વર્કર મોડલ માટે પાંચ સુધીના કોલ્સ
  • ઇવેલ્યુએટર મોડલ માટે પાંચ સુધીના કોલ્સ
  • એજન્ટ દ્વારા કરવામાં આવતા ટૂલ કોલ્સની ગમે તેટલી સંખ્યા

Lambda બિલ અનુમાનિત રહે છે કારણ કે AWS એક્ઝિક્યુશનના મિલીસેકન્ડ દીઠ ચાર્જ કરે છે, પરંતુ કેટલા રીટ્રાયની જરૂર છે તેના આધારે ટોકન બિલમાં મોટો ફેરફાર થઈ શકે છે.

ટાઈમઆઉટનો ફાંસો: API Gateway વિરુદ્ધ Lambda

API Gateway તેના દ્વારા સંચાલિત HTTP વિનંતી પર 29 સેકન્ડનો કડક ટાઈમઆઉટ લાદે છે. પાંચ-ટર્ન એજન્ટ લૂપ આ મર્યાદા સરળતાથી ઓળંગી શકે છે, ભલે અન્ડરલાઇંગ Lambda ફંક્શન પાંચ મિનિટના એક્ઝિક્યુશન વિન્ડો માટે કોન્ફિગર કરેલું હોય. Lambda Function URLs નો ઉપયોગ કરીને API Gateway ને બાયપાસ કરવાથી 29-સેકન્ડની મર્યાદા દૂર થાય છે, જેનાથી ફંક્શન તેની લૂપ અધવચ્ચે કપાયા વગર પૂર્ણ કરી શકે છે.

ડેવલપર્સ માટે બજેટમાં શું ધ્યાનમાં લેવું જોઈએ

પાઠ સરળ છે: સર્વરલેસ AI એજન્ટ માટે બજેટ બનાવવા માટે માત્ર Lambda રનટાઇમના મિલીસેકન્ડ્સનો સરવાળો કરવો પૂરતો નથી. તમારે આ બાબતો ધ્યાનમાં લેવી પડશે:

  • ડિપ્લોયમેન્ટ પેકેજનું કદ અને તેના પરિણામે થતી કોલ્ડ-સ્ટાર્ટ લેટન્સી
  • મેમરી સેટિંગ જે CPU અને તેથી ઇમ્પોર્ટ સ્પીડ નક્કી કરે છે
  • વર્કર-ઇવેલ્યુએટર લૂપમાં અપેક્ષિત રીટ્રાયની સંખ્યા, જે સીધી રીતે ટોકન વપરાશ વધારે છે
  • અકાળ ટાઈમઆઉટ ટાળવા માટે ફ્રન્ટ-એન્ડની પસંદગી (API Gateway વિરુદ્ધ Function URL)

આમાંથી કોઈપણ વેરિએબલને અવગણવાથી તમને એવું બિલ મળી શકે છે જે તમારા અંદાજ કરતા સાવ અલગ હોય.