제 27B post-train bakeoff 게시물의 댓글에서 누군가 35B 버전을 요청하여 실행해 보았습니다. 지난번과 동일한 설정입니다: 제 k8s 클러스터 상의 새로운 Coder 워크스페이스를 사용하며, 각 워크스페이스는 저만의 에이전트(Hermes)를 headless 방식으로 구동합니다. 모델은 하나의 5090에서 llama-swap을 통해 llama.cpp로 구동되며, 모든 호출은 OTel shim을 통해 SigNoz로 추적되어 실행당 전체 트랜스크립트(transcript)가 기록됩니다. 4개의 모델, 6개의 self-grading 태스크, 5회의 반복, 총 120회의 실행, 모든 단계에 MTP 적용, 동일한 샘플링(sampling), 사전 등록된 가설을 바탕으로 진행되었습니다.

KAT-Coder-V2.5-Dev는 기존 모델(stock)의 절반 수준의 입력 토큰(input tokens)만 사용하면서도 가장 높은 기존 모델 통과율(29/30, Qwen3.5-35B와 공동 1위)을 기록했으며, 제가 측정한 것 중 가장 깔끔한 도구 동작(tool behavior)을 보여주었습니다 (30회 실행 동안 잘못된 도구 호출(malformed tool-call) 유출이 0건이었던 반면, 기존 Qwen3.6은 한 가지 태스크에서 195건의 유출이 발생했습니다). 6명의 분석가(3개의 모델 제품군) 모두가 이 모델의 효율적인 규율이 요령을 피우는 것이 아니라, 수정 전 베이스라인 테스트 수행, 버그당 하나의 타겟 패치 적용, 매 반복마다 올바른 경로에 결과물 전달 등을 통해 이루어졌다고 독립적으로 평가했습니다.

Ornith는 25/30을 기록하며 자신의 베이스 모델에 뒤처졌습니다. 이 모델의 실패 원인은 지식이 아닌 메커니즘 문제였습니다: 포맷 유출(format leaks)로 인해 23초 만에 실행이 중단되거나, 파일 전체를 다시 쓰면서 관련 없는 파일들을 손상시키기도 했습니다. 또한 한 연구 실행에서는 llama.cpp 릴리스 태그를 지어냈는데, 정작 자신의 추론(reasoning) 과정에서는 "초안에 언급한 v4659는 조작된 것입니다"라고 말하면서도 결국 해당 태그를 배포했습니다. 채점기(grader)는 이를 통과시켰습니다. 기존 3.6 모델은 가장 강력한 원시 분석가(raw analyst)이자 가장 많은 토큰을 낭비하는 모델이며, 기존 3.5 모델은 조용하고 신뢰할 수 있는 모델입니다.

방법론, 표, 그리고 6개의 인용된 태스크별 분석이 포함된 전체 보고서는 kmarble.dev/posts/35b-coder-bakeoff/에서 확인하실 수 있습니다. 트랜스크립트는 AI 분석가가 읽었으며, 저는 모든 중요한 주장에 대해 수시로 검증(spot-verification)을 수행했습니다. submitted by /u/IvGranite [link] [comments]