Nanbeige4.3-33B veröffentlicht: 33B dicht, 512K Kontext, Apache-2.0-Gewichte, eigene Benchmarks im Konflikt mit fremden Modellkarten
Laut einem Bericht von MarkTechPost vom 25. Oktober 2026 hat das zu BOSS Zhipin gehörende Nanbeige LLM Lab auf Hugging Face unter Apache-2.0-Lizenz das dichte 33B-Modell Nanbeige4.3-33B sowie eine Base-Version für eigenes Nachtraining veröffentlicht, mit Unterstützung für 524.288 Token Kontext; die eigene Tabelle führt in 17 von 20 Benchmarks, doch einige Konkurrenzwerte weichen von den offiziellen Modellkarten der Anbieter ab.
Was sich geändert hat
Laut einem Bericht des MarkTechPost-Journalisten Asif Razzaq vom 25. Oktober 2026 hat das Nanbeige LLM Lab (laut Bericht Teil der Recruiting-Plattform BOSS Zhipin) auf Hugging Face unter Apache-2.0-Lizenz Nanbeige4.3-33B veröffentlicht, zusammen mit Nanbeige4.3-33B-Base für eigenes Nachtraining. Der Bericht bezeichnet das Modell als dichtes 33B-Sprachmodell (kein MoE); die zitierte config.json deklariert die Standardarchitektur LlamaForCausalLM: 52 Schichten, Hidden-Dimension 7.168, 56 Query- und 8 Key-Value-Köpfe (Grouped-Query-Attention), FFN-Zwischendimension 22.016, Vokabular 166.912 Token, RoPE-Theta 120.000.000, maximal 524.288 Positionen (512K Kontext), Eingabemodalität reiner Text; zudem nennt die Modellkarte laut Bericht eine Community-Quantisierung. Der Bericht beschreibt drei Steuerfelder im Chat-Template: enable_thinking (standardmäßig aktiv), preserve_thinking und tools; Nanbeige empfiehlt preserve_thinking für mehrrundige Tool-Nutzung und Coding-Agenten, für Tool-Aufrufe wird das XML-Aufrufformat empfohlen. Das Lab positioniert Nanbeige4.3-33B laut Bericht als „Lehrer“-Modell der Serie und plant, Agentenfähigkeiten in kleinere Modelle zu destillieren, beginnend mit Nanbeige4.3-3B. Zu den Benchmarks: In der eigenen Vergleichstabelle von Nanbeige führt das Modell gegenüber Qwen3.8-27B, Muse-Glimmer-30B und Gemma4-31B in 17 von 20 Punkten: Terminal-Bench 2.1 erreicht 80,9 (Qwen3.8-27B: 73,0), DeepSWE 65,5 gegenüber 42,5; Terminal-Bench 4.0 erreicht 23,8 (laut Bericht der niedrigste Wert des Modells), bei SWE-Bench Pro liegt es mit 60,3 hinter Qwen3.8-27B mit 61,7. Der Bericht weist ausdrücklich darauf hin, dass mehrere Konkurrenzwerte in der Nanbeige-Tabelle den offiziellen Modellkarten widersprechen: Meta gibt für Muse-Glimmer-30B bei SWE-Bench Pro 51,2 an, Gemma4-31B 36,9, während Nanbeige genau das Gegenteil listet; Google nennt für Gemma 4 31B bei GPQA Diamond 84,3, die Nanbeige-Tabelle zeigt 91,3; Meta berichtet für Muse-Glimmer-30B bei Terminal-Bench 2.1 51,7, Nanbeige misst 61,8. Der Bericht hält unterschiedliche Test-Harnesse für eine teilweise Erklärung, doch das SWE-Bench-Pro-Paar wirke vertauscht; bis zur unabhängigen Reproduktion seien diese Zeilen als vorläufig zu betrachten. Zum Deployment: Die Modellkarte enthält laut Bericht Rezepte für Transformers, SGLang und vLLM, das Serverbeispiel nutzt 4-fachen Tensor-Parallelismus zusammen mit den Inferenz- und Tool-Call-Parsern von Qwen3; aus der config.json leitet der Bericht ab, dass BF16-Gewichte rund 66 GB benötigen, der KV-Cache unter BF16 etwa 208 KiB pro Token und eine vollständige Sequenz mit 524.288 Token rund 112 GB. Zum Redaktionszeitpunkt habe kein Hugging-Face-Inferenzanbieter das Modell gehostet. Alle genannten Benchmarks sind Herstellerangaben oder Medienwiedergaben, die Gewichts- und KV-Cache-Zahlen sind Schätzungen des Berichts, keine offiziellen Angaben; wir haben keine eigenen Tests durchgeführt und weder Konfigurations- noch Lizenzdateien des Modell-Repositories unabhängig geprüft.
Auswirkungen für Entwickler
Die unmittelbarste Einschränkung für Entwickler ist die Deployment-Form. Das offizielle Rezept ist laut Bericht 4-facher Tensor-Parallelismus auf einem Multi-GPU-Server, kein Single-GPU-Workstation-Pfad; zugleich nennt der Bericht rund 66 GB für die BF16-Gewichte, was selbst ohne Quantisierung eine Multi-GPU- oder Multi-Node-Umgebung erfordert, um den Dienst zu betreiben. Im Evaluierungsplan muss also zuerst die Hardware geklärt werden, bevor es um Modellqualität geht. Dies ist eine bedingte Analyse: Der tatsächliche Speicherbedarf hängt von Inferenz-Framework, Batch-Größe und Nebenläufigkeit ab und ist auf der eigenen Maschine zu messen. Zweitens die realen Kosten des langen Kontexts. Der Bericht schätzt den KV-Cache unter BF16 auf etwa 208 KiB pro Token und rund 112 GB für eine Sequenz mit 524.288 Token – in derselben Größenordnung wie die Gewichte selbst. 512K ist damit eher eine bedarfsweise aktivierbare Fähigkeit als eine Standardkonfiguration: Ist der Anteil langer Anfragen im Geschäft gering, senkt ein niedrigeres Kontextlimit das Speicherbudget deutlich und erhöht die Nebenläufigkeit; soll die volle Länge tatsächlich gefahren werden, wird der KV-Cache zum Hauptkostenfaktor, den quantisierte Gewichte nicht direkt lösen – dafür braucht es KV-Quantisierung oder Paging-Strategien. Drittens Integration und Framework-Anpassung. Laut Bericht wird für Tool-Aufrufe XML empfohlen, und das Serverbeispiel kombiniert die Inferenz- und Tool-Call-Parser von Qwen3. Für Teams, die ihre Agenten-Schleife bereits auf ein OpenAI-artiges Function-Calling-Protokoll gebaut haben, bedeutet das in der Regel Anpassungen an Parsing-Schicht und Prompt-Template, nicht nur eine neue Endpunkt-Adresse. Dass enable_thinking standardmäßig aktiv ist und preserve_thinking frühere Denkinhalte behält, verändert zudem die Token-Zusammensetzung jeder Runde und die Mehrrunden-Kosten; wenn das Framework Verlaufsrunden kürzt oder umsortiert, sollte das tatsächliche Verhalten dieser Steuerfelder zuerst geprüft werden. Viertens die Bewertungsgrundlage. Der Bericht listet Konflikte zwischen der Nanbeige-Eigenangabe und offiziellen Modellkarten von Meta und Google in mehreren Benchmark-Zeilen, wobei das SWE-Bench-Pro-Paar offenbar vertauscht ist; jede Aussage der Art „stärker als ein bestimmtes knapp-30B-Modell“ hält daher bis zur unabhängigen Reproduktion nicht. Als Anhaltspunkt dienen können strukturelle Informationen innerhalb derselben Tabelle: Terminal-Bench 2.1 wird als führend angegeben, während Terminal-Bench 4.0 in absoluten Zahlen nur 23,8 erreicht; diese Kluft innerhalb einer Benchmark-Familie deutet darauf hin, dass die Fähigkeiten stark von Aufgabe und Test-Harness abhängen. Die Auswahl sollte auf eigenen Reproduktionen beruhen. Fünftens Modalität und Lizenz. Das Modell ist reiner Textinput und verarbeitet weder Screenshots noch Diagramme oder Videos, ersetzt also keine Workflows mit visueller Eingabe. Bei der Lizenz ist zwischen offenen Gewichten und Lizenzbedingungen zu unterscheiden: Der Bericht nennt Apache 2.0 für die Gewichte, was großzügiger ist als nur offene Gewichte, doch maßgeblich bleibt die dem Modell-Repository beiliegende Lizenzdatei; aus der bloßen Downloadbarkeit der Gewichte lassen sich kommerzielle Nutzung und Weitergabe nicht ableiten. Nach Abgleich mit dem aktuellen KimiSeek-Katalog stehen weder Nanbeige4.3-33B noch Nanbeige4.3-33B-Base in der Liste der verfügbaren Modelle; die im Bericht genannte Verbreitung meint den Hugging-Face-Gewichtsdownload, und falls eine gehostete API gemeint ist, den eigenen Kanal des Anbieters.
Integration und Bewertung
Das Folgende sind Empfehlungen und bedingte Analysen, keine Tatsachenbehauptungen aus dem Bericht. Entscheidung 1 (Wahl des Inferenz-Stacks): Der Bericht nennt Rezepte für SGLang und vLLM, das Serverbeispiel nutzt 4-fachen Tensor-Parallelismus und bindet die Inferenz- und Tool-Call-Parser von Qwen3. Die Entscheidung lautet, nur einen Stack oder zwei parallel zu pflegen. Bedingung ist, ob man auf Tool-Aufrufe angewiesen ist: Braucht der Agentenablauf stabiles Function-Calling-Parsing, kann die dargelegte Parser-Bindung bedeuten, dass ein Stackwechsel das Parsing-Verhalten ändert – dann lohnt der Aufwand für zwei Stacks; für reine Textinferenz ist ein Stack wirtschaftlicher. Als messbares Kriterium lassen sich 20 bis 50 Aufgaben mit Tool-Aufrufen auf beiden Stacks hinsichtlich Formatfehler- und Parsing-Fehlerrate vergleichen; sind die Unterschiede akzeptabel, auf einen Stack reduzieren. Entscheidung 2 (Kontextlimit und Speicherbudget): Der Bericht schätzt rund 66 GB für BF16-Gewichte, etwa 208 KiB KV-Cache pro Token und rund 112 GB für eine volle Sequenz. Die Entscheidung betrifft das Kontextlängenlimit und die Nebenläufigkeit des Dienstes. Bedingung ist die tatsächliche Kontextverteilung der Anfragen: Liegen die meisten unter 32K, gibt ein deutlich unter 512K liegendes Limit viel Speicher für höhere Nebenläufigkeit frei und reserviert 512K für wenige lange Aufgaben. Als messbares Kriterium lassen sich Quantile der Kontextlängen aus Produktion oder Lasttests erfassen und unter dem gesetzten Limit Spitzen-Speicherverbrauch sowie P95-Latenz bis zum ersten Token messen; liegen beide im Hardware-Spielraum, passt das Limit, andernfalls senken oder auf die Community-Quantisierung wechseln (laut Bericht ist eine gelistet; die Qualitätsfolgen sind selbst zu testen). Entscheidung 3 (Priorität und Reihenfolge der Evaluierung): Der Bericht zeigt Konflikte der Eigenangaben mit offiziellen Modellkarten bei SWE-Bench Pro, GPQA Diamond und Terminal-Bench 2.1, wobei das SWE-Bench-Pro-Paar offenbar vertauscht ist. Die Entscheidung ist, ob weiter über öffentliche Ranglisten diskutiert oder das Budget in eigene Reproduktionen gesteckt wird. Bedingung ist, ob die Arbeitslast eng mit Agenten-Programmierung oder Büro-Kollaboration zusammenhängt; wenn ja, sind eigene Repositories und echte Aufgaben wertvoller als Ranglisten. Als messbares Kriterium lässt sich mit demselben Evaluierungsskript die Ausführungs- oder Bestehensrate auf eigenen Aufgaben messen und innerhalb desselben Skripts mit einer Baseline gleicher Größe vergleichen; nur Unterschiede im selben Test-Harness sind für die Auswahl verwendbar. Entscheidung 4 (Token-Zusammensetzung mehrrundiger Agenten): Laut Bericht ist enable_thinking standardmäßig aktiv, preserve_thinking behält Denkinhalte früherer Runden, und die offizielle Empfehlung gilt für mehrrundige Tool-Nutzung und Coding-Agenten. Die Entscheidung ist, Denkverläufe standardmäßig zu behalten oder rundenweise zu kürzen. Bedingung ist die Zahl der Gesprächsrunden: Je mehr Runden, desto stärker vergrößern behaltene Denkinhalte Kontext und Kosten. Als messbares Kriterium lassen sich auf denselben mehrrundigen Aufgaben Erfolgsrate, Gesamt-Token-Verbrauch und Latenz bis zum ersten Token für Behalten und Kürzen vergleichen; erst wenn die Erfolgsrate nicht deutlich sinkt, ist Kürzen zur Kostenkontrolle sinnvoll.
Grenzen und offene Fragen
Klarzustellen ist: Nach Abgleich mit dem aktuellen KimiSeek-Online-Katalog stehen Nanbeige4.3-33B und Nanbeige4.3-33B-Base nicht in der Liste der verfügbaren Modelle; diese Version wird derzeit nicht auf KimiSeek angeboten. Die im Bericht genannte Verbreitung und Verfügbarkeit meint den Hugging-Face-Gewichtsdownload, und falls eine gehostete API gemeint ist, den Kanal des Anbieters selbst. Der Bericht bestätigt nur, dass zum Redaktionszeitpunkt kein Hugging-Face-Inferenzanbieter das Modell hostet, und behauptet nicht, dass alle anderen Hosting-Kanäle es nicht tun; ob andere Kanäle es anbieten, ist gesondert zu prüfen. Wir haben weder Modell-Repository noch Konfigurations- oder Lizenzdateien unabhängig geprüft; die genannten Architekturparameter, Steuerfelder und Lizenzangaben stammen aus der Wiedergabe von Modellkarte und config.json durch den Bericht. Alle Benchmark-Werte im Bericht sind Eigenangaben von Nanbeige oder Medienwiedergaben, ohne unabhängige Drittreproduktion, und der Bericht selbst weist auf Konflikte mehrerer Konkurrenzwerte mit offiziellen Modellkarten von Meta und Google hin, wobei das SWE-Bench-Pro-Paar offenbar vertauscht ist; diese Zeilen gelten bis zur unabhängigen Reproduktion als vorläufig. Die Angaben von rund 66 GB Gewichten, etwa 208 KiB KV-Cache pro Token, rund 112 GB KV-Cache für volle Sequenzen und 4-facher Tensor-Parallelismus sind Schätzungen des Berichts aus der config.json oder Wiedergaben der Modellkarte, keine offiziellen Angaben und keine eigenen Messungen; der tatsächliche Speicherbedarf hängt von Inferenz-Framework, Batch-Größe, Nebenläufigkeit und Kontextverteilung ab und ist auf eigener Hardware zu messen. Apache 2.0 ist die im Bericht genannte Lizenzbeschreibung; die Downloadbarkeit der Gewichte ist nicht gleichbedeutend mit den Lizenzbedingungen, und für kommerzielle Nutzung und Weitergabe ist die dem Modell-Repository beiliegende Lizenzdatei maßgeblich. Dass für Tool-Aufrufe XML empfohlen wird, die Parser an Qwen3 angebunden sind und enable_thinking standardmäßig aktiv ist, stammt aus der Beschreibung von Modellkarte und Chat-Template im Bericht; das tatsächliche Verhalten kann sich mit Versionsupdates ändern. Der Destillationsplan zu Nanbeige4.3-3B ist eine angekündigte Planaussage des Anbieters, ohne öffentliche Gewichte oder Fähigkeitsdaten, und nicht als bereits gelieferte Fähigkeit zu betrachten.