DeepSeek ਨੇ V4 Pro general-availability (GA) ਮਾਡਲ ਜਾਰੀ ਕਰ ਦਿੱਤਾ ਹੈ। ਸ਼ੁਰੂਆਤੀ ਮਾਪ ਦੱਸਦੇ ਹਨ ਕਿ ਇਹ preview build ਦੇ ਮੁਕਾਬਲੇ reasoning-token ਦੀ ਵਰਤੋਂ ਨੂੰ 18% ਤੋਂ 62% ਤੱਕ ਘਟਾਉਂਦਾ ਹੈ। ਇਹ ਉਨ੍ਹਾਂ ਲੋਕਾਂ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ ਜੋ ਪ੍ਰਤੀ ਟੋਕਨ (per token) ਭੁਗਤਾਨ ਕਰਦੇ ਹਨ: ਉਹੀ prompts ਹੁਣ ਕਾਫ਼ੀ ਘੱਟ ਕੀਮਤ 'ਤੇ ਮਿਲਦੇ ਹਨ ਜਦੋਂ ਕਿ output ਅਜੇ ਵੀ ਸਮਾਨ ਰਹਿੰਦੀ ਹੈ।

ਤੁਲਨਾ ਕਿਉਂ ਕੀਤੀ ਗਈ

GA ਰਿਲੀਜ਼ ਬਿਨਾਂ ਕਿਸੇ ਬਲੌਗ ਪੋਸਟ ਜਾਂ changelog ਦੇ ਆਈ, ਇਸ ਲਈ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਖੁਦ ਹੀ ਅੰਤਰ ਲੱਭਣੇ ਪਏ। ਇੱਕ ਕਮਿਊਨਿਟੀ ਟੈਸਟ ਨੇ ਦੋਵਾਂ ਵਰਜ਼ਨਾਂ 'ਤੇ ਇੱਕੋ ਜਿਹੇ ਕੰਮ ਕੀਤੇ ਅਤੇ ਸਭ ਤੋਂ ਵੱਡਾ ਬਦਲਾਅ ਲੱਭਿਆ—ਜਵਾਬ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਮਾਡਲ ਦੁਆਰਾ "thinking" ਵਿੱਚ ਖਰਚ ਕੀਤੇ ਜਾਣ ਵਾਲੇ tokens ਵਿੱਚ ਭਾਰੀ ਗਿਰਾਵਟ। ਸਧਾਰਨ look-ups 'ਤੇ GA ਮਾਡਲ ਨੇ 62% ਘੱਟ reasoning tokens ਦੀ ਵਰਤੋਂ ਕੀਤੀ; ਵਧੇਰੇ ਗੁੰਝਲਦਾਰ queries 'ਤੇ ਇਹ ਘਟਾਅਤ 18% ਸੀ।

Token ਕੁਸ਼ਲਤਾ ਅਤੇ ਇਸਦਾ ਪ੍ਰਭਾਵ

ਇੱਕ ਆਮ extraction workflow ਵਿੱਚ, preview build ਨੇ ਇੱਕ prompt ਤੋਂ ਕੁਝ fields ਕੱਢਣ ਲਈ 159 reasoning tokens ਖਰਚ ਕੀਤੇ ਸਨ। "thinking" ਫੀਚਰ ਨੂੰ disable ਕਰਕੇ GA build 'ਤੇ ਬਦਲਣ ਨਾਲ ਇਹ ਸੰਖਿਆ ਘਟ ਕੇ ਸਿਰਫ਼ 40 tokens ਰਹਿ ਗਈ। ਮੀਟਰਡ ਪਲਾਨ (metered plans) ਵਾਲੇ ਉਪਭੋਗਤਾਵਾਂ ਲਈ, ਇਹ ਬਚਤ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਘੱਟ ਬਿੱਲਾਂ ਵਿੱਚ ਬਦਲ ਜਾਂਦੀ ਹੈ, ਖਾਸ ਕਰਕੇ ਵੱਡੇ ਪੱਧਰ 'ਤੇ।

JSON extraction: ਇੱਕ ਲੁਕੀ ਹੋਈ ਮੁਸ਼ਕਲ

