Bonsai 27B: 노트북과 폰에서 실행되는 27B급 이진 및 삼진 저비트 LLM (feat. PrismML)

9bow · 7월 16, 2026, 3:30오전

Bonsai 27B 소개

스마트폰에 27B(270억) 파라미터 규모의 언어 모델을 통째로 담아 실행할 수 있을까요? 상식적으로는 어렵습니다. 27B 모델은 16비트 정밀도(FP16)로 저장하면 가중치만 약 54 GB를 차지하는데, 최신 아이폰이 앱 하나에 허용하는 메모리는 6 GB 남짓에 불과하기 때문입니다. 그동안 이 규모의 지능을 쓰려면 클라우드에 요청을 보내거나, 여러 장의 GPU가 달린 워크스테이션을 갖추는 수밖에 없었습니다.

Bonsai 27B 는 바로 이 문제를 정면으로 공략하는 연구입니다. PrismML이 공개한 이 기술 보고서는 Qwen 팀의 하이브리드 어텐션 모델인 Qwen3.6-27B 를 이진(binary, 1비트) 또는 삼진(ternary) 표현으로 옮기면서도, 그 모델이 가진 사고(reasoning) 능력과 도구 호출, 에이전트 워크플로 능력을 거의 그대로 보존하는 방법을 제시합니다. 그 결과 삼진 모델은 약 5.9 GB로 일반 노트북에서, 이진 모델은 약 3.9 GB로 iPhone 17 Pro Max 같은 고성능 스마트폰에서 처음으로 27B급 모델이 대화형으로 동작합니다. 모든 가중치는 Apache 2.0 라이선스로 공개되었습니다.

27B 규모에서 효율은 선택이 아닌 제약

대형 언어 모델(Large Language Model)의 화두는 이제 "얼마나 잘 학습할 수 있는가"에서 "얼마나 안정적이고 저렴하게 실행할 수 있는가"로 옮겨가고 있습니다. 사용자의 매 발화, 에이전트의 매 단계, 매 도구 호출마다 지연 시간과 에너지, 인프라 비용이 발생하고, 이 비용은 배포된 시스템의 수명 내내 누적됩니다. 특히 노트북, 스마트폰, 임베디드 시스템 같은 엣지(edge) 환경에서는 메모리, 대역폭, 발열, 배터리라는 물리적 한계가 고정되어 있어서, 모델의 품질만으로는 충분하지 않고 기기의 물리적 한계 안에 들어맞아야 합니다.

자기회귀(autoregressive) 생성에서, 특히 온디바이스 환경의 작은 배치 크기에서 병목은 연산량이 아니라 메모리 이동량 입니다. 토큰 하나를 생성할 때마다 사실상 모델의 전체 가중치를 메모리에서 읽어내야 하기 때문입니다. 그래서 가중치를 1비트나 2비트로 저장하는 것은 단순히 디스크 용량을 아끼는 데 그치지 않고, 매 디코딩 단계의 메모리 트래픽을 줄여 토큰당 에너지를 낮추고 제한된 하드웨어에 강력한 모델을 상주시킬 수 있게 합니다. 대역폭에 묶인 디코더의 최대 생성 속도는 "기기의 메모리 대역폭을 모델의 가중치 크기로 나눈 값" 으로 결정되므로, 작은 발자국(footprint)은 곧 더 빠른 속도를 의미합니다.

기존 저비트 방식은 왜 4비트 아래에서 무너지는가

27B 모델의 발자국 사다리를 보면 문제가 분명해집니다. FP16에서 약 54 GB, Qwen이 기본 제공하는 FP8 빌드가 약 27 GB, 진짜 4비트 표현이 약 14 GB입니다. 한 단계씩 내려가도 셋 다 스마트폰과 대부분의 소비자용 노트북에는 여전히 너무 큽니다. 정작 그 기기들에 들어맞을 영역, 즉 가중치당 4비트 아래의 영역이야말로 기존 방식이 무너지는 지점입니다.

