DeepSeek V4 API ट्यूटोरियल: थिंकिंग मोड एरीना बनाना

DeepSeek V4 क्या है?

DeepSeek V4 DeepSeek AI की नवीनतम पीढ़ी के Mixture-of-Experts (MoE) भाषा मॉडल हैं। इस श्रृंखला में दो वेरिएंट शामिल हैं:

• DeepSeek-V4-Pro: इसमें कुल 1.6T पैरामीटर्स (49B सक्रिय) हैं और यह 1M टोकन की कॉन्टेक्स्ट लंबाई सपोर्ट करता है।
• DeepSeek-V4-Flash: छोटे मॉडल संस्करण में कुल 284B पैरामीटर्स (13B सक्रिय) होते हैं, और इसमें भी 1M-टोकन का कॉन्टेक्स्ट विंडो है।

कई आर्किटेक्चरल सुधार V4 को इसके पूर्ववर्तियों से अलग बनाते हैं:

चित्र: DeepSeek V4 श्रृंखला की आर्किटेक्चर (DeepSeek तकनीकी रिपोर्ट)

• हाइब्रिड अटेंशन आर्किटेक्चर (CSA / HCA): प्रत्येक ब्लॉक में दाहिना पाथ (ऊपर दिए चित्र से) Compressed Sparse Attention (CSA) और Heavily Compressed Attention (HCA) से शुरू होता है। हर लेयर पर हर टोकन पर अटेंड करने के बजाय, ये मैकेनिज्म चयनात्मक रूप से अटेंशन गणना को कंप्रेस करते हैं। 1M-टोकन कॉन्टेक्स्ट में, इसका अर्थ है कि DeepSeek-V4-Pro को DeepSeek-V3.2 की तुलना में सिंगल-टोकन इन्फरेंस FLOPs का केवल 27% और KV कैश का 10% चाहिए। अटेंशन आउटपुट को प्री-ब्लॉक और पोस्ट-ब्लॉक मिक्सिंग से रूट किया जाता है, फिर रेजिडुअल कनेक्शन के जरिए मुख्य हिडन स्टेट में जोड़ा जाता है।
• DeepSeekMoE: अटेंशन के बाद, यही पाथ DeepSeekMoE लेयर में फीड होता है, जहाँ Mixture-of-Experts घटक प्रति टोकन केवल पैरामीटर्स के एक सबसेट को सक्रिय करता है। यही कारण है कि V4-Flash के 284B कुल पैरामीटर्स इन्फरेंस समय पर 13B मॉडल जैसे बर्ताव करते हैं, और V4-Pro के 1.6T पैरामीटर्स 49B मॉडल जैसे।
• Manifold-Constrained Hyper-Connections (mHC): बायाँ पाथ (ऊपर दिए चित्र से) यह दिखाता है कि स्टैक्ड हिडन स्टेट रिप्रेजेंटेशन प्रत्येक ब्लॉक के नीचे और ऊपर Residual Mixing से होकर बहते हैं। ये mHC लेयर्स हैं, जहाँ मानक रेजिडुअल कनेक्शंस के स्थान पर ऐसा विकल्प प्रयोग होता है जो अपडेट्स को एक सीखे हुए मैनिफोल्ड तक सीमित रखता है, जिससे डीप स्टैक्स में ग्रेडिएंट सिग्नल स्थिरता सुधरती है, अभिव्यक्तिगत क्षमता से समझौता किए बिना।
• Muon Optimizer: Muon (जो आर्किटेक्चर डायग्राम में दृष्टिगोचर नहीं) अधिकांश पैरामीटर्स के लिए AdamW को प्रतिस्थापित करता है और दूसरे-ऑर्डर-प्रेरित अपडेट नियम का उपयोग करता है, जो V4 के प्रशिक्षण पैमानों पर तेज कन्वर्जेन्स और अधिक स्थिर लॉस कर्व प्रदान करता है।

दोनों मॉडल तीन अलग-अलग रीजनिंग-एफर्ट मोड्स सपोर्ट करते हैं — Non-think, Think High, और Think Max — जिन्हें हम इस ट्यूटोरियल में समझेंगे और तुलना करेंगे।

DeepSeek V4 बेंचमार्क स्कोर

DeepSeek टीम ने V4 मॉडल के प्रदर्शन की समकक्ष मॉडलों से तुलना की, और यह परिणाम मिले:

चित्र: DeepSeek V4 श्रृंखला का बेंचमार्क प्रदर्शन (DeepSeek तकनीकी रिपोर्ट)

बाएँ बार चार्ट दिखाता है कि V4-Pro-Max ज्ञान, तर्क और एजेंटिक कार्यों में फ्रंटियर क्लोज़्ड-सोर्स मॉडलों के सापेक्ष कहाँ आता है। दाएँ के दो प्लॉट दिखाते हैं कि कार्यक्षमता लाभ क्यों मायने रखते हैं — और ये अधिक चौंकाने वाले परिणाम हैं। DeepSeek-V4-Pro-Max (Think Max रीजनिंग मोड) फ्रंटियर क्लोज़्ड-सोर्स मॉडलों के मुकाबले प्रतिस्पर्धी परिणाम हासिल करता है:

