ആഗസ്റ്റ് 3-നാണ് Alibaba തങ്ങളുടെ Qwen3.8-Max പുറത്തിറക്കിയത്. ഇത് 2.4 ട്രില്യൺ പാരാമീറ്ററുകളുള്ള ഒരു mixture-of-experts മോഡലാണ്, എന്നാൽ inference സമയത്ത് 95 ബില്യൺ പാരാമീറ്ററുകൾ മാത്രമേ പ്രവർത്തിക്കുന്നുള്ളൂ. QwenCloud ഗേറ്റ്വേ വഴി ചിത്രങ്ങളും ടെക്സ്റ്റും ഈ മോഡലിന് സ്വീകരിക്കാൻ കഴിയും. അടുത്ത ആഴ്ച മുതൽ ഇതിന്റെ weights പരസ്യമായി ലഭ്യമാകുമെന്ന് Alibaba അറിയിച്ചു.
ഈ വലിയ വാർത്തയ്ക്ക് പിന്നിൽ ഒരു കഠിനമായ ചോദ്യമുണ്ട്: ഉപയോഗിക്കുന്ന ടൂളുകൾ പരാജയപ്പെടുമ്പോൾ ഈ മോഡലിന്റെ ഏജന്റിന് വിശ്വസനീയമായി കോഡ് എഴുതാൻ കഴിയുമോ? വെണ്ടർ ഡെമോകളിൽ പത്ത് ദിവസം നീണ്ടുനിൽക്കുന്ന, പൂർണ്ണമായും സ്വയംഭരണാധികാരമുള്ള (fully autonomous) ഒരു കോഡിംഗ് സ്പ്രിന്റ് കാണിക്കുന്നുണ്ട്. ഇത് ഒരു പ്രോജക്റ്റ് പൂജ്യത്തിൽ നിന്ന് നിർമ്മിച്ചതാണ്. എന്നാൽ ഈ പരീക്ഷണങ്ങൾ Alibaba-യുടെ സ്വന്തം ഇൻഫ്രാസ്ട്രക്ചറിലും അനുയോജ്യമായ പെർമിഷനുകളിലും ആണ് നടത്തിയത്. ടോക്കൺ പരിധികൾ (token limits) കുറയുമ്പോഴോ, ടൂൾ കോളുകൾ പരാജയപ്പെടുമ്പോഴോ, റൈറ്റ് ആക്സസ് (write access) പരിമിതപ്പെടുമ്പോഴോ സിസ്റ്റം എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്ന് യഥാർത്ഥ ഡെവലപ്പർമാർക്ക് അറിയേണ്ടതുണ്ട്.
എന്തുകൊണ്ടാണ് ഈ ചർച്ചകൾ പ്രസക്തമാകുന്നത്
Mixture-of-experts ഡിസൈനുകൾ ഉപയോഗിക്കുന്നതിലൂടെ, ഒരു പ്രത്യേക "expert"-നെ വിളിക്കാത്ത പക്ഷം വലിയൊരു പാരാമീറ്റർ പൂൾ പ്രവർത്തനരഹിതമായി ഇരിക്കാൻ സാധിക്കും. ഇത് സമാനമായ വലിപ്പമുള്ള ഒരു dense model-നെക്കാൾ കുറഞ്ഞ inference ചിലവ് നൽകുന്നു. Multimodal input ഉപയോഗിക്കുന്നതിലൂടെ കോഡ് ജനറേഷന് പുറമെ ഡയഗ്രമുകളോ സ്ക്രീൻഷോട്ടുകളോ പ്രോംപ്റ്റുകളിൽ നൽകാനും ഡെവലപ്പർമാർക്ക് സാധിക്കുന്നു.
എന്നാൽ ഇതിന്റെ വിജയം ഫയൽ എഡിറ്ററുകൾ, കംപൈലറുകൾ, ടെസ്റ്റ് റണ്ണറുകൾ, version-control കമാൻഡുകൾ എന്നിവ നിയന്ത്രിക്കുന്ന agent layer-ലാണ് നിലനിൽക്കുന്നത്. ഒരു ടൂൾ കോൾ പരാജയപ്പെട്ടാൽ ആ ലെയറിന് അതിൽ നിന്ന് തിരിച്ചുവരാൻ കഴിഞ്ഞില്ലെങ്കിൽ, മുഴുവൻ കോഡിംഗ് സെഷനും തകരാം.
വിട്ടുപോയ ഭാഗം: reasoning effort knob
Qwen3.8-Max മൂന്ന് "reasoning effort" പ്രീസെറ്റുകളുമായാണ് (low, medium, xhigh) വരുന്നത്. ഈ സെറ്റിംഗുകൾ വേഗതയ്ക്കും ഉത്തരത്തിന്റെ ഗുണനിലവാരത്തിനും, അതിലുപരി മോഡൽ പുറപ്പെടുവിക്കുന്ന ടോക്കണുകളുടെ എണ്ണത്തിനും ഇടയിലുള്ള ഒരു ബാലൻസ് ആണ് നൽകുന്നത്.
പുനരാവർത്തിക്കാവുന്ന ഒരു ടെസ്റ്റ് പ്ലാൻ
മാർക്കറ്റിംഗ് അവകാശവാദങ്ങൾക്കപ്പുറം യാഥാർത്ഥ്യം അറിയാൻ, നിശ്ചിത ടോക്കൺ ബജറ്റിൽ താഴെ പറയുന്ന പ്രോട്ടോക്കോൾ പരീക്ഷിച്ചു നോക്കുക:
- ഒരു പുതിയ റിപ്പോസിറ്ററി (repository) നിർമ്മിക്കുക: ഏതെങ്കിലും ഭാഷയിൽ ലളിതമായ ഒരു "hello world" scaffold ഉപയോഗിക്കുക.
- ഏജന്റിനോട് ആവശ്യപ്പെടുക (Prompt the agent): ഒരു പുതിയ ഫീച്ചർ (ഉദാഹരണത്തിന്, ഒരു REST endpoint) ചേർക്കാൻ ആവശ്യപ്പെടുക. അത് നൽകുന്ന ഓരോ പ്ലാനും, നടത്തുന്ന ഓരോ ടൂൾ കോളും, മാറ്റം വരുത്തുന്ന ഓരോ ഫയലും രേഖപ്പെടുത്തുക.
- ആദ്യത്തെ പരാജയത്തിൽ തന്നെ തടസ്സപ്പെടുത്തുക: ഉദാഹരണത്തിന്, ഒരു compilation error വരുമ്പോൾ—മോഡലിന്റെ ഇന്റേണൽ സ്റ്റേറ്റ് സേവ് ചെയ്യുക, തുടർന്ന് ആ checkpoint-ൽ നിന്ന് വീണ്ടും തുടങ്ങുക.
- പരീക്ഷണം ആവർത്തിക്കുക: ഓരോ reasoning effort സെറ്റിംഗിലും പരീക്ഷണം ആവർത്തിക്കുക; ആകെ ടോക്കണുകൾ, wall-clock time, ടൂൾ ലെവൽ പിശകുകൾ എന്നിവ കുറിച്ചെടുക്കുക.
- പെർമിഷനുകൾ പരിമിതപ്പെടുത്തുക: ഒരു തവണ പെർമിഷനുകൾ പരിമിതപ്പെടുത്തുക (read-only access), മറ്റൊരു തവണ പൂർണ്ണമായ write access നൽകുക; ഏജന്റ് എങ്ങനെ ഇതിനോട് പൊരുത്തപ്പെടുന്നു എന്ന് പരിശോധിക്കുക.
- റൈട്രൈകൾ (retries) ലോഗ് ചെയ്യുക: പരാജയപ്പെട്ട ഒരു ടൂൾ മോഡൽ വീണ്ടും ഉപയോഗിക്കാൻ ശ്രമിക്കുന്നുണ്ടോ അതോ പ്രവർത്തനം നിർത്തുന്നുണ്ടോ?
ഈ മെട്രിക്സുകൾ ശേഖരിക്കുന്നതിലൂടെ, കോഡിംഗ് ഔട്ട്പുട്ടിനെ എറർ ഹാൻഡ്ലിംഗിനായുള്ള മറഞ്ഞിരിക്കുന്ന ചിലവുമായി താരതമ്യം ചെയ്യാൻ നിങ്ങൾക്ക് സാധിക്കും. ഏജന്റ് ഒരു flaky linter-നെ വീണ്ടും വീണ്ടും ഉപയോഗിക്കാൻ ശ്രമിക്കുകയാണെങ്കിൽ, ഫൈനൽ കോഡ് ശരിയാണെങ്കിൽ പോലും ടോക്കൺ ചിലവ് കുതിച്ചുയരും.
കണക്കുകൾ മറച്ചുവെക്കുന്നത് എന്താണ്
95B ആക്റ്റീവ് പാരാമീറ്റർ എന്ന കണക്ക് നേരിട്ട് പണമായി കണക്കാക്കാൻ കഴിയില്ല. എററുകൾ നൽകുന്ന ടൂൾ കോളുകൾ മോഡലിനെ തിരുത്തൽ പ്രോംപ്റ്റുകൾ (corrective prompts) നിർമ്മിക്കാൻ നിർബന്ധിക്കുന്നു, ഇത് ടോക്കൺ ഉപയോഗം വർദ്ധിപ്പിക്കുന്നു. Durable state—അതായത് ഒരു ക്രാഷിന് ശേഷം വീണ്ടും തുടങ്ങാൻ സഹായിക്കുന്ന പിരിയോഡിക് checkpoints—ഇല്ലാതെ, ഒരു പരാജയത്തിന്റെ ചിലവ് വലിയ രീതിയിൽ വർദ്ധിച്ചേക്കാം.
ഓപ്പൺ-വെയ്റ്റ്സ് മുന്നറിയിപ്പ്
അടുത്ത ആഴ്ച weights റിലീസ് ചെയ്യുമെന്ന അലിബാബയുടെ വാഗ്ദാനം on-prem വിന്യാസത്തിന് വഴിയൊരുക്കുന്നുണ്ടെങ്കിലും രണ്ട് പ്രായോഗിക തടസ്സങ്ങൾ അവശേഷിക്കുന്നു. ഒന്നാമതായി, ലൈസൻസ് വാണിജ്യ ഉപയോഗം പരിമിതപ്പെടുത്തിയേക്കാം അല്ലെങ്കിൽ അറ്റ്രിബ്യൂഷൻ ആവശ്യപ്പെട്ടേക്കാം; ഒരു ഉൽപ്പന്നത്തിലേക്ക് ഈ മോഡൽ സംയോജിപ്പിക്കുന്നതിന് മുമ്പ് ഡെവലപ്പർമാർ അത് വായിച്ചിരിക്കണം. രണ്ടാമതായി, 2.4 T-പാരാമീറ്റർ ഉള്ള ഒരു mixture-of-experts സിസ്റ്റം പ്രവർത്തിപ്പിക്കാൻ ഇപ്പോഴും ഹൈ-എൻഡ് GPU-കളോ സ്പെഷ്യലൈസ്ഡ് ആക്സിലറേറ്ററുകളോ ആവശ്യമാണ്. യഥാർത്ഥ ഹാർഡ്വെയർ ആവശ്യകതകളും പെർഫോമൻസ് കണക്കുകളും പരിശോധിക്കുന്നത് വരെ "local deployment" അവകാശവാദങ്ങളെ താൽക്കാലികമായി മാത്രം കണക്കാക്കുക.
എതിർവാദം: വെണ്ടറുടെ കാഴ്ചപ്പാട്
അലിബാബയുടെ ആഭ്യന്തര പരിശോധനകൾ പ്രകാരം, മനുഷ്യന്റെ ഇടപെടലില്ലാതെ issue triage, കോഡ് ജനറേഷൻ, ടെസ്റ്റ് എക്സിക്യൂഷൻ എന്നിവ കൈകാര്യം ചെയ്തുകൊണ്ട് പത്ത് ദിവസം നീണ്ടുനിൽക്കുന്ന ഒരു ഓട്ടോണമസ് കോഡിംഗ് മാരത്തൺ ഈ മോഡൽ പൂർത്തിയാക്കിയിട്ടുണ്ട്. ഈ ഫലങ്ങൾ ടീം നിങ്ങൾക്ക് കാണിച്ചുതരാൻ ആഗ്രഹിക്കുന്നത് എന്താണെന്ന് കാണിക്കുന്നുണ്ടെങ്കിലും, യഥാർത്ഥ ലോകത്തെ പരീക്ഷണങ്ങളിൽ ഇത് വിശ്വസനീയമാണെന്ന് തെളിയിക്കുന്നില്ല.
ഇനി ശ്രദ്ധിക്കേണ്ട കാര്യങ്ങൾ
- ലൈസൻസ് അന്തിമമാക്കൽ: ഓപ്പൺ-വെയ്റ്റ്സ് റിലീസിന്റെ കൃത്യമായ നിബന്ധനകൾ അനുസരിച്ചായിരിക്കും സ്റ്റാർട്ടപ്പുകൾക്ക് Qwen3.8-Max ഉപയോഗിച്ച് ഉൽപ്പന്നങ്ങൾ പുറത്തിറക്കാൻ കഴിയുമോ അതോ ഹോസ്റ്റഡ് API തന്നെ ഉപയോഗിക്കണോ എന്ന് തീരുമാനിക്കപ്പെടുക.
- ഹാർഡ്വെയർ ലഭ്യത: ക്ലൗഡ് പ്രൊവൈഡർമാർ mixture-of-experts മോഡലുകൾക്കായി പ്രീ-കോൺഫിഗർ ചെയ്ത instances നൽകാൻ തുടങ്ങിയാൽ, on-prem പരിശോധനകളിലെ തടസ്സങ്ങൾ ഗണ്യമായി കുറയും.
സംഗ്രഹം
Qwen3.8-Max-ന്റെ വാർത്തകളിൽ നിറഞ്ഞുനിൽക്കുന്ന വലിപ്പവും മൾട്ടിമോഡൽ വൈഭവവും കഥയുടെ പകുതി മാത്രമാണ്; ഡെവലപ്പർമാരെ സംബന്ധിച്ചിടത്തോളം യഥാർത്ഥ അളവുകോൽ എന്നത് അതിന്റെ ഏജന്റ് ഹാർനസ് (agent harness) ടൂൾ പരാജയങ്ങൾ, ടോക്കൺ ബജറ്റുകൾ, പെർമിഷൻ പരിധികൾ എന്നിവ എങ്ങനെ കൈകാര്യം ചെയ്യുന്നു എന്നതാണ്. റീസണിംഗ് പരിശ്രമവും (reasoning effort) ആക്സസ് അവകാശങ്ങളും (access rights) വ്യത്യാസപ്പെടുത്തിക്കൊണ്ടുള്ള അച്ചടക്കമുള്ളതും ആവർത്തിക്കാവുന്നതുമായ ഒരു പരിശോധനയിലൂടെ, ഈ മോഡൽ അതിന്റെ മാർക്കറ്റിംഗ് വാഗ്ദാനങ്ങൾ പാലിക്കുന്നുണ്ടോ അതോ കോഡിംഗ് പൈപ്പ്ലൈനിൽ വെറുമൊരു ചിലവേറിയ ഘട്ടം കൂടി കൂട്ടുന്നുണ്ടോ എന്ന് വെളിപ്പെടും.