DeepSeek Engram Offloading verlagert KI-Speicher über HBM hinaus

DeepSeek Engram Offloading hat 189 GiB Modellspeicher aus dem GPU-HBM ausgelagert, wobei DRAM-Tests eine reine HBM-Konfiguration teilweise übertrafen. Das Ergebnis stellt eine Grundannahme der Infrastruktur für große Modelle infrage. Der schnellste Speicher ist nicht automatisch der beste Ort für jeden Parameter.

SemiAnalysis veröffentlichte die neuen Experimente am 18. September mit DeepSeek-V4.1-Flash und dem Serving-Framework InferenceX. Die Tests platzierten Engram-Tabellen im Host-DRAM oder in speicherabgebildeten Dateien auf lokalen NVMe-Laufwerken. Der DRAM-Pfad verbesserte eine B300-Konfiguration durch geringeren Tensor-Parallelismus, während die erste SSD-Implementierung langsamer und weniger wirtschaftlich blieb.

Dieser Unterschied ist wichtig. Engram beseitigt weder die Nachfrage nach Nvidia-GPUs noch nach High-Bandwidth Memory. Es verändert jedoch, welche Modellparameter diese knappe Kapazität verdienen. Der kurzfristige Wettbewerb lautet daher nicht HBM gegen SSD. Es geht um ein reines HBM-Deployment-Modell gegenüber einem abgestuften System, das verschiedene Workloads HBM, DRAM und Speicher zuweist.

DeepSeek Engram Offloading verändert die Platzierung von Parametern

Die zentrale Veränderung ist architektonisch: Ein großer Block erlernten Speichers kann HBM verlassen, ohne dass sich das gesamte Modell wie ein ausgelagertes neuronales Netzwerk verhalten muss.

DeepSeek führte Engram als bedingtes Speichermodul für Sprachmodelle ein. Es erweitert gewöhnliche Token-Embeddings um erlernte Lookups für wiederkehrende Muster aus mehreren Tokens. Diese Muster können Namen, Codefragmente, Boilerplate und gängige relationale Formulierungen umfassen.

Ein gewöhnlicher Transformer rekonstruiert solche lokalen Muster häufig über Attention- und Feed-Forward-Schichten. Engram gibt dem Modell einen separaten Lookup-Pfad. Es hasht Tokensequenzen, ruft eine kleine Sammlung von Embedding-Zeilen ab und kombiniert sie mit dem Hidden State des Modells.

Das ursprüngliche Paper zu bedingtem Speicher beschreibt diesen Ansatz als zweite Form der Sparsität. Mixture-of-Experts, kurz MoE, aktiviert für jedes Token nur einen Teil der Modellberechnung. Engram aktiviert nur einen winzigen Teil einer deutlich größeren Speichertabelle.

Dieser Unterschied bestimmt, wie die Hardware das Modell bedienen kann. Ein MoE-Experte enthält Gewichtsmatrizen für umfangreiche Berechnungen. Seine Verschiebung zwischen Speicherebenen kann große Transfers genau zum ungünstigsten Zeitpunkt erfordern.

Engram-Adressen sind anders. Sie hängen von Token-IDs und ihrer lokalen Sequenz ab, nicht von einem Zwischenzustand im Hidden State. Eine Laufzeitumgebung kann wissen, welche Zeilen sie benötigt, bevor spätere Modellschichten ihre Berechnungen abgeschlossen haben.

Diese Vorhersagbarkeit schafft ein Prefetch-Fenster. Der Server kann Zeilen aus dem Host-Speicher abrufen, während die GPU frühere Operationen verarbeitet. Wenn der Abruf innerhalb dieses Fensters abgeschlossen wird, vermeidet das Modell einen großen Teil der gewöhnlich mit Offloading verbundenen Latenz.

DeepSeeks veröffentlichte Forschung skalierte eine experimentelle Engram-Tabelle auf 27 Milliarden Parameter. In kontrollierten Vergleichen berichteten die Autoren über Verbesserungen gegenüber einer MoE-Basislinie mit gleichwertigen Parametern und Berechnungen. Die gemeldeten Verbesserungen umfassten Faktenwissen, Schlussfolgern, Code, Mathematik und Long-Context-Retrieval.

Diese Werte stammen aus Forschungsmodellen, nicht aus dem von SemiAnalysis getesteten exakten Produktionssystem. Sie erklären dennoch, warum Engram nicht als optionale Metadaten behandelt werden kann. Es wird Teil des Reasoning-Pfads des trainierten Modells.

