Génération d’images 1-bit Bonsai Image 4B pour appareils locaux

 (prismml.com)
1 points par GN⁺ 2 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Bonsai Image 4B est une famille compacte de modèles de génération d’images conçue pour exécuter une inférence par diffusion de haute qualité sur du matériel local, comme des ordinateurs portables et des téléphones
  • Elle conserve l’architecture de FLUX.2 Klein 4B tout en remplaçant les poids du transformeur de diffusion par une représentation 1-bit ou ternaire
  • La taille du transformeur de diffusion passe de 7.75GB pour l’original à 0.93GB en 1-bit et 1.21GB en ternaire, ce qui réduit la pression sur le budget mémoire
  • Sur un iPhone 17 Pro Max, elle génère une image 512×512 en 9.4 secondes ; sur un Mac M4 Pro, il faut environ 6 secondes, avec jusqu’à 5.6× plus de vitesse que MFLUX
  • La version ternaire conserve 95 % des performances de FLUX.2 Klein 4B, et les deux variantes seront publiées avec des poids ouverts et du code sous licence Apache 2.0

Bonsai Image 4B pour la génération d’images locale

  • Bonsai Image 4B est une famille compacte de modèles de génération d’images conçue pour exécuter une inférence par diffusion de haute qualité sur du matériel local, des ordinateurs portables aux téléphones
  • Basée sur FLUX.2 Klein 4B, elle en conserve l’architecture tout en convertissant les poids du transformeur de diffusion en format 1-bit ou ternaire
    • 1-bit Bonsai Image 4B utilise des poids de transformeur binaires {−1, +1} et des facteurs d’échelle FP16 par groupe, offrant 1.125 bit effectif par poids
    • Ternary Bonsai Image 4B utilise des poids de transformeur {−1, 0, +1} et des facteurs d’échelle FP16 par groupe, offrant 1.71 bit effectif par poids
  • La variante ternaire est plus volumineuse que la 1-bit, mais l’état 0 supplémentaire améliore la qualité visuelle et la fidélité au prompt
  • Avec ses poids ouverts et son inférence locale, Bonsai Image 4B vise une forme de déploiement permettant la génération d’images sur des appareils qui ne pouvaient pas exécuter facilement des modèles de cette catégorie
  • Selon PrismML, Bonsai Image 4B est le premier modèle d’image de cette classe de paramètres à s’exécuter directement sur iPhone

Réduction mémoire pour l’exécution locale

  • La principale contrainte de la génération d’images locale est que le modèle doit tenir dans le budget mémoire de l’appareil
  • Dans les modèles d’image de classe 4B, le transformeur de diffusion est la plus grosse partie du modèle et il est réexécuté à chaque étape de débruitage pendant la génération
  • La taille du transformeur a un impact direct sur la pression mémoire, les besoins en bande passante et la vitesse de l’inférence locale
  • Le transformeur de diffusion de FLUX.2 Klein 4B pèse 7.75GB ; celui de 1-bit Bonsai Image 4B, 0.93GB ; et celui de Ternary Bonsai Image 4B, 1.21GB
  • La variante 1-bit est 8.3× plus petite que FLUX.2 Klein 4B en pleine précision, et la variante ternaire 6.4× plus petite
  • Les couches binaires elles-mêmes réduisent d’environ 14× la taille par rapport aux poids du transformeur en pleine précision, mais environ 5 % des projection layers, sensibles à la précision, restent en FP16
  • Les couches ternaires offrent une réduction d’environ 10×, pour une taille finale de transformeur de 1.21GB

Payload de déploiement et mémoire d’exécution

  • Sur Apple Silicon, le payload de déploiement incluant l’encodeur de texte compressé et le VAE en FP16 est de 3.42GB pour la version 1-bit et 3.88GB pour la version ternaire
  • Le payload de déploiement de FLUX.2 Klein 4B en pleine précision est de 15.97GB
  • À l’exécution, l’encodeur de texte est déchargé après l’encodage du prompt, de sorte que l’usage mémoire moyen est inférieur au payload complet
  • Pour générer une image 512×512, la mémoire active moyenne est de 1.5GB pour la version 1-bit, 1.96GB pour la ternaire, et 11.74GB pour FLUX.2 Klein 4B d’origine
  • À 512×512, la réduction mémoire est de 7.8× pour la version 1-bit et de 6.0× pour la ternaire
  • Pour générer une image 1024×1024, la mémoire active moyenne est de 1.95GB pour la version 1-bit, 2.38GB pour la ternaire, et 14.39GB pour FLUX.2 Klein 4B d’origine
  • À 1024×1024, la réduction mémoire est de 7.4× pour la version 1-bit et de 6.0× pour la ternaire

