Bonsai 27B: 1-Bit-Modell läuft auf dem iPhone

Bonsai 27B komprimiert ein multimodales 27B-Modell auf bis zu 3,9 GB und läuft laut PrismML mit rund 11 Token pro Sekunde auf einem iPhone 17 Pro Max. Der technische Fortschritt ist relevant: Statt eines kleinen Smartphone-Modells bringt PrismML eine stark komprimierte Variante von Qwen3.6-27B auf lokale Geräte. Die entscheidenden Einschränkungen stehen jedoch im Whitepaper: Nur die binäre 1-Bit-Version passt in das Smartphone-Budget, die Ternary-Version benötigt in der tatsächlich ausgelieferten Form etwa 7,2 GB statt der oft genannten 5,9 GB, und sämtliche Leistungswerte stammen vom Hersteller.

PrismML hat Bonsai 27B am 14. Juli 2026 veröffentlicht. Die Modellgewichte sind über Hugging Face öffentlich zugänglich, das Demo-Repository steht auf GitHub, und der Anbieter nennt Apache 2.0 als Lizenz. Zusätzlich gibt es laut Ankündigung eine zeitlich begrenzte kostenlose Entwickler-Preview über eine API. Damit ist der Release nicht nur eine Forschungsdemo, sondern grundsätzlich testbar.

Was PrismML mit Bonsai 27B veröffentlicht hat

Bonsai 27B basiert laut offizieller Ankündigung auf Qwen3.6-27B. Das Ausgangsmodell ist ein multimodales Hybrid-Attention-Modell mit 27 Milliarden Parametern. Rund drei Viertel der Schichten verwenden nach Angaben im Whitepaper lineare Attention, während 16 von 64 Schichten einen wachsenden Full-Attention-KV-Cache führen. Diese Architektur ist für lange Kontexte günstiger als ein vollständig dichter Transformer.

PrismML bietet zwei stark komprimierte Varianten an:

• 1-bit Bonsai 27B verwendet binäre Gewichte mit den Werten minus eins und plus eins sowie gruppenweise FP16-Skalierung. Der effektive Speicherbedarf liegt laut Whitepaper bei 1,125 Bit pro Gewicht. Die GGUF-Sprachmodellgewichte belegen ungefähr 3,9 GB.
• Ternary Bonsai 27B verwendet Gewichte mit minus eins, null und plus eins. Die theoretische Informationsdichte beträgt 1,71 Bit pro Gewicht. Die Variante zielt auf höhere Qualität und lokale Nutzung auf Laptops oder GPUs.
• Beide Varianten unterstützen laut Anbieter Reasoning, Tool-Aufrufe, lange Kontexte und multimodale Eingaben. Der Vision-Tower wird separat und in komprimierter Form ausgeliefert.
• Die Laufzeiten umfassen GGUF für llama.cpp sowie MLX-Pakete für Apple Silicon. Für NVIDIA-Hardware stellt PrismML CUDA-Pfade bereit.

Der Begriff „1-Bit-Modell“ darf dabei nicht so verstanden werden, dass jeder Teil des Systems ausschließlich mit einem Bit arbeitet. Die Gewichte des Sprachmodells werden binär gespeichert, doch Skalierungswerte, Aktivierungen und numerisch empfindliche Berechnungen bleiben in höherer Präzision. Der Vision-Tower nutzt laut Whitepaper eine 4-Bit-HQQ-Repräsentation. Das ist technisch normal, sollte aber bei extremen Kompressionsangaben transparent bleiben.

3,9 GB auf dem iPhone: Was der Claim wirklich bedeutet

Die spektakulärste Aussage lautet, Bonsai 27B sei das erste Modell dieser Größenklasse, das auf einem Smartphone läuft. Belegt wird dies durch eine Messung auf einem iPhone 17 Pro Max mit A19 Pro. Das Whitepaper nennt für die binäre Variante 11,0 Token pro Sekunde bei der Generierung von 128 Token sowie 111 Token pro Sekunde bei der Verarbeitung eines 512-Token-Prompts.

Das ist für ein lokal ausgeführtes 27B-Modell eine interaktive Geschwindigkeit. Es ist aber keine Aussage darüber, wie schnell ein vollständiger Agentenlauf mit Kamera, langem Kontext, mehreren Werkzeugen und großen Dokumenten arbeitet. Die Veröffentlichung trennt deshalb sinnvoll zwischen Gewichtsspeicher, Kontextspeicher und optionalen Komponenten.

