നിങ്ങൾ ലാർജ് ലാംഗ്വേജ് മോഡലുകൾ (large language models) ഉപയോഗിച്ച് ഒരു ഉൽപ്പന്നം വിപണിയിലിറക്കുകയാണെങ്കിൽ, നിങ്ങളുടെ ലാഭവിഹിതം (margin) നിങ്ങളുടെ സേവനദാതാവിന്റെ നിരക്കുകളെ (rate card) ആശ്രയിച്ചിരിക്കും. Novita-യും StreamLake-യും അടുത്തിടെ അവരുടെ മോഡൽ നിരക്കുകളിൽ മാറ്റം വരുത്തിയിട്ടുണ്ട്, അതിന്റെ അർത്ഥം നിങ്ങൾ ശ്രദ്ധിച്ചാലും ഇല്ലെങ്കിലും നിങ്ങളുടെ യൂണിറ്റ് ഇക്കണോമിക്സിൽ (unit economics) മാറ്റം വന്നിരിക്കുന്നു എന്നാണ്. ഇവ സാധാരണയായി കാണുന്ന മെയിന്റനൻസ് കാലയളവുകളല്ല. ഇൻഫറൻസ് പ്രൊവൈഡർമാർ അവരുടെ പെർ-ടോക്കൺ (per-token) നിരക്കുകളിൽ മാറ്റം വരുത്തുമ്പോൾ, ഒരു സപ്പോർട്ട് ടിക്കറ്റ് തരംതിരിക്കാനോ, ഒരു ഡോക്യുമെന്റ് സംഗ്രഹിക്കാനോ (summarize), അല്ലെങ്കിൽ ഒരു കോഡ് നിർദ്ദേശം (code suggestion) നൽകാനോ ഉള്ള ചിലവ് ഒറ്റരാത്രികൊണ്ട് മാറുന്നു. API നിരക്കുകളെ മാറ്റമില്ലാത്ത ഒന്നായി കാണുന്ന ഡെവലപ്പർമാർക്ക്, അവരുടെ പ്രതിമാസ ബില്ല് ലഭിക്കുമ്പോൾ മാത്രമായിരിക്കും ഈ പ്രശ്നം തിരിച്ചറിയാൻ സാധിക്കുന്നത്.
നിശബ്ദമായ വിലമാറ്റം എങ്ങനെ ഒരു ബജറ്റ് തകർക്കാം
മിക്ക എഞ്ചിനീയറിംഗ് ടീമുകളും ഒരു ഇൻഫറൻസ് പ്രൊവൈഡറെ തിരഞ്ഞെടുക്കുന്നു, കുറച്ച് ലേറ്റൻസി ബെഞ്ച്മാർക്കുകൾ (latency benchmarks) നടത്തുന്നു, തുടർന്ന് ജോലി തുടരുന്നു. പ്രോംപ്റ്റ് ടെംപ്ലേറ്റുകൾ വെർഷൻ കൺട്രോളിലേക്ക് (version control) മാറ്റുന്നു, ക്ലയന്റ് കോഡ് പ്രൊഡക്ഷനിലേക്ക് പോകുന്നു, ഫിനാൻസ് ടീമിന് ഒരു ഏകദേശ പ്രതിമാസ കണക്ക് ലഭിക്കുന്നു. ഈ രീതി ഒരു പരിധിവരെ പ്രവർത്തിക്കും, എന്നാൽ എപ്പോഴെങ്കിലും അത് തകരാം. ടോക്കണുകൾ ഉപയോഗിച്ചു തീർക്കാവുന്ന ഒരു വിഭവമാണ് (consumable resource). ഉപയോക്താക്കളുടെ എണ്ണം, കോൺടെക്സ്റ്റ് ദൈർഘ്യം (context length), റീട്രൈ ബിഹേവിയർ (retry behavior) എന്നിവയ്ക്കനുസരിച്ച് നിങ്ങളുടെ ബില്ലും വർദ്ധിക്കുന്നു. ഒരു സ്പ്രെഡ്ഷീറ്റിൽ നിസ്സാരമായി തോന്നുന്ന നിരക്ക് വർദ്ധനവ്, ഉയർന്ന അളവിൽ ഉപയോഗിക്കുന്ന ഒരു ഫീച്ചറിന്റെ ലാഭവിഹിതം ഇല്ലാതാക്കിയേക്കാം.
ഇതിന്റെ ആഘാതം നിങ്ങളുടെ ഉപയോഗ രീതിയെ (usage shape) ആശ്രയിച്ചിരിക്കും. ചെറിയ ക്ലാസിഫിക്കേഷൻ പ്രോംപ്റ്റുകൾ അയക്കുന്ന ഒരു ടീമിന് കാര്യമായ മാറ്റങ്ങളില്ലാതെ തന്നെ വില വ്യത്യാസം ഉൾക്കൊള്ളാൻ കഴിഞ്ഞേക്കാം. എന്നാൽ വലിയ കോൺടെക്സ്റ്റ് വിൻഡോകൾ പ്രോസസ്സ് ചെയ്യുന്നതോ ആയിരക്കണക്കിന് പേജുകളിലായി ബാച്ച് ജോബുകൾ നടത്തുന്നതോ ആയ ഒരു ടീമിന് അവരുടെ ചിലവ് (burn rate) പെട്ടെന്ന് വർദ്ധിക്കുന്നത് കാണേണ്ടി വന്നേക്കാം. നിങ്ങളുടെ ശരാശരി കോൾ ഇരുന്നൂറ് ടോക്കണുകളാണോ അതോ ഇരുപതിനായിരം ടോക്കണുകളാണോ എന്നതിനെ ആശ്രയിച്ച് ഒരേ ശതമാനത്തിലുള്ള മാറ്റം പോലും വ്യത്യസ്തമായ ആഘാതം ഉണ്ടാക്കും. അതുകൊണ്ടാണ് Novita-യുടെയും StreamLake-യുടെയും അപ്ഡേറ്റുകൾ സൂക്ഷ്മമായി പരിശോധിക്കേണ്ടത് എന്ന് പറയുന്നത്. ഉപയോക്താവിനായുള്ള നിങ്ങളുടെ ശരാശരി ചിലവ് മുൻകൂട്ടി നിശ്ചയിച്ച കണക്കുകളിൽ നിന്ന് വ്യതിചലിച്ചിട്ടുണ്ടോ എന്നും, ട്രാഫിക് റീറൂട്ട് (reroute) ചെയ്യേണ്ട സമയമായോ എന്നും നിങ്ങൾ അറിയേണ്ടതുണ്ട്.
Novita-യുടെ പ്രൈസിംഗ് അപ്ഡേറ്റ്
Novita അടുത്തിടെ അവരുടെ മോഡൽ നിരക്കുകളിൽ മാറ്റം വരുത്തിയിട്ടുണ്ട്. ഈ പ്ലാറ്റ്ഫോം വിവിധ ഭാഷാ മോഡലുകൾ ലഭ്യമാക്കുന്നു, അതിനാൽ ഇതിൽ വരുന്ന ഏതൊരു മാറ്റവും പ്രൈമറി ഇൻഫറൻസ് ലെയറായി (primary inference layer) ഇത് ഉപയോഗിക്കുന്ന ടീമുകളുടെ പ്രവർത്തന ചിലവുകളെ നേരിട്ട് ബാധിക്കും. Novita ഒന്നിലധികം മോഡലുകൾ ഹോസ്റ്റ് ചെയ്യുന്നതിനാൽ, ഈ മാറ്റം എല്ലാ മോഡലുകൾക്കും ഒരുപോലെയാകണമെന്നില്ല. ഒരു വിഭാഗം മോഡലുകളുടെ നിരക്ക് മാറ്റമില്ലാതെ തുടരുമ്പോൾ മറ്റൊന്നിന് മാറ്റം വന്നേക്കാം. ഒരു പൊതുവായ അറിയിപ്പ് നൽകുന്നതിനേക്കാൾ ഈ സൂക്ഷ്മമായ വ്യത്യാസങ്ങൾ ശ്രദ്ധിക്കുന്നത് പ്രധാനമാണ്.
നിങ്ങൾ എല്ലാ ട്രാഫിക്കും ഒരു സിംഗിൾ മോഡൽ ഐഡി (model ID) വഴി റൂട്ട് ചെയ്യുന്നുണ്ടെങ്കിൽ, നിങ്ങളുടെ പുതിയ ചിലവ് കണക്കാക്കുന്നത് എളുപ്പമാണ്. എന്നാൽ സങ്കീർണ്ണമായ പ്രോംപ്റ്റുകൾ വലിയ മോഡലുകളിലേക്കും ലളിതമായവ ചെറിയ മോഡലുകളിലേക്കും റൂട്ട് ചെയ്തുകൊണ്ട് Novita-യുടെ കാറ്റലോഗ് ഡൈനാമിക് ആയി ഉപയോഗിക്കുന്നുണ്ടെങ്കിൽ, ഒരു അലേർട്ട് പോലും തിരിച്ചറിയാൻ കഴിയാത്ത രീതിയിൽ നിങ്ങളുടെ ശരാശരി ചിലവ് വ്യതിചലിച്ചിട്ടുണ്ടാകാം. ഇത് അറിയാനുള്ള ഏക വഴി നിങ്ങളുടെ ഉപയോഗ ലോഗുകൾ (usage logs) എടുത്ത്, അവയെ മോഡലുകൾ തിരിച്ച്, യഥാർത്ഥ ടോക്കൺ എണ്ണത്തെ പുതിയ നിരക്കുമായി ഗുണിക്കുക എന്നതാണ്. ഒരു ദശലക്ഷം ടോക്കണുകൾക്ക് മുൻപ് എത്രയായിരുന്നു എന്ന കാര്യത്തിൽ നിങ്ങളുടെ ഓർമ്മയെ മാത്രം ആശ്രയിക്കരുത്. അത് എഴുതി വെക്കുക. ഒരു ഹിസ്റ്റോറിക്കൽ റെക്കോർഡ് സൂക്ഷിക്കുക. അടുത്ത മാറ്റം നിങ്ങളെ അപ്രതീക്ഷിതമായി ബാധിക്കാതിരിക്കാൻ ഇത് നിങ്ങളുടെ ക്വാർട്ടർലി റിവ്യൂ സൈക്കിളിന്റെ (quarterly review cycle) ഭാഗമാക്കുക.
StreamLake-യുടെ പ്രൈസിംഗ് അപ്ഡേറ്റ്
StreamLake-യും അവരുടെ മോഡലുകളുടെ നിരക്കിൽ മാറ്റം വരുത്തിയിട്ടുണ്ട്. ഇതിന്റെ സ്റ്റാക്കുമായി (stack) ബന്ധിപ്പിച്ചിട്ടുള്ള ടീമുകളെ സംബന്ധിച്ചിടത്തോളം, ടോക്കൺ നിരക്കിലെ ഏതൊരു മാറ്റവും കണ്ടന്റ് അനാലിസിസ് (content analysis), ട്രാൻസ്ക്രിപ്ഷൻ ബാക്കെൻഡുകൾ (transcription back-ends), ജനറേറ്റീവ് ഫീച്ചറുകൾ (generative features) അല്ലെങ്കിൽ പ്ലാറ്റ്ഫോമിലൂടെ പ്രവർത്തിക്കുന്ന മറ്റേതെങ്കിലും ലാംഗ്വേജ് വർക്ക്ലോഡുകളുടെ കണക്കുകളെ മാറ്റുന്നു. നിരക്കിലെ മാറ്റത്തിന്റെ വലുപ്പത്തേക്കാൾ ഉപരിയായി അതിന്റെ ആകെത്തുകയിലുണ്ടാകുന്ന ആഘാതമാണ് (compounding effect) പ്രധാനം. ഒന്നിലധികം എൻവയോൺമെന്റുകളിൽ ദിവസവും ദശലക്ഷക്കണക്കിന് ടോക്കണുകൾ പ്രോസസ്സ് ചെയ്യുമ്പോൾ, ചെറിയൊരു പെർ-ടോക്കൺ വർദ്ധനവ് പോലും വലിയൊരു തുകയായി മാറും.
യഥാർത്ഥ ചോദ്യം പുതിയ വില എത്രയാണ് എന്നതല്ല, മറിച്ച് ആ പുതിയ വില ഓരോ ഫീച്ചറിന്റെയും ഗ്രോസ് മാർജിനെ (gross margin) എങ്ങനെ ബാധിക്കുന്നു എന്നതാണ്. StreamLake ഒരു കസ്റ്റമർ ഫേസിംഗ് സമ്മറൈസേഷൻ ടൂളിനോ (summarization tool) അല്ലെങ്കിൽ ഒരു ഇന്റേണൽ മോഡറേഷൻ ലെയറിനോ (internal moderation layer) ആണ് പവർ നൽകുന്നതെങ്കിൽ, നിങ്ങളുടെ കോസ്റ്റ് ഓഫ് ഗുഡ്സ് സോൾഡ് (cost of goods sold) ഇപ്പോൾ മാറിയിരിക്കുന്നു. നിങ്ങളുടെ ഒബ്സർവബിലിറ്റി ടൂളിംഗിൽ (observability tooling) ഈ ചിലവ് വ്യക്തമായി വേർതിരിച്ചു കാണിക്കണം. ഇൻവോയ്സ് ലഭിക്കുമ്പോൾ കൃത്യമായി വിഭജിക്കാൻ സാധിക്കുന്നതിനായി, പ്രൊവൈഡർ അനുസരിച്ചും ഫീച്ചർ അനുസരിച്ചും ആ API കോളുകൾ ടാഗ് ചെയ്യുക. ഏതെങ്കിലും ഒരു ഉപയോഗം ലാഭകരമല്ലാതാകുകയാണെങ്കിൽ, അത് നിയന്ത്രിക്കണോ (throttle), ചെറിയ മോഡലിലേക്ക് ഡൗൺഗ്രേഡ് ചെയ്യണോ, അതോ ഒരു സ്ട്രാറ്റജിക് കോസ്റ്റായി (strategic cost) സ്വീകരിക്കണോ എന്ന് തീരുമാനിക്കാൻ നിങ്ങൾക്ക് കൃത്യമായ ഡാറ്റ ആവശ്യമാണ്.
നിങ്ങളുടെ ഇൻഫറൻസ് ചിലവ് എങ്ങനെ ഓഡിറ്റ് ചെയ്യാം
സ്വീകരിക്കുന്നത്