3206 की Codeforces रेटिंग V4-Pro-Max को Legendary Grandmaster स्तर पर रखती है, जिससे हमारे एरीना में कोडिंग कार्य वास्तविक रूप से रोचक स्ट्रेस टेस्ट बन जाते हैं।

तीनों थिंकिंग मोड्स को समझना

ऐप बनाने से पहले, यह समझना उपयोगी है कि हर मोड वास्तव में क्या करता है:

• Non-think: मॉडल बिना किसी आंतरिक चेन-ऑफ-थॉट के सीधे प्रतिक्रिया देता है। यह मोड उन कार्यों के लिए आदर्श है जहाँ गति गहराई से अधिक मायने रखती है, जैसे फॉर्मेट रूपांतरण, सरल लुकअप, और एक-वाक्य सारांश।
• Think High: मॉडल उत्तर देने से पहले क्रमबद्ध तरीके से तर्क करता है। यह मोड मध्यम जटिल कार्यों (डिबगिंग, सिस्टम डिज़ाइन, और प्लानिंग) के लिए गहराई और लागत का अच्छा संतुलन प्रदान करता है।
• Think Max: मॉडल रीजनिंग को अधिकतम स्तर तक धकेलता है, कई दृष्टिकोणों का अन्वेषण करता है, अपने तर्क को कड़ाई से सत्यापित करता है, और तभी अंतिम उत्तर देता है जब उसे यकीन हो। इसलिए, Think Max मोड कठिन गणितीय प्रमाणों, जटिल मल्टी-फाइल रिफैक्टर, या ऐसे किसी भी कार्य के लिए सर्वोत्तम है जहाँ गलत आत्मविश्वासी उत्तर एक धीमे लेकिन सत्यापित उत्तर से बदतर हो।

इस ट्यूटोरियल की मुख्य समझ यह है कि Think Max हमेशा नहीं जीतता। तुच्छ कार्यों पर, यह समान गुणवत्ता के लिए compute बर्बाद करता है। एरीना का लक्ष्य यह दिखाना है कि वास्तविक विलंबता, टोकन गिनती, लागत और उपयोगकर्ता रेटिंग के आधार पर किस कार्य प्रकार के लिए कौन-सा मोड वास्तव में सार्थक है।

यदि आप देखना चाहते हैं कि यह मॉडल अन्य अत्याधुनिक LLMs की तुलना में कैसा है, तो मैं हमारे ये लेख पढ़ने की सलाह दूंगा: Claude Opus 4.7 बनाम DeepSeek V4 और GPT-5.5 बनाम DeepSeek V4।

ट्यूटोरियल: DeepSeek V4 के साथ थिंक मोड एरीना बनाना

इस ट्यूटोरियल में, हम एक Streamlit एप्लिकेशन बनाएंगे जो:

• उपयोगकर्ता से प्रॉम्प्ट और टास्क श्रेणी स्वीकार करता है

• Python के ThreadPoolExecutor का उपयोग करके, प्रत्येक रीजनिंग मोड के लिए एक, तीन समानांतर API कॉल्स करता है

• मॉडल के आउटपुट में <think>...</think> ब्लॉक्स से थिंकिंग ट्रेस पार्स करता है

• प्रत्येक मोड के लिए विलंबता, टोकन गिनती, और अनुमानित लागत ट्रैक करता है

• मेट्रिक्स, यूज़र रेटिंग सिस्टम, और विजेता सारांश के साथ साइड-बाय-साइड तुलना प्रस्तुत करता है

पूरा काम करने वाला ऐप एकल app.py फ़ाइल है—किसी बाहरी डेटाबेस या बैकग्राउंड सेवाओं की आवश्यकता नहीं।

इस ट्यूटोरियल का पूरा कोड मेरे GitHub रिपॉजिटरी में उपलब्ध है।

चरण 1: प्रोजेक्ट सेटअप और डिपेंडेंसीज़

एक प्रोजेक्ट फ़ोल्डर बनाकर और दो आवश्यक पैकेज इंस्टॉल करके शुरू करें:

mkdir deepseek-arena && cd deepseek-arena
pip install streamlit>=1.32.0 openai>=1.12.0

openai लाइब्रेरी का उपयोग यहाँ इसलिए किया गया है क्योंकि DeepSeek का API OpenAI-संगत है, यानी हम OpenAI क्लाइंट को DeepSeek के बेस URL पर पॉइंट कर सकते हैं, और कोई अन्य बदलाव आवश्यक नहीं। किसी DeepSeek-विशिष्ट SDK की आवश्यकता नहीं है।