Für das Smartphone sind vor allem vier Grenzen relevant:

• Die 3,9 GB beziehen sich auf die binären GGUF-Gewichte des Sprachmodells. Das MLX-Paket ist laut Whitepaper größer, weil Container und Vision-Komponenten zusätzlichen Speicher benötigen.
• Ein Smartphone stellt einer einzelnen App nicht den gesamten physischen Arbeitsspeicher zur Verfügung. PrismML kalkuliert bei einem Gerät mit 12 GB RAM mit ungefähr 6 GB nutzbarem App-Budget.
• Der KV-Cache wächst mit dem Kontext. Selbst ein Modell, dessen Gewichte passen, kann bei langen Unterhaltungen oder großen Dokumenten an die Speichergrenze stoßen.
• Die auf der Ankündigungsseite gezeigte multimodale iPhone-Demo ist ausdrücklich als „Cached & Prefilled Image Context“ gekennzeichnet. Sie ist daher kein vollständiger Beweis für beliebig lange Live-Vision-Agenten auf dem Smartphone.

Das Whitepaper berichtet für die 1-Bit-Version auf Apple-Hardware einen gemessenen Spitzenbedarf von etwa 5,9 GB bei 4.000 Kontexttoken und 6,3 GB bei 10.000 Token im MLX-Pfad ohne KV-Cache-Kompression. Bei 100.000 Token steigt der Wert auf 12,2 GB. Mit 4-Bit-KV-Cache soll der Bedarf deutlich sinken. Der wichtige Punkt lautet daher nicht „262.000 Token passen immer aufs iPhone“, sondern: Das Modell kann lokal auf einem High-End-Smartphone starten und interaktiv generieren; der praktisch nutzbare Kontext bleibt vom Speicherbudget abhängig.

Die 5,9-GB-Falle bei Ternary Bonsai 27B

In der Ankündigung wird Ternary Bonsai 27B prominent mit 5,9 GB beschrieben. Das ist laut Whitepaper die ideale Größe aus der theoretischen 1,71-Bit-Repräsentation. Die aktuell ausgelieferten Kernel speichern jeden ternären Wert jedoch in einem 2-Bit-Slot. Dadurch liegt der tatsächlich gepackte GGUF-Footprint des Sprachmodells bei ungefähr 7,2 GB.

Diese Differenz ist nicht kleinlich. Sie entscheidet darüber, ob ein Modell in einen bestimmten RAM- oder VRAM-Rahmen passt. PrismML erklärt die Abweichung im technischen Bericht nachvollziehbar und nennt native ternäre Kernel als aktives Entwicklungsziel. Für Nutzer gilt bis dahin:

• 5,9 GB sind die theoretische Zielgröße der ternären Repräsentation.
• Rund 7,2 GB sind die praktisch ausgelieferte GGUF-Größe des ternären Sprachmodells.
• Etwa 3,9 GB erreicht die binäre GGUF-Version ohne vergleichbare Packungslücke.
• Vision-Tower, DSpark-Drafter, KV-Cache, Aktivierungen und Laufzeitpuffer kommen je nach Nutzung zusätzlich hinzu.

Genau diese Trennung macht den Release technisch interessanter als eine bloße „27B auf dem Handy“-Schlagzeile. PrismML zeigt nicht nur eine kleine Datei, sondern dokumentiert, welche Komponenten dauerhaft im Speicher liegen und welche optional geladen werden.

Benchmark-Einordnung: Viel Qualität bleibt, aber nicht überall

PrismML evaluiert die Modelle laut Whitepaper mit EvalScope und vLLM auf NVIDIA H100. Die 15 Tests decken Wissen, Mathematik, Coding, Anweisungsbefolgung, Tool-Nutzung und Vision ab. Alle Varianten sollen über dieselbe Infrastruktur und denselben Scoring-Pfad gelaufen sein. Das verbessert die interne Vergleichbarkeit, ersetzt aber keine unabhängige Reproduktion.

Die vom Hersteller gemeldeten Durchschnittswerte lauten:

• Qwen3.6-27B in FP16 erreicht 85,07 Punkte bei ungefähr 54 GB.
• Ternary Bonsai 27B erreicht 80,49 Punkte und damit 94,6 Prozent des FP16-Durchschnitts.
• 1-bit Bonsai 27B erreicht 76,11 Punkte und damit 89,5 Prozent des FP16-Durchschnitts.
• Eine konventionelle Qwen-IQ2-XXS-Quantisierung erreicht laut demselben Test 72,73 Punkte bei 9,4 GB.

