நீங்கள் பெரிய மொழி மாதிரிகளில் (LLM) உற்பத்திப் பணிகளை (production workloads) நடத்துகிறீர்கள் என்றால், மாதிரியின் செயல்திறன் என்பது பாதிப் போராட்டம் மட்டுமே என்பது உங்களுக்குத் தெரியும். மற்ற பாதிப் போராட்டம் மாத இறுதியில் வரும் பில் (bill) ஆகும். Mancer 2, Novita மற்றும் StreamLake ஆகிய மூன்று நிறுவனங்களும் சமீபத்தில் அவற்றின் மாதிரி விலைகளை மாற்றியமைத்துள்ளன. நீங்கள் இந்த API-களில் ஏதேனும் ஒன்றைப் பயன்படுத்துகிறீர்கள் என்றால், உங்கள் அடுத்த இன்வாய்ஸ் (invoice) முந்தையதை விட வித்தியாசமாக இருக்கலாம்.
இது இப்போது வழக்கமான ஒன்றாக மாறிவிட்டது. LLM சந்தையானது inference-களுக்கு எவ்வாறு கட்டணம் வசூலிப்பது என்பதில் இன்னும் பரிசோதனைகளிலேயே உள்ளது. சில நிறுவனங்கள் ஆயிரம் டோக்கன்களுக்கு ஒருமுறை கட்டணம் வசூலிக்கின்றன. மற்றவை கோரிக்கைகளை (requests) பல்வேறு நிலைகளாகப் (tiers) பிரிக்கின்றன அல்லது தொடர்ச்சியான பயன்பாட்டிற்கான தள்ளுபடிகளை (sustained-use discounts) வழங்குகின்றன. ஒரு தளம் தனது யூனிட் விலையை மாற்றும்போதோ அல்லது அதன் நிலைகளை மறுசீரமைக்கும்போதோ, உங்கள் பட்ஜெட்டில் ஏற்படும் தாக்கம் ஒரு சிறிய எரிச்சலில் இருந்து ஒரு பெரிய செலவு அதிகரிப்பு வரை இருக்கலாம். இந்த மாற்றங்களைக் கண்காணிப்பது விருப்பத்தேர்வு அல்ல; அது வேலையின் ஒரு பகுதியாகும்.
API விலையளிப்பு ஏன் உங்கள் கவனத்திற்குத் தேவைப்படுகிறது
டெவலப்பர்கள் பெரும்பாலும் API விலையளிப்பை ஒருமுறை அமைத்துவிட்டு மறந்துவிட வேண்டிய ஒரு விஷயமாகவே கருதுகிறார்கள். நீங்கள் ஒரு மாதிரியை பெஞ்ச்மார்க் (benchmark) செய்து, ஒரு நிறுவனத்தைத் தேர்ந்தெடுத்துவிட்டு, அம்சங்களை உருவாக்குவதில் கவனம் செலுத்துகிறீர்கள். அது வேலை செய்யும் வரைதான். தற்போதைய சூழலில், விலையில் மாற்றங்கள் எந்தவித முன்னறிவிப்பும் இன்றி நடக்கலாம். ஒரு நிறுவனம் தனது பழைய மாதிரியின் விலையைக் குறைக்கலாம், அதே சமயம் அதன் புதிய எண்ட்பாயிண்டின் (endpoint) விலையை உயர்த்தலாம். மற்றொரு நிறுவனம் கடந்த காலாண்டில் இல்லாத அவுட்புட்-டோக்கன் (output-token) கூடுதல் கட்டணங்களை அறிமுகப்படுத்தலாம். நீங்கள் கவனித்துக் கொண்டிருக்கவில்லை என்றால், உங்கள் கிளவுட் பில் (cloud bill) வரும்போதுதான் அதைத் தெரிந்துகொள்வீர்கள்.
LLM பில்லிங் முறையின் நுணுக்கமான தன்மை (granularity) இதை மிகவும் சிக்கலானதாக மாற்றுகிறது. நீங்கள் அரிதாகவே ஒரு நிலையான மாதாந்திர கட்டணத்தைச் செலுத்துகிறீர்கள். நீங்கள் ஒவ்வொரு ப்ராம்ப்ட் டோக்கனுக்கும் (prompt token) மற்றும் ஒவ்வொரு கம்ப்ளீஷன் டோக்கனுக்கும் (completion token) பணம் செலுத்துகிறீர்கள். அவுட்புட் பக்கத்தில் விலை உயர்வு ஏற்பட்டால், அது இன்புட் பக்கத்தை விட அதிக பாதிப்பை ஏற்படுத்தலாம், ஏனெனில் கம்ப்ளீஷன்கள் பெரும்பாலும் ப்ராம்ப்ட்களை விட நீளமாக இருக்கும். உங்கள் பயன்பாடு நீண்ட வடிவிலான உரை, குறியீடு (code) அல்லது பல படிநிலைகளைக் கொண்ட சிந்தனைச் சங்கிலிகளை (reasoning chains) உருவாக்குகிறது என்றால், ஒரு டோக்கனுக்கான சிறிய விலை உயர்வு மிக வேகமாகப் பெருகும்.
'டிரிஃப்ட்' (drift) என்ற சிக்கலும் உள்ளது. காலப்போக்கில் உங்கள் பயன்பாட்டின் டோக்கன் பயன்பாட்டு முறை (token profile) மாறும். அதிக இன்புட் டோக்கன்களைப் பயன்படுத்தும் ஒரு புதிய சிஸ்டம் ப்ராம்ப்ட்டை (system prompt) நீங்கள் சேர்க்கலாம். அல்லது நீண்ட அவுட்புட்களை உருவாக்கும் chain-of-thought prompting முறைக்கு மாறலாம். நிறுவனங்களின் விலைகள் மாறாமல் இருந்தாலும், உங்கள் செலவுகள் மாறும். நிறுவனங்களின் விலைகளும் ஒரே நேரத்தில் மாறும்போது, சரியான விழிப்புணர்வு இல்லாத ஒரு குழுவிற்கு இது பெரும் பாதிப்பை ஏற்படுத்தும்.
என்ன மாறியுள்ளது
Mancer 2, Novita மற்றும் StreamLake ஆகிய மூன்றும் விலையில் மாற்றங்களைச் செய்துள்ளன. விவரங்கள் ஒவ்வொரு தளத்திற்கும் மாறுபடும், ஆனால் திசை ஒன்றுதான்: கடந்த மாதம் நீங்கள் பயன்படுத்திய கட்டணக் கட்டமைப்பு இப்போது நடைமுறையில் இல்லாமல் இருக்கலாம்.
Mancer 2 தனது மாதிரி விலையை மாற்றியமைத்துள்ளது, இதன் பொருள் அதன் எண்ட்பாயிண்டுகளைப் பயன்படுத்தும் டெவலப்பர்கள் தங்கள் கோரிக்கைக்கான (per-request) செலவுகளை மீண்டும் மதிப்பீடு செய்ய வேண்டும். உங்கள் உள் ஆவணங்களில் பழைய விலை பட்டியல்களைச் சேமித்து வைத்திருந்தால், அந்த எண்கள் இப்போது செல்லாது.
Novita தனது சேவைகளிலும் விலையில் மாற்றங்களைச் செய்துள்ளது. ஒரு குறிப்பிட்ட பட்ஜெட்டிற்குள் செயல்பட Novita-வைத் தேர்ந்தெடுத்த குழுக்களுக்கு, புதிய விகிதங்கள் தற்போதைய திட்டங்களின் மொத்தச் செலவை (total cost of ownership) மாற்றக்கூடும்.
StreamLake-உம் தனது விலையை மாற்றியுள்ளது. StreamLake-ன் முந்தைய விலை அட்டவணையை அடிப்படையாகக் கொண்டு உருவாக்கப்பட்ட எந்தவொரு ஒருங்கிணைப்பும் (integration), அடுத்த பில்லிங் சுழற்சி தொடங்குவதற்கு முன் மறுஆய்வு செய்யப்பட வேண்டும்.
இவை மூன்று வெவ்வேறு தளங்கள் மற்றும் மூன்று வெவ்வேறு விலைக் கொள்கைகளைக் கொண்டிருப்பதால், நீங்கள் அதிகமாகச் செலுத்துவீர்களா அல்லது குறைவாகச் செலுத்துவீர்களா என்பதற்கு எந்த ஒரு பொதுவான விதியும் இல்லை. ஒரு நிறுவனம் ஆரம்ப நிலை (starter-tier) விலைகளைக் குறைத்துவிட்டு, பிரீமியம்த் திறன் (premium throughput) விலையை உயர்த்தியிருக்கலாம். மற்றொரு நிறுவனம் கான்டெக்ஸ்ட்-விண்டோ (context-window) பிரீமியங்களை மாற்றியிருக்கலாம். உங்கள் பழைய ஸ்ப்ரெட்ஷீட் (spreadsheet) தவறானது என்பதே ஒரே பாதுகாப்பான அனுமானம்.
விலை மாற்றங்களைப் புறக்கணிப்பதன் மறைமுகச் செலவுகள்
இது நடைமுறையில் உண்மையில் என்ன அர்த்தம் என்று பார்ப்போம். ஒரு நாளைக்கு பத்தாயிரம் உரையாடல்களைக் கையாளும் ஒரு வாடிக்கையாளர் ஆதரவு உதவியாளரை (customer-support assistant) நீங்கள் இயக்குகிறீர்கள் என்று வைத்துக்கொள்வோம். ஒவ்வொரு பரிமாற்றமும் சராசரியாக இரண்டாயிரம் இன்புட் டோக்கன்களையும் நானூறு அவுட்புட் டோக்கன்களையும் கொண்டுள்ளது. ஒரு மில்லியன் டோக்கன்களுக்கு சில சென்ட்கள் மாற்றம் ஏற்பட்டாலும், அது மாதத்திற்கு நூற்றுக்கணக்கான டாலர்களைச் சேர்க்கும். விலை மாற்றம் அவுட்புட் டோக்கன்களைப் பாதிக்கிறது மற்றும் நீங்கள் மாதிரியை மேம்படுத்தியதால் உங்கள் உதவியாளர் நீண்ட பதில்களை உருவாக்கத் தொடங்கினால், நீங்கள் இரண்டு முறை பாதிக்கப்படுவீர்கள்.
பிறகு 'மல்டிப்ளையர் எஃபெக்ட்' (multiplier effect) உள்ளது. பல பயன்பாடுகள் ஒரு பயனர் கோரிக்கைக்கு ஒருமுறை மட்டும் LLM-ஐ அழைக்காது. அவை ஒரு லூப்பில் (loop), அல்லது மீட்டெடுப்புப் படிகங்களுடன் (retrieval steps) கூடிய ஒரு குழாயில் (pipeline), அல்லது மாற்று மாதிரிகளுக்கான (fallback models) வழிமுறைகளுடன் அழைக்கின்றன. உங்கள் முதன்மை மாதிரி ரேட் லிமிட்டை (rate limit) எட்டும்போது, நீங்கள் எதிர்பாராத ஒரு சூழலில் அதிக விலையுள்ள பேக்கப் மாதிரியைப் பயன்படுத்திச் செலவழிக்கும் வரை, மாற்று மாதிரியின் விலை மாற்றம் அவசரமானது என்று தோன்றாது.
பட்ஜெட் அதிகரிப்பு மட்டுமே ஆபத்து அல்ல. விலைகள் குறைந்தால் நீங்கள் அதை கவனிக்கவில்லை என்றால், தேவையற்ற முறையில் பயன்பாட்டைக் குறைக்கக்கூடும் (throttling). நீங்கள் அதிக பயனர்களுக்குச் சேவை செய்திருக்கலாம், பெரிய ஆவணங்களைக் கையாண்டிருக்கலாம் அல்லது உங்கள் வாடிக்கையாளர்களுக்கு விலையைக் குறைத்திருக்கலாம். அறியாமை இருபுறமும் வேலை செய்யும்.
செலவு கண்காணிப்புப் பழக்கத்தை எவ்வாறு உருவாக்குவது
இதைக் கண்காணிக்க உங்களுக்கு ஒரு பெரிய நிறுவன நிதித் குழு தேவையில்லை. உங்களுக்கு ஒரு வழக்கமும், மாற்றங்களைப் பதிவு செய்ய ஒரு இடமும் தேவை.
முதலில் உங்கள் கட்டண அட்டவணைகளை (rate cards) மையப்படுத்துவதன் மூலம் தொடங்குங்கள். ஒரு எளிய ஆவணத்தைப் பராமரிக்கவும்—அது ஒரு பகிரப்பட்ட விக்கி பக்கம் (wiki page), ஒரு Notion அட்டவணை அல்லது உங்கள் டெவ் (dev) சேனலில் பின் செய்யப்பட்ட செய்தியாக இருக்கலாம்—அதில் நீங்கள் பயன்படுத்தும் ஒவ்வொரு மாடலுக்கான தற்போதைய டோக்கன் அல்லது கோரிக்கை (per-request) விலையைப் பட்டியலிடுங்கள். ஒரு சேவை வழங்குநர் மாற்றத்தை அறிவிக்கும்போது, உடனடியாக ஆவணத்தைப் புதுப்பிக்கவும். ஸ்பிரிண்ட் ரிவியூ (sprint review) வரை காத்திருக்க வேண்டாம்.
அடுத்து, உங்கள் பயன்பாட்டை வழங்குநர் மற்றும் மாடல் வாரியாகக் குறியிடுங்கள் (tag). பெரும்பாலான கண்காணிப்பு கருவிகள் (observability tools) API அழைப்புகளுடன் தனிப்பயன் மெட்டாடேட்டாவை (custom metadata) இணைக்க அனுமதிக்கின்றன. வாராந்திர செலவுச் சுருக்கங்களை உருவாக்க அந்த டேக்குகளைப் பயன்படுத்தவும். ஒரு திடீர் உயர்வைக் கண்டால், அதைச் சில நாட்களில் அல்லாமல், சில நொடிகளிலேயே பயன்பாட்டு அதிகரிப்பு அல்லது கட்டண மாற்றத்தைக் கொண்டு கண்டறிய முடியும்.
ஒரு செலவு விகித எச்சரிக்கையை (burn-rate alert) உருவாக்குங்கள். இது மிகவும் சிக்கலானதாக இருக்க வேண்டிய அவசியமில்லை. உங்கள் பயன்பாட்டு டேஷ்போர்டை (usage dashboard) ஆய்வு செய்து, ஒவ்வொரு காலையிலும் Slack-இல் ஒரு எண்ணைப் பதிவிடும் ஒரு திட்டமிடப்பட்ட ஸ்கிரிப்ட் (scheduled script) போதுமானது. அந்த எண் உயரும்போது, நிதித் துறை ஒரு கோபமான மின்னஞ்சலை அனுப்பும் முப்பது நாட்களுக்குப் பிறகு தெரியாமல், அன்றே உங்களுக்குத் தெரிந்துவிடும்.
உங்கள் மாடல் தேர்வுகளை காலாண்டுக்கு ஒருமுறை மதிப்பாய்வு செய்யுங்கள். ஜனவரியில் உங்கள் பயன்பாட்டிற்குச் சிறந்த மாடல், ஜூன் மாதத்தில் சிறந்ததாக இருக்க வேண்டிய அவசியமில்லை; அது மாடல் மோசமடைந்ததாலோ அல்லது விலை நிர்ணய சூழல் மாறியதாலோ இருக்கலாம். ஒரு காலத்தில் அதிக விலையிருந்த ஒரு சேவை வழங்குநர் விலையைக் குறைத்திருக்கலாம். மலிவான ஒரு மாடல் விலையை உயர்த்தியிருக்கலாம். வரலாற்று விலைகளை வைத்துப் பார்க்காமல், நேரடி விலைகளைக் கொண்டு உங்கள் பெஞ்ச்மார்க்குகளை (benchmarks) மீண்டும் இயக்கவும்.
இறுதியாக, உங்கள் கட்டமைப்பு முடிவுகளில் (architecture decisions) விலையைக் கணக்கில் கொள்ளுங்கள். ஒரு சேவை வழங்குநர் அடிக்கடி விலையை மாற்றுகிறார் என்று உங்களுக்குத் தெரிந்தால், உங்கள் கோட்பேஸின் (codebase) பாதியை மீண்டும் எழுதாமல் எண்ட் பாயிண்ட்களை (endpoints) மாற்றும் வகையில் உங்கள் அமைப்பை வடிவமைக்கவும். கிளையண்ட்டை (client) ஒரு உள்முக இடைமுகத்திற்குப் (internal interface) பின்னால் மறைத்து வைக்கவும். மாடல் பெயரை ஒரு கான்ஃபிகரேஷன் கோப்பில் (configuration file) வைத்திருங்கள், உங்கள் பிராம்ப்ட் லேயரில் (prompt layer) நேரடியாகக் குறியிட வேண்டாம் (hard-coded).
நம்பகமான தகவல்களை எங்கு பெறுவது
சேவை வழங்குநர்களின் வலைப்பதிவுகள் (blogs) மற்றும் ஆவணங்கள் (documentation) அதிகாரப்பூர்வ ஆதாரங்கள், ஆனால் ஒரு பரபரப்பான வாரத்தில் அவற்றை எளிதில் கவனிக்கத் தவறிவிடலாம். இந்த வகையான மாற்றங்களைச் சூழல் முழுவதும் கண்காணிக்கும் தொகுப்புகளைப் (curated roundups) பின்பற்றுவது ஒரு சிறந்த விருப்பமாகும். சமீபத்திய Mancer 2, Novita மற்றும் StreamLake மாற்றங்களின் முழுமையான விவரங்களுக்கு, இங்கே உள்ள விரிவான சுருக்கத்தைப் பார்க்கவும்:
Changes to LLM Pricing: Mancer 2, Novita, and StreamLake
நீங்கள் இந்தத் தகவல்களுடன் இணைந்து இருக்க விரும்பினால் மற்றும் தங்கள் AI உள்கட்டமைப்பு (infrastructure) செலவுகளைக் கட்டுப்படுத்த முயற்சிக்கும் பிற உருவாக்குநர்களுடன் கருத்துக்களைப் பகிர்ந்து கொள்ள விரும்பினால், இணையும் ஒரு சமூகமும் உள்ளது:
எதிர்பாராத பில்களைத் தடுப்பதற்கான சிறந்த வழி, மாற்றங்கள் நிகழும்போதே அவற்றைச் சுட்டிக்காட்டும் நபர்களின் ஒரு வலையமைப்பாகும்.
உண்மையான கருத்து
விலை ஏற்ற இறக்கங்கள் என்பது தற்போதைய LLM சந்தையின் ஒரு அம்சம், அது ஒரு குறைபாடு அல்ல. மாடல்களை இயக்குவது மலிவாகிறது, வழங்குநர்கள் கட்டண அமைப்புகளில் சோதனைகளைச் செய்கிறார்கள் மற்றும் போட்டி விலைகளை மாற்றியமைக்கிறது. இது நீண்ட கால அடிப்படையில் நல்ல செய்திதான், ஆனால் நீங்கள் கவனித்துக் கொண்டிருந்தால் மட்டுமே அது பயனுள்ளதாக இருக்கும். உங்கள் API செலவுகளை உங்கள் அப்டைம் அளவீடுகளைப் (uptime metrics) போலவே நடத்துங்கள்: அவற்றை அளவிடுங்கள், எச்சரிக்கைகளை அமைக்கவும் மற்றும் அவ்வப்போது கேள்வி எழுப்பவும். Mancer 2, Novita மற்றும் StreamLake ஆகியவற்றின் சமீபத்திய மாற்றங்கள், உங்கள் AI ஸ்டேக்கின் (AI stack) விலை ஒருபோதும் நிலையானது அல்ல என்பதற்கான சமீபத்திய நினைவூட்டல் மட்டுமே.