DeepSeek-V4-Pro, Kimi K2.6, GLM-5.1: Long Context Vibe Coding에서 시험에 오른 세 LLMs

Kimi와의 첫 번째 세션. 작업: 메서드 구현`resolveActiveKey()안에`codebase.kt— API 키를 해결하는 함수이며 CLI 폴백을 갖는 함수. 컨텍스트는 30K 토큰이며, Kimi는 빠르게 추론하고 키 만료 관리가 있는 깨끗한 코드를 생성합니다.

코드가 컴파일됩니다. 7개의 테스트 케이스가 통과됩니다. 저는 낙관적입니다.

두 번째 세션. 컨텍스트가 교환으로 인해 약 90K 토큰까지 증가합니다. 나는 Kimi에게 AsciiDoc 스냅샷 메커니즘을 추가하여 글을 쓰기 전에 비밀을 익명화하도록 요청한다.

여기서부터 일이 꼬이기 시작해. 기미는 존재하지 않는 클래스를 발명하기 시작한다. 그는 나에게 제안한다.AnonymizedObjectMapper— 가상의 클래스. 그는 혼동한다`ReadmeYmlAnonymizer` et CodebaseYmlAnonymizer. 그가 내게 수입하라고 제안한다`com.fasterxml.jackson.anonymize.*`— 존재한 적이 없는 패키지.

더욱이: 그의 반성 단계에서, 나는 그가 잘못된 전제에 기반하여 논리를 구성하고 있다는 것을 본다. 그는 "기억한다"고 한다`GitConfig`필드가 있습니다`anonymizedToken`— 아니, 그것이`resolvedToken().그는 …​에 돌린다`SiteYmlAnonymizer`방법`maskSupabaseCredentials()— 존재하지 않는.

_ 이게 버그가 아니었다. 그것은 일관성의 점진적인 소멸이었다. 마치 컨텍스트에 추가된 각 토큰이 처음 30,000개의 메모리를 점점 더 희석시키는 것처럼. _

두 세션 후에 Kimi를 멈춥니다. 진단은 명확합니다: MLA는 KV 캐시를 잘 압축하지만, 미세한 희소 선택 메커니즘이 없으면 주의가 60K 토큰을 넘어가면서 기계적으로 희석됩니다. 각 토큰은 먼 컨텍스트를 점점 더 잘 볼 수 없게 되고 — 빈틈을 소음으로 채우기 시작합니다.

차이는 근본적이다. Kimi가 기록을 단일 잠재 공간에 압축할 때(그리고 점차적으로 관련 정보를 구분하는 능력을 잃을 때), GLM은 사후 훈련된 인덱서를 삽입하여 명시적인 희소 선택을 수행한다.

기술 보고서는 명시적으로 다음과 같이 말합니다: DSA는 "lossless by construction" — SWA (패턴 검색), Gated DeltaNet 또는 SimpleGDN과 같은 대안들과 달리, 이들은 RULER@128K에서 최대 5.69포인트를 잃습니다.

GLM-5.1이 거리를 더 잘 유지합니다. 세션 11 (~60K 토큰)에서 일관성을 유지합니다. 그것은 생산하는`SnapshotManager`네 개의 익명화 도구를 올바르게 관리하는 기능적인

하지만 지연은 문제입니다. DSA 반사 단계는 순수 MLA보다 더 무겁습니다 — 인덱서는 각 단계에서 기록을 다시 스캔해야 합니다. Kimi로는 8초가 걸리던 응답이 GLM에서는 15초가 걸립니다. 30개의 메시지로 구성된 세션에서는 이것이 느껴집니다.

그리고 미묘한 오류들이 있습니다. GLM은 Kimi처럼 환각을 일으키지 않지만, 이름 지정 오류를 합니다. 그것은 호출한다`toAnonymizedYaml()호출되어야 하는 메서드`anonymize()`python print(". 뒤집합니다", end='')`loadReadmeConfiguration() et loadCodebaseConfiguration()`안에`renderFileSection(). 이건 환각이 아니라 표면적인 혼란이지만 — 하지만 프로덕션에서 표면적인 혼란은 빌드를 깨뜨릴 수 있다.

