Looped-Modelle erklärt: Sie sparen Speicher, aber keine Rechenzeit

Darum geht es

Innerhalb weniger Wochen sind zwei Sprachmodelle mit offenen Gewichten erschienen, die einen ungewöhnlichen Trick nutzen: NVIDIA Dory1.0-4B (Gewichte seit Mitte Oktober, Paper vom 3./4. November) und SenseNova-Loop-9B-Preview von SenseTime (30. Oktober). Beide schicken jedes Token mehrfach durch denselben Block von Schichten. Man nennt sie Looped oder Recurrent-Depth-Modelle, also Modelle mit „Schleifen in der Tiefe“.

Unsere These: Looping spart Speicher für Gewichte, aber keine Rechenzeit. Jede Schleife kostet so viel Rechenarbeit wie die Schichten, die sie wiederholt. Deshalb braucht der Ansatz neue Tricks, damit er sich in der Praxis lohnt. Dory ist dafür das bisher beste Anschauungsobjekt, weil NVIDIA die Kosten selbst beziffert. Neben Parametern und Trainingsdaten wird so die Zahl der Durchläufe zur dritten Stellschraube beim Skalieren.

Die Grundidee: ein Werkzeug, mehrmals angesetzt

Ein normaler Transformer schickt jedes Token einmal durch einen Stapel von Schichten. Wer mehr Tiefe will, braucht mehr Schichten und damit mehr Parameter. Ein Looped-Modell teilt den Stapel in drei Teile: einen Eingangsblock, einen wiederholten Kernblock und einen Ausgangsblock. Der Kern verarbeitet bei jedem Durchlauf das Zwischenergebnis des vorigen Durchlaufs weiter. Das ist wie ein Werkzeug, das man mehrmals an ein halb fertiges Werkstück ansetzt.

Die Idee ist alt. Die Universal Transformers (Dehghani et al., 2018) verbanden die Parallelität des Transformers mit dem rekurrenten Prinzip älterer Netze. Dazu kam ein Mechanismus, der pro Position entschied, wann Schluss ist. 2025 trainierten Geiping et al. das Modell Huginn-3.5B auf 800 Mrd. Tokens. Laut Paper verbessert es sich bei Mathe- und Coding-Aufgaben durch mehr Durchläufe bis zu einem Rechenaufwand, der 50 Mrd. Parametern entspricht. ByteDance folgte mit Ouro (1,4 und 2,6 Mrd. Parameter, 7,7 Billionen Tokens). Die Autoren führen den Gewinn ausdrücklich auf besseres Verarbeiten von Wissen zurück, nicht auf mehr gespeichertes Wissen. Diesen Punkt sollte man sich merken.

Eine Fußnote zu den Zahlen: Sebastian Raschka zählt Dory als 8/20/8 Blöcke, das Paper als 16/40/16 Schichten. Beides stimmt. Dory hat 36 reine MLP-Schichten und 36 Attention-Schichten, ein Block besteht also aus zwei Schichten.

Der Haken: Speicher gespart, Rechenzeit nicht

Bei Dory steigt die Zahl der Schicht-Durchläufe pro Token von 72 (eine Schleife) auf 112 (zwei) und 192 (vier). Pro Token ist das also 1,56- bzw. 2,67-mal so viel Arbeit. Das zeigt sich auch in der Praxis. Der Hugging-Face-Nutzer cloudnathan5 hat eigene GGUF-Dateien erstellt (GGUF ist das Dateiformat für llama.cpp). Er misst auf einer RTX PRO 6000 mit Q5_K_M 193,5 Tokens/s bei einer Schleife und 80,9 Tokens/s bei vier, also etwa 2,4-mal langsamer.

Dazu kommt der KV-Cache, ein Zwischenspeicher, in dem das Modell für jedes bisherige Token Rechenergebnisse der Attention aufbewahrt. Standardmäßig bekommt jede Schleife einen eigenen. Laut cloudnathan5 braucht Dory in Q4_K_M mit vier Schleifen 3,6 GiB bei 4.000 Tokens Kontext, 6,2 GiB bei 32.000 und 27,4 GiB bei 256.000 Tokens. Das 4-Milliarden-Modell braucht bei vollem Kontext also mehr Speicher als die Gewichte vieler 30B-Modelle.

Bei SenseNova ist es ähnlich. 56 statt 32 Schicht-Durchläufe bedeuten 1,75-mal so viel Rechenarbeit pro Token. Laut einer Code-Analyse auf note.com bekommt auch hier jeder Durchlauf einen eigenen Cache. Etwas gedämpft wird das, weil drei von vier Schichten lineare Attention nutzen. Diese Variante kommt mit einem Speicher fester Größe aus statt mit einem Eintrag pro Token. Konkrete Speicherzahlen nennt SenseTime nicht.

