DeepSeek-V4-Pro, Kimi K2.6, GLM-5.1: Tiga LLM yang diuji dalam Vibe Coding Konteks Panjang

Table des matières

Konteks: bukan sebuah tempat uji, sebuah proyek konstruksi
lingkungan uji saya
Kriteria Penilaian
Putaran 1 : Kimi K2.6 — Awalan Palsu
- Sesi 9 : perbaikan
- Session 10 : kelamunan sunyi
Round 2 : GLM-5.1 — Pejuang yang terhormat
- Arsitektur : DSA terhadap MLA murni
- Sesi 11-13: teguh tetapi menggecewakan
Round 3 : DeepSeek-V4-Pro — Mesin Perang
Muka ke Muka: Perbandingan Metrik
Mengapa DeepSeek-V4-Pro Menang dalam Pengembangan Perangkat Lunak
Pelajaran yang Dipelajari : Cara Memilih LLM Anda untuk Vibe Coding
Dan bagaimana dengan Governance Agent dalam semua ini?
Sumber Teknis
Conclusion: Pilihan Artisan

waktu membaca : 18 minutes

Perang LLM juga dimainkan di terminal seorang pengembang. Bukan di benchmarks akademis yang steril. Dalam kehidupan nyata: sebuah prompt 30 ribu token, tata kelola agen dalam AsciiDoc, plugin Gradle Kotlin DSL yang perlu didebug, dan sesi-sesi yang berlangsung selama tiga minggu. Saya telah menguji untuk Anda DeepSeek-V4-Pro, Kimi K2.6 dan GLM-5.1. Ini adalah verdict, dengan bukti teknis sebagai pendukung.

gangguan obsesif kompulsif: []

Konteks: bukan sebuah tempat uji, sebuah proyek konstruksi

Tiga minggu yang lalu, saya sedang bekerja pada`codebase-gradle`, meta-build system saya yang memusatkan konfigurasi YAML dari empat proyek: pembuat README PlantUML, pembuat slide AsciiDoc, situs statis JBake, dan chatbot LLM. Agen Opencode, yang dikendalikan oleh metodologi file agen saya dalam AsciiDoc, memuat sekitar 30K token konteks EAGER di awal setiap sesi — aturan mutlak, backlog, riwayat 10 sesi terakhir.

Di lapangan ini saya berhadapan dengan tiga model:

Kimi K2.6(Moonshot AI, 1T parameter / 32B diaktifkan, 256K konteks maks, MLA) - GLM-5.1(Zhipu AI/Tsinghua, 744B params / DSA, 200K konteks maks) - DeepSeek-V4-Pro(DeepSeek, 1.6T parameter / 49B diaktifkan, 1M konteks maksimal, CSA+HCA)

Semua dilayani melalui Ollama di server cloud, semua dalam mode thinking (fase refleksi diaktifkan). Tantangan: menghasilkan kode yang benar, menjaga konsistensi dalam sesi panjang, dan tidak halusinasi ketika konteks melebihi 80K token.

lingkungan uji saya

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

title Lingkungan Uji — Sesi Opencode × 3 LLM
left to right direction

package "🖥️ Terminal Pengembang" #E8F5E9 {
  rectangle "AGENT.adoc
(aturan, backlog)" as AG
  rectangle "PROMPT_REPRISE\n(misi)" as PR
  rectangle "INDEX.adoc
(peta jalan)" as IDX
}

package "☁️ Ollama Cloud" #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 "⚙️ basis kode Gradle" #FFF9C4 {
  folder "buildSrc/" {
    file "codebase.kt"
    file "readme.kt"
    file "site.kt"
    file "slider.kt"
    file "snapshot.kt"
  }
  file "build.gradle.kts
(947 baris)"
  file "embeds.yml"
}

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

DV4 --> "basis kode" : "TDD, pengrefaktoran,\ncuplikan"
KIMI --> "basis kode" : "Degradasi
mulai dari 60K token"

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

