Ternary-Bonsai-27B(2비트)와 Bonsai-27B(1비트)를 8GB VRAM 환경의 Terminal-Bench 2.0에서 돌려봄
I ran Ternary-Bonsai-27B (2-bit) and Bonsai-27B (1-bit) on Terminal-Bench 2.0, in 8GB VRAM
핵심 요약
Bonsai 모델의 성능을 테스트한 결과, 극단적인 양자화로 인해 정확도가 낮고 에이전트 작업에 부적합함이 확인되었습니다.
- 성능 테스트 — 2비트 모델은 9B 모델보다 낮은 정확도를 보임
- 에이전트 한계 — 1비트 모델은 무한 루프에 빠지는 등 실사용 불가
- VRAM 효율성 — 2비트 모델은 오히려 9B 모델보다 VRAM을 더 많이 차지함
- 기술적 제약 — 극단적 압축으로 인한 정보 손실은 물리적 한계가 존재함
Bonsai 모델들이 실제로 어느 정도 수준인지 궁금해서, 이미 가지고 있던 qwen-3.6-35b-a3b와 qwen-3.5-9b의 결과와 비교해 보려고 같은 하네스에서 돌려봤음. 더 많은 사람이 궁금해할 것 같아서 공유함.
셋업: harbor 어댑터를 통한 little-coder 하네스, terminal-bench 2.0의 89개 작업 전체, 단일 시도(k=1), 40턴 제한, 온도 0.2. RTX 5070 노트북 8GB, i9-14900HX, 32GB RAM, CUDA 13.1. 런타임은 PrismML의 llama.cpp 포크 버전임(순정 llama.cpp는 2비트 커널을 로드할 수 없음).
결과: 2비트 Ternary-Bonsai-27B는 7.9%를 기록했고, Qwen3.5-9B는 9.2%, Qwen3.6-35B-A3B는 24.3%를 기록했음(둘 다 k=5 실행의 시행 평균값). 1비트 Bonsai는 숫자를 전혀 만들어내지 못했음.
좋은 점은 진짜로 GPU에 전부 들어간다는 거임. 도구 호출도 깔끔했고, 전체 실행 동안 파싱 에러가 하나도 없었음. 나쁜 점은 정확도임: 7.9%는 같은 카드에 완전히 들어가는 9B 모델보다도 낮음. 즉, 이 모델을 쓰는 건 그냥 일반적인 양자화(Q4)를 적용한 더 작은 밀집 모델을 돌리는 것보다 정확도 측면에서 손해임. 2비트 모델이 해결한 7개 작업 중 35B 모델은 6개를 해결했음.
1비트 모델은 에이전트 하네스에서 사용할 수 없음. 단순한 프롬프트에서는 괜찮음. 12*12는 144가 나오고, 1007 토큰 내에서 is_prime도 정확하게 수행하고 깔끔하게 멈춤. 하지만 에이전트 루프 하에서는 첫 번째 작업에서 14,000 토큰이 넘는 완료물을 생성했는데, 멈춤 토큰을 전혀 내뱉지 않고 32k 문맥을 다 소진할 때까지 횡설수설했음. 추적 결과를 보면 아주 사소한 프롬프트에서도 자기 검증 틱(tic)이 발생하는데, 난이도가 올라갈수록 이게 눈덩이처럼 불어나서 종료되지 않음. 그게 확실해지자마자 실행을 중단했음.
혹시 더 필요한 수치나 데이터가 있으면 언제든 공유하겠음!
