DeepSeek-V4-Pro, Kimi K2.6, GLM-5.1 : लॉन्ग कंटेक्स्ट वाइब कोडिंग परीक्षण में तीन LLMs

प्रकाशित: 28 April 2026

विषय-सूची
pढ़ने का समय : 18 minutes

LLMs की जंग एक डेवलपर के टर्मिनल में भी चलती है। शैक्षणिक बेकरार बेंचमार्क पर नहीं। असली जिंदगी में : 30,000 टोकन का प्रॉम्प्ट, AsciiDoc में एजेंट शासन, डिबग करने के लिए Gradle Kotlin DSL प्लगइन, और तीन सप्ताह तक चलने वाली सत्रों की श्रृंखला। मैंने आपके लिए DeepSeek-V4-Pro, Kimi K2.6 और GLM-5.1 का परीक्षण किया। यहाँ तकनीकी प्रमाणों के साथ निर्णय है।

संदर्भ : यह एक परीक्षण बेंच नहीं, एक निर्माण स्थल

तीन सप्ताह पहले, मैं काम कर रहा था`codebase-gradle`, मेरा मेटा‑बिल्ड सिस्टम जो चार प्रोजेक्ट्स की YAML कॉन्फ़िगरेशन को सेंट्रलाइज़ करता है: एक PlantUML README जनरेटर, एक AsciiDoc स्लाइड बिल्डर, एक स्टैटिक JBake साइट, और एक LLM चैटबॉट। Opencode एजेंट, जो मेरी AsciiDoc में एजेंट फ़ाइल्स पद्धति द्वारा शासित है, प्रत्येक सेशन की शुरूआत पर ~30K टोकन ईगर कॉन्टेक्स्ट लोड करता था —absolute नियम, बैकलॉग, अंतिम 10 सेशन का इतिहास।

यह वही भूमि है जहाँ मैंने तीन मॉडलों का सामना किया:

  • Kimi K2.6(Moonshot AI, 1T params / 32B सक्रिय, 256K अधिकतम संदर्भ, MLA) - GLM-5.1(Zhipu AI/Tsinghua, 744B पैरामीटर / DSA, 200K अधिकतम संदर्भ) - DeepSeek-V4-Pro(DeepSeek, 1.6T पैरामीटर / 49B सक्रिय, 1M अधिकतम संदर्भ, CSA+HCA)

ओलामा के माध्यम से क्लाउड सर्वर पर सभी सेवाएँ प्रदान की जाती हैं, सभी थिंकिंग मोड (सक्रिय प्रतिबिंब चरण) में चल रहे हैं। चुनौती: सही कोड उत्पन्न करना, लंबे सत्रों में संगतता बनाए रखना, और जब संदर्भ 80K टोकन से अधिक हो तो hallucination नहीं करना।

मेरा परीक्षण वातावरण

@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 220

title परीक्षण परिवेश — Opencode सत्र × 3 LLMs
left to right direction

package "🖥️ डेवलपर टर्मिनल" #E8F5E9 {
  rectangle "AGENT.adoc\n(नियम, बैकलॉग)" as AG
  rectangle "प्रॉम्प्ट_पुनरारंभ\n(मिशन)" as PR
  rectangle "INDEX.adoc\n(रोडमैप)" as IDX
}

package "☁️ ओलामा क्लाउड" #BBDEFB {
  rectangle "डीपसीक-वी4-प्रो\n1.6 टी / सीएसए+एचसीए" as DV4
  rectangle "किमी K2.6\n1T / MLA" as KIMI
  rectangle "GLM-5.1\n744B / MLA+DSA" as GLMG
}

package "⚙️ कोडबेस Gradle" #FFF9C4 {
  folder "buildSrc/" {
    file "codebase.kt"
    file "readme.kt"
    file "site.kt"
    file "slider.kt"
    file "snapshot.kt"
  }
  file "build.gradle.kts\n(947 पंक्तियाँ)"
  file "embeds.yml"
}

AG --> DV4 : Sessions 1-8 ✅
AG --> KIMI : Sessions 9-10 ⚠️
AG --> GLMG : Sessions 11-13 ⚠️

DV4 --> "कोडबेस" : "टीडीडी, रिफैक्टरिंग,\nस्नैपशॉट"
KIMI --> "कोडबेस" : "गिरावट\n60K टोकन से"

note bottom of GLMG
  Meilleur que Kimi
  mais latence +
  DSA moins robuste
  que CSA+HCA
end note

@enduml