Matériel pris en charge et performances d’exécution

  • La pile de déploiement prend en charge les iPhone, iPad et Mac Apple Silicon ainsi que les GPU CUDA
  • Sur le matériel Apple, elle utilise la voie low-bit de MLX ; sur CUDA, les kernels GEMM low-bit de Gemlite
  • Sur iPhone 17 Pro Max, le pipeline FLUX.2 Klein 4B en pleine précision ne tient pas dans le budget mémoire de l’appareil, mais les deux variantes de Bonsai Image s’exécutent on-device
  • Bonsai Image 4B génère une image 512×512 en 9.4 secondes sur iPhone 17 Pro Max
  • Sur Mac M4 Pro, elle génère une image 512×512 en environ 6 secondes
  • Sur Mac M4 Pro, Bonsai Image 4B est jusqu’à 5.6× plus rapide que le pipeline MFLUX en pleine précision par défaut

Performances sur les benchmarks

  • Bonsai Image 4B a été évalué sur trois benchmarks : GenEval, HPSv3 et DPG-Bench
  • GenEval évalue la composition d’objets et l’association d’attributs ; HPSv3 évalue les préférences humaines et la qualité esthétique ; DPG-Bench évalue le suivi dense du prompt et la fidélité sémantique
  • Ternary Bonsai Image 4B obtient 0.723 sur GenEval, 12.22 sur HPSv3 et 0.851 sur DPG-Bench avec un transformeur de diffusion de 1.21GB
  • Ternary Bonsai Image 4B conserve 95 % des performances de FLUX.2 Klein 4B tout en réduisant de 6.4× la taille du transformeur de diffusion
  • 1-bit Bonsai Image 4B obtient 0.671 sur GenEval, 11.15 sur HPSv3 et 0.822 sur DPG-Bench avec un transformeur de diffusion de 0.93GB
  • 1-bit Bonsai Image 4B conserve 88 % des performances de FLUX.2 Klein 4B tout en ramenant le transformeur de diffusion sous 1GB
  • FLUX.2 Klein 4B obtient 0.819 sur GenEval, 12.84 sur HPSv3 et 0.853 sur DPG-Bench avec un transformeur de diffusion de 7.75GB
  • SDXL obtient 0.3 sur GenEval, 10.05 sur HPSv3 et 0.74 sur DPG-Bench avec un transformeur de diffusion de 5.14GB, soit 67 % des performances de FLUX.2 Klein 4B
  • BK-SDM-Small obtient 0.297 sur GenEval, 3.05 sur HPSv3 et 0.559 sur DPG-Bench avec un transformeur de diffusion de 0.98GB, soit 42 % des performances de FLUX.2 Klein 4B
  • Stable Diffusion 1.5 obtient 0.396 sur GenEval, 4.2 sur HPSv3 et 0.601 sur DPG-Bench avec un transformeur de diffusion de 1.72GB, soit 51 % des performances de FLUX.2 Klein 4B
  • PixArt-Σ XL 2 obtient 0.541 sur GenEval, 11.93 sur HPSv3 et 0.769 sur DPG-Bench avec un transformeur de diffusion de 1.2GB, soit 83 % des performances de FLUX.2 Klein 4B
  • Les deux variantes de Bonsai restent compétitives face aux modèles d’image 4B modernes tout en conservant une empreinte de transformeur de diffusion bien plus réduite
  • Elles offrent de meilleures performances que des modèles plus petits ayant une empreinte mémoire comparable, apportant ainsi un comportement moderne de transformeur de diffusion dans une plage mémoire auparavant occupée par des modèles plus petits et moins performants

Ce que cela change pour les produits en inférence locale

  • La génération d’images dépend non seulement de la qualité du modèle, mais aussi de son mode de déploiement
  • Les API cloud restent adaptées à de nombreux produits, mais une génération exclusivement cloud transforme chaque prompt en requête distante et ajoute à chaque itération un coût de serving et une latence aller-retour
  • La génération d’images est naturellement itérative : les utilisateurs modifient leurs prompts, comparent les résultats, créent des variantes, écartent les échecs et réessaient
  • Si chaque tentative repose sur un traitement côté serveur, les utilisateurs doivent calculer le coût et attendre à chaque boucle créative
  • L’inférence locale permet d’intégrer directement la génération dans l’expérience produit une fois le modèle présent sur l’appareil
  • L’exécution locale réduit le coût d’exécution, accélère l’itération et convient mieux aux environnements où les prompts et les contenus générés doivent rester privés
  • Bonsai Image 4B constitue une étape vers un mode de déploiement de la génération d’images plus proche des utilisateurs, sur le matériel qu’ils possèdent déjà

Mode de publication et ressources

À lire aussi

