DeepSeek-V4-Pro, Kimi K2.6, GLM-5.1: سه مدل بزرگ زبان (LLM) تحت آزمون Vibe Coding Long Contexte

منتشر شده در 28 April 2026

زمان خواندن : 18 minutes

جنگ LLM‌ها نیز در ترمینال یک توسعه‌دهنده رخ می‌دهد. نه بر بنچمارک‌های آکادیمی بی‌نتیجه. در زندگی واقعی: یک پرامپت ۳۰٬۰۰۰ توکن، یک عامل مدیریت در AsciiDoc، پلاگین‌های Gradle Kotlin DSL برای رفع اشکال و جلساتی که به‌طور پشت سر هم طول سه هفته ادامه می‌یابند. من برای شما DeepSeek-V4-Pro، Kimi K2.6 و GLM-5.1 را تست کردم. این نتیجه است، همراه با شواهد فنی.

تک

[]

به‌맥س: نه یک میز آزمایش، یک سایت ساخت

سه هفته پیش، من در حال کار می‌کردم بر روی`codebase-gradle`, سیستم meta-build من که پیکربندی YAML چهار پروژه را متمرکز می‌سازد: یک تولید کننده README PlantUML، یک سازنده اسلاید AsciiDoc، یک سایت استاتیک JBake و یک چت‌بات LLM. افزاینده Opencode، که تحت منهجیت فایل‌های agente من در AsciiDoc قرار دارد، در هر آغاز جلسه حدود 30K توکن زمینه EAGER را بارگذاری می‌کرد — قوانین قطعی، بیک‌لگ، تاریخچه 10 جلسه اخیر.

در این زمینه، من با سه مدل مواجه شدم :

  • Kimi K2.6(Moonshot AI, 1T params / 32B فعال, 256K حداکثر زمینه, MLA) - GLM-5.1(Zhipu AI/Tsinghua, 744B پارامتر / DSA، حداکثر 200K زمینه) - (empty)(DeepSeek, 1.6T پارامتر / 49B فعال، حداکثر 1M زمینه، CSA+HCA)

همه از طریق Ollama بر روی سرور ابری ارائه می‌شوند، همه در حالت thinking (مرحله réflexion فعال) قرار دارند. چالش: تولید کد صحیح، حفظ سازگاری در جلسات طولانی، و جلوگیری از هلوسینگ وقتیcontext بیش از 80K توکن است.

محیط تست من

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

title محیط تست — Sessions Opencode × 3 LLMs
left to right direction

package "🖥️ ترمینال توسعه‌دهنده" #E8F5E9 {
  rectangle "AGENT.adoc\n(قوانین, backlog)" as AG
  rectangle "PROMPT_REPRISE
(مأموریت)" as PR
  rectangle "INDEX.adoc
(راه‌نامه)" as IDX
}

package "☁️ Ollama ابر" #BBDEFB {
  rectangle "DeepSeek-V4-Pro
1.6T / CSA+HCA" as DV4
  rectangle "Kimi K2.6
1T / MLA" as KIMI
  rectangle "GLM-5.1
744B / 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
(947 خط)"
  file "embeds.yml"
}

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

DV4 --> "پایهٔ کد" : "TDD, بازنویسی،
تصویر لحظه‌ای"
KIMI --> "پایهٔ کد" : "تخریب
از ۶۰K توکن"

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

@enduml

هر جلسه با حدود 30K توکن از context EAGER شروع می‌شد :`AGENT.adoc`(287 خط),PROMPT_REPRISE.adoc(51 خط).agents/INDEX.adoc(218 خط),LAZY_EAGER_ESSENTIALS.adoc(50 خط). زمینه به سرعت با تبادل‌ها افزایش می‌یافت — یک جلسه معمولی 10 پیام 15‑20 هزار توکن به پرامپت تجمیعی اضافه می‌شد.

جدول ارزیابی

من هر مدل را روی چهار محور حیاتی برای توسعه نرم‌افزار یاری‌داده ارزیابی کردم :

محور

معیار ملموس

همسazi بافت طولانی

آیا نمایندگ مlrecrat 40 پیام precursors را yad دارد؟

کیفیت کد تولید شده

کد از ابتدا کامپایل می‌شود؟ الگوهای موجود را رعایت می‌کند؟

استدلال معماری

آیا عامل روابط بین ماژول‌ها را بدون اینکه من برایش دوباره توضیح دهم، می‌فهمد؟

