அம்ச வெளியீடுகளை விட, அமைதியான உள்கட்டமைப்பு மாற்றங்கள் மென்பொருள் வரவு செலவுத் திட்டங்களை மிக வேகமாக மாற்றியமைக்கின்றன. StreamLake போன்ற ஒரு தளம் தனது LLM விலை நிர்ணயத்தை மாற்றியமைக்கும் போது, அதன் தாக்கம் ஒவ்வொரு API அழைப்பு, ஒவ்வொரு பின்னணி பணி மற்றும் அந்த மாதிரிகளைச் சார்ந்திருக்கும் ஒவ்வொரு பயனர் சார்ந்த அரட்டை இடைமுகம் ஆகியவற்றின் வழியாகவும் பரவுகிறது. நீங்கள் StreamLake-இல் கட்டமைப்பவராக இருந்தால், இப்போது உங்கள் பயன்பாட்டுத் தரவுப் பலகைகளை (usage dashboards) ஆய்வு செய்து, உங்கள் டோக்கன்கள் எங்கு செலவிடப்படுகின்றன என்பதை உற்றுநோக்க வேண்டிய நேரம் இது. StreamLake-இன் சமீபத்திய விலை புதுப்பிப்பு, வெவ்வேறு மாதிரிகள் எவ்வாறு கட்டணம் வசூலிக்கப்படுகின்றன என்பதை நேரடியாகப் பாதிக்கிறது. இதன் பொருள், உங்கள் தற்போதைய தொழில்நுட்ப அடுக்கு (stack) கடந்த மாதத்தை விட அதிக செலவை ஏற்படுத்தலாம், அல்லது சில விலைகள் உங்களுக்குச் சாதகமாக மாறியிருந்தால், உங்கள் பயன்பாட்டை விரிவுபடுத்துவதற்கான வாய்ப்பையும் இது திறக்கலாம்.

ஏன் தளத்தின் விலை மாற்றங்கள் முக்கியத்துவம் வாய்ந்தவை

StreamLake உங்கள் பயன்பாட்டிற்கும் வளர்ந்து வரும் பெரிய மொழி மாதிரிகளின் (large language models) தொகுப்பிற்கும் இடையில் ஒரு அடுக்காகச் செயல்படுகிறது. நீங்கள் GPT-4, Claude, Llama அல்லது திறந்த எடை கொண்ட (open-weight) மற்றும் தனியுரிம மாதிரிகளின் (proprietary models) கலவையை ஒரு ஒற்றை endpoint மூலம் அழைக்கலாம். அந்த வசதி மிகவும் சக்தி வாய்ந்தது, ஆனால் நீங்கள் நேரடியாக மூல வழங்குநருக்கு (raw provider) பணம் செலுத்தவில்லை என்பதையும் இது குறிக்கிறது. உங்கள் அலகுப் பொருளாதாரத்தை (unit economics) தீர்மானிக்கும் விகிதங்களை StreamLake நிர்ணயிக்கிறது. அந்த விகிதங்கள் மாறும்போது, ஒரு வாடிக்கையாளர் சேவை பாட் (customer support bot), ஒரு உள்ளடக்க உருவாக்கப் பாதை (content generation pipeline) அல்லது ஒரு குறியீடு ஆய்வு உதவியாளரின் (code review assistant) செலவு ஒரே இரவில் மாறிவிடும்.

பல குழுக்கள் விலை புதுப்பிப்புகளை வெறும் தேவையற்ற தகவலாகவே கருதுகின்றன. மாதாந்திரப் பட்டியல் வரும்போது மட்டுமே அவர்கள் அதை கவனிக்கிறார்கள். புதிய வழங்குநர் ஒப்பந்தங்கள், inference மேம்படுத்தலில் ஏற்படும் மாற்றங்கள் அல்லது தளம் சில மாதிரிகளை எவ்வாறு முன்னிலைப்படுத்த விரும்புகிறது என்பதன் அடிப்படையில் மாதிரிச் செலவுகள் மாறக்கூடிய ஒரு சந்தையில், இது ஒரு ஆபத்தான பழக்கமாகும். StreamLake-இல் ஒரு விலை மாற்றம் என்பது வெறும் பரிவர்த்தனை சரிசெய்தல் மட்டுமல்ல. அது உங்கள் கட்டமைப்பு முடிவுகளை (architecture decisions) மறுபரிசீலனை செய்வதற்கான ஒரு சமிக்ஞையாகும்.

