1-Bit Bonsai: 최초의 상업적으로 실용 가능한 1-Bit LLM 출시
Show HN: 1-Bit Bonsai, the First Commercially Viable 1-Bit LLMs
TL;DR Highlight
PrismML이 1-bit 가중치 기반의 Bonsai LLM 시리즈(8B/4B/1.7B)를 공개했다. 기존 16-bit 모델 대비 메모리 14배 절감, 속도 8배 향상, 에너지 5배 절약을 달성하면서도 벤치마크 성능은 유사하다고 주장한다.
Who Should Read
스마트폰, 로봇, IoT 등 엣지 디바이스에 LLM을 올려야 하는 개발자, 또는 서버 비용과 에너지 소비를 줄이고 싶은 AI 인프라 엔지니어.
Core Mechanics
- PrismML이 1-bit 가중치(각 128비트 그룹마다 16-bit 스케일 팩터를 공유하는 방식, 실제로는 약 1.125-bit)를 사용한 Bonsai 모델 시리즈 세 가지를 출시했다. 8B, 4B, 1.7B 파라미터 규모로 제공된다.
- Bonsai 8B는 메모리 1.15GB만 필요하다. 일반 16-bit FP 8B 모델이 보통 16GB 내외를 쓰는 것과 비교하면 14배 작고, 속도는 8배 빠르며 에너지는 5배 덜 쓴다고 주장한다. IFEval, GSM8K, HumanEval+, BFCL, MuSR, MMLU-Redux 등 여러 벤치마크에서 기존 8B 모델과 유사한 성능을 보였다.
- Bonsai 4B는 0.57GB, Bonsai 1.7B는 0.24GB로 더 작다. 1.7B 모델은 iPhone 17 Pro Max에서 130 tokens/s를 달성한다고 밝혔고, 4B는 M4 Pro에서 132 tokens/s를 기록했다.
- 모델은 Caltech의 연구를 바탕으로 개발됐으며, 'intelligence density(지능 밀도)'라는 새로운 지표를 도입했다. 이는 모델의 오류율의 음의 로그값을 모델 크기로 나눈 값으로, 단순 파라미터 수가 아닌 '비트당 지능'을 측정하려는 시도다.
- 모델 파일은 llama.cpp 호환 GGUF 포맷으로 배포된다. RTX 3090 기준으로 8B 모델이 4GiB VRAM만 사용하면서 700토큰 입력 시 약 190 tokens/s, 6400토큰 입력 시 약 135 tokens/s로 동작한다는 실측 수치가 커뮤니티에서 공유됐다.
- 커뮤니티에서는 이 모델이 Qwen3을 기반으로 커스텀 양자화 커널을 적용한 것 아니냐는 의혹을 제기했다. 실제로 화이트페이퍼가 다른 양자화 모델(INT4 등)과의 비교 없이 full-precision 모델과만 비교한 점을 문제로 지적하는 댓글이 있었다.
- 로보틱스나 실시간 에이전트용으로 설계됐다고 밝혔다. iPhone 앱(Locally AI)을 통해 온디바이스 실행이 가능하며, Cursor 같은 코드 에디터와 연동한 tool use도 동작하는 것이 확인됐다.
Evidence
- 한 사용자가 Bonsai 8B를 Cursor에 연결해 tool use를 테스트했는데, 몬테카를로 파이 시뮬레이션 로직은 맞게 짰지만 UI 생성에서 실패하고 불필요한 기호가 남아 수동 수정이 필요했다는 경험을 공유했다. 전반적으로 '이 크기치고는 인상적이지만 완벽하진 않다'는 평이었다.
- SQL 디버깅 에이전트 벤치마크를 직접 돌려본 사용자가 25문제 중 8개 정답(17 오류)을 얻었다고 보고했다. Qwen3.5-4B(7/25)보다 약간 낫고 Nanbeige4.1-3B(9/25)보다는 약간 부족하지만, 테스트 전체 시간은 200초로 Qwen3.5(976초)나 Nanbeige(2000초+)보다 훨씬 빨랐다. Granite 7B 4bit는 199초로 속도는 비슷하지만 정확도(4/25)가 훨씬 낮았다.
- 이 모델이 '1-bit 목표로 처음부터 학습(trained from scratch)'된 건지, 아니면 기존 float 모델을 사후 양자화(post-training quantization)한 건지가 핵심이라는 의견이 있었다. 전자라면 Microsoft BitNet처럼 진정한 의미의 1-bit 모델이고, 후자라면 그냥 공격적인 양자화일 뿐이라는 지적이다. 화이트페이퍼가 같은 메모리 풋프린트의 다른 양자화 모델(예: 양자화된 Qwen3)과 비교하지 않은 점이 의심스럽다는 댓글도 있었다.
- CPU 전용 구형 2018 랩탑에서 기본 llama.cpp 포크로 돌리면 0.6 tokens/s밖에 안 나왔지만, AVX2(CPU의 병렬 연산 명령어셋) 최적화가 구현되지 않아서임을 확인하고 직접 추가했더니 12 tokens/s까지 올라갔다는 경험이 공유됐다. 공식 CPU 커널에 AVX2 지원이 빠진 것은 아직 최적화가 덜 됐다는 신호다.
- Harry Potter 지식 테스트를 해봤더니 'Sirius Black이 James Potter의 아버지'이고 'James Potter는 Harry의 삼촌이자 Luna Lovegood의 형제'라는 완전히 틀린 답을 자신 있게 내놨다는 사례가 공유됐다. 사실 확인이 필요한 작업에서 환각(hallucination)이 발생한다는 경고다.
How to Apply
- 스마트폰 앱에 온디바이스 AI 기능을 붙이고 싶다면, Locally AI 앱(iOS)에서 Bonsai 1.7B(0.24GB)를 설정에서 다운로드해 테스트할 수 있다. 구형 iPhone SE2에서도 읽는 속도의 절반 정도로 동작한다는 실사용 보고가 있으므로, 일단 체험해보고 정확도가 허용 범위인지 확인하라.
- llama.cpp 기반 로컬 서버를 운영 중이라면 GGUF 포맷의 Bonsai-8B.gguf를 다운로드해 기존 서버에 그대로 올릴 수 있다. RTX 3090에서 4GiB VRAM만 쓰면서 --parallel 5, --cont-batching 옵션으로 5개 동시 요청을 처리할 수 있어 GPU 비용 절감 효과를 바로 측정해볼 수 있다.
- RAG 파이프라인이나 에이전트에서 전처리(오타 교정, 입력 정제) 단계에 소형 모델을 쓰고 싶다면, Bonsai 1.7B나 4B를 경량 필터로 활용하는 구조를 검토할 수 있다. 한 사용자가 NYT 기사 문단을 교정하는 테스트에서 좋은 결과를 얻었다고 보고했다.
- 이 모델을 메인 추론 모델로 채택하기 전에, 본인 서비스의 태스크(특히 멀티스텝 추론, 사실 확인이 필요한 작업)에 대한 자체 벤치마크를 반드시 돌려보라. 공식 벤치마크는 full-precision 모델과만 비교했고, 같은 메모리 크기의 INT4 양자화 모델과의 비교가 없어 실제 우위를 확인해야 한다.
Code Example
snippet
# llama.cpp 서버로 Bonsai 8B 실행하는 예시 (커뮤니티 공유)
./build/bin/llama-server \
-m ../Bonsai-8B.gguf \
-ngl 999 \
--flash-attn on \
--host 0.0.0.0 \
--port 80 \
--ctx-size 65500 \
--batch-size 512 \
--ubatch-size 512 \
--parallel 5 \
--cont-batching \
--threads 8 \
--threads-batch 8 \
--cache-type-k q4_0 \
--cache-type-v q4_0 \
--log-colors on
# 결과: RTX 3090 기준 VRAM 4GiB 사용
# 700토큰 입력 → ~190 tokens/s
# 6400토큰 입력 → ~135 tokens/sTerminology
1-bit 가중치신경망의 각 파라미터(가중치)를 -1 또는 +1 두 값만으로 저장하는 방식. 일반 모델이 32비트나 16비트 소수점 숫자를 쓰는 것에 비해 저장 공간을 극단적으로 줄일 수 있다.
post-training quantization이미 학습이 끝난 모델의 가중치를 사후에 낮은 비트 수로 압축하는 기법. 처음부터 낮은 비트로 학습하는 것보다 정확도 손실이 클 수 있다.
GGUFllama.cpp에서 사용하는 모델 파일 포맷. 다양한 양자화 설정을 하나의 파일에 담을 수 있어 로컬 추론에 널리 쓰인다.
AVX2Intel/AMD CPU의 고급 명령어셋으로, 한 번에 여러 데이터를 병렬 처리(SIMD)할 수 있게 해준다. 이 최적화가 없으면 CPU 추론 속도가 20배 이상 느려질 수 있다.
intelligence densityPrismML이 도입한 지표로, 모델 오류율의 음의 로그값을 모델 크기로 나눈 값. '단위 메모리당 얼마나 정확한가'를 측정하려는 개념이다.
cont-batchingllama.cpp의 연속 배치 처리 기능. 여러 요청이 동시에 들어올 때 완료된 슬롯에 즉시 새 요청을 채워 GPU 활용률을 높이는 방식이다.