ಅಲಿಬಾಬಾ ಆಗಸ್ಟ್ 3 ರಂದು Qwen3.8-Max ಅನ್ನು ಬಿಡುಗಡೆ ಮಾಡಿದೆ. ಇದು 2.4 ಟ್ರಿಲಿಯನ್ ಪ್ಯಾರಾಮೀಟರ್‌ಗಳವರೆಗೆ ವಿಸ್ತರಿಸಬಹುದಾದ mixture-of-experts ಮಾಡೆಲ್ ಆಗಿದ್ದರೂ, inference ಸಮಯದಲ್ಲಿ ಕೇವಲ 95 ಬಿಲಿಯನ್ ಪ್ಯಾರಾಮೀಟರ್‌ಗಳನ್ನು ಮಾತ್ರ ಸಕ್ರಿಯಗೊಳಿಸುತ್ತದೆ. ಈ ಮಾಡೆಲ್ QwenCloud gateway ಮೂಲಕ ಚಿತ್ರಗಳು ಮತ್ತು ಪಠ್ಯವನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ ಮತ್ತು ಮುಂದಿನ ವಾರ weights ಸಾರ್ವಜನಿಕವಾಗಿ ಲಭ್ಯವಿರಲಿದೆ ಎಂದು ಅಲಿಬಾಬಾ ಹೇಳಿದೆ.

ಈ ವೈಭವದ ಸುದ್ದಿಯ ಹಿಂದೆ ಒಂದು ಕಠಿಣ ಪ್ರಶ್ನೆಯಿದೆ: ಮಾಡೆಲ್ ಅವಲಂಬಿಸಿರುವ ಪರಿಕರಗಳು (tools) ವಿಫಲವಾದಾಗ, ಅದರ agent ವಿಶ್ವಾಸಾರ್ಹವಾಗಿ ಕೋಡ್ ಬರೆಯಬಲ್ಲದೇ? ಮಾರಾಟಗಾರರ (vendor) ಪ್ರಾತ್ಯಕ್ಷಿಕೆಗಳು ಶೂನ್ಯದಿಂದ ಒಂದು ಪ್ರಾಜೆಕ್ಟ್ ಅನ್ನು ನಿರ್ಮಿಸುವ ಹತ್ತು ದಿನಗಳ ಸಂಪೂರ್ಣ ಸ್ವಾಯತ್ತ ಕೋಡಿಂಗ್ ಸ್ಪ್ರಿಂಟ್ ಅನ್ನು ತೋರಿಸುತ್ತವೆ, ಆದರೆ ಆ ಪ್ರಕ್ರಿಯೆಗಳು ಅಲಿಬಾಬಾ ತನ್ನದೇ ಆದ ಮೂಲಸೌಕರ್ಯದಲ್ಲಿ ಮತ್ತು ಆದರ್ಶ ಅನುಮತಿಗಳ ಅಡಿಯಲ್ಲಿ ನಡೆಸಲ್ಪಟ್ಟಿದ್ದವು. ನೈಜ ಪ್ರಪಂಚದ ಡೆವಲಪರ್‌ಗಳಿಗೆ ಟೋಕನ್ ಮಿತಿಗಳು ಎದುರಾದಾಗ, tool calls ವಿಫಲವಾದಾಗ ಅಥವಾ write access ಸೀಮಿತಗೊಂಡಾಗ ಸಿಸ್ಟಮ್ ಹೇಗೆ ವರ್ತಿಸುತ್ತದೆ ಎಂಬುದು ತಿಳಿಯಬೇಕಿದೆ.

ಈ ವೈಭವ ಏಕೆ ಮುಖ್ಯ

Mixture-of-experts ವಿನ್ಯಾಸಗಳು ಒಂದು ಬೃಹತ್ parameter pool ಅನ್ನು ನಿರ್ದಿಷ್ಟ "expert" ಅನ್ನು ಕರೆಯುವವರೆಗೆ ಸುಪ್ತವಾಗಿರಲು ಬಿಡುತ್ತವೆ, ಇದರಿಂದಾಗಿ ಇದು ಅದೇ ಗಾತ್ರದ dense model ಅನ್ನು விட ಕಡಿಮೆ inference ವೆಚ್ಚವನ್ನು ಹೊಂದಿರುತ್ತದೆ. Multimodal input ಬಳಕೆಯನ್ನು ಕೇವಲ ಕೋಡ್ ಜನರೇಷನ್‌ನಿಂದ ಮೀರಿ ವಿಸ್ತರಿಸುತ್ತದೆ, ಇದು ಡೆವಲಪರ್‌ಗಳು ಡೈಗ್ರಾಮ್‌ಗಳು ಅಥವಾ ಸ್ಕ್ರೀನ್‌ಶಾಟ್‌ಗಳನ್ನು ಒಂದೇ ಪ್ರಾಂಪ್ಟ್‌ಗೆ ನೀಡಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ.