GLM과 세 번의 세션을 가졌다. 그는 Kimi보다 확실히 더 낫다. 하지만 이름 지정 세부 사항에 대한 수작업 세 세션은 지치게 만든다.

압축의 두 단계, 주의의 두 가지 세밀도:

결과 : 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`. 환각 없이, 발명된 클래스 없이, 이름 지정 혼동 없이 여덟 회의 세션이었습니다.

세션 1: 구현`CodebaseYmlConfig` et CodebaseYmlAnonymizer. 350줄의 Kotlin, 인라인 테스트, 모두 컴파일됨. 세션 4: 추가`SnapshotManager`트리 뷰, 파일 수집, 파일당 AsciiDoc 렌더링. 279줄, 오류 없음. 세션 7: 디버그 du`renderFileSection()`네 가지 유형의 다른 익명화 도구를 해결 모호함 없이 관리해야 했고, 세 개의 메시지로 해결되었습니다.

지연이 Kimi보다 더 높습니다 — 생각 모드에서 응답당 약 10-12초 정도입니다. 하지만 수정률은 거의 제로입니다. 저는 에이전트의 오류를 고치는 데 시간을 보내지 않습니다. 저는 코딩합니다 avec 그.

8회차 세션에서 누적된 컨텍스트가 100K 토큰을 초과합니다. 저는 무거운 리팩터링을 요청합니다: 인라인 검증 작업 네 가지를 추출하는`build.gradle.kts`JUnit5 테스트 파일 쪽으로 안에`buildSrc/src/test/`.

대리인은 3단계 계획을 제안합니다:

계획이 정확합니다. 실행이 깔끔합니다. 그조차도 내가 놓친 엣지 케이스를 식별합니다: 중복된 Jackson 의존성 사이`buildscript {}` et `buildSrc/build.gradle.kts`마이그레이션 중에 통합되어야 하는

100K 컨텍스트 토큰, 그리고 에이전트는 기억합니다`CodebaseYmlAnonymizer.TOKEN_MASK`이다`"*"`, 라고`GitConfig.resolvedToken()는에서`readme.kt, 그리고`SnapshotManager.PRUNED_DIRS`제외한다`build`, .gradle et .git.

그게 차이야.

지원되는 소프트웨어 개발은 장기 컨텍스트 주의를 위한 극한 사용 사례입니다. 다음과 같이 필요합니다: - 현지 정확도 (이 클래스는 무엇을 상속받았나요? 이 메서드는 어디서 정의되었나요?) →CSA - 전체적인 비전 (이 모듈이 왜 존재하는가? 네 개의 익명화 도구가 어떻게 상호작용하는가?) →HCA

Kimi는 MLA만으로 로컬 정확성을 관리하지만 60K 이상에서는 글로벌 시각을 잃습니다. GLM은 DSA로 글로벌 시각을 개선하지만 단일 수준에 머무릅니다. DeepSeek은 두 가지를 명시적으로 결합합니다.

내 거버넌스 시스템은 시작 시 약 30K 토큰의 규칙과 백로그를 로드합니다. 128K까지 안정적인 창을 가지면, DeepSeek은 세션 교환을 위한 약 100K 토큰의 여유를 갖습니다. 이는 Kimi가 성능 저하 없이 처리할 수 있는 양의 3~4배입니다.

_ 완벽한 안정성을 위한 128K 창은 정확히 내 필요에 맞습니다: EAGER 30K + 교환 70K = 녹색 구역을 벗어나지 않는 20-30 메시지의 생산적인 세션. _

예, DeepSeek-V4-Pro는 Kimi보다 느립니다 (11초 vs 8초). 하지만 작업의 total 시간이 훨씬 짧습니다. 왜냐하면 에이전트의 환각을 수정하는 데 20분을 쓰지 않기 때문입니다.

개발자는 응답의 지연 시간을 측정하지 않습니다. '질문을 던지는 순간’과 '코드가 내 저장소에 들어 있고 작동하는' 사이의 시간을 측정합니다. 이 지표에서 DeepSeek-V4-Pro가 세 가지 중 가장 빠릅니다.