SemiAnalysis unterstrich diesen Punkt, indem Engram während der Inferenz entfernt wurde. Laut der Analyse behielten Fakten-Benchmarks in der Ablation des früheren Papers nur 29 bis 44 Prozent ihrer ursprünglichen Leistung. Beim Leseverständnis blieben 81 bis 93 Prozent erhalten.

Dieser Verlust beweist nicht, dass Engram jedes konventionelle Modell übertrifft. Das Netzwerk wurde darauf trainiert, von seinem Speichermodul abhängig zu sein. Das Entfernen dieses Moduls erzeugt eine Diskrepanz zwischen Training und Inferenz.

Das Experiment zeigt jedoch, dass Betreiber die Tabelle nicht einfach löschen können, wenn der Speicher knapp wird. Sie müssen sie effizient bedienen, komprimieren oder anderswo platzieren.

DeepSeek-V4.1-Flash macht das Platzierungsproblem konkret. DeepSeek zufolge besitzt das Modell ein MoE-Backbone mit 552 Milliarden Parametern, von denen bei der Eingabeverarbeitung 8 Milliarden und bei der Ausgabegenerierung 16 Milliarden aktiv sind. Engram fügt einen weiteren großen Pool bedingten Speichers hinzu.

Das V4.1-Flash-Release behauptet außerdem, dass ein KV-Cache nur ein Viertel des HBM und ein Achtel des SSD-Speichers seines Vorgängers benötigt. Der KV-Cache speichert wiederverwendbare Attention-Zustände früherer Tokens. Er ist von Engram getrennt, doch beide Funktionen verändern den Speicherbedarf von Servern.

SemiAnalysis verwendete etwa 189 GiB für die Engram-Tabelle des Modells. Dennoch forderte jede verarbeitete Token-Position an zwei Engram-Schichten nur 24 Zeilen an. Das entsprach etwa 12,4 KiB im gesamten Modell beziehungsweise 3,1 KiB pro GPU in einer Konfiguration mit vier GPUs.

Die Tabelle ist riesig, doch der aktive Lesezugriff ist winzig. Diese Asymmetrie ist überhaupt erst der Grund, warum DeepSeek Engram Offloading funktioniert.

DRAM-Offloading setzt das reine HBM-Design unter Druck

Engram schwächt die Verbindung zwischen der Gesamtzahl an Parametern und der erforderlichen HBM-Kapazität, selbst wenn GPU-Bandbreite weiterhin unverzichtbar bleibt.

HBM besitzt zwei wertvolle Eigenschaften für KI-Inferenz. Es liefert hohe Bandbreite und liegt nahe an der GPU-Rechenleistung. Diese Vorteile machen es zum natürlichen Speicherort für häufig genutzte Gewichte und einen wachsenden KV-Cache.

Kapazität bleibt jedoch aus Systemsicht teuer. Ein Betreiber fügt häufig GPUs hinzu, weil ein Modell nicht hineinpasst, selbst wenn der Workload ihre volle Rechenleistung nicht benötigt. Die zusätzlichen Beschleuniger führen dann zu Kommunikationskosten und operativer Komplexität.

Engram bietet einen Weg, Kapazität von Berechnung zu trennen. Der Server kann dichte Schichten, aktive Experten und latenzkritischen Zustand im HBM halten. Die Sparse-Speichertabelle kann er im Host-DRAM platzieren.

SemiAnalysis testete diese Anordnung über Unified Virtual Addressing, kurz UVA. UVA ermöglicht einer GPU, angehefteten Host-Speicher innerhalb eines gemeinsamen Adressraums zu adressieren. Derselbe GPU-Kernel wählte und dequantisierte Engram-Zeilen aus HBM oder DRAM.

Dabei handelte es sich nicht um gewöhnliches CPU-gesteuertes Offloading. Die GPU griff direkt auf die angeheftete Host-Allokation zu. Asynchrone Ausführung ermöglichte es, den Abruf mit anderer Modellarbeit zu überlappen.

Das überraschende Ergebnis zeigte sich bei Nvidias B300. SemiAnalysis berichtete, dass das Verschieben von Engram in DRAM der Konfiguration den Wechsel von vierfachem zu zweifachem Tensor-Parallelismus erlaubte.

Tensor-Parallelismus verteilt Modelloperationen auf mehrere GPUs. Er kann ein großes Modell passend machen, doch jede Aufteilung fügt Synchronisierung und Kommunikation hinzu. Eine Verringerung der Aufteilung kann daher die langsamere Speicherebene ausgleichen.