مقاومت در برابر هلوسیناس‌های

از چند توکن onwards?

و یک متریک ترکیبی خانگی : اینضریب بازگشت(چقدر زمان را برای اصلاح عامل صرف می‌کنم به جای کدنویسی با او).

دور 1 : Kimi K2.6 — شروع نادرست

Kimi K2.6 اولین گزینه من بود. Benchmark‌های آن در SWE-Bench Verified (80.2) و Terminal-Bench 2.0 (66.7) عالی است. معماری MLA آن کارایی خوبی بر روی دنباله‌های طولانی را تضمین می‌کند.

جلسه ۹: بهبودی

اولین جلسه با Kimi. وظیفه: پیاده‌سازی روش`resolveActiveKey()در`codebase.kt— یک تابع حل کلید API با fallback CLI. متن 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 مورد تست موفق می‌شوند. خوشبین هستم.

نشست ۱۰: غرق ساکت

دومین جلسه. حداکثر توکن‌ها به حدود ۹۰K می‌رسد با تبادل‌ها. از Kimi می‌خواهم مکانیزم اسنپ‌شات AsciiDoc اضافه کند که قبل از نوشتن، اسرار را ناشناس کند.

اینجاست که چیزها به هم میریزند. Kimi شروع به invent کردن کلاس‌هایی که وجود ندارند می‌کند. او به من پیشنهاد می‌دهد.AnonymizedObjectMapper— یک کلاس خیالی. او اشتباه می‌کند`ReadmeYmlAnonymizer` et CodebaseYmlAnonymizer. او به من پیشنهاد می‌دهد که وارد کنم`com.fasterxml.jackson.anonymize.*`— یک بسته که هرگز وجود نداشته است.

بدتر: در مرحله ی فکر کردنش، می‌بینم که او استدلال‌هایی براساس فرضیات نادرست می‌سازد. او "به یاد می‌آورد" که`GitConfig`یک میدان دارد`anonymizedToken`— نه، این است`resolvedToken(). او به`SiteYmlAnonymizer`یک روش`maskSupabaseCredentials()— که وجود ندارد.

_ این یک باگ نبود. این یک پوسیدگی التدریجی انسجام بود. به‌نظر می‌رسید هر توکنی که به زمینه افزوده می‌شود، کمی بیشتر حافظه‌ی ۳۰٬۰۰۰ توکن اول را تخفیف می‌دهد. _

من Kimi را پس از دو جلسه متوقف می‌کنم. تشخیص واضح است: MLA کش KV را به خوبی فشرده می‌کند، اما بدون مکانیزم انتخاب سParse دقیق (fine-grained sparse)، توجه به‌طور خودکار پس از 60K توکن مخفف می‌شود. هر توکن "می‌بیند" کمتر و کمتر زمینه دور را می‌بیند — و شروع به پر کردن خالی‌ها با نویز می‌کند.

دور ۲: GLM-5.1 — مقاتل محترم

GLM-5.1 با یک معماری متفاوت می‌آید: MLA برای مدل پایه، سپس continued pre-training با DSA (DeepSeek Sparse Attention) — یک indexer سبک که به‌صورت پویا ۲۰۴۸ توکن مرتبط را از تمام تاریخچه انتخاب می‌کند.

معماری: DSA در برابر MLA خالص

تفاوت بنیادین است. جایی که Kimi تاریخچه را در یک فضای latent واحد فشرده می‌کند (و progressivement توانایی تمایز اطلاعات مرتبط را از دست می‌دهد)، GLM یک indexer پس از آموزش را پیوند می‌دهد که یک انتخاب صریح sparse انجام می‌دهد.

@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 Cache
کامل" as KV1
  rectangle "فشرده‌سازی
مستتر" as CL1
  rectangle "دیکدینگ
بر روی فضای laten" 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 Cache
کامل" as KV2
  rectangle "فشرده‌سازی
مخفی (MLA)" as CL2
  rectangle "اندیس‌ساز سبک\n(DSA, top-k=2048)" as IL
  rectangle "دکدینگ
روی توکن‌های انتخاب شده" as DL2
  KV2 --> CL2
  CL2 --> IL
  IL --> DL2
  note bottom of DL2
    ✅ "بی‌فقدان به‌طرز ساخت"
    Sélection explicite
    des tokens pertinents
  end note
}

