Meta-യുടെ പുതിയ 30-ബില്യൺ പാരാമീറ്റർ Muse Glimmer, ഒരു MacBook Pro M2 Pro-യിൽ 3-ബില്യൺ പാരാമീറ്റർ Llama 3.2-യേക്കാൾ 56 മടങ്ങ് സാവധാനത്തിലാണ് പ്രവർത്തിക്കുന്നത്. ഇത് മിക്ക ലോക്കൽ-ഏജന്റ് വർക്ക്ഫ്ലോകളെയും നയിക്കുന്ന വേഗതയേറിയതും ആവർത്തന സ്വഭാവമുള്ളതുമായ കോളുകൾക്ക് (calls) ഈ മോഡലിനെ പ്രായോഗികമല്ലാതാക്കുന്നു.

ലോക്കൽ ഏജന്റുകൾക്ക് വേഗത പ്രധാനമാകുന്നത് എന്തുകൊണ്ട്

ലോക്കൽ-ഏജന്റ് ലൂപ്പുകൾ മിനിറ്റിൽ ഡസൻ കണക്കിന്, ചിലപ്പോൾ നൂറുകണക്കിന് മോഡൽ കോളുകൾ നടത്തുന്നു. ഓരോ കോളും ലേറ്റൻസി (latency) വർദ്ധിപ്പിക്കുന്നു; ഈ ആകെത്തുകയായുള്ള കാലതാമസം റെസ്‌പോൺസീവ്നെസ്സിനെ (responsiveness) തകരാറിലാക്കിയേക്കാം. അതിനാൽ, കൃത്യത ഉറപ്പാക്കുന്ന ഏറ്റവും ചെറിയ മോഡലുകൾ ഉപയോഗിക്കാനാണ് ഡെവലപ്പർമാർ താൽപ്പര്യപ്പെടുന്നത്; ആഴത്തിലുള്ള ചിന്താശേഷി (reasoning) ആവശ്യമുള്ള പ്രശ്നങ്ങളിൽ മാത്രമേ അവർ വലിയ മോഡലുകളിലേക്ക് മാറുന്നുള്ളൂ. ഓൺ-ഡിവൈസ് ഗുണങ്ങൾ നഷ്ടപ്പെടുത്താതെ തന്നെ മികച്ച ഇൻഫറൻസ് (inference) വാഗ്ദാനം ചെയ്തുകൊണ്ട്, ഇത്തരം ലൂപ്പുകൾക്കായി നിർമ്മിച്ച ഒരു “thinking” മോഡൽ എന്നാണ് Meta Muse Glimmer-നെ വിപണനം ചെയ്തത്.

ബെഞ്ച്മാർക്ക് സെറ്റപ്പ്

32 GB RAM ഉള്ള ഒരു MacBook Pro M2 Pro-യിൽ ഞങ്ങൾ ഈ ടെസ്റ്റ് നടത്തി. മൂന്ന് പ്രധാനപ്പെട്ട ടാസ്ക്കുകളാണ് ഇതിൽ അളന്നത്:

  • Context re-read speed – മോഡൽ നേരത്തെ കണ്ട ഒരു പ്രോംപ്റ്റ് എത്ര വേഗത്തിൽ പ്രോസസ്സ് ചെയ്യുന്നു എന്നത്.
  • Constrained JSON extraction – ടൂളുകൾ ഉപയോഗിക്കുന്നതിന് മുൻപുള്ള ഒരു സാധാരണ ഘട്ടമായ ഫ്രീ-ഫോം ടെക്സ്റ്റിൽ നിന്ന് സ്ട്രക്ചേർഡ് ഡാറ്റ വേർതിരിച്ചെടുക്കുന്നത്.
  • Tool calling – ശരിയായ രീതിയിൽ ഫോർമാറ്റ് ചെയ്ത ഒരു ഫംഗ്ഷൻ കോൾ (function call) നിർമ്മിക്കുന്നത്.

മൂന്ന് മോഡലുകളെയാണ് താരതമ്യം ചെയ്തത്:

മോഡൽ പ്രോംപ്റ്റ് സ്പീഡ് (tok/s) ജനറേഷൻ സ്പീഡ് (tok/s) JSON വിജയം (5-ട്രയൽ) ഓരോ കോളും എടുക്കുന്ന സമയം
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 മോഡൽ ഒരു സെക്കൻഡിൽ താഴെ സമയം കൊണ്ട് മുഴുവൻ പൈപ്പ്‌ലൈനും പൂർത്തിയാക്കിയപ്പോൾ, 30 B മോഡലിന് അര മിനിറ്റിലധികം സമയം വേണ്ടി വന്നു.

ഈ കണക്കുകൾ സൂചിപ്പിക്കുന്നത് എന്താണ്