API कुंजी platform.deepseek.com से प्राप्त करें और इसे पर्यावरण वेरिएबल के रूप में सेट करें:

export DEEPSEEK_API_KEY="sk-..."

अब जब परिवेश सेट हो गया है, तो हम मॉडलों और उनके मोड्स को कॉन्फ़िगर करने पर जा सकते हैं।

चरण 2: कॉन्फ़िगरेशन — मॉडल, मोड, और प्राइसिंग

कोई भी लॉजिक लिखने से पहले, हम इम्पोर्ट्स, मॉडल आइडेंटिफ़ायर्स, रीजनिंग मोड कॉन्फ़िगरेशन, और प्राइसिंग कॉन्स्टेंट्स परिभाषित करते हैं। ये डिक्शनरी पूरे ऐप का व्यवहार नियंत्रित करती हैं — जैसे मॉडल ड्रॉपडाउन, हर रीजनिंग मोड को चलाने वाले API पैरामीटर्स, UI कलर स्कीम, और तुलना पैनल में दिखाई जाने वाली लागत के अनुमान।

import os
import time
import concurrent.futures
from dataclasses import dataclass
from typing import Optional, Dict
import streamlit as st
from openai import OpenAI
DEEPSEEK_BASE_URL = "https://api.deepseek.com/"
DEEPSEEK_API_KEY_ENV = "DEEPSEEK_API_KEY"
MODELS = {
    "DeepSeek-V4-Flash (default)": "deepseek-v4-flash",
    "DeepSeek-V4-Pro": "deepseek-v4-pro",
}
MODES: Dict[str, dict] = {
    "Non-think": {
        "icon": "",
        "color": "#10b981",
        "badge": "green",
        "desc": "Fast, direct answers — no internal reasoning",
        "thinking_type": "disabled",
        "reasoning_effort": None,
    },
    "Think High": {
        "icon": "",
        "color": "#3b82f6",
        "badge": "blue",
        "desc": "Careful step-by-step reasoning before responding",
        "thinking_type": "enabled",
        "reasoning_effort": "high",
    },
    "Think Max": {
        "icon": "",
        "color": "#ef4444",
        "badge": "red",
        "desc": "Exhaustive reasoning — push analysis to the limit",
        "thinking_type": "enabled",
        "reasoning_effort": "max",
    },
}
PRICING = {
    "deepseek-v4-flash": {
        "input_cache_hit":  0.0028,
        "input_cache_miss": 0.14,
        "output":           0.28,
    },
    "deepseek-v4-pro": {
        "input_cache_hit":  0.003625,
        "input_cache_miss": 0.435,
        "output":           0.87,
    },
}

यहाँ कुछ डिज़ाइन विकल्प उल्लेखनीय हैं:

• थिंकिंग मोड के पैरामीटर्स: MODES में प्रत्येक प्रविष्टि सिस्टम प्रॉम्प्ट के बजाय दो API फ़ील्ड ले जाती है — thinking_type और reasoning_effort (“high”, "max", या None)। thinking_type को extra_body={"thinking": {"type": ...}} के जरिए पास किया जाता है, और reasoning_effort एक टॉप-लेवल रिक्वेस्ट पैरामीटर है। Non-think thinking_type को "disabled" सेट करता है और reasoning_effort को None छोड़ देता है, इसलिए कोई thinking body भेजी ही नहीं जाती।

• डिफ़ॉल्ट मॉडल के रूप में Flash: Flash प्रति टोकन 13B पैरामीटर्स सक्रिय करता है, जबकि Pro 49B, जिससे प्रयोग के दौरान तीन-तरफा समानांतर कॉल्स बार-बार चलाना किफायती रहता है। जब आपको फ्रंटियर परफॉर्मेंस चाहिए, Pro ड्रॉपडाउन से उपलब्ध है, पर Think Max ऑन Pro कोटा तेजी से खर्च करता है, इसलिए इसे डिफ़ॉल्ट के बजाय ऑप्ट-इन रखना जानबूझकर लगाया गया लागत-गार्डरेइल है।

ध्यान दें: ऊपर कोड में उपयोग किए गए मान V4-Pro पर इसके वर्तमान प्रोमोशनल डिस्काउंट को दर्शाते हैं। इसलिए, कोई भी लागत तुलना प्रकाशित करने से पहले हमेशा api-docs.deepseek.com/quick_start/pricing पर मौजूदा दरों की जाँच करें, क्योंकि नए मॉडल रिलीज़ के बाद बेस रेट्स और प्रोमोशनल डिस्काउंट अक्सर बदलते रहते हैं।

चरण 3: टास्क टेम्पलेट्स

किसी रीजनिंग तुलना को बनाने में टास्क डिज़ाइन सबसे कम आंकी गई चीज़ है। यदि सभी कार्य कठिन और ओपन-एंडेड हों, तो Think Max हर बार जीतता है और डेमो कुछ नहीं सिखाता। टास्क सेट को पूरी कठिनाई-रेंज कवर करनी चाहिए ताकि हर मोड के पास कम-से-कम एक ऐसी श्रेणी हो जहाँ वह जीते।