MLA --> DSA : "سود: انتخاب ندر
که از تخفیف جلوگیری می‌کند"

@enduml

گزارش فنی آن را به صورت صریح می‌گوید: DSA "lossless by construction" است — برعکس جایگزین‌هایی مثل SWA (جستجوی الگو)، Gated DeltaNet یا SimpleGDN که تا 5.69 امتیاز در RULER@128K از دست می‌دهند.

جلسات 11-13 : پایدار اما ناراحت‌کننده

GLM-5.1 بهتر فاصله را حفظ می‌کند. در جلسه ۱۱ (حدود ۶۰K توکن)، همگونی دارد. یک`SnapshotManager`عملی با مدیریت صحیح از چهار ناشناس‌ساز.

اما تأخیر یک مشکل است. مراحل تفکر DSA سنگین‌تر از MLA خالص هستند — ایندکس کننده باید در هر مرحله تاریخچهٔ را دوباره اسکن کند. یک پاسخ که با Kimi 8 ثانیه می‌گرفت، با GLM 15 ثانیه می‌گیرد. در یک جلسه از 30 پیام، این احساس محسوس می‌شود.

و سپس خطاهای دقیق وجود دارند. GLM مثل Kimi عیان نمی‌شود — اما خطاهای nommage (نام‌گذاری) می‌کند. او صدا می‌زند`toAnonymizedYaml()rout…​ (Note: The leading space is preserved as in the original text.)`anonymize(). او معکوس می‌کند`loadReadmeConfiguration()` et loadCodebaseConfiguration()`در`renderFileSection(). این هلوسینی نیست، اینها سردرگمی‌های سطحی هستند — اما در تولید، یک سردرگمی سطحی می‌تواند یک build را خراب کند.

من سه جلسه با 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 Cache
1M توکن" as KV #E3F2FD

rectangle "CSA
توجه پراکنده فشرده" as CSA #C8E6C9 {
  rectangle "فشرده‌سازی
m توکن‌ها → 1" as CC
  rectangle "توجه پراکنده
(DSA, top-k)" as SA
  CC --> SA

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

rectangle "HCA
توجه به شدت فشرده" as HCA #BBDEFB {
  rectangle "فشرده‌سازی شدید
m' >> m → 1" as ECC
  rectangle "توجه چگال
باقی‌مانده" as EDA
  ECC --> EDA

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

rectangle "فوشن
هایبرد" as FUSION #FFF9C4
rectangle "دیکدینگ
منسجم" as DEC #FFE0B2

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

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

@enduml

دو سطح فشرده‌سازی، دو دانه‌پردازی‌های توجه :

  • CSA: فشرده می‌کند KV کش همه`m`توکن‌ها، سپس یک توجه پراکنده (DeepSeek Sparse Attention) اعمال می‌کند — تنها top-k از ورورهای فشرده‌شده بررسی می‌شود. دقیق، محلی، کارآمد. - HCA: فشرده‌سازی شدید (عامل`m'`بسیار بزرگتر از`m`), اما توجه چگال بر روی باقی‌مانده فشرده — اتصالات جهانی را حفظ کند بدون انفجار مربعی.

نتیجه: در 1M توکن، DeepSeek-V4-Pro فقط مصرف می‌کند27% از FLOPs استنتاج et 10٪ از اندازه کش KVدر مقایسه با DeepSeek-V3.2. مدل قبلی.

و به‌ویژه، گزارش فنی (شکل 9) اعلام می‌کند: "Retrieval performance remains highly stable within a 128K context window."

جلسات ۱-۸ : تسکین

من هشت جلسه با DeepSeek-V4-Pro را گذراندم بر روی`codebase-gradle`. هuit جلسه بدون هیچ هلوچینی، بدون هیچ کلاس مخترعی، بدون هیچ سردرگمی نامگذاری

جلسه 1 : پیاده‌سازی`CodebaseYmlConfig` et CodebaseYmlAnonymizer. 350 خط کد Kotlin، تست‌های درون خطی، همهٔ چیز کامپایل می‌شود. جلسه ۴: افزودن`SnapshotManager`با tree view, جمع‌آوری فایل‌ها، رندر AsciiDoc برای هر فایل. 279 خط، خطای صفر. جلسه 7: عیب‌یابی`renderFileSection()`که باید چهار نوع مختلف انونیمایزور را بدون ابهام مدیریت کند. در سه پیام حل شد.