@enduml

Setiap sesi dimulai dengan sekitar 30K token konteks EAGER :`AGENT.adoc`(287 baris),PROMPT_REPRISE.adoc(51 baris),.agents/INDEX.adoc(218 baris)LAZY_EAGER_ESSENTIALS.adoc(50 baris). Konteks bertambah cepat dengan pertukaran — sesi tipikal dari 10 pesan menambahkan 15-20K token ke prompt kumulatif.

Kriteria Penilaian

Saya mengevaluasi setiap model pada empat sumbu kritis untuk pengembangan perangkat lunak yang didukung :

axis

Kriteria konkret

Kohersi konteks panjang

Apakah agen mengingat konvensi yang telah diputuskan 40 pesan yang lalu?

Kualitas kode yang dihasilkan

Apakah kode berhasil dikompilasi pada upaya pertama? Apakah ia mematuhi pola yang ada?

Penalaran arsitektur

Apakah agen memahami hubungan antar-modul tanpa saya perlu menjelaskannya lagi?

Resistensi terhadap halusinasi

Dari berapa banyak token agen mulai menciptakan API atau kelas yang tidak ada?

Dan sebuah metrik sintetik buatan sendiri : yangkoefisien pemulihan(berapa banyak waktu yang saya habiskan untuk memperbaiki agen alih-alih mengoding dengannya).

Putaran 1 : Kimi K2.6 — Awalan Palsu

Kimi K2.6 telah menjadi pilihan pertama saya. Benchmark-nya pada SWE-Bench Verified (80.2) dan Terminal-Bench 2.0 (66.7) sangat baik. Arsitektur MLA-nya menjanjikan efisiensi yang baik pada urutan panjang.

Sesi 9 : perbaikan

Sesi pertama dengan Kimi. Tugas: menerapkan metode`resolveActiveKey()di dalam`codebase.kt— sebuah fungsi resolusi kunci API dengan fallback CLI. Konteksnya adalah 30K token, Kimi berpikir cepat, menghasilkan kode bersih dengan manajemen kadaluwarsa kunci.

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é
}

Kode tersebut berhasil dikompilasi. Tujuh kasus uji lulus. Saya optimis.

Session 10 : kelamunan sunyi

Sesi kedua. Konteks meningkat hingga ~90K token dengan pertukaran. Saya meminta Kimi untuk menambahkan mekanisme snapshot AsciiDoc yang menganonimkan rahasia sebelum ditulis.

Inilah tempatnya mulai melenceng. Kimi mulai menciptakan kelas yang tidak ada. Dia menawarkan padaku.AnonymizedObjectMapper— kelas fiktif. Dia membingungkan`ReadmeYmlAnonymizer` et CodebaseYmlAnonymizer. Dia menyarankan saya mengimpor`com.fasterxml.jackson.anonymize.*`— sebuah paket yang tidak pernah ada.

Lebih buruk: dalam fase refleksinya, saya melihat bahwa ia membangun argumen berdasarkan premis yang salah. Dia "ingat" bahwa`GitConfig`memiliki sebuah ladang`anonymizedToken`— tidak, ini`resolvedToken(). Dia mengatribusikan pada`SiteYmlAnonymizer`sebuah metode`maskSupabaseCredentials()— yang tidak ada.

_ Bukan itu sebuah bug. Itu adalah pelarutan progresif koherensi. Seolah-olah setiap token yang ditambahkan ke konteks mengencerkan sedikit lebih memori dari 30.000 token pertama. _

Saya menghentikan Kimi setelah dua sesi. Diagnosisnya jelas: MLA mengompres KV cache dengan baik, tetapi tanpa mekanisme seleksi sparse fine-grained, perhatiannya secara mekanis menjadi encer di atas 60K token. Setiap token "melihat" konteks jauh semakin buruk — dan mulai mengisi lubang dengan noise.

