LLM உள்கட்டமைப்பு கட்டணங்கள் அரிதாகவே அதிர்ச்சியாக வருகின்றன. அவை படிப்படியாகக் கூடுகின்றன—ஆயிரம் கோரிக்கைகளுக்கு (requests) சில கூடுதல் டாலர்கள், வெளியீட்டு டோக்கன் (output-token) விகிதங்களில் சிறிய உயர்வு, நீண்ட உரையாடல்களின் செலவை அமைதியாக உயர்த்தும் ஒரு கான்டெக்ஸ்ட்-விண்டோ (context-window) சரிசெய்தல். மாற்றம் உண்மையாகத் தெரியவரும்போது, நீங்கள் ஏற்கனவே இல்லாத எண்களைக் கொண்டு பணிப்பாய்வுகள் (workflows), வாடிக்கையாளர் வாக்குறுதிகள் மற்றும் பட்ஜெட் முன்னறிவிப்புகளைக் கட்டமைத்திருப்பீர்கள்.

அதனால்தான் Mancer 2, Novita மற்றும் StreamLake ஆகியவற்றின் சமீபத்திய விலை மாற்றங்கள் அடுத்த காலாண்டிற்குப் பதில் இப்போதே உங்கள் கவனத்தைப் பெற வேண்டியவை. இந்தத் தளங்களில் எதுவும் திடீரென பத்து மடங்கு உயர்வு போன்ற செய்திகளில் வரவில்லை, ஆனால் பல வழங்குநர்களிடையே ஏற்படும் படிப்படியான மாற்றங்கள் விரைவாகக் கூட்டுப் பலனைத் தரும். நீங்கள் உற்பத்திப் பணிகளை (production workloads) நடத்துகிறீர்கள் என்றால், அடிக்கடி ஃபைன்-டியூன் (fine-tune) செய்கிறீர்கள் அல்லது பல API-கள் வழியாகப் போக்குவரத்தை வழிநடத்துகிறீர்கள் என்றால், ஒரு சிறிய விகிதச் சரிசெய்தல் கூட உங்கள் யூனிட் எகனாமிக்ஸை (unit economics) மாற்றக்கூடும்.

பெரிய அளவில் சிறிய விலை மாற்றங்கள் ஏன் முக்கியம்

பெரும்பாலான பொறியியல் குழுக்கள் தரம் மற்றும் லேட்டன்சி (latency) அளவுகோல்களின் அடிப்படையில் ஒரு பெரிய மொழி மாதிரி (large language model) API-யைத் தேர்ந்தெடுக்கின்றன. செலவு பற்றிய விவாதம் நடக்கும், ஆனால் அது பெரும்பாலும் ஒரு நிலையான குறிப்புப் பொருளாகவே (static footnote) கருதப்படுகிறது. உண்மையில், விலை என்பது உங்கள் ஸ்டேக்கில் (stack) உள்ள மிகவும் மாறும் மாறிகளில் ஒன்றாகும். டோக்கன் அடிப்படையிலான கட்டணம் (Token-based billing) என்பது உங்கள் செலவுகள் பயன்பாட்டிற்கு ஏற்ப நேர்க்கோட்டில் (linearly) அதிகரிப்பதைக் குறிக்கிறது, ஆனால் அவை உங்கள் செயல்பாடுகளுடனும் (behavior) அதிகரிக்கின்றன. நீண்ட சிஸ்டம் ப்ராம்ப்ட்கள் (system prompts), கனமான JSON வெளியீட்டு ஸ்கீமாக்கள் (JSON output schemas) மற்றும் சாட் ஹிஸ்டரி (chat history) சேமிப்பு ஆகியவை டோக்கன் எண்ணிக்கையை அதிகரிக்கின்றன. ஒரு வழங்குநர் தனது விகித அட்டையை (rate card) மாற்றும்போது, அதன் தாக்கம் ஒரு நிலையான கட்டண உயர்வு மட்டுமல்ல. அது ஒவ்வொரு எதிர்காலத் தொடர்பிலும் ஒரு பெருக்கணியாக (multiplier) அமைகிறது.

