ബില്ല് കുതിച്ചുയരാൻ കാരണമെന്ത്

ടീം ആദ്യമായി generative AI ഉൾപ്പെടുത്തിയപ്പോൾ, ഓരോ ഉപയോക്താവിന്റെയും അഭ്യർത്ഥനകൾ ഏറ്റവും പുതിയതും ഏറ്റവും മികച്ചതുമായ മോഡലിലേക്ക് അയക്കുകയായിരുന്നു ചെയ്തത്. ട്രാഫിക് വർദ്ധിച്ചതോടെ, ഓരോ അഭ്യർത്ഥനയ്ക്കും വരുന്ന ചിലവും അതോടൊപ്പം വർദ്ധിച്ചു. ഉപയോക്താക്കളുടെ എണ്ണത്തേക്കാൾ വേഗത്തിൽ ചിലവ് കൂടുന്നതായി CFO-യുടെ സ്പ്രെഡ്ഷീറ്റിൽ കാണാമായിരുന്നു. "കുറഞ്ഞ ചിലവുള്ള മോഡൽ ഉപയോഗിക്കുക" എന്ന സാധാരണ പരിഹാരം പ്രൊഡക്ഷനിൽ ഫലപ്രദമല്ല, കാരണം ഓരോ ചോദ്യത്തിനും വ്യത്യസ്തമായ യുക്തിപരമായ (reasoning) തലങ്ങൾ ആവശ്യമാണ്. യഥാർത്ഥത്തിൽ മാറ്റം വരുത്തേണ്ടത് ഏത് മോഡൽ ഉപയോഗിക്കുന്നു എന്നതിലല്ല, മറിച്ച് അഭ്യർത്ഥന എങ്ങനെ അയക്കുന്നു എന്നതിലാണ്.

പണം ലാഭിക്കുന്ന ഒരു routing layer നിർമ്മിക്കുന്നു

എൻജിനീയർ inference service-നെ മറ്റ് പ്രൊഡക്ഷൻ ഘടകങ്ങളെപ്പോലെയാണ് പരിഗണിച്ചത്: ടയറുകൾ (tiers) നിശ്ചയിക്കുക, SLA-കൾ ക്രമീകരിക്കുക, ലേറ്റൻസി ബജറ്റുകൾ (latency budgets) നടപ്പിലാക്കുക എന്നിവയായിരുന്നു അത്. ഇതിന്റെ ഫലമായി രൂപപ്പെട്ട ആർക്കിടെക്ചറിൽ നാല് പ്രധാന ഭാഗങ്ങളുണ്ട്, ഇവ ഒത്തുചേർന്ന് 95% ചിലവ് കുറയ്ക്കാൻ സഹായിക്കുന്നു.

Tiered routing

ഒരു ലളിതമായ ഫ്രണ്ട്-എൻഡ് ഓരോ വരുന്ന അഭ്യർത്ഥനയെയും അതിന്റെ പ്രയാസത്തിനനുസരിച്ച് തരംതിരിക്കുന്നു. ഏകദേശം 95% ചോദ്യങ്ങളും ഒരു സാധാരണ മോഡൽ പ്രവർത്തിക്കുന്ന "ചെപ്പ്" (cheap) ടയറിലേക്ക് എത്തുന്നു; ഏറ്റവും പ്രയാസമേറിയ 5% ചോദ്യങ്ങൾ മാത്രമാണ് പ്രീമിയം മോഡലിലേക്ക് മാറ്റുന്നത്. ഈ തരംതിരിക്കൽ നിയമങ്ങൾ അടിസ്ഥാനമാക്കിയോ (ഉദാഹരണത്തിന്: നീളം, ഡൊമെയ്ൻ-സ്പെസിഫിക് കീവേഡുകളുടെ സാന്നിധ്യം) അല്ലെങ്കിൽ പഴയ ഡാറ്റയിൽ നിന്നോ പഠിച്ചെടുക്കാം. കുറഞ്ഞ ചിലവുള്ള ടയറിനെ മുൻഗണന നൽകുന്നതിലൂടെ ചാറ്റ്ബോട്ടിന്റെ പ്രതിമാസ ചിലവ് $420-ൽ നിന്ന് $28 ആയി കുറഞ്ഞു.

