아이폰에서 도는 4B 이미지 생성 모델, Bonsai Image 4B 공개

• PrismML이 Bonsai Image 4B를 공개함. 포인트는 “이미지 생성 모델을 클라우드 말고 로컬 기기에서 돌리자”임

  • 기반 모델은 FLUX.2 Klein 4B이고, 아키텍처는 유지한 채 확산 트랜스포머 가중치 표현을 크게 줄였음
  • 노트북, 휴대폰 같은 로컬 하드웨어에서 고품질 확산 추론을 돌리는 게 목표
  • 회사 주장으로는 이 파라미터급 이미지 모델이 아이폰에서 직접 실행되는 첫 사례라고 함

• 모델은 2가지 버전으로 나뉨. 하나는 극단적 압축, 하나는 품질 쪽에 조금 더 무게를 둔 버전

  • 1비트 Bonsai Image 4B는 가중치를 {-1, +1} 이진 값으로 두고 FP16 그룹별 스케일링을 붙여 유효 1.125비트 수준으로 만듦
  • 삼진 Bonsai Image 4B는 {-1, 0, +1}을 쓰고 유효 1.71비트 수준임
  • 삼진 버전은 0 상태가 하나 더 있어서 프롬프트 충실도와 시각 품질이 더 낫다고 설명함

• 왜 확산 트랜스포머를 줄이는지가 핵심임. 이미지 생성은 이 부분을 한 번만 돌리는 게 아니라 매 노이즈 제거 단계마다 반복해서 호출함

  • 그래서 트랜스포머 크기가 곧 메모리 압박, 메모리 대역폭, 로컬 추론 속도로 이어짐
  • 정밀도에 민감한 일부 보조 텐서, 즉 투영 레이어 약 5%는 FP16으로 남겨 품질 저하를 줄였음
  • 압축 대상과 보존 대상을 나눈 게 단순한 “무조건 1비트로 밀어붙이기”와 다른 지점임

• 전체 배포 패키지 크기도 꽤 인상적임

  • 압축된 텍스트 인코더와 FP16 VAE까지 포함하면 애플 실리콘 배포 패키지는 1비트 모델 3.42GB, 삼진 모델 3.88GB
  • 전체 정밀도 FLUX.2 Klein 4B는 15.97GB가 필요함
  • 런타임에서는 프롬프트 인코딩 뒤 텍스트 인코더를 오프로딩하므로 실제 평균 활성 메모리는 더 작아짐

• 512×512 이미지 생성 기준 평균 활성 메모리는 원본 대비 확 줄었음

  • 1비트 모델은 1.5GB, 삼진 모델은 1.96GB
  • 원본 FLUX.2 Klein 4B는 11.74GB라서 각각 7.8배, 6.0배 감소
  • 1024×1024에서는 1비트 1.95GB, 삼진 2.38GB, 원본 14.39GB로 각각 7.4배, 6.0배 감소

• 실제 기기 실행 수치도 공개됨. 여기서 “로컬 이미지 생성”이 그냥 데모용 문구가 아니라는 걸 보여주려는 듯함

  • 아이폰 17 프로 맥스에서 512×512 이미지를 9.4초에 생성
  • 맥 M4 프로에서는 약 6초
  • 맥 M4 프로 기준 stock 전체 정밀도 MFLUX 파이프라인보다 최대 5.6배 빠르다고 주장함
  • 전체 정밀도 FLUX.2 Klein 4B는 아이폰 17 프로 맥스 메모리 예산 안에 들어가지 않지만, Bonsai 두 버전은 온디바이스 실행이 가능했다고 함

• 품질 평가는 GenEval, HPSv3, DPG-Bench 3개 벤치마크로 진행됨

  • GenEval은 객체 구성과 속성 결합을 봄
  • HPSv3는 사람 선호도와 미적 품질 쪽 평가
  • DPG-Bench는 촘촘한 프롬프트 추종성과 의미 충실도를 보는 벤치마크

• 품질 쪽 버전인 삼진 Bonsai Image 4B는 꽤 공격적인 주장을 내놨음

  • 확산 트랜스포머 크기를 6.4배 줄였는데도 FLUX.2 Klein 4B 정확도의 95%를 유지한다고 함
  • 1비트 버전은 1GB 미만 트랜스포머를 달성하면서 원본 정확도의 88%를 유지한다고 설명함
  • 결국 “작아졌으니 품질은 포기하세요”가 아니라, 품질과 크기의 파레토 곡선을 옮겼다는 메시지임

• 배포 스택은 애플 실리콘과 CUDA 양쪽을 겨냥함

  • 아이폰, 아이패드, 맥에서는 MLX 저비트 경로를 사용
  • CUDA GPU에서는 Gemlite 저비트 GEMM 커널을 사용
  • 모바일 앱만 노린 게 아니라 로컬 개발 환경과 데스크톱 GPU까지 같이 보는 전략임

• 이 발표가 재밌는 이유는 이미지 생성의 병목을 “모델 성능”만이 아니라 “제품 배포” 문제로 본다는 점임

  • 클라우드 API는 여전히 많은 제품에 맞지만, 모든 프롬프트가 원격 요청이 되고 매 반복마다 비용과 지연 시간이 붙음
  • 이미지 생성은 원래 한 번에 끝나는 작업이 아니라 프롬프트 수정, 비교, 변형 생성, 실패작 폐기 같은 루프가 많음
  • 로컬에서 돌면 이 반복 루프가 훨씬 싸고 빠르고, 프롬프트와 생성물이 기기 밖으로 나가지 않아도 됨

• 라이선스와 앱도 같이 공개 예정임

  • 1비트와 삼진 Bonsai Image 4B 모두 오픈 가중치와 코드를 Apache 2.0으로 공개한다고 함
  • 아이폰에서 직접 Bonsai Image 4B를 써볼 수 있는 iOS 앱 Bonsai Studio도 같이 내놓음
  • PrismML은 Caltech 연구자 출신 팀에서 나왔고, Khosla Ventures, Cerberus, Google의 지원을 받았다고 소개함

---

기술 맥락

• 여기서 선택한 기술적 승부수는 모델 전체를 새로 만드는 게 아니라, 반복 실행 비용이 가장 큰 확산 트랜스포머의 가중치 표현을 줄이는 거예요. 이미지 생성에서는 트랜스포머가 매 denoising step마다 다시 돌기 때문에, 이 부분을 줄이면 메모리와 속도 양쪽에 바로 효과가 나거든요.

• 1비트와 삼진 버전을 따로 둔 것도 제품 선택지로 보면 꽤 현실적이에요. 1비트는 배포 크기와 메모리 예산이 빡빡한 기기용이고, 삼진은 조금 더 큰 대신 프롬프트 충실도와 이미지 품질을 챙기는 쪽이에요. 같은 4B급 모델이라도 어디에 넣을지에 따라 최적점이 달라지는 거죠.

• 애플 기기에서는 MLX 저비트 경로를, CUDA에서는 Gemlite 저비트 GEMM 커널을 쓴다고 밝힌 점도 중요해요. 양자화 모델은 파일 크기만 줄인다고 끝나는 게 아니라, 실제 하드웨어에서 저비트 연산을 잘 태워야 체감 속도가 나오거든요.

• 개발자 입장에서는 이게 단순 연구 발표보다 제품 아키텍처 선택에 가깝게 읽혀요. 서버에서 이미지 생성 API를 호출할지, 사용자의 기기에서 반복 생성 루프를 돌릴지에 따라 비용 구조, 지연 시간, 프라이버시 설계가 전부 달라지기 때문이에요.