Laut dem Test verbesserte sich die Kombination aus B300-Durchsatz und Interaktivität um bis zu das 1,6-Fache. Das Zurückverlagern der Tabelle in HBM brachte auf diesem frühen Software-Stack keine messbare Verbesserung über Schwankungen zwischen Durchläufen hinaus.

Dieses Ergebnis kehrt das einfachste Argument der Speicherhierarchie um. HBM beschleunigte den einzelnen Lookup, doch diese Lookups stellten nur einen Teil des vollständigen Serving-Pfads dar. Engram verbrauchte Kapazität, die andernfalls KV-Cache, Batching oder eine kleinere Replik unterstützen könnte.

DRAM verbesserte das Gesamtsystem, indem es dessen Topologie veränderte. Der Vorteil entstand nicht dadurch, dass DRAM HBM bei der reinen Zugriffsgeschwindigkeit übertraf.

Dies ist der zentrale Druck auf das Design von GPU-Systemen. Betreiber haben bislang den Modell-Fit traditionell bewertet, indem sie Checkpoint-Größe, Laufzeitzustand und Sicherheitsmarge addierten. Engram verlangt von ihnen, Speicher nach Zugriffsmustern zu klassifizieren.

Heiße, dichte und bandbreitenintensive Gewichte bleiben für HBM geeignet. Vorhersagbare Sparse-Zeilen können DRAM tolerieren, wenn die Berechnung den Transfer verdeckt. Long-Tail-Zeilen könnten letztlich auf NVMe liegen, sofern Caching und Software-Overhead kontrollierbar bleiben.

Die Verschiebung hat Folgen für Speicheranbieter. Engram beendet die HBM-Nachfrage nicht. Die SemiAnalysis-Experimente deuten vielmehr darauf hin, dass Bandbreite für einige Inferenzkonfigurationen wichtiger sein kann als maximale HBM-Kapazität.

Gleichzeitig wird Server-DRAM Teil des Leistungsrahmens für Model Serving. Die Kapazitätsplanung muss angeheftete Allokationen, Speicherkanäle, PCIe-Verhalten und Konkurrenz zwischen Replikas berücksichtigen.

Auch NVMe erhält eine potenzielle Rolle, die über die Speicherung von Checkpoints und KV-Cache hinausgeht. Sein adressierbarer Markt wächst, wenn Modellparameter aktiv aus lokalem Speicher bedient werden. Diese Chance hängt jedoch davon ab, dass Software Speicherzugriffe wirtschaftlich nutzbar macht.

Die unmittelbaren Gewinner sind nicht zwangsläufig die Anbieter des größten Speicherpools. Es sind Systeme, die mehrere Ebenen koordinieren, ohne teure Beschleuniger zum Stillstand zu bringen.

Für Käufer von KI-Infrastruktur wird die Gesamtgröße eines Modells zu einem schwächeren Beschaffungssignal. Aktive Parameter, pro Token abgerufene Bytes, Prefetch-Distanz und Replikatopologie bieten nützlichere Orientierung.

Ein System mit 748 Milliarden Parametern kann sehr andere Hardwareanforderungen stellen als ein dichtes Modell ähnlicher Größe. DeepSeek-V4.1-Flash kombiniert ein Sparse-Backbone mit bedingtem Speicher und einem reduzierten KV-Cache. Jeder Teil belastet eine andere Ressource.

Diese Komplexität erschwert auch Vergleiche. Ein Benchmark, der nur Tokens pro Sekunde misst, kann Latenz bei einzelnen Parallelitätsstufen verbergen. Ein Kostenergebnis kann sich ändern, wenn eine Konfiguration GPUs ausschließlich für Speicherkapazität hinzufügt.

Der nützlichste Vergleich ordnet Durchsatz der für Nutzer sichtbaren Interaktivität gegenüber. Anschließend fragt er, wie viel nützliche Arbeit jeder vollständige Server liefert, nicht wie schnell ein einzelner isolierter Kernel läuft.

Warum Engram außerhalb des GPU-Speichers funktioniert

Deterministische Adressierung verschafft der Laufzeitumgebung Zeit zum Abrufen von Speicher, während Sparse-Zugriffe jeden Transfer klein genug halten, um ihn mit Berechnung zu überlappen.