TASKS = {
    "Trivial / Lookup": {
        "prompt": (
            "Complete both tasks below:\n\n"
            "Task A — Convert this JSON to YAML:\n"
            '{"name": "Alice", "age": 30, "skills": ["Python", "ML", "LLMs"],\n'
            ' "address": {"city": "San Francisco", "zip": "94105"}}\n\n'
            "Task B — Summarize this paragraph in exactly one sentence:\n"
            '"Large language models have rapidly transformed natural language processing '
            "by demonstrating unprecedented capabilities across translation, summarization, "
            "reasoning, and code generation, driven by scale and alignment techniques like RLHF "
            'that bring model outputs closer to human intent."'
        ),
        "expected_winner": "Non-think",
        "tip": "Non-think should dominate here. No reasoning is required.",
    },
    "Coding / Debugging": {
        "prompt": (
            "Find every bug in the Python code below, explain each bug clearly, "
            "and provide a fully corrected version:\n\n"
            "```python\n"
            "def binary_search(arr, target):\n"
            "    left, right = 0, len(arr)\n"
            "    while left < right:\n"
            "        mid = (left + right) // 2\n"
            "        if arr[mid] == target:\n"
            "            return mid\n"
            "        elif arr[mid] < target:\n"
            "            left = mid\n"
            "        else:\n"
            "            right = mid - 1\n"
            "    return -1\n\n"
            "print(binary_search([1, 3, 5, 7, 9], 7))\n"
            "```"
        ),
        "expected_winner": "Think High",
        "tip": "Think High usually finds the bugs and explains them well.",
    },
    "System Design": {
        "prompt": (
            "Design a scalable vector search system for 100 million documents.\n\n"
            "Address each of the following:\n"
            "1. Indexing strategy and pipeline\n"
            "2. ANN algorithm selection (HNSW vs IVF-PQ vs ScaNN — justify your choice)\n"
            "3. Sharding and replication strategy\n"
            "4. p99 query latency target (< 50 ms) — how do you hit it?\n"
            "5. Real-time document update handling\n"
            "6. Top 3 failure modes and their mitigations"
        ),
        "expected_winner": "Think High",
        "tip": "Think High often gives the best quality-per-dollar design answer.",
    },
    "Planning": {
        "prompt": (
            "Create a detailed 6-month roadmap for deploying an enterprise RAG system.\n\n"
            "Include:\n"
            "- Month-by-month phases with concrete, measurable milestones\n"
            "- Top 5 risks and mitigation strategies\n"
            "- Team roles and headcount required per phase\n"
            "- Evaluation metrics for each phase (how do you know it's working?)\n"
            "- Go / no-go production checklist"
        ),
        "expected_winner": "Think High",
        "tip": "Think High should produce a more structured, complete roadmap.",
    },
    "Math (IMO-style)": {
        "prompt": (
            "Solve this problem completely and verify your answer:\n\n"
            "Find all positive integers n such that n² + 1 is divisible by n + 1.\n\n"
            "Your answer must include:\n"
            "1. A complete proof with clear logical steps\n"
            "2. Verification with at least 3 concrete numerical examples\n"
            "3. A rigorous argument for why your solution set is complete "
            "(i.e., there are no other solutions)"
        ),
        "expected_winner": "Think Max",
        "tip": "Think Max earns its cost when thorough verification matters.",
    },
}

ये पाँच कार्य तीन अपेक्षित विजेताओं से साफ़-साफ़ मैप होते हैं:

हर टास्क में एक expected_winner फ़ील्ड भी है। ऐप परिणाम आने के बाद इसे दिखाता है, ताकि उपयोगकर्ता जाँच सकें कि अपेक्षित विजेता सही रहा या पराजित हुआ।

चरण 4: डेटा क्लास

टास्क टेम्पलेट परिभाषित होने के साथ, अब हमें प्रत्येक API कॉल से प्राप्त परिणामों को रखने के लिए एक संरचना चाहिए। ऐप में कच्चे रेस्पॉन्स ऑब्जेक्ट्स पास करने के बजाय, हम एक एकल RunResult डाटाक्लास परिभाषित करते हैं जो तुलना पैनल की सभी ज़रूरत की मेट्रिक्स कैप्चर करता है।

@dataclass
class RunResult:
    mode: str
    answer: str = ""
    thinking: str = ""
    latency: float = 0.0
    input_tokens: int = 0
    output_tokens: int = 0
    cost_usd: float = 0.0
    error: Optional[str] = None
    @property
    def tokens_per_second(self) -> Optional[float]:
        if self.latency > 0 and self.output_tokens > 0:
            return self.output_tokens / self.latency
        return None
    @property
    def thinking_word_count(self) -> int:
        return len(self.thinking.split()) if self.thinking else 0