StreamLake புதுப்பிப்புகள் பற்றி நாம் அறிவது என்ன

StreamLake தனது பயன்பாட்டில் உள்ள மாதிரிகளுக்கு விலை நிர்ணயம் செய்யும் முறையில் மாற்றங்களைக் கொண்டு வந்துள்ளது. துல்லியமான புதிய விகிதங்கள், நடைமுறைக்கு வரும் தேதிகள் மற்றும் ஏதேனும் முந்தைய நிபந்தனைகளைப் பாதுகாக்கும் கொள்கைகள் (grandfathering policies) ஆகியவை StreamLake குழுவால் ஆவணப்படுத்தப்பட்டுள்ளன. விரைவில் காலாவதியாகக்கூடிய ஒரு அட்டவணையை மீண்டும் இங்கே வழங்குவதற்குப் பதிலாக, முக்கிய புள்ளி இதுதான்: மாதிரியின் திறன் மற்றும் செலவு ஆகியவற்றிற்கு இடையிலான தொடர்பு மாற்றியமைக்கப்பட்டுள்ளது. இதற்கு முன்பு அன்றாடப் பணிகளுக்கான இயல்பான தேர்வாக இருந்த சில மாதிரிகள், இப்போது வேறு விலை வரம்பிற்குள் இருக்கலாம். சோதனைகளுக்காக மிகவும் விலை உயர்ந்ததாகத் தோன்றிய மற்றவை, இப்போது சாத்தியமான மாற்றுகளாக மாறியிருக்கலாம்.

StreamLake பல மாதிரிகளை ஒரே இடத்தில் வழங்குவதால், ஒரு விலை திருத்தம் சிறிய திறந்த மூல மாதிரிக்கும் (open-source model) ஒரு முன்னணி மாதிரிக்கும் (flagship frontier model) இடையிலான இடைவெளியை சுருக்கலாம் அல்லது விரிவுபடுத்தலாம். அதிகாரப்பூர்வ அறிவிப்பை நீங்கள் கட்டாயம் படிக்க வேண்டிய ஒன்றாகக் கருத வேண்டும். அடுத்த காலாண்டின் செலவு விகிதத்தைக் (burn rate) கணக்கிடும்போது, நினைவாற்றல் அல்லது பழைய ஆவணங்களை மட்டும் நம்பிவிடாதீர்கள்.

புதிய விலை மாற்றங்கள் உங்கள் பணிச்சுமையைத் எவ்வாறு பாதிக்கிறது

செலவு மாற்றங்கள் அனைத்து அம்சங்களையும் சமமாகப் பாதிப்பதில்லை. ஒரு நாளைக்கு பத்து கோரிக்கைகளை மட்டுமே கையாளும் ஒரு முன்மாதிரி (prototype), எந்த விலை உயர்வையும் தாங்கிவிடும். ஆனால் ஒவ்வொரு மணிநேரமும் ஆயிரக்கணக்கான சுருக்கப் பணிகளை (summarization jobs) செயலாக்கும் ஒரு உற்பத்தி அமைப்பு (production system), அதை உடனடியாக உணரும்.

