이 기사에서 알 수 있는 것

"27B 클래스의 모델이 iPhone에서 구동된다"라는 뉴스를 보고, 막상 시도해 보려고 HuggingFace를 열면 다음과 같은 벽에 부딪힙니다.

Bonsai-27B와 Ternary-Bonsai-27B라는 2가지 계통이 있어서 어떤 것을 사용해야 할지 모르겠다 -
추가로 -gguf, -mlx-1bit, -mlx-2bit, -AWQ-4bit와 같이 파생형이 많아, 어느 것이 자신의 디바이스용인지 판단할 수 없다 - "3.9GB", "5.9GB", "7.17GB"와 같이 사이즈 표기가 소스마다 달라 혼란스럽다

이 기사는 PrismML이 2026년 7월 14일에 공개한 Bonsai 27B 패밀리에 대해, "명명 규칙의 축"과 "변체(variant) 선택 방법"을 먼저 정리합니다. 그 후 llama.cpp / MLX / iPhone 각각에서의 도입 절차, 메모리 설계, 벤치마크 읽는 법까지 일관되게 정리합니다.

"Bonsai 27B"는 두 가지가 있다 — 먼저 명명을 정리하자

처음 맞닥뜨리는 난관이 바로 여기입니다. Bonsai-27B와 Ternary-Bonsai-27B는 사이즈 차이나 버전 차이가 아니라, "가중치 양자화 방식(weight quantization method)"의 차이를 의미합니다.

출처: PrismML 공식 / MarkTechPost

즉, 기억해야 할 점은 단 하나입니다.

Ternary-가 붙는다 = 삼치 양자화 (Ternary Quantization) = 정밀도 우선 (조금 더 무거움). 붙지 않는 Bonsai-27B = 1-bit = 최경량 (정밀도가 조금 떨어짐).

왜 "Bonsai (분재)"인가

둘 다 원래는 Qwen3.6-27B (27B급 파라미터의 멀티모달 모델)입니다. 이를 새로 학습시킨 것이 아니라, 후양자화 (post-training quantization)를 통해 극한까지 작게 만든 파생 모델입니다. 큰 나무(27B)를 화분에 담길 수 있는 크기로 전정(剪定)한다는 비유가 이름의 유래입니다.

전제 지식: 왜 초저비트 양자화가 필요한가

27B 모델은 16-bit 정밀도 (FP16)일 때 약 54GB의 메모리를 사용합니다. 4-bit로 양자화해도 약 18GB이며, 이는 하이엔드 GPU에서도 버겁고 스마트폰에서는 불가능한 수준입니다.

Bonsai 27B가 목표로 한 것은 이 벽을 "가중치 하나당 1~2bit"까지 깎아내는 것입니다.

• 1-bit 버전: 3.9GB → iPhone 17 Pro의 앱 사용 가능 메모리 범위 (약 6GB) 내에 KV 캐시(KV cache)나 활성화(activation)를 포함해도 들어가는 최초의 27B급 모델
• Ternary 버전: 5.9GB → 노트북 (통합 메모리가 풍부한 Mac 등)에서 정밀도를 유지하며 구동 가능

단순히 "2-bit로 압축"하는 것만으로는 평균 점수는 유지할 수 있어도, 어려운 태스크 (수학 · 코딩)에서 선택적으로 붕괴됩니다. Bonsai는 이러한 붕괴를 피하기 위한 삼치/1-bit 설계를 주장하고 있으며, 이 점이 "단순한 소형 양자화 모델"과의 차별점입니다 (상세 내용은 후술할 벤치마크 섹션 참고).

설정 및 기본 사용법

도입 방법은 3가지 경로

경로 1: llama.cpp (gguf)

# 모델 다운로드
hf download prism-ml/Ternary-Bonsai-27B-gguf Ternary-Bonsai-27B-Q2_0.gguf --local-dir .
# 전용 fork 빌드 (CUDA)
...

권장 샘플링은 temp 0.7 / top-p 0.95 / top-k 20 (gguf model card)입니다.

경로 2: MLX (Apple Silicon)

pip install --upgrade mlx-lm
# 대화 모드
mlx_lm.chat --model "prism-ml/Bonsai-27B-mlx-1bit"
...

Python에서 사용할 경우:

from mlx_lm import load, generate
model, tokenizer = load("prism-ml/Bonsai-27B-mlx-1bit")
messages = [{"role": "user", "content": "아인슈타인에 대한 이야기를 써줘"}]
...

경로 3: Bonsai-demo (가장 빠르게 구동)

우선 실행해보고 싶다면, 공식 통합 데모가 가장 빠릅니다.