Engram beginnt mit N-Grammen, also kurzen Folgen benachbarter Tokens. Die Architektur komprimiert den Wortschatz des Tokenizers, hasht lokale Sequenzen über mehrere Heads und ordnet diese Hashes erlernten Zeilen zu.

Die Vokabularkomprimierung ist wichtig, weil Tokenizer visuell ähnlichem Text häufig unterschiedliche IDs zuweisen. Groß- und Kleinschreibung, Leerzeichen und Unicode-Formen können wiederkehrende Muster aufspalten. Das Paper berichtet für einen Wortschatz mit 128.000 Tokens über eine Verringerung des effektiven Vokabulars um 23 Prozent.

Die abgerufenen Embeddings gelangen nicht unverändert ins Modell. Ein kontextabhängiges Gate steuert, wie stark jeder Lookup den aktuellen Hidden State beeinflusst. Eine leichtgewichtige Convolution fügt Kontext aus der Umgebung hinzu, bevor der Speicherbeitrag spätere Schichten erreicht.

Dieses Design erklärt sowohl Engrams Wert als auch seine Grenzen. Die Tabelle speichert wiederverwendbare statistische Muster, doch das Modell entscheidet weiterhin, wie stark es sie nutzt. Es handelt sich nicht um eine konventionelle Datenbank mit sauber abgelegten Fakten.

SemiAnalysis untersuchte Muster mit hohem Gate-Wert in DeepSeek-V4.1-Flash. Dabei fanden sich Namen, Codefragmente, relationale Formulierungen, Lizenzen, Bibliografiefragmente und Web-Boilerplate. Ein ungewöhnliches Beispiel bezog sich auf die Spielereihe Ace Attorney.

Diese Ergebnisse legen nahe, dass die Tabelle die Next-Token-Prediction optimiert, nicht menschliche Einschätzungen darüber, welches Wissen wertvoll ist. Wiederkehrende Formatierung kann nützlich werden, wenn sie eine Abkürzung für die Vorhersage bietet.

Dieses Ergebnis erschwert das Caching. Ein starkes Gate identifiziert nicht zwangsläufig eine häufig abgerufene Zeile. Eine Zeile kann beim Abruf hohen Wert haben, aber im Produktionsverkehr selten erscheinen.

Die Laufzeitumgebung kann auch nicht jeden schwachen Lookup nach Ermittlung seines Gates vermeiden. Die Berechnung des Gates benötigt den zugehörigen Key, der den Abruf bereits ausgelöst hat. Das Überspringen dieses Lesezugriffs würde einen separaten Prädiktor erfordern, der vor dem Speicherzugriff arbeitet.

Die Zugriffshäufigkeit sollte weiterhin einer Long-Tail-Verteilung folgen. Häufige Wörter, Programmiermuster und routinemäßige Syntax sollten öfter auftreten als seltene Entitäten. Das macht einen mehrstufigen Cache plausibel.

Häufig angeforderte Zeilen könnten im HBM verbleiben. Ein größerer Arbeitssatz könnte im Host-DRAM liegen. Seltene Zeilen könnten auf NVMe gespeichert werden und in schnellere Ebenen aufsteigen, sobald der Datenverkehr sie nützlich macht.

Die CXL-Speicherforschung überträgt dieselbe Idee über das direkt angeschlossene DRAM eines einzelnen Servers hinaus. Ihre Autoren schlagen vor, Engram-Speicher über Compute Express Link zu bündeln, das fein granularen Zugriff auf gemeinsam genutzte Speichergeräte unterstützt.

Dieser Vorschlag bleibt Forschung und ist kein Beleg für die Wirtschaftlichkeit im Produktionsbetrieb. CXL bringt eigene Überlegungen zu Latenz, Topologie und Software mit sich. Dennoch zeigt er, wie bedingter Speicher Systemgrenzen verändert.

Ein Betreiber könnte den Lookup-Pool getrennt von der GPU-Rechenleistung skalieren. Mehrere Beschleuniger könnten Kapazität gemeinsam nutzen, statt die gesamte Tabelle in jeder GPU-Replik zu duplizieren.

Prefetching ist der zentrale Mechanismus in diesen Entwürfen. Engram-Schichten können nicht beliebig früh liegen, wenn die Speicherlatenz verborgen werden muss. Mehr vorausgehende Berechnung schafft ein längeres Zeitfenster für den Abruf.

Die Modellqualität kann in die entgegengesetzte Richtung wirken. Frühe Speicherintervention hilft dem Netzwerk, nicht seine ersten Schichten für die Rekonstruktion häufiger lokaler Muster aufzuwenden. Eine zu späte Platzierung von Engram kann diesen Vorteil schwächen.