1 commentaires

 
GN⁺ 2 시간 전
Avis sur Hacker News

  • Il y a 20 ans, je ne pense pas que beaucoup de gens imaginaient un Internet du futur où l’on ne pourrait pas faire confiance à ce que l’on voit ou lit
    J’espère qu’un jour nous regarderons cette époque comme une parenthèse de déviance, un peu comme la scène de Mad Men où la famille Draper quitte un pique-nique en laissant ses déchets sur la pelouse

    • Il y a 20 ans, les profs nous disaient de ne pas utiliser Wikipedia parce qu’on ne pouvait rien croire sur Internet, et de ne jamais sortir avec quelqu’un rencontré sur une app ou un site web. Ce genre de personne était forcément un meurtrier, et il y avait aussi le fameux « Internet, c’est pour le porno »
      Avec le temps, beaucoup de choses s’améliorent, et les gens ont tendance à toujours surestimer les risques sociaux quand une nouvelle technologie apparaît
    • La scène du pique-nique : https://www.youtube.com/watch?v=FDIvzDGBLWU
    • On dirait que beaucoup ont oublié les débats autour de Narrative Science(https://en.wikipedia.org/wiki/Narrative_Science)
      Cette entreprise, issue d’un spin-out universitaire, arrivait à écrire des articles de baseball plausibles à partir de simples statistiques, puis plus tard des articles financiers. Cela permettait aux sites d’info locale de publier des articles sur tous les matchs, ce qui profitait aux fans de sport et était vu comme un moteur clé d’augmentation du trafic web, mais beaucoup critiquaient cela comme n’étant pas du « vrai » contenu
      Un article de Slate sur le sujet en 2012 : https://slate.com/technology/2012/03/narrative-science-robot...
      Depuis l’existence des ordinateurs, on essaie de leur faire produire quelque chose qui ressemble à la parole humaine, et s’inquiéter que ce qu’on lit ou avec quoi on discute soit un robot imitant un humain n’a rien de nouveau
    • Parler de parenthèse de déviance me paraît être une réaction excessive
    • Il y a toujours eu de la désinformation dans le texte et l’image, et les photos pouvaient être truquées dès l’invention de la photographie
      C’est certes devenu plus facile, mais ce n’est pas un changement qualitativement totalement différent. Il y a 20 ans déjà, croire aveuglément tout ce qu’on voyait sur Internet aurait été tout aussi ridicule qu’aujourd’hui

  • J’attends vraiment avec impatience un futur où, au lieu de payer des abonnements coûteux, on pourra simplement mettre à niveau le matériel pour mettre à niveau son IA
    Parmi les problèmes que j’aimerais traiter, beaucoup demandent des dizaines de milliards de tokens, ce qui est aujourd’hui pratiquement inaccessible sans financement de projet par une entreprise. Une machine de génération ASIC capable de sortir des dizaines de milliers de tokens par seconde avec une qualité de niveau Opus 4.6 me suffirait

    • Une entreprise appelée Taalas construit quelque chose de similaire. Pas au niveau de qualité d’Opus 4.6, mais elle vise sans doute des modèles plus gros
      Pour l’instant, elle utilise un modèle LLama 8B, fonctionne à environ 17k tokens par seconde, et on peut l’essayer sur https://chatjimmy.ai/
    • Tu pourrais donner un exemple de ce type de problème ?
    • Je me demande à quoi ressembleraient les coûts de matériel et d’électricité par rapport au coût d’un abonnement
    • Logiquement, si cinq personnes mutualisent leurs ressources, elles sont plus fortes qu’une seule, donc les datacenters gagnent toujours
      C’est parce que leur taux d’utilisation dans le temps est plus élevé. J’ai souvent le même fantasme, mais logiquement je pense que c’en est un. En moyenne, on ne peut pas utiliser plus de matériel que l’ensemble du collectif qui l’exploite mieux
      Le matériel personnel s’améliorera aussi, mais la pointe de la technologie sera toujours dans le cloud

  • En voyant « 1-bit », ma première idée n’a pas été des poids de modèle en 1 bit, mais de la génération d’images noir et blanc tramées en 1 bit
    Du coup, je me suis demandé à quel point un générateur d’images par diffusion pourrait être intéressant, rapide et compressible si on limitait les images d’entraînement et l’espace de travail à des images 1 bit tramées avec Floyd-Steinberg, Atkinson, ou l’algorithme de son choix
    L’entraînement serait assez rapide, et ça tiendrait probablement même sur un GPU moderne unique

    • Je pense quand même qu’il vaudrait mieux entraîner en niveaux de gris puis appliquer le tramage ensuite
    • J’ai eu exactement la même pensée, et il semble y avoir là pas mal d’idées intéressantes à explorer

  • Question sincère : est-ce que cela résout un vrai problème ?
    Avec les modèles de diffusion, j’ai l’impression que le goulot d’étranglement, ce n’est pas le stockage ou la mémoire mais le temps de génération. Beaucoup de modèles tournent sur des GPU 8 à 12 Go de l’ère 1080 ou sur des Mac avec une mémoire comparable, et de toute façon cela correspond presque à une borne basse du point de vue des performances GPU. En plus, ces modèles semblent légèrement plus lents que le petit modèle FLUX.2 sur lequel ils reposent
    Bien sûr, cela pourrait permettre d’exécuter des modèles locaux sur des appareils comme l’iPhone, qui ont un GPU relativement puissant mais une mémoire limitée, mais est-ce vraiment un besoin si courant ?

    • C’est une avancée utile. Si une inférence à l’échelle locale produit une qualité correcte, on peut créer des produits qui génèrent des images jetables à volonté, sans se soucier du coût
      Jusqu’ici, tous les produits de génération d’images que j’ai vus étaient facturés à l’usage, ce qui limite fortement leur valeur. Je ne sais pas en revanche si cela atteint vraiment le seuil de « qualité correcte »
    • Nous sommes à une époque où la demande en GPU est extrêmement forte et l’offre limitée. Chaque fois qu’on déplace l’inférence vers l’edge, on libère des ressources cloud pour d’autres tâches
      Chaque gain d’efficacité augmente ce qu’on peut faire avec les ressources existantes. Si l’on peut rendre une image avec deux fois moins de calcul, il faut aussi deux fois moins de GPU
    • Les GPU 8 à 12 Go de l’ère 1080 ou les Mac à mémoire comparable ne sont pas la borne basse. La plupart des gens utilisent des ordinateurs portables ou des appareils mobiles bien moins puissants côté GPU
    • Pour l’instant, la valeur semble plus académique que pratique
      Même les modèles de pointe sont encore à peine utilisables, et en génération d’images, même les meilleurs produisent souvent des résultats médiocres. Donc un petit modèle 1 bit, forcément très en retrait par rapport à la pointe en capacité, me paraît difficile à utiliser dès maintenant
      En revanche, augmenter fortement la densité de capacité par unité de calcul est très significatif. Cela permet d’exécuter les modèles de pointe mieux et moins cher, de réduire la consommation de ressources, et d’élargir ce qui peut être fait en edge sur un laptop personnel ou un téléphone
      Du point de vue de la vie privée aussi, beaucoup de tâches devraient tourner sur l’appareil, et tout le monde ne possède pas un gros GPU dédié
    • Exact. La taille et les performances ne sont pas seulement un problème pour les LLM locaux, mais aussi pour les entreprises de LLM de pointe comme OpenAI et Anthropic
      Une entreprise comme Anthropic perd encore énormément d’argent sur l’inférence, et les progrès vers des modèles efficaces et performants aident la rentabilité

  • La phrase « À notre connaissance, Bonsai Image 4B est le premier modèle d’image de cette taille de paramètres à fonctionner directement sur iPhone » est fausse. Mais elle est formulée avec suffisamment de prudence pour ne pas être totalement fausse
    FLUX.2 [klein] 4B, donc à la même échelle de paramètres et en pratique essentiellement le même modèle, fonctionne sur iPhone via l’app Draw Things. Il utilise une quantification en 8 bits ou 6 bits, donc on peut dire que ce n’est pas « directement », mais cette réserve technique semble assez douteuse

  • On parle de modèle de diffusion, mais le modèle sous-jacent, Flux.2, est en fait un modèle de flux rectifié

    • Personnellement, je trouve acceptable d’utiliser « diffusion » pour désigner toute cette famille

  • Bizarre. Je visite depuis le Royaume-Uni et j’obtiens ceci :
    Website Not Allowed
    “⁦‪prismml.com‬⁩” is a restricted website.

  • D’ici un jour, quelqu’un aura entraîné un LoRA pour ce modèle 1 bit afin de générer du hentai sur Apple Watch

  • Si vous voulez l’exécuter sans bricoler le système de fichiers local, vous pouvez utiliser https://github.com/kordless/bonsai-docker

  • J’ai extrait le code de la démo web pour le brancher comme nœud de génération d’images web dans un outil de workflows IA dans le navigateur, et c’est plutôt pas mal
    J’attends que xenova l’ajoute à transformersjs 4.3, et à ce moment-là je le publierai aussi. Je n’avais pas envie d’attendre pour tester, donc j’ai essayé avant

    • Tu pourrais expliquer cet outil de workflows IA dans le navigateur ? Je suis peut-être en train de construire quelque chose de similaire, donc je suis très curieux de voir ce que d’autres font dans ce domaine