git clone https://github.com/PrismML-Eng/Bonsai-demo.git
cd Bonsai-demo
./setup.sh # 의존성 도입 · 모델 DL · 바이너리 취득 · MLX 빌드 · Open WebUI
...

Windows는 setup.ps1 / start_llama_server.ps1을 사용합니다. 의존성은 Python 3.10+, uv, cmake, ninja, huggingface-cli (선택 사항으로 CUDA toolkit / Vulkan SDK)입니다 (Bonsai-demo README).

5가지 변체(Variant) 선택 패턴 — 디바이스별 치트 시트

Bonsai 27B에서 가장 고민되는 부분은 "결국 무엇을 설치할 것인가"입니다. 디바이스와 목적에 따라 역으로 찾아볼 수 있도록 5가지 패턴으로 정리했습니다.

Bonsai-27B-mlx-1bit (단일 선택)

패턴 1: iPhone에서 구동하고 싶다 → iPhone 17 Pro / Pro Max (RAM 12GB, 앱 이용 가능 범위 약 6GB)에서 유일하게 메모리에 들어가는 것이 1-bit MLX 버전입니다.

• 간편한 경로: iOS 앱 **「Locally AI」**에서 Bonsai 27B를 선택 (여러 매체에서 소개, 9to5Mac)
• 직접 빌드: PrismML의 mlx-swift fork로 mlx-1bit를 온디바이스(On-device) 실행

Ternary-Bonsai-27B-mlx-2bit

패턴 2: Mac (통합 메모리 풍부)에서 정밀도 우선 → M5 Pro / Max 클래스라면 삼진(Ternary) 버전이 여유롭게 돌아갑니다. 정밀도 유지율 94.6%를 활용할 수 있습니다.

Ternary-Bonsai-27B-gguf

패턴 3: NVIDIA GPU / Linux → CUDA 빌드의 llama.cpp fork로 구동하는 정석 구성. RTX 5090에서 삼진 버전 134 tok/s (후술).

*-AWQ-4bit

패턴 4: GPU 서버 · vLLM 계열 → prism-ml/Ternary-Bonsai-27B-AWQ-4bit / Bonsai-27B-AWQ-4bit는 서버 추론용입니다. 저비트(Low-bit)에 집착하지 않고 처리량(Throughput)을 확보하고 싶은 경우에 적합합니다.

*-unpacked

패턴 5: 재양자화 · 연구 용도 → *-unpacked는 전개(Unpacked) 버전으로, 직접 재양자화를 하거나 내부를 조사하고 싶은 연구자용입니다.

공식 벤치마크로 보는 베스트 프랙티스

PrismML은 15개 벤치마크 스위트 (6개 도메인)에서 FP16 베이스라인과의 대비를 공개하고 있습니다. 이를 통해 "어떤 변체를 어디까지 신뢰해도 되는지" 알 수 있습니다.

Ternary는 FP16의 94.6%, 1-bit는 89.5%를 유지합니다.

도메인별 스코어 (FP16 기준과의 대비)

권장 1: 정밀도가 필요한 태스크는 Ternary, 가벼움이 최우선이면 1-bit

위 표에서 알 수 있듯이, 1-bit는 Agentic/tool calling에서 66.03(FP16=80)으로 격차가 매우 큽니다. 도구 호출(tool calling)이나 에이전트 용도로 사용한다면 망설임 없이 Ternary를 선택하십시오. 1-bit는 「스마트폰에서 구동된다는 것 자체에 가치가 있는」 용도로 한정하는 것이 안전합니다.

권장 2: 「평균 점수」에 속지 마라

단순한 2-bit 양자화(IQ2_XXS 등)는 MMLU-Redux와 같은 지식 벤치마크에서는 88.93으로 높게 유지되지만, AIME26=57.5 / LiveCodeBench=56.4와 같이 어려운 태스크에서는 성능이 붕괴됩니다. Bonsai의 Ternary/1-bit는 이러한 선택적 붕괴를 피하도록 설계된 것이 특징입니다. 양자화 모델을 평가할 때는 평균이 아니라 어려운 벤치마크(수학·코딩)를 보는 것이 철칙입니다.

권장 3: 멀티모달(Multimodal)도 사용 가능

vision tower(0.46B)를 **4-bit (HQQ)**로 동봉하여 이미지 입력에 대응합니다. 데모 채팅 UI에 이미지를 업로드하면 자동으로 로드됩니다. 컨텍스트(Context)는 최대 262K입니다.

자주 하는 안티 패턴 7가지

1. iPhone에 mlx-2bit(7.2GB)를 넣으려고 시도함

2. 본래의 llama.cpp에서 gguf를 구동하려고 시도함