thinking फ़ील्ड को answer से अलग रखा गया है क्योंकि DeepSeek V4 API चेन-ऑफ-थॉट को एक समर्पित reasoning_content फ़ील्ड में लौटाती है, जो रेस्पॉन्स स्ट्रक्चर में content के समान स्तर पर है। इन्हें अलग रखने से UI एक स्वच्छ अंतिम उत्तर के साथ कॉलेप्सिबल रीजनिंग ट्रेस रेंडर कर सकता है, जो मोड का फर्क तुरंत और स्पष्ट बना देता है — विशेषकर गणित वाले कार्य में जहाँ Think Max ट्रेस हज़ारों शब्दों तक जा सकता है।

tokens_per_second प्रॉपर्टी प्रॉम्प्ट लंबाई से स्वतंत्र होकर जेनरेशन थ्रूपुट मापती है। यह तब उपयोगी है जब आउटपुट टोकन गिनती में मोड्स के बीच बड़ा फर्क हो। ध्यान दें कि Think Max स्वाभाविक रूप से अधिक टोकन उत्पन्न करता है, इसलिए केवल कच्ची विलंबता की तुलना भ्रामक हो सकती है, जब तक कि आप यह न देखें कि प्रत्येक मोड कितनी तेज़ी से जेनरेट कर रहा था।

चरण 5: लागत अनुमान हेल्पर्स

API कॉल लॉजिक लिखने से पहले, हम दो छोटे हेल्पर्स परिभाषित करते हैं जो रॉ SDK रेस्पॉन्स और RunResult के बीच बैठते हैं। इन्हें नज़रअंदाज़ करना आसान है, लेकिन लागत की शुद्धता के लिए ये महत्वपूर्ण हैं।

def get_cached_prompt_tokens(usage) -> int:
    prompt_details = getattr(usage, "prompt_tokens_details", None)
    if prompt_details is None:
        return 0
    cached_tokens = getattr(prompt_details, "cached_tokens", None)
    if cached_tokens is not None:
        return cached_tokens or 0
    if isinstance(prompt_details, dict):
        return prompt_details.get("cached_tokens", 0) or 0
    return 0
def estimate_cost_usd(
    model: str,
    prompt_tokens: int,
    completion_tokens: int,
    cached_prompt_tokens: int,
) -> float:
    pricing = PRICING.get(model, PRICING["deepseek-v4-flash"])
    cached_tokens = min(cached_prompt_tokens, prompt_tokens)
    uncached_tokens = max(prompt_tokens - cached_tokens, 0)
    return (
        cached_tokens   / 1_000_000 * pricing["input_cache_hit"]
        + uncached_tokens / 1_000_000 * pricing["input_cache_miss"]
        + completion_tokens / 1_000_000 * pricing["output"]
    )

get_cached_prompt_tokens() फ़ंक्शन डायरेक्ट फ़ील्ड एक्सेस नहीं देता क्योंकि prompt_tokens_details स्ट्रक्चर SDK वर्ज़न्स के बीच सुसंगत होने की गारंटी नहीं है। यह पहले टाइप्ड एट्रिब्यूट की जाँच करता है, फिर डिक्ट एक्सेस पर फ़ॉलबैक करता है, और अंततः अपवाद उठाने के बजाय शून्य लौटाता है। यह ThreadPoolExecutor के अंदर महत्वपूर्ण है, जहाँ किसी थ्रेड में चुपचाप हुई त्रुटि उस मोड के लिए भ्रामक रूप से कम लागत अनुमान दे सकती थी, बिना किसी दृश्य विफलता के।

estimate_cost_usd() हेल्पर फ़ंक्शन दरें लागू करने से पहले प्रॉम्प्ट टोकन गिनती को cached और uncached हिस्सों में बाँटता है। चूँकि DeepSeek ने cache-hit प्राइसिंग को miss रेट के दसवें हिस्से तक घटा दिया है, इसलिए कोल्ड और वॉर्म प्रॉम्प्ट के बीच का फर्क नाटकीय हो सकता है। किसी दोहराए गए रन-ओवर कार्य पर, Non-think लगभग मुफ़्त लग सकता है Think Max की तुलना में — इसलिए नहीं कि उसने कम टोकन जेनरेट किए, बल्कि इसलिए कि उसका छोटा प्रॉम्प्ट ज़्यादातर cache-warm होने की संभावना रखता है।

चरण 6: समानांतर API निष्पादन

यही एरीना का आर्किटेक्चरल कोर है। सभी तीन मोड ThreadPoolExecutor का उपयोग करते हुए एक साथ फ़ायर होते हैं, इसलिए कुल वॉल-क्लॉक समय तीनों का योग नहीं, बल्कि सबसे धीमे मोड के बराबर होता है।

