Bonsai Image 4B - modelo de generación de imágenes de 1 bit/ternario para dispositivos locales

 (prismml.com)
3 puntos por GN⁺ 2026-06-01 | 1 comentarios | Compartir por WhatsApp
  • Familia de modelos pequeños de generación de imágenes diseñada para ejecutar inferencia de difusión de alta calidad en hardware local como laptops y teléfonos
  • Mantiene la arquitectura de FLUX.2 Klein 4B, pero cambia los pesos del transformer de difusión a una representación de 1 bit o ternaria
  • El tamaño del transformer de difusión se reduce desde 7.75 GB en el original a 0.93 GB en 1 bit y 1.21 GB en ternario, lo que disminuye la carga del presupuesto de memoria
  • Genera imágenes de 512×512 en 9.4 segundos en un iPhone 17 Pro Max, y muestra alrededor de 6 segundos en una Mac M4 Pro y hasta 5.6 veces más velocidad frente a MFLUX
  • La variante ternaria mantiene 95% del rendimiento frente a FLUX.2 Klein 4B, y ambas variantes se publicarán con pesos abiertos y código bajo Apache 2.0

Bonsai Image 4B para generación local de imágenes

  • Bonsai Image 4B es una familia de modelos pequeños de generación de imágenes diseñada para ejecutar inferencia de difusión de alta calidad en hardware local, desde laptops hasta teléfonos
  • Está basado en FLUX.2 Klein 4B y, manteniendo la arquitectura, cambia los pesos del transformer de difusión a formato de 1 bit o ternario
    • 1-bit Bonsai Image 4B usa pesos binarios del transformer {−1, +1} y factores de escalado por grupo en FP16, ofreciendo 1.125 bits efectivos por peso
    • Ternary Bonsai Image 4B usa pesos del transformer {−1, 0, +1} y factores de escalado por grupo en FP16, ofreciendo 1.71 bits efectivos por peso
  • La variante ternaria es más grande que la de 1 bit, pero el estado 0 adicional mejora la calidad visual y la fidelidad al prompt
  • Con pesos abiertos e inferencia local, Bonsai Image 4B apunta a una forma de despliegue que permita generar imágenes incluso en dispositivos donde antes era difícil ejecutar modelos de esta categoría
  • Según PrismML, Bonsai Image 4B es el primer modelo de imágenes de este rango de parámetros que corre directamente en un iPhone

Reducción de memoria para ejecución local

  • La restricción clave de la generación local de imágenes es que el modelo debe caber dentro del presupuesto de memoria del dispositivo
  • En los modelos de imágenes de clase 4B, el transformer de difusión es la parte más grande del modelo y se ejecuta repetidamente en cada paso de denoising durante la generación
  • El tamaño del transformer influye directamente en la presión sobre la memoria, las demandas de ancho de banda y la velocidad de inferencia local
  • El transformer de difusión de FLUX.2 Klein 4B mide 7.75 GB; 1-bit Bonsai Image 4B mide 0.93 GB y Ternary Bonsai Image 4B mide 1.21 GB
  • La variante de 1 bit es 8.3 veces más pequeña que FLUX.2 Klein 4B de precisión completa, y la variante ternaria es 6.4 veces más pequeña
  • Aunque las capas binarias por sí mismas se reducen alrededor de 14 veces frente a los pesos del transformer de precisión completa, cerca del 5% de las projection layer, sensibles a la precisión, se mantienen en FP16
  • Las capas ternarias ofrecen una reducción de alrededor de 10 veces, y el tamaño final del transformer queda en 1.21 GB

Payload de despliegue y memoria en tiempo de ejecución

  • El payload de despliegue para Apple Silicon, incluyendo encoder de texto comprimido y VAE en FP16, es de 3.42 GB para 1 bit y 3.88 GB para ternario
  • El payload de despliegue de FLUX.2 Klein 4B de precisión completa es de 15.97 GB
  • En tiempo de ejecución, después de codificar el prompt, el encoder de texto se descarga, por lo que el uso promedio de memoria queda por debajo del payload total
  • Al generar imágenes de 512×512, la memoria activa promedio es de 1.5 GB para 1 bit, 1.96 GB para ternario y 11.74 GB para el FLUX.2 Klein 4B original
  • La reducción de memoria para 512×512 es de 7.8 veces en 1 bit y 6.0 veces en ternario
  • Al generar imágenes de 1024×1024, la memoria activa promedio es de 1.95 GB para 1 bit, 2.38 GB para ternario y 14.39 GB para el FLUX.2 Klein 4B original
  • La reducción de memoria para 1024×1024 es de 7.4 veces en 1 bit y 6.0 veces en ternario

