1-Bit Bonsai Image 4B zur Bildgenerierung auf lokalen Geräten

• Bonsai Image 4B ist eine Familie kompakter Bildgenerierungsmodelle, die für hochwertige Diffusions-Inferenz auf lokaler Hardware wie Laptops und Smartphones entwickelt wurde
• Die Architektur von FLUX.2 Klein 4B bleibt erhalten, während die Gewichte des Diffusion-Transformers in eine 1-Bit- oder ternäre Darstellung überführt werden
• Die Größe des Diffusion-Transformers schrumpft von ursprünglich 7,75 GB auf 0,93 GB bei 1-Bit bzw. 1,21 GB bei ternär und senkt damit die Belastung des Speicherbudgets
• Auf dem iPhone 17 Pro Max werden 512×512-Bilder in 9,4 Sekunden erzeugt; auf dem Mac M4 Pro dauert es rund 6 Sekunden und ist damit bis zu 5,6-mal schneller als MFLUX
• Die ternäre Variante hält gegenüber FLUX.2 Klein 4B 95 % der Leistung und beide Varianten sollen mit offenen Gewichten und Code unter Apache 2.0 veröffentlicht werden

---

Bonsai Image 4B für lokale Bildgenerierung

• Bonsai Image 4B ist eine Familie kompakter Bildgenerierungsmodelle, die für hochwertige Diffusions-Inferenz auf lokaler Hardware von Laptops bis hin zu Smartphones entwickelt wurde
• Es basiert auf FLUX.2 Klein 4B, behält die Architektur bei und wandelt lediglich die Gewichte des Diffusion-Transformers in 1-Bit- oder ternäre Form um
  • 1-Bit Bonsai Image 4B verwendet binäre Transformer-Gewichte {−1, +1} und FP16-Gruppenskalierungsfaktoren und liefert damit 1,125 effektive Bits pro Gewicht
  • Ternary Bonsai Image 4B verwendet Transformer-Gewichte {−1, 0, +1} und FP16-Gruppenskalierungsfaktoren und liefert damit 1,71 effektive Bits pro Gewicht
• Die ternäre Variante ist größer als die 1-Bit-Version, verbessert durch den zusätzlichen 0-Zustand aber die visuelle Qualität und die Prompt-Treue
• Mit offenen Gewichten und lokaler Inferenz zielt Bonsai Image 4B auf eine Bereitstellungsform ab, die Bildgenerierung auch auf Geräten ermöglicht, auf denen Modelle dieser Klasse bislang schwer ausführbar waren
• Laut PrismML ist Bonsai Image 4B das erste direkt auf dem iPhone laufende Bildmodell in dieser Parameterklasse

Speicherreduktion für lokale Ausführung

• Die zentrale Einschränkung lokaler Bildgenerierung besteht darin, dass das Modell in das Speicherbudget des Geräts passen muss
• Bei Bildmodellen der 4B-Klasse ist der Diffusion-Transformer der größte Teil des Modells und wird bei jedem Denoising-Schritt der Generierung wiederholt ausgeführt
• Die Größe des Transformers beeinflusst Speicherdruck, Bandbreitenanforderungen und die Geschwindigkeit lokaler Inferenz direkt
• Der Diffusion-Transformer von FLUX.2 Klein 4B ist 7,75 GB groß, 1-Bit Bonsai Image 4B kommt auf 0,93 GB und Ternary Bonsai Image 4B auf 1,21 GB
• Die 1-Bit-Variante ist gegenüber FLUX.2 Klein 4B in voller Präzision 8,3-mal, die ternäre Variante 6,4-mal kleiner
• Die binären Layer selbst werden gegenüber Transformer-Gewichten in voller Präzision um etwa das 14-Fache reduziert, doch rund 5 % der präzisionsempfindlichen Projection Layer bleiben in FP16
• Die ternären Layer liefern eine Reduktion um etwa das 10-Fache, wodurch der finale Transformer auf 1,21 GB kommt

Deployment-Payload und Laufzeitspeicher

