Bonsai 27B im Test: Läuft ein 27B-LLM wirklich auf dem Smartphone?

Ja, ein Modell der 27B-Klasse kann jetzt auf einem Smartphone laufen. Die ehrliche Antwort braucht aber mehr Kontext als die Schlagzeile. PrismML meldet für die rund 3,9 GB großen 1-Bit-Sprachgewichte etwa 11 Token pro Sekunde auf einem iPhone 17 Pro Max. Bonsai 27B basiert auf Qwen3.6-27B und steht laut Modellkarte unter Apache 2.0. Das ist ein echter Meilenstein für lokale KI, aber kein Beweis, dass jeder 27B-Workload bequem auf jedem Smartphone läuft.

Auch der Qualitätserhalt ist differenziert zu lesen. Im eigenen 15-Benchmark-Test von PrismML erreicht die 1-Bit-Variante 89,5 Prozent des FP16-Durchschnitts. Mathematik und Coding halten sich besser als Instruction Following, Vision und mehrstufige Tool-Nutzung. Die Ternary-Variante erreicht 94,6 Prozent, belegt im aktuellen GGUF-Paket aber rund 7,2 GB. Die oft genannten 5,9 GB sind die ideale Repräsentationsgröße, nicht der heutige Deployment-Footprint.

Was ist Bonsai 27B?

Bonsai 27B ist PrismMLs Low-Bit-Version von Qwen3.6-27B. Das dichte multimodale Modell hat einen 27B-Sprach-Backbone, einen Vision Encoder und ein natives Kontextfenster von 262.144 Token. Qwen nutzt in den meisten Blöcken lineare Attention und nur in 16 von 64 Blöcken volle Attention. Dadurch wächst der KV Cache langsamer als bei einem klassischen reinen Attention-Modell.

PrismML veröffentlicht zwei Varianten. Das 1-Bit-Modell speichert binäre Gewichte aus {−1, +1} und teilt pro 128 Gewichten einen FP16-Skalierungsfaktor. Daraus entstehen 1,125 effektive Bit pro Gewicht und rund 3,9 GB Sprachgewichte. Das Ternary-Modell ergänzt den Wert null und verwendet {−1, 0, +1}. Seine 1,71 effektiven Bit pro Gewicht kaufen mehr Qualität mit mehr Speicher.

Das geht tiefer als ein normaler nachträglicher 1-Bit-Export. Laut PrismML ziehen sich die niedrigen Bitbreiten durch Embeddings, Attention-Projektionen, MLP-Projektionen und den Language-Model-Head. Angepasste CUDA-, Metal-, MLX- und WebGPU-Kernel verarbeiten die gepackten Gewichte direkt, statt sie für jede Operation wieder auf FP16 aufzublasen.

Wie schrumpft ein 27B-Modell von 54 GB auf 3,9 GB?

Die FP16-Rechnung ist einfach: Rund 27,3 Milliarden Sprachparameter mal zwei Byte ergeben etwa 54 GB, noch ohne Runtime-Overhead. Das Binärmodell speichert ein Vorzeichen-Bit pro Gewicht sowie einen gemeinsamen 16-Bit-Scale für jeweils 128 Gewichte. Das ergibt 1,125 Bit pro Gewicht und ungefähr den Faktor 14,2 gegenüber FP16.

Die Download-Größe ist nicht der gesamte Speicherbedarf:

• Sprachgewichte: rund 3,9 GB für 1-Bit oder rund 7,2 GB für das heutige Ternary-GGUF.
• Runtime und Activations: die veröffentlichten Messungen enthalten rund 1,3 GB über die Backends hinweg.
• KV Cache: wächst mit dem aktiven Kontext. Selbst mit 4-Bit-KV-Kompression erreicht das volle 262K-Fenster beim 1-Bit-Modell rund 9,4 GB Peak Memory.
• Optionale Komponenten: die kompakte Vision-Projektion belegt etwa 0,63 GB. Auch der Speculative-Decoding-Drafter kostet zusätzlichen Speicher.

Für ein Produkt heißt das: Die Modellgewichte können ins App-Budget passen, während das maximale Kontextfenster nicht hineinpasst. Kapazitätsplanung muss Gewichte, echten Kontext und Runtime gemeinsam auf dem Zielgerät messen.

Behält Bonsai 27B wirklich 90 Prozent der Qwen3.6-Intelligenz?

Es behält 89,5 Prozent eines herstellereigenen Benchmark-Durchschnitts, nicht 90 Prozent jeder Fähigkeit. PrismML testete die Varianten im Thinking Mode mit EvalScope und vLLM auf derselben H100-Infrastruktur. Die identischen Bedingungen machen den Vergleich nützlich. Unabhängig reproduziert ist er noch nicht, und der Durchschnitt verdeckt deutliche Unterschiede.

Die Einzelwerte zeigen das Problem. Beim 1-Bit-Modell fällt MATH-500 nur von 99,40 auf 98,00 und BFCL v3 von 77,10 auf 70,72. Das schwierigere mehrstufige τ²-Bench sinkt aber von 82,90 auf 61,34, IFBench von 68,03 auf 52,36 und MMMU-Pro von 79,94 auf 60,48. Genau in langen Agent-Loops können kleine Fehler dadurch schnell kumulieren.