ਜਦੋਂ "thinking" ਮੋਡ ਚਾਲੂ ਹੁੰਦਾ ਹੈ ਤਾਂ ਦੋਵੇਂ builds ਅੜਖੜੇ ਪੈਂਦੇ ਹਨ: ਉਹ JSON schema ਚੈੱਕ ਤਾਂ ਪਾਸ ਕਰ ਲੈਂਦੇ ਹਨ ਪਰ ਗਲਤ numeric ਮੁੱਲ ਦਰਜ ਕਰਦੇ ਹਨ। ਸਿਰਫ਼ GA ਵਰਜ਼ਨ ਹੀ ਸਹੀ JSON ਵਾਪਸ ਕਰਦਾ ਹੈ ਜਦੋਂ "thinking" ਬੰਦ ਹੁੰਦਾ ਹੈ। ਜਿਨ੍ਹਾਂ ਟੀਮਾਂ ਨੂੰ structured output ਦੀ ਲੋੜ ਹੈ, ਉਨ੍ਹਾਂ ਨੂੰ extraction ਕੰਮਾਂ ਲਈ thinking flag ਨੂੰ disable ਕਰ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ, ਨਹੀਂ ਤਾਂ ਉਨ੍ਹਾਂ ਨੂੰ syntactically ਸਹੀ ਪਰ numerically ਗਲਤ ਡਾਟਾ ਮਿਲੇਗਾ।

Refusal handling ਨੇ ਸਥਿਤੀ ਬਦਲ ਦਿੱਤੀ

Preview ਮਾਡਲ ਅਜਿਹੇ ਸਵਾਲ ਨੂੰ ਰੱਦ ਕਰ ਸਕਦਾ ਸੀ ਜਿਸ ਨੂੰ ਉਹ ਅਣਉੱਤਰਯੋਗ ਸਮਝਦਾ ਸੀ, ਜਵਾਬ ਵਜੋਂ “I do not know” ਕਹਿੰਦਾ ਸੀ। GA ਮਾਡਲ ਹੁਣ ਅਜਿਹਾ ਨਹੀਂ ਕਰਦਾ। ਇਸ ਦੀ ਬਜਾਏ, ਇਹ ਜਾਂ ਤਾਂ ਜਵਾਬ ਦਿੱਤੇ ਬਿਨਾਂ ਆਪਣੇ token budget ਤੋਂ ਬਾਹਰ ਹੋ ਜਾਂਦਾ ਹੈ ਜਾਂ ਫਿਰ ਇੱਕ ਗਲਤ (fabricated) ਜਵਾਬ ਬਣਾਉਂਦਾ ਹੈ। ਇਹ ਬਦਲਾਅ token ਕੁਸ਼ਲਤਾ ਵਿੱਚ ਸੁਧਾਰ ਕਰਦਾ ਹੈ ਪਰ ਉਸ safety net ਨੂੰ ਹਟਾ ਦਿੰਦਾ ਹੈ ਜੋ ਮਾਡਲ ਨੂੰ ਅਣਜਾਣ ਵਿਸ਼ਿਆਂ 'ਤੇ hallucinating ਕਰਨ ਤੋਂ ਰੋਕਦਾ ਸੀ।

ਭਰੋਸੇਯੋਗਤਾ ਵਿੱਚ ਵਾਧਾ