• Die Apple-Silicon-Deployment-Payload inklusive komprimiertem Text-Encoder und FP16-VAE beträgt 3,42 GB für 1-Bit und 3,88 GB für ternär
• Die Deployment-Payload von FLUX.2 Klein 4B in voller Präzision beträgt 15,97 GB
• Zur Laufzeit wird der Text-Encoder nach dem Prompt-Encoding ausgelagert, daher liegt die durchschnittliche Speichernutzung unter der gesamten Payload
• Bei der Erzeugung von 512×512-Bildern beträgt der durchschnittlich aktive Speicher 1,5 GB für 1-Bit, 1,96 GB für ternär und 11,74 GB für das ursprüngliche FLUX.2 Klein 4B
• Bezogen auf 512×512 beträgt die Speicherreduktion beim 1-Bit-Modell das 7,8-Fache und beim ternären Modell das 6,0-Fache
• Bei der Erzeugung von 1024×1024-Bildern beträgt der durchschnittlich aktive Speicher 1,95 GB für 1-Bit, 2,38 GB für ternär und 14,39 GB für das ursprüngliche FLUX.2 Klein 4B
• Bezogen auf 1024×1024 beträgt die Speicherreduktion beim 1-Bit-Modell das 7,4-Fache und beim ternären Modell das 6,0-Fache

Unterstützte Hardware und Ausführungsleistung

• Der Deployment-Stack unterstützt Apple Silicon iPhone, iPad, Mac sowie CUDA-GPUs
• Auf Apple-Hardware wird der MLX-Low-Bit-Pfad verwendet, auf CUDA Gemlite Low-Bit GEMM Kernel
• Auf dem iPhone 17 Pro Max passt die FLUX.2-Klein-4B-Pipeline in voller Präzision nicht in das Speicherbudget des Geräts, die beiden Bonsai-Image-Varianten laufen jedoch direkt auf dem Gerät
• Bonsai Image 4B erzeugt auf dem iPhone 17 Pro Max ein 512×512-Bild in 9,4 Sekunden
• Auf dem Mac M4 Pro wird ein 512×512-Bild in rund 6 Sekunden erzeugt
• Auf dem Mac M4 Pro ist Bonsai Image 4B bis zu 5,6-mal schneller als die standardmäßige MFLUX-Pipeline in voller Präzision

Benchmark-Leistung

• Bonsai Image 4B wurde mit den drei Benchmarks GenEval, HPSv3 und DPG-Bench evaluiert
• GenEval bewertet Objektkomposition und Attributbindung, HPSv3 menschliche Präferenz und ästhetische Qualität, DPG-Bench dichte Prompt-Befolgung und semantische Treue
• Ternary Bonsai Image 4B erreicht mit einem 1,21-GB-Diffusion-Transformer 0,723 in GenEval, 12,22 in HPSv3 und 0,851 in DPG-Bench
• Ternary Bonsai Image 4B hält gegenüber FLUX.2 Klein 4B 95 % der Leistung, während die Größe des Diffusion-Transformers um das 6,4-Fache sinkt
• 1-Bit Bonsai Image 4B erreicht mit einem 0,93-GB-Diffusion-Transformer 0,671 in GenEval, 11,15 in HPSv3 und 0,822 in DPG-Bench
• 1-Bit Bonsai Image 4B hält gegenüber FLUX.2 Klein 4B 88 % der Leistung, während der Diffusion-Transformer unter 1 GB sinkt
• FLUX.2 Klein 4B erreicht mit einem 7,75-GB-Diffusion-Transformer 0,819 in GenEval, 12,84 in HPSv3 und 0,853 in DPG-Bench
• SDXL erreicht mit einem 5,14-GB-Diffusion-Transformer 0,3 in GenEval, 10,05 in HPSv3 und 0,74 in DPG-Bench und kommt damit auf 67 % der Leistung von FLUX.2 Klein 4B
• BK-SDM-Small erreicht mit einem 0,98-GB-Diffusion-Transformer 0,297 in GenEval, 3,05 in HPSv3 und 0,559 in DPG-Bench und kommt damit auf 42 % der Leistung von FLUX.2 Klein 4B
• Stable Diffusion 1.5 erreicht mit einem 1,72-GB-Diffusion-Transformer 0,396 in GenEval, 4,2 in HPSv3 und 0,601 in DPG-Bench und kommt damit auf 51 % der Leistung von FLUX.2 Klein 4B
• PixArt-Σ XL 2 erreicht mit einem 1,2-GB-Diffusion-Transformer 0,541 in GenEval, 11,93 in HPSv3 und 0,769 in DPG-Bench und kommt damit auf 83 % der Leistung von FLUX.2 Klein 4B
• Beide Bonsai-Varianten konkurrieren mit modernen Bildmodellen der 4B-Klasse und halten den Footprint des Diffusion-Transformers dennoch deutlich kleiner
• Sie liefern höhere Leistung als kleinere Modelle mit ähnlichem Speicher-Footprint und bringen damit modernes Diffusion-Transformer-Verhalten in einen Speicherbereich, der bislang kleineren und leistungsschwächeren Modellen vorbehalten war

