4 Punkte von GN⁺ 4 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Während bisherige 27B-Modelle selbst auf 4 Bit reduziert noch 18 GB benötigen, hat PrismML Bonsai 27B auf Basis von Qwen3.6 27B an die Speichergrenzen des iPhone angepasst und unterstützt Inferenz, Tool-Aufrufe, Vision und Computer Use
  • Das qualitätsorientierte Ternary-Modell kommt mit 1,71 Bit pro Gewicht auf 5,9 GB, das kapazitätsorientierte 1-Bit-Modell mit 1,125 Bit auf 3,9 GB; Low-Bit-Repräsentationen werden auf das gesamte Sprachmodell angewendet
  • In 15 Benchmarks im Thinking-Modus hält das Ternary-Modell 95 % der Leistung der Full-Precision-Basis, das 1-Bit-Modell 90 %; die Gesamtscores liegen bei 80,5 bzw. 76,1 Punkten
  • Gemessen wurden bis zu 163 tok/s auf einer NVIDIA GeForce RTX 5090 und bis zu 87 tok/s auf einem M5 Max; unterstützt werden 262K Token Kontext, ein 4-Bit-Vision-Tower und Speculative Decoding
  • Die lokale Ausführung eliminiert schrittweise API-Kosten und Datenübertragung bei wiederholten Agentenaufgaben und ermöglicht hybride Deployments, bei denen sensible Aufgaben auf dem Gerät bleiben und nur schwierige Schritte in die Cloud gehen

Wie man ein Modell der 27B-Klasse auf ein Smartphone bringt

  • Bisherige 27B-Modelle benötigen bei 16-Bit-Präzision etwa 54 GB und selbst in typischen 4-Bit-Builds 18 GB, was eine lokale Bereitstellung auf Smartphones und den meisten Laptops erschwert
  • Bonsai 27B auf Basis von Qwen3.6 27B unterstützt mehrstufiges Reasoning, strukturierte Tool-Aufrufe, Vision-Aufgaben sowie einen Computer-Use-Agent-Loop, der über mehrere Schritte hinweg konsistent bleibt
  • Die zwei Low-Bit-Konfigurationen zielen auf unterschiedliche Deployment-Umgebungen
    • Ternary Bonsai 27B verwendet {−1, 0, +1}-Gewichte und gruppenweise FP16-Skalierung und erreicht damit effektiv 1,71 Bit pro Gewicht bei einer Größe von 5,9 GB
    • Es zielt auf Qualität auf Laptop-Niveau und bietet vollständige Inferenz-, Tool-Calling- und Agentenfunktionen
    • 1-bit Bonsai 27B verwendet {−1, +1}-Gewichte mit derselben gruppenweisen Skalierung und erreicht effektiv 1,125 Bit pro Gewicht bei einer Größe von 3,9 GB
    • Es konzentriert sich auf eine smartphonegerechte Größe, die innerhalb des Speicherbudgets eines iPhone 17 Pro bleibt

End-to-End-Low-Bit- und multimodaler Aufbau

  • Low-Bit-Repräsentationen werden auf das gesamte Sprachmodell angewendet, einschließlich Embeddings, Attention, MLP und LM Head, ohne einzelne Bereiche mit höherer Präzision zu umgehen
  • Beide Modelle sind multimodal, und der Vision-Tower wird in einem komprimierten 4-Bit-Format bereitgestellt, sodass Screenshots, Dokumente und Kameraeingaben direkt auf dem Gerät verarbeitet werden können
  • Unterstützt werden bis zu 262K Token Kontext
  • Verwendet werden kann Speculative Decoding, eine verlustfreie Beschleunigungsmethode, bei der zunächst ein Entwurf erzeugt und anschließend verifiziert wird
  • Die Modellgewichte werden unter der Apache 2.0 License bereitgestellt

