ஏன் செலவு அதிகரித்தது

குழு முதன்முதலில் generative AI-ஐச் சேர்த்தபோது, ஒவ்வொரு பயனர் கோரிக்கையையும் புதிய மற்றும் மிகவும் திறன்மிக்க மாடலுக்கு (model) அனுப்பினார்கள். போக்குவரத்து (traffic) அதிகரித்த隨著, கோரிக்கைக்கான செலவும் அதற்கேற்ப அதிகரித்தது, மேலும் CFO-வின் ஸ்பிரெட்ஷீட்டில் செலவு பயனர் வளர்ச்சியைக் காட்டிலும் வேகமாக அதிகரிப்பதைக் காட்டியது. வழக்கமான விரைவுத் தீர்வு—"குறைந்த விலையுள்ள மாடலைப் பயன்படுத்து"—நடைமுறைச் செயல்பாட்டில் (production) தோல்வியடைகிறது, ஏனெனில் வெவ்வேறு வினவல்களுக்கு (queries) வெவ்வேறு அளவிலான பகுத்தறிவுத் திறன் தேவைப்படுகிறது. உண்மையான தீர்வானது கோரிக்கை எப்படி அனுப்பப்படுகிறது என்பதில் உள்ளது, எப்போதும் எந்த மாடல் பயன்படுத்தப்படுகிறது என்பதில் இல்லை.

பணத்தைச் சேமிக்கும் ஒரு ரூட்டிங் லேயரை (routing layer) உருவாக்குதல்

பொறியாளர் அந்த inference service-ஐ மற்ற உற்பத்தி கூறுகளின் (production components) போலவே கருதினார்: நிலைகளை (tiers) வரையறுத்தல், SLAs மற்றும் லேட்டன்சி பட்ஜெட்களை (latency budgets) நிர்ணயித்தல். இதன் விளைவாக உருவான கட்டமைப்பில் நான்கு முக்கியப் பகுதிகள் உள்ளன, அவை இணைந்து 95% செலவுக் குறைப்பைத் தருகின்றன.

நிலைகளாகப் பிரிக்கப்பட்ட ரூட்டிங் (Tiered routing)

ஒரு மெல்லிய முன்முனை (thin front-end) வரும் ஒவ்வொரு கோரிக்கையையும் அதன் கடினத்தன்மையைக் கொண்டு வகைப்படுத்துகிறது. தோராயமாக 95% வினவல்கள் ஒரு சாதாரண மாடலை இயக்கும் "மலிவான" (cheap) நிலைக்குச் செல்கின்றன; கடினமான 5% வினவல்கள் மட்டுமே பிரீமியம் மாடலுக்கு மாற்றப்படுகின்றன (escalated). இந்த வகைப்பாடு விதிகளின் அடிப்படையிலோ (உதாரணமாக: நீளம், குறிப்பிட்ட துறை சார்ந்த முக்கிய வார்த்தைகள்) அல்லது முந்தைய தரவுகளிலிருந்து கற்றுக் கொண்ட முறையிலோ இருக்கலாம். குறைந்த செலவு நிலையைத் தொடக்க நிலையாகப் பயன்படுத்துவதன் மூலம், சாட்போட்டின் (chatbot) மாதாந்திரச் செலவு $420-லிருந்து $28 ஆகக் குறைந்தது.

மாடலைச் சரியாகத் தேர்ந்தெடுத்தல் (Model right-sizing)

பணிகளுக்குத் தேவையான மாடலின் திறனைச் சரியாகப் பொருத்துவதே மிகப்பெரிய சேமிப்பைத் தருகிறது:

  • எளிய அரட்டை (Simple chat) – முதன்மையான மாடலுக்குப் பதிலாக ஒரு இலகுரக மாடலைப் பயன்படுத்துதல் (97.5% சேமிப்பு).
  • வகைப்பாடு (Classification) – நடுத்தர அளவிலான மாடலுக்குப் பதிலாக மலிவான மாடலைப் பயன்படுத்துதல் (98.3% சேமிப்பு).
  • சுருக்கம் செய்தல் (Summarization) – உயர்தர மாடலுக்குப் பதிலாக நடுத்தரத் தர மாடலைப் பயன்படுத்துதல் (97.2% சேமிப்பு).

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

புத்திசாலித்தனமான கேச்சிங் (Smart caching)

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

