Du entwickelst einen automatischen Assistenten, der Software repariert, mit deinem Terminal kommuniziert und mehrfach nachdenkt, bevor er ein Werkzeug einsetzt. Zwei unterschiedliche Motoren stehen zur Wahl. Der eine ist klein, kompakt und läuft auf deinem Arbeitsrechner. Der andere ist ein Gigant, der nur auf teuren Spezial-GPUs funktioniert, aber ganze Code-Repositorien durchforsten kann. Genau diesen Größenvergleich zeigt die aktuellen Veröffentlichungen der Agentic-KI-Modelle Nanbeige 4.2-3B und Laguna S 2.1. Beide sind für agentische Arbeitslasten optimiert – Aufgaben, die mehrstufiges Denken, Werkzeugeinsatz und Interaktion mit externen Umgebungen erfordern. Die Umsetzung dieser Fähigkeiten könnte unterschiedlicher kaum sein.
Die Analyse zeigt die Stärken und Grenzen beider Architekturen. Nanbeige 4.2-3B ist ein kompaktes dichtes Modell mit etwa vier Milliarden Parametern, davon etwa drei Milliarden nicht zu den Einbettungen zählend. Laguna S 2.1 ist ein Mischung-von-Experten-Modell (MoE) mit 118 Milliarden Parametern, pro Token werden jedoch nur rund acht Milliarden aktiviert. Nanbeige durchläuft die gleichen Gewichte mehrfach. Laguna greift auf einen großen Expertenpool zu, wählt für jeden Schritt nur einen Bruchteil aus. Das ist nicht nur Skalierung, sondern ein grundlegend verschiedener Ansatz: zweimal rechnen mit wenig Speicher gegen einmal rechnen mit riesigem, sparsam genutztem Wissen.
Nanbeige 4.2-3B: Kompakter Kraftprotz mit Schleifenarchitektur
Die Architektur von Nanbeige hat sich grundlegend geändert. Statt einer einfachen Llama-Struktur setzt das Modell auf einen Looped Transformer. Es gibt 22 physische Decoder-Layer, die zweimal durchlaufen werden – die gleichen Gewichte werden im zweiten Durchlauf wiederverwendet. Rechnerisch entspricht das etwa 44 Layer-Ausführungen, ohne 44 unabhängige Layer speichern zu müssen. Das reduziert den Gewichtsspeicher, nicht aber die Rechenzeit für die Inferenz. Jeder Token läuft tatsächlich zweimal durch den Transformer-Stapel. Das Modell hat 48 Aufmerksamkeitsköpfe mit einer Dimension von 128 sowie acht Key/Value-Köpfe. Im Vergleich zu anderen Modellen dieser Größe sind das viele – Qwen 3.6 35B A3B hat nur zwei KV-Köpfe.
Diese Schleifenstruktur bringt Herausforderungen für den KV-Cache. Teilt die Implementierung nicht explizit den Cache-Zustand zwischen den Durchläufen, benötigt jede Schleife eigene Key/Value-Einträge. Die Standardkonfiguration von Nanbeige scheint diese gemeinsame Nutzung nicht zu aktivieren. Der KV-Cache verbraucht etwa 176 KiB pro gecachten Token und aktiver Sequenz. Bei 16.000 Tokens Kontextlänge wären das rund 2,75 GiB, bei maximalen 256.000 Tokens etwa 44 GiB – fast doppelt so viel wie ein Qwen 3.6 mit 27 Milliarden Parametern bei gleicher Länge. Das ist eine beachtliche Menge, die selbst für ein 3B-Modell die Hardwareanforderungen erhöht. Eine GPU mit 16 GB VRAM kann das Modell bei moderaten Kontextlängen und sorgfältigen Einstellungen noch ohne Quantisierung betreiben. Eine 24-GB-GPU bietet mehr Spielraum für längere Prompts und höhere Gleichzeitigkeit.
Der Autor schlägt für Looped Transformer eine eigene Namenskonvention vor – ähnlich wie bei kleinen MoE-Modellen mit der Anzahl aktiver Parameter (etwa 26B-A4B). Für Nanbeige wäre „3B-2P“ (zwei Durchläufe) passend. Wer ein 3B-Modell herunterlädt, erwartet nicht, dass es annähernd so langsam ist wie ein 6B-Modell. Bei der Veröffentlichung stellte das Entwicklerteam eine spezielle vLLM-Version sowie einen Chat-Template mit zwei Steuerungsmöglichkeiten bereit: enable_thinking bestimmt, ob die aktuelle Antwort eine explizite Denkphase enthält, und preserve_thinking legt fest, ob Denkinhalte aus früheren Assistentenantworten erhalten bleiben. Für normale Chats und Frage-Antwort-Aufgaben kann man die Denkspuren abschalten. Für mehrstufige Werkzeugnutzung, Büro-Workflows und Coding-Agenten empfehlen die Entwickler, diese Inhalte zu behalten. Der Autor zeigt sich skeptisch: Denkspuren können 50.000 Tokens oder mehr umfassen. Selbst eine einzige gespeicherte Denkspur kann beim nächsten Schritt die maximale Kontextlänge erreichen lassen.
Trotz dieser Einschränkungen zeigt die veröffentlichte Evaluierung, dass Nanbeige das deutlich größere Qwen 3.5-9B auf den meisten agentischen, Code- und Denkaufgaben übertrifft. Auch Gemma 4 12B wird auf Benchmarks wie GDPval, SWE-Bench Verified, SWE-Bench Pro und Terminal-Bench 2.0 geschlagen. Die Ergebnisse hängen stark von der erlaubten Denk-Budget, den Werkzeugdefinitionen, der Prompting-Strategie, der Gesprächsverwaltung, der Wiederholungspolitik und der maximalen Anzahl von Aktionen ab. Für ein Modell dieser Größe ist das beachtlich.
Laguna S 2.1: Code-Riese mit Expertenmix
Ganz anders gelagert ist Laguna S 2.1, ein auf Code spezialisiertes MoE-Modell mit 118 Milliarden Parametern, pro Token werden etwa acht Milliarden aktiviert. Ein Routing-Mechanismus wählt während der Inferenz eine Teilmenge der Experten aus. So greift das Modell auf einen großen Pool gelernter Parameter zu, ohne jeden einzelnen für jeden Token auszuführen. Laguna besteht aus 48 Transformer-Layern. Zwölf nutzen globale Aufmerksamkeit, die restlichen 36 verwenden Sliding-Window-Aufmerksamkeit mit einem Fenster von 512 Tokens. Die globalen und lokalen Layer sind ungefähr im Verhältnis eins zu drei angeordnet. Globale Layer erlauben Informationsfluss über den gesamten Eingabekontext. Lokale Layer beschränken die Aufmerksamkeit auf nahe Tokens, reduzieren so Kosten für lange Kontexte und das KV-Cache-Wachstum.
Das Modell enthält 256 geroutete Experten und einen gemeinsamen Experten. Für jeden Token wählt der Router die Top Ten der gerouteten Experten zusätzlich zur gemeinsamen Berechnung. Laguna verwendet eine per-head softplus output gating – eine pro Kopf angewandte Softplus-Ausgangssteuerung. Jeder Aufmerksamkeitskopf bekommt seine eigene Lautstärkeregelung. Das Modell kann den Beitrag einzelner Köpfe reduzieren, beibehalten oder verstärken, bevor ihre Ergebnisse kombiniert werden. Die Softplus-Funktion hält diese Tore positiv, erlaubt Werte über eins, sodass nützliche Köpfe verstärkt werden können. Laguna setzt auf verschränktes Denken: Das Modell führt einen Gedankenschritt aus, tätigt einen Werkzeugaufruf, empfängt das Ergebnis und setzt seine Denkspur fort, bevor es die nächste Aktion wählt.
Für spekulative Dekodierung stellt Poolside ein DFlash-Draft-Modell bereit, das Kandidatentoken generiert, die das Hauptmodell parallel verifizieren kann – das beschleunigt die Ausgabe potenziell. Die Unterstützung für Laguna ist in vLLM ab Version 0.25.0 dokumentiert. Das Modell läuft auf einer einzelnen B300-GPU, die NVFP4- und INT4-Varianten verbrauchen weniger als 80 GB. Für die volle Kontextlänge bräuchte man eine 96-GB-GPU wie die RTX Pro 6000. Der KV-Cache für 256.000 Tokens wird auf etwa 24 GB geschätzt. Auch hier empfehlen die Entwickler, die vorherigen reasoning_content im Gesprächsverlauf zu behalten – das gleiche Problem wie bei Nanbeige, nur dass Laguna aufgrund seiner geringeren KV-Cache-Größe pro Token etwas nachsichtiger ist.
Laguna ist deutlich spezialisierter als Nanbeige. Sein primäres Ziel ist langfristiges Software-Engineering: Beheben von Bugs auf Repository-Ebene, Terminal-Interaktion, Shell-basierte Workflows, mehrsprachige Code-Pflege, Erkundung von Codebasen und Beantwortung von Fragen, die das Verständnis großer Software-Repositorien erfordern. Die spärliche Architektur und das auf Code fokussierte Training machen Laguna effektiv für Terminal-Interaktion, Repository-Level-Denken und mehrsprachiges Software-Engineering. Das Modell sieht auf dem Papier hervorragend aus. Das Feedback aus der Community ist bisher gemischt – was bei der Komplexität solcher Modelle nicht überrascht.
Zwei Lager, ein Ziel: Was bedeutet das in der Praxis?
Beide Modelle zielen auf denselben Einsatzbereich – agentische KI für Code und Workflows –, aber sie gehen unterschiedliche Wege. Nanbeige setzt auf Wiederholung: kleine, schlanke Gewichte, zweimal denken. Das spart Speicher, fordert Rechenzeit und erzeugt einen überraschend großen KV-Cache. Laguna setzt auf Auswahl: ein Heer von Experten, aber nur die relevanten abrufen. Das spart Rechenzeit, braucht enormen Gewichtsspeicher und eine leistungsfähige GPU, um die vielen Parameter zu laden.
Für dich als Anwender stellt sich die Frage: Hast du Hardware mit 96 GB VRAM und brauchst ein Modell, das über ganze Code-Repositorien hinweg denken kann? Dann ist Laguna die richtige Wahl. Arbeitest du auf einem Workstation-Rechner mit 24 GB und möchtest einen soliden Coding-Assistenten, der in den meisten Benchmarks größere Modelle schlägt? Dann ist Nanbeige spannend – aber du musst die Einschränkungen beim KV-Cache und die doppelte Durchlaufzeit akzeptieren. Der Autor kündigt an, beide Modelle in den nächsten Wochen selbst für agentisches Coding zu testen.
Agentic KI ist kein Einheitsbrei mehr. Du hast heute die Wahl zwischen einem flinken Schwergewicht und einem monumentalen Spezialisten. Die Kunst wird sein, das richtige Werkzeug für deine konkrete Aufgabe auszuwählen – und die Hardwarekosten im Auge zu behalten. Was nützt das mächtigste Modell, wenn die GPU für den nächsten Denkschritt keine Tokens mehr verarbeiten kann?
Quelle: kaitchup.substack.com