Aufrechterhaltene Leistung in 15 Benchmarks

  • Im Thinking-Modus, der die vollständigen Reasoning-Fähigkeiten des Modells nutzt, wurden 15 Benchmarks aus den Bereichen Wissen, Reasoning, Mathematik, Coding, Befolgung von Anweisungen, Tool-Aufrufe und Vision evaluiert
  • Der Gesamtscore von Qwen3.6 27B in Full Precision liegt bei 85,0 Punkten, Ternary Bonsai 27B erreicht 80,5 Punkte und 1-bit Bonsai 27B 76,1 Punkte
    • Das Ternary-Modell hält 95 % der Referenzleistung in Full Precision
    • Das 1-Bit-Modell hält 90 % der Referenzleistung
  • Die bereichsspezifischen Werte sind wie folgt
    • Mathematik — GSM8K, MATH-500, AIME25, AIME26: Full Precision 95,3, Ternary 93,4, 1-Bit 91,7
    • Coding — HumanEval+, MBPP+, LiveCodeBench: Full Precision 88,7, Ternary 86,0, 1-Bit 81,9
    • Agenten·Tool-Aufrufe — BFCL v3, TauBench: Full Precision 80,0, Ternary 74,0, 1-Bit 66,0
    • Befolgung von Anweisungen — IFEval, IFBench: Full Precision 78,4, Ternary 71,8, 1-Bit 65,8
    • Wissen·STEM — MMLU-Redux, MuSR: Full Precision 83,1, Ternary 77,0, 1-Bit 73,4
    • Vision — MMMU Pro, OCRBench: Full Precision 72,6, Ternary 65,2, 1-Bit 59,6
  • In Mathematik und Coding ist der Leistungsrückgang relativ gering, und auch die Tool-Calling-Leistung des Ternary-Modells bleibt nahe an Full Precision
  • Der aggressivste allgemeine Low-Bit-Build auf derselben Basismodellfamilie verbraucht 2,5-mal mehr Speicher als 1-bit Bonsai 27B und erzielt dennoch niedrigere Werte

Intelligenzdichte pro Gigabyte

  • 1-bit Bonsai 27B liefert Leistung auf 27B-Niveau bei kleinerer Größe als ein 2B-Modell in Full Precision
  • Nach dem von PrismML mit 1-bit Bonsai 8B eingeführten Maßstab für Intelligenzdichte erreicht 1-bit Bonsai 27B 0,53 pro GB
    • Das ist mehr als 10-mal höher als bei Full Precision
    • Und etwa 2,7-mal höher als bei der besten verfügbaren Low-Bit-Alternative
  • In dieser Unterscheidung bestimmt die absolute Fähigkeit des Modells, welche Aufgaben es erledigen kann, während die Intelligenzdichte bestimmt, auf welchen Geräten und in welchen Umgebungen diese Aufgaben ausgeführt werden können

Persistente Agentenaufgaben lokal ausführen

  • AI-Workloads entwickeln sich weg von Einzelantworten hin zu dauerhaften Aufgaben wie Assistenten mit echten Tools, autonomen Workflows oder Research, das Dutzende Dokumente zusammenführt
  • Agenten rufen das Modell nicht einmal, sondern Hunderte Male auf, geben bei jedem Schritt Kontext weiter, erzeugen strukturierte Ausgaben und verwenden diese als Eingabe für den nächsten Schritt
  • Cloud-APIs bleiben für viele Produkte geeignet, aber wenn Agentenaufgaben ausschließlich in der Cloud laufen, entstehen strukturelle Einschränkungen
    • Jeder Schritt wird als Remote-Request verarbeitet
    • Mit jeder Iteration steigen die Token-Kosten
    • Nicht nur Planung, Tool-Aufrufe und Zwischenergebnisse, sondern auch persönliche Dateien, Bildschirme und Daten der Nutzer passieren das Netzwerk
  • Wenn ein ausreichend leistungsfähiges Modell auf dem Gerät läuft, kann der Agent im Produkt selbst verbleiben
    • Selbst bei einem 100-Schritte-Loop entstehen keine zusätzlichen Kosten für Modellaufrufe
    • Nutzerdaten verlassen das Gerät nicht
    • Damit lassen sich persistente On-Device-Agenten, Offline-Assistenten und Assistenten umsetzen, die lokale private Daten direkt verarbeiten
  • Mit einer hybriden Architektur, bei der unkritische Aufgaben oder Aufgaben ohne Frontier-Anforderungen lokal laufen und nur die schwierigsten Schritte an ein Cloud-Modell gehen, lassen sich die Kosten pro Aufgabe in Agentensystemen senken