Die Verluste sind ungleich verteilt. Mathematik bleibt laut Hersteller mit 93,40 Punkten bei Ternary und 91,66 bei 1-Bit relativ nah an 95,33 Punkten der FP16-Basis. Coding sinkt von 88,74 auf 85,96 beziehungsweise 81,88. Deutlicher fällt der Abstand bei Tool-Nutzung, Anweisungsbefolgung und Vision aus. Bei Agentic- und Tool-Calling-Tests meldet PrismML 80,00 Punkte für FP16, 74,01 für Ternary und 66,03 für 1-Bit. Vision fällt von 72,61 auf 65,19 beziehungsweise 59,57.

Das widerspricht nicht der Kernaussage des Releases, relativiert aber den Begriff „volle 27B-Fähigkeit“. Das binäre Modell hält viele Reasoning- und Coding-Werte erstaunlich gut, gibt für den Smartphone-Footprint jedoch gerade bei Vision und Tool-Nutzung merklich Qualität ab.

Die Grafik verwendet eine von PrismML definierte „Intelligenzdichte“: Der negative Logarithmus der Fehlerrate wird durch die Modellgröße in GB geteilt. Daraus ergeben sich laut Anbieter vier Kernaussagen:

• 1-bit Bonsai 27B erreicht mit 0,530 den höchsten Wert im gezeigten Vergleich.
• Ternary Bonsai 27B folgt mit 0,400.
• Die stärkste gezeigte konventionelle Niedrigbit-Variante liegt bei 0,199.
• Das Maß belohnt kleine Dateien stark und ist kein etablierter Ersatz für unabhängige Qualitäts-, Latenz- oder Energiebenchmarks.

Warum Hybrid Attention und 4-Bit-KV-Cache wichtig sind

Ein 3,9-GB-Modell allein löst das Kontextproblem nicht. Bei autoregressiver Generierung muss die Laufzeit frühere Schlüssel- und Wertrepräsentationen im KV-Cache halten. Dieser Speicher wächst mit jedem Token.

Qwen3.6-27B besitzt laut Whitepaper 64 Schichten, von denen nur 16 einen wachsenden Full-Attention-Cache verwenden. Dadurch fällt der KV-Cache ungefähr viermal kleiner aus als bei einem vergleichbaren dichten Transformer. PrismML quantisiert ihn zusätzlich auf 4 Bit.

Der Hersteller nennt bei voller Kontextlänge von 262.000 Token etwa 17,2 GB für einen FP16-KV-Cache und rund 4,3 GB für die 4-Bit-Variante. Damit wird ein sehr langer Kontext auf gut ausgestatteten Laptops grundsätzlich realistischer. Auf dem Smartphone bleibt die volle Länge trotzdem nicht automatisch nutzbar, weil Gewichte, Cache, Aktivierungen und App-Puffer gleichzeitig in den verfügbaren Speicher passen müssen.

PrismML berichtet außerdem, die Bonsai-Varianten seien gegenüber KV-Quantisierung ungewöhnlich tolerant. Diese Aussage basiert auf eigenen KL-Divergenz- und Benchmarkmessungen. Entwickler sollten sie mit realen Langkontext-Aufgaben überprüfen: große Codebasen, Dokumentensammlungen, mehrstufige Tool-Aufrufe und lange Dialoge sind aussagekräftiger als ein kurzer Chat.

Lokale Inferenz: GGUF, MLX, CUDA und llama.cpp

Der Release ist für mehrere lokale Pfade vorbereitet. Die binäre Q1_0-Unterstützung ist laut Repository bereits in das Hauptprojekt llama.cpp integriert und deckt CPU, Metal, CUDA und Vulkan ab. Für Ternary ist die Lage komplizierter: CPU und Metal sind mit einer kompatiblen Group-64-Datei im Hauptzweig verfügbar, während andere Formate oder Backends teilweise noch den PrismML-Fork benötigen. CUDA-Unterstützung für das ternäre Format befindet sich laut Repository noch im Upstream-Prozess.

Für Apple-Geräte gibt es MLX-Pakete. PrismML stellt außerdem einen Swift-Pfad für iPhone und iPad bereit. Die Modellkollektion auf Hugging Face umfasst binäre und ternäre GGUF- sowie MLX-Varianten. Stand 15. Juli 2026 waren die Repositories öffentlich und nicht zugangsbeschränkt.

