Technical Assessment

Bonsai 27B, 진짜로 쓸 수 있는 물건인가

PrismML의 1-bit / Ternary Qwen3.6-27B를 상용 API 및 로컬 대안과 비교한 현실 평가

작성일 2026-08-12 대상 모델 prism-ml/bonsai-27b 기준 하드웨어 RTX 5060 Ti 16GB

결론부터 — 세 줄

01이게 대체 뭔가

먼저 오해부터 걷어내자. Bonsai 27B는 새로 학습한 모델이 아니다.

PrismML(Caltech 출신, Khosla·Google·Samsung 투자)이 2026년 7월 14일에 낸 것은 알리바바 Qwen3.6-27B의 사후 극단 양자화 빌드다. 임베딩·어텐션·MLP·LM 헤드까지 언어 네트워크 전체를 1-bit 또는 ternary로 밀어붙였고, 고정밀 예외 구간을 두지 않았다. 비전 타워만 따로 4-bit NF4로 처리한다.

이게 왜 중요하냐면 — BitNet처럼 처음부터 저비트로 사전학습한 게 아니라 이미 학습된 FP16 모델을 사후에 눌러 담은 쪽이라는 뜻이다. 문헌상 극단 비트폭에서는 네이티브 사전학습이 사후 양자화보다 유리한데, Bonsai는 어려운 쪽을 택하고도 숫자를 뽑았다. 대신 열화가 균일하지 않다. 원래 모델이 정밀도를 가장 많이 쓰던 능력이 제일 크게 깎인다. 이게 이 보고서의 핵심이다.

표 1. 두 변형의 실측 스펙. 업계는 ternary를 "1.58-bit"로 부르지만 FP16 그룹 스케일 비용을 치르면 실제는 1.71bit다. PrismML은 이론값이 아닌 실측값을 공개했다 — 작지만 진짜 신뢰 신호.
변형가중치 표현실효 bit/weight파일 크기평균 유지율
Ternary Bonsai 27B {−1, 0, +1} + FP16 g128 스케일 1.715.9 GB94.6%
1-bit Bonsai 27B {−1, +1} + 그룹 스케일 1.1253.9 GB89.5%
Qwen3.6-27B FP16 (기준) FP1616~54 GB100%

따라온 것 (아키텍처 상속)

  • 262K 컨텍스트 — 양자화 트릭 아님. Qwen3.6의 하이브리드 어텐션(~75% linear) 덕분
  • 비전 입력 (mmproj +0.9GiB 별도)
  • Thinking 모드 / 하이브리드 추론
  • 툴 콜 학습됨

PrismML이 추가한 것

  • llama.cpp 커스텀 저비트 커널 (CUDA·Metal)
  • MLX 네이티브 빌드 (Apple Silicon·iPhone)
  • DSpark 투기적 디코딩 드래프터 — 무손실 1.34~1.37배
  • 4-bit KV 캐시 옵션
  • Apache 2.0 — 상업 배포 가능

02어디가 무너지는가 — 평균 뒤에 숨은 표

모든 기사가 "95% 유지"만 쓰고 넘어간다. 카테고리별로 쪼개면 이야기가 완전히 달라진다.

표 2. PrismML 자체 15개 벤치마크(thinking 모드), EvalScope + vLLM on H100. 상대 열화율은 FP16 기준 계산.
카테고리 Qwen3.6 27B Ternary 1-bit Ternary 열화 1-bit 열화
수학 GSM8K·MATH-500·AIME 95.393.491.7 −2.0%−3.8%
코딩 HumanEval+·MBPP+·LCB 88.786.081.9 −3.0%−7.7%
지식/STEM MMLU-Redux·MuSR 83.177.073.4 −7.3%−11.7%
에이전트·툴콜 BFCL v3·TauBench 80.074.066.0 −7.5%−17.5%
지시 이행 IFEval·IFBench 78.471.865.8 −8.4%−16.1%
비전 MMMU Pro·OCRBench 72.665.259.6 −10.2%−17.9%
전체 평균 (15개) 85.080.576.1 −5.3%−10.5%
수학은 −2%인데 비전은 −10%, 1-bit에서는 −18%. 같은 모델 안에서 열화율이 5배 넘게 벌어진다. "95% 유지"는 통계적으로 참이지만 의사결정 근거로는 쓸모없는 숫자다.