Dadurch entsteht ein echtes Co-Design-Problem. Modellforscher wählen Einfügungsschichten, Tabellendimensionen, Hashing-Verhalten und Gates. Runtime-Ingenieure entwerfen darum herum Prefetch-Warteschlangen, Caches, Kernel und Übertragungspfade.

Hardware-Teams entscheiden anschließend, wie viel Bandbreite und Kapazität jede Ebene bereitstellen sollte. Keine dieser Entscheidungen lässt sich unabhängig optimieren.

DeepSeeks Paper berichtete über einen U-förmigen Zusammenhang zwischen den Parametern für MoE-Berechnung und den Parametern für Engram-Speicher. Zu wenig Speicher ließ wiederholte Muster beim neuronalen Backbone. Zu viel Speicher verringerte die für andere Aufgaben verfügbare Rechenleistung.

Dieses Ergebnis spricht dagegen, Engram als unbegrenzte günstige Kapazität zu behandeln. Mehr Tabellenzeilen können den Validierungsverlust verbessern, jedoch nur in einem ausgewogenen System. Auch die Qualität der Trainingsdaten bestimmt, was diese Zeilen lernen.

Die weiterreichende architektonische Implikation ist wichtig. Skalierung bedeutet nicht länger, jeden neuen Parameter neben GPU-Arithmetik zu platzieren. Ein Modell kann Kapazität durch vorhersehbaren, spärlichen Abruf hinzufügen und gleichzeitig teure Bandbreite für dynamische Berechnung reservieren.

SSD-Offloading ist noch nicht die günstige Antwort

Das erste NVMe-Experiment sparte fest zugewiesene DRAM-Kapazität, doch sein nicht optimierter Datenpfad unterlag gepinntem DRAM sowohl bei Geschwindigkeit als auch bei Effizienz.

SemiAnalysis ersetzte die 189-GiB-Engram-Zuweisung durch speicherabgebildete Dateien auf lokalen SSDs. Eine speicherabgebildete Datei ermöglicht es dem Betriebssystem, Speicher über virtuelle Speicherseiten bereitzustellen. Kürzlich genutzte Seiten können im Dateisystem-Cache verbleiben.

Dieser Ansatz bietet operative Flexibilität. Das Betriebssystem kann zwischengespeicherte Seiten zurückfordern, wenn andere Anwendungen Speicher benötigen. Betreiber vermeiden es, die vollständige Engram-Tabelle dauerhaft im DRAM zu pinnen.

Ein warmer Page Cache macht den SSD-Pfad jedoch nicht mit nativem DRAM-Offload gleichwertig. Der Prototyp übertrug weiterhin Zeilenkennungen an die CPU, entfernte Duplikate, sammelte Zeilen in gepinnten Puffern und kopierte sie zurück.

Anschließend dequantisierte er die ausgewählten Zeilen auf der GPU. Diese Schritte liefen zwischen Segmenten der GPU-Ausführung, statt über den direkten UVA-Kernel, der für gepinnten Host-Speicher verwendet wurde.

Jeder Schritt erhöht den Koordinationsaufwand. CPU-Planung, Übertragungen von Kennungen, Zeilensammlung, Puffermanagement und GPU-Kopien können mehr kosten als der physische Speicherzugriff. Eine zwischengespeicherte Datei kann daher hinter gepinntem DRAM zurückbleiben, selbst wenn keine Anfrage NAND-Flash erreicht.

Die B200-Ergebnisse legten diese Lücke offen. Bei knapp 125 Tokens pro Sekunde je Nutzer erzeugte die DRAM-Konfiguration 121 Millionen Tokens insgesamt pro Ausgabeeinheit. Der SSD-Pfad erreichte 52 Millionen.

DRAM lieferte unter diesem gemessenen Vergleich somit etwa 2,3-mal so viele Tokens. Auch bei der beobachteten P90-Interaktivität, die die Erfahrung langsamerer Anfragen nahe dem Tail misst, übertraf es die SSD-Konfigurationen.

Die Forscher konnten GPUDirect Storage, kurz GDS, für den Test nicht aktivieren. GDS kann Daten mit weniger CPU-Beteiligung zwischen NVMe und GPU-Speicher bewegen. Sein Fehlen begrenzt, was das Experiment über einen optimierten Speicherpfad aussagt.

