DeepSeek Engram: Konditionaler Speicher als neue Sparse-Achse für LLMs
DeepSeek hat im Januar Engram veröffentlicht, einen Lookup-Baustein, der Fakten mit konstanter Zugriffszeit aus Hash-Tabellen liefert, statt sie im Netz zu rekonstruieren: plus 3 bis 5 Punkte im Wissensbereich, 97 Prozent beim Nadel-im-Stapel-Test und eine 100-Mrd-Embedding-Tabelle im Host-DRAM bei unter 3 Prozent Durchsatzverlust.

Kein fertiges Produkt und keine Hochglanz-Rückschau: Dieser Eintrag hält fest, was gebaut, getestet, verworfen und als Nächstes überprüft wird.
Am 12. Januar 2026 hat DeepSeek ein Architekturpapier veröffentlicht, das die Rollen im Inneren eines Sprachmodells neu mischt: Conditional Memory via Scalable Lookup, herausgegeben unter dem Projektnamen Engram, mit vierzehn Autoren, darunter der Gründer des Unternehmens, Liang Wenfeng, und Forschende der Peking University. Der Kern ist ein Baustein, der statisches Wissen per direktem Nachschlagen mit konstanter Zugriffszeit aus Hash-Tabellen liefert, statt es wie ein klassischer Transformer Schicht für Schicht aus den Gewichten selbst herauszurechnen. Papier und Code sind vollständig offen gelegt, das Repo liegt unter deepseek-ai/Engram auf GitHub. Ausgelöst hat den heutigen Newsdesk-Lauf ein Video von Two Minute Papers mit dem Titel DeepSeek Solved AI's Memory Problem, auf Deutsch etwa: DeepSeek hat das Speicherproblem gelöst. Die Belege dieses Beitrags stammen aus dem Repo und aus einem technischen Deepdive, der die Benchmark-Tabellen des Papiers abdruckt. Vorab ein Hinweis zur Datierung, den ich unten nicht verstecke: Das Papier ist von Januar, der Auslöser von heute, und der Newsdesk sichtet nach Sichtungsdatum, nicht nach Erscheinungsdatum. Neu an diesem Morgen ist also nicht der Mechanismus, neu ist die Erinnerung daran, und die lohnt sich, weil die Zahlentabelle des Papiers stärker ausfällt, als der bescheidene Titel vermuten lässt.
Warum Fakten den Rechenpfad zumachen
Der Ausgangspunkt ist eine Ineffizienz, die seit dem ersten Transformer mitläuft: Ein Sprachmodell kann Fakten nicht nachschlagen. Fragt man es nach der Hauptstadt von Frankreich, läuft die Frage nicht in eine Datenbank, sondern durch mehrere Aufmerksamkeits- und Feed-Forward-Schichten, die die Antwort aus Mustern der Trainingsdaten rekonstruieren. Das Papier beschreibt das als Simulation von Retrieval: Was ein simpler Lookup wäre, wird zu Rechenleistung gemacht, und die ist im Modellbetrieb der teuerste Posten. Daran schließt die Hardware-Diagnose an, die der Deepdive aus dem Papier zieht: High Bandwidth Memory auf GPUs ist knapp und teuer, und die Branchenberichte zeichnen seit Monaten dasselbe Bild, jede zusätzliche HBM-Kapazität wird sofort von größeren Modellen verputzt, so dass Speichern kontinuierlich der nächste Flaschenhals bleibt. Der Betriebsteil der Diagnose kommt ebenfalls aus dem Deepdive: Großbatch-Inferenz bleibt memory-bound, und die Sättigung der DRAM-Bandbreite, nicht die Rechenleistung der GPU-Kerne, ist die Decke, unter der viele Deployments arbeiten. Wer Agenten fährt, kennt den Effekt in anderer Kleidung: Faktenwissen im Modell bindet Bandbreite bei jedem Durchlauf, unabhängig davon, wie oft es eigentlich gebraucht wird.
Lookup als zweite Sparse-Achse
Engram modernisiert für diesen Zweck ein altes Verfahren: N-Gramm-Embeddings, die in den Anfangsjahren der Sprachmodellierung Standard waren und danach als überholt abgelegt wurden. Der Baustein hält Wissensmuster in Tabellen, auf die über Hash-Funktionen in konstanter Zeit zugegriffen wird, unabhängig von Modelltiefe und Kontextlänge. An der heutigen Ausgestaltung hängen drei Details. Erstens komprimiert der Tokenizer äquivalente Zeichenformen auf kanonische Identifier: Groß- und Kleinschreibung, Akzente und Whitespace-Varianten laufen über einen Normalisierungspfad in dasselbe Ziel, das Vokabular schrumpft laut Papier um 23 Prozent. Zweitens greift pro N-Gramm-Ordnung nicht eine, sondern ein Satz von Hash-Köpfen an, im Testaufbau acht; eine Kollision in einem Kopf wird durch die Aggregation über die übrigen abgefedert. Drittens entscheidet ein Gate über die Übergabe: Der jeweils aktive verborgene Zustand wirkt als Abfrage, passt der Nachschlag zum Kontext, wird er durchgelassen, widerspricht er, wird er gedämpft, so dass veraltete oder kollidierte Einträge nicht laut in die Ausgabe rutschen. Wer Mixture-of-Experts kennt, erkennt die Bau-Position sofort: MoE entscheidet, welcher Experte rechnet, Engram entscheidet, welches Wissen nachgeschlagen wird; zwei konditionale Mechanismen auf zwei Achsen von Sparsity, die sich ergänzen statt ersetzen.
Die Testaufstellung und die Zahlen
Geprüft wurde der Baustein an einem 27-Milliarden-Parameter-Vergleichsaufbau, bei dem die Engram-Variante und die MoE-Baseline unter strikt gleichen Parameter- und FLOPs-Budgets laufen, damit der Vergleich die Architektur misst und nicht die Größe. Die Sprünge im Wissensbereich liegen durchgehend bei drei bis fünf Punkten: MMLU steigt von 57,4 auf 60,4, MMLU-Redux von 60,6 auf 64,0, CMMLU um vier Punkte auf 61,9, Big Bench Hard von 50,9 auf 55,9, ARC-Challenge von 70,1 auf 73,8, AGIEval von 38,6 auf 41,8. Im Code-Bereich bewegen sich die Zugewinne in derselben Größenordnung: HumanEval von 37,8 auf 40,8, MBPP von 46,6 auf 48,2. In der Mathematik: GSM8K von 58,4 auf 60,6, MATH von 28,3 auf 30,7. Der mit Abstand größte Effekt sitzt im langen Kontext: Beim Multi-Query-Needle-in-a-Haystack-Test, der prüft, ob ein Modell eine einzelne Nadel in einem langen Dokumentenstapel findet, springt die Genauigkeit von 84,2 auf 97,0 Prozent. Die ergänzenden Lesetests ziehen an: DROP von 55,7 auf 59,0 F1, RACE-Middle von 80,9 auf 82,8, RACE-High von 75,4 auf 78,2. Ein Wort zur Bauweise, weil sie diese Zahlen einordnet: Für den Testaufbau wurden die gerouteten Experten von 72 auf 55 reduziert und die freigewordenen Parameter in ein 5,7 Milliarden Parameter großes Embedding-Modul verschoben; die Engram-Module sitzen bei Schicht 2 und 15, die maximale N-Gramm-Ordnung ist 3, mit acht Hash-Köpfen und 1280 Dimensionen. Das ist keine Spezialkonfiguration für einen Schönheitsvergleich, sondern die Ausgestaltung, die als Referenz im offenen Code liegt.
Der DRAM-Hebel: Rechnen und Speichern entkoppelt
Der Ergebnisteil mit der größten Reichweite jenseits der Modellarchitektur behandelt die Platzierung: Die Forschenden haben eine Embedding-Tabelle mit hundert Milliarden Parametern vollständig aus dem GPU-Arbeitsspeicher in den Host-DRAM verlagert und demonstriert, dass der Durchsatzverlust unter drei Prozent bleibt. Möglich ist das, weil die Adressen des Nachschlags im Voraus feststehen: Das System lädt die benötigten Embeddings asynchron über PCIe vor, während der Rest des Modells weiterrechnet. Tom's Hardware bringt dieselbe Pointe in der Überschrift als Entkopplung von Rechenleistung und RAM-Pools, die die HBM-Grenzen umgeht. Die Ökonomie dahinter verschiebt die Kostenkurve: GPUs mit HBM sind die teuerste Komponente pro Gigabyte in jedem KI-Knoten, System-RAM die billigste. Wenn sich das statische Wissen eines Modells in das billige Medium verlagern lässt, während die teure Hardware nur noch das Denken führt, wandert die Kostenschraube weg von dem Bauteil, das die Branche knapp hält. Die Grenze des Hebels liegt in der Zugriffscharakteristik: Der Vorab-Lader braucht planbare Zugriffe, Embedding-Tabellen haben genau solche, weil ihre Indizes vor dem Durchlauf feststehen; für beliebige Modellgewichte gilt das nicht. Der Hebel ist deshalb kein Argument gegen HBM, sondern eines für die Aufgabenteilung zwischen beiden Speicherarten.
Die Mischungsquote: mehr Speicher macht es nicht besser
Der aufschlussreichste Befund neben den Benchmark-Tabellen ist eine Mischungsquote. Die Versuchsreihe variiert, wie viel des sparsamen Parameter-Budgets dem Lookup und wie viel dem Rechnungsteil zugewiesen wird, und zeichnet eine U-Kurve: Rein mit MoE läuft es schlechter als die beste Mischung, rein mit Lookup bricht die Rechenqualität ein, und die Optimalzone sitzt laut Papier bei 20 bis 25 Prozent des Budgets im Engram-Anteil, 75 bis 80 Prozent im Rechnungsnetz. Die Erklärung passt in zwei Sätzen: Zu viel Rechenleistung verschwendet Modelltiefe darauf, statische Muster zu rekonstruieren, die ein Lookup in einem Schritt liefert; zu viel Lookup kostet das Netz die Kapazität, die es für komplexes Denken braucht. Heraus kommt eine Entwurfsregel ohne Bauchgefühl: Speicher und Rechnung sind im Modell kein Entweder-oder, sondern ein gemeinsames Budget mit einem Optimalpunkt, den man ausmisst, statt zu raten.
Warum auch das Denken mitzieht
Der eigentümlichste Teil der Zahlen ist, dass auch die Denkaufgaben zulegen, und zwar stärker, als die Wissenspunkte allein erklären. Die mechanistische Auswertung im Papier führt das auf verlagerte Arbeit zurück: Werden die frühen Schichten vom Rekonstruieren von Faktenmustern befreit, bleibt ihnen Tiefe für komplexe Denkaufgaben übrig; am stärksten wirkt der Effekt laut Papier mit dem Modul ab Schicht 2 und klingt nach hinten ab. Parallel werden Aufmerksamkeitskapazitäten frei, die vorher lokale Abhängigkeiten stemmten und jetzt globale Kontexte lesen. Die Ablationsexperimente machen die Arbeitsteilung unmissverständlich: Wird das Engram-Modul deaktiviert, brechen die Wissensbenchmarks auf 29 bis 44 Prozent ihrer Ausgangswerte ein, TriviaQA fällt auf 29 Prozent, während der Rest des Modells weiterrechnet, als wäre nichts passiert. Das ist der Beleg, dass der Nachschlag keine Garnitur ist, sondern die Funktion tatsächlich übernommen hat, und es spitzt den Handel von der anderen Seite zu: Wer Fakten nicht nachschlagen will, zahlt für sie mit Modelltiefe.
Einordnung aus dem Agenten-Deck
Aus dem Agentenbetrieb gelesen hat der Mechanismus zwei Berührungspunkte. Der erste ist die Ökonomie: Mein Ollama-Vertrag läuft auf Anfragebasis mit Wochenfenster, die Währung meines Betriebs sind Requests, und jede Effizienzforschung, die den Speicherdruck senkt, arbeitet an genau der Stelle, von der die Preise abhängen. Eine Demonstration mit einem 27-Millardengruppen-Testaufbau, hundert Milliarden nachschlagbaren Parametern und einem Durchsatzverlust unter drei Prozent ist auf Dauer eine Verlagerung von der teuersten auf die billigste Komponente, und das gerinnt irgendwann bis in die Budgets kleiner Betriebe. Der zweite Berührungspunkt ist der lange Kontext: Ein Agent, der Sitzungsverläufe und Quelldokumente in den Kontext schiebt, lebt von der Fähigkeit, die Nadel im Stapel zu finden, und genau dort zeigt das Papier seinen größten Sprung, von 84,2 auf 97 Prozent. Was lokal fehlt: Auf dem Deck läuft kein Engram-Build, und ob Serving-Stacks wie Ollama oder llama.cpp eine Lookup-Ebene eines Tages bedienen, ist in meiner Lektüre offen geblieben. Beobachten will ich zweierlei: ob die nächste DeepSeek-Generation den Baustein tatsächlich trägt und ob die offenen Inferenz-Stacks die Idee nachbauen, denn das Muster ist unabhängig vom konkreten Autor kopierbar, jeder Anbieter mit HBM-Lücken hat denselben Antrieb.
Zwillingspapier, Fazitzitat und die V4-Frage
Neben dem Engram-Papier hat DeepSeek am 13. Januar ein Zwillingspapier zu Manifold-Constrained Hyper-Connections nachgeschoben, das die Trainingsstabilität zum Thema hat; Beobachter lesen die beiden Papiere zusammen, weil sie zwei getrennte Probleme angreifen, Speicherbedarf und Stabilität. Das Fazit der Autoren ist deutlicher als der Projektname: Konditionale Speicherfunktionen gelten den Autoren ausdrücklich als unverzichtbares Grundelement für die nächste Generation sparsamer Modelle. Zur V4-Frage gibt es Berichte, aber keine Bestätigung: The Information schrieb zur Paperzeit von einem nächsten Flaggschiffmodell mit starkem Coding-Anteil, das Mitte Februar erwartet wurde, und die South China Morning Post las die Januar-Ankündigung als Startsignal für den Versuch, größere Modelle für weniger Aufwand zu trainieren. Ob Engram in V4 sitzt, ist Spekulation; sie ist aber von der Sorte mit Vorgeschichte, weil die Papiere bei DeepSeek typischerweise den Weg vorarbeiten, den die Modelle anschließend fahren.
Die Grenzen dieser Lektüre, ehrlich
Erstens: Geprüft habe ich nichts selbst. Der Testaufbau braucht Trainings- und Evaluationsrechenleistung einer Größenordnung, die weit über einem Schreibtischbetrieb liegt; den offenen Code habe ich zur Lektüre genutzt, aber nicht laufen lassen, und unabhängige Benchmark-Wiederholungen im Inferenzbetrieb sind mir in diesem Durchgang nicht begegnet. Solange die fehlen, gilt der Zahlenkorpus als Selbstbericht der Autoren. Zweitens die Datierung: Das Papier ist vom Januar, der Anlass von heute; wer diesen Beitrag später liest, sollte über die Suchmaschine seiner Wahl prüfen, ob inzwischen eine Produkt- oder Serving-Seite den Mechanismus konkreter beschreibt, denn die hätte dann Vorrang vor einem Januarpapier. Drittens die Tabellen: Ich habe sie aus dem technischen Deepdive übernommen, der die Kopfwerte des Papiers abdruckt, das Original nicht Seite für Seite nachgelesen; deshalb liest sich hier jedes Prozent als Papier-Ergebnis und nicht als eigener Test. Was fehlt: die Integrationsschicht. Wie eine Lookup-Ebene in Serving-Stacks wie Ollama, llama.cpp oder vLLM ankommt, welche Swap-Strategien Provider wählen und ob die unter-drei-Prozent-Grenze im Produktbetrieb gehalten wird, ist offen; das ist der Abstand zwischen Papier und Betrieb.
- 12.01.2026
DeepSeek veröffentlicht das Engram-Papier Conditional Memory via Scalable Lookup und legt Papier und Code im Repo deepseek-ai/Engram offen.
- 13.01.2026
Zwillingspapier zu Manifold-Constrained Hyper-Connections, Fokus Trainingsstabilität; Beobachter lesen beide Papiere gemeinsam.
- ca. Mitte Februar 2026
Ein nächstes DeepSeek-Flaggschiffmodell (V4) wird laut The-Information-Bericht erwartet; ob Engram darin sitzt, ist offen.
- 11.10.2026
Two Minute Papers rollt das Thema erneut an die Oberfläche; dieser Newsdesk-Lauf ordnet es ein und verlagert jede Zahl zum Papier.
Verwandte Beiträge
Verwandt: Qwen 3.8 mit bis zu 1.500 Tokens pro Sekunde via Cerebras ↗
Häufige Fragen
Was ist Engram und wie unterscheidet es sich von einem klassischen Transformer?
Engram ist ein konditionaler Speicherbaustein: Statisches Wissen liegt in Hash-Tabellen und wird in konstanter Zeit nachgeschlagen, das neurale Netz rekonstruiert es nicht mehr Schicht für Schicht. Dazu kommen Tokenizer-Kompression (23 Prozent kleineres Vokabular), mehrere Hash-Köpfe gegen Kollisionen und ein Kontext-Gate, das widersprechende Nachschläge dämpft.
Warum gilt der Speicher als Flaschenhals der LLM-Infrastruktur?
Fakten durchlaufen im klassischen Aufbau teure Aufmerksamkeits- und Feed-Forward-Schichten, statt per Lookup beantwortet zu werden. High Bandwidth Memory auf GPUs ist knapp und teuer, Großbatch-Inferenz bleibt memory-bound, und jede zusätzliche HBM-Kapazität wurde bisher sofort von größeren Modellen verbraucht.
Was besagt die DRAM-Zahl mit der 100-Mrd-Embedding-Tabelle?
Das Forschungsteam hat eine Embedding-Tabelle mit hundert Milliarden Parametern vollständig in den Host-DRAM verlagert, die Embeddings werden asynchron über PCIe vorgeladen, und der Durchsatzverlust blieb unter drei Prozent. Statisches Wissen skaliert damit am billigen System-RAM, während die GPUs für die Rechenpfade frei bleiben.
Wie belastbar sind die Benchmark-Sprünge wie 97 Prozent beim Nadel-im-Stapel-Test?
Die Werte stammen aus einem Vergleich unter gleichen Parameter- und FLOPs-Budgets: MMLU plus 3,0, Big Bench Hard plus 5,0, Needle-in-a-Haystack von 84,2 auf 97,0 Prozent. Papier und Code sind offen gelegt, unabhängige Wiederholungen im Inferenzbetrieb fehlen nach meiner Sichtung bislang, solange gilt der Korpus als Selbstbericht der Autoren.
Ist Engram im erwarteten DeepSeek V4?
Das ist nicht bestätigt. The Information berichtete zur Paperzeit von einem nächsten Flaggschiffmodell mit starkem Coding, das Mitte Februar erwartet wurde, und das Autoren-Fazit nennt konditionale Speicherfunktionen ein Grundelement für sparsame nächste Modelle. Beides deutet in die Richtung, bleibt aber Spekulation, bis die Release-Dokumentation es zeigt.
Über den Autor
Über den Autor: Ich bin Marcel, Grafikdesigner, und betreibe das HUNTER-Cyberdeck auf einem gebrauchten Google Pixel 6a. Ich orchestriere meine Agentenfamilie mit Hermes, pi und herdr und schreibe diese Beiträge aus dem laufenden Betrieb. Zuletzt fachlich geprüft am 11.10.2026.
Quellen
Quellen: DeepSeek und Peking University, Conditional Memory via Scalable Lookup: A New Axis of Sparsity for Large Language Models (Engram), offenes Repo mit Papier und Code unter github.com/deepseek-ai/Engram, abgerufen am 11.10.2026. Introl, technischer Deepdive zur Engram-Architektur mit Benchmark-Tabellen (MMLU, BBH, Needle-in-a-Haystack, DRAM-Offload), abgerufen am 11.10.2026. Tom's Hardware: Meldung zur Entkopplung von Rechenleistung und RAM-Pools, abgerufen am 11.10.2026. The Information und South China Morning Post, Berichte zur V4-Erwartung, zitiert nach der Quellenliste des Deepdives, abgerufen am 11.10.2026. YouTube: Two Minute Papers, DeepSeek Solved AI's Memory Problem (auf Deutsch etwa: DeepSeek hat das Speicherproblem gelöst), Auslöser-Video, gesichtet am 11.10.2026.
Two Minute Papers: DeepSeek Solved AI's Memory Problem (Auslöser-Video) ↗
Nachgebaut oder getestet?
Teile deine Erfahrung mit genau diesem Build-Log. Reviews werden vor der Veröffentlichung moderiert.
Noch keine Reviews für diesen Eintrag.
Fragen, Reaktionen und Verbesserungen werden direkt über GitHub Discussions eingebettet.
GitHub-Bereich öffnen ↗