왜 이런 패턴이 나오는가

수학과 코드는 중복성이 강한 구조다. "2+2=4"에 도달하는 내부 경로가 여러 개라, 정밀도를 깎아도 우아하게 열화한다. 반면 툴콜·지시이행·OCR은 정밀 판별(fine discrimination) 문제다. 비슷하게 생긴 함수 여럿 중 정확히 하나를 고르고, 인자 이름을 한 글자도 안 틀리게 JSON으로 뱉어야 한다. get_weather(city=…)get_forecast(location=…)는 의미적으로 이웃이고 기능적으로 완전히 다르다. 근사 정답 = 완전 실패인 영역이다.

양자화는 미세한 구분을 뭉갠다. 그리고 미세한 구분이 그 작업의 전부다. 인과 설명은 PrismML이 공개한 게 아니라 합리적 추론이지만, 행동하는 데엔 숫자만 있으면 충분하다.

덜 알려진 두 가지

비전이 최악이다

대부분의 리뷰는 툴콜(−17.5%)만 지적하는데, 상대 열화율 1위는 비전(−17.9%)이다. 게다가 원래 점수 자체가 72.6으로 제일 낮았다. 언어 가중치는 ternary인데 비전 타워는 4-bit — 비트폭이 다르니 열화 특성도 다르고, 세부 비전 벤치는 공개되지 않았다. "멀티모달 플래그십"이 헤드라인인데 정작 그 능력이 가장 약하다. 측정 전까지 비전은 미검증으로 취급해라.

지시 이행도 같이 무너진다

IFEval·IFBench가 78.4 → 71.8 → 65.8. ternary에서 이미 −8.4%로 툴콜(−7.5%)보다 더 나쁘다. 이건 "JSON으로만 답해", "3줄 이내로", "마크다운 쓰지 마" 같은 출력 포맷 제약을 지키는 능력이다. 파이프라인에 파서 물려놓고 쓰는 사람한텐 툴콜만큼 치명적인데 아무도 언급 안 한다.

03네 하드웨어 기준 — RTX 5060 Ti 16GB

1-bit은 볼 필요 없다. 3.9GB가 의미를 갖는 건 iPhone처럼 물리 메모리의 절반만 앱에 주는 환경뿐이다. 16GB VRAM을 갖고 있으면서 2GB 아끼자고 툴콜 8점, 비전 5.6점, 지시이행 6점을 버리는 건 그냥 손해다. 선택지는 Ternary 하나다.

진짜 함정은 가중치가 아니라 KV 캐시다

5.9GB 보고 "8GB면 되겠네" 하면 262K 컨텍스트 쓰는 순간 프로세스가 죽는다.

표 3. Ternary 기준 피크 메모리(FP16 KV 캐시). 가중치는 두 행 모두 5.9GB로 고정 — 늘어나는 건 KV 캐시다.
컨텍스트 길이피크 메모리16GB VRAM 여유
4K~7.8 GiB넉넉
100K~13.7 GiB아슬아슬 — KV4 필수
262K (최대)추정 20GiB+KV4 없이는 불가

우선순위는 명확하다. ternary ↔ 1-bit 선택은 2GB를 벌어주지만, KV 캐시 설정은 100K에서 6GiB를 벌어준다. 가중치 타협하기 전에 KV부터 잡아라.

export BONSAI_MODEL=27B
export BONSAI_FAMILY=ternary
export BONSAI_TOKEN="hf_..."        # 27B 리포는 게이트됨. 사전 승인 필요

BONSAI_KV4=1 ./scripts/start_llama_server.sh          # 4-bit KV — 1일차부터 켜라
BONSAI_SPECULATIVE=1 ./scripts/start_llama_server.sh  # CUDA 투기적 디코딩 1.34x
./scripts/start_llama_server.sh --reasoning-budget 2048  # thinking 토큰 상한

먼저 알아둘 것

27B 리포지토리는 Hugging Face 게이트가 걸려 있다. 8B·4B·1.7B는 토큰 없이 받아지지만 27B는 접근 요청이 필요하다. "받아서 5분 만에 돌린다"는 승인 이후에만 참이다. 급하면 Together AI에 무료 API가 올라와 있으니 다운로드 전에 거기서 한국어부터 찔러보는 게 순서다.

속도 추정

