API விலையிடல் மாற்றங்கள் அரிதாகவே சத்தத்தை உண்டாக்குகின்றன. ஸ்டேட்டஸ்-பேஜ் எச்சரிக்கை இல்லை, பயன்பாடு நிறுத்தப்படும் (deprecation) எச்சரிக்கை இல்லை, பொதுவாக மின்னஞ்சல் அறிவிப்புகளும் இல்லை. ஒரு வழங்குநரின் விலையிடல் பக்கத்தில் உள்ள எண்கள் சாதாரணமாக மாறுகின்றன, மேலும் அடுத்த முறை உங்கள் பேட்ச் வேலை (batch job) முடிவடையும் போது, பில் வேறுபட்டுத் தெரியும். Novita மற்றும் StreamLake ஆகியவற்றுடன் சரியாக இதுவே நடந்தது. இரண்டு தளங்களும் அவற்றின் LLM விலை அட்டவணைகளை (rate cards) புதுப்பித்துள்ளன, எனவே நீங்கள் ஏதேனும் ஒரு சேவையில் inference workloads-களை இயக்கிக் கொண்டிருந்தால், உங்கள் அடுத்த பணியைத் தொடங்குவதற்கு முன் புதிய எண்களை நீங்கள் சரிபார்க்க வேண்டும்.
மாறிவரும் விலை இலக்குகளின் அமைதியான அச்சுறுத்தல்
பெரும்பாலான பொறியியல் குழுக்கள் uptime, latency மற்றும் token accuracy ஆகியவற்றை மிகுந்த கவனத்துடன் கண்காணிக்கின்றன. இருப்பினும், ஆயிரம் டோக்கன்களுக்கான செலவு (Cost per thousand tokens), தொடக்கக் காலத்தில் ஒருமுறை மட்டுமே பார்க்கப்பட்டு, பின்னர் பின்னடைவாகிவிடுகிறது. அது ஒரு தவறு. அதிக அளவிலான பயன்பாடுகளில்—வாடிக்கையாளர் சேவை சாட்பாட்கள் (customer support chatbots), ஆவணச் சுருக்கப் குழாய்கள் (document summarization pipelines), குறியீடு உருவாக்கும் கருவிகள் (code generation tools)—ஒரு டோக்கனுக்கான ஒரு சிறிய சென்ட் மாற்றம் கூட மாத இறுதியில் குறிப்பிடத்தக்க பட்ஜெட் அழுத்தமாக மாறும்.
ஒரு அம்சம் நிறுத்தப்படும்போது (feature deprecation) உடனடியாக குறியீட்டை மாற்ற வேண்டிய கட்டாயம் ஏற்படும், ஆனால் விலையிடல் புதுப்பிப்பு உங்கள் ஒருங்கிணைப்பை (integration) பாதிக்காது. உங்கள் கோரிக்கைகள் (requests) இன்னும் 200 status codes-களைத் தான் வழங்கும். உங்கள் JSON payloads இன்னும் சரியாகவே இருக்கும். ஒரே ஒரு வித்தியாசம் விலைப்பட்டியல் (invoice) மட்டுமே. நிதித் துறை இந்த முரண்பாட்டைக் கண்டறியும் போது, நீங்கள் ஏற்கனவே ஒரு ஸ்பிரிண்டிற்கான (sprint) inference பட்ஜெட்டைத் தீர்த்துவிட்டிருக்கலாம். Novita மற்றும் StreamLake ஆகிய இரண்டும் சமீபத்தில் அவற்றின் விலையிடல் கட்டமைப்புகளை மாற்றியுள்ளன, அதாவது அவற்றின் endpoints-களைப் பயன்படுத்தும் எந்தவொரு தானியங்கி குழாய் (automated pipeline), ஸ்டேஜிங் சோதனை (staging test) அல்லது ப்ரொடக்ஷன் workload-ம் நீங்கள் எதிர்பார்ப்பதை விட அதிகமாகவோ அல்லது குறைவாகவோ செலவு செய்யலாம். யூகிக்கத் தொடங்குவது ஒரு சிறந்த உத்தியல்ல.
சமீபத்திய புதுப்பிப்புகள் பற்றி நாம் அறிவது என்ன
Novita மற்றும் StreamLake ஆகியவற்றிற்கான வெளியிடப்பட்ட விலை அட்டவணைகள் இரண்டும் மாறியுள்ளன. துல்லியமான மாற்றங்கள் (deltas) மாடல் அடுக்கு (model tier) மற்றும் டோக்கன் வகையைப் பொறுத்து மாறுபடும் என்றாலும், முக்கிய கருத்து ஒன்றுதான்: inference செலவைப் பற்றி கடந்த மாதம் நீங்கள் வைத்திருந்த அனுமானங்கள் இனி செல்லாது. GPU cloud சேவைகளுடன் பல்வேறு பெரிய மொழி மாதிரி (large language model) API-களை வழங்கும் Novita, மாடல் அணுகலுக்கான கட்டண முறையை மாற்றியமைத்துள்ளது. ஒரு விரிவான கிளவுட் மற்றும் AI உள்கட்டமைப்பு வழங்குநராகச் செயல்படும் StreamLake-உம் இதேபோல் தனது LLM விலையிடல் அட்டவணையை மாற்றியமைத்துள்ளது.
இந்தத் தளங்கள் செலவுகளை வெவ்வேறு விதமாக கட்டமைக்கின்றன—சிலவை உள்ளீடு (input) மற்றும் வெளியீடு (output) டோக்கன்கள் பிரிக்கப்பட்டுள்ளன, சிலவற்றில் அவை ஒன்றாக இணைக்கப்பட்டுள்ளன, சிலவற்றில் நீண்ட-சூழல் விண்டோக்களுக்கு (long-context windows) அல்லது அதிக-திறன் கொண்ட endpoints-களுக்கு கூடுதல் கட்டணம் வசூலிக்கப்படுகிறது—எனவே நீங்கள் ஒரு பழைய மதிப்பீட்டைப் புதிய பணிக்குத் தாராளமாகப் பயன்படுத்த முடியாது. திங்கட்கிழமை சிக்கனமானதாக இருந்த ஒரு பணிப்பாய்வு (workflow), வெளியீடு-டோக்கன் மல்டிப்ளையர் (output-token multiplier) மாறினால் அல்லது தள்ளுபடி அடுக்கு மறுசீரமைக்கப்பட்டால், புதன்கிழமைக்குள் பட்ஜெட் வரம்பைத் தாண்டிவிடக்கூடும். குறிப்பிட்ட விலை மாற்றங்களின் விவரங்கள் அசல் டெவலப்பர் அறிக்கையில் ஆவணப்படுத்தப்பட்டுள்ளன. அந்த அறிக்கையை ஒரு மூன்றாம் தரப்பு சுருக்கமாகக் கருதாமல், அதை உங்கள் உண்மையான ஆதாரமாக (ground truth) எடுத்துக்கொள்ள வேண்டும்.
ஒரு LLM விலை அட்டவணையை எவ்வாறு படிப்பது
பழைய செலவை புதிய செலவோடு ஒப்பிடுவதற்கு முன், நீங்கள் உண்மையில் எதைப் பார்க்கிறீர்கள் என்பதை நீங்கள் தெரிந்து கொள்ள வேண்டும். பெரும்பாலான வழங்குநர்கள் விலையிடலை சில தனித்துவமான காரணிகளாகப் பிரிக்கிறார்கள், Novita மற்றும் StreamLake என்பাও விதிவிலக்கல்ல.
முதலாவதாக, உள்ளீடு டோக்கன்களை (input tokens) வெளியீடு டோக்கன்களிலிருந்து (output tokens) பிரிக்கவும். உள்ளீடு என்பது நீங்கள் மாடலுக்கு அனுப்புவது; வெளியீடு என்பது மாடல் உருவாக்குவது. பல ப்ரொடக்ஷன் சிஸ்டம்களில், குறிப்பாக சாட் சுருக்கம் (chat summarization) அல்லது ஆக்கப்பூர்வமான எழுத்துத் பணிகளில், வெளியீடு அளவு உள்ளீடு அளவை விட அதிகமாக இருக்கும். உள்ளீடு செலவைக் குறைத்து, வெளியீடு செலவை உயர்த்தும் ஒரு வழங்குநர், உண்மையில் உங்கள் மொத்த பில்லை அதிகரிக்கக்கூடும்.
இரண்டாவதாக, context-window விலையிடலைக் கவனியுங்கள். ஒரே முறையில் பல்லாயிரக்கணக்கான டோக்கன்களைக் கையாளும் நீண்ட-சூழல் மாடல்கள் (long-context models), சில நேரங்களில் நேரியல் முறையில் (linearly) அதிகரிக்காத கூடுதல் கட்டணங்களைக் கொண்டிருக்கும். உங்கள் பயன்பாடு முழுமையான குறியீட்டுத் தொகுப்புகள் (codebases) அல்லது நீண்ட சட்ட ஆவணங்களை ப்ராம்ப்ட்களாக (prompts) அனுப்பினால், நீண்ட-சூழல் அடுக்கில் (long-context tier) ஏற்படும் சிறிய டோக்கன் உயர்வு, பொதுவான விலை உயர்வை விட அதிக பாதிப்பை ஏற்படுத்தும்.
மூன்றாவதாக, throughput மற்றும் concurrency விதிகளைக் கவனியுங்கள். சில விலை அட்டவணைகள் தொகுக்கப்பட்ட (batched) அல்லது ஆஃப்லைன் inference-களுக்குக் குறைந்த விலையை வழங்குகின்றன, ஆனால் நிகழ்நேர ஸ்ட்ரீமிங்கிற்கு (real-time streaming) அதிக கட்டணம் வசூலிக்கின்றன. உங்கள் பயனர் சார்ந்த பயன்பாடு குறைந்த-தாமத (low-latency) பதில்களைச் சார்ந்து இருந்தால், டோக்கன் அளவைப் பொருட்படுத்தாமல் நீங்கள் ஒரு பிரீமியம் அடுக்கிலேயே இருக்க வேண்டியிருக்கும்.
இறுதியாக, மறைமுகமான கூடுதல் செலவுகளைச் சரிபார்க்கவும். Retrieval-augmented generation (RAG) பணிப்பாய்வுகள் பெரும்பாலும் LLM-ஐ அடைவதற்கு முன்பே embedding endpoints, vector stores மற்றும் reranking APIs ஆகியவற்றைப் பயன்படுத்துகின்றன. Novita மற்றும் StreamLake தங்களது LLM விலையிடலை மாற்றியிருக்கலாம், ஆனால் அதே விலைப்பட்டியலில் உள்ள தொடர்புடைய சேவைகளும் மாறியிருக்கலாம். வெறும் மில்லியன்-டோக்கன் விகிதத்தை மட்டும் பார்க்காமல், முழுப் பக்கத்தையும் வாசிக்கவும்.
உங்கள் அடுத்த பயன்பாட்டு deployment-க்கு முன் எண்களைச் சரிபார்க்கவும்
புதிய கட்டண அட்டவணை (rate card) கிடைத்தவுடன், வெறும் கணிப்புகளை மட்டும் நம்பிவிடாதீர்கள். அளவிடுங்கள். கடந்த ஏழு முதல் முப்பது நாட்களின் கோரிக்கை பதிவுகளை (request logs) எடுத்து, அதே வேலைப்பளு புதிய கட்டமைப்பின் கீழ் எவ்வளவு செலவாகும் என்பதைக் கணக்கிடுங்கள். நீங்கள் ஒரு மையப்படுத்தப்பட்ட லாகிங் கருவி அல்லது an observability dashboard பயன்படுத்தினால், provider endpoint மூலம் வடிகட்டி (filter), token counts-ஐ ஏற்றுமதி செய்யுங்கள். பெரும்பாலான APIs அவற்றின் response payload-இல் பயன்பாட்டு மெட்டாடேட்டாவைத் திருப்பித் தரும், எனவே இதை சில வரிகளில் Python மூலம் ஸ்கிரிப்ட் செய்யலாம்.
ஒரு பிரதிநிதித்துவ மாதிரியுடன் தொடங்குங்கள். முந்தைய பில்லிங் சுழற்சியில் மிகவும் பிஸியாக இருந்த நாளைத் தேர்ந்தெடுங்கள். உள்ளீட்டு டோக்கன்களை (input tokens) புதிய உள்ளீட்டு விகிதத்தாலும், வெளியீட்டு டோக்கன்களை (output tokens) புதிய வெளியீட்டு விகிதத்தாலும் பெருக்குங்கள். உங்கள் மாடல் அடுக்கிற்கு (model tier) பொருந்தும் context-window அல்லது throughput கூடுதல் கட்டணங்களையும் சேர்க்கவும். அந்தச் செயற்கையான கட்டணத்தை நீங்கள் உண்மையில் செலுத்திய தொகையுடன் ஒப்பிட்டுப் பாருங்கள். அந்த வித்தியாசம் (delta) உங்கள் தாங்கும் வரம்பைத் தாண்டினால்—உதாரணமாக, பத்து அல்லது இருபது சதவீதம்—நீங்கள் ஒரு முடிவை எடுக்க வேண்டியிருக்கும்.
அந்த முடிவு எப்போதும் வழங்குநர்களை மாற்றுவதைக் குறிப்பதல்ல. சில நேரங்களில் ஒரே தளத்திற்குள் மாடல் அடுக்குகளை மாற்றுவது, பிராம்ட் (prompt) நீளத்தைக் குறைப்பது, response caching-ஐ செயல்படுத்துவது அல்லது முக்கியமற்ற பேட்ச் வேலைகளை (batch jobs) பயன்பாடு குறைவாக உள்ள நேரங்களுக்கு மாற்றுவது போன்றவற்றை இது குறிக்கலாம். அடுத்த இன்வாய்ஸ் வரும்போது மாற்றத்தைக் கண்டறிவதை விட, தரவுகளின் அடிப்படையில் அந்த முடிவை எடுப்பதே முக்கியம்.
தளம் அனுமதித்தால், நீங்கள் செலவு வரம்புகள் (spend caps) அல்லது பட்ஜெட் எச்சரிக்கைகளையும் அமைக்க வேண்டும். பல API டேஷ்போர்டுகள் திட்டம் அல்லது கீ (key) மட்டத்தில் அறிவிப்பு வரம்புகளை (notification thresholds) அமைக்க அனுமதிக்கின்றன. அவற்றை மிகவும் பாதுகாப்பான அளவில் அமைக்கவும். எதிர்காலத்தில் Novita அல்லது StreamLake மீண்டும் ஒரு கட்டண மாற்றத்தைக் கொண்டு வந்தால், உங்களுக்குத் தேவை ஒரு நிதிப் பாதுகாப்பு முறையே தவிர, எதிர்பாராத நான்கு இலக்க கூடுதல் செலவு அல்ல.
பெரிய படம்: உள்கட்டமைப்பு செலவுகள் ஒருபோதும் நிலையானவை அல்ல
Novita மற்றும் StreamLake ஆகியவற்றிலிருந்து வரும் இந்தத் தகவல்கள், foundation-model சந்தை இன்னும் நிலைபெறவில்லை என்பதற்கான நினைவூட்டல்கள் ஆகும். விலை நிர்ணயம் என்பது தற்செயலானது அல்ல; அது கணினித் திறன் கிடைப்புத்தன்மை (compute availability), உரிம ஒப்பந்தங்கள் மற்றும் போட்டி நிலைப்பாட்டைப் பிரதிபலிக்கிறது. ஒரு வழங்குநர் அதிகப் பயன்பாட்டை ஈர்க்கக் கட்டணங்களைக் குறைக்கலாம், பின்னர் பயனர்கள் நிலைபெற்றவுடன் அவற்றை உயர்த்தலாம். அல்லது, புதிய மற்றும் அதிக திறன் கொண்ட மாடல்களின் செலவை ஈடுகட்ட விலையை உயர்த்தலாம், அதே சமயம் பழைய மாடல்களுக்குச் சலுகைகளைத் தொடரலாம். எதுவாக இருந்தாலும், ஒரு தனி வழங்குநரின் கட்டண அட்டவணையை நிலையானது என்று நம்புவது தவறான செயல்பாட்டு முறையாகும்.
Inference-ஐ ஒரு பொதுவான அடுக்காகக் கருதும் குழுக்கள் ஏற்கனவே பல வழங்குநர் அமைப்புகளைப் (multi-provider setups) பயன்படுத்துகின்றன. அவர்கள் தரமான எளிய வினவல்களை (queries) மலிவான எண்ட்பாயிண்டிற்கு வழிநடத்துகிறார்கள் மற்றும் கடினமான பணிகளுக்காக விலையுயர்ந்த மாடல்களை ஒதுக்குகிறார்கள். அந்தத் தொழில்நுட்பக் கட்டமைப்பு (architecture) ஆரம்பத்தில் அதிக வேலைப்பளுவைக் கொண்டிருக்கலாம், ஆனால் இது இத்தகைய அமைதியான விலை மாற்றங்களிலிருந்து உங்களைப் பாதுகாக்கிறது. நீங்கள் ஒரு முழுமையான routing layer-ஐ அமைக்கத் தயாராக இல்லாவிட்டாலும், ஒரு இரண்டாம் நிலை வழங்குநரை (secondary provider) எப்போதும் தயார் நிலையில் வைத்திருப்பது, முதன்மை வழங்குநர் விலையை மாற்றும்போது உங்களுக்குச் சாதகமான நிலையைத் தரும்.
துல்லியமான விவரங்களைக் கண்டறிவது எப்படி
என்ன மாற்றங்கள் நிகழ்ந்துள்ளன என்பதன் நுணுக்கமான விவரங்கள்—ஒவ்வொரு மாடல் வாரியாக, ஒவ்வொரு டோக்கன் வகை வாரியாக—அசல் அறிக்கையில் கிடைக்கின்றன. இந்தத் தகவல்களைப் பதிவு செய்த மூல இணைப்பில் (source link) முழு விவரங்களையும் நீங்கள் படிக்கலாம். உள்கட்டமைப்பு விலை நிர்ணயம், மாடல் வெளியீடுகள் மற்றும் செலவு மேம்பாட்டு உத்திகள் (cost optimization tactics) குறித்த தொடர்ச்சியான விவாதங்களுக்கு, Telegram-இல் GyaanSetu கற்றல் சமூகம் (learning community) செயல்பட்டு வருகிறது.
முக்கியக் கருத்து
ஒரு விலை மாற்றத்தை ஒரு post-mortem ஆய்வாக மாற்ற அனுமதிக்காதீர்கள். உங்கள் அடுத்த training run, batch inference job அல்லது Novita அல்லது StreamLake-க்கான production deployment-ஐத் தொடங்குவதற்கு முன், அவற்றின் தற்போதைய விலை பக்கங்களைத் திறந்து, கடந்த வாரத் தரவுகளைப் புதிய விகிதங்களுடன் மீண்டும் சரிபார்க்கவும். கணக்கீடு சரியாக இருந்தால், நம்பிக்கையுடன் தொடரலாம். இல்லையெனில், செலவுத் தொடங்குவதற்கு முன்பே உங்கள் பைப்லைனை (pipeline) மறுபேச்சுவார்த்தை செய்யத் தேவையான தரவுகள் உங்களிடம் இருக்கும். உங்கள் எதிர்கால இன்வாய்ஸ் உங்களுக்கு நன்றி சொல்லும்.