प्रत्येक सत्र लगभग 30K टोकन के EAGER संदर्भ से शुरू होता था :`AGENT.adoc`(287 पंक्तियाँ),PROMPT_REPRISE.adoc(51 लाइनें).agents/INDEX.adoc(218 लाइनें)LAZY_EAGER_ESSENTIALS.adoc(50 लाइनों)। संदर्भ तेज़ी से बढ़ रहा था, आदान-प्रदान के साथ — 10 संदेशों की एक सामान्य सत्र में 15-20K टोकन संचयी प्रॉम्प्ट में जोड़ दिए जाते थे।

मूल्यांकन ग्रिड

मैंने प्रत्येक मॉडल को सॉफ़्टवेयर विकास सहायता के लिए चार महत्वपूर्ण अक्षों पर मूल्यांकन किया:

अक्ष वास्तविक मानदंड

दीर्घ संदर्भ संगति

क्या एजेंट 40 संदेश पहले तय किए गए सम्मेलनों को याद रखता है ?

उत्पादित कोड की गुणवत्ता

क्या कोड पहली बार में सफलतापूर्वक संकलित होता है? क्या यह मौजूदा पैटर्न का पालन करता है?

आर्किटेक्चरल तर्क

क्या एजेंट को मॉड्यूल के बीच संबंधों को समझने के लिए मुझे उन्हें फिर से समझाने की ज़रूरत नहीं है?

हलूसिनेशन के प्रति प्रतिरोध

कितने टोकन से एजेंट अस्तित्व में नहीं होने वाले API या क्लास आविष्कार करना शुरू कर देता है?

और एक घर का बना सिंथेटिक मेट्रिक : वहवसूली गुणांक(मैं एजेंट को सुधारने में कितना समय बिताता हूँ, उससे कोड लिखने के बजाय)

राउंड 1 : Kimi K2.6 — गलत प्रारम्भ

Kimi K2.6 मेरी पहली पसंद रहा। उसके SWE-Bench Verified (80.2) और Terminal-Bench 2.0 (66.7) बेंचमार्क उत्कृष्ट हैं। उसकी MLA आर्किटेक्चर लंबी अनुक्रमों पर अच्छी प्रभावकारिता का वादा करती है।

सत्र 9 : सुधार

Kimi के साथ पहला सत्र। कार्य : विधि को लागू करें`resolveActiveKey()में`codebase.kt— एपीआई कुंजी समाधान फ़ंक्शन, CLI फॉलबैक के साथ। contexto 30K टोकन है, Kimi तेजी से तर्क करता है, स्वच्छ कोड उत्पन्न करता है कुंजी समाप्ति प्रबंधन के साथ

fun resolveActiveKey(
    cfg: CodebaseConfiguration,
    logger: Logger,
    cliProvider: String? = null,
    cliAccount: String? = null,
    cliKey: String? = null
): NamedApiKey? {
    // Résolution provider → compte → clé avec CLI override
    // Kimi a parfaitement compris la chaîne de priorité
}

कोड कंपाइल होता है। 7 टेस्ट केस पास होते हैं। मैं आशावादी हूँ।

सत्र 10 : शांतिपूर्ण जहाज का डूबना

दूसरा सत्र। संदर्भ ~90K टोकन तक बढ़ रहा है क्योंकि विनिमय हो रहे हैं। मैं किमी से अनुरोध करता हूँ कि वह एक एस्कीडॉक़ स्नैपशॉट तंत्र जोड़ दे जो लेखन से पहले रहस्यों को अनामीकृत कर दे।

यहाँ वह जगह है जहाँ यह बिगड़ जाता है। Kimi ऐसी वर्गों का आविष्कार करना शुरू कर देता है जो वास्तव में नहीं हैं। वह मुझे प्रस्ताव करता है।AnonymizedObjectMapper— एक काल्पनिक कक्षा. वह भ्रमित करता है`ReadmeYmlAnonymizer` et CodebaseYmlAnonymizer. वह मुझे इम्पोर्ट करने का सुझाव देता है`com.fasterxml.jackson.anonymize.*`— एक ऐसा पैकेज जो कभी मौजूद नहीं था।

और भी बुरा: उसके विचार के चरण में, मुझे पता चलता है कि वह गलत आधार पर तर्क बना रहा है। वह "याद रखता है" कि`GitConfig`के पास एक खेत है`anonymizedToken`— नहीं, यह`resolvedToken(). वह …​ को attribuित करता है`SiteYmlAnonymizer`एक विधि`maskSupabaseCredentials()— जो मौजूद नहीं है।

_ यह एक बग नहीं था। यह संगति का धीरे‑धीरे विलय था। जैसे ही संदर्भ में प्रत्येक टोकन जोड़ा जाता, पहले 30,000 टोकन की स्मृति और भी कमजोर हो जाती। _

