Ternary 양자화로 27B 모델을 7GB에 담아 로컬 추론하기

로컬에서 큰 언어모델을 돌릴 때 진짜 걸림돌은 연산량이 아니라 메모리다. 27B 모델을 FP16으로 올리면 그것만으로 50GB를 넘기고, 흔한 INT4 양자화로 줄여도 여전히 소비자용 GPU 한 장을 넘어서기 일쑤다. 더 공격적으로 2비트까지 내리면 이번엔 모델이 눈에 띄게 멍청해진다. Prism ML이 공개한 Ternary Bonsai 27B는 이 트레이드오프를 다른 각도에서 공격한다. 가중치를 아예 세 값만 갖게 만들어서, 27B급 추론 능력을 7GB 안에 눌러 담았다.

Ternary 양자화란 무엇인가

일반적인 정수 양자화가 가중치를 4비트나 8비트 정수로 반올림하는 것과 달리, ternary 양자화는 가중치를 {-1, 0, +1} 세 값 중 하나로만 표현한다. Bonsai 27B는 이걸 GGUF Q2_0_g128 포맷으로 구현했는데, 128개 가중치 묶음마다 FP16 스케일 팩터 하나를 공유하는 구조다. 정보이론적으로는 가중치 하나당 약 1.71비트면 충분하고, 이게 임베딩·어텐션 프로젝션·MLP 프로젝션·LM 헤드까지 전부 적용돼 FP16 대비 9.4배 축소된다.

베이스는 Qwen3.6-27B 하이브리드 어텐션 모델(약 75% 선형 어텐션, 25% 전체 어텐션)이고, 컨텍스트 길이는 262K 토큰까지 지원한다.

무엇을 얼마나 희생하는가

핵심은 이 축소가 공짜가 아니라는 걸 숫자로 보여준다는 점이다. 15개 벤치마크 평균으로 FP16이 85.07점일 때 Ternary Bonsai는 80.49점, 즉 94.6%를 유지한다. 같은 27B를 단순 2비트(IQ2_XXS)로 내린 버전은 72.73점까지 떨어진다. ternary 방식이 같은 비트 예산에서 훨씬 덜 잃는다는 뜻이다.

분야	FP16	Ternary 27B
수학	95.33	93.40
코딩	88.74	85.96
에이전트/도구 사용	80.00	74.01
비전	72.61	65.19

수학·코딩은 손실이 작지만 에이전트/도구 사용과 비전은 상대적으로 더 깎인다. 어떤 작업에 쓸지 고를 때 참고할 지점이다.

실제로 돌리는 법

llama.cpp 기반으로 동작하며, CUDA 빌드는 다음과 같다.

git clone https://github.com/PrismML-Eng/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON && cmake --build build -j
hf download prism-ml/Ternary-Bonsai-27B-gguf Ternary-Bonsai-27B-Q2_0.gguf
./build/bin/llama-cli -m Ternary-Bonsai-27B-Q2_0.gguf \
  -p "질문..." -n 256 --temp 0.7 --top-p 0.95 -ngl 99

서버로 띄우거나 Python에서 쓰고 싶다면:

from llama_cpp import Llama

llm = Llama.from_pretrained(
    repo_id="prism-ml/Ternary-Bonsai-27B-gguf",
    filename="Ternary-Bonsai-27B-F16.gguf"
)
llm.create_chat_completion(messages=[{"role": "user", "content": "질문"}])

Ollama, LM Studio, Jan, vLLM, Apple Silicon용 MLX 백엔드도 지원한다. 권장 생성 파라미터는 temperature 0.7, top-p 0.95, top-k 20이다.

배포 크기와 하드웨어 요구사항

언어모델 본체(Q2_0)만 필요하면 7.17GB로 끝난다. 추측 디코딩용 DSpark 드래프터(Q4_1, 1.95GB)를 얹으면 CUDA에서 디코딩 속도가 1.34배 빨라지고, 이미지 입력이 필요할 때만 비전 타워(HQQ 4-bit, 0.63GB)를 추가로 받으면 된다.

처리량은 단일 배치 128토큰 생성 기준 Apple M5 Pro 26.2 tok/s, M5 Max 44.0 tok/s, H100 98.0 tok/s다. 메모리는 4비트 KV 캐시를 쓰면 100K 컨텍스트에서도 10.1GB로 버틸 수 있다(FP16 캐시면 14.7GB).

한계

모델 카드가 스스로 밝히는 한계도 뚜렷하다. 7.2GB는 iOS의 6GB 메모리 예산을 넘어서 휴대폰에서는 아직 못 돌리고, 1비트 버전을 대신 권한다. 2비트 슬롯에 3진 값을 욱여넣는 방식이라 배포 크기가 이상적인 5.9GB보다 크며, 네이티브 ternary 커널은 아직 개발 중이다. 그리고 표에서 보이듯 에이전트/도구 사용 능력은 FP16의 74%까지만 유지되므로, 여러 파일을 오가는 장기 에이전틱 코딩 워크플로우에는 아직 강점이 아니다.

결국 이 모델이 잘 맞는 자리는 분명하다. GPU 한 장 없이도 27B급 수학·코딩 추론을 로컬에서 돌리고 싶을 때이고, 복잡한 다단계 에이전트 작업이라면 다른 선택지를 함께 고려하는 게 낫다.