DeepSeek-V4-Pro, Kimi K2.6, GLM-5.1: Drei LLMs im Test des Vibe Coding Long Kontext

Erste Sitzung mit Kimi. Aufgabe: die Methode implementieren`resolveActiveKey()in`codebase.kt— eine Funktion zur Auflösung eines API-Schlüssels mit CLI-Fallback. Der Kontext liegt bei 30 K Tokens, Kimi denkt schnell und erzeugt sauberen Code mit Verwaltung des Schlüsselablaufs.

Der Code kompiliert. Die 7 Testfälle bestehen. Ich bin optimistisch.

Zweite Sitzung. Der Kontext steigt auf ~90K Tokens mit den Austauschen. Ich bitte Kimi, ein AsciiDoc-Snapshot-Mechanismus hinzuzufügen, der Geheimnisse vor dem Schreiben anonymisiert.

Das ist der Punkt, an dem es aus dem Ruder läuft. Kimi beginnt, Klassen zu erfinden, die nicht existieren. Er schlägt mir vor`AnonymizedObjectMapper`— eine fiktive Klasse. Er verwechselt`ReadmeYmlAnonymizer` et CodebaseYmlAnonymizer. Er schlägt vor, dass ich importiere`com.fasterxml.jackson.anonymize.*`— ein Paket, das nie existiert hat.

Schlimmer noch: In seiner Reflexionsphase sehe ich, dass er Schlussfolgerungen auf falschen Prämissen aufbaut. Er "erinnert sich", dass`GitConfig`hat ein Feld`anonymizedToken`— nein, es ist`resolvedToken(). Er weist zu`SiteYmlAnonymizer`une Methode`maskSupabaseCredentials()— existiert nicht.

_ Es war kein Fehler. Es war eine schrittweise Auflösung der Kohärenz. Als ob jedes Token, das dem Kontext hinzugefügt wird, das Gedächtnis der ersten 30 000 ein wenig mehr verdünnte. _

Ich breche Kimi nach zwei Sitzungen ab. Die Diagnose ist klar: Der MLA komprimiert den KV-Cache gut, aber ohne einen feinkörnigen sparsen Selektionsmechanismus verdünnt sich die Aufmerksamkeit mechanisch über 60K Tokens hinaus. Jedes Token "sieht" den fernen Kontext immer schlechter — und beginnt, die Lücken mit Rauschen zu füllen.

Der Unterschied ist grundlegend. Wo Kimi die Historie in einem einzelnen latenten Raum komprimiert (und dabei allmählich die Fähigkeit verliert, relevante Informationen zu unterscheiden), fügt GLM ein nachträglich trainiertes Indexer ein, das eine explizite selektive Sparsamkeit durchführt.

Der technische Bericht sagt es ausdrücklich: DSA ist "lossless by construction" — im Gegensatz zu Alternativen wie SWA (Pattern Search), Gated DeltaNet oder SimpleGDN, die bis zu 5,69 Punkte auf RULER@128K verlieren.

GLM-5.1 hält die Distanz besser. In Session 11 (~60k Token) bleibt es konsistent. Es erzeugt ein`SnapshotManager`funktionsfähig mit korrekter Verwaltung der vier Anonymisierer.

Aber die Latenz ist ein Problem. Die Reflexionsphasen von DSA sind schwerer als reines MLA — der Indexer muss bei jedem Schritt den Verlauf neu scannen. Eine Antwort, die mit Kimi 8 Sekunden dauerte, braucht bei GLM 15 Sekunden. Bei einer Sitzung von 30 Nachrichten merkt man das.

Und dann gibt es die subtilen Fehler. GLM verrücktert nicht wie Kimi — aber er macht Fehler beim nommage. Er ruft`toAnonymizedYaml()die Methode, die aufgerufen werden sollte`anonymize(). Er kehrt um`loadReadmeConfiguration()` et loadCodebaseConfiguration()`im`renderFileSection(). Das sind keine Halluzinationen, sondern Oberflächenverwechslungen — aber in der Produktion kann eine Oberflächenverwechslung einen Build zerstören.

Ich hatte drei Sitzungen mit GLM. Es ist besser als Kimi, zweifellos. Aber drei Sitzungen manueller Korrektur bei der Namensgebung zehren.

Zwei Kompressionsstufen, zwei Aufmerksamkeitsgranularitäten:

