DeepSeek তাদের V4 Pro general-availability (GA) মডেলটি প্রকাশ করেছে। প্রাথমিক পরিমাপ অনুযায়ী, প্রিভিউ বিল্ডের তুলনায় এটি reasoning-token ব্যবহার ১৮% থেকে ৬২% কমিয়ে দেয়। যারা প্রতি টোকেনের জন্য অর্থ প্রদান করেন তাদের জন্য এটি অত্যন্ত গুরুত্বপূর্ণ: একই প্রম্পটের জন্য এখন উল্লেখযোগ্যভাবে কম খরচ হবে, অথচ আউটপুট প্রায় একই রকম থাকবে।

কেন এই তুলনা করা হলো

GA রিলিজটি কোনো ব্লগ পোস্ট বা চ্যানজলগ (changelog) ছাড়াই এসেছে, তাই ডেভেলপারদের নিজেদের প্রচেষ্টায় পার্থক্যগুলো খুঁজে নিতে হয়েছে। একটি কমিউনিটি টেস্ট উভয় ভার্সনে একই ধরণের কাজ চালিয়ে একটি বড় পরিবর্তন লক্ষ্য করেছে—উত্তর দেওয়ার আগে মডেলটি "thinking" বা চিন্তা করার জন্য যে টোকেন ব্যয় করে, তার পরিমাণ ব্যাপকভাবে কমে গেছে। সাধারণ অনুসন্ধানের ক্ষেত্রে GA মডেলটি ৬২% কম reasoning token ব্যবহার করেছে; আর জটিল প্রশ্নের ক্ষেত্রে এই হ্রাস ছিল ১৮%।

টোকেন দক্ষতা এবং এর প্রভাব

একটি সাধারণ extraction workflow-এ, প্রিভিউ বিল্ড একটি প্রম্পট থেকে কয়েকটি ফিল্ড বের করার জন্য ১৫৯টি reasoning token খরচ করত। "thinking" ফিচারটি নিষ্ক্রিয় করে GA বিল্ডে সুইচ করলে সেই সংখ্যাটি কমে মাত্র ৪০টি টোকেনে দাঁড়িয়েছে। মিটারড প্ল্যান (metered plans) ব্যবহারকারী গ্রাহকদের জন্য এই সাশ্রয় সরাসরি বিল কমিয়ে দেবে, বিশেষ করে বড় পরিসরে ব্যবহারের ক্ষেত্রে।

JSON extraction: একটি লুকানো সমস্যা

"thinking" মোড চালু থাকলে উভয় বিল্ডই সমস্যায় পড়ে: তারা JSON schema চেক পাস করলেও ভুল সংখ্যাগত মান (numeric values) প্রদান করে। শুধুমাত্র GA ভার্সনটি "thinking" বন্ধ থাকলে সঠিক JSON প্রদান করে। যে দলগুলোর structured output প্রয়োজন, তাদের extraction কাজের জন্য thinking flag নিষ্ক্রিয় করে রাখা উচিত, অন্যথায় তারা সিনট্যাক্স অনুযায়ী সঠিক কিন্তু গাণিতিকভাবে ভুল ডেটা পেতে পারেন।

রিফিউজাল হ্যান্ডলিং (Refusal handling) এর পরিবর্তন

প্রিভিউ মডেলটি কোনো প্রশ্ন উত্তরযোগ্য নয় বলে মনে করলে "I do not know" বলে উত্তর দিতে পারত। GA মডেলটি এখন আর তা করে না। পরিবর্তে, এটি হয় উত্তর না দিয়ে টোকেন বাজেট শেষ করে ফেলে, অথবা একটি কাল্পনিক উত্তর (fabricate) তৈরি করে। এই পরিবর্তন টোকেন দক্ষতা বাড়ালেও সেই সেফটি নেটটি সরিয়ে দিয়েছে যা মডেলটিকে অজানা বিষয়ে ভুল তথ্য বা hallucination দেওয়া থেকে বিরত রাখত।

নির্ভরযোগ্যতা বৃদ্ধি

প্রিভিউ বিল্ডে একটি বিপজ্জনক লুপ ছিল—যা একটি সীমিত "thinking" বাজেটের কারণে তৈরি হতো—এবং মডেলটি একই টেক্সট বারবার পুনরাবৃত্তি করতে থাকতো যতক্ষণ না ৮,১৯২-টোকেন উইন্ডোটি পূর্ণ হতো। GA রিলিজটি এই বাগটি সমাধান করেছে, ফলে সেই অনিয়ন্ত্রিত পুনরাবৃত্তি বন্ধ হয়েছে যা আগে রিকোয়েস্ট উইন্ডো শেষ করে দেওয়ার এবং খরচ বাড়িয়ে দেওয়ার ঝুঁকি তৈরি করত।

ব্যবহারকারীদের যা খেয়াল রাখা উচিত

  • কম টোকেন ব্যবহারের জন্য GA বিল্ড ব্যবহার করুন। কাজের জটিলতা নির্বিশেষে টোকেন হ্রাসের এই হার বজায় থাকে।
  • যেকোনো JSON বা structured-data extraction-এর জন্য “thinking” বন্ধ রাখুন। এটি সঠিক মান নিশ্চিত করে এবং টোকেন ব্যবহার সর্বনিম্ন রাখে।
  • বিল্ট-ইন রিফিউজালের (refusals) ওপর নির্ভর করবেন না। যদি কোনো প্রম্পটে যাচাই অযোগ্য ডেটা চাওয়া হয়, তবে GA মডেলটি তবুও উত্তর দিতে পারে, তাই পরবর্তী যাচাইকরণ (downstream validation) অপরিহার্য।
  • পিক-আওয়ার বিলিংয়ের দিকে নজর দিন। নতুন প্রাইসিং নিয়মের কারণে হাই-ট্রাফিক সময়ে টোকেন ব্যবহার আগের চেয়ে সামগ্রিক খরচের ওপর বেশি প্রভাব ফেলবে।

সারকথা

DeepSeek-এর V4 Pro GA মডেলটি স্পষ্ট দক্ষতা বৃদ্ধি নিশ্চিত করেছে—reasoning token ব্যবহার ৬২% পর্যন্ত কমিয়ে দেয়—এবং একটি গুরুত্বপূর্ণ রিপিটেশন বাগ সংশোধন করেছে। তবে, সরাসরি রিফিউজাল রেসপন্স না থাকা এবং সঠিক JSON আউটপুটের জন্য thinking নিষ্ক্রিয় করার প্রয়োজনীয়তা নতুন কিছু বিবেচনার বিষয় যোগ করেছে। যে দলগুলো তাদের পাইপলাইন অনুযায়ী মানিয়ে নেবে, তারা কার্যকারিতা বজায় রেখেই খরচ কমাতে পারবে।

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