Das ist ein anderer Ansatz als lokale Modelle über mehrere Grafikkarten zu verteilen. Wer größere Modelle über vorhandene Hardware splitten will, findet im Beitrag zu Mesh LLM und verteilter lokaler Inferenz den Gegenentwurf. Bonsai versucht dagegen, den Speicherbedarf des einzelnen Modells so weit zu senken, dass ein Gerät genügt.

DSpark beschleunigt die CUDA-Ausführung, nicht das iPhone

Bonsai 27B wird mit einem spekulativen Drafter auf Basis von DSpark ausgeliefert. Ein kleines Modell schlägt mehrere Token vor, die das Zielmodell gemeinsam prüft. Korrekt implementiert bleibt die Ausgabe-Verteilung des Zielmodells erhalten; der Vorteil liegt in weniger vollständigen Zielmodell-Durchläufen.

Auf einer H100 meldet PrismML für Ternary eine Steigerung von 98,0 auf 131,8 Token pro Sekunde und für die binäre Variante von 104,8 auf 143,8 Token pro Sekunde. Das entspricht 34 beziehungsweise 37 Prozent. Auf Apple Silicon ist der Drafter bei Batch-Größe eins laut Whitepaper noch nicht standardmäßig aktiv, weil der Verifikationsaufwand den Gewinn nicht zuverlässig amortisiert.

Die Beschleunigung darf deshalb nicht mit dem Smartphone-Wert vermischt werden. Die gemessenen 11 Token pro Sekunde auf dem iPhone stammen aus dem normalen binären MLX-Pfad. Eine breitere Einordnung spekulativer Verfahren bietet unser Beitrag zu DSpark und schnellerer LLM-Inferenz.

Zugang, Lizenz und Verfügbarkeit

Der Zugangszustand ist zum Start vergleichsweise offen:

• Die Modellgewichte sind öffentlich über die Bonsai-27B-Kollektion auf Hugging Face abrufbar.
• PrismML kennzeichnet die Modelle und das Demo-Repository mit Apache 2.0.
• GGUF- und MLX-Varianten stehen für lokale Tests bereit.
• Eine WebGPU-Demo wird über die offizielle Kollektion verlinkt.
• Eine Entwickler-API ist laut Anbieter kostenlos, aber ausdrücklich nur zeitlich begrenzt als Preview verfügbar.

„Open Weights“ bedeutet dennoch nicht, dass jede Komponente vollständig offen entwickelt wurde. PrismML beschreibt die Kompressionsmethode als proprietäre Caltech-Technologie. Veröffentlicht sind Gewichte, Laufzeitpfade, Demo-Code und Whitepaper; die vollständige Herstellungsmethode ist damit nicht automatisch reproduzierbar.

Was Entwickler jetzt testen sollten

Bonsai 27B ist besonders für lokale Agenten, Offline-Assistenten und datensensible Workflows relevant. Vor einer produktiven Entscheidung sollten Entwickler die Herstellerwerte jedoch auf der eigenen Zielhardware prüfen.

Eine sinnvolle Testliste umfasst:

1. Speicherbedarf unter realem Kontext: Nicht nur die Modelldatei messen, sondern den Peak mit 4.000, 16.000 und längeren Kontexten.
2. Tool-Aufrufe: JSON-Struktur, Argumente, Abbruchverhalten und Wiederholungen in mehrstufigen Abläufen testen.
3. Vision-Qualität: Screenshots, PDFs und Kameraaufnahmen getrennt bewerten. Die 1-Bit-Version verliert laut Hersteller hier stärker als bei Mathematik.
4. Langzeitstabilität: Agenten über viele Schritte laufen lassen und Planverlust, Schleifen sowie fehlerhafte Werkzeugwahl protokollieren.
5. Energie und Thermik: Token pro Sekunde allein reichen auf Smartphones nicht. Dauerlast, Drosselung und Akkuverbrauch sind für echte On-Device-Nutzung zentral.
6. Runtime-Kompatibilität: Prüfen, ob das gewünschte Format im offiziellen llama.cpp-Zweig läuft oder noch einen PrismML-Fork erfordert.
7. Lizenz und Komponenten: Gewichte, Vision-Tower, Runtime-Forks und eingebundene Bibliotheken getrennt dokumentieren.

Grenzen des Releases