ஒரு பொதுவான பயன்பாட்டைப் பற்றிச் சிந்திப்போம். ஒரு பெரிய மாதிரி ஆவணங்களிலிருந்து தகவல்களைப் பிரித்தெடுக்கும் ஒரு முதன்மைப் பாதை (primary pipeline), ஒரு நடுத்தர மாதிரி மின்னஞ்சல் பதில்களைத் தயாரிக்கும் ஒரு இரண்டாம் நிலை வழி (secondary route), மற்றும் டெவலப்பர் ப்ராம்ப்ட்கள் (developer prompts) மிகவும் திறன் வாய்ந்த மாதிரியைத் தொடர்பு கொள்ளும் ஒரு பிழைத்திருத்த அடுக்கு (debugging layer) ஆகியவற்றை நீங்கள் வைத்திருக்கலாம். StreamLake அந்தப் பெரிய தகவல் பிரித்தெடுக்கும் மாதிரியின் விலையைச் சிறிய அளவில் உயர்த்தினால் கூட, உங்கள் அதிகப்படியான போக்குவரத்துப் பாதை (traffic path) மிகவும் விலையுயர்ந்த ஒன்றாக மாறிவிடும். நடுத்தர மாதிரியின் விலை குறைந்தால், உங்கள் மின்னஞ்சல் வழிமுறை முன்பை விடத் திடீரெனத் திறமையானதாகத் தோன்றும்.

இந்த மாற்றங்கள் நீங்கள் 'retries' மற்றும் 'fallbacks' பற்றிச் சிந்திக்கும் முறையையும் பாதிக்கின்றன. ஒரு மாதிரி மலிவாக இருந்தபோது, அதை இரண்டு முறை அழைத்து முடிவுகளை ஒப்பிட்டுப் பார்க்க உங்களால் முடிந்திருக்கும். விலை மாறும்போது, அந்தத் தேவையற்ற நகல் முறை (redundancy) ஒரு ஆடம்பரமாகிவிடும். பலமுறை உருவாக்கித் துல்லியத்தை அடைய முயற்சிப்பதற்குப் பதிலாக, உங்கள் prompt engineering முறையை நீங்கள் மேம்படுத்த வேண்டியிருக்கலாம்.

உங்கள் தற்போதைய மாதிரிப் பயன்பாட்டினைத் தணிக்கை செய்தல்

நீங்கள் எந்த மாற்றங்களைச் செய்வதற்கு முன்பும், உங்களுக்குத் தரவு தேவை. உங்கள் StreamLake கணக்கில் உள்நுழைந்து, கடந்த முப்பது முதல் அறுபது நாட்களின் பயன்பாட்டைத் தரவிறக்கம் (export) செய்யவும். முடிந்தால் அதை மாதிரி வாரியாகவும், endpoint வாரியாகவும் மற்றும் போக்குவரத்து மூலத்தின் (traffic source) வாரியாகவும் பிரிக்கவும். நீங்கள் 90-10 என்ற விகிதத்தைத் தேடுகிறீர்கள். பெரும்பாலான பயன்பாடுகளில், ஒரு சில மாதிரி அழைப்புகளே டோக்கன் செலவில் பெரும்பகுதியை உருவாக்குகின்றன.

இந்த முறைகளைக் கவனியுங்கள்:

  • அதிகத் தீவிரம் கொண்ட, குறைந்த சிக்கல்தன்மை கொண்ட பணிகள். சிறிய ட்வீட்களில் (tweets) உணர்வுகளை வகைப்படுத்த (classify sentiment) நீங்கள் ஒரு பெரிய மாடலைப் பயன்படுத்தினால், நீங்கள் அதிகப்படியான தொகையைச் செலவிடுகிறீர்கள் என்று அர்த்தம்.
  • வீணான ப்ராம்ப்ட்கள் (Bloated prompts). நீண்ட சிஸ்டம் ப்ராம்ப்ட்கள் மற்றும் few-shot உதாரணங்கள் டோக்கன் எண்ணிக்கையை (token counts) அதிகரிக்கின்றன. ஒவ்வொரு கோரிக்கைக்கும் தேவையற்ற சூழலை (redundant context) நீங்கள் வழங்கும்போது, விலை மாற்றங்கள் அதிக பாதிப்பை ஏற்படுத்தும்.
  • குறைவாகப் பயன்படுத்தப்படும் விலையுயர்ந்த மாடல்கள். சில நேரங்களில் ஒரு டெவலப்பர் பழக்கத்தின் காரணமாக, ஒரு சிறிய மாடலே போதுமானதாக இருக்கும் இடத்திலும், ஒரு முன்னணி மாடலை (frontier model) கட்டாயமாகப் பயன்படுத்துகிறார்.
  • ஸ்ட்ரீமிங் (Streaming) மற்றும் பேட்ச் (Batch) முறைகளுக்கு இடையிலான வேறுபாடுகள். நிகழ்நேர ஸ்ட்ரீமிங் செலவுகள், அசின்க்ரோனஸ் (asynchronous) பேட்ச் வேலைகளைப் போல இருக்காது. உங்கள் விலை குறித்த அனுமானங்கள் உங்கள் விநியோக முறையுடன் (delivery mode) ஒத்துப்போவதை உறுதி செய்து கொள்ளுங்கள்.