기존 저비트 방식의 첫 번째 접근은 혼합 정밀도(mixed-precision) 양자화 입니다. 이 방식은 임베딩이나 어텐션 및 출력 프로젝션 같은 민감한 텐서를 4에서 8비트로 남겨두고 일부 텐서만 공격적으로 압축한 뒤, 블록 단위 스케일과 최솟값을 덧붙입니다. 문제는 광고된 비트 폭이 가장 많이 압축된 텐서만을 가리킨다는 점입니다. 예컨대 "4비트" 라고 불리는 Q4_K_XL 빌드는 가중치당 실제 평균이 5.2 비트이고, "2비트" IQ2_XXS 는 실제로 2.8 비트입니다. 이런 고정밀 탈출구(escape hatch)가 도처에 남아 있기 때문에 4비트 위에서는 품질이 유지되지만, 엣지 배포에 필요한 2비트 미만 영역에는 결코 도달하지 못합니다.

두 번째 접근은 처음부터 저비트로 학습하는 방식입니다. 가장 유명한 BitNet 과 그 1.58비트 후속 연구 는 네트워크를 low-bit 영역에서 밑바닥부터 사전 학습해 품질 붕괴를 피합니다. 하지만 이는 훨씬 제약이 큰 접근입니다. 기존에 사전 학습된 모델을 전부 버리고 새 모델마다 전체 사전 학습을 다시 해야 하며, 그 비용은 소수의 조직만 감당할 수 있습니다. 확장성도 입증되지 않아서, 네이티브 1비트 모델은 아직 약 2B 규모에 머물러 있습니다.

Bonsai는 BitNet과 정반대의 길을 택합니다. 이미 나와 있는 사전 학습 모델에서 출발해 이를 이진 또는 삼진 표현으로 옮기므로, 실무자들이 이미 신뢰하며 쓰는 바로 그 모델을 대체하지 않고 보존합니다. 이 접근이 실용적이라는 점은 PrismML이 앞서 공개한 1.7B에서 8B 규모의 Bonsai 모델들이 이미 입증했습니다. 다만 그 모델들은 사고, 연쇄적 사고(chain-of-thought), 신뢰할 만한 도구 사용 같은 현대 모델의 핵심 능력을 갖추지 못했습니다. Bonsai 27B는 이 능력 집합 전체를 1비트 및 삼진 영역으로 온전히 가져온 최초의 모델 입니다.

"저비트(Low-Bit)"라는 이름의 함정

이 분야에서 비트 폭 라벨은 실제 평균 비트 폭과 거의 일치하지 않으며, 바로 이 지점이 이 보고서가 강조하는 핵심입니다. 앞서 언급했듯 라벨은 가장 많이 압축된 텐서만을 묘사할 뿐, 모델 전체를 대변하지 않습니다. 평가에 쓰인 빌드들의 실제 평균 비트 폭과 발자국을 나란히 놓으면 차이가 분명해집니다.

빌드	광고된 라벨	실제 평균 bits/weight	발자국
Q4_K_XL	"4비트"	5.2	17.6 GB
IQ2_XXS	"2비트"	2.8	9.4 GB
Ternary Bonsai 27B	ternary	1.71	5.9 GB
1-bit Bonsai 27B	1비트	1.125	3.9 GB

여기서 두 가지가 따라 나옵니다. 첫째, 기존 사후 학습(post-training) 방식은 어디에도 완전한 종단간(end-to-end) 압축이 없습니다. 디코딩 경로 어딘가에 항상 고정밀 탈출구가 존재하기 때문에 4비트 위에서 품질을 지키지만, 동시에 엣지 배포가 요구하는 2비트 미만 발자국에는 이르지 못합니다. 둘째, 정직한 비교는 이름 대 이름이 아니라 비트 대 비트 여야 합니다. Bonsai는 언어 모델의 행렬 위주 구성 요소, 즉 임베딩, 어텐션 프로젝션, MLP 프로젝션, LM 헤드 전체에 이진 또는 삼진 표현을 종단간으로 적용하여 진짜 1.125 비트와 1.71 비트를 달성합니다. 비전 타워는 별도로 4비트(HQQ)로 다루고, 정규화 및 스케일 파라미터라는 극소량의 꼬리만 고정밀로 남긴다는 점을 분명히 밝히고 있습니다.

Bonsai 27B의 표현 방식

Bonsai 27B는 Qwen3.6-27B 에서 직접 유도되며 아키텍처 자체는 그대로 유지합니다. 새로운 부분은 두 층위에 걸쳐 있습니다. 하나는 사전 학습된 27B를 이진 또는 삼진 가중치로 옮기면서 행동을 보존하는 표현 변환 이고, 다른 하나는 그 가중치를 효율적으로 실행하는 배포 스택 (종단간 저비트 저장, 명시적 런타임 형식, 하이브리드 어텐션 백본을 위한 커스텀 커널)입니다.

