BLOG
„9-mal kleiner, 98,2 % beibehalten“: Wie technische Manager die Rhetorik von Anbietern lesen
Einleitung: Ein Satz, zwei Zahlen
Am 17. September veröffentlichte PrismML im offiziellen Blog Ternary Bonsai 2 27B. Die offizielle Aussage lautete in einem Satz: mehr als 9-mal kleiner als die Vollpräzisionsversion, bei gleichzeitiger Beibehaltung von 98,2 % der aggregierten Benchmark-Leistung. Ist das falsch? Nicht unbedingt. Aber wie man diesen Satz liest, ist eine andere Kunst. Am selben Tag erhielt dieser Satz auf Hacker News 563 Upvotes. Geht man zwei Monate zurück, so hatte die Firma bei der Vorstellung der ersten Generation Bonsai 27B ihre offizielle Rhetorik bereits stillschweigend von „Modell verkleinern“ zu „Komprimierung wird zu Deployment-Freischaltung (deployment unlock)“ geändert.
Marketingbegriffe sind kein Synonym für Lügen, aber sie haben ihre eigene Wortbildungslogik und ihre eigenen Nutznießer. Die Aufgabe des technischen Managers ist es nicht, sie zu verfluchen oder ihnen zu glauben, sondern sie in verifizierbare Bestandteile zu zerlegen.
Shiwen: Ein Satz, zwei Zahlen – warum lohnt sich dafür eine eigene Ausgabe?
Yongliang: Weil ich in siebzehn Jahren der Berichterstattung als Dienstleister und der Bewertung von Angeboten festgestellt habe, dass mehr als die Hälfte der Meinungsverschiedenheiten nicht technischer Natur sind, sondern in der Rhetorik liegen. Der Anbieter nennt eine Zahl, der Auftraggeber hört eine Zahl, beide Seiten glauben, sie sprechen vom Gleichen, und erst nach Vertragsunterzeichnung stellt sich heraus, dass es völlig unterschiedlich ist. In dieser Ausgabe zerlegen wir genau das: Wie man Zahlen liest, wie Wörter geformt werden, wie Sterne wachsen, und am Ende gebe ich Ihnen drei Fragen, die Sie direkt in der Beschaffungssitzung stellen können.
Q1: Zuerst die Zahlen „9-mal kleiner, 98,2 %“ selbst zerlegen
Yongliang: Zuerst die Festlegung der Kennzahlen: Im Folgenden handelt es sich ausschließlich um selbst gemeldete Zahlen aus dem offiziellen Blog von PrismML, die ich mit „offiziell heißt es“ zitiere. Unter dieser Voraussetzung sind diese beiden Zahlen genau die am值得 zerlegenden Musterproben.
Laut offiziellem Blog basiert Ternary Bonsai 2 27B auf Qwen3.8 27B, die Gewichte wurden ternarisiert – drei Werte {-1, 0, +1}, plus FP16-Gruppenskalierung. Offiziell heißt es, es seien 1,76 effektive Bits pro Gewicht, das Modell belege insgesamt 5,9 GB, unterstütze 262K Kontext, multimodale Bild-Text-Eingabe und nutze die Apache-2.0-Lizenz. Allein betrachtet ist das solide Ingenieursarbeit, das muss man anerkennen.
Es lohnt sich, den zweiten Teil langsamer zu lesen. Offiziell heißt es: „mehr als 9-mal kleiner als die Vollpräzisionsversion, bei gleichzeitiger Beibehaltung von 98,2 % der aggregierten Benchmark-Leistung“. Auseinandergenommen gibt es drei Fragen zur Definition. Erstens: Wer ist der Nenner bei „9-mal“? Handelt es sich bei der Vollpräzisionsversion um FP16 oder FP32? Bei unterschiedlichem Nenner ist der Faktor völlig anders. Zweitens: Welche Benchmarks wurden bei „98,2 %“ aggregiert und mit welchen Gewichten? Der offizielle Blog gibt keine vollständige Benchmark-Liste und auch keine Aggregationsmethode an – das ist keine Anklage, sondern eine Frage des Offenlegungsgrades. Drittens, und das wird am leichtesten übersehen: Benchmark-Punkte sind nicht gleichbedeutend mit der Erfahrung bei echten Aufgaben. Aggregierte Benchmarks sind der Durchschnittswert aus Dutzenden Aufgaben; eine durchschnittliche Beibehaltung von 98,2 % bedeutet, dass manche einzelnen Aufgaben stark verlieren, andere wenig, und der Teil, der durch den Durchschnitt geglättet wurde, könnte genau bei Ihren geschäftskritischen Aufgaben verloren gehen.
Ich sage es noch einmal: Ich habe siebzehn Jahre lang als Dienstleister berichtet. Diese Methode, Zahlen zu paketieren, habe ich bei anderen gesehen und selbst angewendet. Eine Prozentangabe mit einer Nachkommastelle dient dazu, präzise zu wirken; „aggregiert“ zu verwenden, ohne eine Liste aufzuführen, dient dazu, dass die Verluste nicht auf der Bühne erscheinen. Ich behaupte nicht, dass der Hersteller fälscht – keine Liste zu geben, kann am Platzmangel liegen oder an einer selektiven Darstellung, beides ist möglich. Aber die Lesart des Managers gibt es nur in einer Art: Bei jeder „X-fach“- oder „Y %“-Paketzahl zuerst nach dem Nenner und der Liste fragen, dann erst über Glauben reden.
Q2: Wie entstehen Begriffe wie „near-lossless“ und „deployment unlock“?
Yongliang: Wörter werden nicht einfach so erfunden, hinter jedem Marketingbegriff steht ein konkreter Nutznießer.
Vor zwei Monaten, als PrismML die erste Generation Bonsai 27B vorstellte, lautete die offizielle Rhetorik „Komprimierung wird zu Deployment-Freischaltung“ (deployment unlock). Beim diesmaligen Bonsai 2 tauchten in der Communitydiskussion Begriffe wie near-lossless (beinahe verlustfrei) auf. Wenn man diese beiden Begriffe nebeneinanderlegt, ist das Muster der Wortbildung klar.
„Verlustfrei“ (lossless) ist in der Ingenieurswesen klar definiert: Informationen lassen sich vollständig wiederherstellen. Aber quantisierte Modelle können das nicht – nach der Ternarisierung lassen sich die ursprünglichen Gewichte nicht wiederfinden. Also traut sich niemand, „verlustfrei“ zu sagen, also erfand man „near-lossless“: Man fügt ein Wort hinzu, leiht sich das Gewicht von „verlustfrei“ aus, muss aber keine Beweislast für „verlustfrei“ tragen. Wer profitiert? Kurzfristig die Verbreiter, ein professionell klingendes Wort sorgt für mehr Weiterleitungen; langfristig der Hersteller, wenn sich das Wort verbreitet, ist der Standardeindruck gesät.
„deployment unlock“ ist ein anderer Weg: Keine Zahlen, sondern eine Erzählung. „Komprimierung“ ist ein technischer Begriff, den nur Ingenieure interessieren; „Deployment freischalten“ ist ein Geschäftsbegriff, für Chefs und Investoren. Aus 5,9 GB „Deployment freischalten“ zu machen, ändert die Frage im Kopf des Zuhörers von „Wie groß ist das Modell?“ zu „Wie viele Karten kann ich mir sparen?“. Die technischen Parameter haben sich nicht geändert, das Ziel der Erzählung schon, das ist die Wende, die vor zwei Monaten bei der ersten Vorstellung vollzogen wurde.
Die Nutznießer im Überblick: Erstens die Markt- und Finanzierungsgeschichte des Herstellers; zweitens die Inhaltsverbreiter, die neue Wörter zu schreiben haben; indirekt profitieren sogar diejenigen auf der Seite des Auftraggebers, die ein Projekt vorantreiben wollen, weil gefällige Wörter den Widerstand gegen das Projekt verringern. Der einzige, der nicht profitiert, ist der, der bezahlt und abnimmt – sofern er die Begriffe vor Vertragsabschluss nicht wieder in Zahlen zerlegt hat.
Q3: Drei Tage, fünf Repositories, tausende Sterne – Wie ist die Welle gleichnamiger Projekte um Jev zu lesen?
Shiwen: Nach der Analyse der Hersteller-Wortbildung schauen wir auf die Community. Das kommerzielle Modell Jev von TypeSafe: Innerhalb von drei Tagen tauchten auf GitHub fünf Projekte in dieselbe Richtung auf, zusammen über zehntausend Sterne. Ist das ein Beweis für technische Hype?
Yongliang: Zuerst die überprüfbaren Fakten auf den Tisch legen, dann über die Lesart reden.
Jev ist ein kommerzielles Modell von TypeSafe. Laut offiziellem Blog von TypeSafe bezeichnet es sich als System-One-Modell: Es generiert keine Antworten Wort für Wort, sondern gibt die Wahrscheinlichkeit jeder Option direkt für gegebene Optionen aus, verwendet für schnelle Verzweigungsentscheidungen bei Agents. TypeSafe hat das Modelldesign nicht öffentlich gemacht.
Die Welle der gleichnamigen Projekte begann am 16. September und dauert bis heute drei Tage. Laut öffentlichen GitHub-Daten: browser-use/jev-ultrafast 5487 Sterne, das README präsentiert eine Demo „7,1 Sekunden um ein Flugticket von Zürich nach London zu buchen“, oben auf der README-Seite ist der Einstieg zur Warteliste (Waitlist) von Browser Use Cloud; tamaratran/fast-jev-compaction 3206 Sterne; TheoLeeCJ/SemIf 1585 Sterne, ursprünglich OpenJev, auf der Startseite wird erklärt, dass keine Verbindung zu TypeSafe besteht; vinnylarouge/jevlike 885 Sterne, selbstbeschrieben „Jev ist ein kommerzielles Modell von TypeSafe, Design nicht öffentlich, dieses Repository ist ein unabhängiges Einsteigermodell mit gleicher Ein-/Ausgabeform“; jarrodwatts/jev-trader 866 Sterne, ein On-Chain-Handelsbot, der alle 300 Millisekunden eine Kauf-/Verkaufsentscheidung trifft. Der Hacker-News-Thread zu „OpenJev“ erhielt 534 Upvotes.
In dieser Gruppe von Zahlen gibt es zwei Dinge, die getrennt gelesen werden müssen. Das erste ist eine Marketing-Aktion: Das schnellste Repository platziert Demo und Waitlist-Trichter auf demselben Bildschirm, das Wachstum der Sterne ist selbst der Trichtereingang – das ist kein technischer Beweis, sondern Kundenakquise-Ingenieurswesen, ziemlich gut gemacht, aber es beantwortet nicht die Frage „Funktioniert dieses Modell?“. Das Mitläufer-Namensgebende ist ähnlich: Der Name hängt sich an den Trend, Sterne wachsen schnell, aber Sterne sind niemals gleichbedeutend mit Verwendbarkeit. Als alter Dienstleister sage ich: In Bewertungssitzungen GitHub-Sterne als technischen Beweis zu nutzen, ist methodisch derselbe Fehler wie die Länge der Schlange vor einem Restaurant als Geschmacksbewertung zu nutzen.
Das zweite Ding ist genau das gesunde Signal. SemIf hat den Namen geändert und erklärt, dass keine Verbindung zu TypeSafe besteht, jevlike erklärt explizit, es sei ein „unabhängiges Einsteigermodell mit gleicher Ein-/Ausgabeform“ – diese beiden Haftungsausschlüsse sind die Korrektur der Community für das, was der Hersteller nicht offengelegt hat. Wenn ein Trend aufkommt und jemand bereit ist, Zeit für eine unabhängige Implementierung mit Formkompatibilität zu investieren und „Ich bin nicht offiziell, das Design kenne ich nicht“ auf die Startseite schreibt, zeigt das, dass in der Community jemanden die Reproduzierbarkeit wichtig ist. Marketing-Aktionen werden ebben, Haftungsausschlüsse bleiben. Diese Welle zu lesen, reicht es, auf Letztere zu schauen.
Q4: Wie man bei Beschaffung und Projektstart mit drei Fragen die Rhetorik entlarvt
Yongliang: Das ist das, was ich Ihnen in dieser Ausgabe am liebsten geben möchte. Drei Fragen, direkt anwendbar in der Bewertungssitzung.
Die erste Frage: Bitte geben Sie eine reproduzierbare Definition an. Welches Modell, welche Präzision ist der Nenner bei „9-mal kleiner“? Kann die Benchmark-Liste und die Aggregierungsgewichtung bei „98,2 %“ aufgelistet werden? Der Schlüssel bei dieser Frage liegt nicht in der Antwort, sondern darin, wie der Gegner sie aufnimmt. Wer eine Liste liefern kann, dessen Zahlen halten wahrscheinlich einer Prüfung stand; wer anfängt von „Branchenüblichkeit“ oder „kann nicht öffentlich gemacht werden“ zu reden, bei dem wissen Sie – er schützt keine Geheimnisse, sondern die Zahlen. Die zweite Frage: Gibt es Dritttests? Nicht einen Bericht suchen, der offizielle Zahlen zitiert, sondern ein Team ohne Interessenkonflikt zum Hersteller finden, das unter vergleichbaren Bedingungen vergleichbare Ergebnisse liefert. Letzte Woche haben wir einen Fall aus der Infrastruktur zerlegt, bei dem die offiziellen Angaben alle aus einer einzigen Quelle stammten – Technologie-Stack und Schwierigkeiten waren alles einseitige Aussagen – selbst gemeldete Kennzahlen kann man glauben, man darf ihnen nur nicht blind glauben. Die dritte Frage am härtesten: Schreiben Sie die Werbeversprechen in die Abnahmeklauseln. „Sie sagen near-lossless, dann schreiben wir den Akzeptanzstandard nach Fehlergrenzen; Sie sagen 98,2 %, dann testen wir die Abnahme Punkt für Punkt nach Ihrer Benchmark-Liste.“ Sobald aus Rhetorik Vertragssprache wird, fängt der Gegner entweder an, jeden Begriff ernsthaft zu definieren, oder der Begriff verschwindet aus dem Angebot – beide Ergebnisse sind ein Gewinn für den Auftraggeber.
Diese drei Fragen nutze ich seit über einem Jahrzehnt, das Prinzip in einem Satz: Marketingbegriffe zeichnen sich dadurch aus, dass sie nur nach oben berichtet, aber nicht nach unten abgenommen werden können. Jedes Wort, das nicht in die Abnahmeklauseln geschrieben werden kann, sollte in der Beschaffungsentscheidung Gewicht Null haben.
Q5: Abschluss – Welche Rhetorik ist alarmierend, welche Übertreibungen sind akzeptabel?
Shiwen: Zum Schluss ein Maßstab für das Publikum zur Unterscheidung?
Yongliang: Mein Maßstab richtet sich nach der „Richtung der Übertreibung“, nicht nach der Branche.
Bei Geschwindigkeits-Übertreibungen ist meine Toleranz hoch. Eine Demo wie „7,1 Sekunden um ein Flugticket zu buchen“, auch wenn sie unter den besten Bedingungen aufgenommen wurde, ihre Behauptungsrichtung ist „schnell“, und die Verifizierungskosten für „schnell“ sind extrem gering – Sie laufen es einmal selbst und wissen, ob es stimmt. Bei Fähigkeits-Behauptungen habe ich Null Toleranz. „98,2 % Leistungserhalt“, „near-lossless“ – die Behauptungsrichtung ist „äquivalent“, und die Verifizierungskosten für „äquivalent“ sind extrem hoch, wenn Sie fertig verifiziert haben, ist der Vertrag bereits unterschrieben, das Geld bereits ausgezahlt. Es gibt eine Kategorie, die noch alarmierender ist als Fähigkeits-Behauptungen: Definitions-Rhetorik. Das Wort „deployment unlock“ an sich hat keinen verifizierbaren Inhalt, es tut nichts anderes, als das Problem neu zu definieren – aus „Modell wurde komprimiert“ wird „Deployment wurde freigeschaltet“. Das Merkmal von Definitions-Rhetorik ist: Je angenehmer es sich anhört, desto mehr müssen Sie zurückschauen und fragen: Wohin ist eigentlich das ursprüngliche Problem verschwunden?
Also meine Reihenfolge: Geschwindigkeits-Übertreibungen, einfach darüber lächeln, selbst einmal reproduzieren zählt; Fähigkeits-Behauptungen, zuerst nach Definition und Dritten fragen, Abnahmeklauseln bringen die Wahrheit ans Licht; Definitions-Rhetorik, direkt dem ursprünglichen Problem nachstellen. Bei den Plänen, die ich in siebzehn Jahren geprüft habe, führten fast alle Streitigkeiten nicht auf falsche Zahlen zurück, sondern darauf, dass Begriffe von Anfang an nicht klar definiert waren.
Nachwort
Shiwen: Zum Schluss, fassen Sie diese Ausgabe in einem Satz zusammen?
Yongliang: Marketingbegriffe sind keine Lügen, sondern komprimierte Pakete. Die Aufgabe des technischen Managers ist es nicht, sie zu verfluchen oder zu glauben, sondern sie vor Vertragsabschluss zu entpacken – Nenner, Liste, Abnahmeklauseln, erst nach dem Entpacken ansehen, oft ist es nicht so schrecklich und nicht so billig, wie es schien.
Shiwen: Dieser Satz gilt für alle. Bis zur nächsten Ausgabe.
[Technische Tiefe] Was macht Ternärquantisierung eigentlich, und warum sind 5,9 GB die am besten überprüfbare Zahl im ganzen Blogbeitrag
Die Hauptlinie dieser Ausgabe ist das Lesen von Rhetorik, manche Leser wollen vielleicht eine Ebene tiefer wissen: Was ist Ternärquantisierung, warum ist die seltsame Zahl „1,76 effektive Bits“ eigentlich der ehrlichste Teil des offiziellen Blogs.
Ternäre Gewichte: {-1, 0, +1}. Herkömmliche Quantisierung drückt jedes Gewicht von 16 oder 32 Bit Floating Point auf weniger Bits, zum Beispiel 4-Bit-Integer. Ternarisierung geht weiter: Jedes Gewicht darf nur minus eins, null, plus eins annehmen, dazu kommt eine Gruppe von FP16-Gruppenskalierungskoeffizienten. Offiziell heißt es, diese Kombination kommt auf 1,76 effektive Bits pro Gewicht.
Warum 1,76 ehrlich ist. Drei Werte selbst brauchen weniger als 2 Bits zur Kodierung,加上 Gruppenskalierung und Kodierungsaufwand, auf jedes Gewicht entfallen 1,76 Bits. Diese Zahl hat Nachkommastellen, ist nicht rund, was genau zeigt, dass es sich um einen berechneten Durchschnittswert handelt, nicht um eine herausgepickte Ganzzahl. 27 Milliarden Parameter mal 1,76 Bits, geteilt durch 8 Bits pro Byte, ergibt rund 5,9 GB – diese Multiplikation kann jeder nachrechnen. Dass Zahlen nachrechenbar sind, ist der Grund für ihre Glaubwürdigkeit; dass glaubwürdige Zahlen genutzt werden, um nicht nachrechenbare „98,2 %“ zu verpacken, das ist genau das Wesen der Rhetorik.
Die verlorenen 1,8 % sind nicht gleichmäßig verteilt. Ternarisierung schadet verschiedenen Aufgaben unterschiedlich: Bei Aufgaben mit glatter Gewichtsverteilung und hoher Fehlertoleranz ist der Verlust nahe null; bei Aufgaben, die von feinen numerischen Unterschieden abhängen, fällt die Punktzahl deutlich. Der aggregierte Durchschnittswert überdeckt genau diese Ungleichmäßigkeit. Das ist die Grundlage für den Satz in Q1: Zuerst nach der Liste fragen, dann über Glauben reden.
Zurück zur Hauptlinie dieser Ausgabe. Nachrechenbare Zahlen sind nie beängstigend, beängstigende Zahlen lassen sich oft nicht nachrechnen. Das ist das erste Prinzip beim Lesen aller Hersteller-Rhetorik.
Quellen für diese Ausgabe
- PrismML offizieller Blog 2026-09-17: Veröffentlichung von Ternary Bonsai 2 27B (basiert auf Qwen3.8 27B; Ternäre Gewichte + FP16-Gruppenskalierung; 1,76 effektive Bits pro Gewicht; 5,9 GB; 262K Kontext; Apache 2.0; „mehr als 9-mal kleiner, behält 98,2 % der aggregierten Benchmark-Leistung“ sind allesamt offiziell gemeldete Kennzahlen, vollständige Benchmark-Liste und Aggregationsmethode nicht offengelegt)
- PrismML offizieller Blog (vor zwei Monaten): Veröffentlichung der ersten Generation Bonsai 27B, offizielle Rhetorik „Komprimierung wird zu Deployment-Freischaltung“ (deployment unlock)
- Hacker News 2026-09-17: Diskussionsthread zu Ternary Bonsai 2, 563 ▲
- TypeSafe offizieller Blog: Introducing System One Models and Jev (Jev ist ein kommerzielles Modell, Modelldesign nicht offengelegt, allesamt offizielle Aussagen)
- GitHub öffentliche Daten (Stand Vormittag 2026-09-19): browser-use/jev-ultrafast 5487★, tamaratran/fast-jev-compaction 3206★, TheoLeeCJ/SemIf 1585★ (Startseite erklärt keine Verbindung zu TypeSafe), vinnylarouge/jevlike 885★ (selbstbeschrieben als unabhängiges Einsteigermodell mit gleicher Ein-/Ausgabeform), jarrodwatts/jev-trader 866★ (alle fünf Repositories erstellt am 2026-09-16)
- Hacker News: Diskussionsthread zu „OpenJev“, 534 ▲