DeepSeek એ V4 Pro general-availability (GA) મોડલ રિલીઝ કર્યું છે. શરૂઆતના માપદંડો દર્શાવે છે કે પ્રીવ્યુ બિલ્ડની સરખામણીમાં તે reasoning-token ના વપરાશમાં 18% થી 62% નો ઘટાડો કરે છે. જે લોકો પ્રતિ ટોકન ચૂકવણી કરે છે તેમના માટે આ મહત્વનું છે: સમાન પ્રોમ્પ્ટ્સ માટે હવે નોંધપાત્ર રીતે ઓછો ખર્ચ થાય છે, જ્યારે આઉટપુટ હજુ પણ સમાન જ મળે છે.

સરખામણી શા માટે કરવામાં આવી

GA રિલીઝ કોઈ બ્લોગ પોસ્ટ અથવા changelog વગર આવ્યું હતું, તેથી ડેવલપર્સે જાતે જ તફાવતો શોધવા પડ્યા હતા. એક કોમ્યુનિટી ટેસ્ટમાં બંને વર્ઝન પર સમાન કાર્યો કરવામાં આવ્યા અને સૌથી મોટો ફેરફાર જોવા મળ્યો—જવાબ આપતા પહેલા મોડલ "thinking" માં જે ટોકન્સ વાપરે છે તેમાં મોટો ઘટાડો થયો છે. સામાન્ય લુક-અપ્સ (look-ups) પર GA મોડલે 62% ઓછા reasoning tokens વાપર્યા; વધુ જટિલ ક્વેરીઝ પર આ ઘટાડો 18% હતો.

ટોકન કાર્યક્ષમતા અને તેની અસર

એક સામાન્ય extraction workflow માં, પ્રીવ્યુ બિલ્ડ પ્રોમ્પ્ટમાંથી થોડા ફિલ્ડ્સ મેળવવા માટે 159 reasoning tokens વાપરતું હતું. "thinking" ફીચર ડિસેબલ કરીને GA બિલ્ડ પર સ્વિચ કરવાથી આ સંખ્યા ઘટીને માત્ર 40 ટોકન્સ થઈ ગઈ. મીટરડ પ્લાન (metered plans) વાપરતા વપરાશકર્તાઓ માટે, આ બચત સીધી રીતે ઓછા બિલમાં પરિણમે છે, ખાસ કરીને મોટા પાયે (at scale).

JSON extraction: છુપાયેલી મુશ્કેલી

જ્યારે "thinking" મોડ ચાલુ હોય ત્યારે બંને બિલ્ડ્સ ભૂલ કરે છે: તેઓ JSON schema ચેક પાસ કરે છે પરંતુ ખોટા ન્યુમેરિકલ (numeric) મૂલ્યો ઉમેરે છે. જ્યારે "thinking" બંધ હોય ત્યારે માત્ર GA વર્ઝન જ સાચું JSON આપે છે. જે ટીમોને structured output ની જરૂર હોય તેમણે extraction કાર્યો માટે thinking flag ડિસેબલ કરી દેવો જોઈએ, અન્યથા તેમને વ્યાકરણની દ્રષ્ટિએ સાચો (syntactically valid) પરંતુ આંકડાકીય રીતે ખોટો (numerically incorrect) ડેટા મળશે.

રિફ્યુઝલ હેન્ડલિંગમાં મોટો ફેરફાર

પ્રીવ્યુ મોડલ જે પ્રશ્નનો જવાબ આપી શકે તેમ નથી તેને "I do not know" કહીને નકારી શકતું હતું. GA મોડલ હવે આવું કરતું નથી. તેના બદલે, તે કાં તો જવાબ આપ્યા વગર તેના ટોકન બજેટની બહાર નીકળી જાય છે અથવા ખોટો (fabricates) જવાબ આપે છે. આ ફેરફાર ટોકન કાર્યક્ષમતામાં સુધારો કરે છે પરંતુ તે સેફ્ટી નેટને દૂર કરે છે જે મોડલને અજાણ્યા વિષયો પર Hallucinate થતા અટકાવતું હતું.

વિશ્વસનીયતામાં વધારો

પ્રીવ્યુ બિલ્ડમાં એક જોખમી લૂપ (loop)—જે મર્યાદિત "thinking" બજેટને કારણે ટ્રિગર થતું હતું—મોડલને ત્યાં સુધી એક જ ટેક્સ્ટનું પુનરાવર્તન કરવા માટે મજબૂર કરી શકતું હતું જ્યાં સુધી 8,192-ટોકન વિન્ડો ભરાઈ ન જાય. GA રિલીઝ આ બગ (bug) ને સુધારે છે, જેનાથી અગાઉના અનિયંત્રિત પુનરાવર્તનને અંત આવે છે જે રિક્વેસ્ટ વિન્ડોને ખતમ કરવાનો અને ખર્ચ વધારવાનો જોખમ પેદા કરતું હતું.

વપરાશકર્તાઓએ શું ધ્યાન રાખવું જોઈએ

  • ઓછા ટોકન કાઉન્ટ માટે GA બિલ્ડનો ઉપયોગ કરો. કાર્યની જટિલતા ગમે તે હોય, માપવામાં આવેલા ઘટાડા જોવા મળે છે.
  • કોઈપણ JSON અથવા structured-data extraction માટે “thinking” બંધ કરો. આનાથી સાચા મૂલ્યો મળે છે અને ટોકનનો વપરાશ ન્યૂનતમ રહે છે.
  • ઇન-બિલ્ટ રિફ્યુઝલ (refusals) પર આધાર રાખશો નહીં. જો પ્રોમ્પ્ટમાં અપ્રમાણિત ડેટા માંગવામાં આવે, તો પણ GA મોડલ જવાબ આપી શકે છે, તેથી ડેટાનું પાછળથી વેરિફિકેશન (validation) કરવું અનિવાર્ય છે.
  • પીક-અવર બિલિંગ પર નજર રાખો. નવી પ્રાઇસિંગ નિયમોને કારણે હાઈ-ટ્રાફિક સમય દરમિયાન ટોકનનો વપરાશ અગાઉ કરતા વધુ ઝડપથી કુલ ખર્ચને અસર કરી શકે છે.

નિષ્કર્ષ

DeepSeek નું V4 Pro GA મોડલ સ્પષ્ટ કાર્યક્ષમતા આપે છે—62% સુધી ઓછા reasoning tokens—અને એક ગંભીર રિપીટીશન બગને સુધારે છે. જોકે, સ્પષ્ટ રિફ્યુઝલ પ્રતિસાદોનો અભાવ અને સચોટ JSON આઉટપુટ માટે thinking ડિસેબલ કરવાની જરૂરિયાત નવા પડકારો ઊભા કરે છે. જે ટીમો તેમના પાઇપલાઇન્સને અનુકૂળ બનાવશે તેઓ કાર્યક્ષમતા સાથે બાંધછોડ કર્યા વિના ખર્ચ ઘટાડી શકશે.

સ્ત્રોત: https://dev.to/synthorai/deepseek-v4-pro-ga-vs-preview-measured-18-62-less-thinking-539l