기반 모델인 Qwen3.6-27B는 어텐션의 약 75\% 가 선형 어텐션(linear attention)이고 나머지 약 25\% 가 완전 어텐션(full attention)인 하이브리드 구조입니다. 여기에 SwiGLU MLP, RoPE, RMSNorm을 사용하며, $262$K 토큰의 긴 컨텍스트를 지원합니다. 선형 어텐션이 지배적인 덕분에 긴 컨텍스트 추론(inference)이 온디바이스에서도 실용적으로 유지됩니다. 파라미터는 언어 모델 약 $24.8$B(64개 블록), 비전 타워 약 $0.46$B(27개 블록), 임베딩 및 LM 헤드 약 $2.5$B로 구성됩니다.

삼진(Ternary) 가중치 형식

삼진 형식에서 각 가중치는 \{-1, 0, +1\} 중 하나의 값을 가지며, 128개 가중치로 이루어진 그룹마다 FP16 스케일 하나를 공유합니다. 유효 가중치는 w_i = s_g \cdot t_i (t_i \in \{-1, 0, +1\})로 표현되며, 여기서 s_g 는 그룹 g 의 스케일입니다. 삼진 값 하나는 \log_2 3 \approx 1.585 비트의 정보를 담으므로, 128개마다 FP16 스케일 하나를 더하면 유효 저장 비용은 다음과 같습니다.

b_{\text{eff}} \approx \log_2 3 + \frac{16}{128} \approx 1.71 \text{ bits/weight}

이는 FP16 대비 이상적으로 16 / 1.71 \approx 9.4\times 의 가중치 압축에 해당합니다. 이진 형식에 비해 0 이라는 상태가 하나 더 있어 더 표현력이 풍부한 알파벳을 갖게 되고, 이 덕분에 완전 정밀도 모델의 행동을 더 많이 복원합니다. 그래서 삼진은 이 계열에서 품질 지향 운영 지점입니다.

이진(Binary) 가중치 형식

이진 형식에서 각 가중치는 부호 비트 하나, 즉 \{-1, +1\} 중 하나만 가지며, 마찬가지로 128개 그룹마다 FP16 스케일 하나를 공유합니다. 유효 저장 비용은 다음과 같습니다.

b_{\text{eff}} \approx 1 + \frac{16}{128} = 1.125 \text{ bits/weight}

이는 FP16 대비 이상적으로 16 / 1.125 \approx 14.2\times 의 압축입니다. 이 계열에서 가장 공격적인 지점으로, 저장 발자국과 매 디코딩 단계의 가중치 트래픽을 모두 최소화하며, 27B 모델을 스마트폰의 메모리 예산 안으로 밀어 넣는 것이 바로 이 형식입니다.

저장 공간과 실제 배포 크기

이론적 크기와 실제 배포 크기는 삼진에서만 차이가 납니다. 현재 커널은 삼진 값 하나를 2비트 슬롯에 저장하기 때문에, 네이티브 삼진 커널이 나오기 전까지 삼진의 배포 발자국은 정보 이론적 최솟값보다 큽니다. 이진 형식에는 이런 간극이 없어 네이티브 1비트 레이아웃 그대로 배포됩니다.

형식	이상적 bpw	이상적 크기	압축률	실제 배포
FP16 (기준)	16.0	약 54 GB	1.0\times	-
Ternary g128	1.71	5.9 GB	약 9.4\times	약 7.2 GB
Binary g128	1.125	3.9 GB	약 14.2\times	약 3.9 GB

스마트폰에서는 저장 크기보다 "들어맞는가"라는 관문이 더 까다롭습니다. iOS는 앱 하나가 물리 메모리의 절반가량만 쓰도록 제한하므로 12 GB 아이폰은 모델에 약 6 GB만 노출합니다. 이 예산에서는 FP16과 Q4_K_XL 은 물론이고 삼진 빌드(5.9 GB)조차 KV 캐시와 활성값이 들어갈 자리를 거의 남기지 못합니다. 결국 3.9 GB의 이진 Bonsai만이 여유를 두고 온디바이스로 동작하는 유일한 변형입니다.

KV 캐시 양자화