Ausführungsgeschwindigkeit und Speichergrenzen von Smartphones

  • Die gemessene maximale Generierungsgeschwindigkeit auf einer NVIDIA GeForce RTX 5090 ist wie folgt
    • 1-Bit-Modell: 163 tok/s
    • Ternary-Modell: 134 tok/s
  • Die gemessene maximale Generierungsgeschwindigkeit auf einem M5 Max ist wie folgt
    • 1-Bit-Modell: 87 tok/s
    • Ternary-Modell: 58 tok/s
  • Eine Smartphone-App kann nicht den gesamten Gerätespeicher nutzen; selbst auf einem iPhone mit 12 GB stehen dem Modell nur etwa 6 GB zur Verfügung
  • In dieses Budget müssen nicht nur die Modellgewichte, sondern auch KV-Cache und Aktivierungen passen, daher reicht es nicht aus, nur die Dateigröße der gespeicherten Gewichte zu verkleinern
  • Das etwa 4 GB große 1-bit Bonsai 27B erfüllt diese Speichergrenze und lässt gleichzeitig noch ausreichend Spielraum für den eigentlichen Workload
  • Die Demo eines multimodalen Agenten auf dem iPhone 17 Pro Max läuft im Demo-Modus unter Verwendung von Cache und vorab eingegebenem Bildkontext

Unterstützte Plattformen und Deployment-Modell

  • Auf Apple-Geräten läuft es über MLX nativ auf Mac, iPhone und iPad
  • Auf NVIDIA-GPUs wird CUDA verwendet
  • Beide Plattformen nutzen angepasste Low-Bit-Kernel, die auf die hybride Attention-Architektur zugeschnitten sind
  • Für begrenzte Zeit wird eine kostenlose Developer Preview API angeboten, mit der Entwickler das Modell testen können
  • Die vollständigen technischen Details zu Kompression, Evaluation und Benchmarking finden sich im Bonsai 27B Whitepaper

Größere Modelle und neue Architekturen

  • Bonsai 27B verkleinert die Fähigkeiten moderner Modelle – darunter Thinking, multimodales Verstehen, Vision und Tool-Nutzung – auf eine Größe, die auf Geräten läuft, über die normale Nutzer tatsächlich verfügen
  • Die Kompressionsmethodik ist nicht an eine bestimmte Architektur gebunden, und PrismML arbeitet bereits an größeren Modellen und neuen Architekturen
  • Mit steigender Intelligenzdichte erweitert sich die Bandbreite der Geräte, Produkte und Umgebungen, auf denen fortschrittliche AI laufen kann – vom Smartphone bis zum Server mit einer einzelnen GPU