تلاتانس نسبت به Kimi بالاتر است — حدود ۱۰‑۱۲ ثانیه برای هر پاسخ در حالت thinking. اما نرخ تصحیح تقریباً صفر است. من زمانم را برای رفع خطاهای عامل نمی‌گذارم. من با او کد می‌زنم.

آزمون قطعی : بازنویسی در 100K توکن

در جلسه ۸، سیاق تجمعی بیش از ۱۰۰K توکن می‌شود. من یک بازنگری سنگین درخواست می‌دهم: استخراج چهار وظیفه بررسی درون‌خط از`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()یک تابع افزونه که در …​ تعریف شده است`readme.kt, و که`SnapshotManager.PRUNED_DIRS`حذف می‌کند`build`, .gradle et .git.

این همان تفاوت است.

مقابله چهره‑به‑چهره : معیارهای مقایسه‌ای

معيار Kimi K2.6 GLM-5.1 DeepSeek-V4-Pro

حداکثر زمینه

256K

۲۰۰ هزار

1M

مکانیزم توجه

MLA خالص

MLA + DSA

CSA + HCA هیبرید

پارامترهای کل

1T

744B

1.6T

تنظیمات فعال

32B

منتشر نشده

49B

آستانه تخریب مشاهده‌شده

~60K tokens

~120K tokens

[No source text provided]

رفتار فراتر

هلوسه‌های گسترده

اشتباهات سطحی

تخریب کند و تدریجی

ثبات NIAH

منتشر نشده

100% @128K (DSA)

پایدار تا 128K (شکل 9)

MRCR @128K

منتشر نشده

منتشر نشده

بیشتر از Gemini 3.1 Pro

جلسات برگزار شده قبل از انصراف

2

3

8 (و ادامه)

زمان اصلاح / زمان کد

60%

30%

<5%

میانگین تاخیر (حالت think)

8 s

15 s

11 s

ضریب اطمینان*

2/10

6/10

9/10

*ضریب اعتماد = اندازه‌گیری ذاتی از توانایی من برای گرفتن کد عامل و commit بدون بررسی خط به خط.

@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center

title Radar مقایسه‌ای — 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+ tokens" as coh #F5F5F5
rectangle "کیفیت
کد" as qual #F5F5F5
rectangle "استدلال
معماری" as arch #F5F5F5
rectangle "مقاومت
هلوسینیشن" as hall #F5F5F5
rectangle "سرعت
(تجربه توسعه)" as speed #F5F5F5
rectangle "آشنایی
Gradle/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 به دلیل یک عامل نیست — یک همگرایی است:

معماری CSA+HCA برای کد تنظیم شده است.

توسعه نرم‌افزار کمک‌شده یک مورد استفاده extrême برای توجه طولانی‌مدت است. شما نیاز دارید به: - دقت محلی (این کلاس از چه چیزی ارث‌بری می‌کند؟ این متد کجا تعریف شده است؟) →CSA - دیدن کلی (چرا این ماژول وجود دارد؟ چگونه چهار ناشناس‌سازی‌کنندگان تعامل می‌کنند؟) →HCA

Kimi با MLA تنها دقت محلی را مدیریت می‌کند اما بینش جهانی را فراتر از 60K از دست می‌دهد. GLM با DSA بینش جهانی را بهبود می‌بخشد اما تک‌سطحی باقی می‌ماند. DeepSeek هر دو را به‌طور صریح ترکیب می‌کند.

2. محیط EAGER منطقه راحتی اوست

سیستم حاکمیت من در زمان راه‌اندازی حدود ۳۰K توکن از قوانین و back‑log را بارگذاری می‌کند. با پنجره ثابت تا ۱۲۸K توکن، دیپ سیek حدود ۱۰۰K توکن حاشیه برای تبادل‌های جلسه دارد. این ۳ تا ۴ برابر چیزی است که Kimi می‌تواند بدون تدهور مدیریت کند.

_ پنجره 128K ثبات کامل دقیقاً با نیازهای من همخوانی دارد: 30K EAGER + 70K تبادل = یک جلسه پروداکتیو از 20-30 پیام بدون اینکه هرگز از ناحیه سبز خارج شویم. _

3. نسبت کیفیت/اخیران بهینه برای جریان است