मैं दो सत्रों के बाद किमि को रोकता हूँ। निदान स्पष्ट है: एमएलए केवी कैश को अच्छी तरह से संपीड़ित करता है, लेकिन फाइन-ग्रेडेड स्पर्स चयन तंत्र के बिना, ध्यान 60K टोकन से परे यांत्रिक रूप से कमजोर हो जाता है। प्रत्येक टोकन "देखता" दूर के संदर्भ को कम और कम अच्छी तरह से — और शोर से अंतराल भरना शुरू कर देता है।

राउंड 2 : GLM-5.1 — सम्मानित योद्धा

GLM-5.1 एक अलग आर्किटेक्चर के साथ आता है: बेस मॉडल के लिए MLA, फिर एक जारी प्री‑ट्रेनिंग DSA (DeepSeek Sparse Attention) के साथ — एक हल्का इंडेक्सर जो पूरे इतिहास में संबंधित टॉप-2048 टोकन का गतिशील चयन करता है।

आर्किटेक्चर: DSA बनाम शुद्ध MLA

अंतर मूलभूत है। जहाँ Kimi इतिहास को एक अद्वितीय लेटेंट स्थान में संपीड़ित करता है (और धीरे-धीरे प्रासंगिक जानकारी को भेदने की क्षमता खो देता है), GLM एक प्रशिक्षणोत्तर इंडेक्सर जोड़ता है जो एक स्पष्ट स्पर्स चयन करता है।

@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center

title अटेंशन आर्किटेक्चर — MLA बनाम MLA+DSA
left to right direction

rectangle "**Kimi K2.6 — शुद्ध MLA**" as MLA #FFCDD2 {
  rectangle "KV कैश\nपूर्ण" as KV1
  rectangle "अव्यक्त\nसंपीड़न" as CL1
  rectangle "डिकोडिंग\nलेटेंट स्पेस पर" as DL1
  KV1 --> CL1
  CL1 --> DL1
  note bottom of DL1
    ⚠️ Au-delà de 60K tokens :
    perte de discrimination
  end note
}

rectangle "**GLM-5.1 — MLA + DSA**" as DSA #C8E6C9 {
  rectangle "KV कैश\nपूर्ण" as KV2
  rectangle "लेटेंट संपीड़न (MLA)" as CL2
  rectangle "लाइट इंडेक्सर\n(DSA, top-k=2048)" as IL
  rectangle "डिकोडिंग\nचयनित टोकनों पर" as DL2
  KV2 --> CL2
  CL2 --> IL
  IL --> DL2
  note bottom of DL2
    ✅ "निर्माण से क्षतिरहित"
    Sélection explicite
    des tokens pertinents
  end note
}

MLA --> DSA : "लाभ: विरल चयन\nजो डाइल्यूशन से बचाता है"

@enduml

तकनीकी रिपोर्ट स्पष्ट रूप से कहती है: DSA \"lossless by construction\" है — SWA (pattern search), Gated DeltaNet या SimpleGDN जैसी विकल्पों के विपरीत, जो RULER@128K पर अधिकतम 5.69 अंक खो देते हैं।

सत्र 11-13 : ठोस लेकिन निराशाजनक

GLM-5.1 दूरी को बेहतर ढंग से बनाए रखता है। सत्र 11 (~60K टोकन) में, यह सुसंगत बना रहता है। यह एक`SnapshotManager`सही प्रबंधन के साथ चार अनॉनिमाइज़र कार्यात्मक

लेकिन विलंब एक समस्या है। DSA के विचार चरण MLA के शुद्ध रूप से भारी होते हैं — इंडेक्सर को प्रत्येक चरण पर इतिहास को पुनः स्कैन करना पड़ता है। जिस जवाब को Kimi के साथ 8 सेकंड में लिया जाता था, वह GLM के साथ 15 सेकंड लेता है। 30 संदेशों की एक सत्र में, यह महसूस किया जाता है।

और फिर सूक्ष्म त्रुटियाँ हैं। GLM Kimi की तरह बड़बड़ाता नहीं है — लेकिन वह नामकरण में त्रुटियाँ करता है। वह बुलाता है`toAnonymizedYaml()वह विधि जो कहलानी चाहिए`anonymize(). वह उल्टा है`loadReadmeConfiguration()` et loadCodebaseConfiguration()`में`renderFileSection(). ये हलूसिनेशन नहीं हैं, ये सतही भ्रम हैं — लेकिन उत्पादन में, एक सतही भ्रम एकビル्ड को तोड़ सकता है।