பிராம்ப்ட் சுருக்கம் (Prompt compression)

நீண்ட பிராம்ப்ட்கள் (prompts) டோக்கன் பயன்பாட்டை அதிகரிக்கின்றன, இது நேரடியாகச் செலவை உயர்த்துகிறது. குழுவினர் கிளையண்ட் பக்கத்திலோ அல்லது முன்-செயலாக்க (pre-processing) நிலையிலோ ஒரு மலிவான சுருக்கி (summarizer) மூலம், 2,000 டோக்கன்கள் கொண்ட சூழலை (context) விலையுயர்ந்த மாடலைச் சென்றடைவதற்கு முன்பே சுமார் 400 டோக்கன்களாகச் சுருக்குகிறார்கள். இந்த டோக்கன் குறைப்பு அனைத்து கோரிக்கைகளிலும் பலமடங்கு சேமிப்பைத் தருகிறது, மேலும் இது பயனரின் அனுபவத்தை மாற்றாமல் பெரும் சேமிப்பை வழங்குகிறது.

மூலோபாய பேட்சிங் (Strategic batching)

பேட்சிங் (Batching) என்பது பல தனித்தனி கோரிக்கைகளை ஒரே API அழைப்பாக ஒருங்கிணைக்கிறது. இதன் எளிமையான விதி: ஒரு பயனர் பதிலுக்காகக் காத்திருந்தால், பேட்சிங் செய்ய வேண்டாம்; கோரிக்கை பின்னணியில் (background) இயங்கினால் (இரவு நேர அறிக்கைகள், திட்டமிடப்பட்ட வேலைகள்), அனைத்தையும் பேட்சிங் செய்யலாம். இரவு நேர பேட்சிங் வேலைகள் மட்டுமே செலவில் மேலும் 10-20% குறைவை ஏற்படுத்துகின்றன.

உகப்பாக்க சுழற்சியைக் கண்காணித்தல் (Monitoring the optimization loop)

நீங்கள் அளவிடாத ஒன்றைத் தரம் உயர்த்த முடியாது. பொறியாளர் நான்கு வாராந்திர அளவீடுகளை (metrics) அமைத்தார்:

  1. நிலைகளின் அடிப்படையில் கோரிக்கைக்கான செலவு.
  2. ஒவ்வொரு ரூட்டிங் பாதையின் கேச்-ஹிட் விகிதம் (cache-hit rate).
  3. மலிவான நிலையிலிருந்து பிரீமியம் நிலைக்கு மாறும் விகிதம் (escalation rate).
  4. ஒவ்வொரு வாடிக்கையாளர் பிரிவிற்கான செலவு.

இந்த எண்கள் விலகல்களை (drift) கண்டறிய உதவுகின்றன—உதாரணமாக, உயரும் எஸ்கலேஷன் விகிதம், வகைப்பாட்டுத் தர்க்கம் (classification logic) மிகவும் தீவிரமாக உள்ளது அல்லது மலிவான மாடலின் தரம் குறைந்துவிட்டது என்பதைக் குறிக்கலாம். குழு ஒவ்வொரு வாரமும் வரம்புகள் (thresholds), மாடல் ஒதுக்கீடுகள் மற்றும் கேச் கொள்கைகளைச் சீரமைப்பதன் மூலம், செலவுக் கட்டுப்பாட்டை ஒரு நெருக்கடி காலத் தீர்வாகப் பார்க்காமல், ஒரு வழக்கமான பழக்கமாக மாற்றுகிறது.

முக்கியக் கருத்து (Takeaway)

கோரிக்கைகளை வகைப்படுத்தும், மாடல்களைச் சரியாகத் தேர்ந்தெடுக்கும், தீவிரமாக கேச் செய்யும், பிராம்ப்ட்களைச் சுருக்கும் மற்றும் பின்னணி வேலைகளை பேட்சிங் செய்யும் ஒரு ஒழுக்கமான ரூட்டிங் லேயர், நம்பகத்தன்மையைத் தக்கவைத்துக் கொண்டே AI-API செலவை 95% வரை குறைக்க முடியும். இன்ஃபரன்ஸ் ஸ்டேக்கை (inference stack) ஒரு புரொடக்ஷன் சேவையாகக் கருதுங்கள்: நிலைகளை வரையறுக்கவும், முடிவுகளை அளவிடவும் மற்றும் வாரந்தோறும் மேம்படுத்தவும்.