1비트 양자화로 Qwen 3.6 27B를 4기가로 눌러놓은 모델이 있는데 이게 의미가 있는지 궁금해서 조사하게되엇고 그에관한내용을 작성하게되었습니다.

Bonsai 27B와 1비트가 살아남는 법

27B 모델이 아이폰에서 돌아간다는 얘기를 처음 들었을 때는 솔직히 좀 의심했습니다. 그냥 홍보용 숫자놀음 아닌가 싶었죠.

https://huggingface.co/prism-ml/Bonsa...

확인해보니 PrismML이라는 캘텍 출신 팀이 만든 모델이었습니다.
다만 새로 사전학습한 모델은 아닙니다.
Qwen3.6-27B를 그대로 가져온 뒤 가중치를 ternary나 binary 수준까지 압축한 방식입니다.

ternary와 binary가 뭔가

지난 Q5 글에서 Q4는 가중치를 16단계, Q5는 32단계로 나눈다고 설명했습니다.

binary는 이 단계 수를 극단적으로 줄여 딱 2단계(-1, +1)만 사용합니다.
ternary는 여기에 0을 추가해 3단계(-1, 0, +1)를 씁니다.

Q4의 16단계나 Q5의 32단계와 비교하면 훨씬 거친 양자화입니다.
가중치 하나를 표현하는 데 이론적으로 binary는 log₂(2)=1비트, ternary는 log₂(3)≈1.58비트면 충분합니다. 그래서 각각 "1비트 모델", "1.58비트 모델"이라고 부릅니다.

Bonsai는 여기에 그룹 단위 스케일을 추가하면서 실제로는 ternary 1.71비트, binary 1.125비트라는 수치가 나옵니다.

그 상태에서 FP16 대비 각각 94.6%, 89.5%의 성능을 유지한다고 주장합니다.

포맷의 정체

실제 가중치 공식은 다음과 같습니다.

w_i = s_g · t_i
(128개 가중치가 FP16 스케일 s_g 하나를 공유)

어디서 많이 본 구조입니다.

Q4_K/Q5_K가 블록마다 로컬 스케일 하나를 두는 방식과 기본 아이디어는 같습니다.
차이라면 블록 크기를 128로 키우고, 블록 안에서 표현 가능한 레벨을 Q5의 32단계가 아니라 2~3단계까지 줄였다는 점입니다.

그래서 "1비트"라는 이름만 보면 모든 정보가 정말 1비트에 들어가는 것처럼 보이지만, 실제로는 정보의 상당 부분이 FP16 스케일 채널에 남아 있습니다.

순수한 1비트 표현이라기보다는 블록 양자화를 극단까지 밀어붙인 구조에 가깝습니다.

왜 ternary가 binary보다 유리한가

여기서 지난 Q5 글에서 이야기했던 가중치 분포 문제가 다시 나옵니다.

대부분의 가중치는 0 근처에 몰려 있고, 일부 값만 100배 이상 크게 튀는 첨도 높은 분포를 보입니다.

binary는 모든 값을 무조건 -1이나 +1 중 하나로 표현해야 합니다.
원래 0 근처에 있던 수많은 가중치도 강제로 양쪽 극단 중 하나로 보내야 한다는 뜻입니다.

반면 ternary에는 0이라는 별도 값이 있습니다.
0 근처에 몰려 있는 가중치를 그대로 0으로 표현할 수 있습니다.

실측 결과도 일관됩니다.
8B와 27B 모두 ternary가 binary보다 높게 나옵니다.

8B는 85.0% vs 78.9%, 27B는 86.2% vs 82.9%입니다.
독립 벤치마크 기준입니다.

이 정도 차이는 단순히 학습을 얼마나 잘했느냐의 문제라기보다 포맷 자체가 가진 구조적인 한계로 보는 편이 맞습니다.

PTQ가 아니라 QAT+증류

여기가 핵심입니다.

이 팀이 공개한 방식은 이미 학습된 모델의 가중치를 단순히 반올림하는 PTQ가 아닙니다.
양자화를 학습 루프 안에 넣고 다시 학습하는 QAT를 사용했습니다.

여기에 정답 라벨만 학습한 것도 아닙니다. 원본 모델이 생성한 사고 과정까지 증류에 활용했다고 합니다.

llama.cpp의 imatrix 캘리브레이션이 "어떤 값이 자주 사용되는지 확인해서 양자화 방향을 조정하는 방식"이라면, Bonsai 쪽은 가중치 자체를 학습 단계에서부터 "반올림해도 손실이 적은 위치"로 이동시키는 접근입니다.

Q4_K_M이 일부 파라미터에 더 많은 비트를 배정해서 손실을 보완하는 방식이라면, 이쪽은 처음부터 극단적인 이산화를 견딜 수 있는 가중치 분포를 학습으로 만들어내겠다는 겁니다.

문제는 정작 이 과정의 핵심이 공개되지 않았다는 점입니다.

STE를 사용했는지, 손실함수를 어떻게 구성했는지, calibration 데이터로 무엇을 사용했는지는 모두 "Caltech IP"라는 이유로 비공개입니다.