56 മടങ്ങ് വേഗത കുറയുന്നത് നേരിട്ട് CPU ഉപയോഗവും ആകെ എടുക്കുന്ന സമയവും വർദ്ധിപ്പിക്കുന്നു, ഇത് ഊർജ്ജ ഉപഭോഗം കൂട്ടുകയും ഒരു മെഷീനിൽ ഒരേസമയം എത്ര ഏജന്റുകളെ പ്രവർത്തിപ്പിക്കാം എന്നതിനെ പരിമിതപ്പെടുത്തുകയും ചെയ്യുന്നു. “thinking” മോഡ് ഓഫ് ചെയ്തിട്ടുപോലും, Muse Glimmer കൂടുതൽ ടോക്കണുകൾ ഉപയോഗിച്ച് ചിന്തിച്ചുകൊണ്ടിരുന്നു. ഇത് ലേറ്റൻസി എന്നത് ഒരു ഓപ്ഷണൽ ഫീച്ചർ എന്നതിലുപരി ആർക്കിടെക്ചറിന്റെ തന്നെ ഭാഗമാണെന്ന് സൂചിപ്പിക്കുന്നു.

ചാറ്റ്-ബോട്ടുകൾ, പേഴ്സണൽ അസിസ്റ്റന്റുകൾ, അല്ലെങ്കിൽ ഉടൻ പ്രതികരിക്കേണ്ട ഓട്ടോണമസ് സ്ക്രിപ്റ്റുകൾ (ഉദാഹരണത്തിന്: “എന്റെ കലണ്ടർ ഇവന്റുകൾ എടുക്കുക” അല്ലെങ്കിൽ “പുതിയ ഇമെയിൽ സംഗ്രഹിക്കുക”) എന്നിവ നിർമ്മിക്കുന്ന ഡെവലപ്പർമാരെ സംബന്ധിച്ചിടത്തോളം, Llama 3.2-യുടെ 0.6 സെക്കൻഡ് ലേറ്റൻസി മനുഷ്യർക്ക് സ്വീകാര്യമായ പരിധിക്കുള്ളിലാണ്. എന്നാൽ Muse Glimmer നൽകുന്ന 33 സെക്കൻഡ് ഇടവേള പ്രൊഡക്ഷനിൽ ശ്രദ്ധിക്കപ്പെടുകയും സ്വീകാര്യമല്ലാതിരിക്കുകയും ചെയ്യും.

Muse Glimmer-ന് ഇപ്പോഴും പ്രസക്തിയുള്ള ഇടങ്ങൾ

ഈ ബെഞ്ച്മാർക്ക് ചെറിയതും നിശ്ചിതവുമായ (deterministic) ടാസ്ക്കുകളിലാണ് ശ്രദ്ധ കേന്ദ്രീകരിച്ചത്. എന്നാൽ ഓപ്പൺ-എൻഡഡ് റീസണിംഗിൽ (open-ended reasoning) Muse Glimmer തിളങ്ങുന്നു; അവിടെ അത് നിർമ്മിക്കുന്ന അധിക ടോക്കണുകൾ ഒരു ഉത്തരത്തിൽ എത്തുന്നതിന് മുമ്പ് വിവിധ പരിഹാര മാർഗങ്ങൾ പര്യവേക്ഷണം ചെയ്യുന്നു. സങ്കീർണ്ണമായ കോഡ് സിന്തസിസ്, മൾട്ടി-സ്റ്റെപ്പ് പ്ലാനിംഗ്, അല്ലെങ്കിൽ അവ്യക്തമായ ഉപയോക്താവിന്റെ ഉദ്ദേശ്യം മനസ്സിലാക്കൽ തുടങ്ങിയ സൂക്ഷ്മമായ വിധിനിർണ്ണയം (nuanced judgment) ആവശ്യമുള്ള സാഹചര്യങ്ങളിൽ, ഈ ഡീപ്പർ മോഡൽ നൽകുന്ന ഉയർന്ന നിലവാരമുള്ള ഔട്ട്പുട്ടുകൾ ആ കാത്തിരിപ്പിന് അർഹമായതാണ്.

ചിലവ് സംബന്ധിച്ച കാര്യങ്ങൾ

ഒരു 30 B മോഡൽ ലോക്കലായി പ്രവർത്തിപ്പിക്കുന്നത് 3 B മോഡലിനേക്കാൾ കൂടുതൽ GPU മെമ്മറിയും പവറും ഉപയോഗിക്കുന്നു. ഒരു ലാപ്ടോപ്പ് ക്ലാസ് മെഷീനിൽ, കുറഞ്ഞ സ്പീഡ് കാരണം CPU കൂടുതൽ സമയം വെറുതെ ഇരിക്കേണ്ടി വരികയും ഇത് റിക്വസ്റ്റുകളുടെ മൊത്തത്തിലുള്ള സമയം വർദ്ധിപ്പിക്കുകയും ചെയ്യുന്നു. ക്ലൗഡ് ചിലവുകൾ ശ്രദ്ധിക്കുന്ന ടീമുകളെ സംബന്ധിച്ചിടത്തോളം, ഇതിലെ വിട്ടുവീഴ്ച വളരെ വ്യക്തമാണ്: ഒരു വലിയ ഹോസ്റ്റഡ് മോഡലിലേക്കുള്ള വേഗതയേറിയ API കോളേക്കാൾ കൂടുതൽ ചിലവ് ഒരു സാവധാനത്തിലുള്ള ലോക്കൽ മോഡലിന് ഒരു ഇൻഫറൻസിനായി വന്നേക്കാം.