मैंने GLM के साथ तीन सत्र आयोजित किए। यह बिना किसी संदेह के Kimi से बेहतर है। लेकिन नामकरण विवरणों पर तीन मैनुअल सुधार सत्र करने से थकावट होती है।

राउंड 3 : DeepSeek-V4-Pro — युद्ध की मशीन

DeepSeek-V4-Pro तीनों में से सबसे महत्वाकांक्षी वास्तुकला के साथ आता है: एक हाइब्रिड सिस्टम जो दो पूरक ध्यान तंत्र को जोड़ता है।

आर्किटेक्चर : CSA + HCA, दोहरा धागा

@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 180

title DeepSeek-V4-Pro — हाइब्रिड आर्किटेक्चर CSA + HCA
left to right direction

rectangle "KV कैश\n1M टोकन" as KV #E3F2FD

rectangle "CSA\nसंपीड़ित विरल अटेंशन" as CSA #C8E6C9 {
  rectangle "संपीड़न\nm टोकन → 1" as CC
  rectangle "विरल अवधान\n(DSA, top-k)" as SA
  CC --> SA

  note bottom of SA
    Attention locale fine
    + sélection sparse
  end note
}

rectangle "HCA\nअत्यधिक संपीड़ित अटेंशन" as HCA #BBDEFB {
  rectangle "अत्यधिक संपीड़न\nm' >> m → 1" as ECC
  rectangle "सघन\nअवशिष्ट ध्यान" as EDA
  ECC --> EDA

  note bottom of EDA
    Contexte global
    + connexions longue distance
  end note
}

rectangle "हाइब्रिड\nफ्यूज़न" as FUSION #FFF9C4
rectangle "सुसंगत डिकोडिंग" as DEC #FFE0B2

KV --> CSA : Précision locale
KV --> HCA : Vision globale

CSA --> FUSION
HCA --> FUSION
FUSION --> DEC

@enduml

दो स्तर की संपीड़न, ध्यान की दो विस्तृतताएँ :

  • CSA: केवी कैश को संपीड़ित करता है सभी`m`tokens, फिर यह एक sparse ध्यान (DeepSeek Sparse Attention) लागू करता है — केवल top-k संपीड़ित प्रविष्टियों पर ध्यान दिया जाता है। सटीक, स्थानीय, प्रभावी। - HCA: अत्यधिक संपीड़न (कारक`m'`बहुत बड़ा`m`), लेकिन संकुचित अवशेष पर घना ध्यान — ग्लोबल कनेक्शन रखें बिना वर्गीय विस्फोट के

परिणाम: 1M टोकन पर, DeepSeek-V4-Pro केवल उपयोग करता है27% अनुमान FLOPs et KV कैश के आकार का 10%DeepSeek-V3.2 के सापेक्ष। पिछला मॉडल।

और सबसे महत्वपूर्ण, तकनीकी रिपोर्ट (चित्र 9) बताती है : \"पुनः प्राप्ति प्रदर्शन 128K संदर्भ विंडो के भीतर अत्यधिक स्थिर बना रहता है।\"

सत्र 1-8 : राहत

मैंने DeepSeek-V4-Pro के साथ आठ सत्र बिताए पर`codebase-gradle`. आठ सत्रों में एक भी hallucination नहीं, एक भी आविष्कृत वर्ग नहीं, एक भी नामकरण की भ्रम नहीं.

सत्र 1 : कार्यान्वयन`CodebaseYmlConfig` et CodebaseYmlAnonymizer. 350 लाइनों कोटलिन, इनलाइन परीक्षण, सबकुछ संकलित. सत्र 4 : जोड़`SnapshotManager`tree view के साथ, फ़ाइल संग्रह, फ़ाइल प्रति AsciiDoc रेंडर। 279 पंक्तियाँ, कोई त्रुटि नहीं। सत्र 7: डिबग का`renderFileSection()`जिसे चार अलग‑अलग प्रकार के अनॉनिमाइज़र को प्रबंधित करना था, बिना किसी समाधान की अस्पष्टता के। इसे तीन संदेशों में हल किया गया।

लेटेंसी Kimi से अधिक है — सोच मोड में प्रति उत्तर लगभग 10-12 सेकंड। लेकिन सुधार की दर शून्य के करीब है। मैं एजेंट की त्रुटियों को ठीक करने में अपना समय बर्बाद नहीं करता। मैं उसके साथ कोड लिखता हूँ।

निर्णायक परीक्षण: 100K टोकन पर रीफ़ैक्टरिंग

सत्र 8 में, संचयित संदर्भ 100K टोकन से अधिक हो गया है। मैं एक भारी रिफ़ैक्टरिंग मांगता हूँ: इन्लाइन सत्यापन के चार कार्यों को निकालें का`build.gradle.kts`की ओर कुछ JUnit5 टेस्ट फ़ाइलें में`buildSrc/src/test/`.

