ஒரு தயாரிப்புத் தரத்திலான இன்ஃபரன்ஸ் சேவையை (inference service) உருவாக்கிய குழு, DigitalOcean Inference-இல் ஆறு மொழி மாதிரிகளை (language models) 48 மணிநேரம் இயக்கின. மாதம் $0.20 செலவாகும் "tiny" மாதிரி, விலையுயர்ந்த மற்ற விருப்பங்களை விடச் சிறப்பாகச் செயல்பட்டது. இது அவர்களின் droplets-இன் 8 GB நினைவக வரம்பிற்குள்ளேயே இருந்தது மற்றும் 70 B மாடலை முடக்கிய செயலிழப்புகளைத் (crashes) தவிர்த்தது; மேலும் மிகக் குறைந்த செலவில் பயனுள்ள தாமத நேரத்தையும் (latency) துல்லியத்தையும் வழங்கியது.
இந்தச் சோதனை ஏன் முக்கியமானது
பெரிய மொழி மாதிரிகளை (LLMs) API-களாகப் பயன்படுத்தும் நிறுவனங்கள், பெரிய மற்றும் அதிக விலை கொண்ட மாதிரிகளே சிறந்த அனுபவத்தைத் தரும் என்று பெரும்பாலும் கருதுகின்றன. ஆனால் உண்மையில், தயாரிப்புச் சூழல்களில் (production environments) நினைவகம் (memory), ஒரே நேரத்தில் கையாளப்படும் கோரிக்கைகள் (concurrency) மற்றும் இயங்கும் நேரம் (uptime) ஆகியவற்றைச் சமநிலைப்படுத்த வேண்டியுள்ளது. காகித அளவில் சிறப்பாகத் தோன்றும் ஒரு மாதிரி, நினைவகம் இல்லாமலேயே செயலிழக்கும்போது (out-of-memory (OOM) kills) அல்லது தொடக்க நேரத் தாமதத்தின் (cold starts) போது சேவையை முடக்கும்போது ஒரு சுமையாக மாறிவிடும். இந்த நேரடிச் சோதனை, சாதாரண வன்பொருள்களிலும் (modest hardware) ஒரு மலிவான மாதிரி மட்டுமே நடைமுறைக்குச் சாத்தியமான விருப்பமாக இருக்க முடியும் என்பதைக் காட்டுகிறது.
ஆறு போட்டியாளர்கள்
| Model | Monthly Cost | Avg. Latency | Accuracy* | RAM Usage / Crash |
|---|---|---|---|---|
| mistral-tiny | $0.20 | 120 ms | 88 % | 1.2 GB |
| mistral-small | $0.80 | 180 ms | 91 % | 2.4 GB |
| mistral-medium | $2.50 | 250 ms | 93 % | 4.1 GB |
| mistral-large | $5.00 | 300 ms | 94 % | 6.8 GB |
| llama-70b | $8.00 | 450 ms | 95 % | CRASH |
| mixtral-8x7b | $10.00 | 500 ms | 96 % | CRASH |
*துல்லியம் (Accuracy) என்பது குழுவின் உள்நிலை அளவுகோல் தொகுப்பில் (internal benchmark suite) மாதிரிகளின் செயல்திறனைக் குறிக்கிறது.
"tiny" மாதிரியின் மாதாந்திரச் செலவு கால் டாலருக்கும் குறைவாக இருந்தது மற்றும் 8 GB நினைவக வரம்பிற்குள்ளேயே தங்கியிருந்தது. மிகப்பரிய இரண்டு மாதிரிகளான llama-70b மற்றும் mixtral-8x7b ஆகியவை அந்த வரம்பைத் தாண்டி, ஹோஸ்ட்டை (host) மீண்டும் மீண்டும் செயலிழக்கச் செய்தன; இதனால் அதிக துல்லியப் புள்ளிகளைக் கொண்டிருந்தாலும் அவை பயன்படுத்த முடியாததாகிவிட்டன.
பெரிய மாதிரிகளை முடக்கிய சிக்கல்கள்
- Hard-coded endpoints – அசல் கட்டமைப்பு (original architecture) ஒவ்வொரு கோரிக்கையையும் (request) ஒரே மாதிரிக்கே அனுப்பியது. அந்த மாதிரி தோல்வியடையும் போது, முழு API-யும் முடங்கியது.
- No memory caps – பெரிய மாதிரிகள் கிடைக்கக்கூடிய அனைத்து RAM-ஐயும் பயன்படுத்தின, இது எச்சரிக்கையின்றி OOM kills-ஐத் தூண்டியது.
- Cold-start latency – புதிய மாதிரிக்கான முதல்முறை கோரிக்கைகள் பல வினாடிகள் எடுத்தன, இது சேவையின் வேகத்தைக் குறைத்தது.
- Unbounded concurrency – ஒரே நேரத்தில் வந்த கோரிக்கைகளின் அதிகரிப்பு நினைவகம் மற்றும் CPU-வைச் சோர்வடையச் செய்து, முறையான தோல்விகளை (systemic failures) ஏற்படுத்தியது.
யதார்த்தமான சுமையின் கீழ் (realistic load) சேவை ஆன்லைனில் இருக்க முடியாவிட்டால், வெறும் செயல்திறன் எண்கள் எதற்கும் உதவாது.
டைனமிக் ரூட்டிங் (Dynamic Routing) தீர்வு
பொறியாளர்கள் மூன்று கொள்கைகளின் அடிப்படையில் கோரிக்கை பாதையை (request path) மாற்றியமைத்தனர்:
- Runtime model selection – ரூட்டர் (router) ஒரு நிலையான எண்ட்ஸ்பாயிண்டிற்கு (static endpoint) பதிலாக, ஒவ்வொரு கோரிக்கைக்கும் ஒரு மாதிரியைத் தேர்ந்தெடுக்கிறது.
- Hardware awareness – ஒவ்வொரு கோரிக்கைக்கும் ஒரு நினைவக வரம்பு (memory budget) வழங்கப்படுகிறது; மீதமுள்ள RAM-க்குள் பொருந்தக்கூடிய மாதிரிகளுக்கு மட்டுமே ரூட்டர் கோரிக்கையை அனுப்புகிறது.
- Fallback chains – தேர்ந்தெடுக்கப்பட்ட மாதிரி தோல்வியடைந்தாலோ அல்லது காலாவதியானாலோ (times out), ரூட்டர் தானாகவே அடுத்த சிறந்த மாதிரியுடன் மீண்டும் முயற்சிக்கிறது.
மாற்றியமைக்கப்பட்ட கட்டமைப்பு நான்கு உறுதியான பாதுகாப்பு நடவடிக்கைகளைச் சேர்க்கிறது:
- Bounded concurrency – ஒரு செமாஃபோர் (semaphore) இணையாகச் செய்யப்படும் இன்ஃபரன்ஸ்களைக் கட்டுப்படுத்துகிறது, இது நினைவகம் தீர்ந்துபோவதைத் தடுக்கிறது.
- Fail-fast timeouts – ஒவ்வொரு கோரிக்கைக்கும் கடுமையான காலக்கெடு (timers) நிர்ணயிக்கப்பட்டுள்ளது, இது மெதுவான மாதிரிகள் முழுச் செயல்பாட்டையும் முடக்குவதற்கு முன்பே அவற்றை நிறுத்திவிடுகிறது.
- Memory buffers – சிஸ்டம் droplets-இன் RAM-இல் 20% கூடுதல் இடத்தைப் (headroom) ஒதுக்குகிறது, இது OS செயல்பாடுகளுக்கும் திடீர் அதிகரிப்பிற்கும் (spikes) இடமளிப்பதை உறுதி செய்கிறது.
- Pre-warming – தொடக்கத்தின் போது ஒவ்வொரு மாதிரியையும் சோதனை கோரிக்கைகள் (dummy requests) அணுகுகின்றன, இது தொடக்க நேரத் தாமதத்தைத் (cold-start penalty) தவிர்க்கிறது.
இந்த நடவடிக்கைகள் ஒரு பலவீனமான குழாயை (fragile pipeline), துல்லியத்தை அதிகம் இழக்காமல், சாதாரண 8 GB droplets-களில் போக்குவரத்தைத் தாங்கக்கூடிய ஒரு மீள்திறன் கொண்ட சேவையாக (resilient service) மாற்றின.
அடுத்து கவனிக்க வேண்டியவை
- Hardware scaling – கிளவுட் வழங்குநர்கள் குறைந்த விலையில் பெரிய நினைவக droplets-களை வழங்கும் போது, பெரிய மாதிரிகளுக்கான லாப வரம்பு (breakeven point) மாறக்கூடும்.
- Model compression – Quantization அல்லது knowledge distillation நுட்பங்கள் அதிக துல்லியமான மாதிரிகளின் RAM பயன்பாட்டைக் குறைக்கலாம், இது அவற்றைச் சிறிய இயந்திரங்களில் இயக்க அனுமதிக்கும்.
- Adaptive routing – எதிர்கால ரூட்டர்கள், ஒரு குறிப்பிட்ட வினாவிற்கு (query) எந்த மாதிரி சிறந்த சமநிலையைத் தரும் என்பதை நிகழ்நேரத்தில் (real time) கற்றுக்கொள்ளலாம், இது துல்லியம் மற்றும் செலவு இடையிலான சமநிலையை மேலும் தானியக்கமாக்கும்.
இதிலிருந்து நாம் கற்றுக்கொள்ள வேண்டியது எளிது: தயாரிப்புச் சூழலில், காகித அளவில் சிறப்பாகத் தோன்றும் மாதிரியை விட, அழுத்தமான சூழலிலும் தொடர்ந்து இயங்கும் மாதிரியே அதிக மதிப்பைக் கொடுக்கிறது. உங்கள் பயன்பாட்டுத் தடைகளை (deployment constraints) அடிப்படையாகக் கொண்டு ஒரு மாதிரியைத் தேர்ந்தெடுங்கள், வெறும் துல்லியத்தை மட்டும் வைத்து அல்ல.