Round 2 : GLM-5.1 — Pejuang yang terhormat

GLM-5.1 hadir dengan arsitektur yang berbeda: MLA untuk model dasar, kemudian continued pre-training dengan DSA (DeepSeek Sparse Attention) — sebuah indexer ringan yang secara dinamis memilih token-token teratas 2048 yang relevan dari seluruh riwayat.

Arsitektur : DSA terhadap MLA murni

Perbedaan tersebut bersifat fundamental. Di tempat Kimi mengompresi riwayat dalam ruang laten unik (dan secara bertahap kehilangan kemampuan untuk mendiskriminasikan informasi yang relevan), GLM menambahkan indexer pasca-pelatihan yang melakukan pemilihan sparse secara eksplisit.

@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center

title Arsitektur Perhatian — MLA vs MLA+DSA
left to right direction

rectangle "**Kimi K2.6 — MLA murni**" as MLA #FFCDD2 {
  rectangle "KV Cache
lengkap" as KV1
  rectangle "kompresi\nlaten" as CL1
  rectangle "Dekoding\ndi ruang 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
lengkap" as KV2
  rectangle "Kompresi\nlaten (MLA)" as CL2
  rectangle "Pengindeks ringan
(DSA, top-k=2048)" as IL
  rectangle "Dekode
pada token yang dipilih" as DL2
  KV2 --> CL2
  CL2 --> IL
  IL --> DL2
  note bottom of DL2
    ✅ "Tanpa kehilangan secara inherent"
    Sélection explicite
    des tokens pertinents
  end note
}

MLA --> DSA : "Gain: seleksi sparse\nmengurangi penyampingan"

@enduml

Laporan teknis ini secara eksplisit menyatakan: DSA adalah "lossless by construction" — berbeda dengan alternatif seperti SWA (pattern search), Gated DeltaNet atau SimpleGDN yang kehilangan hingga 5.69 poin pada RULER@128K.

Sesi 11-13: teguh tetapi menggecewakan

GLM-5.1 lebih baik menjaga jarak. Pada sesi 11 (~60K token), ia tetap koheren. Ia menghasilkan sebuah`SnapshotManager`berfungsi dengan manajemen yang tepat untuk empat anonimizer

Namun latensi adalah masalah. Tahap refleksi DSA lebih berat daripada MLA murni — indexer harus memindai ulang sejarah setiap langkah. Sebuah respons yang membutuhkan 8 detik dengan Kimi membutuhkan 15 detik dengan GLM. Pada sesi 30 pesan, hal ini terasa.

Dan kemudian ada kesalahan halus. GLM tidak mengelirukan seperti Kimi — tapi ia membuat kesalahan penamaan. Ia memanggil`toAnonymizedYaml()metode yang seharusnya disebut`anonymize(). Dia membalikkan`loadReadmeConfiguration()` et loadCodebaseConfiguration()`di`renderFileSection(). Bukan halusinasi, ini adalah kebingungan permukaan — tetapi di produksi, kebingungan permukaan dapat memecah build.

Saya telah mengadakan tiga sesi dengan GLM. Lebih baik daripada Kimi, tanpa ragu. Tapi tiga sesi perbaikan manual pada detail penamaan, itu menguras.

Round 3 : DeepSeek-V4-Pro — Mesin Perang

DeepSeek-V4-Pro hadir dengan arsitektur paling ambisius dari tiga: sebuah sistem hibrid yang menggabungkan dua mekanisme perhatian komplementer.

Arsitektur: CSA + HCA, jaring ganda

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

title DeepSeek-V4-Pro — Arsitektur Hibrid CSA + HCA
left to right direction

rectangle "KV Cache
1M token" as KV #E3F2FD

rectangle "CSA\nPerhatian Sparse yang Dikompresi" as CSA #C8E6C9 {
  rectangle "Kompresi
m token → 1" as CC
  rectangle "Perhatian Sparse\n(DSA, top-k)" as SA
  CC --> SA

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