공식 수치는 RTX 5090에서 ternary 134 tok/s, 1-bit 163 tok/s. 5090의 메모리 대역폭이 ~1792GB/s이고 5060 Ti가 ~448GB/s이니 대역폭 비례로 보면 대략 40~55 tok/s 정도가 현실적 기대치다(투기적 디코딩 포함 시 상단). 실측이 아니라 외삽이니 그대로 믿지 말고 직접 재라. 참고로 M5 Max는 ternary 58 tok/s, iPhone 17 Pro는 1-bit 11 tok/s — 폰에서 도는 건 사실이지만 11 tok/s는 천천히 읽는 속도다. 데모용이지 대화용이 아니다.

04상용 API와 비교하면

여기서부터가 진짜 판단이 갈리는 지점이다. Bonsai의 세일즈 포인트 중 하나가 "에이전트 루프의 한계 비용이 0"인데, 2026년 8월 토큰 가격을 보면 그 논리가 잘 안 선다.

표 4. 2026년 8월 기준 API 단가(100만 토큰당 USD). Claude Sonnet 5는 8/31까지 도입가이며 9/1부터 $3/$15로 환원된다. 벤치 점수 체계가 서로 다르니 절대 비교가 아닌 대략적 티어 참고용.
모델입력출력티어
Qwen3.7 Flash$0.03$0.13최저가
DeepSeek V4-Flash$0.14$0.28저가·1M 컨텍스트
Gemini 3.5 Flash-Lite$0.30$2.50중저가
Claude Sonnet 5$2.00$10.00프로덕션급
Claude Opus 4.8$5.00$25.00프론티어
GPT-5.6 Sol$5.00$30.00프론티어
Ternary Bonsai 27B (로컬)전기료아래 계산

전기료로 환산하면

RTX 5060 Ti 16GB 로컬 추론 실비 (추정)

Qwen3.7 Flash 출력 100만 토큰이 $0.13. 네 GPU 전기료가 $0.22. GPU 구매비(약 80만원)와 네 시간은 아직 세지도 않았다. 2026년 가격 환경에서 "로컬이 싸다"는 명제는 죽었다.

그러니 로컬을 선택하는 이유는 비용이 아니라 딱 세 가지로 좁혀진다.

  1. 프라이버시 — 데이터가 기기 밖으로 안 나간다. 계약상·법적으로 외부 전송이 막힌 워크로드에서는 가격표 자체가 무의미하다. 이게 압도적 1번 이유다.
  2. 오프라인·폐쇄망. 현장 게이트웨이, 인터넷 없는 환경, 망분리 고객사.
  3. 과금 없는 무제한 반복. 실험적으로 100만 번 돌려도 청구서가 안 온다는 심리적 자유. 실비는 비슷해도 예측 가능하다.

품질 격차의 실제 크기

Ternary Bonsai의 전체 평균 80.5는 나쁘지 않은 숫자다. 문제는 에이전트에서 오차가 곱해진다는 점이다. 툴콜 74.0을 스텝당 성공률로 거칠게 대입하면 5스텝 루프의 종단 성공률은 0.74⁵ ≈ 22%다. 1-bit(66.0)이면 12%로 떨어진다. 벤치 점수와 실제 스텝 성공률이 1:1은 아니지만 방향은 정확하다.

그리고 양자화된 모델은 거부하지 않는다. 자신 있게 부정확해진다. 맞는 함수에 미묘하게 틀린 인자를 넣고, 트레이스는 초록불이고, 결과만 조용히 잘못된다. 검증 레이어 없는 로컬 에이전트는 사고를 은닉하는 장치다.

05아무도 측정 안 한 것 — 한국어

최대 리스크

15개 벤치마크가 전부 영어권이다. GSM8K, MATH-500, AIME, HumanEval+, MBPP+, LiveCodeBench, BFCL, TauBench, IFEval, MMLU-Redux, MuSR, MMMU Pro, OCRBench — 한국어 평가가 단 하나도 없다.

극단 저비트 양자화가 가장 먼저 깎아내는 건 저빈도 표현과 비주류 언어 능력이다. 위 표에서 확인한 대로 열화는 "정밀 판별"이 필요한 곳에 집중되는데, 한국어 어미·조사·존댓말 체계는 정확히 그런 종류의 미세 구분이다. Qwen3.6의 학습 분포에서 한국어는 영어·중국어 대비 소수 언어다. 1.71bit로 눌렀을 때 한국어가 얼마나 남아있는지는 지금 지구상 누구도 공개 데이터로 답할 수 없다.