एजेंट तीन चरणों की योजना प्रस्तावित करता है :

  1. मौजूदा केसों के माइग्रेशन के साथ टेस्ट क्लासेस बनाएँ

  2. JUnit5 और Kotest निर्भरताएँ में जोड़ें`buildSrc/build.gradle.kts`

  3. इंलाइन कोड को हटाएँ`build.gradle.kts`

योजना सही है। निष्पादन साफ़ है। यह एक एज केस भी पहचानता है जो मैं याद नहीं रख पाया था: Jackson परस्पर निर्भरताएँ दोहराई गईं हैं।buildscript {} et `buildSrc/build.gradle.kts`जिन्हें माइग्रेशन के दौरान एकीकृत किया जाना चाहिए।

100K टोकन संदर्भ, और एजेंट याद करता है कि`CodebaseYmlAnonymizer.TOKEN_MASK`है`"*"`, कि`GitConfig.resolvedToken()एक extension function परिभाषित है में`readme.kt, और कि`SnapshotManager.PRUNED_DIRS`अपवर्जित करता है`build`, .gradle et .git.

वही अंतर है।

फ़ेस-टू-फ़ेस : तुलनात्मक मेट्रिक्स

मापदंड Kimi K2.6 GLM-5.1 DeepSeek-V4-Pro

अधिकतम संदर्भ

256K

200K

1M

ध्यान तंत्र

MLA शुद्ध

MLA + DSA

CSA + HCA हाइब्रिड

कुल पैरामीटर

1T

744B

1.6टन

सेटिंग्स सक्रिय

32B

अप्रकाशित

49B

प्रेक्षित क्षरण सीमा

~60K tokens

~120K tokens

~128K tokens

व्यवहार से परे

भारी हलुसिनेशन

सतह का भ्रम

धीरे-धीरे प्रगतिशील क्षय

स्थिरता NIAH

अप्रकाशित

100% @128K (DSA)

स्थिर तक 128K (आंकड़ा 9)

MRCR @128K

अप्रकाशित

अप्रकाशित

Gemini 3.1 Pro से बेहतर

छोड़ने से पहले आयोजित सत्र

2

3

8 (और जारी रखें)

सुधार का समय / कोड का समय

60%

30%

<5%

औसत विलंब (mode think)

8 s

15 s

11 s

विश्वास गुणांक*

2/10

6/10

9/10

_*विश्वास का गुणांक = व्यक्तिपरक माप मेरी क्षमता के अनुसार एजेंट के कोड और कमिट को लेना, लाइन‑बाय‑लाइन समीक्षा किए बिना.

@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center

title तुलनात्मक रडार — सहायता-प्राप्त सॉफ़्टवेयर विकास में 3 एलएलएम
legend right
  |= Couleur |= Modèle |
  | <#FF5252> | Kimi K2.6 |
  | <#FFC107> | GLM-5.1 |
  | <#4CAF50> | DeepSeek-V4-Pro |
endlegend

rectangle " " as space #FFFFFF

rectangle "संगति\n80K+ टोकन" as coh #F5F5F5
rectangle "गुणवत्ता\nकोड" as qual #F5F5F5
rectangle "स्थापत्यिक\nतर्क" as arch #F5F5F5
rectangle "प्रतिरोध\nमतिभ्रम" as hall #F5F5F5
rectangle "गति\n(डेव अनुभव)" as speed #F5F5F5
rectangle "ज्ञान\nGradle/Kotlin" as kg #F5F5F5
rectangle "सुधार की\nदर" as corr #F5F5F5

coh --> qual
qual --> arch
arch --> hall
hall --> speed
speed --> kg
kg --> corr

note top of coh
  Kimi      ████░░░░░░ 4/10
  GLM       ██████░░░░ 6/10
  DeepSeek  █████████░ 9/10
end note

note top of qual
  Kimi      ███████░░░ 7/10 (sous 60K)
  GLM       ████████░░ 8/10
  DeepSeek  █████████░ 9/10
end note

note top of arch
  Kimi      █████░░░░░ 5/10
  GLM       ███████░░░ 7/10
  DeepSeek  █████████░ 9/10
end note

note top of hall
  Kimi      ██████░░░░ 6/10 → ██░░░░░░░░ 2/10 (> 60K)
  GLM       ███████░░░ 7/10
  DeepSeek  █████████░ 9/10
end note

note top of speed
  Kimi      █████████░ 9/10
  GLM       ██████░░░░ 6/10
  DeepSeek  █████░░░░░ 5/10
