# 로컬 기기용 1비트 Bonsai Image 4B 이미지 생성 > Clean Markdown view of GeekNews topic #30073. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=30073](https://news.hada.io/topic?id=30073) - GeekNews Markdown: [https://news.hada.io/topic/30073.md](https://news.hada.io/topic/30073.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-06-01T16:34:42+09:00 - Updated: 2026-06-01T16:34:42+09:00 - Original source: [prismml.com](https://prismml.com/news/bonsai-image-4b) - Points: 1 - Comments: 1 ## Topic Body - **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 유효 비트를 제공함 - 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](https://github.com/PrismML-Eng/Bonsai-Image-Demo/blob/main/bonsai-image-4b-whitepaper.pdf) - [Hugging Face](https://huggingface.co/collections/prism-ml/bonsai-image) - [WebGPU demo](https://huggingface.co/spaces/webml-community/bonsai-image-webgpu) - [Bonsai Studio for iPhone](https://apps.apple.com/us/app/bonsai-studio-by-prismml/id6767042620) - [GitHub](https://github.com/PrismML-Eng/Bonsai-image-demo) ## Comments ### Comment 58746 - Author: neo - Created: 2026-06-01T16:34:43+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48346257) - 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년 전 인터넷에서 본 것을 그대로 믿는 것도 지금만큼이나 우스운 일이었을 것임 - 비싼 구독 대신 하드웨어를 업그레이드해서 내 **AI를 업그레이드**하는 미래가 정말 기다려짐 하고 싶은 문제 중에는 수십억 토큰이 필요한 것들이 많은데, 지금은 기업 프로젝트 후원이 없으면 사실상 접근 불가능함. Opus 4.6 수준 품질로 초당 수만 토큰을 뽑아낼 수 있는 ASIC 생성 머신이면 충분함 - **Taalas**라는 회사가 비슷한 걸 만들고 있음. Opus 4.6 품질은 아니지만 더 큰 모델을 목표로 하고 있을 것임 현재는 LLama 8B 모델을 쓰고, 초당 약 17k 토큰으로 동작하며 [https://chatjimmy.ai/]()에서 테스트 가능함 - 그런 문제의 예를 하나 들어줄 수 있음? - 하드웨어와 전력 비용이 **구독 비용**과 비교해 어느 정도일지 궁금함 - 논리적으로 보면 다섯 명이 자원을 모으는 쪽이 한 명보다 강하므로, **데이터센터**가 항상 이김 시간 활용률이 더 높기 때문임. 나도 늘 같은 상상을 하지만, 논리적으로는 환상이라고 봄. 평균적으로 하드웨어를 더 잘 활용하는 집단 전체보다 더 많이 쓸 수는 없음 개인 하드웨어도 좋아지겠지만, 최첨단은 항상 클라우드에 있을 것임 - “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 워크플로 도구**”를 설명해줄 수 있음? 비슷한 걸 만들고 있을 수도 있어서, 이 분야에서 다른 사람들이 무엇을 만드는지 매우 궁금함