온디바이스 긴 컨텍스트는 메모리 문제가 두 겹입니다. 가중치가 들어맞아야 하고, 그 가중치가 생성하는 KV 캐시(key-value cache)도 들어맞아야 합니다. Qwen3.6-27B가 하이브리드 모델인 덕분에 64개 레이어 중 16개만 커지는 완전 어텐션 캐시를 갖고(선형 어텐션 레이어는 고정 크기 순환 상태를 유지), 캐시가 이미 조밀한 27B 트랜스포머보다 약 4\times 작습니다. 그럼에도 FP16 기준으로 토큰당 약 64 KiB이고, $256$K 토큰 창은 약 17 GB를 차지하여 두 Bonsai 모델의 가중치보다도 큽니다. 4비트 KV 캐시를 쓰면 이를 약 4\times 줄여 $256$K 창에서 약 4.3 GB로 낮춥니다.

흥미로운 점은 "4비트 캐시가 쓸 만한지는 모델이 그것을 견디는지에 달려 있다" 는 것입니다. 연구팀은 각 모델의 FP16 KV 기준선 대비 4비트 KV 캐시가 유발하는 출력 순방향 KL 발산(forward-KL)으로 이 내성을 측정했습니다.

모델 (가중치 형식)	On-policy (MATH-500)	Off-policy (BABILong-16K)
Qwen3.6-27B FP16	0.0137	0.222
Qwen3.6-27B Q4_K_XL ("4비트")	0.0146	0.259
Ternary Bonsai 27B	0.0011	0.0029
Binary Bonsai 27B	0.0009	0.00233

Bonsai 모델은 4비트 KV 캐시를 거의 손실 없이 견딥니다. FP16 기준선 대비 온폴리시에서 약 12 배에서 15 배, 오프폴리시에서 약 75 배에서 95 배 적은 출력 발산을 보이는 반면, 기존 "4비트" 빌드는 FP16과 똑같이 행동하여 압축된 가중치가 캐시 내성에는 전혀 기여하지 못함을 드러냅니다. 해석은 자연스럽습니다. Bonsai 모델은 이미 이런 종류의 이산화 잡음을 견디도록 다듬어졌기 때문에, KV 캐시를 압축해도 버려지는 유용한 정보가 훨씬 적습니다.

하이브리드 어텐션을 위한 저비트 커널

압축된 표현은 런타임이 그것을 직접 실행할 수 있어야 비로소 값어치를 합니다. 기존 저비트 추론 경로는 표준 완전 어텐션 트랜스포머를 위해 만들어져서, 선형 어텐션과 주기적 완전 어텐션이 교차하는 Qwen3.6-27B의 하이브리드 블록을 다루지 못합니다. 그래서 연구팀은 이 하이브리드 백본을 위한 커스텀 1비트 및 2비트 커널을 각 백엔드에 맞춰 새로 구축했습니다.

이 커널은 패킹된 이진 또는 삼진 가중치를 직접 소비합니다. 부호 코드나 삼진 코드를 풀어내고 그룹별 FP16 스케일을 융합 행렬 곱셈 안에서 적용하므로, 모델이 조밀한 FP16 텐서로 메모리에서 복원되는 일이 없습니다. 활성값과 어텐션 연산, 누적에 민감한 단계는 수치 안정성을 위해 고정밀로 유지합니다. 이 경로는 Mac, iPhone, iPad를 위한 Apple MLX(Python 및 Swift)와 NVIDIA GPU를 위한 CUDA에서 제공됩니다.

이득은 온디바이스 사용에서 가장 중요한 곳에 집중됩니다. 토큰 생성은 메모리 대역폭에 묶여 있어 매 단계 전체 가중치를 읽어야 하므로, 단계당 이동 바이트를 줄이면 큰 속도 향상이 나타납니다. 반면 프롬프트 처리는 여러 토큰을 병렬로 다루는 연산 위주 작업이라 저비트 표현의 이득이 크지 않습니다. 즉 체감 지연을 좌우하는 토큰 단위 생성 단계가 정확히 가장 큰 이득을 보는 바람직한 구조입니다.

플랫폼	변형	발자국	TG128 (tok/s)	PP512 (tok/s)
Laptop (M5 Max)	Binary	3.9 GB	66.4	874
Laptop (M5 Max)	Ternary	7.2 GB	44.0	830
Laptop (M5 Pro)	Binary	3.9 GB	44.2	421
Laptop (M5 Pro)	Ternary	7.2 GB	26.2	393
iPhone 17 Pro Max (A19 Pro)	Binary	3.9 GB	11.0	111
Single GPU (H100, CUDA)	Binary	3.9 GB	104.8	2755
Single GPU (H100, CUDA)	Ternary	7.2 GB	98.0	2596