Ergebnis: bei 1M Token verbraucht DeepSeek-V4-Pro nur27% der Inferenz-FLOPs et 10% der Größe des KV‑CachesIm Vergleich zu DeepSeek-V3.2. Das vorherige Modell.

Und vor allem gibt der technische Bericht (Abbildung 9) an: "Retrieval performance remains highly stable within a 128K context window."

Ich habe acht Sitzungen mit DeepSeek-V4-Pro auf`codebase-gradle`. Acht Sitzungen ohne eine einzige Halluzination, ohne eine einzige erfundene Klasse, ohne eine einzige Namensverwechslung.

Sitzung 1: Implementierung von`CodebaseYmlConfig` et CodebaseYmlAnonymizer. 350 Zeilen Kotlin, Inline-Tests, alles kompiliert. Sitzung 4 : Hinzufügen des`SnapshotManager`mit Baumansicht, Dateisammlung, AsciiDoc-Rendering pro Datei. 279 Zeilen, kein Fehler. Sitzung 7 : Debug des`renderFileSection()`der vier verschiedenen Arten von Anonymisierern ohne Mehrdeutigkeit bei der Auflösung verwalten musste. Gelöst in drei Nachrichten.

Die Latenz ist höher als bei Kimi — etwa 10-12 Sekunden pro Antwort im Thinking-Modus. Aber die Korrekturquote ist praktisch null. Ich verbringe meine Zeit nicht damit, die Fehler des Agents zu korrigieren. Ich code mit ihm.

In Session 8 übersteigt der kumulierte Kontext 100K Token. Ich fordere ein schweres Refactoring: extrahe die vier Inline-Verifizierungsaufgaben des`build.gradle.kts`zu JUnit5-Testdateien in`buildSrc/src/test/`python import sys sys.stdout.write(sys.stdin.read())

Der Agent schlägt einen Plan in drei Phasen vor.

Der Plan ist korrekt. Die Ausführung ist sauber. Er identifiziert sogar einen Edge Case, den ich übersehen habe: die doppelten Jackson-Abhängigkeiten zwischen`buildscript {}` et `buildSrc/build.gradle.kts`die während der Migration vereinheitlicht werden müssen

100K Tokens Kontext, und der Agent erinnert sich daran, dass`CodebaseYmlAnonymizer.TOKEN_MASK`ist`"*"`, dass`GitConfig.resolvedToken()ist eine Erweiterungsfunktion definiert in`readme.kt, und dass`SnapshotManager.PRUNED_DIRS`schließt aus`build`, .gradle et .git.

Das ist es, der Unterschied.

Die gestützte Softwareentwicklung ist ein Anwendungsfall extremer für die Langkontext-Aufmerksamkeit. Sie benötigen: - Lokale Präzision (von was erbt diese Klasse? Wo ist diese Methode definiert?) →CSA - Globale Vision (Warum existiert dieses Modul? Wie interagieren die vier Anonymisierer?) →HCA

Kimi mit MLA allein verwaltet die lokale Präzision, verliert jedoch den globalen Überblick über 60K. GLM mit DSA verbessert den globalen Überblick, bleibt jedoch einstufig. DeepSeek kombiniert beides explizit.

Mein Governance-System lädt beim Start ~30K Tokens an Regeln und Backlog. Mit einem stabilen Fenster von bis zu ~128K Tokens verfügt DeepSeek über ~100K Tokens Puffer für die Austausche der Sitzung. Das ist 3‑bis‑4‑mal mehr als das, was Kimi ohne Leistungsverlust verarbeiten kann.

_ Die 128‑K‑Fenster mit perfekter Stabilität entsprechen genau meinen Anforderungen: 30 K EAGER + 70 K Austausch = eine produktive Sitzung mit 20‑30 Nachrichten, ohne jemals den grünen Bereich zu verlassen. _

Ja, DeepSeek-V4-Pro ist langsamer als Kimi (11s vs 8s). Aber die *Gesamt*zeit einer Aufgabe ist viel geringer, weil ich nicht 20 Minuten damit verbringe, die Halluzinationen des Agents zu korrigieren.

Der Entwickler misst nicht die Latenz einer Antwort. Er misst die Zeit zwischen "je pose la question" und "le code est dans mon repo et il fonctionne". Nach dieser Metrik ist DeepSeek-V4-Pro der schnellste der drei.