Bonsai Image 4B – 1-Bit-/ternäres Bildgenerierungsmodell für lokale Geräte

 (prismml.com)
3 Punkte von GN⁺ 2026-06-01 | 1 Kommentare | Auf WhatsApp teilen
  • Eine Familie kompakter Bildgenerierungsmodelle, die für hochwertige Diffusions-Inferenz auf lokaler Hardware wie Laptops und Smartphones entwickelt wurde
  • Behält die FLUX.2 Klein 4B-Architektur bei, ersetzt jedoch die Gewichte des Diffusion-Transformers durch 1-Bit- oder ternäre Darstellungen
  • Die Größe des Diffusion-Transformers sinkt von ursprünglich 7,75 GB auf 0,93 GB bei 1-Bit und 1,21 GB bei ternär, was die Belastung des Speicherbudgets senkt
  • Erzeugt auf dem iPhone 17 Pro Max ein 512×512-Bild in 9,4 Sekunden; auf dem Mac M4 Pro etwa in 6 Sekunden und damit bis zu 5,6-mal schneller als MFLUX
  • Die ternäre Variante hält 95 % der Leistung von FLUX.2 Klein 4B 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 Smartphones entwickelt wurde
  • Es basiert auf FLUX.2 Klein 4B und behält die Architektur bei, während die Gewichte des Diffusion-Transformers in 1-Bit- oder ternäre Form überführt werden
    • 1-bit Bonsai Image 4B nutzt binäre Transformer-Gewichte {−1, +1} und FP16-Skalierungsfaktoren auf Gruppenebene und bietet damit 1,125 effektive Bit pro Gewicht
    • Ternary Bonsai Image 4B nutzt ternäre Transformer-Gewichte {−1, 0, +1} und FP16-Skalierungsfaktoren auf Gruppenebene und bietet damit 1,71 effektive Bit pro Gewicht
  • Die ternäre Variante ist größer als 1-Bit, verbessert aber durch den zusätzlichen 0-Zustand die visuelle Qualität und die Prompt-Treue
  • Mit offenen Gewichten und lokaler Inferenz zielt Bonsai Image 4B auf eine Bereitstellungsform, die Bildgenerierung auch auf Geräten ermöglicht, auf denen Modelle dieser Klasse bislang schwer auszuführen waren
  • Laut PrismML ist Bonsai Image 4B unter Bildmodellen dieser Parameterklasse das erste Modell, das direkt auf dem iPhone läuft

Speicherreduktion für lokale Ausführung

  • Die zentrale Einschränkung lokaler Bildgenerierung ist, 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 während der Generierung in jedem Denoising-Schritt wiederholt ausgeführt
  • Die Größe des Transformers wirkt sich direkt auf Speicherdruck, Bandbreitenanforderungen und die Geschwindigkeit lokaler Inferenz aus
  • Der Diffusion-Transformer von FLUX.2 Klein 4B ist 7,75 GB groß, 1-bit Bonsai Image 4B 0,93 GB und Ternary Bonsai Image 4B 1,21 GB
  • Die 1-Bit-Variante ist gegenüber FLUX.2 Klein 4B in voller Präzision 8,3-mal kleiner, die ternäre Variante 6,4-mal
  • Die binären Layer selbst sind gegenüber den Transformer-Gewichten in voller Präzision um etwa das 14-Fache reduziert, aber rund 5 % der präzisionsempfindlichen projection layer bleiben in FP16
  • Die ternären Layer bieten eine Reduktion um etwa den Faktor 10, wodurch die endgültige Transformer-Größe 1,21 GB beträgt