여기서 TG128 은 128개 토큰 생성 처리량, PP512 는 512개 입력 토큰의 프롬프트 처리 처리량입니다. 엣지 플랫폼에서는 완전 정밀도(54 GB)는 물론 Q4_K_XL(17.6 GB)조차 적재되지 않으므로, 여기서 의미 있는 진술은 속도 배수가 아니라 "27B 모델이 기기에서 아예 돌아간다" 는 사실 그 자체입니다. M5 Pro에서 삼진 빌드는 약 26 tok/s, 이진 빌드는 약 44 tok/s를 유지하며, iPhone 17 Pro Max에서 이진 모델은 약 11 tok/s로 생성합니다. 이는 27B급 모델이 스마트폰에서 대화형으로 생성하는 최초의 사례입니다. 한편 H100의 두 변형이 서로 수렴하는(104.8 대 98 tok/s) 현상은 규칙을 증명하는 예외입니다. 배치 크기 1 에서 데이터센터 GPU는 가중치 대역폭이 아니라 커널 실행과 동기화 지연에 묶이기 때문입니다.

DSpark: 추측 디코딩으로 한 번 더 가속

저비트 가중치가 디코딩 단계당 이동 바이트를 줄인다면, 추측 디코딩(speculative decoding)은 생성 토큰당 대상 모델의 순전파 횟수를 줄입니다. 둘은 상호 보완적이며 Bonsai 27B는 둘을 함께 제공합니다. 추측 디코딩은 무손실(lossless) 기법입니다. 가벼운 드래프터(drafter)가 후보 토큰 블록을 제안하면 대상 모델이 이를 단 한 번의 순전파로 검증하고, 대상 모델 자신의 분포와 일치하는 가장 긴 접두사를 거절 샘플링으로 받아들입니다. 검증이 분포를 정확히 보존하므로 받아들여진 토큰은 일반 생성과 구분되지 않고, 속도 향상에 품질 대가가 따르지 않습니다.

DSpark 는 DeepSeek-AI가 제안한 준자기회귀(semi-autoregressive) 드래프터 입니다. 비싼 초안 백본을 완전히 병렬로 유지해 초안 지연이 블록 크기와 거의 무관하도록 하고, 여기에 블록 내부의 토큰 의존성을 주입하는 가벼운 순차 헤드(sequential head)만 덧붙입니다. 이 순차 헤드는 순수 병렬 드래프터의 고질적 약점인 "접미사 감쇠(suffix decay)", 즉 블록 후반 위치일수록 독립적으로 예측되어 거절될 확률이 높아지는 문제를 해결합니다. 그 위에 확신 헤드(confidence head)가 위치별 접두사 생존 확률을 추정하고, 하드웨어를 고려한 스케줄러가 이를 이용해 기대 이득이 양(+)인 토큰만 검증합니다. 즉 "더 길게가 아니라 더 똑똑하게 검증" 하는 방식으로, 동시 부하에서도 이득을 안정적으로 유지합니다.

이 릴리스의 드래프터는 대상의 5개 균등 간격 레이어에서 뽑은 은닉 상태를 조건으로 삼는 6개 레이어짜리 컴팩트한 블록 병렬 트랜스포머로, 드래프터 고유 가중치는 서빙 정밀도에서 약 0.5 GB를 더합니다. 드래프터 자체도 4비트로 양자화되어 배포됩니다.

구성	수용 길이 \tau	tok/s	속도 향상
Ternary, 저비트 커널만	1.0	98.0	1.0\times
Ternary + DSpark	3.7	131.8	1.34\times
Binary, 저비트 커널만	1.0	104.8	1.0\times
Binary + DSpark	3.6	143.8	1.37\times

NVIDIA H100의 CUDA 서빙 경로에서 드래프터 레이어는 저비트 커널 위에서 측정된 순이득을 보입니다. 초안 깊이 k=4 에서 이진 대상은 1.37\times, 삼진 대상은 1.34\times 의 디코딩 속도 향상을 얻습니다. 다만 Apple Silicon에서는 배치 크기 1 의 다중 행 검증 패스가 아직 이득을 상쇄하지 못해 온디바이스에서는 기본적으로 꺼져 있으며, 이를 순이득으로 만드는 것이 향후 커널 과제입니다.

벤치마크와 지능 밀도

