NVIDIA DORY 4B: EIN MODELL, VIER RECHENBUDGETS DURCH LOOPED-ARCHITEKTUR

Das Wichtigste

Ein einziger Checkpoint lässt sich bei NVIDIA Dory 4B mit ein bis vier Rechendurchläufen pro Token betreiben, ganz ohne Retraining. Mehr Loops heißt mehr Rechenleistung pro Token, aber keine zusätzlichen Parameter.

Was ist passiert?

MarkTechPost zeigt in einem Schritt-für-Schritt-Guide, wie sich Dory 1.0 4B von NVIDIAs Nemotron Labs lokal mit llama.cpp betreiben lässt. Das Besondere an Dory: Die mittleren Layer bilden einen gemeinsamen Block, der pro Token ein-, zwei-, drei- oder viermal durchlaufen werden kann.

Jeder zusätzliche Loop kostet mehr Rechenzeit, aber keinen einzigen zusätzlichen Parameter. Damit lässt sich ein und dasselbe 3,7 GB große Modell je nach Anwendungsfall zwischen vier verschiedenen Kosten-Leistungs-Profilen umschalten.

Da die Unterstützung für Dory in llama.cpp noch als offener Draft-Pull-Request existiert (PR #30306), muss der Guide einen gepinnten Fork von NVIDIA selbst bauen. Es gibt aktuell keine offizielle Binary, die das Modell laden kann.

Technische Details

Die Architektur besteht laut Modellkarte aus drei Layer-Gruppen: Input-Layer, ein wiederverwendbarer Recurrent-Block und Output-Layer. Dieser Recurrent-Block wird je nach gewähltem Loop-Count mehrfach durch dieselben Gewichte geschickt, ähnlich einem Schleifen-Mechanismus in klassischer Software.

Der Guide baut den Server aus dem exakten, von NVIDIA gepinnten Commit, prüft die Checksumme der Q5_K_M GGUF-Datei (3,67 GB) gegen den publizierten SHA-256-Wert und liest die Architektur direkt aus der Datei aus, um Parameterzahl und Cache-Speicher pro Loop-Stufe vorherzusagen.

Anschließend wird die Decodier-Geschwindigkeit bei jeder Loop-Zahl gemessen und geprüft, ob ein günstigerer Cache im letzten Loop die Vorhersagen verändert. Eine gepaarte GSM8K-Auswertung zeigt, wie sich Genauigkeit, Antwortlänge und Zeit pro gelöster Aufgabe mit steigender Loop-Zahl verschieben.

Warum ist das relevant?

Für Entwickler ist das ein konkretes Beispiel für Test-Time Compute Scaling ohne separate Modellversionen. Statt vier unterschiedlich große Checkpoints vorzuhalten, reicht ein Modell, dessen Rechenaufwand sich zur Laufzeit per Parameter steuern lässt.

Das senkt den Aufwand für Infrastruktur-Teams, die zwischen schnellen, günstigen Antworten und tiefer reasoning-lastiger Inferenz abwägen müssen. Gerade für On-Premise- oder Edge-Deployments im DACH-Raum, wo Hardwarebudgets oft knapp sind, ist ein flexibel skalierbares 4B-Modell interessant.

Der Haken: Die llama.cpp-Unterstützung ist noch nicht gemerged. Wer produktiv gehen will, braucht vorerst den gepinnten Fork und sollte Versionsstände sorgfältig dokumentieren, wie es der Guide selbst vormacht.

Take-Away

Teams, die mit kleinen Reasoning-Modellen experimentieren, sollten sich den Dory-Ansatz genau ansehen. Die Guide-Methodik mit SHA-256-Verifikation, gepinnten Commits und GSM8K-Benchmarks liefert zudem eine saubere Vorlage für eigene Evaluierungen von quantisierten GGUF-Modellen.