உங்களுக்கு இந்தத் தெளிவு இன்னும் இல்லையென்றால், எதையும் மாற்றுவதற்கு முன் அதை உருவாக்குங்கள். உங்கள் மிகப்பெரிய செலவு மையங்களைக் கணிப்பது பொதுவாக தவறான பகுதியை மேம்படுத்துவதற்கே வழிவகுக்கும்.

விலை மாற்றத்திற்குப் பிறகு செலவைக் கட்டுப்படுத்த நடைமுறை வழிகள்

பணம் எங்கு செலவாகிறது என்பதை நீங்கள் அறிந்தவுடன், உங்கள் தயாரிப்பைச் சிதைக்காமல் நீங்கள் பதிலளிக்க முடியும். விலை மாற்றத்திற்குப் பிந்தைய ஆய்வுக்குப் பொருத்தமான சில உறுதியான உத்திகள் இங்கே உள்ளன.

பணிகளின் நிலையைப் பொறுத்து மாடல்களை மாற்றவும். ஒவ்வொரு வசதிக்கும் பட்டியலில் உள்ள மிகச்சிறந்த மாடல் தேவையில்லை. எளிய வகைப்படுத்துதல் அல்லது வடிவமைத்தல் போன்ற பணிகளைச் சிறிய, வேகமான மாடல்களுக்கு மாற்றவும். பிழைகளைத் திருத்துவது செலவுமிக்கதாக இருக்கும் காரணங்கள் (reasoning, creative writing, அல்லது சிக்கலான தரவுப் பிரித்தெடுத்தல்) போன்றவற்றுக்கு மட்டுமே பெரிய மாடல்களைப் பயன்படுத்தவும்.

ப்ராம்ப்ட் சுருக்கத்தை (Prompt compression) செயல்படுத்தவும். தேவையற்ற பகுதிகளை நீக்கவும், சிஸ்டம் மெசேஜ்களைச் சுருக்கவும் மற்றும் தேவையற்ற few-shot உதாரணங்களை நீக்கவும். ஒரு பணிக்கு உண்மையிலேயே உதாரணங்கள் தேவைப்பட்டால், ஒவ்வொரு API அழைப்பிலும் முழுப் பத்திகளையும் இணைப்பதற்குப் பதிலாக, அவற்றை வெளிப்புறத்தில் சேமித்து வைத்து லேசாகக் குறிப்பிடவும்.

தீவிரமான கேச்சிங் (Caching) முறையைச் சேர்க்கவும். உங்கள் பயன்பாடு மீண்டும் மீண்டும் ஒரே மாதிரியான வெளியீடுகளை உருவாக்கினால், பொதுவான பதில்களை அப்ளிகேஷன் லேயரில் கேச் (cache) செய்து வைக்கவும். கேச் செய்யப்பட்ட பதிலுக்கு டோக்கன் செலவோ அல்லது தாமதமோ (latency) இருக்காது.