def call_mode(client: OpenAI, model: str, mode_name: str, user_prompt: str) -> RunResult:
    result = RunResult(mode=mode_name)
    mode_cfg = MODES[mode_name]
    start = time.perf_counter()
    try:
        request_kwargs = {
            "model": model,
            "messages": [{"role": "user", "content": user_prompt}],
            "max_tokens": 4096,
            "extra_body": {"thinking": {"type": mode_cfg["thinking_type"]}},
        }
        if mode_cfg["reasoning_effort"]:
            request_kwargs["reasoning_effort"] = mode_cfg["reasoning_effort"]
        response = client.chat.completions.create(**request_kwargs)
        result.latency = time.perf_counter() - start
        message = response.choices[0].message
        result.thinking = (getattr(message, "reasoning_content", None) or "").strip()
        result.answer   = (message.content or "").strip()
        usage = response.usage
        result.input_tokens  = getattr(usage, "prompt_tokens", 0) or 0
        result.output_tokens = getattr(usage, "completion_tokens", 0) or 0
        result.cost_usd = estimate_cost_usd(
            model=model,
            prompt_tokens=result.input_tokens,
            completion_tokens=result.output_tokens,
            cached_prompt_tokens=get_cached_prompt_tokens(usage),
        )
    except Exception as exc:
        result.latency = time.perf_counter() - start
        result.error = str(exc)
    return result
def run_parallel(client: OpenAI, model: str, prompt: str) -> Dict[str, RunResult]:
    results: Dict[str, RunResult] = {}
    with concurrent.futures.ThreadPoolExecutor(max_workers=3) as pool:
        futures = {
            pool.submit(call_mode, client, model, mode_name, prompt): mode_name
            for mode_name in MODES
        }
        for fut in concurrent.futures.as_completed(futures):
            results[futures[fut]] = fut.result()
    return results

यहाँ कुछ डिज़ाइन फ़ैसले उल्लेखनीय हैं:

• request_kwargs को सशर्त बनाना: Non-think मोड thinking_type: "disabled" भेजता है और कोई reasoning_effort कुंजी नहीं। Think High और Think Max thinking_type: "enabled" और अपने-अपने effort स्तर भेजते हैं। if mode_cfg["reasoning_effort"] गार्ड सुनिश्चित करता है कि Non-think के लिए पैरामीटर पूरी तरह छोड़ा जाए, None के रूप में न भेजा जाए, जो API वेलिडेशन त्रुटि ट्रिगर कर सकता है।

• reasoning_content को सीधे पढ़ना: चेन-ऑफ-थॉट ट्रेस को message.reasoning_content से getattr() के साथ खाली स्ट्रिंग फ़ॉलबैक का उपयोग करके पढ़ा जाता है। यह <think>...</think> टैग्स को content स्ट्रिंग से पार्स करने से अधिक मज़बूत है। यह आधिकारिक रेस्पॉन्स फ़ील्ड का उपयोग करता है, उस स्थिति को संभालता है जहाँ कोई ट्रेस नहीं निकला (Non-think) और तब भी नहीं टूटता जब मॉडल के आउटपुट में अन्य कारणों से “think” शब्द आ जाए।

• usage फ़ील्ड्स पर डिफेंसिव getattr(): usage फ़ील्ड्स को getattr(..., 0) or 0 से एक्सेस किया जाता है, ताकि यदि किसी पुराने SDK वर्ज़न में फ़ील्ड गायब हो या असामान्य रेस्पॉन्स आए, तो फ़ॉलबैक अपवाद उठाने के बजाय शून्य दे।

• त्रुटि सँभालना: यदि कोई कॉल विफल हो, तो RunResult डाटाक्लास अपवाद स्ट्रिंग स्टोर करता है, उठाता नहीं। UI result.error जाँचकर सूचना-प्रद कार्ड रेंडर कर देता है, बिना पूरे तीन-मोड रन को क्रैश किए।

चरण 7: Streamlit UI और CSS

यह चरण प्रस्तुति-लेयर कवर करता है: पेज लेआउट, CSS डिज़ाइन सिस्टम, प्रति-मोड रिज़ल्ट कॉलम, और टैब संरचना जो पहले लोड पर उपयोगकर्ता को अधिभारित किए बिना तुलना को व्यवस्थित करती है।

ऐप तीन-कॉलम तुलना को पर्याप्त क्षैतिज स्पेस देने के लिए st.set_page_config में layout="wide" का उपयोग करता है:

def main():
    st.set_page_config(
        page_title="DeepSeek V4 Think Mode Arena",
        layout="wide",
        initial_sidebar_state="expanded",
    )
    inject_css()

inject_css() फ़ंक्शन st.markdown के जरिए पूरा डिज़ाइन सिस्टम इंजेक्ट करता है। यह मोनोस्पेस हेडर और मेट्रिक चिप्स के लिए Space Mono तथा बॉडी टेक्स्ट के लिए DM Sans के साथ एक गरम पार्चमेंट बैकग्राउंड उपयोग करता है।

