Qwen3.6 토큰 낭비 확 줄인 GBNF 트릭, LocalLLaMA가 들썩인 이유

LocalLLaMA가 이 글에 크게 반응한 이유는 모두가 이미 겪는 고통을 정면으로 건드렸기 때문이다. 기본 성능은 마음에 드는데, 로컬 모델이 쓸데없이 길게 생각하며 시간을 태우는 현상이다. 글쓴이는 llama.cpp에서 Qwen3.6 35B-A3B와 27B에 맞춘 GBNF grammar를 손봐 prefill churn을 줄였다고 주장했다. 커뮤니티가 바로 움직인 것도 이 문제가 낯설지 않아서다. 그런데 반응이 더 커진 건 개선 폭이 생각보다 컸기 때문이다.

테스트 조건도 비교적 구체적이었다. RTX 5090, Fedora 43, 4월 24일자 llama.cpp mainline 환경에서 간단한 인사 프롬프트, 제약 퍼즐, 그리고 비공개 Rust/Next.js 벤치 60 task-suite를 돌렸다고 적었다. Qwen3.6 27B는 퍼즐 토큰이 40,101에서 7,376으로 줄고, 퍼즐 시간은 13m36s에서 2m27s, 벤치 시간은 29m54s에서 22m20s로 줄었는데 점수는 4620으로 유지됐다고 한다. Qwen3.6 35B-A3B는 숫자가 더 세다. 퍼즐 시간 2m32s에서 12s, 벤치 시간 33m52s에서 11m04s, 벤치 점수는 4620에서 4740으로 올랐다고 적었다.

• 핵심은 새 모델 공개가 아니라 grammar 제약 조정이다
• 가장 큰 장점으로 제시된 것은 reasoning token 낭비 감소다
• 결과는 self-reported이며 Rust/Next.js 벤치는 공개돼 있지 않다
• 댓글은 이게 진짜 품질 향상인지, 아니면 불필요한 chain-of-thought만 눌러서 생긴 효과인지부터 따졌다

바로 그 의심이 이 글을 살렸다. 첫 댓글 중 하나가 사실상 “이거 thinking을 그냥 꺼버린 것 아니냐”는 질문이었다. 다른 이용자들은 적용 방법과 실제 downside를 더 쉽게 설명해 달라고 요구했다. 반대로 호의적인 반응은 GBNF가 예전 structured output 시절에는 흔했는데 왜 요즘 로컬 LLM 튜닝에서 잘 안 보이냐고 되묻는다. 즉, 이 스레드는 점수 자랑보다 훨씬 실무적이었다. 오래된 제어 장치 하나가 최신 reasoning 모델에도 아직 힘을 발휘하는지 모두가 확인하고 싶어 한 셈이다.

매력이 큰 이유는 분명하다. 로컬 모델 이용자는 항상 더 큰 모델만 원하는 것이 아니다. 지금 쓰는 모델이 의식처럼 길게 생각하며 토큰을 태우는 일을 멈추길 바란다. 이 GBNF 조정이 다른 장비에서도 통한다면, 마법 같아서가 아니라 싸고, 로컬에서 바로 시험할 수 있고, 체감이 빠르기 때문에 가치가 있다. 출처 링크: r/LocalLLaMA 스레드.