Mancer 2, Novita மற்றும் StreamLake ஆகியவை இன்ஃபரன்ஸ் சந்தையில் (inference market) வெவ்வேறு இடத்தைப் பிடித்துள்ளன, மேலும் மூன்றிலும் சமீபத்தில் செய்யப்பட்ட மாற்றங்கள், ஒரு காலத்தில் API செலவிற்காக எளிய ஸ்பிரெட்ஷீட்டை (spreadsheet) மட்டுமே நம்பியிருந்த டெவலப்பர்கள் இப்போது மிகவும் தீவிரமான கண்காணிப்பு உத்தியை (monitoring strategy) மேற்கொள்ள வேண்டியதன் அவசியத்தைக் காட்டுகின்றன. இந்தத் تحدேதல்களைச் சிறிய நிர்வாகக் குறிப்புகளாக நீங்கள் கருதினால், உங்கள் மாதாந்திர விலைப்பட்டியல் (invoice) வந்த பின்னரே அதன் தாக்கத்தைக் கண்டறியும் அபாயத்தில் நீங்கள் இருப்பீர்கள்.

என்ன மாறியுள்ளது, எங்கு தேட வேண்டும்

Mancer 2 மாற்றங்கள்

Mancer 2 அதன் எண்ட்பாயிண்ட்களுக்கான (endpoints) பட்ஜெட்டை நீங்கள் எவ்வாறு திட்டமிடுகிறீர்கள் என்பதைப் பாதிக்கும் வகையில் விலை மாற்றங்களைச் செயல்படுத்தியுள்ளது. நீங்கள் தற்போது உற்பத்திப் போக்குவரத்திற்கு (production traffic) Mancer 2-ஐப் பயன்படுத்தினால், முதலில் சரிபார்க்க வேண்டியது அந்த மாற்றம் இன்புட் டோக்கன்கள் (input tokens), அவுட்புட் டோக்கன்கள் (output tokens) அல்லது இரண்டையும் பாதிக்கிறதா என்பதாகும். சில வழங்குநர்கள் உருவாக்கும் பக்கத்தின் (generation-side) விலையை மட்டுமே மாற்றியமைக்கிறார்கள், இது நீண்ட, கட்டமைக்கப்பட்ட வெளியீடுகளைத் தரும் பயன்பாடுகளைப் பாதிக்கிறது. மற்றவர்கள் ப்ராம்ப்ட் பக்கத்தின் (prompt side) செலவை உயர்த்துகிறார்கள், இது விரிவான ஃபியூ-ஷாட் ப்ராம்ப்டிங் (few-shot prompting) அல்லது பெரிய கான்டெக்ஸ்ட் இன்ஜெக்ஷன்களைப் (context injections) பாதிக்கிறது. குறிப்பிட்ட விவரங்களைப் படிக்காமல், அதன் தாக்கம் சீராக இருக்கும் என்று நீங்கள் assumptions செய்ய முடியாது. உங்கள் பயன்பாட்டு வழக்குகள் (use cases) எதில் அதிக செலவு செய்கின்றன என்பதைப் பார்க்க, புதிய விகித அட்டையுடன் உங்கள் சொந்த லாகிங் தரவை (logging data) ஒப்பிட்டுப் பாருங்கள்.

Novita விலை மாற்றங்கள்

Novita-வும் தனது விகிதங்களை மாற்றியுள்ளது. பெரிய கிளவுட் API-களுக்கு மாற்றாக செலவு குறைந்த தேர்வாக Novita-வைப் பயன்படுத்தும் குழுக்களுக்கு, மில்லியன் கணக்கில் பயன்பாடு அதிகரிக்கும் போது, ஒரு சிறிய சென்ட்-பெர்-தௌசண்ட்-டோக்கன் (cent-per-thousand-tokens) மாற்றம் கூட முக்கியமானது. மேலாண்மை செய்யப்பட்ட பிளாட்ஃபார்ம் பிரீமியம் (managed platform premiums) சுமை இல்லாமல் அதிகத் திறன் (high throughput) தேவைப்படும் திட்டங்களுக்கு Novita-வின் உள்கட்டமைப்பு பெரும்பாலும் ஈர்க்கிறது. அந்த கணக்கீடு மாறும்போது, நீங்கள் உங்கள் கோரிக்கைக்கான செலவு மாதிரிகளை (per-request cost models) மீண்டும் இயக்க வேண்டும். குறிப்பாக Novita அடுக்கு விலை முறையை (tiered pricing) அறிமுகப்படுத்தியுள்ளதா, மொத்த இன்ஃபரன்ஸ் தள்ளுபடிகளை (bulk-inference discounts) மாற்றியுள்ளதா அல்லது இலவசத் திட்டக் கட்டுப்பாடுகளை (free-tier limitations) மறுசீரமைத்துள்ளதா என்பதைப் பாருங்கள். இவற்றில் ஏதேனும் ஒன்று, ஒரு பணிப்பாய்வை (workload) எச்சரிக்கையின்றி "மிகக் குறைந்த விலை விருப்பத்திலிருந்து" "நடுத்தர நிலையில்" மாற்றக்கூடும்.