Ternary/1-bit의 독자적인 포맷에 대응하지 못할 가능성이 높으므로, PrismML fork가 필수적입니다. 본래 버전에서 빌드하다가 「읽어올 수 없다」며 어려움을 겪는 사례가 빈번합니다.

3. 긴 컨텍스트에서 KV 캐시 압축을 사용하지 않음

100K 토큰을 다룰 경우, Ternary에서도 피크(Peak) 14.7GB급까지 부풀어 오릅니다. BONSAI_KV4=1 (4-bit KV 캐시)를 설정하는 것만으로도 대폭 절감할 수 있습니다(후술).

4. Agentic 용도로 1-bit를 선택함

벤치마크 결과처럼 1-bit는 도구 호출 능력이 약합니다. 정밀도가 필요한 용도에서 「가벼우니까」라는 이유로 1-bit를 선택하면 에이전트가 제대로 작동하지 않습니다.

5. 「5.9GB / 3.9GB」를 실제 파일 크기라고 오해함

이론적인 footprint와 실제 배포 파일은 별개입니다. 디스크 및 대역폭 추정은 모델 카드에 명시된 실제 수치(gguf 7.17GB 등)를 기준으로 하십시오.

6. 「Bonsai Studio」 앱을 LLM 실행 환경이라고 생각함

앞서 언급했듯이 이는 이미지 생성 앱입니다. LLM 실행은 「Locally AI」나 자체적인 MLX 빌드를 사용합니다.

7. Ollama에서 돌아간다고 단정 짓고 절차를 찾아 헤맴

메모리 설계 최적값 — 컨텍스트 길이에 따라

모델 본체의 크기뿐만 아니라, 컨텍스트 길이에 따른 KV 캐시가 메모리를 압박합니다.

Ternary-Bonsai-27B (footprint ~7.2GB)

Bonsai-27B 1-bit (footprint ~3.9GB)

추론 속도 (tok/s)

iPhone에서는 「배터리 1%당 약 672 토큰」, 16-bit 대비 4~5배의 에너지 효율이라는 수치도 공개되어 있습니다(공식).

가속화 옵션

BONSAI_SPECULATIVE=1 (DSpark drafter를 병용한 투기적 디코딩(Speculative Decoding))을 사용하면, CUDA 환경에서의 디코딩(decode) 속도가 약 1.8~2배 빨라집니다.

관련 모델·포맷 비교

실전 체크리스트

모델 선정 시

• 디바이스를 확인했는가 (iPhone → mlx-1bit 한 길뿐)
• 용도를 확인했는가 (에이전트/도구 호출 (Tool calling) → Ternary)
• 다운로드 전에 모델 카드의 실제 파일 크기를 확인했는가
• gguf라면 PrismML fork를 사용하는 것을 전제로 이해했는가

설정 (Setup) 시

• llama.cpp는 github.com/PrismML-Eng/llama.cpp (fork)를 클론했는가
• MLX는 pip install --upgrade mlx-lm을 실행했는가
• 27B 리포지토리 다운로드 시 403 에러가 발생하면 BONSAI_TOKEN (HF 토큰)을 설정했는가

운용 시

• 긴 컨텍스트 (Long context)를 다룬다면 BONSAI_KV4=1을 추가했는가
• 샘플링 (Sampling)은 temp 0.7 / top-p 0.95 / top-k 20을 기준으로 했는가
• 에이전트 용도로 1-bit를 사용하고 있지는 않은지 재검토했는가

요약

• 요점 1: Ternary-Bonsai-27B = 삼진법(Ternary) · 정확도 우선 (94.6% 유지), Bonsai-27B = 1-bit · 최경량 (89.5%). 명명 기준은 "양자화 방식"입니다.
• 요점 2: iPhone에서 구동되는 것은 mlx-1bit 뿐입니다. mlx-2bit는 메모리 용량 초과로 들어가지 않습니다.
• 요점 3: 에이전트/도구 호출 등 정확도가 필요한 용도는 반드시 Ternary를 사용하세요. 1-bit는 "가벼움이 정의"인 용도로 한정합니다.
• 요점 4: "5.9GB/3.9GB"는 이론치이며, 실제 파일은 7.17GB 등입니다. 긴 컨텍스트는 BONSAI_KV4=1로 메모리를 억제합니다.
• 요점 5: Ollama 대응은 공식적으로 확인되지 않았습니다. 도입은 llama.cpp (fork) / MLX / Bonsai-demo가 정석입니다.

27B급 모델이 스마트폰 주머니 속에 들어가는 시대가 2026년 7월에 현실이 되었습니다. 변체(Variant)가 너무 많아 혼란스럽다면, 이 기사의 "디바이스별 치트 시트"로 돌아오세요.

참고 링크

Discussion