ಆದರೆ ಈ ಭರವಸೆಯು file editors, compilers, test runners ಮತ್ತು version-control commands ಅನ್ನು ಸಂಘಟಿಸುವ agent layer ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದೆ. ಒಂದು ವೇಳೆ ಆ ಲೇಯರ್ ವಿಫಲವಾದ tool call ನಿಂದ ಚೇತರಿಸಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ಇಡೀ ಕೋಡಿಂಗ್ ಸೆಷನ್ ಕುಸಿಯುತ್ತದೆ.

ಕಾಣೆಯಾದ ಭಾಗ: reasoning effort knob

Qwen3.8-Max ಮೂರು “reasoning effort” presets—low, medium, ಮತ್ತು xhigh—ಅಡಿಯಲ್ಲಿ ಬರುತ್ತದೆ. ಈ ಸೆಟ್ಟಿಂಗ್‌ಗಳು ವೇಗ ಮತ್ತು ಉತ್ತರದ ಗುಣಮಟ್ಟದ ನಡುವೆ ಹಾಗೂ ಮುಖ್ಯವಾಗಿ, ಮಾಡೆಲ್ ಹೊರಸೂಸುವ ಟೋಕನ್‌ಗಳ ಸಂಖ್ಯೆಯ ನಡುವೆ ಸಮತೋಲನವನ್ನು ಕಾಯ್ದುಕೊಳ್ಳುತ್ತವೆ.

ಪುನರಾವರ್ತಿಸಬಹುದಾದ ಪರೀಕ್ಷಾ ಯೋಜನೆ

Marketing claims ಗಳನ್ನು ಮೀರಿ ನೋಡಲು, ನಿಗದಿತ ಟೋಕನ್ ಬಜೆಟ್‌ನೊಂದಿಗೆ ಈ ಕೆಳಗಿನ ಪ್ರಾಯೋಗಿಕ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಪ್ರಯತ್ನಿಸಿ:

  1. ಹೊಸ ರೆಪೊಸಿಟರಿಯನ್ನು ರಚಿಸಿ (Create a fresh repository): ಯಾವುದೇ ಭಾಷೆಯಲ್ಲಿ ಸರಳವಾದ “hello world” scaffold ಬಳಸಿ.
  2. ಏಜೆಂಟ್‌ಗೆ ಪ್ರಾಂಪ್ಟ್ ನೀಡಿ (Prompt the agent): ಒಂದು ಹೊಸ ಫೀಚರ್ (ಉದಾಹರಣೆಗೆ, ಒಂದು REST endpoint) ಅನ್ನು ಸೇರಿಸಲು ಮತ್ತು ಅದು ನೀಡುವ ಪ್ರತಿಯೊಂದು ಪ್ಲಾನ್, ಮಾಡುವ ಪ್ರತಿಯೊಂದು tool call ಮತ್ತು ಸ್ಪರ್ಶಿಸುವ ಪ್ರತಿಯೊಂದು ಫೈಲ್ ಅನ್ನು ದಾಖಲಿಸಿ.
  3. ಮೊದಲ ವೈಫಲ್ಯದ ನಂತರ ಅಡ್ಡಿಪಡಿಸಿ (Interrupt on first failure): ಉದಾಹರಣೆಗೆ, ಕಂಪೈಲೇಶನ್ ಎರರ್ ಕಾಣಿಸಿಕೊಂಡಾಗ—ಮಾಡೆಲ್‌ನ ಆಂತರಿಕ ಸ್ಥಿತಿಯನ್ನು (internal state) ಉಳಿಸಿ, ನಂತರ ಆ checkpoint‌ನಿಂದ ಪುನರಾರಂಭಿಸಿ.
  4. ಚಾಲನೆಯನ್ನು ಪುನರಾವರ್ತಿಸಿ (Repeat the run): ಪ್ರತಿ reasoning effort ಸೆಟ್ಟಿಂಗ್ ಅಡಿಯಲ್ಲಿ ಚಾಲನೆಯನ್ನು ಪುನರಾವರ್ತಿಸಿ, ಒಟ್ಟು ಟೋಕನ್‌ಗಳು, ತಗಲಿದ ಸಮಯ (wall-clock time) ಮತ್ತು ಯಾವುದೇ tool-level ದೋಷಗಳನ್ನು ಗಮನಿಸಿ.
  5. ಅನುಮತಿಗಳನ್ನು ಸೀಮಿತಗೊಳಿಸಿ (Restrict permissions): ಏಜೆಂಟ್ ಹೇಗೆ ಹೊಂದಿಕೊಳ್ಳುತ್ತದೆ ಎಂದು ನೋಡಲು ಒಂದು ಬಾರಿ ಅನುಮತಿಗಳನ್ನು ಸೀಮಿತಗೊಳಿಸಿ (read-only access) ಮತ್ತು ಇನ್ನೊಮ್ಮೆ ಪೂರ್ಣ write access ನೀಡಿ.
  6. Retries ಅನ್ನು ಲಾಗ್ ಮಾಡಿ (Log retries): ಮಾಡೆಲ್ ವಿಫಲವಾದ tool ಅನ್ನು ರದ್ದುಗೊಳಿಸುವ ಬದಲು ಎಷ್ಟು ಬಾರಿ ಮತ್ತೆ ಕರೆಯುತ್ತದೆ?