def render_mode_column(result: RunResult, mode_name: str):
    cfg = MODES[mode_name]
    badge_cls = f"mode-{cfg['badge']}"  
    st.markdown(
        f'<div class="mode-header {badge_cls}">{mode_name}</div>',
        unsafe_allow_html=True,
    )
    st.markdown(f'<div class="subtle-copy">{cfg["desc"]}</div>', unsafe_allow_html=True)
    if result.error:
        st.error(f"**API Error:** {result.error}")
        return
    chips = [
        ("Latency", f"{result.latency:.1f}s"),
        ("Output tokens", f"{result.output_tokens:,}"),
        ("Cost", f"${result.cost_usd:.5f}"),
    ]
    if result.tokens_per_second:
        chips.append(("Tok/s", f"{result.tokens_per_second:.0f}"))
    chip_html = "".join(
        f'<span class="metric-chip">{label} <span>{val}</span></span>'
        for label, val in chips
    )
    st.markdown(chip_html, unsafe_allow_html=True)
    if result.thinking:
        with st.expander(f" Thinking trace — {result.thinking_word_count:,} words"):
            preview = result.thinking[:5000]
            if len(result.thinking) > 5000:
                preview += "\n\n[… truncated for display …]"
            st.text(preview)
    elif mode_name != "Non-think":
        st.caption("_No thinking trace emitted_")
    st.markdown('<div class="answer-label">Final answer</div>', unsafe_allow_html=True)
    st.markdown(result.answer if result.answer else "_No answer returned._")

थिंकिंग ट्रेस एक्सपैंडर विशेष रूप से उपयोगी है क्योंकि यह मोड का फर्क महसूस करा देता है — Think Max ट्रेस कठिन गणितीय समस्या पर आत्म-सुधार और सत्यापन के हज़ारों शब्दों तक जा सकता है, जबकि Non-think में कोई ट्रेस न हो।

मुख्य लेआउट Streamlit टैब्स का उपयोग करता है ताकि बिना सब कुछ एक ही स्क्रॉल में ठूँसने के, विषयों को अलग-अलग रखा जा सके:

overview_tab, answers_tab, ratings_tab = st.tabs(
    ["Overview", "Full Responses", "Ratings"]
)

“Overview” टैब विजेता सारांश और मेट्रिक्स टेबल दिखाता है। “Full Responses” टैब सोचने की ट्रेस के साथ तीन-कालम साइड-बाय-साइड तुलना दिखाता है, जबकि “Ratings” टैब प्रति मोड यूज़र क्वालिटी रेटिंग (1–5) के लिए स्लाइडर्स दिखाता है।

चरण 8: मेट्रिक्स और रेटिंग्स

यह अंतिम चरण Overview टैब में रहने वाले दो कॉम्पोनेंट्स बनाता है — एक फ्लैट मेट्रिक्स टेबल जो हर मापे गए आयाम को साथ-साथ रखता है, और एक विजेता सारांश जो चार अलग-अलग श्रेणियों में विजेता बताता है।

def render_metrics_table(results: Dict[str, RunResult], ratings: Dict[str, int]):
    rows = []
    for mode_name, res in results.items():
        ok = not res.error
        rows.append({
            "Mode":            mode_name,
            "Latency (s)":     f"{res.latency:.2f}" if ok else "—",
            "Input Tokens":    f"{res.input_tokens:,}" if ok else "—",
            "Output Tokens":   f"{res.output_tokens:,}" if ok else "—",
            "Tok/s":           f"{res.tokens_per_second:.0f}" if (ok and res.tokens_per_second) else "—",
            "Est. Cost (USD)": f"${res.cost_usd:.5f}" if ok else "—",
            "Thinking Words":  f"{res.thinking_word_count:,}" if ok else "—",
            "User Rating":     f"{ratings.get(mode_name)}/5" if ratings.get(mode_name) else "—",
        })
    st.table(rows)
def render_winner_summary(results: Dict[str, RunResult], ratings: Dict[str, int], expected: str):
    valid = {k: v for k, v in results.items() if not v.error}
    fastest        = min(valid, key=lambda k: valid[k].latency)
    cheapest       = min(valid, key=lambda k: valid[k].cost_usd)
    most_efficient = max(
        valid,
        key=lambda k: valid[k].output_tokens / max(valid[k].cost_usd, 1e-9),
    )
    top_rated = max(ratings, key=ratings.get) if ratings else None

ये दोनों फ़ंक्शन क्या करते हैं, एक त्वरित झलक:

• render_metrics_table() हर RunResult पर इटरेट करता है और प्रत्येक मोड के लिए एक रो डिक्शनरी बनाता है। आठ कॉलम पूरी तुलना कवर करते हैं — समय (विलंबता, tok/s), पैमाना (इनपुट और आउटपुट टोकन, सोचने के शब्द), पैसा (अनुमानित लागत), और मानव निर्णय (यूज़र रेटिंग)।