Hardware compatible y rendimiento de ejecución

  • La pila de despliegue es compatible con iPhone, iPad y Mac con Apple Silicon, además de GPU con CUDA
  • En hardware de Apple usa la ruta low-bit de MLX, y en CUDA usa los kernels low-bit GEMM de Gemlite
  • En el iPhone 17 Pro Max, el pipeline de FLUX.2 Klein 4B de precisión completa no cabe dentro del presupuesto de memoria del dispositivo, pero ambas variantes de Bonsai Image sí corren on-device
  • Bonsai Image 4B genera imágenes de 512×512 en 9.4 segundos en un iPhone 17 Pro Max
  • En una Mac M4 Pro genera imágenes de 512×512 en alrededor de 6 segundos
  • En una Mac M4 Pro, Bonsai Image 4B es hasta 5.6 veces más rápido que el pipeline MFLUX base de precisión completa

Rendimiento en benchmarks

  • Bonsai Image 4B fue evaluado con tres benchmarks: GenEval, HPSv3 y DPG-Bench
  • GenEval evalúa composición de objetos y asociación de atributos, HPSv3 evalúa preferencia humana y calidad estética, y DPG-Bench evalúa seguimiento denso del prompt y fidelidad semántica
  • Ternary Bonsai Image 4B registra 0.723 en GenEval, 12.22 en HPSv3 y 0.851 en DPG-Bench con un transformer de difusión de 1.21 GB
  • Ternary Bonsai Image 4B mantiene 95% del rendimiento frente a FLUX.2 Klein 4B mientras reduce 6.4 veces el tamaño del transformer de difusión
  • 1-bit Bonsai Image 4B registra 0.671 en GenEval, 11.15 en HPSv3 y 0.822 en DPG-Bench con un transformer de difusión de 0.93 GB
  • 1-bit Bonsai Image 4B mantiene 88% del rendimiento frente a FLUX.2 Klein 4B mientras reduce el transformer de difusión a menos de 1 GB
  • FLUX.2 Klein 4B registra 0.819 en GenEval, 12.84 en HPSv3 y 0.853 en DPG-Bench con un transformer de difusión de 7.75 GB
  • SDXL registra 0.3 en GenEval, 10.05 en HPSv3 y 0.74 en DPG-Bench con un transformer de difusión de 5.14 GB, mostrando 67% del rendimiento de FLUX.2 Klein 4B
  • BK-SDM-Small registra 0.297 en GenEval, 3.05 en HPSv3 y 0.559 en DPG-Bench con un transformer de difusión de 0.98 GB, mostrando 42% del rendimiento de FLUX.2 Klein 4B
  • Stable Diffusion 1.5 registra 0.396 en GenEval, 4.2 en HPSv3 y 0.601 en DPG-Bench con un transformer de difusión de 1.72 GB, mostrando 51% del rendimiento de FLUX.2 Klein 4B
  • PixArt-Σ XL 2 registra 0.541 en GenEval, 11.93 en HPSv3 y 0.769 en DPG-Bench con un transformer de difusión de 1.2 GB, mostrando 83% del rendimiento de FLUX.2 Klein 4B
  • Las dos variantes de Bonsai compiten con modelos modernos de imágenes de clase 4B mientras mantienen una huella del transformer de difusión mucho menor
  • Superan en rendimiento a modelos más pequeños con huellas de memoria similares, llevando un comportamiento moderno de transformer de difusión a un rango de memoria que antes ocupaban modelos más pequeños y de menor rendimiento

Significado del producto para la inferencia local

  • La generación de imágenes depende no solo de la calidad del modelo, sino también de la forma de despliegue
  • Las APIs en la nube siguen siendo adecuadas para muchos productos, pero la generación solo en la nube convierte todos los prompts en solicitudes remotas y añade costo de serving y latencia de ida y vuelta en cada iteración
  • La generación de imágenes es naturalmente iterativa: los usuarios ajustan prompts, comparan resultados, crean variaciones, descartan resultados fallidos y vuelven a intentarlo
  • Si cada intento requiere trabajo del lado del servidor, en cada ciclo creativo el usuario tiene que calcular el costo y esperar
  • La inferencia local permite que, una vez que el modelo está en el dispositivo, la función de generación quede integrada directamente dentro de la experiencia del producto
  • La ejecución local reduce el costo de operación, acelera la iteración y facilita el uso en entornos donde los prompts y los assets generados deben mantenerse privados
  • Bonsai Image 4B es un paso hacia una forma de despliegue de generación de imágenes que se mueve más cerca del usuario, sobre hardware que este ya posee

