Meta-வின் புதிய 30-billion-parameter Muse Glimmer, MacBook Pro M2 Pro-வில் 3-billion-parameter Llama 3.2-ஐ விட 56 மடங்கு மெதுவாக இயங்குகிறது. இது பெரும்பாலான local-agent workflows-களை இயக்கும் வேகமான மற்றும் தொடர்ச்சியான அழைப்புகளுக்கு (calls) இந்த மாடலை நடைமுறைக்குச் சாத்தியமற்றதாக மாற்றுகிறது.
Local agents-களுக்கு வேகம் ஏன் முக்கியம்
Local-agent loops ஒரு நிமிடத்திற்கு டஜன் கணக்கான அல்லது சில நேரங்களில் நூற்றுக்கணக்கான model calls-களைச் செய்கின்றன. ஒவ்வொரு அழைப்பும் தாமதத்தை (latency) ஏற்படுத்துகிறது; இந்தத் தொடர்ச்சியான தாமதம் பதிலளிக்கும் திறனை (responsiveness) முடக்கிவிடும். எனவே, டெவலப்பர்கள் துல்லியத்தன்மைக்குத் தேவையான மிகச்சிறிய மாடலையே பயன்படுத்துகிறார்கள்; ஒரு பிரச்சனைக்கு ஆழமான பகுத்தறிவு (reasoning) தேவைப்படும்போது மட்டுமே பெரிய மாடல்களை மாற்றுகிறார்கள். Meta, Muse Glimmer-ஐ இந்த loops-களுக்காக உருவாக்கப்பட்ட ஒரு “thinking” மாடல் என்று சந்தைப்படுத்தியது, மேலும் on-device வசதியை இழக்காமல் சிறந்த inference-ஐ வழங்குவதாக உறுதியளித்தது.
Benchmark அமைப்பு
நாங்கள் 32 GB RAM கொண்ட MacBook Pro M2 Pro-வில் இந்தச் சோதனையைச் செய்தோம், இதில் மூன்று முக்கியப் பணிகளை அளவிட்டோம்:
- Context re-read speed – மாடல் ஏற்கனவே பார்த்த ஒரு prompt-ஐ எவ்வளவு விரைவாகச் செயலாக்குகிறது.
- Constrained JSON extraction – ஒரு free-form உரையில் இருந்து கட்டமைக்கப்பட்ட தரவை (structured data) எடுப்பது, இது கருவிகளை (tools) அழைப்பதற்கு முன் செய்யப்படும் ஒரு பொதுவான படியாகும்.
- Tool calling – சரியாக வடிவமைக்கப்பட்ட function call-ஐ உருவாக்குதல்.
மூன்று மாடல்கள் ஒப்பிடப்பட்டன:
| Model | Prompt வேகம் (tok/s) | Generation வேகம் (tok/s) | JSON வெற்றி (5-trial) | ஒரு அழைப்பிற்கான நேரம் |
|---|---|---|---|---|
| Llama 3.2 3B | 702.9 | 56.7 | 5/5 | 0.6 s |
| Qwen 3 14B | 161.8 | 14.6 | 5/5 | 16.1 s |
| Muse Glimmer 30B | 56.7 | 7.1 | 5/5 | 33.4 s |
மூன்று மாடல்களும் துல்லிய இலக்கை எட்டின, ஒவ்வொரு சோதனையிலும் ஒரே மாதிரியான JSON வெளியீட்டை வழங்கின. 3 B மாடல் முழுமையான pipeline-ஐ ஒரு வினாடிக்கும் குறைவான நேரத்தில் முடித்தது; 30 B மாடல் அரை நிமிடத்திற்கும் மேலாக எடுத்துக்கொண்டது.
இந்த எண்கள் எதைக் குறிக்கின்றன
56 மடங்கு வேகம் குறைவது நேரடியாக CPU பயன்பாடு மற்றும் wall-clock நேரத்தை அதிகரிக்கிறது, இது ஆற்றல் நுகர்வை (energy consumption) அதிகரிப்பதோடு, ஒரு இயந்திரம் எத்தனை concurrent agents-களைத் தாங்க முடியும் என்பதையும் கட்டுப்படுத்துகிறது. “thinking” mode ஆஃப் செய்யப்பட்டிருந்தாலும் கூட, Muse Glimmer கூடுதல் tokens-களைச் சிந்திக்கப் பயன்படுத்தியது, இது தாமதம் (latency) என்பது ஒரு விருப்பத்தேர்வு (optional feature) அல்ல, மாறாக அதன் கட்டமைப்பிலேயே (architecture) உள்ளது என்பதைக் காட்டுகிறது.
உடனடியாகப் பதிலளிக்க வேண்டிய chat-bots, personal assistants அல்லது autonomous scripts-களை உருவாக்கும் டெவலப்பர்களுக்கு (உதாரணமாக: “எனது calendar நிகழ்வுகளைப் பெறு” அல்லது “புதிய மின்னஞ்சலைச் சுருக்கிக் கூறு”) — Llama 3.2-ன் 0.6 வினாடி தாமதம் மனிதர்கள் ஏற்றுக்கொள்ளக்கூடிய வரம்பிற்குள் உள்ளது. ஆனால் Muse Glimmer-ன் 33 வினாடி இடைவேளை கவனிக்கத்தக்கதாகவும், தயாரிப்பு நிலையில் (production) பெரும்பாலும் ஏற்றுக்கொள்ள முடியாததாகவும் இருக்கும்.
Muse Glimmer இன்னும் எங்கு முக்கியப் பங்கு வகிக்கிறது
இந்த benchmark குறுகிய, deterministic பணிகளில் கவனம் செலுத்தியது. Muse Glimmer திறந்தநிலை பகுத்தறிவில் (open-ended reasoning) சிறந்து விளங்குகிறது, அங்கு அது உருவாக்கும் கூடுதல் tokens ஒரு பதிலைத் தீர்மானிப்பதற்கு முன் பல தீர்வுகளை ஆராய உதவும். நுணுக்கமான தீர்ப்பு தேவைப்படும் சூழல்களில் — சிக்கலான code synthesis, பல படிநிலைகளைக் கொண்ட திட்டமிடல் (multi-step planning), அல்லது தெளிவற்ற பயனர் நோக்கத்தைப் புரிந்துகொள்ளுதல் — இந்த ஆழமான மாடல் அதிகத் தரமான வெளியீடுகளை வழங்கக்கூடும், இது காத்திருப்பு நேரத்தை நியாயப்படுத்தும்.
செலவு குறித்த பரிசீலனைகள்
ஒரு 30 B மாடலை உள்ளூர் ரீதியாக (locally) இயக்குவது, 3 B மாடலை விட அதிக GPU memory மற்றும் மின்சாரத்தைப் பயன்படுத்துகிறது. ஒரு laptop-வகை இயந்திரத்தில், மெதுவான throughput காரணமாக CPU நீண்ட நேரம் idle நிலையில் இருக்கும், இது ஒரு தொகுதி கோரிக்கைகளின் (batch of requests) ஒட்டுமொத்த இயக்க நேரத்தை நீட்டிக்கிறது. Cloud-க்கு இணையான செலவுகளைக் கண்காணிக்கும் குழுக்களுக்கு, இந்தச் சமநிலை (trade-off) மிகத் தெளிவாகத் தெரிகிறது: ஒரு மெதுவான local மாடல், ஒரு பெரிய, hosted மாடலுக்குச் செய்யப்படும் வேகமான API call-ஐ விட ஒரு inference-க்கு அதிகச் செலவை ஏற்படுத்தலாம்.
அடுத்து கவனிக்க வேண்டியவை
Meta, Muse Glimmer-க்கான விரிவான performance-tuning வழிகாட்டுதல்களை இன்னும் வெளியிடவில்லை. எதிர்கால firmware அல்லது driver மேம்படுத்தல்கள் வேக இடைவெளியைக் குறைக்கலாம், குறிப்பாக மாடலின் பகுத்தறிவுத் திறனை இழக்காமல் அதை quantized அல்லது pruned செய்ய முடிந்தால். பல அழைப்புகளைத் தொகுக்கும் (batch) அல்லது இடைநிலை prompt-களைச் சேமித்து வைக்கும் (cache) சமூகத்தால் உருவாக்கப்பட்ட toolkits-களும் குறிப்பிட்ட வேலைப்பளுக்களுக்கான தாமதத்தைக் குறைக்கலாம்.
டெவலப்பர்கள் இதைக் கண்காணிக்க வேண்டும்:
- Quantization breakthroughs – குறைந்த துல்லியமான கணித முறைகள் (lower-precision arithmetic) token-per-second விகிதத்தை அதிகரிக்கலாம்.
- Hybrid pipelines – வழக்கமான தரவுப் பிரித்தெடுத்தலுக்கு (routine extraction) ஒரு சிறிய மாடலைப் பயன்படுத்தவும், நம்பகத்தன்மைத் தளம் (confidence threshold) தோல்வியடையும் போது மட்டும் Muse Glimmer-க்கு மாறவும்.
- Hardware shifts – புதிய Apple silicon, 30 B weight matrix-ஐ அதிகத் திறனுடன் கையாளலாம்.
முடிவுரை
Muse Glimmer ஒரு 30 B மாதிரி வாக்குறுதி அளிக்கும் ஆழத்தை வழங்குகிறது, ஆனால் தற்போதைய நுகர்வோர் வன்பொருளில், பெரும்பாலான உள்ளூர் ஏஜெண்டுகளை இயக்கும் அதிக அதிர்வெண் கொண்ட சுழற்சிகளுக்கு (high-frequency loops) இது மிகவும் மந்தமாக உள்ளது. சாதனத்தில் இயங்கும் மாதிரிகளை (on-device models) வெளிப்புற API-கள் போலக் கருதுங்கள்: துல்லியத் தேவைகளைப் பூர்த்தி செய்யும் மிகச்சிறிய மாதிரியிலிருந்து தொடங்குங்கள், மேலும் கூடுதல் பகுத்தறியும் திறன் உண்மையிலேயே தேவைப்படும் பணிகளுக்காக மட்டுமே அந்த வலிமையான மாதிரியைப் பயன்படுத்துங்கள். Meta இந்த வேக இடைவெளியைக் குறைக்கும் வரை, அன்றாடத் தரவுப் பிரித்தெடுத்தல், வடிவமைத்தல் மற்றும் எளிய கருவிப் பயன்பாட்டிற்கு 3 B Llama 3.2 நடைமுறைக்கு ஏற்றத் தேர்வாக இருக்கும்; அதே நேரத்தில், Muse Glimmer அவ்வப்போது வரும் ஆழமான சிந்தனைத் தேவைகளுக்கான அடுத்த கட்டத் தேர்வாகவே இருக்கும்.