모든 벤치마크는 EvalScope 와 vLLM 백엔드를 NVIDIA H100에서 동일한 인프라, 디코딩, 채점 조건으로 실행하여, 관측된 차이가 평가 방식이 아니라 표현 방식에서 비롯되도록 통제했습니다. 지식과 사고, 수학, 코딩, 명령 따르기, 에이전트형 도구 호출, 비전에 걸친 15개 벤치마크의 평균을 사고 모드(thinking mode)에서 측정했습니다. 사고 모드는 모델의 사고 능력이 온전히 발휘되고 4비트 미만의 붕괴가 가장 뚜렷하게 드러나는 조건입니다.

변형	실제 bpw	발자국	사고 모드 평균	FP16 대비
Qwen3.6-27B FP16	16.0	54 GB	85.07	100\%
Qwen3.6-27B Q4_K_XL ("4비트")	5.2	17.6 GB	84.99	99.9\%
Qwen3.6-27B IQ2_XXS ("2비트")	2.8	9.4 GB	72.73	85.5\%
Gemma-4-31B FP16	16.0	61.5 GB	84.58	99.4\%
Gemma-4-31B Q2_K_XL ("2비트")	3.0	11.8 GB	73.31	86.2\%
Ternary Bonsai 27B	1.71	5.9 GB	80.49	94.6\%
1-bit Bonsai 27B	1.125	3.9 GB	76.11	89.5\%

5.9 GB의 Ternary Bonsai 27B는 FP16 기준선의 94.6\% 를 유지하는데, 이는 그 발자국의 3분의 2도 안 되는 크기로 기존 IQ2_XXS 빌드(85.5\%)를 앞지르는 수치입니다. 3.9 GB의 1-bit Bonsai 27B도 89.5\% 를 지킵니다. 비교를 위해 함께 실은 Gemma-4-31B 계열은 다른 기반 모델에서도 동일한 구조를 보여, 4비트 아래의 붕괴가 특정 모델이 아니라 방식 자체의 속성 임을 확인해 줍니다.

평균이 감추는 선택적 붕괴

집계 평균은 기존 빌드가 어떻게 실패하는지를 오히려 과소평가합니다. 이들의 열화는 균일하지 않고, 지속적인 사고 연쇄를 요구하는 벤치마크에 집중적으로 나타나기 때문입니다. IQ2_XXS 는 MMLU-Redux에서 88.93 점을 유지하면서도 AIME26에서는 57.5, LiveCodeBench에서는 56.4 로 무너집니다. Gemma의 Q2_K_XL 역시 AIME25에서 58.2, \tau^2-Bench에서 53.2 로 같은 서명을 보입니다. 반면 Bonsai 모델은 그 절반에서 3분의 1 크기로 바로 이 벤치마크들을 지켜냅니다. 삼진 모델은 AIME를 87.5 에서 90.8 사이로 유지하고, 1비트 모델조차 AIME에서 87 점을 넘깁니다. 짧은 형식의 벤치마크가 이 차이를 가리기 때문에 가벼운 테스트로는 붕괴를 놓치기 쉽고, 그래서 이 보고서는 핵심 주장을 집계 유창성이 아니라 장문 사고와 도구 사용, 에이전트 행동 위에 세웁니다.

능력 범주별로 나누어 보면 이야기가 더 선명해집니다.

범주 (벤치마크)	FP16	Ternary 27B	1-bit 27B
지식 및 사고 (MMLU-Redux, MuSR)	83.15	76.96	73.39
수학 (GSM8K, MATH-500, AIME25, AIME26)	95.33	93.40	91.66
코딩 (HumanEval+, MBPP+, LiveCodeBench)	88.74	85.96	81.88
명령 따르기 (IFEval, IFBench)	78.47	71.77	65.74
에이전트/도구 호출 (BFCL v3, \tau-Bench)	80.00	74.01	66.03
비전 (MMMU-Pro, OCR Bench v2)	72.61	65.19	59.57
전체 (15개)	85.07	80.49	76.11

