1-bit/Ternary Bonsai Image 4B: 로컬 디바이스용 이미지 생성 모델
1-Bit Bonsai Image 4B Image Generation for Local Devices
TL;DR Highlight
4B 파라미터 이미지 생성 모델의 가중치를 1비트/3값으로 극단적으로 압축해서 iPhone에서도 돌아가게 만든 모델. 7.75GB짜리 diffusion transformer를 0.93GB까지 줄였다.
Who Should Read
모바일/엣지 디바이스에서 이미지 생성 기능을 구현하고 싶은 iOS/macOS 앱 개발자, 또는 로컬 AI 추론 최적화에 관심 있는 ML 엔지니어.
Core Mechanics
- PrismML이 공개한 Bonsai Image 4B는 FLUX.2 Klein 4B 아키텍처를 그대로 유지하면서 transformer 가중치만 1-bit({-1, +1}) 또는 Ternary({-1, 0, +1})로 바꾼 모델이다.
- 1-bit 변형은 유효 비트 수가 1.125 bits/weight, Ternary 변형은 1.71 bits/weight로, 원본 FP16 대비 각각 8.3x, 6.4x 용량이 줄었다. 구체적으로 diffusion transformer가 7.75GB → 0.93GB(1-bit), 1.21GB(Ternary)가 됐다.
- 정밀도에 민감한 projection layer 약 5%는 FP16으로 유지했고, text encoder는 추론 후 offload하는 방식을 사용해서 실제 런타임 메모리를 더 줄였다.
- Apple Silicon 기준 전체 배포 페이로드는 1-bit가 3.42GB, Ternary가 3.88GB인데, 원본 FLUX.2 Klein 4B는 15.97GB다. 512x512 이미지 생성 시 mean-active memory는 각각 1.5GB, 1.96GB(원본 11.74GB)다.
- iPhone 17 Pro Max에서 512x512 이미지를 약 9.4초, Mac M4 Pro에서 약 6초에 생성한다. Mac M4 Pro 기준으로 full-precision MFLUX 파이프라인보다 최대 5.6배 빠르다.
- 배포 스택은 Apple Silicon(iPhone, iPad, Mac)과 CUDA GPU를 모두 지원한다. Apple 하드웨어는 MLX low-bit 경로를, CUDA는 Gemlite low-bit GEMM 커널을 사용한다.
- 성능 평가는 GenEval(객체 구성/속성 바인딩), HPSv3(인간 선호도/미적 품질), DPG-Bench(dense prompt 따르기/의미 충실도) 세 가지 벤치마크로 진행했다.
- 회사 측 주장으로는 '이 파라미터 클래스에서 iPhone에서 직접 돌아가는 최초의 이미지 모델'이라고 하지만, 커뮤니티에서는 FLUX.2 Klein 4B가 이미 Draw Things 앱으로 iPhone에서 8-bit/6-bit 양자화로 돌아간다며 이 주장의 정확성을 문제삼고 있다.
Evidence
- '이 파라미터 클래스에서 iPhone에서 직접 돌아가는 최초의 이미지 모델'이라는 주장에 대해, Draw Things 앱을 통해 FLUX.2 Klein 4B(동일 파라미터 클래스, 사실상 같은 모델)가 이미 8-bit/6-bit 양자화로 iPhone에서 돌아간다는 반박이 있었다. 다만 '직접(directly)'이라는 단어로 빠져나갈 여지를 만들었다는 지적도 있었다.
- Stable Diffusion XL 3.5B나 리파이너 모델도 iPhone 13 Pro에서 돌아간다는 댓글도 있어, '최초' 주장의 근거가 더욱 흔들렸다.
- 실제 bottleneck은 메모리가 아니라 생성 속도라는 의견이 있었다. 8-12GB VRAM의 1080 세대 GPU나 동급 Mac에서 이미 많은 모델이 돌아가고, 이 모델이 기반 모델인 FLUX.2보다 오히려 조금 느리다는 점을 들어 실용적 필요성에 의문을 제기했다.
- 텍스트 인코더가 1.8GB인데, 이 부분을 압축하지 않으면 결국 총 용량 절감 효과가 제한적이라는 지적이 있었다. 실제로 전체 배포 페이로드(3.42~3.88GB)를 보면 diffusion transformer 외 나머지 부분이 상당한 비중을 차지한다.
- 미래에는 고가 구독 서비스 대신 하드웨어를 업그레이드해서 로컬 AI를 쓰는 시대가 오길 기대한다는 감성적 반응도 있었고, 로컬 실행 가능한 모델이 늘어날수록 일반 사용자들이 스스로 선택권을 요구하게 될 것이라는 의견도 있었다.
How to Apply
- iOS/macOS 앱에 이미지 생성 기능을 추가하고 싶은데 메모리 제약이 걸린다면, Bonsai Image 4B Ternary 변형(3.88GB 페이로드)을 MLX 백엔드로 통합하면 iPhone 17 Pro Max급 기기에서 512x512를 약 9.4초에 생성할 수 있다.
- CUDA GPU 환경에서 경량 이미지 생성 서버를 운영한다면 Gemlite low-bit GEMM 커널을 사용하는 Bonsai Image 4B를 적용해 GPU 메모리 사용량을 원본 대비 최대 7.4x 줄이고 더 많은 동시 요청을 처리할 수 있다.
- Mac M4 Pro 이상을 사용하는 로컬 개발 환경이라면 Bonsai Studio 앱을 먼저 테스트해보고, LM Studio에 올라온 구현체 중 자신의 워크플로우에 맞는 것을 골라 파이프라인에 통합하면 된다.
- 생성 이미지 품질보다 메모리 절약이 우선이면 1-bit 변형(0.93GB transformer, 3.42GB 페이로드)을, 프롬프트 충실도와 시각적 품질이 중요하면 Ternary 변형(1.21GB transformer, 3.88GB 페이로드)을 선택하는 기준으로 삼을 수 있다.
Terminology
관련 논문
Tiny-vLLM: C++와 CUDA로 만드는 고성능 LLM 추론 엔진
vLLM의 핵심 기능을 C++와 CUDA로 직접 구현하며 배울 수 있는 교육용 LLM 추론 엔진 프로젝트로, 소스코드와 단계별 강의가 함께 제공된다.
일반 데이터센터 GPU에서 요청당 3,000 tokens/s 실시간 LLM 추론
Kog AI가 8× AMD MI300X에서 요청당 3,000 tokens/s를 달성하는 LLM 추론 엔진을 공개했고, 기존 소프트웨어 스택의 병목을 GPU 메모리 대역폭 최대화로 풀어냈다는 내용이다.
LLM을 위한 수면과 유사한 컨텍스트 통합 메커니즘
LLM이 긴 컨텍스트를 처리할 때 발생하는 Attention 비용 문제를 해결하기 위해, 사람의 수면처럼 주기적으로 컨텍스트를 fast weight에 압축·저장하는 새로운 메커니즘을 제안한 논문이다.
CODA: Transformer 블록을 GEMM-Epilogue 프로그램으로 재작성하기
GPU에서 Transformer 학습 시 발생하는 메모리 병목을 해결하기 위해, 정규화·활성화 등 소규모 연산들을 GEMM 출력이 칩 위에 있는 동안 함께 실행하는 커널 추상화 CODA를 소개한다. LLM이 이 추상화를 활용해 고성능 커널을 자동 생성할 수 있다는 점이 특히 주목받고 있다.
KV-Fold: 긴 컨텍스트 추론을 위한 One-Step KV-Cache Recurrence
모델 수정 없이 KV 캐시를 청크 간 누산기로 쓰면 128K 토큰까지 100% 정확도로 정보를 검색할 수 있다.
Swift로 LLM 학습시키기 Part 1: 행렬 곱셈을 Gflop/s에서 Tflop/s로 끌어올리기
Apple Silicon에서 Swift로 직접 행렬 곱셈 커널을 구현하며 CPU, SIMD, AMX, GPU(Metal)를 단계별로 최적화해 Gflop/s에서 Tflop/s 수준까지 성능을 높이는 과정을 상세히 설명한 글이다. 프레임워크 없이 LLM 학습의 핵심 연산을 밑바닥부터 구현하고 싶은 개발자에게 Apple Silicon의 성능 한계를 체감할 수 있는 드문 자료다.