Trick 1: Wer gründlicher denkt, redet weniger

NVIDIAs wichtigstes Argument steht im Paper: Mit vier Schleifen erzeugt Dory bei Agenten-Aufgaben 1,3- bis 2,5-mal weniger Tokens als mit einer. Bei GDPval-AA v2 sinkt die Zahl der Runden pro Versuch von 116 auf 49 und die Ausgabe von 212.000 auf 85.000 Tokens. Bei Terminal-Bench v2.1 fällt sie von 109.000 auf 54.000 Tokens.

Wir haben nachgerechnet: Gesamtaufwand = Tokens × Schicht-Durchläufe. Bei GDPval ergibt das 85/212 × 192/72 ≈ 1,07-facher Aufwand für vier Schleifen, bei Terminal-Bench 54/109 × 192/72 ≈ 1,32-fach. Laut Paper reicht die Spanne bei vier Schleifen von 1,07 bis 2,04, bei zwei Schleifen von 1,03 bis 1,25.

Unsere Einschätzung: Das funktioniert vor allem bei langen Agenten-Aufgaben, bei denen ein klügeres Modell Umwege spart. Bei einer kurzen Chatfrage gibt es kaum Tokens zu sparen, dort zahlt man die 2,4-fache Rechenzeit fast voll. Der Entwickler Laurence Moroney hält den Ausgleich für plausibel, aber unbewiesen. Gemessene Latenzen auf Laptops bei zwei bis vier Schleifen hat er nirgends gesehen.

Trick 2: Last-Loop-KV-Caching

Beim Last-Loop-Caching gibt es pro Schicht nur einen Cache, und jede Schleife überschreibt den der vorigen. Der Speicher bleibt so groß wie bei einer einzigen Schleife. Der Haken: Frühe Schleifen schauen bei älteren Tokens auf Werte aus der letzten Schleife statt auf ihre eigenen, so wurden sie nicht trainiert. Laut NVIDIA verschieben sich die Ergebnisse um −2,12 bis +0,42 Punkte. Am stärksten verlieren AA-LCR (−2,12) und Terminal-Bench (−1,97). In cloudnathan5s Messung sinkt der Speicher bei 32.000 Tokens von 6,2 GiB (vier Schleifen, getrennte Caches) auf 4,1 GiB. Im llama.cpp-PR steht eine weitere Auffälligkeit: Im Last-Loop-Modus hängen die Vorhersagen davon ab, in welchen Häppchen der Prompt verarbeitet wird.

Trick 3: Das Modell als sein eigener Entwurfshelfer

Normales spekulatives Dekodieren nutzt ein kleines Hilfsmodell, das schnell mehrere Tokens rät. Das große Modell prüft sie dann in einem Rutsch. Dory braucht dafür kein zweites Modell. Dieselbe Datei mit einer Schleife entwirft vier Tokens, die Vier-Schleifen-Variante prüft sie. Beide teilen sich den Cache des Eingangsblocks und der ersten Schleife, und Zwischenergebnisse des Entwurfs werden wiederverwendet. Laut Paper bleibt die Ausgabe-Verteilung der Vier-Schleifen-Variante mathematisch erhalten. Der Durchsatz beim Dekodieren steigt um das 1,37- bis 1,71-Fache, bei größeren Batches wird der Vorteil kleiner. Pro Anfrage sinkt die Dauer um das 1,11-Fache (τ³-Banking) bis 1,53-Fache (AA-Omniscience). Wie viele Entwürfe angenommen werden, verrät das Paper nicht. Ob llama.cpp oder vLLM die Selbst-Spekulation schon beherrschen, geht aus den Pull Requests nicht hervor.

Elastische Tiefe: ein Checkpoint, vier Modelle

Im Training wurde die Zahl der Schleifen zufällig aus {1, 2, 3, 4} gewählt. Schwierige Aufgaben bekamen dabei häufiger mehr Schleifen. Deshalb funktioniert ein einziger Checkpoint mit jeder Schleifenzahl. NVIDIA nennt das „elastic inference compute“. Die Herstellerzahlen zeigen, wo das hilft und wo nicht:

Zwei Schleifen holen schon 80 Prozent des Gewinns bei SWE-Bench und 86 Prozent bei GDPval. Danach flacht die Kurve ab. Beim Faktenwissen (AA-Omniscience) bringen mehr Schleifen gar nichts, das passt zum Befund aus Ouro. Bei GPQA liegt Dory laut Moroney mit 72,41 hinter Qwen3.5-4B (77,71). Alle Zahlen stammen von NVIDIA, eine unabhängige Nachmessung haben wir nicht gefunden.