PrismML nennt mehrere Einschränkungen selbst. Die Qualität sinkt gegenüber FP16, besonders bei Vision, Tool-Nutzung und strikter Anweisungsbefolgung. Die ternäre Packung erreicht ihre theoretischen 5,9 GB noch nicht. DSpark bringt auf Apple-Geräten bei Batch eins derzeit keinen zuverlässigen Vorteil. Eine speziell für langfristige Coding-Agenten optimierte Variante steht erst auf der Roadmap.

Hinzu kommt die Quellenlage: Benchmarks, Speichermessungen und Durchsatzwerte stammen von PrismML. Das Whitepaper beschreibt Methodik, Tokenbudgets und Scoring detaillierter als viele typische Release-Posts, ist aber keine unabhängige Evaluation. Besonders der iPhone-Claim sollte auf öffentlich reproduzierbaren Geräten, mit dokumentierter Laufzeitversion und ohne vorbereiteten Bildkontext wiederholt werden.

Auch die Aussage, lokale Agenten hätten „null“ Grenzkosten, ist zu absolut. Es entfallen API-Tokenpreise und Netzwerkrunden, doch Strom, Geräteverschleiß, Entwicklungsaufwand und Wartung bleiben reale Kosten. Der Vorteil liegt in Kontrolle, Datenschutz, Offline-Fähigkeit und planbaren Betriebskosten, nicht in kostenloser Rechenleistung.

Fazit: Ein wichtiger Edge-Release mit klaren Fußnoten

Bonsai 27B verschiebt die Grenze lokaler KI deutlich. Ein binäres 27B-Sprachmodell mit etwa 3,9 GB Gewichtsspeicher und gemessener interaktiver iPhone-Generierung war bisher kein üblicher Release. Öffentliche Gewichte, Apache-2.0-Lizenz, GGUF, MLX und ein detailliertes Whitepaper machen das Modell für Entwickler unmittelbar prüfbar.

Die nüchterne Einordnung ist ebenso wichtig: Ternary Bonsai belegt praktisch etwa 7,2 statt 5,9 GB, das Smartphone unterstützt nur die aggressiver komprimierte Variante, lange Kontexte erhöhen den Speicherbedarf stark, und die Herstellerbenchmarks zeigen sichtbare Verluste bei Vision und Tool-Nutzung. Wer diese Grenzen akzeptiert, bekommt einen der technisch interessantesten Open-Weight-Edge-Releases des Jahres 2026.

Teste zuerst die 1-Bit- und Ternary-Varianten auf deiner tatsächlichen Zielhardware. Entscheidend ist nicht der kleinste Download, sondern ob Speicher, Qualität, Laufzeit und Tool-Stabilität für den geplanten lokalen Workflow zusammenpassen.

FAQ zu Bonsai 27B

Läuft Bonsai 27B wirklich auf einem iPhone?

Ja, PrismML misst die binäre 1-Bit-Version auf einem iPhone 17 Pro Max mit rund 11 Token pro Sekunde. Die Ternary-Version passt laut Whitepaper nicht in das angenommene iOS-App-Speicherbudget, und lange Kontexte erhöhen den Bedarf zusätzlich.

Wie groß ist Bonsai 27B tatsächlich?

Die binäre GGUF-Version des Sprachmodells benötigt ungefähr 3,9 GB. Für Ternary nennt PrismML theoretisch 5,9 GB, während die aktuell gepackte und ausgelieferte GGUF-Version wegen 2-Bit-Slots ungefähr 7,2 GB belegt.

Ist Bonsai 27B frei verfügbar?

Stand 15. Juli 2026 sind die Modellgewichte öffentlich auf Hugging Face verfügbar und mit Apache 2.0 gekennzeichnet. Zusätzlich gibt es laut PrismML eine kostenlose, zeitlich begrenzte Entwickler-Preview per API.

Wie viel Qualität verliert die 1-Bit-Version?

Im Herstellerbenchmark erreicht 1-bit Bonsai 27B durchschnittlich 76,11 statt 85,07 Punkten der FP16-Basis, also 89,5 Prozent. Die Verluste sind bei Vision, Tool-Nutzung und Anweisungsbefolgung größer als bei Mathematik und Coding.

Kann Bonsai 27B den vollen 262K-Kontext auf dem Smartphone nutzen?

Nicht automatisch. Die Modellarchitektur unterstützt 262.000 Token, doch der KV-Cache, Aktivierungen und Laufzeitpuffer müssen zusätzlich in den Gerätespeicher passen; praktisch nutzbare Kontextlängen hängen daher stark von Hardware und KV-Quantisierung ab.