Produktbedeutung lokaler Inferenz

• Bildgenerierung wird nicht nur von der Modellqualität, sondern auch von der Bereitstellungsform bestimmt
• Cloud-APIs bleiben für viele Produkte sinnvoll, doch rein cloudbasierte Generierung macht jeden Prompt zu einer Remote-Anfrage und fügt jeder Iteration Serving-Kosten sowie Roundtrip-Latenz hinzu
• Bildgenerierung ist von Natur aus iterativ: Nutzer passen Prompts an, vergleichen Ergebnisse, erzeugen Varianten, verwerfen Fehlversuche und probieren erneut
• Wenn jeder Versuch serverseitige Arbeit erfordert, müssen Nutzer in jeder kreativen Schleife Kosten abwägen und warten
• Lokale Inferenz ermöglicht es, die Generierungsfunktion nach dem Laden des Modells direkt in das Produkterlebnis einzubetten
• Lokale Ausführung senkt die Betriebskosten, beschleunigt Iterationen und ist leichter in Umgebungen nutzbar, in denen Prompts und generierte Assets privat bleiben müssen
• Bonsai Image 4B ist ein Schritt hin zu einer Bereitstellungsform für Bildgenerierung, die näher an die Nutzer und auf bereits vorhandene Hardware rückt

Veröffentlichungsform und Ressourcen

• 1-Bit Bonsai Image 4B und Ternary Bonsai Image 4B sollen mit offenen Gewichten und Code veröffentlicht werden
• Die Lizenz ist Apache 2.0
• PrismML veröffentlicht außerdem die iOS-App Bonsai Studio, mit der sich Bonsai Image 4B direkt auf dem iPhone testen lässt
• Whitepaper
• Hugging Face
• WebGPU demo
• Bonsai Studio for iPhone
• GitHub

[GN⁺]

Hacker-News-Kommentare

