1비트로 풀정밀도 따라잡았다는 8B 모델 — 후기 글들이 좀 이상함
1.15GB짜리 8B 모델 Bonsai 8B가 풀정밀도와 동급이라는 영문 후기 글들이 한 다스쯤 도는 중인데, 공식 모델 카드 숫자와 대조하면 일부 셀이 어긋나고 빠진 디테일도 보임. Qwen3 베이스라는 점, 실제로는 1.125비트라는 점, 한국어 약점 가능성까지 한 번 짚어봤음.
1비트로 가중치를 압축한 8B 모델이 풀정밀도 16비트 모델 벤치를 따라잡았다는 후기 글이 영문권에 한 다스쯤 도는 중. 1.15GB짜리 모델이 Llama 3.1 8B를 잡고 Olmo 3 7B와 동급이라는 결론들. 진짜라면 엣지 AI 판이 한 번 흔들리는 게 맞아요. 근데 "I tested" "I benchmarked" 톤으로 떠도는 후기 글들 숫자를 PrismML 공식 모델 카드와 한 줄씩 대조해보니 살짝 어긋나는 셀이 있고, 후기 글들이 빼먹은 디테일이 두어 개 보임. 한 박자 끊고 정리해두려고 함.
본문 들어가기 전에 자주 나올 표현 한 호흡으로. 양자화(quantization)는 보통 학습 끝난 모델의 가중치를 더 적은 비트로 압축하는 후처리 작업인데, Bonsai는 처음부터 1비트 제약 안에서 학습한 점이 다름. 모델 파일 형식으로 GGUF는 llama.cpp 계열에서 쓰는 포맷이고, MLX는 애플 실리콘 전용 추론 프레임워크. "엣지 AI"는 클라우드 안 거치고 디바이스 — 폰, 노트북, 임베디드 — 위에서 직접 돌리는 AI를 말함.
공식 자료로 확인되는 사실
- Caltech 출신 Babak Hassibi 교수가 공동 창업한 PrismML이 3월 말 스텔스에서 나옴
- Khosla Ventures, Cerberus, Google이 약 1,625만 달러 시드 투자
- 1비트 Bonsai 8B가 1.15GB, FP16 기준 14배 압축
- Apache 2.0 라이선스로 PrismML 공식 사이트와 Hugging Face에 GGUF·MLX 빌드 둘 다 공개. 1.7B / 4B 변형도 같이 있음
여기까지는 검증 가능. 회사 공식 자료에 다 박혀 있음.
후기 글들 숫자가 살짝 어긋남
문제는 영문권 후기 글들. "내가 직접 6개 벤치를 5개 모델에 돌려봤다"는 톤으로 표를 박아놓은 케이스들이 있는데, 표 안의 숫자를 공식 모델 카드와 한 줄씩 대조하면 미묘하게 안 맞음.
예를 들어 한 글은 Bonsai 8B의 HumanEval+를 57.9로 적어놨는데, 공식 카드에는 73.8로 나옴. MuSR도 후기는 64.3, 공식은 50 — 14점 차이남. 평균(70.5)과 IFEval(79.8), GSM8K(88.0)는 일치하는데 일부 셀만 어긋나는 패턴.
이게 진짜로 본인이 다른 평가 환경에서 다시 잰 거면 정상이긴 한데, 그럼 환경 디테일이 글에 있어야 정상임. vLLM 버전, 시드, 프롬프트 템플릿, 평가 하네스 — 공식 카드는 "EvalScope v1.4.2 + vLLM 0.15.1 on NVIDIA H100"이라고 명시함. 후기 글에 그런 디테일 없이 "I tested" 톤만 있으면 일단 거리두고 봐야 함. 본인 측정인지 회사 발표를 적당히 옮긴 건지 구분 안 가니까.
이게 1비트 Bonsai 자체의 문제는 아니에요. 큐레이션 글들이 회사 발표 숫자를 자기 측정처럼 옮기는 패턴 자체에 대한 거리두기가 필요하다는 얘기.
Qwen3 베이스라는 사실은 후기에 빠짐
공식 모델 카드에 명확히 적혀 있는 한 줄: "Architecture: Qwen3-8B dense". 즉 Bonsai는 처음부터 새로 설계한 아키텍처가 아니라 Qwen3 8B 아키텍처를 베이스로 1비트 학습 방법론을 적용한 것. GQA 32/8 헤드 구성, SwiGLU, RoPE, RMSNorm — Qwen3 그대로. vocab 151,936에 chat template도 Qwen 계열.
이게 폄하할 일은 아님. 오히려 합리적인 선택이고, 1비트 학습 자체가 어려운 작업이라 검증된 베이스를 쓰는 게 자연스러움. 다만 후기 글 일부에서 "trained from scratch with 1-bit constraints baked in" 같은 표현으로 모호하게 처리한 부분은 좀 짚어둘 만함. 진짜 from scratch면 토크나이저랑 vocab부터 새로 짠다는 얘긴데, 둘 다 Qwen3 그대로 쓰면서 from scratch라고 부르는 건 마케팅 어휘에 가까워요.
"1비트"는 실제로는 1.125비트
공식 카드에 박혀 있는 또 한 줄: "Effective bits per weight: 1.125". 가중치 자체는 1비트(부호만 +1/-1)인데 128개 그룹마다 FP16 스케일 인자 하나씩 따로 저장하니까 평균치는 1비트보다 살짝 위. Microsoft BitNet b1.58이 1.58비트라고 정직하게 부르는 거랑 비교하면 표현이 묘함. "1비트"가 임팩트 있으니까 그렇게 부르는 마케팅 선택인 듯.
추가로 카드의 한계 섹션에 한 줄 더 있음: "No native 1-bit hardware exists yet — current gains are software-kernel optimizations on general-purpose hardware." FP16 곱셈을 ±부호 처리로 대체해서 메모리/전력 절감하는 거지 진짜 1비트 전용 칩이 따로 있는 게 아님. 이론적 최대치는 1비트 네이티브 하드웨어 나오면 더 올라간다는 얘긴데, 그건 시간이 좀 걸릴 듯.
한국어는 어떨까
한국 개발자 입장에서 가장 결정적인 질문. 공식 자료 어디에도 한국어 성능 벤치는 없음. 학습 데이터 구성도 자세히 안 적혀 있음. Qwen3 베이스이긴 한데 1비트 제약 안에서 다시 학습하는 과정에서 다국어 능력이 어떻게 보존됐는지 — 이건 직접 돌려봐야 알 수 있음.
안 깔아봐서 정확한 건 모르는데, 8B 1비트 모델에서 다국어 품질이 풀정밀도 Qwen3 8B와 동등할 가능성은 별로 없어 보여요. 1비트 압축은 표현력의 절대 상한을 깎는 작업이고, 다국어 능력처럼 데이터 비중이 작은 영역이 먼저 무너지는 게 일반적인 양자화 손실 패턴이거든요. 한국어로 사이드 프로젝트 짜는 입장에선 잠재적인 빨간불.
내 경우 aickyway 쪽에서 한국어 → 영어 프롬프트 다듬기처럼 좁은 단방향 작업에 작은 LLM이 필요한데, 그런 협소한 use case면 시도해볼 만함. 한국어 입력 → 한국어 출력 풀 파이프라인에는 지금 단계에선 못 쓸 듯.
한계
- 직접 돌려본 적 없음. RTX 3090에 GGUF 띄우는 건 가능하지만 한국어 테스트 결과가 어떻게 나오든 학습 데이터 비중 문제라 1비트 자체의 성능 평가로 보긴 어려워서 일단 보류
- 후기 글 숫자가 어긋나는 게 의도적인지 평가 환경 차이인지 단정 못 함. 그냥 의심스럽다 정도까지만
- 1.7B / 4B 작은 변형은 더 안 만져봤음. 작은 모델일수록 다국어가 더 약해질 가능성이 큼
- "엣지 AI 게임체인저" 류 결론은 충분히 시간 두고 봐야 함. 지금은 첫 발표 1개월 시점
잡담
1비트 LLM 같은 압축 기법이 발전해도 한국어 학습 비중이 작은 모델은 한국 개발자 손에 잘 안 들어옴. 이게 한국어로 사이드 프로젝트 짜는 입장에서 늘 한 박자 늦는 이유. 큰 회사들이 다국어 모델 내놓을 때까지 기다리거나, 아니면 한국 안에서 비슷한 압축 기법 시도하는 팀이 나와줘야 하는데 자본 규모가 다르니 시간이 걸리겠죠. 그래도 한 회사가 길을 뚫어놓으면 다른 데가 따라가는 게 보통이라, 흐름은 계속 봐둘 가치 있음.
마무리
정리. 1.15GB로 8B 모델 돌리는 거 자체는 진짜고 의미 있는 발표임. 다만 영문권 "I tested" 글들의 일부 숫자가 공식 자료와 어긋나는 점, Qwen3 베이스라는 사실이 모호하게 처리된 점, "1비트"가 실제로는 1.125비트인 점은 한 박자 끊고 봐야 함. 한국 개발자가 당장 자기 한국어 서비스에 끼울 모델은 아니에요. 그래도 양산 1비트 모델 시대가 진짜 열리면 한국어 잘하는 후속작이 따라 나올 가능성도 같이 열리는 거니까, 흐름은 계속 봐둘 가치 있음.
다음 글에서는 Bonsai 8B를 RTX 3090에 GGUF로 띄워서 한국어 응답 품질을 간단히 보는 글을 쓸 예정. 진짜로 돌리는 거니까 B 유형으로.
댓글
NEXT_PUBLIC_GISCUS_*환경변수 구성 필요)