Bereitstellungspayload und Laufzeitspeicher

  • Die Apple-Silicon-Bereitstellungspayload einschließlich komprimiertem Text-Encoder und FP16-VAE beträgt 3,42 GB für 1-Bit und 3,88 GB für ternär
  • Die Bereitstellungspayload von FLUX.2 Klein 4B in voller Präzision beträgt 15,97 GB
  • Zur Laufzeit wird der Text-Encoder nach der Prompt-Kodierung ausgelagert, sodass die durchschnittliche Speichernutzung unter der gesamten Payload liegt
  • Bei der Generierung eines 512×512-Bildes 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 das 7,8-Fache für 1-Bit und das 6,0-Fache für ternär
  • Bei der Generierung eines 1024×1024-Bildes 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 das 7,4-Fache für 1-Bit und das 6,0-Fache für ternär

Unterstützte Hardware und Ausführungsleistung

  • Der Bereitstellungs-Stack unterstützt Apple-Silicon-iPhone, iPad, Mac sowie CUDA-GPUs
  • Auf Apple-Hardware wird der MLX-Low-Bit-Pfad genutzt, unter CUDA die 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 on-device
  • 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 etwa 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 bewertet menschliche Präferenz und ästhetische Qualität, und DPG-Bench bewertet dichte Prompt-Befolgung und semantische Treue
  • Ternary Bonsai Image 4B erreicht mit einem 1,21-GB-Diffusion-Transformer 0,723 bei GenEval, 12,22 bei HPSv3 und 0,851 bei DPG-Bench
  • Ternary Bonsai Image 4B hält 95 % der Leistung von FLUX.2 Klein 4B, 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 bei GenEval, 11,15 bei HPSv3 und 0,822 bei DPG-Bench
  • 1-bit Bonsai Image 4B hält 88 % der Leistung von FLUX.2 Klein 4B, während der Diffusion-Transformer unter 1 GB sinkt
  • FLUX.2 Klein 4B erreicht mit einem 7,75-GB-Diffusion-Transformer 0,819 bei GenEval, 12,84 bei HPSv3 und 0,853 bei DPG-Bench
  • SDXL erreicht mit einem 5,14-GB-Diffusion-Transformer 0,3 bei GenEval, 10,05 bei HPSv3 und 0,74 bei 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 bei GenEval, 3,05 bei HPSv3 und 0,559 bei 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 bei GenEval, 4,2 bei HPSv3 und 0,601 bei 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 bei GenEval, 11,93 bei HPSv3 und 0,769 bei 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 gleichzeitig den Footprint des Diffusion-Transformers deutlich kleiner
  • Gegenüber kleineren Modellen mit ähnlichem Speicher-Footprint liefern sie höhere Leistung und bringen damit modernes Diffusion-Transformer-Verhalten in einen Speicherbereich, der bisher kleineren und leistungsschwächeren Modellen vorbehalten war

Produktrelevanz lokaler Inferenz

  • Bildgenerierung hängt nicht nur von der Modellqualität ab, sondern auch von der Art der Bereitstellung
  • Cloud-APIs bleiben für viele Produkte geeignet, aber reine Cloud-Generierung macht jeden Prompt zu einer Remote-Anfrage und fügt jeder Iteration Serving-Kosten und Round-Trip-Latenz hinzu
  • Bildgenerierung ist von Natur aus iterativ: Nutzer passen Prompts an, vergleichen Ergebnisse, erzeugen Varianten, verwerfen Fehlversuche und versuchen es erneut
  • Wenn jeder Versuch serverseitige Arbeit erfordert, müssen Nutzer in jeder kreativen Schleife Kosten einkalkulieren und warten
  • Lokale Inferenz ermöglicht es, die Generierungsfunktion nach dem Laden des Modells auf das Gerät direkt in das Produkterlebnis einzubetten
  • Lokale Ausführung senkt die Betriebskosten, beschleunigt Iterationen und ist einfacher in Umgebungen einsetzbar, in denen Prompts und generierte Assets vertraulich bleiben müssen
  • Bonsai Image 4B ist ein Schritt hin zu einer Bereitstellungsform der Bildgenerierung, die näher an den Nutzern auf bereits vorhandener Hardware stattfindet

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 ausprobieren lässt
  • Whitepaper
  • Hugging Face
  • WebGPU demo
  • Bonsai Studio for iPhone
  • GitHub

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-06-01
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.