மாடல் கேஸ்கேடிங் (Model cascading) முறையைப் பயன்படுத்தவும். ஒவ்வொரு கோரிக்கையையும் அந்த வேலையைச் செய்யக்கூடிய மிகக் குறைந்த விலையுள்ள மாடலுடன் தொடங்கவும். ஒரு லேசான சரிபார்ப்பாளர் (lightweight validator) மூலம் வெளியீட்டை மதிப்பீடு செய்யவும். முதல் முயற்சி தரக் கட்டுப்பாட்டில் தோல்வியடைந்தால் மட்டுமே ஒரு பிரீமியம் மாடலுக்கு மாறவும். இந்த முறை கோரிக்கைக்கான சராசரி செலவை வியத்தகு முறையில் குறைக்கிறது.

பேட்ச் (Batch) மற்றும் நிகழ்நேர (Real-time) தேவைகளை ஆய்வு செய்யவும். பயனர்களுக்கு உடனடி முடிவுகள் தேவையில்லை என்றால், StreamLake ஆதரிக்கும் இடங்களில் சிங்க்ரோனஸ் (synchronous) API அழைப்புகளிலிருந்து பேட்ச் செயலாக்கத்திற்கு மாறவும். பேட்ச் முறையானது பெரும்பாலும் வேறுபட்ட விலை மற்றும் செயல்திறன் அமைப்புகளைக் கொண்டிருக்கும்.

எச்சரிக்கைகள் மூலம் திடீர் மாற்றங்களைக் கண்காணிக்கவும். உங்கள் StreamLake டேஷ்போர்டில் அல்லது உங்கள் சொந்த டெலிமெட்ரி (telemetry) மூலம் பட்ஜெட் எச்சரிக்கைகளை அமைக்கவும். விலை மாற்றத்திற்குப் பிறகு செலவில் ஏற்படும் திடீர் உயர்வை, முப்பது நாட்களுக்குப் பிறகு சரிசெய்வதை விட மூன்றாவது நாளில் சரிசெய்வது எளிது.

வெளியீட்டுத் தரத்துடன் செலவை ஒப்பிட்டு மதிப்பீடு செய்தல்

விலை என்பது பாதி மட்டுமே. மாயத்தோற்றம் (hallucinate) அல்லது தேவையற்ற குப்பையான தகவல்களைத் தரும் மலிவான மாடல், அடுத்தடுத்த நிலைகளில் மறைமுகச் செலவுகளை உருவாக்கும். வெளியீட்டை வடிகட்ட நீங்கள் இன்ஜினியரிங் நேரத்தைச் செலவிட வேண்டியிருக்கும், அல்லது அதைவிட மோசமாக, பயனர்களுக்குத் தவறான முடிவுகளை வழங்க நேரிடும்.

ஒரு விரைவான தணிக்கையைச் செய்யுங்கள். உங்கள் தயாரிப்பு லாக்ஸிலிருந்து (production logs) ஐம்பது பிரதிநிதித்துவ ப்ராம்ப்ட்களைத் தேர்ந்தெடுக்கவும். புதிய விலை அமைப்பின் கீழ் நீங்கள் பரிசீலிக்கும் மாடல்கள் மூலம் அவற்றைச் சோதிக்கவும். துல்லியம், தாமதம் (latency) மற்றும் டோக்கன் நீளம் ஆகியவற்றிற்காக வெளியீடுகளை மதிப்பிடவும். சில நேரங்களில், சற்று விலையுயர்ந்த மாடல் குறைவான டோக்கன்களில் சுருக்கமான, சரியான பதில்களைத் தரும்; இது அதிகப்படியான தகவல்களைத் தரும் மலிவான மாடலை விட நடைமுறையில் மலிவானதாக இருக்கும்.

தோல்வி விகிதங்களையும் அளவிடவும். மீண்டும் முயற்சிக்க வேண்டிய (retries) மாடல் உண்மையில் மலிவானது அல்ல. மாற்றுத் தர்க்கத்தைப் (fallback logic) பராமரிப்பதற்கான இன்ஜினியரிங் செலவையும், மெதுவான பதில்களால் பயனருக்கு ஏற்படும் பாதிப்பையும் கணக்கில் கொள்ளவும்.

அடுத்த மாற்றத்திற்குத் திட்டமிடுதல்