사고의 중추가 온전히 살아남는다는 점이 핵심입니다. Ternary Bonsai는 수학을 완전 정밀도에서 두 점 이내인 93.40, 코딩을 85.96 으로 유지하고, 1비트 모델조차 수학 91.66, 코딩 81.88 을 지킵니다. 압축은 자연히 가장 까다로운 범주인 에이전트형 도구 사용, 명령 따르기, 비전에서 가장 많은 것을 요구하며, 바로 여기서 두 변형이 갈립니다. 삼진은 여분의 발자국을 써서 도구 사용을 74.01, 비전을 65.19 로 붙잡고, 1비트 모델은 그 여유의 일부(66.03 과 59.57)를 내주는 대신 27B 모델을 스마트폰에 올리는 더 작은 발자국을 얻습니다. 이 계열은 하나의 타협이 아니라 노트북급 품질(삼진)과 스마트폰급 발자국(이진)이라는 두 개의 의도된 운영 지점으로 읽힙니다.

지능 밀도(Intelligence Density)

이 연구는 1-bit Bonsai 8B 백서에서 도입한 지능 밀도 개념을 이어받습니다. 저장 공간 단위당 지능을 뜻하며, 평균 벤치마크 점수로부터 오류 확률 P_e = 1 - \frac{\text{평균 점수}}{100} 를 정의하고, 지능을 -\log_2(P_e) 로 측정한 뒤 다음과 같이 밀도를 계산합니다.

D = \frac{-\log_2(P_e)}{N}

여기서 N 은 GB 단위의 모델 크기입니다.

지능 밀도는 모델이 얼마나 잘하느냐가 아니라 기가바이트당 얼마나 많은 지능을 전달하느냐를 묻습니다. 크기로 나누기 때문에 이진과 삼진 표현의 가파른 발자국 감소가 곧바로 보상받고, 원점수 대신 -\log_2(P_e) 를 측정하므로 단순히 살아남는 것이 아니라 오류를 낮게 유지하는 데 점수를 줍니다. 격차는 결정적입니다. 1-bit Bonsai 27B는 0.530 에 이르러 가장 조밀한 기존 빌드(Q2_XXS 의 0.199)의 약 2.7\times, FP16의 10\times 이상을 기록하고, Ternary Bonsai 27B는 0.400 에 도달합니다. Qwen3.6-27B든 Gemma-4-31B든 어떤 기존 빌드도 0.2 를 넘지 못합니다. 이는 8B 규모에서 처음 입증된 밀도 우위가 27B로 확장된 것으로, 단지 작아서가 아니라 저장된 기가바이트 하나하나를 훨씬 더 쓸모 있는 지능으로 번역해 낸다는 것을 뜻합니다.

활용 사례

Bonsai 27B가 이룬 압축은 그동안 훨씬 작은 모델에만 허용되던 배포 시나리오를 열어젖힙니다. 관통하는 아이디어는 하나입니다. "27B급 지능이 이제 사용자와 데이터가 이미 있는 그곳에서 살 수 있다" 는 것입니다.

노트북 로컬 27B 에이전트: 약 7.2 GB로 배포되는 Ternary Bonsai 27B는 일반 맥북과 노트북에 넉넉히 들어맞아, $262$K 토큰 컨텍스트로 긴 문서 분석과 저장소 전체 코드 작업을 온디바이스에서 수행합니다. 프롬프트와 출력이 기기를 벗어나지 않고, 매 단계 클라우드 왕복 없이 반복적 에이전트 워크플로가 실용적으로 돌아갑니다.
스마트폰 로컬 27B 사고: 약 3.9 GB의 1-bit Bonsai 27B는 iPhone 17 Pro Max의 메모리 예산 안에 들어맞습니다. KV 캐시 양자화에 유난히 강건한 덕분에 짧은 단발성 프롬프트에 그치지 않고 수만 토큰의 다중 턴 컨텍스트를 온디바이스에서 유지합니다.
프라이버시 민감 및 오프라인 환경: 온디바이스 실행은 데이터가 기기를 벗어나지 않음을 구조적으로 보장하므로, 프롬프트와 문서를 기기 밖으로 내보낼 수 없는 기업, 규제, 개인 데이터 워크플로에 적합합니다.
단일 GPU 서빙: 줄어든 발자국 덕분에 27B 모델을 소비자용 또는 엔트리급 데이터센터 GPU 한 장으로 서빙할 수 있으며, 4비트 KV 캐시와 결합하면 단일 24 GB GPU에서 고처리량 서빙과 긴 컨텍스트 문서 분석이 가능해집니다.

한계점 및 향후 계획

연구팀은 한계를 솔직하게 밝힙니다.