rectangle "HCA
Perhatian yang terkompresi berat" as HCA #BBDEFB {
  rectangle "Kompresi ekstrem\nm' >> m → 1" as ECC
  rectangle "Perhatian padat
sisa" as EDA
  ECC --> EDA

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

rectangle "Fusi
hibrid" as FUSION #FFF9C4
rectangle "Dekoding\nkohéren" as DEC #FFE0B2

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

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

@enduml

Dua tingkat kompresi, dua tingkat ketelitian perhatian:

CSAmengompres cache KV setiap`m`tokens, lalu menerapkan perhatian spars (DeepSeek Sparse Attention) — hanya top-k entri yang dikompresi yang diakses. Akurat, lokal, efisien. - HCAkompresi ekstrem (faktor`m'` bien plus grand que m), perhatian yang padat pada sisa yang dikompresi — pertahankan koneksi global tanpa ledakan kuadratik.

Hasil: pada 1M token, DeepSeek-V4-Pro hanya mengonsumsi27% dari FLOPs inferensi et 10% dari ukuran cache KVdibandingkan dengan DeepSeek-V3.2. Model sebelumnya.

Dan terutama, laporan teknis (Gambar 9) mengumumkan : "Retrieval performance remains highly stable within a 128K context window."

Sesi 1-8: kelegaan

Saya telah menghabiskan delapan sesi dengan DeepSeek-V4-Pro pada`codebase-gradle`. Delapan sesi tanpa satu pun halusinasi, tanpa satu pun kelas yang diciptakan, tanpa satu pun kebingungan penamaan.

Sesi 1: implementasi`CodebaseYmlConfig` et CodebaseYmlAnonymizer. 350 baris Kotlin, tes inline, semua berhasil dikompil. Sesi 4 : penambahan`SnapshotManager`dengan tree view, pengumpulan file, rendering AsciiDoc per file. 279 baris, tidak ada error. Sesi 7 : debug dari`renderFileSection()`yang harus mengelola empat jenis anonymizer berbeda tanpa keambiguan resolusi. Diselesaikan dalam tiga pesan.

Latensi lebih tinggi daripada Kimi — sekitar 10-12 detik per respons dalam mode thinking. Namun tingkat koreksi hampir nol. Saya tidak menghabiskan waktu saya untuk memperbaiki kesalahan agen. Saya coding dengan dia.

Ujian yang menentukan: refactoring hingga 100K token

Pada sesi 8, konteks kumulatif melebihi 100K token. Saya meminta refactoring berat: mengekstrak empat tugas verifikasi inline dari`build.gradle.kts`ke file tes JUnit5 di`buildSrc/src/test/`.

Agen menawarkan rencana dalam tiga tahap:

Membuat kelas pengujian dengan migrasi kasus yang ada
Menambahkan dependensi JUnit5 dan Kotest dalam`buildSrc/build.gradle.kts`
Hapus kode inline dari`build.gradle.kts`

Rencananya benar. Pelaksanaannya rapi. Ia bahkan mengidentifikasi sebuah kasus tepi yang saya lewatkan: dependensi Jackson yang terduplikasi antara`buildscript {}` et `buildSrc/build.gradle.kts`yang harus disatukan selama migrasi.

100K token konteks, dan agen ingat bahwa`CodebaseYmlAnonymizer.TOKEN_MASK`adalah`"*"`, bahwa`GitConfig.resolvedToken()adalah sebuah fungsi ekstensi yang didefinisikan dalam`readme.kt, dan bahwa`SnapshotManager.PRUNED_DIRS`mengecualikan`build`, .gradle et .git.

Itu saja, perbedaan.

Muka ke Muka: Perbandingan Metrik