• render_winner_summary() पहले किसी भी विफल रन को निकाल देता है, फिर विजेताओं की गणना करता है, ताकि एक भी API त्रुटि परिणामों को विकृत न करे। यह चार स्वतंत्र आयामों में चैंपियन ढूँढता है — वॉल-क्लॉक स्पीड, कच्ची लागत, आउटपुट दक्षता, और यूज़र रेटिंग।

इन चार श्रेणियों को जानबूझकर अलग रखा गया है, किसी एकल स्कोर में नहीं जोड़ा गया, क्योंकि वेटेड कंपोज़िट बनाने का मतलब होगा कि ऐप यह तय करे कि लागत की तुलना में विलंबता अधिक मायने रखती है — जो एक प्रोडक्ट निर्णय है, फ्रेमवर्क निर्णय नहीं।

ऐप प्रत्येक कार्य के लिए अनुमानित विजेता भी दिखाता है, उपयोगकर्ता को यह पुष्टि करने के लिए प्रेरित करता है कि क्या यह मेल खाया:

st.markdown(
    f"> **Expected winner for this task type:** {expected} — "
    "does your result match? Rate answers to confirm.",
)

चरण 9: ऐप चलाना

पूरा ऐप एकल app.py फ़ाइल में है, केवल दो डिपेंडेंसीज़ के साथ, और इसे शुरू करने के लिए दो कमांड्स चाहिए:

# Set your API key
export DEEPSEEK_API_KEY="sk-..."
# Run
streamlit run app.py

ऐप आपके ब्राउज़र में localhost:8501 पर खुलता है। ड्रॉपडाउन से कोई टास्क टेम्पलेट चुनें, आवश्यकता हो तो प्रॉम्प्ट संपादित करें, और Run Arena पर क्लिक करें। एक प्रोग्रेस बार हर मोड के पूरा होने पर अपडेट होता है। परिणाम st.session_state में संग्रहीत होते हैं, ताकि आप टैब बदल सकें और उत्तरों को रेट कर सकें, बिना फिर से रन ट्रिगर किए।

प्राइसिंग पर नोट: DeepSeek ने लॉन्च के बाद से V4 API दरों में उल्लेखनीय समायोजन किए हैं। V4-Pro पर वर्तमान में प्रोमोशनल डिस्काउंट है, और अप्रैल 2026 में cache-hit कीमतें miss रेट के दसवें हिस्से तक घटा दी गईं। ऐप में दिखाए गए लागत आंकड़े मौजूदा दरों को दर्शाते हैं, पर बदल सकते हैं। किसी भी मॉडल का उपयोग करने से पहले हमेशा api-docs.deepseek.com/quick_start/pricing पर सत्यापित करें।

निष्कर्ष

इस ट्यूटोरियल में, हमने एक Streamlit एप्लिकेशन बनाया जो एक ही प्रॉम्प्ट को DeepSeek V4 के तीन रीजनिंग मोड्स पर समानांतर चलाता है और विलंबता, लागत, टोकन उपयोग, थिंकिंग ट्रेस गहराई, और उपयोगकर्ता-रेटेड गुणवत्ता के आधार पर परिणामों की तुलना करता है। प्रमुख आर्किटेक्चरल विकल्प ये रहे:

• सच्चे समानांतरता के लिए ThreadPoolExecutor, जिसका मतलब है कि कुल वॉल-क्लॉक समय तीनों का योग नहीं, बल्कि सबसे धीमे मोड के बराबर होता है

• thinking और reasoning_effort API पैरामीटर्स, ताकि मोड नियंत्रण साफ़, स्पष्ट और DeepSeek के API के अनुरूप रहे — सिस्टम प्रॉम्प्ट स्टियरिंग पर निर्भर रहने के बजाय

• कैश-अवेयर लागत अनुमान, जो इनपुट टोकन को cache-hit और cache-miss हिस्सों में बाँटता है, और खासकर दोहराए गए रन में अधिक सटीक लागत आँकड़े देता है, जहाँ वॉर्म-कैश डिस्काउंट Non-think को लगभग मुफ़्त जैसा दिखा सकते हैं

इस प्रोजेक्ट को आगे बढ़ाने के लिए, एक LLM-as-judge लेयर जोड़ने पर विचार करें (उत्तर स्वत: स्कोर करने के लिए Claude या GPT-4 जैसे अलग मॉडल का उपयोग), समान प्रॉम्प्ट हैश पर रेस्पॉन्स कैश करना ताकि एक जैसे क्वेरी पुन: न चलें, या एक क्रॉस-मॉडल अक्ष जोड़ना जो Flash Think Max को Pro Think High के विरुद्ध खड़ा करे — यह वास्तव में एक रोचक लागत-पैरिटी प्रश्न है जिसे V4 पेपर उठाता है पर पूरी तरह उत्तर नहीं देता।