마음일벌 텍스트 처리나 한국어 리포트 생성에 쓸 생각이면, 이건 도입 여부를 가르는 단일 최대 변수다. 다운로드보다 측정이 먼저다.

06현실적 용도 판정

쓸 만하다

  • 프라이버시 강제 문서 처리 — 고객사 로그, 개인정보 포함 데이터. 외부 전송이 금지된 순간 API 단가는 무의미해지고 Bonsai가 유일 선택지가 된다
  • 262K 장문 요약·추출 — API 입력 토큰 청구가 진짜 아픈 구간. 문서 수십 개를 반복 스캔하는 작업
  • 배치 분류·태깅·정규화 — 지시 이행 열화가 걱정되지만 출력 스키마를 단순하게 잡으면 커버 가능
  • 코드 리뷰·설명·단일 파일 생성 — 코딩 86.0은 ternary에서 거의 안 깎였다. 자율 루프가 아닌 단발 질의는 충분
  • 오프라인 데모·영업 임팩트 — "이거 지금 인터넷 끊고 돌아갑니다"는 여전히 강한 카드
  • Apache 2.0 — 법무 상의 없이 상업 배포 가능

쓰지 마라

  • Cline 같은 자율 에이전트 루프 — 5스텝 종단 22%. 툴콜은 클라우드로 라우팅해라
  • 사용자 대면 프로덕션 품질 — 80.5는 내부용 점수지 고객 앞에 내놓을 점수가 아니다
  • 한국어 정밀 작업 — 자체 측정 전까지 전면 보류
  • 비전 기반 실무 — 65.2에 세부 벤치 미공개. 상대 열화 1위
  • 폰 배포 — 11 tok/s는 백그라운드 요약용이지 채팅 UI가 아니다
  • 비용 절감이 도입 명분인 경우 — 3장 계산 참조. 명분이 안 선다
  • IoT 게이트웨이 온디바이스 — 5.9GB + KV 캐시를 감당할 엣지 하드웨어가 사실상 없다. Bonsai 4B/1.7B 쪽을 봐라

07권장 액션

  1. 다운로드 전에 Together AI 무료 API로 한국어부터 때려봐라. 20분이면 도입 여부의 80%가 결정된다. 27B HF 리포는 게이트라 승인 기다리는 시간도 아낄 수 있다.
  2. 받는다면 Ternary GGUF 하나만. 16GB VRAM에서 1-bit은 순손실이다.
  3. BONSAI_KV4=1을 1일차에 박아라. 튜닝 순서를 바꾸면 100K에서 OOM으로 하루 날린다.
  4. 네 툴 스키마로 직접 BFCL을 대신해라. llama.cpp 서버가 OpenAI 호환이니 기존 SDK 코드를 localhost:8080/v1로 돌리면 끝. 벤치의 74.0이 너한테 낙관인지 비관인지가 나온다. 함수 이름이 서로 비슷하면 이름부터 최대한 다르게 바꿔라 — 흐릿해진 모델이 미세 구분을 하도록 돕는 건 공짜 정확도다.
  5. Qwen3 14B의 대체가 아니라 역할 분담으로 넣어라. 5.9GB에 27B급 추론이 들어오는 건 밀도상 명백한 이득이지만, Cline 자율 루프는 지금 쓰는 GLM/Claude 유지. Bonsai는 설명·리뷰·장문 요약·프라이버시 배치 담당.
  6. 하이브리드 라우팅을 처음부터 설계해라. 로컬에서 스키마 검증 → 실패 시 클라우드 1회 재시도. ternary 74.0이면 대략 넷 중 하나가 이 경로를 탄다. 감당 가능한 비율인데, 경로가 존재할 때만 그렇다. 없으면 틀린 답이 200 OK를 달고 나간다.

한 문장 요약

Bonsai 27B는 "싼 모델"이 아니라 "밀도가 미친 모델"이다. 클라우드 API보다 저렴해서 쓰는 게 아니라, 데이터를 기기 밖으로 내보낼 수 없을 때 27B급 추론을 5.9GB에 담아 쓸 수 있다는 사실이 유일하고 충분한 도입 명분이다. 그 조건이 아니라면 Qwen3.7 Flash 쓰는 게 모든 면에서 낫다.