ಈ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುವುದರಿಂದ ನೀವು ಕೇವಲ ಕೋಡಿಂಗ್ ಔಟ್‌ಪುಟ್ ಅನ್ನು ದೋಷ ನಿರ್ವಹಣೆಯ (error handling) ಗುಪ್ತ ವೆಚ್ಚದೊಂದಿಗೆ ಹೋಲಿಸಬಹುದು. ಏಜೆಂಟ್ ಪದೇ ಪದೇ ವಿಫಲವಾಗುವ linter ಅನ್ನು ಮತ್ತೆ ಪ್ರಯತ್ನಿಸಿದರೆ, ಅಂತಿಮ ಕೋಡ್ ಸರಿಯಾಗಿ ಕಂಡರೂ ಟೋಕನ್ ಬಿಲ್ ಹೆಚ್ಚಾಗಬಹುದು.

ಅಂಕಿಅಂಶಗಳು ಏನನ್ನು ಮರೆಮಾಚುತ್ತವೆ

95B active-parameter ಅಂಕಿಅಂಶ

Qwen3.8-Max ನ ಗಮನ ಸೆಳೆಯುವ ಗಾತ್ರ ಮತ್ತು ಮಲ್ಟಿಮೋಡಲ್ ವೈವಿಧ್ಯತೆಯು ಕೇವಲ ಅರ್ಧದಷ್ಟು ವಿಷಯವಷ್ಟೇ; ಡೆವಲಪರ್‌ಗಳಿಗೆ ನಿಜವಾದ ಮಾನದಂಡವೆಂದರೆ ಅದರ ಏಜೆಂಟ್ ಹಾರ್ನೆಸ್ ಟೂಲ್ ವೈಫಲ್ಯಗಳು, ಟೋಕನ್ ಬಜೆಟ್‌ಗಳು ಮತ್ತು ಅನುಮತಿ ಮಿತಿಗಳನ್ನು ಹೇಗೆ ನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದು. ತಾರ್ಕಿಕ ಪ್ರಯತ್ನ ಮತ್ತು ಪ್ರವೇಶ ಹಕ್ಕುಗಳನ್ನು ಬದಲಾಯಿಸುವ ಮೂಲಕ ನಡೆಸುವ ಶಿಸ್ತುಬದ್ಧವಾದ, ಪುನರಾವರ್ತಿತ ಪರೀಕ್ಷೆಯು, ಈ ಮಾಡೆಲ್ ತನ್ನ ಮಾರುಕಟ್ಟೆ ಭರವಸೆಗೆ ತಕ್ಕಂತೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆಯೇ ಅಥವಾ ಕೋಡಿಂಗ್ ಪೈಪ್‌ಲೈನ್‌ಗೆ ಕೇವಲ ಮತ್ತೊಂದು ದುಬಾರಿ ಹಂತವನ್ನು ಸೇರಿಸುತ್ತದೆಯೇ ಎಂಬುದನ್ನು ಬಹಿರಂಗಪಡಿಸುತ್ತದೆ.