Wichtig für die Praxis: „Elastisch“ heißt bei Dory, dass du die Schleifenzahl beim Start festlegst. Pro Anfrage oder pro Token passt sie sich nicht von selbst an. SenseNova läuft fest mit zwei Durchläufen. Bei Ouro rechnet der veröffentlichte Code laut Raschka immer alle vier Durchläufe und wählt erst danach eine Ausgabe, die versprochene Ersparnis bleibt dort also Theorie. Echte variable Tiefe passt schlecht zu heutigen Serving-Systemen wie vLLM, weil Tokens dann an verschiedenen Stellen aussteigen. Das Paper „Continuous Depth Batching“ (Schwethelm et al.) setzt dafür die Batches zwischen den Schleifen neu zusammen. Bei Ouro und Huginn erreicht das bis zu 99 Prozent der geschätzt möglichen Beschleunigung.

Stolperfallen beim lokalen Betrieb

• llama.cpp: Dory-Unterstützung steckt im Draft-PR #30306, der noch nicht gemergt ist. Die normalen Builds und Ollama laden das Modell nicht. NVIDIAs eigene GGUF verlangt einen festgelegten Commit aus einem Fork. Metal ist laut PR ungetestet, Kontext-Verschiebung (--no-context-shift setzen) und mehr als vier Schleifen werden nicht unterstützt.
• Virtuelle Layer: llama.cpp zählt jeden Schleifendurchlauf als eigene Schicht, das sind 16 + 40 × Schleifen + 16, also 192 bei vier Schleifen. Wer wie gewohnt -ngl 40 setzt, lagert unbemerkt fast alles auf die CPU aus. Ein Tester im PR berichtet, dass damit nur der Ausgabekopf auf der GPU landete. Richtig ist -ngl 999.
• Schleifen per Override: Die Zahl stellst du mit --override-kv dory.num_loops=int:2 ein. Die cloudnathan5-Dateien laufen ohne Angabe mit vier Schleifen, NVIDIA empfiehlt zwei als Start.
• Widersprüchliche Anleitungen: Mehrere Blogs nennen den vLLM-PR #60149 „offen“, laut GitHub wurde er aber am 25. Oktober gemergt. In Transformers gibt es dagegen kein dory.
• SenseNova und trust_remote_code: Der Loader führt die Python-Datei modeling_sensenova_loop.py aus dem Repo aus. AiCybr rät, sie vorher zu lesen und eine bestimmte Revision festzupinnen. Vorgegeben ist Transformers 5.18.0. Der Download umfasst rund 38 GB, deutlich mehr, als 9 Mrd. Parameter in BF16 erwarten lassen. Die vLLM- und LightLLM-Beispiele nutzen vier GPUs, GGUF-Dateien gibt es offiziell nicht.

Was die Forschung noch offen lässt

Die neuen Paper zeigen, wo es noch hakt. Das Nanbeige4.2-Team fand, dass mehr als zwei Durchläufe das Training stark verteuern, ohne viel zu bringen. Das Paper „Allocating Recurrent Compute“ wiederholt nur den Attention-Teil statt des ganzen Blocks. Das spart 45,9 Prozent der Rechenoperationen im Kern, behält aber bei 110 Mio. Parametern nur 41,5 Prozent des Gewinns. „Readout Blind Spot“ zeigt an kleinen Modellen (44 und 129 Mio. Parameter), dass die internen Werte ohne Normalisierung zwischen den Schleifen auf Tausende anwachsen können. Unsere Einschätzung: Dory normalisiert den Zustand vor und nach jeder Schleife und geht damit genau in die Richtung, die das Paper empfiehlt. Belegt ist dieser Zusammenhang aber nicht. Ein Einzelautor hat Schleifen nachträglich in Qwen2.5-0.5B eingebaut, allerdings nur für eine eng umrissene Rechenaufgabe.

Einordnung

Looped-Modelle sind kein Gratis-Upgrade. Sie tauschen Speicher gegen Rechenzeit. Das ist für lokale Nutzer interessant, deren Grafikkarte zu wenig VRAM, aber genug Rechenleistung hat. Dory kommt in Q4_K_M mit 2,4 GB Gewichten aus, braucht mit vier Schleifen beim Dekodieren aber rund 2,4-mal so lange. Ob sich das lohnt, hängt an Trick 1: Spart das Modell bei deinen Aufgaben wirklich so viele Tokens wie bei NVIDIAs Agenten-Benchmarks?

Unsere Einschätzung: NVIDIA legt erstmals bei einem großen Hersteller ehrliche Kostenzahlen und brauchbare Gegenmittel vor. Bei SenseNova fehlen Paper, Speicherwerte und Rechenkosten noch ganz. Offen sind drei Dinge: unabhängige Benchmarks, Selbst-Spekulation in gängigen Programmen und eine Tiefe, die sich wirklich automatisch an jede Anfrage anpasst. Bis dahin ist „Rekurrenz“ eine vielversprechende dritte Stellschraube, aber noch eine für Tüftler.