Die Modellkarte nennt langfristiges, mehrdateibasiertes Agentic Coding selbst als noch schwaches Ziel dieses Releases. Für eine Kaufentscheidung ist dieser Hinweis wichtiger als das gerundete 90-Prozent-Label.

Läuft Bonsai 27B wirklich lokal auf Smartphone und Laptop?

Ja, auf unterstützter High-End-Hardware und mit passender Runtime. PrismML meldet etwa 11 tok/s für MLX Swift auf dem iPhone 17 Pro Max. Beim 1-Bit-GGUF nennt llama-bench 26,0 tok/s auf M4 Pro, 44,2 auf M5 Pro und 66,4 auf M5 Max für die Generierung von 128 Token. Das Ternary-GGUF liegt auf denselben Laptopklassen bei 18,0, 26,2 und 44,0 tok/s.

Diese Zahlen sind nicht austauschbar. Smartphone, Metal, CUDA und WebGPU nutzen andere Kernel, Kontextlängen, Power Limits und Messprotokolle. Prompt Processing und Token Generation sind außerdem verschiedene Phasen. Schnelles Decoding garantiert bei langen Dokumenten keine kurze Time to First Token.

Wie belastbar sind die 90 Token pro Sekunde im Browser?

Joshua Lochners Hugging-Face-Demo bestätigt den entscheidenden Teil: Bonsai 27B läuft lokal im Browser über angepasste WGSL-Compute-Shader. Die Seite nennt Fable 5 und GPT 5.6 Sol als Autoren und Optimierer der Kernel, die vor der Aufnahme auf Korrektheit und konkrete Tensorformen getestet wurden. Nach dem Download bleiben Modell und Unterhaltung lokal.

Für die oft zitierten 90 tok/s nennt der öffentliche Demo-Quelltext aber weder Hardware noch Browser-Version, Kontext, Warm-up oder reproduzierbares Testprotokoll. Behandle den Wert als Demo-Ergebnis, nicht als fixe Kapazität. Für den Einkauf misst du Browser, GPU, Energiemodus, Promptlänge, Outputlänge, First-Token-Latenz, dauerhaftes Decoding, Peak Memory und Thermal Throttling über mehrere Durchläufe.

Wo kann Bonsai 27B kommerziellen Wert schaffen?

• Private Dokumentenassistenten: sensible lokale Dateien zusammenfassen, klassifizieren oder extrahieren, ohne sie an eine Modell-API zu senden.
• Offline-Software im Feld: Techniker, Prüfer oder mobile Teams auch bei instabiler Verbindung unterstützen.
• On-Device-Produktfeatures: Textassistenz mit planbarer lokaler Latenz und ohne laufende Token-Kosten bereitstellen.
• Hybrides Routing: private, begrenzte Schritte lokal ausführen und schwieriges Reasoning oder fragile Tool-Flows an ein stärkeres Cloud-Modell übergeben.
• Piloten auf einer Maschine: 27B-Klasse auf Laptop oder kleiner GPU evaluieren, bevor ein Inference-Cluster beschafft wird.

Der Geschäftswert kommt weiterhin aus dem System um das Modell. Unser AI Enablement umfasst Use-Case-Auswahl, Evals, Datenzugriff, Routing, Deployment, Observability und Übergabe. Die Twinsoft AI Case Study zeigt, warum der produktive Workflow und seine Kontrollen mehr zählen als die Parameterzahl.

Welche Bonsai-27B-Variante sollte ein Unternehmen wählen?

Dieser Artikel beantwortet bewusst nur die Bonsai-spezifische Deployment-Frage. Für die breitere Modellfamilien-Auswahl dient unser Open-Weight-LLM-Vergleich 2026. Für die Infrastrukturkosten nutzt du den Break-even-Rechner für lokale Modelle und APIs. So konkurriert ein Produktreview nicht mit Marktvergleich und Wirtschaftlichkeitsrechnung.

Was muss ein Bonsai-27B-Pilot messen?

1. Artefakt und Runtime einfrieren: Hugging-Face-Revision, Hash, Backend-Fork, Kernel-Commit, Gerät, OS und MLX- oder Browser-Version dokumentieren.
2. Gesamten Speicher messen: Gewichte, Runtime, erwarteten Kontext, KV-Format, Vision-Projektion und optionalen Drafter einschließen.
3. Eigenes Eval bauen: mindestens 50 bis 100 reale Aufgaben mit Format-Constraints, Tool-Schemas, Refusals und unzulässigen Fehlern.
4. Latenzphasen trennen: Time to First Token, Prompt Processing, dauerhaftes Decoding und wiederholte warme Runs messen.
5. Offline- und Privacy-Grenzen prüfen: Model Fetch, Analytics, Crash Reporting, Logs, Embeddings und Fallbacks kontrollieren.
6. Erfolgreiche Outcomes bepreisen: Gerätesupport, Engineering, Update-Verteilung, Monitoring und Fallback gegen eine API rechnen.
7. Rollback planen: ein bewährtes Modell und eine Server-Route für inkompatible Geräte, Überlast oder Qualitätsfehler behalten.

Unser Leitfaden zur Tech-Stack-Auswahl fürs MVP folgt derselben Regel: Entscheide zuerst nach dem Constraint, das später teuer umkehrbar ist. Bei On-Device-KI sind das meist die unterstützte Hardware-Untergrenze und die Qualität des kritischsten Workflows, nicht die Download-Größe.