end note

note top of kg
  Kimi      ███████░░░ 7/10
  GLM       ███████░░░ 7/10
  DeepSeek  █████████░ 9/10
end note

note top of corr
  Kimi      ██░░░░░░░░ 2/10 (beaucoup de corrections)
  GLM       █████░░░░░ 5/10
  DeepSeek  ██████████ 10/10 (presque rien à corriger)
end note

@enduml

DeepSeek-V4-Pro सॉफ़्टवेयर विकास में क्यों जीतता है

DeepSeek-V4-Pro की श्रेष्ठता एक ही कारक के कारण नहीं है — यह एक संगम :

1. CSA+HCA वास्तुकला कोड के लिए बनाई गई है

सहायता प्राप्त सॉफ़्टवेयर विकास एक अत्यंत उपयोग का मामला है लंबे संदर्भ ध्यान के लिए। आपको चाहिए : - स्थानीय सटीकता (यह क्लास किससे विरासत में मिली है? यह विधि कहाँ परिभाषित है?) →CSA - वैश्विक दृष्टिकोण (इस मॉड्यूल का क्यों अस्तित्व है? चार अनोनिमाइज़र कैसे बातचीत करते हैं?) →HCA

केवल MLA के साथ Kimi स्थानीय सटीकता संभालता है लेकिन 60K से परे वैश्विक दृष्टि खो देता है। DSA के साथ GLM वैश्विक दृष्टि में सुधार करता है लेकिन एकल स्तर पर बना रहता है। DeepSeek दोनों को स्पष्ट रूप से जोड़ता है।

2. ईगर संदर्भ उसका आराम क्षेत्र है

मेरा शासन प्रणाली शुरू होने पर ~30K टोकन नियम और बैकलॉग लोड करती है। 128K तक की स्थिर विंडो के साथ, DeepSeek सत्र के आदान-प्रदान के लिए ~100K टोकन का मार्जिन रखती है। यह Kimi के बिना क्षय हुए संभालने की क्षमता से 3 से 4 गुना अधिक है।

3. गुणवत्ता/लेटेंसी अनुपात प्रवाह के लिए इष्टतम है।

हाँ, DeepSeek-V4-Pro Kimi से धीमा है (11s बनाम 8s)। लेकिन एक कार्य का कुल समय बहुत कम है क्योंकि मैं एजेंट के हलूसिनेशन को ठीक करने में 20 मिनट नहीं बिताता।

डेवलपर एक प्रतिक्रिया की लेटेंसी नहीं मापता। वह "मैं सवाल पूछता हूँ" और "कोड मेरे रिपो में है और यह काम करता है" के बीच का समय मापता है। इस मेट्रिक पर, DeepSeek-V4-Pro तीनों में सबसे तेज़ है।

सीखे गए सबक : Vibe Coding के लिए अपना LLM कैसे चुनें

क्षणिक रैंकिंग से परे, इस अनुभव ने मुझे सिखाया कि किसी LLM का मूल्यांकन एसिस्टेड सॉफ्टवेयर डेवलपमेंट के लिए उन मानदंडों के आधार पर कैसे करना है जो किसी भी बेंचमार्क में नहीं हैं:

  1. आर्किटेक्चर देखें, घोषित संदर्भ आकार नहीं— एक मॉडल जो 256K संदर्भ की घोषणा करता है लेकिन केवल एक MLA है kimi की तरह समाप्त हो जाएगा: सैद्धांतिक रूप से सक्षम, 60K से आगे व्यावहारिक रूप से अनुपयोग्य।

  2. अपने संदर्भ में परीक्षण करें, सामान्य बेंचमार्क पर नहींमेरा प्रारंभिक प्रॉम्प्ट 30K टोकन AsciiDoc, सख्त नियम और बैकलॉग के साथ, HLE या AIME के प्रश्नों से कोई संबंध नहीं रखता।

  3. लेटेंसी दुश्मन नहीं है यदि गुणवत्ता बनी रहे— एक धीमा मॉडल जो सही कोड उत्पन्न करता है, एक तेज़ मॉडल से अधिक तेज़ होता है जो ग़लत कोड उत्पन्न करता है.

  4. सार्वजनिक टेक्निकल रिपोर्ट के बिना मॉडलों से सावधान रहें— यदि टीम अपनी ध्यान आर्किटेक्चर का दस्तावेज़ीकरण नहीं करती है, तो इसका अर्थ है कि उसे इसके लंबे संदर्भ में प्रदर्शन पर भरोसा नहीं है।

@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 260

title निर्णय का पेड़ — Dev-Assisted के लिए अपना LLM चुनें
start

:Contexte initial\n> 20K tokens ?;