Das Ergebnis sollte nicht als Beweis dargestellt werden, dass NVMe Engram nicht bedienen kann. Es zeigt, dass günstige Speichermedien nicht automatisch günstige Inferenz ermöglichen.

Die vier B200-GPUs blieben im Server. Ebenso blieben CPU, Netzwerk, Stromversorgung und der Großteil der unterstützenden Infrastruktur. Der Austausch von DRAM durch SSD verringerte eine Kapazitätsanforderung, ohne die teuren Teile der Konfiguration zu reduzieren.

Ein wirtschaftlicher Vorteil erfordert einen zweiten Effekt. SSD-Offloading muss einen günstigeren Server ermöglichen, mehr produktive Repliken unterbringen, ein größeres Modell unterstützen oder DRAM für eine andere wertvolle Arbeitslast freigeben.

Der Prototyp erzielte keines dieser Ergebnisse in seinem gemessenen Setup. Sein Dateisystem-Cache könnte außerdem einen Großteil des DRAM verbrauchen, den die Dateispeicherung eigentlich einsparen sollte.

Die Lokalität der Arbeitslast schafft eine weitere Unsicherheit. Ein stabiler Dienst mit wiederholten Prompts könnte einen nützlichen warmen Cache erhalten. Eine vielfältige Agenten-Arbeitslast könnte ein breiteres Spektrum von N-Grammen berühren und mehr Speicherfehler verursachen.

Batching verändert die Gleichung erneut. Mehrere Anfragen können Zeilen innerhalb eines Batches wiederverwenden, während Deduplizierung Übertragungen reduziert. Größere Batches erhöhen jedoch auch die Anforderungen an den KV-Cache und können die Latenz verändern.

Allein anhand von SSD-Hardwarespezifikationen lässt sich das Ergebnis nicht vorhersagen. Zufallsleselatenz, Warteschlangentiefe, Dateisystemverhalten, Seitengröße, CPU-Overhead und Cache-Richtlinien tragen alle bei.

Empfehlungssysteme bieten einen nützlichen historischen Präzedenzfall. Sie bedienen seit Jahren große Embedding-Tabellen aus gestuftem Speicher. Einige Systeme cachen beliebte Zeilen im DRAM, während sie den Long Tail auf SSDs platzieren.

Der Engram-Datenverkehr von Sprachmodellen ist ähnlich genug, um Ideen zu übernehmen, aber nicht identisch. Autoregressive Generierung erzwingt enge sequenzielle Latenzanforderungen. Eine Verzögerung an einer Token-Position kann spätere Positionen aufhalten.

AgentX macht dieses Problem sichtbarer. Es repräsentiert Long-Context-, Multi-Turn-Agentic-Coding-Verkehr statt eines kurzen synthetischen Prompts. Solche Arbeitslasten wechseln zwischen umfangreicher Eingabeverarbeitung und latenzsensitiver Generierung.

Der Storage-Fall wird sich nur verbessern, wenn Software Engram als erstklassige Serving-Primitiv behandelt. Eine generische speicherabgebildete Datei ist für Experimente nützlich, lässt aber zu viel Arbeit im CPU-gesteuerten Pfad.

Künftige Entwürfe benötigen direktes I/O, asynchrone Warteschlangen, zeilenbewusstes Caching und vorhersehbare Prefetch-Zeitpläne. Sie könnten zudem Speicherlayouts benötigen, die an Engrams quantisierte Zeilen angepasst sind.

NVMe bleibt daher eher eine Chance als der aktuelle Standard. DRAM hat bereits gezeigt, dass Tiering das System verbessern kann. SSD benötigt weiterhin einen Serving-Stack, der auf das spärliche Zugriffsmuster des Modells ausgelegt ist.

AgentX zeigt den Software-Graben um neue Architekturen

Engram verändert die Speicherplatzierung, doch Software-Unterstützung am Launch-Tag entscheidet weiterhin, welcher Beschleuniger die Architektur in einen nutzbaren Dienst verwandeln kann.

SemiAnalysis bewertete DeepSeek-V4.1-Flash auf Nvidia-Systemen mit H100, H200, B200, B300, GB200 und GB300. Zudem testete es AMDs MI355X über das InferenceX-Framework.

Die InferenceX-Messungen verwenden reale Hardware und erfassen Durchsatz im Verhältnis zur Interaktivität. AgentX liefert eine Long-Context-Coding-Arbeitslast, die wiederholten, toolorientierten Sitzungen ähneln soll.