• Vor 20 Jahren hätte wohl niemand mit einem Internet der Zukunft gerechnet, dem man nicht vertrauen kann, wenn es darum geht, ob das, was wir sehen oder lesen, echt ist.
  Hoffentlich werden wir eines Tages auf diese Ära als eine Phase der Entgleisung zurückblicken, so wie in Mad Men die Szene, in der die Familie Draper ihren Picknickmüll auf den Rasen wirft und einfach wegfährt.

  • Vor 20 Jahren sagten Lehrer, man solle Wikipedia nicht benutzen, weil man im Internet nichts glauben könne, und man solle niemals mit jemandem ausgehen, den man in einer App oder auf einer Website kennengelernt hat. Solche Leute seien zu 100 % Mörder, und es gab auch den Spruch: „Das Internet ist für Pornos.“
    Mit der Zeit wird vieles besser, und Menschen neigen dazu, die gesellschaftlichen Risiken neuer Technologien anfangs immer zu überschätzen.
  • Die Picknick-Szene: https://www.youtube.com/watch?v=FDIvzDGBLWU
  • Offenbar erinnert man sich nicht an die Debatte um Narrative Science(https://en.wikipedia.org/wiki/Narrative_Science).
    Das Unternehmen war ein Spin-out aus einer Universität und konnte allein auf Basis von Statistiken plausible Baseball-Artikel und später auch Finanzartikel schreiben. Es galt als großer Vorteil für Sportfans, weil lokale Nachrichtenseiten damit Berichte zu jedem Spiel veröffentlichen konnten, und wurde als zentraler Treiber für mehr Web-Traffic gesehen, bekam aber auch viel Kritik, weil es nicht „echt“ sei.
    Ein Artikel von Slate dazu aus dem Jahr 2012: https://slate.com/technology/2012/03/narrative-science-robot...
    Seit es Computer gibt, versuchen Menschen, Computer so klingen zu lassen wie Menschen, und die Sorge, dass das, womit ich spreche oder was ich lese, ein Roboter ist, der Menschen imitiert, ist ebenfalls nichts Neues.
  • „Phase der Entgleisung“ wirkt dafür wie eine Überreaktion.
  • Bei Texten und Bildern gab es schon immer Desinformation, und Fotos konnten seit den Anfängen der Fotografie manipuliert werden.
    Sicher wird das einfacher, aber qualitativ ist es kein völlig anderer Wandel. Dem, was man vor 20 Jahren im Internet gesehen hat, einfach so zu glauben, wäre genauso lächerlich gewesen wie heute.

• Ich freue mich wirklich auf eine Zukunft, in der ich statt teurer Abos einfach meine Hardware aufrüste und damit meine AI aufrüste.
  Unter den Problemen, die ich lösen möchte, gibt es viele, die Milliarden von Tokens brauchen, und derzeit ist das ohne Förderung durch ein Unternehmensprojekt praktisch unerreichbar. Eine ASIC-Generierungsmaschine, die bei Opus-4.6-Niveau Zehntausende Tokens pro Sekunde ausspucken kann, wäre völlig ausreichend.

  • Eine Firma namens Taalas baut etwas Ähnliches. Nicht auf Opus-4.6-Niveau, aber vermutlich mit dem Ziel größerer Modelle.
    Aktuell nutzt sie ein LLama-8B-Modell, läuft mit etwa 17k Tokens pro Sekunde und lässt sich unter https://chatjimmy.ai/ testen.
  • Kannst du ein Beispiel für so ein Problem nennen?
  • Ich frage mich, wie sich Hardware- und Stromkosten im Vergleich zu Abo-Kosten verhalten würden.
  • Logisch gesehen ist es stärker, wenn sich fünf Personen Ressourcen teilen, als wenn es nur eine tut, daher gewinnen Rechenzentren immer.
    Der Grund ist die höhere zeitliche Auslastung. Ich fantasiere darüber auch ständig, aber logisch betrachtet ist es eine Illusion. Im Durchschnitt kann man nicht mehr verbrauchen als die Gesamtgruppe, die Hardware einfach besser auslastet.
    Private Hardware wird auch besser werden, aber der Stand der Technik wird immer in der Cloud sein.

• Als ich „1-bit“ sah, dachte ich zuerst nicht an 1-Bit-Modellgewichte, sondern an 1-Bit-Schwarzweiß-Bildgenerierung mit Dithering.
  Deshalb habe ich mich gefragt, wie cool, schnell und kompakt ein Diffusions-Bildgenerator wäre, wenn man Trainingsbilder und Arbeitsraum auf 1-Bit-Bilder beschränkt, die mit Floyd-Steinberg, Atkinson oder einem anderen bevorzugten Algorithmus gedithert wurden.
  Das Training wäre ziemlich schnell und würde vermutlich sogar auf eine einzelne moderne GPU passen.

  • Ich denke trotzdem, es wäre besser, in Graustufen zu trainieren und erst später zu dithern.
  • Ich hatte exakt denselben Gedanken, und es scheint hier einige spannende Ideen zu geben, die man weiter erforschen könnte.

• Ernst gemeinte Frage: Löst das eigentlich ein reales Problem?
  Bei Diffusionsmodellen ist der Flaschenhals aus meiner Sicht nicht Speicherplatz oder RAM, sondern die Generierungszeit. Viele Modelle laufen auf GPUs der 1080-Generation mit 8 bis 12 GB oder auf Macs mit ähnlicher Speicherausstattung, und aus Sicht der GPU-Leistung ist das ohnehin schon fast die Untergrenze. Außerdem scheinen diese Modelle sogar etwas langsamer zu sein als das kleinere zugrunde liegende FLUX.2-Modell.
  Natürlich könnte das helfen, lokale Modelle auf Geräten mit relativ starker GPU, aber begrenztem Speicher wie dem iPhone laufen zu lassen, aber ist das wirklich ein häufiges Bedürfnis?

  • Es ist ein nützlicher Fortschritt. Wenn Inference im lokalen Maßstab eine halbwegs ordentliche Qualität erreicht, kann man Produkte bauen, die Bilder erzeugen, die man oft und ohne Kostensorgen wieder verwerfen kann.
    Alle Bildgenerierungsprodukte, die ich bisher gesehen habe, rechnen nutzungsbasiert ab, was ihren Wert stark einschränkt. Ob das hier tatsächlich schon den Punkt „ordentliche Qualität“ erreicht, weiß ich allerdings nicht.
  • Wir leben derzeit in einer Zeit extrem hoher GPU-Nachfrage bei begrenztem Angebot. Jedes Mal, wenn man Inference an den Edge-Bereich verlagert, werden Cloud-Ressourcen für andere Aufgaben frei.
    Jede Effizienzsteigerung erhöht, was man mit den vorhandenen Ressourcen machen kann. Wenn man Bilder mit der halben Rechenleistung rendern kann, braucht man auch nur halb so viele GPUs.
  • Eine GPU der 1080-Generation mit 8 bis 12 GB oder ein Mac mit ähnlichem Speicher ist nicht die Untergrenze. Die meisten Menschen nutzen Laptops oder mobile Geräte mit deutlich schwächerer GPU-Leistung.
  • Der aktuelle Wert scheint eher wissenschaftlicher Natur zu sein als für den praktischen Einsatz.
    Selbst Frontier-Modelle sind bislang nur gerade so brauchbar, und bei der Bildgenerierung liefern selbst die besten Modelle oft miserable Ergebnisse. Deshalb dürfte ein kleines 1-Bit-Modell, das gegenüber der Frontier in seinen Fähigkeiten zwangsläufig weit zurückliegt, kurzfristig schwer nutzbar sein.
    Aber die Fähigkeitsdichte pro Recheneinheit massiv zu erhöhen, ist sehr bedeutsam. Man kann Frontier-Modelle besser und günstiger betreiben und den Ressourcenverbrauch senken, außerdem erweitert es die Bandbreite dessen, was auf dem Edge, etwa auf privaten Laptops oder Smartphones, möglich ist.
    Auch aus Datenschutzsicht gibt es viele Aufgaben, die auf dem Gerät selbst laufen sollten, und nicht jeder besitzt eine große dedizierte GPU.
  • Genau. Größe und Leistung sind nicht nur für lokale LLMs ein Problem, sondern auch für Frontier-LLM-Unternehmen wie OpenAI und Anthropic.
    Firmen wie Anthropic machen bei Inference immer noch enorme Verluste, und Fortschritte bei effizienten, leistungsstarken Modellen helfen der Profitabilität.

• Der Satz „Soweit wir wissen, ist Bonsai Image 4B das erste Bildmodell dieser Parametergröße, das direkt auf dem iPhone läuft“ ist falsch. Er ist nur vorsichtig genug formuliert, um nicht komplett falsch zu sein.
  FLUX.2 [klein] 4B, also dieselbe Parametergröße und praktisch dasselbe Modell, läuft auf dem iPhone über die App Draw Things. Es verwendet 8-Bit- oder 6-Bit-Quantisierung, daher kann man argumentieren, dass es nicht „direkt“ läuft, aber dieser technische Vorbehalt wirkt ziemlich verdächtig.

• Man nennt es zwar ein Diffusionsmodell, aber das zugrunde liegende Flux.2 ist ein Rectified-Flow-Modell.

  • Ich persönlich finde es okay, „Diffusion“ als Bezeichnung für diese ganze Familie zu verwenden.

• Merkwürdig. Ich bin Besucher aus Großbritannien, und bei mir erscheint Folgendes:
  Website Not Allowed
  “⁦‪prismml.com‬⁩” is a restricted website.

• Innerhalb eines Tages wird jemand ein LoRA für dieses 1-Bit-Modell trainieren, damit es auf der Apple Watch Hentai-Inhalte erzeugt.

• Wenn man es ausführen will, ohne am lokalen Dateisystem herumzufummeln, kann man https://github.com/kordless/bonsai-docker verwenden.

• Ich habe den Code aus der Web-Demo extrahiert und als Web-Bildgenerierungs-Node an ein browserinternes AI-Workflow-Tool gehängt, und das funktioniert ziemlich gut.
  Ich warte darauf, dass xenova das in transformersjs 4.3 aufnimmt; dann werde ich es auch veröffentlichen. Ich konnte mit dem Testen nicht warten und habe es daher schon vorher ausprobiert.

  • Könntest du dieses browserinterne AI-Workflow-Tool näher erklären? Ich baue vielleicht etwas Ähnliches und bin sehr neugierig, was andere Leute in diesem Bereich entwickeln.