로컬 기기용 1비트 Bonsai Image 4B 이미지 생성
(prismml.com)- Bonsai Image 4B는 노트북과 휴대폰 같은 로컬 하드웨어에서 고품질 확산 추론을 실행하도록 설계된 소형 이미지 생성 모델군임
- FLUX.2 Klein 4B 아키텍처를 유지하면서 확산 트랜스포머 가중치를 1-bit 또는 ternary 표현으로 바꿈
- 확산 트랜스포머 크기는 원본 7.75GB에서 1-bit 0.93GB, ternary 1.21GB로 줄어 메모리 예산 부담을 낮춤
- iPhone 17 Pro Max에서 512×512 이미지를 9.4초에 생성하며, Mac M4 Pro에서는 약 6초와 MFLUX 대비 최대 5.6배 속도를 보임
- ternary는 FLUX.2 Klein 4B 대비 95% 성능을 유지하고, 두 변형은 Apache 2.0 오픈 가중치와 코드로 공개될 예정임
로컬 이미지 생성을 위한 Bonsai Image 4B
- Bonsai Image 4B는 노트북부터 휴대폰까지 로컬 하드웨어에서 고품질 확산 추론을 실행하도록 설계된 소형 이미지 생성 모델군임
- FLUX.2 Klein 4B를 기반으로 하며, 아키텍처는 유지한 채 확산 트랜스포머 가중치를 1-bit 또는 ternary 형태로 바꿈
- 1-bit Bonsai Image 4B는 이진
{−1, +1}트랜스포머 가중치와 FP16 그룹 단위 스케일링 팩터를 사용해 가중치당 1.125 유효 비트를 제공함 - Ternary Bonsai Image 4B는
{−1, 0, +1}트랜스포머 가중치와 FP16 그룹 단위 스케일링 팩터를 사용해 가중치당 1.71 유효 비트를 제공함
- 1-bit Bonsai Image 4B는 이진
- ternary 변형은 1-bit보다 크지만, 추가된 0 상태로 시각 품질과 프롬프트 충실도를 높임
- Bonsai Image 4B는 오픈 가중치와 로컬 추론을 통해, 이 등급 모델을 실행하기 어려웠던 기기에서도 이미지 생성을 가능하게 하는 배포 형태를 목표로 함
- PrismML 기준으로 Bonsai Image 4B는 해당 파라미터급 이미지 모델 중 iPhone에서 직접 실행되는 첫 모델임
로컬 실행을 위한 메모리 절감
- 로컬 이미지 생성의 핵심 제약은 모델이 기기 메모리 예산 안에 들어가야 한다는 점임
- 4B급 이미지 모델에서는 확산 트랜스포머가 모델에서 가장 큰 부분이며, 생성 중 각 디노이징 단계마다 반복 실행됨
- 트랜스포머 크기는 메모리 압박, 대역폭 요구, 로컬 추론 속도에 직접 영향을 줌
- FLUX.2 Klein 4B의 확산 트랜스포머는 7.75GB이고, 1-bit Bonsai Image 4B는 0.93GB, Ternary Bonsai Image 4B는 1.21GB임
- 1-bit 변형은 전체 정밀도 FLUX.2 Klein 4B 대비 8.3배, ternary 변형은 6.4배 작음
- 이진 레이어 자체는 전체 정밀도 트랜스포머 가중치 대비 약 14배 줄어들지만, 정밀도에 민감한 약 5%의 projection layer는 FP16으로 유지됨
- ternary 레이어는 약 10배 절감을 제공하며, 최종 트랜스포머 크기는 1.21GB가 됨
배포 페이로드와 런타임 메모리
- 압축된 텍스트 인코더와 FP16 VAE를 포함한 Apple Silicon 배포 페이로드는 1-bit가 3.42GB, ternary가 3.88GB임
- 전체 정밀도 FLUX.2 Klein 4B의 배포 페이로드는 15.97GB임
- 런타임에서는 프롬프트 인코딩 후 텍스트 인코더가 오프로드되므로, 평균 메모리 사용량은 전체 페이로드보다 작아짐
- 512×512 이미지 생성 시 평균 활성 메모리는 1-bit가 1.5GB, ternary가 1.96GB, 원본 FLUX.2 Klein 4B가 11.74GB임
- 512×512 기준 메모리 감소율은 1-bit가 7.8배, ternary가 6.0배임
- 1024×1024 이미지 생성 시 평균 활성 메모리는 1-bit가 1.95GB, ternary가 2.38GB, 원본 FLUX.2 Klein 4B가 14.39GB임
- 1024×1024 기준 메모리 감소율은 1-bit가 7.4배, ternary가 6.0배임
지원 하드웨어와 실행 성능
- 배포 스택은 Apple Silicon iPhone, iPad, Mac과 CUDA GPU를 지원함
- Apple 하드웨어에서는 MLX low-bit 경로를 사용하고, CUDA에서는 Gemlite low-bit GEMM 커널을 사용함
- iPhone 17 Pro Max에서는 전체 정밀도 FLUX.2 Klein 4B 파이프라인이 기기 메모리 예산 안에 들어가지 않지만, Bonsai Image 두 변형은 온디바이스로 실행됨
- Bonsai Image 4B는 iPhone 17 Pro Max에서 512×512 이미지를 9.4초에 생성함
- Mac M4 Pro에서는 512×512 이미지를 약 6초에 생성함
- Mac M4 Pro에서 Bonsai Image 4B는 기본 전체 정밀도 MFLUX 파이프라인보다 최대 5.6배 빠름
벤치마크 성능
- Bonsai Image 4B는 GenEval, HPSv3, DPG-Bench 세 가지 벤치마크로 평가됨
- GenEval은 객체 구성과 속성 바인딩을 평가하고, HPSv3는 인간 선호와 미적 품질을 평가하며, DPG-Bench는 조밀한 프롬프트 추종과 의미 충실도를 평가함
- Ternary Bonsai Image 4B는 1.21GB 확산 트랜스포머로 GenEval 0.723, HPSv3 12.22, DPG-Bench 0.851을 기록함
- Ternary Bonsai Image 4B는 FLUX.2 Klein 4B 대비 95% 성능을 유지하면서 확산 트랜스포머 크기를 6.4배 줄임
- 1-bit Bonsai Image 4B는 0.93GB 확산 트랜스포머로 GenEval 0.671, HPSv3 11.15, DPG-Bench 0.822를 기록함
- 1-bit Bonsai Image 4B는 FLUX.2 Klein 4B 대비 88% 성능을 유지하면서 확산 트랜스포머를 1GB 아래로 낮춤
- FLUX.2 Klein 4B는 7.75GB 확산 트랜스포머로 GenEval 0.819, HPSv3 12.84, DPG-Bench 0.853을 기록함
- SDXL은 5.14GB 확산 트랜스포머로 GenEval 0.3, HPSv3 10.05, DPG-Bench 0.74를 기록하며 FLUX.2 Klein 4B 대비 67% 성능을 보임
- BK-SDM-Small은 0.98GB 확산 트랜스포머로 GenEval 0.297, HPSv3 3.05, DPG-Bench 0.559를 기록하며 FLUX.2 Klein 4B 대비 42% 성능을 보임
- Stable Diffusion 1.5는 1.72GB 확산 트랜스포머로 GenEval 0.396, HPSv3 4.2, DPG-Bench 0.601을 기록하며 FLUX.2 Klein 4B 대비 51% 성능을 보임
- PixArt-Σ XL 2는 1.2GB 확산 트랜스포머로 GenEval 0.541, HPSv3 11.93, DPG-Bench 0.769를 기록하며 FLUX.2 Klein 4B 대비 83% 성능을 보임
- 두 Bonsai 변형은 현대 4B급 이미지 모델과 경쟁하면서도 확산 트랜스포머 풋프린트를 훨씬 작게 유지함
- 비슷한 메모리 풋프린트를 가진 더 작은 모델보다 성능이 높아, 기존에는 더 작고 낮은 성능의 모델이 차지하던 메모리 범위로 현대적인 확산 트랜스포머 동작을 가져옴
로컬 추론의 제품적 의미
- 이미지 생성은 모델 품질뿐 아니라 배포 방식에도 좌우됨
- 클라우드 API는 많은 제품에서 계속 적합하지만, 클라우드 전용 생성은 모든 프롬프트를 원격 요청으로 만들고, 모든 반복에 서빙 비용과 왕복 지연을 추가함
- 이미지 생성은 자연스럽게 반복적이어서 사용자는 프롬프트를 수정하고, 결과를 비교하고, 변형을 만들고, 실패 결과를 버리고 다시 시도함
- 각 시도가 서버 측 작업이면 창작 루프마다 사용자가 비용을 계산하고 기다려야 함
- 로컬 추론은 모델이 기기에 들어간 뒤 생성 기능을 제품 경험 안에 직접 배치할 수 있게 함
- 로컬 실행은 실행 비용을 낮추고, 반복 속도를 높이며, 프롬프트와 생성 자산이 비공개로 유지되어야 하는 환경에서 쓰기 쉬움
- Bonsai Image 4B는 사용자가 이미 가진 하드웨어에서 사용자에게 더 가까운 위치로 옮겨가는 이미지 생성 배포 방식을 향한 단계임
공개 방식과 리소스
- 1-bit Bonsai Image 4B와 Ternary Bonsai Image 4B는 오픈 가중치와 코드로 공개될 예정임
- 라이선스는 Apache 2.0임
- PrismML은 iPhone에서 Bonsai Image 4B를 직접 시험해볼 수 있는 iOS 앱 Bonsai Studio도 함께 출시함
- Whitepaper
- Hugging Face
- WebGPU demo
- Bonsai Studio for iPhone
- GitHub
댓글과 토론
Hacker News 의견들
-
20년 전에는 우리가 보거나 읽는 것이 진짜인지 신뢰할 수 없는 미래의 인터넷을 기대한 사람은 없었을 것 같음
언젠가는 이 시대를, Mad Men에서 Draper 가족이 피크닉 쓰레기를 잔디밭에 던져두고 떠나는 장면처럼 일탈적 시기로 돌아볼 수 있기를 바람- 20년 전 선생님들은 인터넷은 아무것도 믿을 수 없으니 Wikipedia를 쓰지 말라고 했고, 앱이나 웹사이트에서 만난 사람과는 절대 데이트하지 말라고 했음. 그런 사람은 100% 살인자라고 했고, “인터넷은 포르노용”이라는 말도 있었음
시간이 지나며 좋아지는 일도 많고, 사람들은 새 기술이 처음 나올 때 사회적 위험을 늘 과대평가하는 편임 - 그 피크닉 장면: https://www.youtube.com/watch?v=FDIvzDGBLWU
- 그때 Narrative Science(https://en.wikipedia.org/wiki/Narrative_Science)를 둘러싼 논의를 기억 못 하는 듯함
이 회사는 대학에서 나온 스핀아웃으로, 통계만으로 그럴듯한 야구 기사와 이후 금융 기사를 쓸 수 있었음. 지역 뉴스 사이트가 모든 경기 기사를 발행할 수 있게 해 스포츠 팬에게 이득이고 웹 트래픽을 늘리는 핵심 동력으로 여겨졌지만, “진짜”가 아니라는 비판도 많았음
Slate가 2012년에 이에 대해 쓴 글: https://slate.com/technology/2012/03/narrative-science-robot...
컴퓨터가 생긴 이래 사람들은 컴퓨터가 사람처럼 들리게 만들려고 해왔고, 내가 대화하거나 읽는 대상이 사람을 흉내 내는 로봇인지 걱정하는 것도 새롭지 않음 - “일탈적 시기”라고 하기엔 과한 반응처럼 보임
- 텍스트와 이미지에는 항상 허위 정보가 있었고, 사진은 사진술이 생긴 때부터 조작 가능했음
확실히 더 쉬워지고는 있지만 질적으로 완전히 달라진 변화는 아님. 20년 전 인터넷에서 본 것을 그대로 믿는 것도 지금만큼이나 우스운 일이었을 것임
- 20년 전 선생님들은 인터넷은 아무것도 믿을 수 없으니 Wikipedia를 쓰지 말라고 했고, 앱이나 웹사이트에서 만난 사람과는 절대 데이트하지 말라고 했음. 그런 사람은 100% 살인자라고 했고, “인터넷은 포르노용”이라는 말도 있었음
-
비싼 구독 대신 하드웨어를 업그레이드해서 내 AI를 업그레이드하는 미래가 정말 기다려짐
하고 싶은 문제 중에는 수십억 토큰이 필요한 것들이 많은데, 지금은 기업 프로젝트 후원이 없으면 사실상 접근 불가능함. Opus 4.6 수준 품질로 초당 수만 토큰을 뽑아낼 수 있는 ASIC 생성 머신이면 충분함- Taalas라는 회사가 비슷한 걸 만들고 있음. Opus 4.6 품질은 아니지만 더 큰 모델을 목표로 하고 있을 것임
현재는 LLama 8B 모델을 쓰고, 초당 약 17k 토큰으로 동작하며 https://chatjimmy.ai/에서 테스트 가능함 - 그런 문제의 예를 하나 들어줄 수 있음?
- 하드웨어와 전력 비용이 구독 비용과 비교해 어느 정도일지 궁금함
- 논리적으로 보면 다섯 명이 자원을 모으는 쪽이 한 명보다 강하므로, 데이터센터가 항상 이김
시간 활용률이 더 높기 때문임. 나도 늘 같은 상상을 하지만, 논리적으로는 환상이라고 봄. 평균적으로 하드웨어를 더 잘 활용하는 집단 전체보다 더 많이 쓸 수는 없음
개인 하드웨어도 좋아지겠지만, 최첨단은 항상 클라우드에 있을 것임
- Taalas라는 회사가 비슷한 걸 만들고 있음. Opus 4.6 품질은 아니지만 더 큰 모델을 목표로 하고 있을 것임
-
“1-bit”를 보고 처음 떠올린 건 1비트 모델 가중치가 아니라 1비트 디더링 흑백 이미지 생성이었음
그래서 훈련 이미지와 작업 공간을 Floyd-Steinberg, Atkinson, 혹은 선호하는 알고리즘으로 디더링한 1비트 이미지로 제한하면 확산 이미지 생성기가 얼마나 멋지고 빠르고 압축될지 궁금해짐
학습은 꽤 빠를 것이고, 아마 최신 GPU 하나에도 들어갈 듯함- 그래도 그레이스케일로 학습한 뒤 나중에 디더링하는 편이 더 나을 것 같음
- 나도 정확히 같은 생각을 했고, 여기서 탐구할 만한 멋진 아이디어가 꽤 있어 보임
-
진짜 궁금해서 묻는데, 이게 실제 문제를 해결하는 건가?
확산 모델을 쓸 때 병목은 저장 공간이나 메모리가 아니라 생성 시간이라고 봄. 많은 모델은 1080 세대 이후의 8~12GB GPU나 비슷한 메모리의 Mac에서 돌아가고, 어차피 GPU 성능 관점에서는 그 정도가 하한에 가까움. 게다가 이 모델들은 기반이 된 작은 FLUX.2 모델보다 약간 느린 것으로 보임
물론 iPhone처럼 비교적 강한 GPU가 있지만 메모리가 제한된 기기에서 로컬 모델을 돌릴 수 있게 해줄 수는 있겠지만, 그게 정말 흔한 요구사항인가?- 유용한 진전임. 로컬 규모 추론으로 그럭저럭 괜찮은 품질이 나오면, 비용 걱정 없이 자주 버려도 되는 이미지를 생성하는 제품을 만들 수 있음
지금까지 본 이미지 생성 제품은 모두 사용량 과금이라 가치가 크게 제한됨. 다만 이게 실제로 “괜찮은 품질” 지점에 도달했는지는 모르겠음 - 지금은 GPU 수요가 극단적으로 높고 공급은 제한된 시대임. 추론을 엣지로 밀어낼 때마다 클라우드 자원이 다른 작업에 비게 됨
효율이 좋아질 때마다 기존 자원으로 할 수 있는 일이 늘어남. 이미지를 절반의 연산량으로 렌더링할 수 있다면 GPU도 절반만 필요함 - 8~12GB 1080 세대 GPU나 비슷한 메모리의 Mac은 하한이 아님. 대부분은 그보다 GPU 성능이 훨씬 낮은 노트북이나 모바일 기기를 씀
- 현재 가치는 실사용보다는 학술적 가치에 더 가까워 보임
최전선 모델도 아직 간신히 쓸 만한 수준이고, 이미지 생성에서는 최고 모델조차 대부분 형편없는 결과가 많음. 그래서 능력 면에서 최전선보다 훨씬 뒤처질 수밖에 없는 작은 1비트 모델은 당장 쓰기 어렵다고 봄
하지만 연산 단위당 능력 밀도를 크게 높이는 건 큰 의미가 있음. 최전선 모델을 더 좋고 싸게 운영하고 자원 소모를 줄일 수 있으며, 개인 노트북이나 휴대폰 같은 엣지에서 수행 가능한 작업 범위도 넓어짐
개인정보 관점에서도 기기 내에서 돌아가야 할 작업이 많고, 모두가 큰 전용 GPU를 갖고 있지는 않음 - 맞음. 크기와 성능은 로컬 LLM만의 문제가 아니라 OpenAI와 Anthropic 같은 최전선 LLM 회사에도 문제임
Anthropic 같은 회사는 아직도 추론에서 막대한 손실을 보고 있고, 효율적이면서 성능 좋은 모델의 발전은 수익성에 도움이 됨
- 유용한 진전임. 로컬 규모 추론으로 그럭저럭 괜찮은 품질이 나오면, 비용 걱정 없이 자주 버려도 되는 이미지를 생성하는 제품을 만들 수 있음
-
“우리가 알기로 Bonsai Image 4B는 해당 매개변수 규모에서 iPhone에서 직접 실행되는 첫 이미지 모델”이라는 문장은 틀렸음. 다만 완전히 틀리지는 않게 조심스럽게 표현했음
FLUX.2 [klein] 4B, 즉 같은 매개변수 규모이자 사실상 같은 모델이 Draw Things 앱을 통해 iPhone에서 돌아감. 8비트나 6비트 양자화를 쓰므로 “직접”은 아니라고 할 수 있겠지만, 그 기술적 단서가 꽤 수상하게 들림 -
확산 모델이라고 부르지만, 기반인 Flux.2는 정류 흐름 모델임
- 개인적으로는 “확산”을 이 계열 전체를 가리키는 말로 써도 괜찮다고 봄
-
이상함. 영국 방문자인데 이렇게 뜸:
Website Not Allowed
“prismml.com” is a restricted website. -
하루 안에 누군가 이 1비트 모델용 LoRA를 학습시켜 Apple Watch에서 헨타이 콘텐츠를 생성하게 만들 것임
-
로컬 파일시스템을 만지작거리지 않고 실행하고 싶다면 https://github.com/kordless/bonsai-docker를 쓰면 됨
-
웹 데모에서 코드를 추출해서 브라우저 내 AI 워크플로 도구에 웹 이미지 생성 노드로 붙였고, 꽤 괜찮음
xenova가 transformersjs 4.3에 추가해주기를 기다리는 중이고, 그러면 나도 공개할 예정임. 테스트는 기다릴 수 없어서 먼저 해봤음- 그 “브라우저 내 AI 워크플로 도구”를 설명해줄 수 있음? 비슷한 걸 만들고 있을 수도 있어서, 이 분야에서 다른 사람들이 무엇을 만드는지 매우 궁금함