if (Oui) then
  :Architecture d'attention\nhybride ou multi-niveau ?;

  if (CSA+HCA) then
    :DeepSeek-V4-Pro
    Fenetre stable 128K
    Ideal pour gouvernance EAGER;
    stop
  elseif (MLA + DSA) then
    :GLM-5.1
    Correct jusqu'a ~120K
    Latence elevee;
    stop
  else (MLA seul)
    :Kimi K2.6 (sessions courtes)
    ou eviter pour long contexte
    Chercher un modele avec
    sparse attention;
    stop
  endif
else (Contexte < 20K)
  :N'importe lequel fonctionne.
  Privilegier la latence.;
  stop
endif

@enduml
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 260

title निर्णय वृक्ष — डेव असिस्टेड के लिए अपना LLM चुनें
start

:Contexte initial\n> 20K tokens ?;

if (Oui) then
  :Architecture d'attention\nhybride ou multi-niveau ?;

  if (CSA+HCA) then
    :DeepSeek-V4-Pro
    Fenetre stable 128K
    Ideal pour gouvernance EAGER;
    stop
  elseif (MLA + DSA) then
    :GLM-5.1
    Correct jusqu'a ~120K
    Latence elevee;
    stop
  else (MLA seul)
    :Kimi K2.6 (sessions courtes)
    ou eviter pour long contexte
    Chercher un modele avec
    sparse attention;
    stop
  endif
else (Contexte < 20K)
  :N'importe lequel fonctionne.
  Privilegier la latence.;
  stop
endif

@enduml

यह अनुभव एक बिंदु की पुष्टि करता है जो मैं अपने एगर/लैज़ी शासन लेख से बचाव कर रहा हूँ:LLM की गुणवत्ता और शासन की गुणवत्ता गुणात्मक हैं, जोड़ात्मक नहीं.

Kimi K2.6 के साथ, मेरा शासन निर्दोष था — लेकिन मॉडल ने जानकारी को कमजोर कर दिया। परिणाम: परिपूर्ण शासन × भ्रम = शून्य।

DeepSeek-V4-Pro के साथ, EAGER (30K टोकन नियम) + LAZY (सत्र अभिलेख, तकनीकी संदर्भ) + Hot/Warm/Cold (घूर्णी बैकअप) शासन एक ऐसा पारिस्थितिकी तंत्र बनाता है जहाँ प्रत्येक परत दूसरे को बढ़ाती है। एजेंट के पास नियम हमेशा सामने होते हैं (EAGER), वह इतिहास देख सकता है (LAZY), और संदर्भ कभी बैकअप घूर्णन के कारण भर नहीं जाता।

_ एक अच्छा LLM शासन के बिना, यह एक फेरारी इंजन जैसा होता है, स्टीयरिंग व्हील के बिना। एक अच्छा शासन बिना अच्छे LLM के, यह एक स्टीयरिंग व्हील इंजन के बिना जैसा है। DeepSeek-V4-Pro + मेरा गवर्नेंस एजेंट = पहली बार जब मुझे लगा कि मैं चला रहा हूँ। _

घूर्णी बैकअप तंत्र (हर 10 सत्रों के बाद या 500 से अधिक EAGER पंक्तियों पर घूर्णी) 128K संदर्भ धारण करने वाले मॉडल के साथ पूरा अर्थ रखता है: सक्रिय 10 सत्रों की स्लाइडिंग विंडो ताज़ा संदर्भ बनाए रखती है और कभी भी क्षय क्षेत्र को पार नहीं करती।

तकनीकी स्रोत

मैंने अपने प्रायोगिक अनुभव को आधिकारिक तकनीकी रिपोर्टों के साथ मिलाकर अपने अवलोकनों को मान्य किया :

  1. DeepSeek-V4 Technical Report — PDF को से प्राप्त किया गयाhttps://huggingface.co/deepseek-ai/DeepSeek-V4-Flash[HuggingFace]. चित्र 9 : "सूचना पुनर्प्राप्ति का प्रदर्शन 128K संदर्भ विंडो के भीतर अत्यधिक स्थिर बना रहता है। 128K बिंदु से परे प्रदर्शन में कमी स्पष्ट हो जाती है, परंतु 1M टोकन पर मॉडल की पुनर्प्राप्ति क्षमताएँ उल्लेखनीय रूप से मजबूत बनी रहती हैं।" CSA+HCA आर्किटेक्चर, अनुभाग 2.3 में दस्तावेज़ीकृत।

  2. GLM-5 टेक्निकल रिपोर्ट —https://arxiv.org/abs/2602.15763[arXiv:2602.15763]. DSA जारी प्री-ट्रेनिंग के माध्यम से पेश किया गया, "lossless by construction"। अधिकतम संदर्भ 202,752 टोकन। तालिकाएँ 3/5/6 दीर्घ‑संदर्भ प्रदर्शन बनाम विकल्प (SWA, Gated DeltaNet, SimpleGDN) को दर्शाती हैं।

  3. Kimi K2.6 मॉडल कार्ड —https://huggingface.co/moonshotai/Kimi-K2.6[HuggingFace]. MLA, 256K अधिकतम संदर्भ. discard-all की रणनीति सीमा से परे एजेंटिक कार्यों पर (जिससे MLA की व्यावहारिक सीमा लंबे संदर्भ में अप्रत्यक्ष रूप से पुष्ट की जाती है).

  4. Kimi K2 Technical Report —https://arxiv.org/abs/2507.20534[arXiv:2507.20534]. वास्तु MoE, MuonClip ऑप्टिमाइज़र, एजेंटिक प्रदर्शन (HLE, BrowseComp, Terminal-Bench).