Forma de publicación y recursos

Lecturas relacionadas

1 comentarios

 
GN⁺ 2026-06-01
Comentarios de Hacker News

  • Hace 20 años, no creo que nadie esperara el internet del futuro en el que no podríamos confiar en que lo que vemos o leemos sea real
    Ojalá algún día podamos ver esta época en retrospectiva como un periodo de desviación, como esa escena de Mad Men en la que la familia Draper deja tirada la basura del picnic en el césped y se va

    • Hace 20 años, los profesores decían que no usaras Wikipedia porque no se podía creer nada de internet, y que jamás salieras con alguien que conocieras en una app o sitio web. Decían que esa persona era asesina al 100%, y también estaba eso de que “internet es para porno”
      Con el tiempo muchas cosas mejoran, y la gente tiende a sobreestimar siempre el riesgo social cuando aparece una tecnología nueva
    • La escena del picnic: https://www.youtube.com/watch?v=FDIvzDGBLWU
    • Parece que no recuerdas el debate alrededor de Narrative Science(https://en.wikipedia.org/wiki/Narrative_Science)
      Era una empresa surgida de una universidad que podía escribir artículos de béisbol bastante creíbles, y luego artículos financieros, solo a partir de estadísticas. Permitía que los sitios de noticias locales publicaran artículos de todos los partidos, así que era una ventaja para los fans del deporte y se consideraba un motor clave para aumentar el tráfico web, pero también recibió muchas críticas por no ser “real”
      Un artículo de Slate de 2012 sobre esto: https://slate.com/technology/2012/03/narrative-science-robot...
      Desde que existen las computadoras, la gente ha intentado hacer que suenen como personas, y tampoco es nueva la preocupación de si aquello con lo que hablo o leo es un robot imitando a un humano
    • Me parece una reacción exagerada llamarlo un “periodo de desviación”
    • Siempre ha habido desinformación en texto e imágenes, y las fotos se pueden manipular desde que existe la fotografía
      Sin duda se está volviendo más fácil, pero no es un cambio cualitativamente distinto. Creer sin más lo que veías en internet hace 20 años habría sido tan ridículo como ahora

  • De verdad espero con ganas un futuro en el que pueda mejorar mi IA actualizando hardware en vez de pagar suscripciones caras
    Hay muchos problemas que quiero abordar que requieren decenas de miles de millones de tokens, y ahora mismo son prácticamente inaccesibles sin el patrocinio de un proyecto corporativo. Me bastaría con una máquina generadora ASIC capaz de sacar decenas de miles de tokens por segundo con una calidad al nivel de Opus 4.6

    • Una empresa llamada Taalas está haciendo algo parecido. No con calidad de Opus 4.6, pero supongo que apuntan a modelos más grandes
      Por ahora usan el modelo LLama 8B, funciona a unos 17k tokens por segundo, y se puede probar en https://chatjimmy.ai/
    • ¿Podrías dar un ejemplo de uno de esos problemas?
    • Me pregunto cuánto serían los costos de hardware y energía comparados con el costo de suscripción
    • Viéndolo lógicamente, cinco personas que juntan recursos siempre serán más fuertes que una sola, así que los centros de datos siempre ganan
      Porque la utilización del tiempo es mayor. Yo también siempre fantaseo con eso, pero lógicamente me parece una ilusión. En promedio no puedes usar más que el conjunto entero, que aprovecha mejor el hardware
      El hardware personal también va a mejorar, pero la frontera siempre va a estar en la nube

  • Cuando vi “1-bit”, lo primero que pensé no fue en pesos de modelo de 1 bit, sino en generación de imágenes en blanco y negro con dithering de 1 bit
    Entonces me dio curiosidad qué tan increíble, rápida y compacta sería una generadora de imágenes por difusión si se limitaran las imágenes de entrenamiento y el espacio de trabajo a imágenes de 1 bit con dithering de Floyd-Steinberg, Atkinson o el algoritmo que prefieras
    El entrenamiento sería bastante rápido y probablemente cabría hasta en una sola GPU moderna

    • Aun así, me parece que sería mejor entrenar en escala de grises y luego aplicar el dithering al final
    • Yo pensé exactamente lo mismo, y parece que aquí hay bastantes ideas interesantes por explorar

  • Pregunto con genuina curiosidad: ¿esto resuelve algún problema real?
    Cuando usas modelos de difusión, me parece que el cuello de botella no es almacenamiento ni memoria, sino tiempo de generación. Muchos modelos corren en GPUs de la era 1080 con 8~12GB o en Macs con memoria similar, y en términos de rendimiento de GPU eso ya está cerca del piso de todos modos. Además, estos modelos parecen ser un poco más lentos que el pequeño modelo base FLUX.2 del que parten
    Claro, podría permitir correr modelos locales en dispositivos como un iPhone, que tienen GPUs relativamente potentes pero memoria limitada, pero ¿de verdad eso es una necesidad tan común?

    • Es un avance útil. Si la inferencia a escala local da una calidad más o menos aceptable, puedes crear productos que generen imágenes descartables con frecuencia sin preocuparte por el costo
      Hasta ahora, todos los productos de generación de imágenes que he visto cobran por uso, lo que limita mucho su valor. Aunque no sé si esto realmente ya llegó al punto de “calidad aceptable”
    • Estamos en una época donde la demanda de GPU es extremadamente alta y la oferta es limitada. Cada vez que empujas la inferencia hacia el edge, liberas recursos de la nube para otras tareas
      Cada mejora en eficiencia aumenta lo que puedes hacer con los recursos existentes. Si puedes renderizar imágenes con la mitad de cómputo, también necesitas solo la mitad de GPUs
    • GPUs de la era 1080 con 8~12GB o Macs con memoria similar no son el piso. La mayoría usa laptops o dispositivos móviles con un rendimiento de GPU mucho menor
    • El valor actual parece estar más cerca del valor académico que del uso práctico
      Incluso los modelos de frontera apenas son utilizables todavía, y en generación de imágenes hasta los mejores modelos suelen dar resultados bastante malos. Así que veo difícil usar de inmediato un modelo pequeño de 1 bit que, en capacidad, inevitablemente va mucho más atrás que la frontera
      Pero aumentar de forma importante la densidad de capacidad por unidad de cómputo sí tiene gran significado. Permite operar modelos de frontera de forma mejor y más barata, reducir el consumo de recursos y ampliar el rango de tareas que pueden ejecutarse en el edge, como en una laptop personal o un teléfono
      También hay muchas tareas que, por privacidad, deberían ejecutarse en el dispositivo, y no todo el mundo tiene una GPU dedicada grande
    • Exacto. El tamaño y el rendimiento no son solo un problema para los LLM locales, sino también para las empresas de LLM de frontera como OpenAI y Anthropic
      Empresas como Anthropic todavía pierden cantidades enormes de dinero en inferencia, y los avances en modelos eficientes y con buen rendimiento ayudan a la rentabilidad

  • La frase “Hasta donde sabemos, Bonsai Image 4B es el primer modelo de imágenes de ese tamaño de parámetros que corre directamente en iPhone” es incorrecta. Pero está redactada con cuidado para no ser del todo falsa
    FLUX.2 [klein] 4B, o sea el mismo tamaño de parámetros y básicamente el mismo modelo, corre en iPhone mediante la app Draw Things. Usa cuantización de 8 bits o 6 bits, así que podría decirse que no corre “directamente”, pero esa precisión técnica suena bastante sospechosa

  • Lo llaman modelo de difusión, pero su base, Flux.2, es un modelo de flujo rectificado

    • En lo personal, creo que está bien usar “difusión” para referirse a toda esa familia

  • Qué raro. Soy visitante del Reino Unido y me aparece esto:
    Website Not Allowed
    “⁦‪prismml.com‬⁩” is a restricted website.

  • Antes de que termine el día, alguien va a entrenar un LoRA para este modelo de 1 bit y lo va a hacer generar contenido hentai en un Apple Watch

  • Si quieres ejecutarlo sin andar manoseando el sistema de archivos local, puedes usar https://github.com/kordless/bonsai-docker

  • Saqué el código del demo web y lo conecté como un nodo de generación de imágenes web dentro de una herramienta de flujos de trabajo de IA en el navegador, y está bastante bien
    Estoy esperando a que xenova lo agregue a transformersjs 4.3, y entonces también lo voy a publicar. No podía esperar para probarlo, así que lo hice primero

    • ¿Podrías explicar esa herramienta de flujos de trabajo de IA en el navegador? Puede que yo también esté haciendo algo parecido, así que me da mucha curiosidad ver qué está construyendo otra gente en este espacio