Model right-sizing

ജോലിയുടെ സങ്കീർണ്ണതയ്ക്ക് അനുസൃതമായ മോഡൽ ശേഷി ഉപയോഗിക്കുന്നത് വലിയ ലാഭമുണ്ടാക്കുന്നു:

  • ലളിതമായ ചാറ്റ് – ഫ്ലാഗ്ഷിപ്പ് മോഡലിന് പകരം ഒരു ലൈറ്റ്വെയ്റ്റ് മോഡൽ ഉപയോഗിക്കുക (97.5% ലാഭം).
  • Classification – മിഡ്-സൈസ് മോഡലിന് പകരം കുറഞ്ഞ ചിലവുള്ള മറ്റൊരു മോഡൽ ഉപയോഗിക്കുക (98.3% ലാഭം).
  • Summarization – ടോപ്പ്-ടയർ മോഡലിന് പകരം മിഡ്-റേഞ്ച് മോഡൽ ഉപയോഗിക്കുക (97.2% ലാഭം).

കൃത്യമായ മോഡൽ പേരുകൾ ഇവിടെ പ്രസക്തമല്ല; യഥാർത്ഥത്തിൽ ആവശ്യമായ കുറച്ച് ചോദ്യങ്ങൾക്കായി മാത്രം ഏറ്റവും മികച്ച മോഡലിനെ കരുതിവെക്കുക എന്നതാണ് ഇതിന്റെ തത്വം.

Smart caching