품질과 발자국의 상충: 삼진과 이진은 완전 정밀도 평균의 94.6\% 와 89.5\% 를 유지하지만 남는 격차는 존재합니다. 다만 그 차이는 예측 가능하며 사고 핵심(수학, 코딩)은 기준선에서 몇 점 이내에 머뭅니다. 마지막 몇 점의 정확도가 필요하고 발자국이 제약이 아닌 경우에는 완전 정밀도 모델을 쓸 수 있습니다.
에이전트형 코딩: 다중 파일 편집, 실행 후 수정 루프, 저장소 규모의 지속적 사고 같은 장기 도구 주도 소프트웨어 엔지니어링은 이번 릴리스가 아직 강하게 겨냥하지 않은 영역이며, 이를 위해 튜닝한 Bonsai 27B 변형이 다음 로드맵입니다.
네이티브 저비트 커널: 오늘날 삼진 배포는 각 값을 2비트 슬롯에 저장하므로 배포 발자국(약 7.2 GB)이 정보 이론적 최솟값(약 5.9 GB)보다 큽니다. 네이티브 1비트 및 삼진 커널은 활발한 엔지니어링 과제입니다.
극단적 KV 압축: 이번 릴리스는 4비트 KV 캐시를 표준으로 삼지만, Bonsai 모델의 캐시 내성 여유는 컨텍스트 길이가 늘수록 커지며 2비트 미만 영역으로도 여지가 큽니다.

결론적으로 Bonsai 27B는 엣지의 정의를 다시 씁니다. 지금까지 27B급 지능은 클라우드로 요청을 보내거나 비현실적인 로컬 장비에 의존해야만 했습니다. Bonsai 27B는 이 짝지음을 깨고, 사고와 도구 사용, 에이전트 능력을 갖춘 프론티어급 모델을 사용자와 데이터가 이미 있는 바로 그 기기 안에 놓습니다. PrismML은 지능 밀도가 다음 단계 AI 발전의 결정적 축 중 하나가 될 것이라고 전망합니다. 원초적 능력이 모델이 무엇을 할 수 있는지를 정한다면, 밀도는 그것을 어디서 할 수 있는지를 정하기 때문입니다.

설치 및 사용 방법

Bonsai-demo 저장소 를 이용하면 Mac(Metal), Linux/Windows(CUDA, Vulkan, ROCm), CPU에서 Bonsai 및 Ternary-Bonsai 모델을 로컬로 실행할 수 있습니다. 기본값은 Ternary-Bonsai-27B이며, 두 개의 명령으로 채팅과 비전, 도구 호출을 갖춘 서버가 뜹니다.

git clone https://github.com/PrismML-Eng/Bonsai-demo.git
cd Bonsai-demo

# (선택) 모델 크기 지정: 27B(기본값), 8B, 4B, 1.7B
export BONSAI_MODEL=27B

# 의존성 설치, 모델 및 바이너리 다운로드까지 한 번에
./setup.sh

# 채팅 UI 서버 실행 (http://localhost:8080)
./scripts/start_llama_server.sh

BONSAI_FAMILY 로 삼진(ternary, 기본값)과 1비트(bonsai) 계열을, BONSAI_MODEL 로 크기를 자유롭게 조합할 수 있습니다. 1비트 형식 Q1_0 은 llama.cpp 메인라인에 이미 병합되어 CPU, Metal, CUDA, Vulkan에서 바로 동작하고, 삼진 형식 Q2_0 은 CPU와 Metal이 메인라인에 병합되었으며 Vulkan은 검토 중입니다. Apple Silicon용 MLX와 웹 브라우저에서 WebGPU로 실행하는 경로도 함께 공개되어 있습니다.

Bonsai 27B 백서 (Whitepaper)

Announcing Bonsai 27B 발표 블로그

Bonsai 공식 문서 (Documentation)

Bonsai-demo GitHub 저장소

Bonsai 27B Collection (Hugging Face)

Bonsai 27B WebGPU Kernels (브라우저에서 실행)

더 읽어보기

이 글은 GPT 모델로 정리한 글을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 덧글로 알려주시기를 부탁드립니다.

파이토치 한국 사용자 모임이 정리한 이 글이 유용하셨나요? 회원으로 가입하시면 주요 글들을 이메일로 보내드립니다! 텔레그램(Telegram)이나 Slack/Discord/Teams/Dooray/GoogleChat 등으로도 새 글 알림을 받으실 수 있습니다.

아래쪽에 좋아요를 눌러주시면 새로운 소식들을 정리하고 공유하는데 힘이 됩니다~