StreamLake மாற்றங்கள்

StreamLake தனது சொந்த மாற்றங்களுடன் இந்தத் தொடரை நிறைவு செய்கிறது. StreamLake உங்கள் மீடியா-ரிச் (media-rich) அல்லது நீண்ட கான்டெக்ஸ்ட் (long-context) பணிப்பாய்வுகளைக் கையாள்கிறது என்றால், புதிய விகிதங்களை உங்கள் வரலாற்று சராசரி அமர்வு நீளத்துடன் (historical average session length) ஒப்பிட்டுப் பாருங்கள். நீண்ட கான்டெக்ஸ்ட்களில் நிபுணத்துவம் பெற்ற வழங்குநர்கள் சில நேரங்களில் நீட்டிக்கப்பட்ட வரிசைகளுக்கான (extended sequences) கட்டண முறையை மாற்றுகிறார்கள், இதன் பொருள் உங்கள் மிகவும் விலையுயர்ந்த கோரிக்கைகள் அதிகம் பாதிக்கப்படலாம். ஒரு தலைப்புச் செய்தியாக வரும் சதவீத மாற்றம் உங்கள் உண்மையான பாதிப்பைக் காட்டுகிறது என்று assumptions செய்யாதீர்கள். கடந்த மாதத்தின் கோரிக்கைகளில் ஒரு பிரதிநிதித்துவ மாதிரியை (representative sample) எடுத்து, புதிய ஸ்கீமாவைப் பயன்படுத்தி அவற்றை மீண்டும் கணக்கிடுங்கள்.

Dev.to-வில் உள்ள Narev-ன் விரிவான விளக்கத்தில் முழு விகித அட்ட ஒப்பீடு மற்றும் புதுப்பிப்பு காலவரிசையைப் பார்க்கலாம். அதை உங்கள் சொந்தக் கணக்கீட்டிற்கு மாற்றாகப் பயன்படுத்தாமல், ஒரு குறுக்கு-குறிப்பிற்காக (cross-reference) மட்டும் பயன்படுத்தவும்.

தேவையற்ற குழப்பங்கள் இன்றி ஒரு விலை மாற்றத்தைப் படிப்பது எப்படி

ஒரு API வழங்குநர் புதிய விகிதங்களை அறிவிக்கும் போது, சந்தைப்படுத்தல் மொழி (marketing language) பொதுவாக அணுகல் மற்றும் செயல்திறனை (accessibility and performance) வலியுறுத்தும். அதைத் தவிர்க்கவும். மூன்று உறுதியான கேள்விகளில் கவனம் செலுத்துங்கள்.

முதலாவதாக, இந்தத் திருத்தம் உள்ளீட்டு விலை (input pricing), வெளியீட்டு விலை (output pricing) அல்லது எம்பெடிங் (embedding) அல்லது ஃபைன்-டியூனிங் (fine-tuning) போன்ற துணைக்கட்டணங்களை மாற்றுகிறதா? உங்கள் சொந்த டெலிமெட்ரியையும் (telemetry) அதே அச்சுகளின் அடிப்படையில் பிரிக்கவும். உங்கள் செலவில் 80 சதவீதம் வெளியீட்டு உருவாக்கத்திற்காக (output generation) செலவிடப்பட்டு, வழங்குநர் உள்ளீட்டு விலையை மட்டுமே உயர்த்தியிருந்தால், உங்களுக்குப் பெரிய பாதிப்பு இருக்காது. நீங்கள் மிகப்பெரிய உள்ளீடுகளிலிருந்து சிறிய வெளியீடுகளை வழங்கும் சுருக்கச் செயல்பாடுகளை (summarization pipelines) இயக்கினால், அதற்கு நேர்மாறான நிலை இருக்கும்.

இரண்டாவதாக, ரேட் லிமிட்கள் (rate limits) அல்லது த்ரூபுட் நிலைகள் (throughput tiers) மாறியுள்ளதா? சில நேரங்களில், ஒரு வழங்குநர் டோக்கன் வாரியான விலையை மாற்றாமல் வைத்திருப்பார், ஆனால் இலவச கன்கரன்சி நிலையை (free concurrency tier) குறைப்பார் அல்லது புதிய வரிசை கட்டணங்களை (queueing charges) அறிமுகப்படுத்துவார். இது நேரடியாக லேட்டன்சி (latency) மற்றும் உள்கட்டமைப்புச் செலவில் (infrastructure cost) மாற்றத்தை ஏற்படுத்தும்.

