Bonsai Image 4B de 1 bit para generación de imágenes en dispositivos locales

 (prismml.com)
1 puntos por GN⁺ 3 시간 전 | 1 comentarios | Compartir por WhatsApp
  • Bonsai Image 4B es una familia de modelos pequeños de generación de imágenes diseñada para ejecutar inferencia por difusión de alta calidad en hardware local como laptops y teléfonos
  • Mantiene la arquitectura de FLUX.2 Klein 4B, pero convierte los pesos del transformador de difusión a representación de 1 bit o ternaria
  • El tamaño del transformador de difusión se reduce desde 7.75GB en el original a 0.93GB en 1 bit y 1.21GB en ternario, lo que baja la carga del presupuesto de memoria
  • Genera imágenes de 512×512 en 9.4 segundos en un iPhone 17 Pro Max y en unos 6 segundos en una Mac M4 Pro, con hasta 5.6 veces más velocidad frente a MFLUX
  • La variante ternaria mantiene el 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 por difusión de alta calidad en hardware local, desde laptops hasta teléfonos
  • Está basado en FLUX.2 Klein 4B y conserva la arquitectura, pero cambia los pesos del transformador de difusión a formato de 1 bit o ternario
    • 1-bit Bonsai Image 4B usa pesos binarios del transformador {−1, +1} y factores de escalado por grupo en FP16 para ofrecer 1.125 bits efectivos por peso
    • Ternary Bonsai Image 4B usa pesos del transformador {−1, 0, +1} y factores de escalado por grupo en FP16 para ofrecer 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 un formato de despliegue que haga posible la generación de 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 esta escala de parámetros que corre directamente en un iPhone

Reducción de memoria para ejecución local

  • La restricción principal 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 transformador 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 transformador influye directamente en la presión de memoria, los requisitos de ancho de banda y la velocidad de inferencia local
  • El transformador de difusión de FLUX.2 Klein 4B ocupa 7.75GB, mientras que 1-bit Bonsai Image 4B ocupa 0.93GB y Ternary Bonsai Image 4B ocupa 1.21GB
  • La variante de 1 bit es 8.3 veces más pequeña que FLUX.2 Klein 4B en precisión completa, y la variante ternaria es 6.4 veces más pequeña
  • Las capas binarias por sí solas se reducen unas 14 veces frente a los pesos del transformador de precisión completa, pero cerca del 5% de las projection layer sensibles a la precisión se mantienen en FP16
  • Las capas ternarias ofrecen una reducción de unas 10 veces, y el tamaño final del transformador queda en 1.21GB

Payload de despliegue y memoria en tiempo de ejecución

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

Hardware compatible y rendimiento de ejecución

  • El stack de despliegue es compatible con iPhone, iPad y Mac con Apple Silicon, además de GPU 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 en 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 unos 6 segundos
  • En una Mac M4 Pro, Bonsai Image 4B es hasta 5.6 veces más rápido que el pipeline MFLUX base en 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 registró 0.723 en GenEval, 12.22 en HPSv3 y 0.851 en DPG-Bench con un transformador de difusión de 1.21GB
  • Ternary Bonsai Image 4B conserva el 95% del rendimiento de FLUX.2 Klein 4B mientras reduce 6.4 veces el tamaño del transformador de difusión
  • 1-bit Bonsai Image 4B registró 0.671 en GenEval, 11.15 en HPSv3 y 0.822 en DPG-Bench con un transformador de difusión de 0.93GB
  • 1-bit Bonsai Image 4B conserva el 88% del rendimiento de FLUX.2 Klein 4B mientras baja el transformador de difusión por debajo de 1GB
  • FLUX.2 Klein 4B registró 0.819 en GenEval, 12.84 en HPSv3 y 0.853 en DPG-Bench con un transformador de difusión de 7.75GB
  • SDXL registró 0.3 en GenEval, 10.05 en HPSv3 y 0.74 en DPG-Bench con un transformador de difusión de 5.14GB, mostrando el 67% del rendimiento de FLUX.2 Klein 4B
  • BK-SDM-Small registró 0.297 en GenEval, 3.05 en HPSv3 y 0.559 en DPG-Bench con un transformador de difusión de 0.98GB, mostrando el 42% del rendimiento de FLUX.2 Klein 4B
  • Stable Diffusion 1.5 registró 0.396 en GenEval, 4.2 en HPSv3 y 0.601 en DPG-Bench con un transformador de difusión de 1.72GB, mostrando el 51% del rendimiento de FLUX.2 Klein 4B
  • PixArt-Σ XL 2 registró 0.541 en GenEval, 11.93 en HPSv3 y 0.769 en DPG-Bench con un transformador de difusión de 1.2GB, mostrando el 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 transformador de difusión mucho más pequeña
  • Su rendimiento supera al de modelos más pequeños con huellas de memoria parecidas, llevando un transformador de difusión moderno a un rango de memoria que antes estaba ocupado por modelos más pequeños y de menor rendimiento

Significado de producto de la inferencia local

  • La generación de imágenes no depende solo de la calidad del modelo, sino también de cómo se despliega
  • Las API en la nube siguen siendo adecuadas para muchos productos, pero la generación exclusiva en la nube convierte cada prompt en una solicitud remota y añade costo de serving y latencia de ida y vuelta a 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 intentar
  • 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 colocar la capacidad de generación directamente dentro de la experiencia del producto una vez que el modelo ya está en el dispositivo
  • La ejecución local reduce el costo por ejecución, acelera la iteración y facilita su uso en entornos donde los prompts y los recursos generados deben mantenerse en privado
  • Bonsai Image 4B es un paso hacia un modelo de despliegue para generación de imágenes que se mueve más cerca del usuario, sobre el hardware que ya tiene

Forma de publicación y recursos

Lecturas relacionadas

1 comentarios

 
GN⁺ 3 시간 전
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