StreamLake தனது LLM விலைகளை மாற்றியுள்ளது. நீங்கள் உண்மையில் செய்ய வேண்டியது இதுதான்.
நீங்கள் StreamLake-இல் அம்சங்களை (features) உருவாக்கித் தள்ளிக் கொண்டிருந்தால், LLM மாடல் விலையில் சமீபத்தில் செய்யப்பட்ட மாற்றம் என்பது நீங்கள் கடந்து செல்லும் ஒரு சிறிய குறிப்பு அல்ல. இது ஒரு செயல்பாட்டுத் தகவல் (operational signal). இன்ஃபரன்ஸிற்காக (inference) இந்தத் தளம் வசூலிக்கும் கட்டணத்தை மாற்றும்போது, நீங்கள் கவனித்தாலும் இல்லாவிட்டாலும் உங்கள் யூனிட் எகனாமிக்ஸ் (unit economics) மாறும். லாபத்துடன் தொடரும் குழுக்கள் இத்தகைய மாற்றங்களை வெறும் சுமையாக ஏற்கும் முன், அவற்றை ஆய்வு செய்ய ஒரு வாய்ப்பாகக் கருதுகின்றன.
StreamLake மாடல் விலைகளை மாற்றியுள்ளது. இதுதான் அடிப்படை உண்மை. ஒவ்வொரு எண்ட்பாயிண்டிற்கும் (endpoint) மற்றும் டோக்கன் நிலைகளுக்கும் (token tier) உரிய துல்லியமான கட்டண மாற்றங்கள் கீழே இணைக்கப்பட்டுள்ள டெவலப்பர் அறிவிப்பில் கொடுக்கப்பட்டுள்ளன. புதிய எண்களைப் படித்துவிட்டு அப்படியே விட்டுவிடுவது உங்கள் வேலையல்ல. கடந்த ஆறு மாதங்களில் நீங்கள் எடுத்த ஒவ்வொரு தயாரிப்பு முடிவிலும் அந்த எண்கள் எவ்வாறு தாக்கத்தை ஏற்படுத்துகின்றன என்பதைப் புரிந்துகொள்வதே உங்கள் கடமையாகும்.
விலை மாற்றங்கள் நீங்கள் எதிர்பார்ப்பதை விட ஏன் அதிக பாதிப்பை ஏற்படுத்துகின்றன
பெரும்பாலான மென்பொருள் வணிகங்கள் நிலையான செலவுகளை (fixed costs) அடிப்படையாகக் கொண்டவை. நீங்கள் சர்வர்கள், தரவுத்தளங்கள் (databases) மற்றும் பேண்ட்வித் (bandwidth) ஆகியவற்றிற்குப் பணம் செலுத்துகிறீர்கள். அந்தப் பட்டியல்கள் கணிக்கக்கூடியவை. ஆனால், லார்ஜ் லாங்குவேஜ் மாடல்கள் (LLMs) அந்த முறையை மாற்றுகின்றன. இன்ஃபரன்ஸ் என்பது பயனர் நடத்தையுடன் நேரடியாகத் தொடர்புடைய ஒரு மாறுபடும் செலவு (variable cost). உங்கள் செயலியில் ஐம்பது பக்க ஆவணத்தை காப்பி-பேஸ்ட் செய்யும் ஒரு வாடிக்கையாளர், மூன்று வார்த்தைகளைக் கேட்கும் வாடிக்கையாளரை விட முற்றிலும் மாறுபட்ட கட்டணத்தை உருவாக்குகிறார். StreamLake தனது கட்டணங்களை மாற்றும்போது, அந்த மாறுபாடு இன்னும் தீவிரமடைகிறது.
அதிக மாடல் செலவுகள், உடனடியாகத் தெரியாத வகையில் உங்கள் லாப வரம்புகளை (margins) அரிக்கும். நீங்கள் ஒரு அம்சத்தைத் தொடங்கும் போது கணக்கிட்டுப் பார்த்தால், உங்கள் AI அம்சம் நல்ல லாபத்தைத் தருவது போலத் தெரியலாம். ஆனால் ஆறு மாதங்களுக்குப் பிறகு, விலை மாற்றம் மற்றும் பயன்பாடு அதிகரித்த பிறகு, அதே அம்சம் ஒவ்வொரு அழைப்பிலும் (call) நஷ்டத்தையே ஏற்படுத்தும். நிலையான விலையை (flat-rate pricing) நிர்ணயித்துள்ள குழுக்களுக்கே ஆபத்து அதிகம். நீங்கள் பயனர்களிடம் மாதம் $29 வசூலிக்கிறீர்கள், ஆனால் ஒரு கனமான இன்ஃபரன்ஸ் அழைப்பிற்காக உங்கள் பேக்எண்ட் (backend) $8 செலவிடுகிறது என்றால், அது ஒரு வணிக மாதிரி அல்ல; அது ஒரு மானியம் (subsidy) மட்டுமே.
இந்த பாதிப்பு இன்புட் டோக்கன்கள் (input tokens), அவுட்புட் டோக்கன்கள் (output tokens) அல்லது குறிப்பிட்ட மாடல் குடும்பங்கள் ஆகியவற்றில் எதில் மாற்றம் ஏற்படுகிறது என்பதைப் பொறுத்தும் அமையும். சில பயன்பாடுகள் இன்புட் சார்ந்தவை (input-heavy). முழுமையான ரெப்போசிட்டரிகளையும் (repositories) சூழலாக (context) அனுப்பும் கோட் ரிவியூ (code review) கருவிகளைப் பாருங்கள். மற்றவை அவுட்புட் சார்ந்தவை (output-heavy), உதாரணமாக பயனருக்கு ஆயிரக்கணக்கான டோக்கன்களைத் தரும் நீண்ட வடிவிலான எழுத்து உதவியாளர்கள் (writing assistants). அவுட்புட் டோக்கன்களை மட்டும் பாதிக்கும் விலை மாற்றம், கோட் ரிவியூவரை விட எழுத்தாளரை அதிகம் பாதிக்கும், அல்லது இதற்கு நேர்மாறாக இருக்கலாம். பாதிப்பை மதிப்பிடுவதற்கு முன், உங்கள் டோக்கன் பயன்பாட்டுத் தன்மையை (token profile) நீங்கள் தெரிந்து கொள்ள வேண்டும்.
விலை குறித்த விழிப்புணர்வுடன் கூடிய பணிப்பாய்வை (Workflow) உருவாக்குங்கள்
உங்கள் மாதக் கட்டணம் உங்களை அதிர்ச்சியடையச் செய்யும் வரை காத்திருப்பது ஒரு தவறான உத்தி. விலை மாற்றங்களால் ஏற்படும் ஏற்ற இறக்கங்களைத் தாங்கி நிற்கும் குழுக்கள், கண்காணிப்பைத் (monitoring) தங்கள் அன்றாடப் பழக்கமாக மாற்றிக்கொள்கின்றன. ஸ்பிரெட்ஷீட்களில் (spreadsheets) மூழ்கிவிடாமல் இதை எப்படிச் செய்வது என்று இங்கே பார்ப்போம்.
முதலாவதாக, ஒவ்வொரு API அழைப்பையும் அம்சம் (feature) மற்றும் மாடல் (model) வாரியாகக் குறியீடு (tag) செய்யுங்கள். உங்கள் செயலியில் ஒரு சம்மரைசர் (summarizer), ஒரு சாட்பாட் (chatbot) மற்றும் ஒரு மொழிபெயர்ப்பு அடுக்கு (translation layer) இருந்தால், உங்கள் லாகிங் பைப்பலைனில் (logging pipeline) செலவுகளைப் பிரியுங்கள். StreamLake தனது கட்டணங்களை மாற்றும்போது, "எங்கள் இன்ஃபரன்ஸ் செலவில் 70 சதவீதம் சம்மரைசருக்காகச் செலவிடப்படுகிறது" என்று ஒரு அறிக்கையைத் தயார் செய்ய உங்களுக்குத் தெரிந்திருக்க வேண்டும். அந்தத் துல்லியம் எங்கு முதலில் மேம்படுத்த வேண்டும் (optimize) என்பதை உங்களுக்குச் சொல்லும்.
இரண்டாவதாக, பட்ஜெட் எச்சரிக்கைகளை (budget alerts) அமைக்கவும். StreamLake உட்பட பெரும்பாலான தளங்கள், நீங்கள் செலவு வரம்புகளை (spending thresholds) வரையறுக்க அனுமதிக்கின்றன. அவற்றைத் தீவிரமாக அமைக்கவும். உங்கள் தினசரி இன்ஃபரன்ஸ் கட்டணம் வழக்கத்தை விட 30 சதவீதம் அதிகரித்தால், முப்பது நாட்களுக்குப் பிறகு ஒரு ஆச்சரியமான இன்வாய்ஸாக (invoice) வராமல், சில மணி நேரங்களிலேயே ஒரு Slack செய்தி அல்லது மின்னஞ்சல் உங்களுக்கு வர வேண்டும். சில குழுக்கள் இன்னும் கூடுதலாகச் சென்று, அப்ளிகேஷன் மட்டத்திலேயே (application layer) செலவு வரம்புகளைக் (hard cost caps) கட்டாயமாக்குகின்றன. ஒரு பயனர் கோரிக்கை முன்கூட்டியே நிர்ணயிக்கப்பட்ட பட்ஜெட்டைத் தாண்டினால், செயலி ஒரு லேசான மாடலுக்கு (lighter model) மாற்றப்படும் அல்லது சேமிக்கப்பட்ட முடிவை (cached result) வழங்கும்.
மூன்றாவதாக, உங்கள் ப்ராம்ப்ட்களை (prompts) சுருக்குங்கள். விலை மாற்றங்கள் உங்கள் கான்டெக்ஸ்ட் விண்டோக்களை (context windows) ஆய்வு செய்ய ஒரு சிறந்த வாய்ப்பாகும். டெவலப்பர்கள் பெரும்பாலும் உதாரணங்கள், அறிவுறுத்தல்கள் மற்றும் வடிவமைப்புக் விதிகளைச் சேர்க்கும்போது, ப்ராம்ப்ட்கள் காலப்போக்கில் நீண்டு கொண்டே போகின்றன. ஒவ்வொரு கூடுதல் வாக்கியமும் ஒவ்வொரு அழைப்பிலும் பணத்தை வீணாக்குகிறது. மில்லியன் கணக்கான கோரிக்கைகளை நீங்கள் கையாளும்போது, 2,000 டோக்கன் ப்ராம்ப்டை 1,200 டோக்கன்களாகக் குறைப்பது என்பது ஒரு சிறிய மேம்பாடு (micro-optimization) மட்டுமல்ல; அது உயிர்வாழ்வதற்கான வழி.
நான்காவதாக, ஒரு மாற்றுத் திட்டத்தை (fallback ladder) வைத்திருங்கள். முதன்மை மாடல் (flagship option) மிகவும் விலை உயர்ந்ததாக மாறினால், எந்தெந்தப் பணிகளைச் சிறிய அல்லது பழைய மாடல் மூலம் செய்ய முடியும் என்பதை நீங்கள் முன்கூட்டியே அறிந்திருக்க வேண்டும். எளிய வகைப்பாடு (classification), நோக்கம் கண்டறிதல் (intent detection) மற்றும் உணர்வுப் பகுப்பாய்வு (sentiment scoring) ஆகியவற்றிற்குப் பட்டியலில் உள்ள மிகப்பெரிய மாடல் அரிதாகவே தேவைப்படும். விலை மாறும்போது உடனடியாகப் போக்குவரத்தை (traffic) மாற்றிக்கொள்ள, மலிவான மாற்று வழியைத் தயாராக வைத்திருங்கள்.
எப்போது மேம்படுத்த வேண்டும் மற்றும் எப்போது மறுவடிவமைப்பு செய்ய வேண்டும் என்பதைத் தெரிந்து கொள்ளுங்கள்
ஒவ்வொரு விலை உயர்வையும் செலவுக் குறைப்பு மூலம் மட்டுமே எதிர்கொள்ள வேண்டிய அவசியமில்லை. சில நேரங்களில் உங்கள் தயாரிப்பையே மாற்றுவதே சரியான தீர்வாக இருக்கும். ஒரு முக்கிய அம்சம் (core feature) அதன் விலை இருமடங்காக உயர்ந்த ஒரு endpoint-ஐச் சார்ந்து இருந்தால், இன்னும் ஆழமான கேள்விகளைக் கேளுங்கள். செலவைக் குறைக்க கோரிக்கைகளை (requests) தொகுப்பாக (batch) அனுப்ப முடியுமா? பயனர்களின் ஐம்பது பொதுவான வினவல்களை (queries) cache செய்து, அவற்றை மாடலுக்குப் பதிலாக ஒரு தரவுத்தளத்திலிருந்து (database) வழங்க முடியுமா? அதிகப்படியான முன்செயலாக்கத்தை (pre-processing) client-side embeddings-க்கு மாற்றுவதன் மூலம், API-க்கு அனுப்பப்படும் உரையின் அளவைக் குறைக்க முடியுமா?
இத்தகைய சூழலில் hybrid architectures உங்களுக்கு உதவியாக இருக்கும். ஒரு பயனர் வினவலுக்கு விலையுயர்ந்த reasoning engine தேவையா இல்லையா என்பதைத் தீர்மானிக்க, பல குழுக்கள் upstream-இல் ஒரு மலிவான classifier model-ஐப் பயன்படுத்துகின்றன. கேள்வி எளிமையானதாக இருந்தால், ஒரு lightweight model அல்லது rules-based system மூலம் அதற்குப் பதிலளியுங்கள். கடினமான சிக்கல்களுக்கு மட்டுமே அந்த விலையுயர்ந்த அழைப்புகளை (costly calls) ஒதுக்குங்கள். இது உங்கள் தயாரிப்பின் தரத்தைக் குறைக்காமல், உங்கள் செலவு விகிதத்தைக் கட்டுப்படுத்தும்.
உங்கள் தரப்பிலும் விலை நிர்ணய உத்தி (pricing strategy) குறித்த கேள்வி உள்ளது. inference செலவுகள் அதிகரித்துக்கொண்டிருந்தால், பயன்பாட்டு அடிப்படையிலான நிலைகள் (usage-based tiers) மூலம் அதன் ஒரு பகுதியை பயனர்களிடம் கொண்டு சேர்ப்பது பயனர்களுக்கு எதிரான செயல் அல்ல. அது நேர்மையானது. அதிகப்படியான token சுமைகளை உருவாக்கும் வாடிக்கையாளர்கள் தாங்கள் பயன்படுத்தும் உள்கட்டமைப்புக்காக (infrastructure) பணம் செலுத்துகிறார்கள். குறைந்த தேவைகளைக் கொண்டவர்கள் மலிவான திட்டங்களில் தொடரலாம். இதற்கு மாற்றாக, உங்கள் லாப வரம்பு (margin) சுருங்கிப் போகும் வரை, இல்லாத ஒரு பாதுகாப்பை (moat) தேடிக்கொண்டிருப்பது வீணாகும்.
விவரங்களை எங்கே பெறுவது
துல்லியமான புதிய கட்டணங்கள், நடைமுறைக்கு வரும் தேதிகள் மற்றும் பாதிக்கப்பட்ட மாடல் நிலைகள் (model tiers) அதிகாரப்பூர்வ Stream