PrismML이 1.58비트 가중치를 쓰는 Ternary Bonsai 모델군을 공개했다. 8B, 4B, 1.7B 세 가지 크기이며, 핵심 메시지는 단순하다. "더 작은 파일"이 아니라, 16비트 모델이 너무 무거운 환경에서 성능과 배포 가능성의 균형점을 다시 그리겠다는 시도다.1
지금 이게 중요한 이유는 벤치마크 점수 하나 때문이 아니다. 로컬 AI 사용자는 늘 같은 질문 앞에 선다. "이 모델이 대단한가?"보다 "내 맥북, 아이폰, 소형 GPU, 혹은 엣지 장비에서 실제로 더 나은 선택인가?"가 더 중요하다. Ternary Bonsai는 그 질문에 새 기준을 던진다.
진짜 비교 대상은 '대형 모델'이 아니라 작은 dense 모델과 4bit·8bit 모델이다
공식 발표 기준으로 Ternary Bonsai 8B는 약 1.75GB 메모리 풋프린트에 평균 벤치마크 75.5를 기록했고, 이전 1-bit Bonsai 8B보다 5포인트 높다. 대신 메모리는 약 600MB 더 든다.1 Hugging Face 모델 카드는 배포 형식 기준 packed 2-bit 크기를 2.15GiB(2.30GB)로 적고 있어, "1.58비트"와 "실제 파일 크기"는 구분해서 봐야 한다고 설명한다.2
여기서 실무적으로 중요한 건, 이 모델의 경쟁 상대가 꼭 FP16 8B만은 아니라는 점이다. 예를 들어 사용자가 실제로 고민하는 선택지는 보통 셋 중 하나다.
첫째, 더 작은 dense 모델을 그냥 돌린다.
둘째, 기존 8B 계열을 4bit나 GGUF로 양자화해 쓴다.
셋째, 처음부터 초저비트 구조로 설계된 ternary 모델을 쓴다.
Ternary Bonsai가 유리한 쪽은 "8B급 추론 성향은 유지하고 싶지만, 16GB 안팎 메모리는 감당 못 하는 경우"다. 반대로 작업이 단순 질의응답 위주이거나, 이미 잘 최적화된 4bit 4B 모델로 충분한 환경이라면 굳이 새 포맷의 생태계 리스크를 떠안을 이유는 약해진다.
즉, 이 모델은 "무조건 최고"가 아니라 "메모리 예산이 빡빡한데 너무 많이 다운사이징하고 싶지 않은 사람"에게 맞는 카드에 가깝다.
1.58비트가 곧바로 모든 병목을 해결해주진 않는다
PrismML은 Ternary Bonsai를 "진짜 ternary 모델"로 소개한다. 임베딩, 어텐션, MLP, LM head까지 전부 {-1, 0, +1} 기반 표현을 쓰고, 128개 가중치마다 FP16 스케일을 공유한다.1 이건 사후 압축 체크포인트와 다른 접근이다.
하지만 여기서 오해하면 안 되는 부분이 있다. 가중치가 작아지면 VRAM 부담은 줄지만, 시스템 전체가 똑같이 줄어드는 것은 아니다. 긴 컨텍스트를 쓰면 KV 캐시와 활성값 메모리가 다시 커지고, 속도는 커널 최적화와 런타임 지원에 크게 좌우된다. 실제로 현재 공개 자료에서 가장 강한 플랫폼 지원은 Apple의 MLX 쪽이다. 공식 모델 카드도 초기 한계로 "출시 시점에는 MLX 2-bit 포맷만 제공"된다고 적고 있다.2
이 점은 꽤 중요하다. 같은 모델이라도 어디서 돌리느냐에 따라 체감 가치가 달라진다. Apple Silicon에서는 M4 Pro 기준 생성 속도 약 83 tok/s, iPhone 17 Pro Max 기준 27 tok/s 수치가 제시됐다.12 반면 비-Apple 환경은 아직 "모델이 좋다"와 "내 장비에서 쉽게 빠르게 돈다" 사이에 간극이 남아 있다. 제3자 Jetson Orin 실험도 ternary 모델의 정확도는 인상적이지만, 속도는 런타임 성숙도 영향을 크게 받는다고 분명히 적고 있다.3
요컨대 1.58비트의 진짜 가치는 "항상 더 빠름"이 아니라 "메모리 제약을 크게 낮추면서도 품질 손실을 상대적으로 억제할 가능성"이다.
어디서 먼저 이길까: 온디바이스 보조도구와 배치형 작업
이 계열이 먼저 빛날 곳은 뚜렷하다. 맥북·아이폰 같은 Apple 기기에서 오프라인 보조도구를 만들거나, 작은 메모리 안에서 여러 모델 인스턴스를 띄워야 하는 경우다. 메모리당 성능, 전력 효율, 배포 단순성이 중요한 워크로드에서 이점이 크다.12
특히 "항상 최고 품질"보다 "로컬에서 충분히 괜찮고 빨라야 함"이 중요한 제품에 맞는다. 예를 들어 사내 문서 요약, 오프라인 개인 비서, 현장 장비용 음성/텍스트 보조, 또는 배치 처리형 에이전트다. 이런 환경에서는 16비트 8B가 아예 안 들어가거나, 들어가도 발열·전력·지연 때문에 운영이 어렵다.
반대로 장문 컨텍스트 품질, 복잡한 툴 사용 안정성, 다국어 강건성, CUDA 생태계의 즉시성까지 중요하다면 아직은 보수적으로 봐야 한다. 공개 자료의 강점은 주로 표준 벤치마크와 Apple 실행 수치에 집중돼 있고, 장시간 에이전트 운용이나 다양한 런타임 간 일관성은 더 검증이 필요하다. 이건 모델의 약점이라기보다, 새 포맷이 늘 겪는 초기 생태계 문제에 가깝다.
다음 저비트 모델을 볼 때는 '압축률'보다 이 다섯 가지를 보자
앞으로 1비트, 1.58비트, 2비트 계열 발표는 더 많아질 가능성이 크다. 그때는 숫자 하나보다 체크리스트가 필요하다.
첫째, 실제 배포 포맷 크기. 이론상 비트 수와 디스크·메모리 실사용은 다를 수 있다.2
둘째, 지원 런타임. MLX만 되는지, GGUF나 CUDA 스택이 안정적인지 봐야 한다.2
셋째, 긴 컨텍스트와 KV 캐시 비용. 가중치가 작아도 전체 메모리 문제는 끝나지 않는다.
넷째, 작업 유형별 성능. 수학, 코드, 툴 호출, 다국어는 손실 양상이 다르다.13
다섯째, throughput per watt. 로컬 AI는 종종 "최고 점수"보다 "지속 가능한 속도"가 더 중요하다.1
결론은 간단하다. Ternary Bonsai는 모델 출시 뉴스라기보다 로컬 AI의 의사결정 기준이 바뀌는 신호에 가깝다. 지금 당장 신경 써야 할 사람은 Apple 기기에서 온디바이스 AI를 만들려는 개발자, 제한된 VRAM으로 8B급 품질을 최대한 유지하려는 로컬 사용자, 그리고 "작은 모델이면 곧 약한 모델"이라는 전제를 다시 검토해야 하는 팀이다. 앞으로의 판단 기준은 압축 그 자체가 아니라, 압축이 실제 배포 전략을 얼마나 바꾸는가다.
참고
1Ternary Bonsai: Top Intelligence at 1.58 Bits
2prism-ml/Ternary-Bonsai-8B-mlx-2bit · Hugging Face
3GitHub - ArmanJR/PrismML-Bonsai-vs-Qwen3.5-Benchmark: PrismMl Bonsai vs Qwen3.5 Benchmark · GitHub
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.