Kriteria	Kimi K2.6	GLM-5.1	DeepSeek-V4-Pro
konteks maks	256K	200K	1M
Mekanisme perhatian	MLA murni	MLA + DSA	CSA + HCA hibrid
Parameter total	1T	744B	1.6T
Pengaturan diaktifkan	32B	tidak dipublikasikan	49B
ambang degradasi yang diamati	</think> (output nothing)	~120K tokens	~128K tokens
Perilaku di luar	Hallusinasi massal	Kesalahan permukaan	degradasi progresif lambat
Stabilitas NIAH	belum dipublikasikan	100% @128K (DSA)	stabil hingga 128K (Gambar 9)
MRCR @128K	tidak dipublikasikan	belum dipublikasikan	lebih baik daripada Gemini 3.1 Pro
sesi-sesi yang diadakan sebelum pengabaian	2	3	8 (dan melanjutkan)
Waktu koreksi / waktu kode	60%	30%	<5%
Latensi rata-rata (mode berpikir)	8 s	15 s	11 s
Koefisien kepercayaan*	2/10	6/10	9/10

Kriteria

Kimi K2.6

GLM-5.1

DeepSeek-V4-Pro

konteks maks

256K

200K

Mekanisme perhatian

MLA murni

MLA + DSA

CSA + HCA hibrid

Parameter total

744B

1.6T

Pengaturan diaktifkan

32B

tidak dipublikasikan

49B

ambang degradasi yang diamati

</think> (output nothing)

~120K tokens

~128K tokens

Perilaku di luar

Hallusinasi massal

Kesalahan permukaan

degradasi progresif lambat

Stabilitas NIAH

belum dipublikasikan

100% @128K (DSA)

stabil hingga 128K (Gambar 9)

MRCR @128K

tidak dipublikasikan

belum dipublikasikan

lebih baik daripada Gemini 3.1 Pro

sesi-sesi yang diadakan sebelum pengabaian

8 (dan melanjutkan)

Waktu koreksi / waktu kode

60%

30%

<5%

Latensi rata-rata (mode berpikir)

8 s

15 s

11 s

Koefisien kepercayaan*

2/10

6/10

9/10

*Koefisien kepercayaan = ukuran subjektif dari kemampuan saya untuk mengambil kode agen dan commit tanpa membaca baris demi baris.

@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center

title Radar Perbandingan — 3 LLMs dalam Pengembangan Perangkat Lunak yang Dibantu
legend right
  |= Couleur |= Modèle |
  | <#FF5252> | Kimi K2.6 |
  | <#FFC107> | GLM-5.1 |
  | <#4CAF50> | DeepSeek-V4-Pro |
endlegend

rectangle " " as space #FFFFFF

rectangle "Konsistensi
80K+ token" as coh #F5F5F5
rectangle "Kualitas\nkode" as qual #F5F5F5
rectangle "Penalaran
arsitek" as arch #F5F5F5
rectangle "Resistensi
halusinasi" as hall #F5F5F5
rectangle "Kecepatan\n(pengalaman pengembangan)" as speed #F5F5F5
rectangle "Pengetahuan
Gradle/Kotlin" as kg #F5F5F5
rectangle "Tingkat koreksi" 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

Mengapa DeepSeek-V4-Pro Menang dalam Pengembangan Perangkat Lunak

Kelebihan DeepSeek-V4-Pro bukan karena hanya satu faktor — ini adalah konvergensi :

Arsitektur CSA+HCA dirancang untuk kode

pengembangan perangkat lunak yang dibantu adalah kasus penggunaan ekstrem untuk perhatian konteks panjang. Anda perlu : - Presisi lokal (kelas ini mewarisi apa? metode ini didefinisikan di mana?) →CSA - Visi global (mengapa modul ini ada ? bagaimana empat anonymiser berinteraksi ?) →HCA

Kimi hanya dengan MLA mengelola akurasi lokal tetapi kehilangan visi global di atas 60K. GLM dengan DSA meningkatkan visi global tetapi tetap mono-level. DeepSeek menggabungkan keduanya secara eksplisit.