Laut SemiAnalysis funktionierte Nvidias vLLM-Pfad beim Modellstart auf allen sechs getesteten Nvidia-Plattformen. AMDs referenziertes Container-Image war in den ersten 23 Stunden nicht öffentlich verfügbar.

Die AMD-Unterstützung kam später, doch die frühe Leistungslücke blieb in den Messungen des Analysten erheblich. Sieben Tage nach der Veröffentlichung ordnete SemiAnalysis die Leistung pro Ausgabeeinheit des MI355X zwischen zwei- und viermal hinter dem B200 ein.

Dies sind anbietersensitive Aussagen einer einzelnen Benchmarking-Organisation. Sie hängen von Cloud-Annahmen, Runtime-Versionen, Quantisierung, Topologie und schnellen Softwareänderungen ab. Sie sollten nicht auf jedes Modell oder jede AMD-Arbeitslast verallgemeinert werden.

Sie offenbaren jedoch eine wichtige Einschränkung. Eine Architektur kann für Offloading ausgelegt sein, ihre Bereitstellung hängt aber weiterhin von Kerneln, Graph Capture, Speicheradressierung, Quantisierung und verteilter Planung ab.

DeepSeek-Engram-Offloading benötigt mehr als ausreichende PCIe-Bandbreite. Die Runtime muss Übertragungen überlappen, ohne Decode-Graphs zu unterbrechen. Sie muss Zeilen auf jeder Plattform effizient auswählen und dequantisieren.

Ein neues Modell testet daher ein Beschleuniger-Ökosystem, bevor Hardware-Teams Monate für dessen Optimierung hatten. Vertrautheit der Maintainer und funktionierende Release-Pipelines werden Teil der Leistung.

Diese Dynamik stärkt Nvidias Software-Position, selbst wenn die Modellarchitektur die pro Replik benötigte HBM-Kapazität verringert. Weniger GPUs pro Replik können die Kommunikation reduzieren, doch jede verbleibende GPU benötigt ausgereifte Kernel und Runtime-Integration.

Die Auswirkung auf die Gesamtnachfrage nach Beschleunigern ist nicht eindeutig. Bessere Speichernutzung kann die Zahl der für eine Modellreplik benötigten GPUs reduzieren. Niedrigere Serving-Kosten können die Nachfrage auch ausweiten, indem sie mehr Anwendungen wirtschaftlich tragfähig machen.

Engram könnte größere Modelle fördern, weil bedingter Speicher getrennt von aktiver Berechnung skaliert. Betreiber könnten das eingesparte HBM für mehr gleichzeitige Sitzungen nutzen, statt weniger Beschleuniger zu kaufen.

DeepSeek hat laut seinen Release-Materialien auch die Anforderungen an den KV-Cache in V4.1-Flash reduziert. Engram-Offload und KV-Komprimierung geben Speicher aus zwei unterschiedlichen Richtungen frei.

Diese Kombination ist für agentische Inferenz wichtig. Agenten führen lange Verläufe, Tool-Ausgaben, Code und Zwischenpläne mit sich. Ihr KV-Cache kann erhebliche Kapazität belegen, selbst wenn die Modellgewichte bereits passen.

Ein Server, der spärliche Lookup-Tabellen in DRAM verlagert, kann mehr HBM für diese aktiven Sitzungen bereitstellen. Der praktische Vorteil könnte sich in höherer Parallelität zeigen, nicht in einem kleineren physischen Modell.

Die skeptische Sicht bleibt erforderlich. SemiAnalysis’ Engram-Reproduktion verwendete veröffentlichten Code und Trainingskonfigurationen, weil DeepSeek die beiden trainierten Forschungsmodelle aus dem Originalpaper nicht veröffentlichte. Das Produktionsverhalten kann von kontrollierten Skalierungsexperimenten abweichen.

Der SSD-Pfad war ausdrücklich nicht optimiert. Die Nvidia- und AMD-Ergebnisse erfassten frühe Software-Stacks, die sich verändern werden. Selbst das stärkste DRAM-Ergebnis hing von einer spezifischen B300-Topologie und Arbeitslastgrenze ab.

Engram speichert zudem, was auch immer das Training belohnt. Mehr Kapazität kann neben nützlichen Entitäten oder Code auch Boilerplate und beiläufige Muster bewahren. Bessere Speicherzuweisung garantiert keine bessere Datenauswahl.