மூன்றாவதாக, புதிய செலவுக் கட்டுப்பாட்டு கருவிகள் உள்ளனவா? நீங்கள் உங்கள் அழைப்புகளை (calls) மறுசீரமைத்தால், விலை உயர்வுடன் சேர்த்து வழங்கப்படும் ப்ராம்ப்ட்-கேச்சிங் (prompt-caching) தள்ளுபடி அல்லது பேட்ச்-இன்ஃபரன்ஸ் (batch-inference) தள்ளுபடி உங்களுக்கு உண்மையில் உதவக்கூடும். தலைப்புச் செய்தியில் வரும் எண் முழுமையான உண்மையைச் சொல்லாது.

செலவுகள் மாறும்போது உங்கள் ஸ்டேக்கை (stack) கணிக்கக்கூடியதாக வைத்திருத்தல்

நீங்கள் வழங்குநரின் விலையை முடக்கிவிட முடியாது, ஆனால் ஒவ்வொரு காலாண்டிலும் குறியீட்டை (code) மீண்டும் எழுதாமல் மாற்றங்களை உள்வாங்கிக் கொள்ளும் அமைப்புகளை நீங்கள் உருவாக்க முடியும்.

கோரிக்கை வழிசெலுத்தலில் (request routing) இருந்து தொடங்குங்கள். உங்கள் கட்டமைப்பில் Mancer 2, Novita மற்றும் StreamLake ஆகியவை வெவ்வேறு பணிகளைச் செய்கின்றன என்றால், போக்குவரத்தை (traffic) விரைவாக மாற்றியமைக்க செலவு-செயல்திறன் சமநிலையை (cost-performance trade-off) முறைப்படுத்துங்கள். ஆறு மாதங்களுக்கு முன்பு 20 சதவீதம் அதிக செலவு செய்த ஒரு மாற்று மாதிரி (fallback model), சமீபத்திய புதுப்பிப்புகளுக்குப் பிறகு இப்போது மலிவான விருப்பமாக இருக்கலாம். நேரடி விலையைக் கருத்தில் கொள்ளும் ரூட்டர் (router) இல்லையென்றால், நீங்கள் பணத்தை வீணடிக்கிறீர்கள் என்று அர்த்தம்.

அடுத்து, உங்கள் சூழலைச் (context) சுருக்குங்கள். பழக்கத்தின் காரணமாக ஒவ்வொரு கோரிக்கையிலும் ஆயிரக்கணக்கான டோக்கன்களை அனுப்பும்போது விலை மாற்றங்கள் அதிக பாதிப்பை ஏற்படுத்தும். தேவையற்ற சிஸ்டம் அறிவுறுத்தல்கள் (system instructions), அதிகப்படியான விவரங்களைக் கொண்ட ஸ்கீமாக்கள் (verbose schemas) மற்றும் சுருக்கப்படாத உரையாடல் வரலாறு (uncompressed chat history) ஆகியவற்றிற்காக உங்கள் ப்ராம்ப்ட்களை (prompts) ஆய்வு செய்யுங்கள். உள்ளீட்டு நீளத்தை 30 சதவீதம் குறைப்பது, 30 சதவீத விலை உயர்வைச் சமன் செய்யும். இது வழங்குநர்களை மாற்றுவதை விட பெரும்பாலும் வேகமானது.

தீவிரமாக கேச் (Cache) செய்யுங்கள். ஒரு கேச் அடுக்கைப் (cache layer) பராமரிப்பதை விட, ஒரே மாதிரியான அல்லது கிட்டத்தட்ட ஒரே மாதிரியான ப்ராம்ப்ட்களை மீண்டும் அனுப்புவது எளிது என்பதால் பல குழுக்கள் அவ்வாறு செய்கின்றன. விலை மாறும்போது, அந்தத் தயக்கம் விலையுயர்ந்ததாக மாறும். உங்கள் பயன்பாட்டு முறை அனுமதிக்கும்போது, சமீபத்திய முடிவுகள் (completions) மற்றும் எம்பெடிங்குகளைச் (embeddings) சேமித்து வையுங்கள், குறிப்பாக StreamLake அல்லது Novita எண்ட்-பாயிண்ட்கள் (endpoints) மூலம் இயங்கும் பகுப்பாய்வு அல்லது திரும்பத் திரும்பச் செய்யப்படும் பணிகளுக்கு இது உதவும்.