ഓരോ തവണയും കാഷിൽ (cache) നിന്ന് വിവരങ്ങൾ ലഭിക്കുമ്പോൾ ഒരു നെറ്റ്‌വർക്ക് കോളും API ചാർജും ഒഴിവാക്കപ്പെടുന്നു. ഒരു ഡിസ്ട്രിബ്യൂട്ടഡ് Redis cache, വിജയകരമായ മറുപടികൾക്കൊപ്പം "എനിക്കറിയില്ല" (I don't know) പോലുള്ള "നെഗറ്റീവ്" ഉത്തരങ്ങളും സൂക്ഷിക്കുന്നു. ഒരേ ചോദ്യം വീണ്ടും വരുമ്പോൾ, മോഡലിനെ വീണ്ടും വിളിക്കുന്നതിന് പകരം സിസ്റ്റം കാഷിലുള്ള "എനിക്കറിയില്ല" എന്ന മറുപടി നൽകുന്നു. ആയിരക്കണക്കിന് അഭ്യർത്ഥനകൾ വരുമ്പോൾ, ഇത് മാത്രം ബില്ലിൽ വലിയൊരു കുറവുണ്ടാക്കുന്നു.

Prompt compression

നീളമുള്ള പ്രോംപ്റ്റുകൾ ടോക്കൺ ഉപയോഗം വർദ്ധിപ്പിക്കുന്നു, ഇത് നേരിട്ട് ചിലവിനെ ബാധിക്കുന്നു. ടീം ക്ലയന്റ് സൈഡിലോ പ്രീ-പ്രോസസ്സിംഗ് ഘട്ടത്തിലോ ഒരു കുറഞ്ഞ ചിലവുള്ള സമ്മറൈസർ ഉപയോഗിക്കുന്നു. ഇതിലൂടെ 2,000 ടോക്കണുകളുള്ള ഒരു കോൺടെക്സ്റ്റിനെ വിലകൂടിയ മോഡലിലേക്ക് എത്തുന്നതിന് മുമ്പ് ഏകദേശം 400 ടോക്കണുകളായി ചുരുക്കുന്നു. എല്ലാ അഭ്യർത്ഥനകളിലും ഈ ടോക്കൺ കുറവ് വലിയ ലാഭമുണ്ടാക്കുന്നു, ഒപ്പം ഉപയോക്താവിന്റെ അനുഭവത്തിലും മാറ്റം വരുത്തുന്നില്ല.

Strategic batching

Batching എന്നത് ഒന്നിലധികം സ്വതന്ത്രമായ അഭ്യർത്ഥനകളെ ഒരു സിംഗിൾ API കോളിലേക്ക് ഗ്രൂപ്പ് ചെയ്യുന്ന രീതിയാണ്. ഇതിന്റെ ലളിതമായ നിയമം ഇതാണ്: ഒരു ഉപയോക്താവ് മറുപടിക്കായി കാത്തിരിക്കുകയാണെങ്കിൽ batch ചെയ്യരുത്; എന്നാൽ അഭ്യർത്ഥന ബാക്ക്ഗ്രൗണ്ടിൽ നടക്കുകയാണെങ്കിൽ (രാത്രികാല റിപ്പോർട്ടുകൾ, ഷെഡ്യൂൾ ചെയ്ത ജോലികൾ), എല്ലാം batch ചെയ്യുക. രാത്രികാല batch ജോലികൾ മാത്രം ചിലവിൽ 10-20% കുറവുണ്ടാക്കുന്നു.

Monitoring the optimization loop

അളക്കാൻ കഴിയാത്ത ഒന്നിനെ നിങ്ങൾക്ക് മെച്ചപ്പെടുത്താൻ കഴിയില്ല. എൻജിനീയർ നാല് പ്രതിവാര മെട്രിക്സുകൾ (metrics) സജ്ജീകരിച്ചു:

  1. ടയറുകൾ തിരിച്ചുള്ള ഓരോ അഭ്യർത്ഥനയ്ക്കുമുള്ള ചിലവ്.
  2. ഓരോ റൂട്ടിംഗ് പാത്തിനും വേണ്ടിയുള്ള cache-hit rate.
  3. കുറഞ്ഞ ചിലവുള്ള ടയറിൽ നിന്ന് പ്രീമിയം ടയറിലേക്കുള്ള മാറ്റത്തിന്റെ നിരക്ക് (escalation rate).
  4. ഓരോ കസ്റ്റമർ സെഗ്മെന്റിനും വേണ്ടിയുള്ള ചിലവ്.

ഈ കണക്കുകൾ വ്യതിയാനങ്ങൾ (drift) കണ്ടെത്താൻ സഹായിക്കുന്നു—ഉദാഹരണത്തിന്, escalation rate കൂടുന്നത് classification ലോജിക് വളരെ കർശനമാണെന്നോ അല്ലെങ്കിൽ കുറഞ്ഞ ചിലവുള്ള മോഡലിന്റെ ഗുണനിലവാരം കുറഞ്ഞുവെന്നോ സൂചിപ്പിക്കാം. ടീം ഓരോ ആഴ്ചയും thresholds, model assignments, cache policies എന്നിവ പരിഷ്കരിക്കുന്നു. ഇത് ചിലവ് നിയന്ത്രിക്കുന്നത് ഒരു പ്രതിസന്ധി ഘട്ടത്തിലെ നടപടിയെന്നതിലുപരി ഒരു ശീലമാക്കി മാറ്റുന്നു.

Takeaway

അഭ്യർത്ഥനകളെ തരംതിരിക്കുകയും, മോഡലുകളെ ശരിയായ രീതിയിൽ ഉപയോഗിക്കുകയും, കാഷിംഗ് കാര്യക്ഷമമാക്കുകയും, പ്രോംപ്റ്റുകൾ ചുരുക്കുകയും, ബാക്ക്ഗ്രൗണ്ട് ജോലികൾ batch ചെയ്യുകയും ചെയ്യുന്ന ഒരു കൃത്യമായ routing layer ഉപയോഗിക്കുന്നതിലൂടെ, വിശ്വാസ്യത നിലനിർത്തിക്കൊണ്ടുതന്നെ AI-API ചിലവ് 95% വരെ കുറയ്ക്കാം. inference stack-നെ ഒരു പ്രൊഡക്ഷൻ സർവീസിനെപ്പോലെ കാണുക: ടയറുകൾ നിശ്ചയിക്കുക, ഫലങ്ങൾ അളക്കുക, ഓരോ ആഴ്ചയും പരിഷ്കരിക്കുക.