Die Benchmark-Tabelle von Nanbeige4.3-33B macht Lust auf einen Test. Das verfügbare, als Apache-2.0 lizenziert gekennzeichnete Modell hat 33 Milliarden Parameter und eine dichte Architektur. Der Entwickler meldet für Terminal-Bench 2.1 einen Wert von 80,9 gegenüber 73,0 für Qwen3.8-27B; bei DeepSWE stehen 65,5 gegenüber 42,5. Das ist ein guter Grund für einen Vergleichstest, nicht für einen sofortigen Austausch des produktiven Agentenmodells. [1]

In derselben Tabelle liegt Qwen bei SWE-Bench Pro leicht vorn: 61,7 gegenüber 60,3. Andere Aufgaben, anderes Ergebnis. Die Zahlen stammen vom Entwickler, nicht aus meinen Messungen oder einer unabhängigen Wiederholung. Laut Modellkarte galten innerhalb jedes Benchmarks dieselben Inferenzparameter und derselbe Harness für die verglichenen Modelle; zwischen den Benchmarks wurden unterschiedliche Harnesses eingesetzt. Zudem ist Qwen3.8-27B nicht automatisch das Modell, das bei anderen bereits im Einsatz ist. [1]

Das Modell kommt nicht allein beim Agenten an

Für mehrschrittige Werkzeugnutzung empfiehlt die Modellkarte preserve_thinking=true, damit vorherige Denkabschnitte erhalten bleiben. Als bevorzugtes Werkzeugformat nennt sie XML; JSON wird ebenfalls unterstützt. Der angegebene Kontext reicht bis 512K. Keine dieser Angaben beweist, dass ein konkreter Server mit einer bestimmten Quantisierung Werkzeuge korrekt aufruft oder der volle Kontext bei akzeptablem Speicherbedarf und Tempo nutzbar ist. Gewichte, Chat-Template, Parser und Harness bilden erst zusammen einen Agenten. [1]

Viele werden statt der ursprünglichen BF16-Gewichte ein GGUF-Derivat nutzen. AtomicChat bietet solche Dateien an: AD-Q4_K_M ist laut Karte 21,2 GB groß, Q8_0 35,2 GB. Das sind Dateigrößen und kein vollständiger Laufzeitspeicherbedarf; KV-Cache, Kontext und parallele Anfragen kommen hinzu. Die Karte erklärt außerdem, dass das ursprüngliche einfache Q4_K_M nach besseren Ergebnissen der Imatrix-Varianten entfernt wurde. Wer exakt diese alte Datei aus diesem Repository empfiehlt, hat den aktuellen Bestand nicht geprüft. [2]

Tokentreue ist kein Aufgabenerfolg

Der Anbieter der Quantisierung vergleicht die nächste Tokenvorhersage seiner Dateien mit BF16 auf einem eigenen mehrsprachigen Teststand. Für das entfernte einfache Q4_K_M nennt er 89,9 % Übereinstimmung beim Top-Token, für AD-Q4_K_M 92,6 % und für Q8_0 98,0 %. Die Karte beschreibt das Verfahren und verweist auf Rohprotokolle. Das sind hilfreiche Diagnosedaten des Derivatanbieters, keine Erfolgsraten von Agentenaufgaben. 92,6 % bedeutet weder, dass 92,6 % der Aufgaben gelingen, noch dass ein Coding-Benchmark den Wechsel zur Quantisierung unbeschadet übersteht. [2]

Ein einzelnes anderes Token kann einen Werkzeugnamen, ein Argument oder ein Trennzeichen verändern. Es kann aber auch folgenlos bleiben. Die ursprüngliche Agenten-Benchmark-Tabelle und der Vergleich der quantisierten Dateien testen verschiedene Dinge. Wer sie gedanklich zu einer einzigen Leistungsangabe verschmilzt, vergleicht Äpfel mit Schnittstellenfehlern. [1][2]

So würde ich testen

Ich würde harmlose, feste Aufgaben verwenden: Codeänderungen mit Tests, mehrschrittige Recherche mit Quellenprüfung und Werkzeugaufrufe mit schwierigen Argumenten. Aufgaben, Berechtigungen, Bewertungsregeln und Wiederholungsbudget müssen für jede Quantisierung identisch bleiben. Dokumentiert gehören exakte Dateien und Hashes, Template-Einstellungen, Server- und Parser-Versionen, Kontextbudget und Temperatur. Entscheidend ist der erreichte Endzustand, nicht die selbstbewusste Zusammenfassung des Modells.

Erstversuchserfolg und Erfolg nach Wiederholungen müssen getrennt ausgewiesen werden, ebenso Latenz, Spitzen-Speicherbedarf und ungültige Werkzeugaufrufe. Auch sollte geprüft werden, ob Werkzeuge tatsächlich aufgerufen und ihre Ergebnisse an das Modell zurückgegeben wurden. Einen langen Kontext testet man bei der beanspruchten Länge, statt ihn bis zum erfolgreichen Start zu kürzen. Das ist ein Testvorschlag. Ich habe Nanbeige nicht selbst vermessen und veröffentliche keine eigenen Erfolgs- oder Geschwindigkeitswerte.

Legitime Sicherheitsunterstützung und faktische Offenheit gehören getrennt von der Ablehnung schädlicher Anfragen geprüft. Weniger Ablehnung bedeutet nicht automatisch bessere Kompetenz bei autorisierter Sicherheitsarbeit. Weder die Coding-Tabelle noch die Tokentreue-Messung beantwortet diese Frage. [1][2]

Mein Urteil: Kandidat, kein Ersatzmodell. Die verfügbaren Gewichte und die Lizenzkennzeichnung ermöglichen einen Test; die Entwicklerzahlen machen ihn interessant. Die Quantisierungsdaten helfen bei der Auswahl der Testdateien, nicht bei der Entscheidung über einen produktiven Gewinner. Wer behauptet, die quantisierte Variante sei einem bestehenden Agenten überlegen, sollte Datei, Template, Parser, Aufgabenprotokolle und Vergleichsbasis vorlegen. Ohne das liegt eine interessante Hypothese vor, kein belastbarer Agenten-Benchmark.

Quellen

[1] https://huggingface.co/Nanbeige/Nanbeige4.3-33B [2] https://huggingface.co/AtomicChat/Nanbeige4.3-33B-GGUF