بله، DeepSeek-V4-Pro کندتر از Kimi است (11s مقابل 8s). اما زمان total یک کار به‌وضوح کمتر است، چرا که من 20 دقیقه را برای اصلاح هلوسین-agent صرف نمی‌کنم.

توسعه‌دهنده تأخیر یک پاسخ را اندازه‌گیری نمی‌کند. او زمان بین "je pose la question" و "le code est dans mon repo et il fonctionne" را اندازه‌گیری می‌کند. بر این معیار، DeepSeek-V4-Pro سریع‌ترین از بین سه مورد است.

دروس آموخته‌شده: چگونه LLM خود را برای Vibe Coding انتخاب کنیم

علاوه بر رتبه‌بندی موقت، این تجربه بهmآموزش داد که یک LLM را برای توسعه نرم‌افزار کمک‌سنجی بر مبنای معیارهایی ارزیابی کنم که در هیچ-benchmarkی وجود ندارد:

  1. **معماری را نگاه کن، نه اندازه‌ی contextِ advertised? No, correct: "معماری را نگاه کن، نه اندازه‌ی contextِ اعلام شده". I’ll output that.

</think>

معماری را نگاه کن، نه اندازه‌ی contextِ اعلام شده**— مدلی که 256K از/context را اعلام می‌کند اما فقط یک MLA دارد، مثل Kimi خواهد شد: به طور نظری قابل، اما به طور عملی فراتر از 60K قابل استفاده نیست.

  1. تست روی تو بافت، نه روی یک معیار عمومی— پرامپت اولیه من از 30K توکن AsciiDoc با قوانین مطلق و backlog هیچ ربطی به سوالات HLE یا AIME ندارد.

  2. تاخیر دشمن نیست اگر کیفیت پیروی کند— یک مدل کند که کد درست تولید می‌کند، سریع‌تر از یک مدل سریع است که کد نادرست تولید می‌کند.

  3. از مدل‌های بدون گزارش فنی عمومی مراقب باش— اگر تیم معماری توجه خود را مستند نکند، این به دلیل این است که به کارایی آن در طولانی‌مدت اطمینان ندارد.

@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

و حکمرانی Agent در این همه؟

این تجربه نقطه‌ای را تأیید می‌کند که من از مقاله‌ی خود دربارهٔ حکم‌داری Eager/Lazy دفاع کرده‌ام :کیفیت LLM و کیفیت گَوَرنانس ضربی‌اند، نه جمعی.

با Kimi K2.6، مدیریت من بی‌نقص بود — اما مدل اطلاعات را مخفف می‌کرد. نتیجه: مدیریت کامل × توهیم = صفر.

با DeepSeek-V4-Pro، حکمرانی EAGER (۳۰K توکن قوانین) + LAZY (بایگانی‌های جلسات، مراجع فنی) + Hot/Warm/Cold (پشتیبان‌گیری دورانی) یک اکوسیستم شکل می‌دهد که هر لایه دیگری را تقویت می‌کند. آجنت قوانین را پیش‌روی خود دارد (EAGER)، می‌تواند تاریخچه را بررسی کند (LAZY) و بافت هرگز اشباع نمی‌شود (پشتیبان‌گیری دورانی).

_ یک LLM خوب بدون حکمرانی، مثل موتور یک فيراری بدون چرخ است. حکمرانی خوب بدون یک LLM خوب، مثل چرخ بدون موتور است. DeepSeek-V4-Pro + عامل حکمران من = اولین بار که احساس رانندگی می‌کنم. _

مکانیزم بکاپ چرخشی (دوراندازی هر 10 جلسه یا بیش از ۵۰۰ خط EAGER) تمام معنی خود را پیدا می‌کند با مدلی که 128K از زمینه را نگه می‌دارد: پنجره لغزشی 10 جلسه فعال، زمینه را تازه نگه می‌دارد و هرگز به область تخریب نمی‌رسد.

منابع فنی