Preview build ਵਿੱਚ ਇੱਕ ਖ਼ਤਰਨਾਕ loop—ਜੋ ਕਿ ਇੱਕ ਸੀਮਤ “thinking” ਬਜਟ ਕਾਰਨ ਸ਼ੁਰੂ ਹੁੰਦਾ ਸੀ—ਮਾਡਲ ਨੂੰ ਉਹੀ ਟੈਕਸਟ ਦੁਹਰਾਉਣ ਲਈ ਮਜਬੂਰ ਕਰ ਸਕਦਾ ਸੀ ਜਦੋਂ ਤੱਕ 8,192-token window ਭਰ ਨਹੀਂ ਜਾਂਦੀ ਸੀ। GA ਰਿਲੀਜ਼ ਇਸ bug ਨੂੰ ਠੀਕ ਕਰਦੀ ਹੈ, ਜਿਸ ਨਾਲ ਉਸ ਲਗਾਤਾਰ ਦੁਹਰਾਅ ਦਾ ਅੰਤ ਹੋ ਜਾਂਦਾ ਹੈ ਜੋ ਪਹਿਲਾਂ request window ਨੂੰ ਖਤਮ ਕਰਨ ਅਤੇ ਲਾਗਤ ਵਧਾਉਣ ਦਾ ਖ਼ਤਰਾ ਪੈਦਾ ਕਰਦਾ ਸੀ।

ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਕਿਸ ਚੀਜ਼ ਦਾ ਧਿਆਨ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ

  • ਘੱਟ token ਗਿਣਤੀ ਲਈ GA build ਦੀ ਵਰਤੋਂ ਕਰੋ। ਮਾਪੀਆਂ ਗਈਆਂ ਕਟੌਤੀਆਂ ਕੰਮ ਦੀ ਗੁੰਝਲਤਾ ਦੇ ਅਨੁਸਾਰ ਬਣੀ ਰਹਿੰਦੀਆਂ ਹਨ।
  • ਕਿਸੇ ਵੀ JSON ਜਾਂ structured-data extraction ਲਈ “thinking” ਨੂੰ ਬੰਦ ਕਰ ਦਿਓ। ਇਸ ਨਾਲ ਸਹੀ ਮੁੱਲ ਮਿਲਦੇ ਹਨ ਅਤੇ token ਦੀ ਵਰਤੋਂ ਘੱਟ ਰਹਿੰਦੀ ਹੈ।
  • Built-in refusals 'ਤੇ ਭਰੋਸਾ ਨਾ ਕਰੋ। ਜੇਕਰ ਕੋਈ prompt ਅਜਿਹੇ ਡਾਟਾ ਦੀ ਮੰਗ ਕਰਦਾ ਹੈ ਜਿਸਦੀ ਪੁਸ਼ਟੀ ਨਹੀਂ ਕੀਤੀ ਜਾ ਸਕਦੀ, ਤਾਂ GA ਮਾਡਲ ਫਿਰ ਵੀ ਜਵਾਬ ਦੇ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ downstream validation ਜ਼ਰੂਰੀ ਰਹਿੰਦੀ ਹੈ।
  • Peak-hour billing 'ਤੇ ਨਜ਼ਰ ਰੱਖੋ। ਨਵੇਂ ਕੀਮਤ ਨਿਯਮਾਂ ਕਾਰਨ, ਜ਼ਿਆਦਾ ਟ੍ਰੈਫਿਕ ਵਾਲੇ ਸਮੇਂ ਦੌਰਾਨ token ਦੀ ਖਪਤ ਪਹਿਲਾਂ ਨਾਲੋਂ ਕਿਤੇ ਜ਼ਿਆਦਾ ਪ੍ਰਭਾਵ ਪਾ ਸਕਦੀ ਹੈ।

ਨਿਚੋੜ

DeepSeek ਦਾ V4 Pro GA ਮਾਡਲ ਕੁਸ਼ਲਤਾ ਵਿੱਚ ਇੱਕ ਸਪੱਸ਼ਟ ਜਿੱਤ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ—62% ਤੱਕ ਘੱਟ reasoning tokens—ਅਤੇ ਇੱਕ ਗੰਭੀਰ ਦੁਹਰਾਅ ਵਾਲੇ bug ਨੂੰ ਠੀਕ ਕਰਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਸਪੱਸ਼ਟ refusal ਜਵਾਬਾਂ ਦਾ ਨਾ ਹੋਣਾ ਅਤੇ ਸਹੀ JSON output ਲਈ thinking ਨੂੰ disable ਕਰਨ ਦੀ ਲੋੜ ਨਵੇਂ ਵਿਚਾਰਾਂ ਨੂੰ ਜੋੜਦੀ ਹੈ। ਉਹ ਟੀਮਾਂ ਜੋ ਆਪਣੇ pipelines ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਂਦੀਆਂ ਹਨ, ਉਹ ਕਾਰਜਸ਼ੀਲਤਾ ਨਾਲ ਸਮਝੌਤਾ ਕੀਤੇ ਬਿਨਾਂ ਲਾਗਤ ਘਟਾ ਸਕਦੀਆਂ ਹਨ।

Source: https://dev.to/synthorai/deepseek-v4-pro-ga-vs-preview-measured-18-62-less-thinking-539l