2. Konteks EAGER adalah zona kenyamanan

Sistem tata kelola saya memuat sekitar 30K token aturan dan backlog saat startup. Dengan jendela stabil hingga 128K, DeepSeek memiliki sekitar 100K token ruang tambahan untuk pertukaran sesi. Ini adalah 3 hingga 4 kali lebih banyak daripada yang dapat Kimi tangani tanpa degradasi.

_ Jendela 128K stabilitas sempurna cocok tepat dengan kebutuhan saya: 30K EAGER + 70K pertukaran = sesi produktif 20-30 pesan tanpa pernah keluar dari zona hijau. _

3. Rasio kualitas/latensi optimal untuk alur

Ya, DeepSeek-V4-Pro lebih lambat daripada Kimi (11s vs 8s). Tapi waktu total dari suatu tugas jauh lebih rendah karena saya tidak menghabiskan 20 menit untuk memperbaiki halusinasi agen.

Pengembang tidak mengukur latensi dari sebuah respons. Dia mengukur waktu antara "saya menajukan pertanyaan" dan "kode ada di repositori saya dan berfungsi". Pada metrik tersebut, DeepSeek-V4-Pro adalah yang tercepat dari tiga.

Pelajaran yang Dipelajari : Cara Memilih LLM Anda untuk Vibe Coding

Di luar peringkat spesifik, pengalaman ini mengajarkan saya untuk mengevaluasi LLM untuk pengembangan perangkat lunak yang didukung berdasarkan kriteria yang tidak ada dalam benchmark manapun :

Lihat arsitekturnya, bukan ukuran konteks yang diumumkan— Sebuah model yang menglaim 256K konteks tetapi hanya memiliki MLA akan berakhir seperti Kimi: secara teoretis mampu, secara praktis tidak dapat digunakan di atas 60K.
Uji pada konteks Anda, bukan pada benchmark generik— Prompt awal saya sebesar 30K token AsciiDoc dengan aturan absolut dan backlog tidak ada hubungannya dengan pertanyaan HLE atau AIME.
Latensi bukanlah musuh bila kualitas ikut— Sebuah model lambat yang menghasilkan kode yang benar lebih cepat daripada model cepat yang menghasilkan kode yang salah.
Waspadalah terhadap model tanpa laporan teknis publik— Jika tim tidak mendokumentasikan arsitektur perhatiannya, berarti mereka tidak percaya pada kinerjanya dalam konteks panjang.

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

title Pohon Keputusan — Memilih LLM-nya untuk Pengembangan yang Dibantu
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

Dan bagaimana dengan Governance Agent dalam semua ini?

Pengalaman ini mengonfirmasi satu poin yang saya pertahankan sejak artikel saya tentang tata kelola Eager/Lazy:Kualitas LLM dan kualitas tata kelola bersifat multiplikatif, bukan aditif.

Dengan Kimi K2.6, tata kelola saya sempurna — tetapi model mengaburkan informasi. Hasil: tata kelola sempurna × halusinasi = nol.

Dengan DeepSeek-V4-Pro, tata kelola EAGER (30K token aturan) + LAZY (arsip sesi, referensi teknis) + Hot/Warm/Cold (cadangan rotatif) membentuk sebuah ekosistem di mana setiap lapisan memperkuat yang lain. Agen memiliki aturan di depan mata (EAGER), dapat mengakses riwayat (LAZY), dan konteks tidak pernah meluap (rotasi cadangan).

_ Sebuah LLM yang baik tanpa tata kelola adalah seperti mesin Ferrari tanpa stir. Tata kelola yang baik tanpa LLM yang baik adalah seperti stir tanpa mesin. DeepSeek-V4-Pro + tata kelola agen saya = pertama kali saya merasa sedang mengemudi. _

Mekanisme backup rotatif (rotasi setiap 10 sesi atau >500 baris EAGER) menjadi bermakna dengan model yang mampu menahan konteks 128K: sliding window dari 10 sesi aktif mempertahankan konteks yang segar tanpa pernah melebihi zona degradasi.