ഇനി ശ്രദ്ധിക്കേണ്ട കാര്യങ്ങൾ

Muse Glimmer-ന് വേണ്ടിയുള്ള വിശദമായ പെർഫോമൻസ് ട്യൂണിംഗ് മാർഗ്ഗനിർദ്ദേശങ്ങൾ Meta ഇതുവരെ പുറത്തിറക്കിയിട്ടില്ല. ഭാവിയിലെ ഫേംവെയർ അല്ലെങ്കിൽ ഡ്രൈവർ അപ്‌ഡേറ്റുകൾ വേഗതയിലെ ഈ വ്യത്യാസം കുറച്ചേക്കാം, പ്രത്യേകിച്ച് മോഡലിന്റെ റീസണിംഗ് ശേഷി നഷ്ടപ്പെടാതെ തന്നെ അതിനെ ക്വാണ്ടൈസ് (quantized) ചെയ്യാനോ പ്രൂൺ (pruned) ചെയ്യാനോ സാധിച്ചാൽ. ഒന്നിലധികം കോളുകൾ ബച്ച് (batch) ചെയ്യുന്നതോ അല്ലെങ്കിൽ ഇടക്കാല പ്രോംപ്റ്റുകൾ കാഷെ (cache) ചെയ്യുന്നതോ ആയ കമ്മ്യൂണിറ്റി ടൂൾകിറ്റുകൾ ചില പ്രത്യേക ജോലികളിലെ ലേറ്റൻസി കുറയ്ക്കാൻ സഹായിച്ചേക്കാം.

ഡെവലപ്പർമാർ ഇവ നിരീക്ഷിക്കണം:

  • Quantization breakthroughs – കുറഞ്ഞ പ്രിസിഷൻ അരിത്മെറ്റിക് (lower-precision arithmetic) ടോക്കൺ-പെർ-സെക്കൻഡ് നിരക്ക് വർദ്ധിപ്പിച്ചേക്കാം.
  • Hybrid pipelines – സാധാരണ ആവശ്യങ്ങൾക്കായി ചെറിയ മോഡലുകൾ ഉപയോഗിക്കുകയും, കോൺഫിഡൻസ് തംശ്രെഷിൽ (confidence threshold) പരാജയപ്പെടുമ്പോൾ മാത്രം Muse Glimmer ഉപയോഗിക്കുകയും ചെയ്യുക.
  • Hardware shifts – പുതിയ ആപ്പിൾ സിലിക്കൺ (Apple silicon) 30 B വെയിറ്റ് മാട്രിക്സിനെ കൂടുതൽ കാര്യക്ഷമമായി കൈകാര്യം ചെയ്തേക്കാം.

ചുരുക്കത്തിൽ

Muse Glimmer ഒരു 30B മോഡൽ വാഗ്ദാനം ചെയ്യുന്ന ആഴത്തിലുള്ള പ്രകടനം നൽകുന്നുണ്ടെങ്കിലും, നിലവിലെ കൺസ്യൂമർ ഹാർഡ്‌വെയറുകളിൽ മിക്ക ലോക്കൽ ഏജന്റുകളെയും പ്രവർത്തിപ്പിക്കുന്ന ഹൈ-ഫ്രീക്വൻസി ലൂപ്പുകൾക്ക് (high-frequency loops) ഇത് വളരെ സാവധാനമാണ്. ഓൺ-ഡിവൈസ് മോഡലുകളെ എക്സ്റ്റേണൽ API-കൾ പോലെ കാണുക: കൃത്യത ആവശ്യമായ കാര്യങ്ങൾക്ക് ഏറ്റവും ചെറിയ മോഡലിൽ നിന്ന് തുടങ്ങുക, കൂടാതെ കൂടുതൽ ചിന്താശേഷി (reasoning capacity) ആവശ്യമുള്ള ജോലികൾക്കായി മാത്രം വലിയ മോഡലുകളെ ഉപയോഗിക്കുക. Meta വേഗതയുടെ ഈ വ്യത്യാസം പരിഹരിക്കുന്നത് വരെ, ദൈനംദിന എക്സ്ട്രാക്ഷൻ, ഫോർമാറ്റിംഗ്, ലളിതമായ ടൂൾ ഡിസ്പാച്ച് എന്നിവയ്ക്ക് 3B Llama 3.2 ആണ് പ്രായോഗികമായ തിരഞ്ഞെടുപ്പ്; എന്നാൽ ഇടയ്ക്കിടെയുള്ള സങ്കീർണ്ണമായ ചിന്താപരമായ വെല്ലുവിളികൾക്കായി Muse Glimmer ഒരു ഉയർന്ന തലത്തിലുള്ള ഓപ്ഷനായി തുടരുന്നു.

ഉറവിടം: Frank Chu എഴുതിയ dev.to ലേഖനം