가중치와 코드, 벤치마크는 Apache-2.0으로 공개하면서 정작 "왜 이게 되는가"를 설명할 핵심 부분만 닫아둔 셈입니다.

Qwen 에이전트 월드 모델 글을 쓸 때는 "이걸 공개하는 게 놀랍다"고 느꼈는데, 이번에는 반대로 "이 부분만 안 공개하네"라는 생각이 들었습니다.

평균 성능보다 중요한 건 어디서 무너지느냐

평균 89.5%라는 숫자만 보면 모든 영역에서 성능이 약 10%씩 균일하게 떨어진 것처럼 보입니다.

실제로는 그렇지 않습니다.

수학·코딩 영역의 손실은 약 3.8~4% 수준입니다.
구조가 명확하고 중복성이 있는 영역이라 근사가 비교적 잘 먹힙니다.

반면 도구 호출은 80.0에서 66.0으로 떨어집니다. 손실률로 보면 17.5%로, 수학 영역의 약 4.6배입니다.

"정확한 함수명 + JSON 포맷"을 맞혀야 하는 작업은 작은 오차도 바로 실패로 이어지기 때문에 근사의 영향을 크게 받습니다.

다국어와 산술에서도 차이가 큽니다.
페르시아어는 45.2%까지 떨어지는 사례가 있습니다.
조밀하게 저장된 사실 기억은 압축 과정에서 먼저 손실되기 쉬운 영역입니다.

지난 Q4/Q5 글에서 "꼬리 채널이 전체 웨이트의 1%인데 활성화의 55%를 차지한다"고 했던 내용과 같은 맥락입니다.

평균 손실률 하나만 보는 것보다 태스크마다 손실이 얼마나 다르게 나타나는지를 보는 게 더 중요합니다.

독립 벤치마커 ArmanJR가 지적한 부분도 흥미롭습니다.

겉으로 보이는 일부 "붕괴"가 실제 정보 손실이라기보다 토큰 비효율 때문일 수 있다는 겁니다.

같은 정확도에 도달하더라도 Bonsai가 더 긴 사고 사슬을 생성해야 한다면, 동일한 토큰 예산으로 비교하는 것 자체가 불공정할 수 있다는 이야기입니다.

실측에서는 같은 예산에서 Bonsai가 Qwen IQ2_XXS보다 더 빠르게 수렴했고, 지식 자체는 통계적으로 동등했습니다(MMLU p=0.737).

QAT+증류가 압축된 모델 용량에 맞게 다시 적응시키는 효과가 실제로 있는 것으로 보입니다.

그래서 실사용은

폰에서 27B 모델이 돌아간다는 상징성은 분명 큽니다.

다만 3.9GB 모델이라도 100K 컨텍스트를 사용하면 KV 캐시를 포함해 13.7GB까지 늘어납니다.
긴 컨텍스트에서는 "가벼운 모델"이라는 장점이 상당 부분 줄어듭니다.

도구 호출 정확도 역시 74% 수준입니다.
이 상태로 멀티스텝 에이전트 루프에 바로 연결하면 각 단계의 실패가 누적될 수밖에 없습니다.

실사용 기준으로 보면 binary는 아직 쓰기 어렵고, ternary 정도가 마지노선으로 보입니다.

Q5_K_S를 최소선으로 잡는 것과 비슷한 이유입니다.
용량을 조금 더 줄이겠다고 0 근처에 몰려 있는 대다수 가중치의 표현력을 통째로 포기하면 결국 잘못된 출력을 만들 가능성도 같이 올라갑니다.

도구 호출이 필요한 워크플로우라면 이 모델 하나에 전부 맡기기보다, 스키마 검증을 붙인 API 라우팅을 함께 두는 하이브리드 구성이 현실적이라고 봅니다.

1-bit Bonsai 27B — Unpacked FP16 Safetensors

FP16 safetensors (HuggingFace format) of the 1-bit Bonsai 27B model. This repo exists for users who want to run Bonsai with stock HuggingFace tooling or frameworks that don't yet support 1-bit weights natively. The 1-bit hybrid-attention kernels are currently in our forks of MLX, mlx-swift, and llama.cpp — once they land upstream, this unpacked version will no longer be needed.

We strongly recommend using the native 1-bit models instead. The 1-bit format is where all the benefits of Bonsai come from — a 14.2x memory reduction to 3.9 GB, interactive decoding on everyday laptops (44 tok/s on an M5 Pro), and the first 27B-class model that runs on a phone (11 tok/s on iPhone 17 Pro Max). This unpacked FP16 version is full-size (~54 GB) and does not provide any of those advantages.

For the optimized 1-bit release models (recommended):

• Bonsai-27B-mlx-1bit — 1-bit MLX for Apple Silicon (Mac, iPhone, iPad)
• 1-bit GGUF (Q1_0_g128) for llama.cpp (CUDA, Metal, CPU)

For the quality-oriented variant:

• Ternary-Bonsai-27B-mlx-2bit — Ternary Bonsai 27B (~7.2 GB, 95% of FP16) for laptops and GPUs