Alibaba ਨੇ 3 ਅਗਸਤ ਨੂੰ Qwen3.8-Max ਲਾਂਚ ਕੀਤਾ। ਇਹ ਇੱਕ mixture-of-experts ਮਾਡਲ ਹੈ ਜੋ 2.4 ਟ੍ਰਿਲੀਅਨ ਪੈਰਾਮੀਟਰਾਂ ਤੱਕ ਵਿਸਤਾਰਿਤ ਹੁੰਦਾ ਹੈ ਪਰ ਇਨਫਰੈਂਸ (inference) ਸਮੇਂ ਸਿਰਫ 95 ਬਿਲੀਅਨ ਹੀ ਐਕਟੀਵੇਟ ਹੁੰਦਾ ਹੈ। ਇਹ ਮਾਡਲ QwenCloud ਗੇਟਵੇ ਰਾਹੀਂ ਚਿੱਤਰਾਂ ਅਤੇ ਟੈਕਸਟ ਨੂੰ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ, ਅਤੇ Alibaba ਦਾ ਕਹਿਣਾ ਹੈ ਕਿ ਵੇਟਸ (weights) ਅਗਲੇ ਹਫ਼ਤੇ ਜਨਤਕ ਤੌਰ 'ਤੇ ਉਪਲਬਧ ਹੋ ਜਾਣਗੇ।
ਚਮਕਦਾਰ ਹੈੱਡਲਾਈਨ ਇੱਕ ਔਖੇ ਸਵਾਲ ਨੂੰ ਛੁਪਾਉਂਦੀ ਹੈ: ਕੀ ਮਾਡਲ ਦਾ ਏਜੰਟ ਭਰੋਸੇਮੰਦ ਤਰੀਕੇ ਨਾਲ ਕੋਡ ਲਿਖ ਸਕਦਾ ਹੈ ਜਦੋਂ ਉਹ ਟੂਲ ਜਿਨ੍ਹਾਂ 'ਤੇ ਇਹ ਨਿਰਭਰ ਕਰਦਾ ਹੈ, ਅਸਫਲ ਹੋ ਜਾਂਦੇ ਹਨ? ਵੈਂਡਰ ਦੇ ਡੈਮੋ ਇੱਕ ਦਸ-ਦਿਨ ਦੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਵੈ-ਨਿਰਭਰ ਕੋਡਿੰਗ ਸਪ੍ਰਿੰਟ ਨੂੰ ਦਿਖਾਉਂਦੇ ਹਨ ਜਿਸ ਨੇ ਜ਼ੀਰੋ ਤੋਂ ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਬਣਾਇਆ, ਪਰ ਉਹ ਰਨ Alibaba ਦੇ ਆਪਣੇ ਇਨਫਰਾਸਟ੍ਰਕਚਰ 'ਤੇ ਅਤੇ ਆਦਰਸ਼ ਅਨੁਮਤੀਆਂ (permissions) ਦੇ ਅਧੀਨ ਕੀਤੇ ਗਏ ਸਨ। ਅਸਲ ਦੁਨੀਆ ਦੇ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਇਹ ਜਾਣਨ ਦੀ ਲੋੜ ਹੈ ਕਿ ਟੋਕਨ ਸੀਮਾਵਾਂ, ਟੂਲ ਕਾਲ ਫੇਲ ਹੋਣ, ਜਾਂ ਰਾਈਟ ਐਕਸੈਸ (write access) ਸੀਮਤ ਹੋਣ 'ਤੇ ਸਿਸਟਮ ਕਿਵੇਂ ਵਿਵਹਾਰ ਕਰਦਾ ਹੈ।
ਹਾਈਪ (Hype) ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ
Mixture-of-experts ਡਿਜ਼ਾਈਨ ਇੱਕ ਵਿਸ਼ਾਲ ਪੈਰਾਮੀਟਰ ਪੂਲ ਨੂੰ ਉਦੋਂ ਤੱਕ ਸੌਂ ਕੇ ਰੱਖਣ ਦਿੰਦੇ ਹਨ ਜਦੋਂ ਤੱਕ ਕੋਈ ਖਾਸ "ਐਕਸਪਰਟ" ਨਹੀਂ ਬੁਲਾਇਆ ਜਾਂਦਾ, ਜਿਸ ਨਾਲ ਇਨਫਰੈਂਸ ਲਾਗਤਾਂ ਨੂੰ ਉਸੇ ਆਕਾਰ ਦੇ ਡੈਂਸ (dense) ਮਾਡਲ ਨਾਲੋਂ ਘੱਟ ਰੱਖਿਆ ਜਾਂਦਾ ਹੈ। ਮਲਟੀਮੋਡਲ ਇਨਪੁਟ ਕੋਡ ਜਨਰੇਸ਼ਨ ਤੋਂ ਇਲਾਵਾ ਵਰਤੋਂ ਦੇ ਮਾਮਲਿਆਂ ਨੂੰ ਵਧਾਉਂਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਡਿਵੈਲਪਰ ਇੱਕੋ ਪ੍ਰੋਂਪਟ ਵਿੱਚ ਡਾਇਗ੍ਰਾਮ ਜਾਂ ਸਕ੍ਰੀਨਸ਼ੌਟ ਭੇਜ ਸਕਦੇ ਹਨ।
ਪਰ ਇਹ ਵਾਅਦਾ ਉਸ ਏਜੰਟ ਲੇਅਰ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਜੋ ਫਾਈਲ ਐਡੀਟਰਾਂ, ਕੰਪਾਈਲਰਾਂ, ਟੈਸਟ ਰਨਰਾਂ ਅਤੇ ਵਰਜ਼ਨ-ਕੰਟਰੋਲ ਕਮਾਂਡਾਂ ਦਾ ਪ੍ਰਬੰਧ ਕਰਦਾ ਹੈ। ਜੇਕਰ ਉਹ ਲੇਅਰ ਇੱਕ ਫੇਲ ਹੋਈ ਟੂਲ ਕਾਲ ਤੋਂ ਉਭਰ ਨਹੀਂ ਸਕਦੀ, ਤਾਂ ਪੂਰਾ ਕੋਡਿੰਗ ਸੈਸ਼ਨ ਟੁੱਟ ਜਾਂਦਾ ਹੈ।
ਗੁੰਮ ਹੋਇਆ ਹਿੱਸਾ: ਰੀਜ਼ਨਿੰਗ ਐਫਰਟ (reasoning effort) ਨੌਬ
Qwen3.8-Max ਤਿੰਨ "reasoning effort" ਪ੍ਰੀਸੈਟਸ—low, medium, ਅਤੇ xhigh ਦੇ ਨਾਲ ਆਉਂਦਾ ਹੈ। ਇਹ ਸੈਟਿੰਗਾਂ ਜਵਾਬ ਦੀ ਗੁਣਵੱਤਾ ਅਤੇ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਗੱਲ, ਮਾਡਲ ਦੁਆਰਾ ਜਾਰੀ ਕੀਤੇ ਜਾਣ ਵਾਲੇ ਟੋਕਨਾਂ ਦੀ ਗਿਣਤੀ ਲਈ ਸਪੀਡ ਨਾਲ ਸਮਝੌਤਾ ਕਰਦੀਆਂ ਹਨ।
ਇੱਕ ਰੀਪ੍ਰੋਡਿਊਸਿਬਲ (reproducible) ਟੈਸਟ ਪਲਾਨ
ਮਾਰਕੀਟਿੰਗ ਦਾਅਵਿਆਂ ਦੀ ਅਸਲੀਅਤ ਜਾਣਨ ਲਈ, ਇੱਕ ਨਿਸ਼ਚਿਤ ਟੋਕਨ ਬਜਟ ਦੇ ਨਾਲ ਹੇਠਾਂ ਦਿੱਤੇ ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਵਰਤੋਂ ਕਰੋ:
- ਇੱਕ ਨਵਾਂ ਰੈਪੋਜ਼ਟਰੀ (repository) ਬਣਾਓ ਕਿਸੇ ਵੀ ਭਾਸ਼ਾ ਵਿੱਚ ਇੱਕ ਸਧਾਰਨ “hello world” ਸਕੈਫੋਲਡ (scaffold) ਦੇ ਨਾਲ।
- ਏਜੰਟ ਨੂੰ ਪ੍ਰੋਂਪਟ ਕਰੋ ਇੱਕ ਨਵਾਂ ਫੀਚਰ (ਜਿਵੇਂ ਕਿ ਇੱਕ REST endpoint) ਜੋੜਨ ਲਈ ਅਤੇ ਇਸ ਦੁਆਰਾ ਜਾਰੀ ਕੀਤੇ ਗਏ ਹਰ ਪਲਾਨ, ਇਸ ਦੁਆਰਾ ਕੀਤੀ ਗਈ ਹਰ ਟੂਲ ਕਾਲ, ਅਤੇ ਇਸ ਦੁਆਰਾ ਛੇੜੀ ਗਈ ਹਰ ਫਾਈਲ ਨੂੰ ਰਿਕਾਰਡ ਕਰੋ।
- ਪਹਿਲੀ ਅਸਫਲਤਾ 'ਤੇ ਰੋਕੋ—ਉਦਾਹਰਨ ਲਈ, ਜਦੋਂ ਕੋਈ ਕੰਪਾਈਲੇਸ਼ਨ ਐਰਰ (compilation error) ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ—ਮਾਡਲ ਦੀ ਅੰਦਰੂਨੀ ਸਥਿਤੀ (internal state) ਨੂੰ ਸੇਵ ਕਰੋ, ਫਿਰ ਉਸ ਚੈੱਕਪੁਆਇੰਟ ਤੋਂ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰੋ।
- ਹਰ reasoning effort ਸੈਟਿੰਗ ਦੇ ਅਧੀਨ ਰਨ ਨੂੰ ਦੁਹਰਾਓ, ਕੁੱਲ ਟੋਕਨ, ਲੱਗਿਆ ਸਮਾਂ (wall-clock time), ਅਤੇ ਕਿਸੇ ਵੀ ਟੂਲ-ਲੇਵਲ ਦੀਆਂ ਗਲਤੀਆਂ ਨੂੰ ਨੋਟ ਕਰੋ।
- ਇੱਕ ਪਾਸ ਵਿੱਚ ਇਜਾਜ਼ਤਾਂ ਨੂੰ ਸੀਮਤ ਕਰੋ (read-only access) ਅਤੇ ਦੂਜੇ ਵਿੱਚ ਪੂਰੀ ਰਾਈਟ ਐਕਸੈਸ (write access) ਦਿਓ, ਇਹ ਦੇਖਣ ਲਈ ਕਿ ਏਜੰਟ ਕਿਵੇਂ ਅਨੁਕੂਲਿਤ ਹੁੰਦਾ ਹੈ।
- ਰੀਟ੍ਰਾਈਜ਼ (retries) ਨੂੰ ਲੌਗ ਕਰੋ: ਮਾਡਲ ਅਸਫਲ ਟੂਲ ਨੂੰ ਰੱਦ ਕਰਨ ਦੀ ਬਜਾਏ ਕਿੰਨੀ ਵਾਰ ਦੁਬਾਰਾ ਬੁਲਾਉਂਦਾ ਹੈ?
ਇਹਨਾਂ ਮੈਟ੍ਰਿਕਸ ਨੂੰ ਇਕੱਠਾ ਕਰਨ ਨਾਲ ਤੁਸੀਂ ਸ਼ੁੱਧ ਕੋਡਿੰਗ ਆਉਟਪੁੱਟ ਦੀ ਤੁਲਨਾ ਗਲਤੀਆਂ ਨੂੰ ਸੰਭਾਲਣ ਦੀ ਲੁਕੀ ਹੋਈ ਲਾਗਤ ਨਾਲ ਕਰ ਸਕਦੇ ਹੋ। ਜੇਕਰ ਏਜੰਟ ਵਾਰ-ਵਾਰ ਇੱਕ ਖਰਾਬ ਲਿੰਟਰ (linter) ਨੂੰ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ, ਤਾਂ ਟੋਕਨ ਦਾ ਬਿੱਲ ਵਧ ਜਾਵੇਗਾ ਭਾਵੇਂ ਅੰਤਿਮ ਕੋਡ ਠੀਕ ਲੱਗੇ।
ਅੰਕੜੇ ਕੀ ਛੁਪਾਉਂਦੇ ਹਨ
95B ਐਕਟਿਵ-ਪੈਰਾਮੀਟਰਾਂ ਦਾ ਅੰਕੜਾ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਡਾਲਰ ਦੀ ਰਕਮ ਵਿੱਚ ਨਹੀਂ ਬਦਲਦਾ। ਗਲਤੀਆਂ ਵਾਪਸ ਕਰਨ ਵਾਲੇ ਟੂਲ ਕਾਲ ਮਾਡਲ ਨੂੰ ਸੁਧਾਰ ਲਿਆਉਣ ਵਾਲੇ ਪ੍ਰੋਂਪਟ ਬਣਾਉਣ ਲਈ ਮਜਬੂਰ ਕਰਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਟੋਕਨ ਦੀ ਵਰਤੋਂ ਵਧ ਜਾਂਦੀ ਹੈ। ਟਿਕਾਊ ਸਟੇਟ (durable state)—ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਚੈੱਕਪੁਆਇੰਟ ਜੋ ਤੁਹਾਨੂੰ ਕ੍ਰੈਸ਼ ਤੋਂ ਬਾਅਦ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ—ਦੇ ਬਿਨਾਂ, ਇੱਕ ਸਿੰਗਲ ਅਸਫਲ
Qwen3.8-Max ਦਾ ਸੁਰਖੀਆਂ ਖਿੱਚਣ ਵਾਲਾ ਆਕਾਰ ਅਤੇ ਮਲਟੀਮੋਡਲ ਸੁਭਾਅ ਸਿਰਫ਼ ਅੱਧੀ ਕਹਾਣੀ ਹੈ; ਡਿਵੈਲਪਰਾਂ ਲਈ ਅਸਲ ਮਾਪਦੰਡ ਇਹ ਹੈ ਕਿ ਇਸਦਾ agent harness ਟੂਲ ਦੀਆਂ ਅਸਫਲਤਾਵਾਂ, ਟੋਕਨ ਬਜਟ ਅਤੇ ਇਜਾਜ਼ਤ ਦੀਆਂ ਸੀਮਾਵਾਂ ਨੂੰ ਕਿਵੇਂ ਸੰਭਾਲਦਾ ਹੈ। ਇੱਕ ਅਨੁਸ਼ਾਸਿਤ, ਦੁਹਰਾਉਣਯੋਗ ਟੈਸਟ—ਜਿਸ ਵਿੱਚ ਤਰਕਸ਼ੀਲਤਾ ਦੇ ਯਤਨਾਂ ਅਤੇ ਪਹੁੰਚ ਅਧਿਕਾਰਾਂ ਵਿੱਚ ਤਬਦੀਲੀ ਕੀਤੀ ਗਈ ਹੋਵੇ—ਇਹ ਸਾਹਮਣੇ ਲਿਆਵੇਗਾ ਕਿ ਕੀ ਇਹ ਮਾਡਲ ਆਪਣੇ ਮਾਰਕੀਟਿੰਗ ਵਾਅਦੇ 'ਤੇ ਖਰਾ ਉਤਰਦਾ ਹੈ ਜਾਂ ਸਿਰਫ਼ ਕੋਡਿੰਗ ਪਾਈਪਲਾਈਨ ਵਿੱਚ ਇੱਕ ਹੋਰ ਮਹਿੰਗੀ ਪਰਤ ਜੋੜਦਾ ਹੈ।