StreamLake அல்லது வேறு எந்த LLM தளத்திலும் இதுவே கடைசி விலை மாற்றம் இருக்காது. மாடல் சந்தை நிலையற்றது. புதிய குவாண்ட்டைசேஷன் (quantization) நுட்பங்கள் இன்ஃபரன்ஸ் (inference) செலவுகளைக் குறைக்கின்றன. சேவை வழங்குநர்களின் கூட்டணிகள் மாறுகின்றன. தளங்கள் போட்டியிடத் தங்கள் நிலைகளை (tiers) மறுசீரமைக்கின்றன. விலைகள் நிலையானவை என்று நீங்கள் உங்கள் பயன்பாட்டை உருவாக்கினால், அது எளிதில் பாதிக்கப்படக்கூடியதாக இருக்கும்.

உங்கள் மாடல் தேர்வு முறையை ஆவணப்படுத்தவும். வசதி X-க்கு ஏன் மாடல் A என்பதையும், வசதி Y-க்கு ஏன் மாடல் B என்பதையும் எழுதி வையுங்கள். அடுத்த முறை விலைகள் மாறும்போது, உங்கள் சொந்த கட்டமைப்பை மீண்டும் ஆய்வு செய்ய வேண்டிய அவசியம் இருக்காது. மாற்றங்களைச் செய்ய உங்களிடம் ஒரு முடிவுப் பதிவு (decision log) இருக்கும்.

StreamLake டெவலப்பர் சேனல்கள் மற்றும் பரந்த சமூக விவாதங்களைக் கவனித்துக் கொண்டே இருங்கள். விலை என்பது பெரும்பாலும் செயல்திறன் அளவீடுகள் (performance benchmarks) மற்றும் புதிய மாடல்களின் வருகையுடன் சேர்த்து விவாதிக்கப்படுகிறது. சூழல் முக்கியமானது. தாமதக் குறைப்புடன் கூடிய விலை உயர்வு ஒரு நல்ல வர்த்தகமாக இருக்கலாம். பயன்பாட்டில் இல்லாத (deprecated) ஒரு மாடலின் விலை குறைவது கொண்டாட்டத்திற்குரியது அல்ல.

உண்மையான கருத்து

விலை மாற்றங்கள் ஒரு கட்டாயத் தூண்டுதல். அவை உங்கள் பயன்பாட்டை ஆழமாகப் புரிந்துகொள்ள உங்களைத் தூண்டுகின்றன. புதிய StreamLake கட்டணங்களை அப்படியே ஏற்றுக்கொண்டு கடந்து செல்லாதீர்கள். உங்கள் டோக்கன் ஓட்டத்தை (token flow) தணிக்கை செய்யவும், உங்கள் ப்ராம்ப்ட்களை (prompts) செம்மைப்படுத்தவும் மற்றும் மாடல்களுக்கு இடையே புத்திசாலித்தனமான வழித்தடங்களை (routing) உருவாக்கவும் அவற்றை ஒரு தூண்டுதலாகப் பயன்படுத்தவும். விலை மாற்றங்களை ஒரு செயல்பாட்டு இடையூறாகக் கருதும் குழுக்கள், மெதுவாகத் தங்கள் பட்ஜெட்டை இழப்பார்கள். அவற்றை ஒரு மேம்படுத்தல் சமிக்ஞையாகக் கருதும் குழுக்கள், வேகமான, மலிவான மற்றும் அதிக நம்பகமான அமைப்புகளைப் பெறுவார்கள். அதிகாரப்பூர்வ விவரங்களைச் சரிபார்க்கவும், உங்கள் உண்மையான பயன்பாட்டுடன் அந்த மாற்றங்களை ஒப்பிட்டுப் பார்க்கவும், மேலும் இந்த வாரம் ஒரு திட்டமிட்ட மாற்றத்தைச் செய்யவும். உங்கள் எதிர்காலப் பில் அறிக்கையில் அந்தத் வித்தியாசம் பிரதிபலிக்கும்.