இறுதியாக, API பில் ஆய்வுக்கு (API bill review) ஒருவரைப் பொறுப்பேற்கச் செய்யுங்கள். இது முழுநேரப் பணியாக இருக்க வேண்டிய அவசியமில்லை, ஆனால் இது ஒரு வழக்கமான காலண்டர் நிகழ்வாக இருக்க வேண்டும். மாதத்திற்கு ஒருமுறை, கணிக்கப்பட்ட செலவை உண்மையான செலவோடு ஒப்பிட்டுச் சரிபார்க்கவும், விலையில் மாற்றம் ஏற்பட்ட எந்தவொரு வழங்குநரையும் அடையாளம் காணவும் மற்றும் மாற்றுத் தேர்வுகளுடன் செலவு ஒப்பீட்டை மீண்டும் செய்யவும். பொறுப்புணர்வு இல்லையென்றால், விலை மாற்றம் என்பது ஒரு கட்டமைப்புத் கடனாக (architectural debt) மாறிவிடும்.

விலைக் கட்டுப்பாட்டு முறையை உங்கள் செயல்முறையின் ஒரு பகுதியாக ஆக்குங்கள்

உள்கட்டமைப்பு குழுக்கள் ஏற்கனவே பாதுகாப்பு பேட்ச்கள் (security patches) மற்றும் சார்புநிலை புதுப்பிப்புகளை (dependency updates) ஒரு கால அட்டவணையின்படி ஆய்வு செய்கின்றன. விலையும் அதே சரிபார்ப்புப் பட்டியலில் இருக்க வேண்டும். Mancer 2, Novita மற்றும் StreamLake ஆகியவற்றின் சமீபத்திய மாற்றங்கள் விதிவிலக்குகள் அல்ல. இன்ஃபரன்ஸ் சந்தை (inference market) இன்னும் தனது சமநிலையைக் கண்டறிந்து கொண்டிருக்கிறது என்பதற்கான சான்றுகள் இவை. புதிய வன்பொருள் (hardware), மேம்படுத்தப்பட்ட இன்ஃபரன்ஸ் என்ஜின்கள் (optimized inference engines) மற்றும் மாறிவரும் தேவை ஆகியவை வரும் காலங்களிலும் விலை அட்டைகளில் மாற்றங்களை ஏற்படுத்தும்.

இதைச் சிறப்பாகக் கையாளும் குழுக்கள் ஒவ்வொரு மாற்றத்தையும் முன்கூட்டியே கணிக்க மாட்டார்கள். அவர்கள் வெறும் கண்காணிப்பை (visibility) மட்டுமே பராமரிப்பார்கள். எந்த எண்ட்-பாயிண்ட்களுக்கு (endpoints) எவ்வளவு செலவாகிறது, எந்தப் பணிகள் நெகிழ்வானவை (elastic), மற்றும் கணக்கீடுகள் மாறும்போது போக்குவரத்தை எங்கு நகர்த்த வேண்டும் என்பது அவர்களுக்குத் தெரியும். அந்த ஒழுக்கம், ஒரு இடையூறு விளைவிக்கும் புதுப்பிப்பை ஒரு சாதாரண கட்டமைப்பு மாற்றமாக (routine configuration tweak) மாற்றுகிறது.

இதே போன்ற மாற்றங்களைச் சந்திக்கும் பிற உருவாக்குநர்களுடன் (builders) கருத்துக்களைப் பகிர்ந்து கொள்ள ஒரு இடத்தைத் தேடுகிறீர்கள் என்றால், GyaanSetu கற்றல் சமூகம் (learning community) உங்களுக்காகத் திறந்திருக்கிறது. எங்களை டெலிகிராமில் (Telegram) நீங்கள் காணலாம்.

சுருக்கமாகச் சொன்னால்: Mancer 2, Novita மற்றும் StreamLake ஆகியவற்றின் விலைகள் மாறியுள்ளன. நினைவாற்றலையோ அல்லது பழைய ஆவணங்களையோ நம்பியிருக்க வேண்டாம். உங்கள் லாக்ஸ்களைப் (logs) பெற்று, அவற்றை புதிய விலைகளுடன் ஒப்பிட்டுப் பார்த்து, உங்கள் தற்போதைய வழிசெலுத்தல் (routing) இன்னும் நிதி ரீதியாகச் சரியாக இருக்கிறதா என்பதைத் தீர்மானிக்கவும். கடந்த மாதம் மலிவானதாக இருந்த மாதிரி இன்று மலிவாக இருக்கும் என்று சொல்ல முடியாது.