Die Evidenz stützt eine engere Schlussfolgerung. Bedingter Speicher ist technisch mit niedrigeren Speicherebenen kompatibel, und DRAM kann die Leistung des gesamten Serving-Systems verbessern. Eine universelle Konfiguration ist damit noch nicht belegt.

Drei Signale werden die Auswirkungen auf DRAM und NVMe entscheiden

Die nächste Phase hängt von optimiertem SSD-Serving, reproduzierbaren Topologiegewinnen und breiter Runtime-Unterstützung über eine einzelne Modellveröffentlichung hinaus ab.

Das erste Signal ist eine optimierte NVMe-Implementierung mit einem direkten, GPU-orientierten Pfad. Der wichtige Vergleich ist nicht die maximale SSD-Bandbreite. Es ist die vollständige Grenze von Durchsatz und P90-Interaktivität gegenüber gepinntem DRAM.

Unterstützung für GPUDirect Storage würde einen Teil des CPU-Rundwegs entfernen. Native Zeilendeduplizierung, asynchrones Prefetching und Engram-bewusste Speicherlayouts könnten weiteren Overhead beseitigen.

Wenn ein optimierter Pfad sich der DRAM-Leistung annähert und zugleich den benötigten Host-Speicher wesentlich reduziert, wird die NVMe-Chance glaubwürdig. Bleibt zwischengespeicherte SSD deutlich zurück, wird Engram stattdessen die DRAM-Nachfrage stärken.

Das zweite Signal ist, ob sich kleinere Replikat-Topologien über verschiedene Hardware und Workloads hinweg wiederholen. Der Wechsel von SemiAnalysis bei B300 von vierfacher zu zweifacher Tensor-Parallelität lieferte das folgenreichste Ergebnis.

Unabhängige Tests sollten B200, H200, MI355X und künftige Systeme untersuchen. Sie sollten unterschiedliche Kontextlängen, Batch-Größen, Parallelitätsstufen und Cache-Zustände einbeziehen.

Wiederholte Verbesserungen würden bestätigen, dass Engram-Offloading die Serverökonomie durch weniger Kommunikation verändert. Lassen sie sich nicht reproduzieren, wäre die Erkenntnis auf eine frühe einzelne Konfiguration begrenzt.

Das dritte Signal ist die Akzeptanz im Ökosystem. DeepSeek-V4.1-Flash bietet einen sichtbaren Testfall, doch Engram-ähnlicher Speicher muss sich auf weitere Modellfamilien und Serving-Engines ausbreiten, um die Hardware-Nachfrage zu verändern.

Der SemiAnalysis-Bericht verweist auf verwandte N-Gram-Mechanismen in LongCat- und Qwen-Modellen. Forschende haben außerdem gebündelte Engram-Kapazität über CXL vorgeschlagen. Diese Ansätze benötigen stabile Unterstützung in vLLM, SGLang und den Runtimes der Anbieter.

Eine breite Einführung würde die Nachfrage nach ausgewogenen Servern mit höherer DRAM-Bandbreite, leistungsfähigem lokalem NVMe und flexiblen Interconnects stärken. Bei begrenzter Verbreitung bliebe Engram eine wichtige, DeepSeek-spezifische Optimierung.

Entwickler sollten Bereitstellungsrezepte beobachten, nicht Parameter-Schlagzeilen. Unternehmenskäufer sollten Leistung bei ihren eigenen Kontextlängen und Latenzzielen anfordern. Infrastrukturteams sollten kalte, warme und gemischte Cache-Zustände getrennt messen.

Wissensarbeiter werden das Ergebnis indirekt erleben. Eine bessere Speicherplatzierung kann längere Sitzungen, geringere Latenz und einen breiteren Zugang zu leistungsfähigen Modellen ermöglichen. Diese Vorteile zählen nur, wenn vollständige Anwendungen sie zuverlässig nutzen.

Teams, die KI-Systeme bewerten, sollten ihre eigenen Nachweise neben Benchmark-Behauptungen bewahren. Eine durchsuchbare Engineering-Wissensdatenbank kann Modellkarten, Runtime-Versionen und interne Testergebnisse miteinander verknüpft halten.

DeepSeek Engram-Offloading ist nicht das Ende der HBM-geführten Inferenz. Es zeigt vielmehr, dass die Modellarchitektur zunächst entscheiden kann, welche Parameter HBM verdienen. Die nächste Frage ist, ob optimiertes NVMe und gemeinsam genutzter Speicher das Ergebnis von DRAM wiederholen können, ohne den Engpass in die Software zu verlagern.