1 Kommentare

 
GN⁺ 4 시간 전
Hacker-News-Meinungen
  • Am ehesten würde ich das mit der 4-Bit-QAT-Version von Gemma 4 12B vergleichen wollen. Sie ist etwas unter 7 GB groß, also nur ein wenig größer als dieses Modell, läuft auf den meisten halbwegs aktuellen Geräten und ist gemessen an ihrer Größe erstaunlich intelligent.
    Die Tool-Nutzung ist stark, und auch die Vision-Leistung ist für die Größe beeindruckend. Ich versuche noch zu verstehen, wie viel Leistung bei jeder weiteren Reduktion der Präzision verloren geht, aber Googles QAT-Versionen scheinen zu zeigen, dass der Verlust bei 4 Bit sehr gering ist.

    • Wenn man die veröffentlichten Zahlen mit den Gemma-Ergebnissen quervergleicht, liegt dieses Modell bei Mathematik und Coding deutlich vor Gemma 4 12B, bei Wissen und Tool-Calling etwas dahinter und bei Vision-Aufgaben merklich zurück.
    • Es wäre schön, wenn es auch eine 1-Bit-Binärversion von Gemma 4 12B gäbe ;)
    • Bei vielen Modellfamilien ist 4 Bit der Kipppunkt, aber es hängt davon ab, ob Gewichte, Gewichte und Aktivierungen oder der KV-Cache auf 4 Bit quantisiert werden. Es hängt auch von Modellgröße und Aufgabe ab, daher ist Quantisierung in mehr Hinsicht subtil, als man denkt.
      Eine gute Auswertung aus dem Jahr 2024 ist https://arxiv.org/pdf/2402.18158. Ich bin zwar nicht der ursprüngliche Autor, arbeite aber gerade an einer aktualisierten Fassung und würde gern wissen, ob jemand ähnliche Übersichtsarbeiten kennt, da ich noch keine gründliche Literaturrecherche gemacht habe.
  • Aus Investorensicht ist das ein echter Paradigmenwechsel. Europäische Startups, die mit Privacy werben und dabei große gehostete Modelle umhüllen, könnten massenhaft verschwinden.
    Wenn man alles direkt auf dem Laptop ausführen kann, gibt es absolut keinen Grund mehr, einen Anbieter wie „Privacy GPT™“ zu nutzen. Banken und andere regulierte Branchen können Intelligenz auf diesem Niveau auch selbst hosten, sodass sie nicht mehr auf solche Firmen angewiesen sind.

  • Ich brauche Hilfe beim Verständnis. Ich habe das so verstanden, dass der Kern hier darin liegt, per Quantisierung 50 GB auf 4 GB zu reduzieren und dabei den Großteil der Intelligenz innerhalb eines pareto-optimalen Bereichs zu erhalten, und dass dann die Intelligenz pro Größe mit anderen quantisierten Modellen verglichen wird. Allerdings scheint gerade die Tool-Calling-Leistung, die auch bei anderen kleinen Modellen problematisch ist, am stärksten gelitten zu haben.
    Wie schneidet dieses Modell im Vergleich zu anderen aktuellen 4-GB-Modellen ab? Woran erkennt man, ob tatsächlich die Intelligenz des Elternmodells erhalten blieb oder ob auf Benchmarks hin feinabgestimmt wurde?
    Ich will das nicht schlechtreden und hoffe wirklich, dass es ein erstaunliches Ergebnis ist, aber mit meinem begrenzten Wissen scheint eine faire Vergleichsgrafik zu fehlen, und selbst die vorhandenen Grafiken wirken potenziell irreführend. Es wäre hilfreich, wenn mir jemand erklären könnte, was ich missverstanden habe.

    • Ich hatte verstanden, dass PrismML nicht einfach wie üblich Quantisierung nutzt, also bei einem in FP16 trainierten Modell Bits abschneidet, um den VRAM-Bedarf zu senken, sondern dass es von Anfang an mit 1-Bit-Gewichten trainiert.
      Im Artikel steht mehr dazu, etwa Techniken wie ein FP16-Gewicht pro 128er-Block von 1-Bit-Gewichten, um mehr Information unterzubringen.
  • Apple soll mit PrismML in Verhandlungen stehen: https://www.cnbc.com/2026/07/14/apple-prismml-ai-compression...

    • Das stammt direkt von PrismML-CEO Babak Hassibi gegenüber CNBC, also ist es entweder erfunden, oder er hat durch das Durchstechen der Verhandlungen selbst die Aussicht auf einen Abschluss zunichtegemacht.
  • Das ist vielleicht kleinlich, aber das Gericht, das das Modell in der Demo vorgeschlagen hat, sah nicht besonders lecker aus, und auch die Makronährstoffberechnung scheint komplett falsch zu sein. 25 g Protein für „Spaghetti, Karotten, Paprika, Knoblauch, Kräuter“?

    • Gute Spaghetti haben einen Proteinanteil von 15 %, also 15 g pro 100 g, und selbst die billigsten Produkte kommen auf 12 g pro 100 g.
    • Ich persönlich mag Karotten nicht besonders, aber unappetitlich sieht es nicht aus. Mit Tomatensauce wäre es viel besser, aber auf dem gezeigten Bild schien das keine Option gewesen zu sein.
      Die 25 g Protein setzen vielleicht eine proteinreiche Pasta wie Kichererbsenpasta voraus, aber es wirkt auf jeden Fall wie ein falscher Wert.
    • 200 g Spaghetti enthalten tatsächlich etwa 25 g Protein.
    • Ich verstehe nicht, warum man eine so banale Frage mit KI auf dem Handy beantworten sollte. Dafür braucht man weder KI noch lokale KI; dafür reichte schon immer eine einfache Google-Suche.
      Wenn KI in Handygröße nützlich sein soll, muss sie Aufgaben lösen, die nur KI kann. Kann sie Dokumente verarbeiten, die mit der Handykamera gescannt wurden? Kann sie in Echtzeit übersetzen? Rezepttipps sind längst über andere Wege im Überfluss verfügbar, daher gibt es keinen besonderen Grund, danach zu fragen.
  • Das Modell wird auf Hugging Face unter https://huggingface.co/prism-ml/models bereitgestellt.
    Ich habe in LM Studio sowohl die GGUF- als auch die MLX-Modelle ausprobiert, aber keines von beiden funktionierte. Möglicherweise muss LM Studio zuerst die llama.cpp- oder MLX-Engine aktualisieren; mich würde interessieren, ob es jemand erfolgreich zum Laufen gebracht hat.

    • Das vorherige Modell lief mit dem Custom Fork von llama.cpp von PrismML unter https://github.com/PrismML-Eng/llama.cpp. Dieses Modell habe ich noch nicht ausprobiert, aber ich will mir diese Woche Zeit nehmen und Benchmarks machen.
      Da offenbar auch im Mainline-llama.cpp Patches für die Metal- und CPU-Backends enthalten sind, dürfte auf einem Mac oder mit ausreichend schneller CPU und genug Speicher wohl auch das aktuelle llama.cpp allein reichen.
    • Je nach Modell, das man ausführen möchte, kann ein Custom Fork nötig sein; Details stehen unter https://github.com/PrismML-Eng/Bonsai-demo/blob/main/README.....
    • Ich weiß nicht, ob es eine Möglichkeit gibt, den llama.cpp-Fork von PrismML innerhalb von LM Studio auszuführen.
      Der Fork selbst läuft zwar gut, aber in einem einfachen Test geriet das Modell stark in Inference-Loops. Das könnte dasselbe Problem sein, das auftritt, wenn man die Reasoning-Stärke hoch einstellt.
      Auf dem M1 Max scheinen MoE Qwen 3.6 und Gemma 4 weiterhin die beste Wahl zu sein. Ich bin auch nicht überzeugt von der Behauptung, dass 35B tatsächlich schlechter sei; in meiner Umgebung gerät es deutlich seltener in Inference-Loops als 27B.
    • Ich habe in LM Studio die zwei offiziellen Modelle heruntergeladen, beide waren 3,6 GB groß, aber keines ließ sich laden.
    • In Unsloth funktionierte es ebenfalls nicht, aber mit dem nächsten Update-Bundle wird das wahrscheinlich innerhalb von ein oder zwei Tagen behoben.
  • Stark! Ich warte seit über einem Jahr auf eine Skalierung ternärer Modelle[1]. Ein gewöhnliches Qwen 27B ist zu schwer, um auf lokaler Hardware mit vernünftiger Geschwindigkeit zu laufen, daher freue ich mich darauf, das selbst auszuprobieren.
    [1] https://jackson.dev/post/dont-sleep-on-bitnet/

    • Geht mir genauso. Ich freue mich auf ein Modell, das auf einem 16-GB-Laptop vielleicht brauchbar sein könnte.
  • 90 % der Leistung mit einem 1-Bit-Modell zu erreichen, ist zunächst einmal ein erstaunliches Ergebnis.
    Aber in den letzten zwei Wochen ist das schon die fünfte Produktankündigung dieser Art, und jedes Mal heißt es, damit ändere sich die Art, wie AI genutzt wird, und der jeweilige Kompromiss sei die perfekte Antwort. Paradigmenwechsel finden nicht in Produktankündigungen statt.
    Ich frage mich, ob dieses Erzeugen-des-Eindrucks-von-Paradigmenwechseln bei jedem Release nicht eine Art AI-typischer Schreibstil ist.

    • Das gilt für alle Tech-Ankündigungen. Unabhängig von der Realität machen Marketing-Leute eben Marketing.
  • Selbst bei voller Kontextlänge wirkt der KV-Cache-Speicherverbrauch erstaunlich niedrig. Dadurch könnte das besonders für Coding-Workflows mit mehreren Agenten nützlich sein.
    Es wäre schön, wenn neue Modellankündigungen und Demos den KV-Cache-Speicherverbrauch und die zugehörigen Optimierungen klarer behandeln würden.

    • Wenn man den KV-Cache quantisiert, verschlechtern sich Attention und Recall, und dadurch leiden auch Long-Context-Aufgaben. Je nach Modellfamilie und Größe ist unterschiedlich, wie gut die einzelnen Teile Quantisierung vertragen, und das hängt auch von der Zielaufgabe ab.
  • Heute gelernt: 1-Bit-Modelle sind in Wirklichkeit 1,58-Bit-Modelle, die die drei Werte +1, 0, -1 verwenden.

    • Dabei gibt es zwei Varianten. Etwas scherzhaft gesagt hat man die Werte eines Bits einfach sehr groß gewählt.
      Ternary Bonsai 27B verwendet ternäre Gewichte {-1, 0, +1} und FP16-Gruppenskalierung, wodurch sich effektiv 1,71 Bit pro Gewicht ergeben. 1-bit Bonsai 27B verwendet binäre Gewichte {-1, +1} und dieselbe Gruppenskalierung, wodurch sich effektiv 1,125 Bit pro Gewicht ergeben.
    • Rechnet man nach der praktischsten Methode, fünf Zahlen mit drei Zuständen in ein Byte zu packen, kommt man auf 1,6 Bit. Tatsächlich bündelt man aber meist vier Zahlen mit vier Zuständen.
    • Das ist eine bedauerliche Konvention, die schon mit den ersten „1-Bit“-Modellen begonnen hat. Bei Bonsai gibt es allerdings sowohl eine ternäre Version als auch eine echte 1-Bit-Version.