Microsoft, Azure API Management (APIM)-இல் ஒரு பிரத்யேகமான AI Gateway tier-ஐச் சேர்த்துள்ளது. இந்த நடவடிக்கை, LLM அழைப்புகள் (calls) இனி வெறும் மற்றொரு API endpoint மட்டுமல்ல, அவை ஒரு தனித்துவமான பணிச்சுமை (workload) எனக் கருதப்படுகின்றன என்பதைக் குறிக்கிறது.
ஏன் LLM டிராஃபிக் பாரம்பரிய கேட்வேகளுக்கு சவாலாக உள்ளது
ஒரு தனிப்பட்ட ப்ராம்ப்ட் (prompt), மற்றொன்றை விட நூறு மடங்கு அதிகச் செலவை ஏற்படுத்தலாம், ஆனால் ஒரு சாதாரண API கேட்வே இவை இரண்டையும் ஒரே மாதிரியான ஒரு கோரிக்கையாகவே (request) பார்க்கும். கேட்வே என்பது அழைப்புகளை (calls) மட்டுமே கணக்கிடுகிறதே தவிர, மாடல் செயலாக்கும் டோக்கன்களின் (tokens) எண்ணிக்கையைக் கணக்கிடுவதில்லை. சில நூறு டோக்கன்களை அனுப்பும் ஒரு கோரிக்கையும், பல ஆயிரம் டோக்கன்களை அனுப்பும் ஒரு கோரிக்கையும் ஒரே மாதிரியான கோரிக்கை-எண்ணிக்கை அளவீடுகளைக் (request-count metrics) காட்டுகின்றன, ஆனால் இரண்டாவதாகக் குறிப்பிட்ட கோரிக்கையின் செலவு பல மடங்கு அதிகமாக இருக்கலாம்.
கோரிக்கை அடிப்படையிலான வரம்புகள் (request-based limits) AI-க்கு பயனற்றதாக மாறுவதற்கு நான்கு காரணங்கள் உள்ளன:
- செலவு ≠ கோரிக்கை எண்ணிக்கை. பில்லிங் என்பது நீங்கள் செய்யும் HTTP அழைப்புகளைப் பொறுத்தது அல்ல, அது டோக்கன்களைப் பொறுத்தது.
- டோக்கன் அளவு பெரிதும் மாறுபடும். ஒரு வினவல் (query) சிறிய கேள்வியாக இருக்கலாம்; மற்றொன்று ஒரு நீண்ட ஆவணத்தைக் கொண்டிருக்கலாம்.
- மாடல் தேர்வு விலையை மாற்றுகிறது. வெவ்வேறு LLM-கள் ஒரு டோக்கனுக்கான வெவ்வேறு கட்டணங்களை வசூலிக்கின்றன.
- ஸ்ட்ரீமிங் (Streaming) இறுதிப் பட்டியலை மறைக்கிறது. பதில்கள் ஸ்ட்ரீமிங் செய்யப்படும்போது, ஸ்ட்ரீமிங் முடியும் வரை மொத்த டோக்கன் எண்ணிக்கை தெரியாது.
நீங்கள் கோரிக்கைகளை மட்டுமே தொடர்ந்து அளவிட்டுக் கொண்டிருந்தால், உங்கள் உண்மையான செலவைப் பற்றிய எந்தத் தகவலையும் வழங்காத கண்காணிப்புத் தரவுகளையே (monitoring data) நீங்கள் பெறுவீர்கள்.
AI Gateway tier என்ன மாற்றங்களை ஏற்படுத்துகிறது
டோக்கன் பயன்பாட்டைக் கட்டுப்படுத்தத் தேவையான பெரும்பாலான கொள்கைகள் (policies) ஏற்கனவே நிலையான APIM tiers-இல் உள்ளன—அவை XML விதிகளாக எழுதப்பட்டு தனிப்பயனாக்கப்பட்ட டேஷ்போர்டுகளில் (custom dashboards) காட்டப்படுகின்றன. AI tier அதே திறன்களை ஒரு பிரத்யேக அனுபவமாக ஒருங்கிணைக்கிறது:
- AI டிராஃபிக்கிற்கான தனிமைப்படுத்தப்பட்ட அளவிடுதல் (Isolation of scaling).
- கைமுறையாக உருவாக்கப்பட்ட XML கொள்கைகளின் தேவையை நீக்கும் எளிமைப்படுத்தப்பட்ட கட்டமைப்பு (Simplified configuration).
இதன் முக்கிய மாற்றம் செயல்பாட்டு ரீதியானது (operational): டோக்கன் பட்ஜெட்டுகளை அமல்படுத்த நீங்கள் இனி சிக்கலான குறியீடுகளை (code) எழுதவோ அல்லது தனித்தனி டேஷ்போர்டுகளைப் பராமரிக்கவோ வேண்டியதில்லை. இந்த tier அந்த கட்டுப்பாடுகளுக்கான ஒரு தயார்நிலை இடைமுகத்தை (ready-made interface) வழங்குகிறது.
எப்போது மாற வேண்டும் – டிராஃபிக் அடிப்படையிலான வழிகாட்டி
- AI உங்கள் டிராஃபிக்கில் ஒரு சிறிய பகுதி மட்டுமே. உங்கள் தற்போதைய APIM tier-ஐத் தொடர்ந்து பயன்படுத்துங்கள் மற்றும் நுணுக்கமான கட்டுப்பாடுகள் தேவைப்பட்டால் டோக்கன் கொள்கைகளைச் சேர்க்கவும்.
- AI உங்கள் அழைப்புகளில் ஆதிக்கம் செலுத்துகிறது. அளவிடுதலைத் தனிமைப்படுத்தவும் மற்றும் செலவு நிர்வாகத்தை (cost governance) சீராக வைத்திருக்கவும் AI tier-க்கு மாறவும்.
- நீங்கள் பொறியியல் பணிச்சுமையைத் (engineering overhead) தவிர்க்க விரும்புகிறீர்கள். இந்த tier-இல் உள்ள உள்ளமைக்கப்பட்ட கருவிகள், தனிப்பயனாக்கப்பட்ட கொள்கைகளை உருவாக்குவதற்கும் பராமரிப்பதற்கும் செலவிடப்படும் நேரத்தைக் குறைக்கின்றன.
மிகப்பெரிய செலவு சந்தா விலை (subscription price) அல்ல; ஒரு பொதுவான கேட்வே டோக்கன் பொருளாதாரத்தைப் புரிந்துகொள்ளச் செய்வதற்காக, அதில் உள்ள இடைவெளிகளைச் சரிசெய்யச் செலவிடப்படும் பொறியியல் நேரமே ஆகும்.
முன்னோட்டக் கட்ட (Preview-phase) செயல்முறைத் திட்டம்
Microsoft இன்னும் AI tier-ஐ முன்னோட்ட நிலையிலேயே (preview) வழங்குகிறது. இதை ஒரு சோதனைத் தளமாக (testbed) கருதுங்கள், நேரடிப் பயன்பாட்டுத் தொடக்கமாக (production launch) கருத வேண்டாம்.
- அதிக அளவிலான உள் AI பணிச்சுமையைத் (internal AI workload) தேர்ந்தெடுக்கவும். அதிகப்படியான டோக்கன் டிராஃபிக்கை உருவாக்கும் சேவையைத் தேர்ந்தெடுக்கவும்.
- அந்தப் பணிச்சுமையை AI tier வழியாக வழிநடத்தவும் (Route). ஒவ்வொரு பயனரின் டோக்கன் பயன்பாட்டையும் கண்டறிய புதிய கட்டமைப்பைப் பயன்படுத்தவும்.
- சில வாரங்களுக்கு டோக்கன் செலவுத் தரவுகளைச் சேகரிக்கவும். டோக்கன் எண்ணிக்கை மற்றும் அதனுடன் தொடர்புடைய செலவுகளை உங்கள் தற்போதைய கண்காணிப்புடன் ஒப்பிட்டுப் பார்க்கவும்.
- பட்ஜெட் திட்டமிடலுக்கு இந்த அடிப்படைத் தரவைப் (baseline) பயன்படுத்தவும். இந்த tier-இன் செலவுக் கட்டுப்பாட்டு நன்மைகள் அதன் முன்னோட்டக் கட்டக் கட்டுப்பாடுகளை விட அதிகமாக உள்ளனவா என்பதைத் தீர்மானிக்கவும்.
இது பொதுவான பயன்பாட்டிற்கு (general availability) வரும் வரை, மிக முக்கியமான நேரடிப் பணிச்சுமைகளை (mission-critical production workloads) முன்னோட்டச் சேவைக்கு மாற்ற வேண்டாம்.
மாற்றுக்கருத்து: அனைவருக்கும் தனித்த Tier தேவையில்லை
உங்கள் நிறுவனம் அவ்வப்போது மட்டுமே LLM-க்கு அழைப்புகளைச் செய்கிறது என்றால், AI tier-இன் கூடுதல் செலவு நியாயமானதாக இருக்காது. தற்போதுள்ள கொள்கை கட்டமைப்பைக் கொண்டே (policy framework) டோக்கன் அளவிலான நிர்வாகத்தை நீங்கள் அடைய முடியும், ஆனால் அதற்கு அதிக நேரடி உழைப்பு தேவைப்படும். AI டிராஃபிக் உங்கள் API பரப்பில் ஒரு குறிப்பிடத்தக்க மற்றும் வளர்ந்து வரும் பகுதியாக இருக்கும்போது இந்த tier மிகவும் பயனுள்ளதாக இருக்கும்.
முடிவுரை
LLM டிராஃபிக் என்பது பாரம்பரிய API அழைப்பிலிருந்து முற்றிலும் மாறுபட்ட முறையில் செயல்படுகிறது என்பதை AI Gateway tier அங்கீகரிக்கிறது. கோரிக்கைகளை எண்ணுவதிலிருந்து டோக்கன் அடிப்படையிலான நிர்வாகத்திற்கு மாறுவதன் மூலம், தனிப்பயனாக்கப்பட்ட குறியீடுகளில் மூழ்கிவிடாமல், AI செலவைக் கட்டுப்படுத்த டெவலப்பர்களுக்கு ஒரு நடைமுறை வழியை இது வழங்குகிறது. ஏற்கனவே கணிசமான அளவில் AI பயன்பாட்டைக் கொண்ட அல்லது வளரத் தொடங்கும் குழுக்களுக்கு, இப்போது முன்னோட்ட நிலையைச் சோதிப்பது டோக்கன் செலவுக்கான ஒரு அடிப்படைத் தரவை (baseline) உருவாக்க உதவும்.