सबसे अधिक खुलासा करने वाला बिंदु: उनके अपने मूल्यांकन में, Moonshot एक discard-all रणनीति (पुराने संदर्भ को हटाना) लागू करता है, जैसे ही संदर्भ खिड़की पार हो जाती है। यह ठीक वही है जो मैंने देखा है: MLA अकेला 256K की पूरी खिड़की में संगतता बनाए रख नहीं सकता। आर्किटेक्चर इसके साथ नहीं चल पाता।

निष्कर्ष: कारीगर की पसंद

तीन सप्ताह और तेरह वास्तविक विकास सत्रों के बाद, फैसला स्पष्ट है:

Kimi K2.6 GLM-5.1 DeepSeek-V4-Pro

60K से कम उत्कृष्ट

120K तक ठोस

हर जगह हावी है

बेकार से परे

सतह पर भ्रम

128K तक स्थिर

2 सत्र, त्याग दिया गया

3 सत्र, परित्यक्त

8 सत्र, अपनाया

DeepSeek-V4-Pro मेरे सभी Opencode के साथ AI-सहायता प्राप्त सॉफ़्टवेयर विकास सत्रों के लिए डिफ़ॉल्ट LLM बन गया है। क्योंकि यह सबसे नया नहीं है। क्योंकि इसमें सर्वश्रेष्ठ शैक्षणिक बेंचमार्क नहीं हैं। लेकिन क्योंकि एक डेवलपर की वास्तविक जिंदगी में जो Gradle Kotlin DSL प्लगइन को 30K टोकन एजेंट संदर्भ के साथ धकेलता है, यह केवल एक ही है जो संदर्भ बढ़ने पर मुझे धोखा नहीं देता।

CSA+HCA एक game changer वास्तुशिल्पी है। द्वि-स्तरीय संपीड़न + स्पार्सिफिकेशन एक कार्यान्वयन विवरण नहीं है — यह वह है जो कोड सहायक और विश्वसनीय टीममेट के बीच अंतर बनाता है।

_ मैंने DeepSeek-V4-Pro चुना क्योंकि यह तीन में से एकमात्र है जो मेरी एजेंट शासन को एक रक्षात्मक बंधन ("एजेंट को भूलने से कैसे रोका जाए?") से एक आक्रामक लाभ ("अब जब एजेंट सब कुछ याद रखता है, तो हम क्या बना सकते हैं?") में बदल देता है। _

यह लेख प्रोजेक्ट पर 13 वास्तविक विकास सत्रों का परिणाम है`codebase-gradle`, दस्तावेज़ की गईं में`.agents/sessions/`मेरी governance agent पद्धति के अनुसार Eager/Lazy/Hot/Warm/Cold. उद्धृत तकनीकी स्रोतों सार्वजनिक रूप से उपलब्ध हैं HuggingFace और arXiv पर。

संबंधित लेख

HyperFrames-Gradle : AsciiDoc को MP4 वीडियो में बदलें
31 May 2026
मेरी LLM उपभोग का ऑडिट: SQLite, OpenCode, Ollama Cloud, और क्यों मेरा प्रो सब्सक्रिप्शन वैश्विक बाजार को बर्बाद कर रहा है
18 May 2026
स्वतंत्र प्लग‑इन + उपभोक्ता मूल आर्किटेक्चर: मेरे Gradle बिल्ड्स क्यों दोहराते हैं
14 May 2026
सिफ़ारिश इंजन के रूप में Knowledge Graph: मैंने क्रमानुक्रमिक « सम्बन्धित लेख » को कैसे समाप्त कर दिया
12 May 2026