من تجربه تجربی خود را با گزارش‌های فنی رسمی ترکیب کردم تا مشاهداتم را تأیید کنم :

  1. DeepSeek-V4 Technical Report — PDF دریافت‌شده ازhttps://huggingface.co/deepseek-ai/DeepSeek-V4-Flash[HuggingFace]. شکل 9 : "عملکرد بازیابی در پنجره‌ای از contexto 128K به‌طور بسیار پایدار می‌ماند. در حالی که کاهش عملکرد بعد از علامت 128K قابل مشاهده می‌شود، توانایی‌های بازیابی مدل در 1M توکن به‌طور چشمگیر قوی می‌ماند." معماری CSA+HCA مستند شده در بخش 2.3.

  2. گزارش فنی GLM-5 —https://arxiv.org/abs/2602.15763[arXiv:2602.15763]. DSA معرفی شده از طریق آموزش پیش‌محصوره‌ی ادامه‌یافته، "lossless by construction". حداکثر context 202,752 توکن. جداول 3/5/6 عملکردهای طول‑context را نسبت به گزینش‌های جایگزین (SWA, Gated DeltaNet, SimpleGDN) مستند می‌کنند.

  3. کارت مدل Kimi K2.6 —https://huggingface.co/moonshotai/Kimi-K2.6[HuggingFace]. MLA, حداکثر ۲۵۶K متن. استراتژی discard-all فراتر از آستانه بر روی وظایف عامل (که به صورت ضمنی حد عملی MLA در زمینه‌های طولانی را تأیید می‌کند).

  4. گزارش فنی Kimi K2 —https://arxiv.org/abs/2507.20534[arXiv:2507.20534]معماری MoE، بهینه‌ساز MuonClip، عملکردهای اژنتی (HLE, BrowseComp, Terminal-Bench).

نکته‌ای که بیش از همه آشکار است: در ارزیابی خودشان، Moonshot از استراتژی discard-all (حذف زمینه قدیمی) به محض vượt شدن از پنجره زمینه استفاده می‌کند. این دقیقاً همان چیزی است که من مشاهده کرده‌ام: تنها MLA نمی‌تواند همگرایی را در تمام پنجره 256K حفظ کند. معماری پیروی نمی‌کند.

نتیجه: انتخاب حرفي

پس از سه هفته و هشتازده جلسه توسعه واقعی، حکم نهایی و بی‌اختیار است:

Kimi K2.6

GLM-5.1

DeepSeek-V4-Pro

عالی زیر 60K

قوی تا 120K

در همه جا حاکم شو

به کار نرفتنی فراتر از

التباسات سطحی

ثابت تا 128K

2 جلسه, ترک شده

3 جلسه، رها شده

۸ جلسه، مصوب

DeepSeek-V4-Pro به‌عنوان LLM پیش‌فرض من برای تمام جلسات توسعه نرم‌افزار تحت Opencode شده است. نه به دلیل اینکه جدیدترین است. نه به دلیل داشتن بهترین معیارهای دانشگاهی. اما به این دلیل که در زندگی واقعی یک توسعه‌دهنده که پلاگین‌های Gradle Kotlin DSL را با یک context agent 30K توکن می‌فرساند، تنها گزینه‌ای است که وقتی context گسترش می‌یابد، من را دغه نمی‌دهد.

CSA+HCA یک game changer معماری است. فشرده‌سازی دو سطح + sparsification جزئی از پیاده‌سازی نیست — این دقیقاً چیزی است که بین یک دستیار کد و یک همکار قابل اعتماد تفاوت ایجاد می‌کند.

_ من DeepSeek-V4-Pro را انتخاب کردم چون آن تنها بین سه مورد است که governance-agent من را از یک محدودیت دفاعی ("چطور می‌توانیم از فراموش شدن agent جلوگیری کنیم؟") به یک مزیت هجومی ("چه‌چیزی می‌توانیم الان بسازیم که agent همه چیز را به خاطر داشته باشد؟") تبدیل کند. _

*این مقاله حاصل 13 جلسه توسعه واقعی در پروژه است`codebase-gradle`, اسناد شده در`.agents/sessions/`منهجية حکمرانی وکیل من Eager/Lazy/Hot/Warm/Cold. منابع فنی نقل شده به‌طور عمومی در HuggingFace و arXiv قابل دسترسی هستند.

مقالات مرتبط

HyperFrames-Gradle : تحويل AsciiDoc إلى فيديو MP4
31 May 2026
بررسی مصرف من LLM : SQLite, OpenCode, Ollama Cloud، و چرا اشتراک حرفه‌ای من بازار جهانی را شکسته است
18 May 2026
Architecture « افزونه مستقل + ریه مصرف‌کننده »: چرا ساخت‌های Gradle من تکرار می‌شوند؟
14 May 2026
گراف دانش به عنوان موتور توصیه: چگونه من «مقالات مرتبط» زمانی را حذف کردم
12 May 2026