Sumber Teknis

Saya telah menggabungkan pengalaman empiris saya dengan laporan teknis resmi untuk memvalidasi pengamatan saya :

DeepSeek-V4 Technical Report — PDF diambil darihttps://huggingface.co/deepseek-ai/DeepSeek-V4-Flash[HuggingFace]. Gambar 9 : "Kinerja pengambilan tetap sangat stabil dalam jendela konteks 128K. Sementara degradasi kinerja menjadi terlihat di luar batas 128K, kemampuan pengambilan model pada 1 juta token tetap sangat kuat." Arsitektur CSA+HCA yang didokumentasikan bagian 2.3.
GLM-5 Laporan Teknis —https://arxiv.org/abs/2602.15763[arXiv:2602.15763]DSA diperkenalkan melalui pra-pelatihan berkelanjutan, "lossless by construction". Konteks maksimal 202.752 token. Tabel 3/5/6 mendokumentasikan performa konteks panjang versus alternatif (SWA, Gated DeltaNet, SimpleGDN).
Kartu Model Kimi K2.6 —https://huggingface.co/moonshotai/Kimi-K2.6[HuggingFace]. MLA, konteks maksimal 256K. Strategi discard-all di atas ambang batas pada tugas agen (mengonfirmasi secara implisit batas praktis MLA dalam konteks panjang).
Kimi K2 Laporan Teknis —https://arxiv.org/abs/2507.20534[arXiv:2507.20534]. Arsitektur MoE, optimiser MuonClip, kinerja agen (HLE, BrowseComp, Terminal-Bench).

Poin paling terungkap: Dalam penilaian mereka sendiri, Moonshot menerapkan strategi discard-all (penghapusan konteks lama) begitu jendela konteks melebihi batas. Hal ini secara pasti mengonfirmasi apa yang saya amati: MLA saja tidak dapat mempertahankan koherensi di seluruh jendela 256K. Arsitektur tidak mengikuti.

Conclusion: Pilihan Artisan

Setelah tiga minggu dan tiga belas sesi pengembangan nyata, putusannya mutlak:

Kimi K2.6

GLM-5.1

DeepSeek-V4-Pro

Excellent di bawah 60K

Kuat hingga 120K

Mendominasi di mana-mana

Tidak dapat digunakan di luar

Kebingungan permukaan

Stabil hingga 128K

2 sesi, ditinggalkan

3 sesi, ditinggalkan

8 sesi, diadopsi

DeepSeek-V4-Pro telah menjadi LLM default saya untuk semua sesi pengembangan perangkat lunak yang dibantu dengan Opencode. Tidak karena ia yang terbaru. Tidak karena ia memiliki benchmark akademik terbaik. Namun karena dalam kehidupan nyata seorang pengembang yang mengirimkan plugin Gradle Kotlin DSL dengan konteks agen 30K token, ia adalah satu-satunya yang tidak meniakhiri saya ketika konteks membesar.

CSA+HCA adalah game changer arkitektonik. Kompresi tingkat ganda + sparsifikasi bukan detail implementasi — ini yang membedakan antara asisten kode dan rekan tim yang andal.

_ Saya memilih DeepSeek-V4-Pro karena ia adalah satu-satunya dari tiga yang mengubah tata kelola agen saya dari batasan defensif ("bagaimana menghindari agen lupa?") menjadi keunggulan ofensif ("apa yang bisa kita bangun sekarang bahwa agen mengingat semuanya?"). _

Makalah ini adalah hasil dari 13 sesi pengembangan nyata pada proyek`codebase-gradle`, dokumentasi dalam`.agents/sessions/`menurut metodologi pengelolaan agen saya Eager/Lazy/Hot/Warm/Cold. Sumber-sumber teknis yang disebut dapat diakses secara publik di HuggingFace dan arXiv.