L’offloading di DeepSeek Engram porta la memoria AI oltre l’HBM

L’offloading di DeepSeek Engram ha spostato 189 GiB di memoria del modello al di fuori dell’HBM della GPU, con test su DRAM che talvolta hanno superato una configurazione interamente in HBM. Il risultato mette in discussione un presupposto fondamentale dell’infrastruttura per i grandi modelli. La memoria più veloce non è automaticamente la collocazione migliore per ogni parametro.

SemiAnalysis ha pubblicato i nuovi esperimenti il 18 settembre, utilizzando DeepSeek-V4.1-Flash e il framework di serving InferenceX. I test hanno collocato le tabelle Engram nella DRAM dell’host o in file mappati in memoria su unità NVMe locali. Il percorso DRAM ha migliorato una configurazione B300 riducendo il parallelismo tensoriale, mentre la prima implementazione SSD è rimasta più lenta e meno economica.

Questa distinzione è importante. Engram non elimina la domanda di GPU Nvidia o di memoria ad alta larghezza di banda. Cambia quali parametri del modello meritano quella capacità scarsa. La competizione nel breve termine non è quindi HBM contro SSD. È un modello di deployment interamente in HBM contro un sistema a livelli che assegna carichi di lavoro diversi a HBM, DRAM e storage.

L’offloading di DeepSeek Engram cambia il posizionamento dei parametri

Il cambiamento centrale è architetturale: un grande blocco di memoria appresa può lasciare l’HBM senza costringere l’intero modello a comportarsi come una rete neurale sottoposta a offloading.

DeepSeek ha introdotto Engram come modulo di memoria condizionale per modelli linguistici. Estende gli embedding ordinari dei token con lookup appresi per schemi ricorrenti composti da più token. Questi schemi possono includere nomi, frammenti di codice, testo standardizzato e frasi relazionali comuni.

Un Transformer ordinario spesso ricostruisce tali schemi locali tramite livelli di attenzione e feed-forward. Engram offre al modello un percorso di lookup separato. Esegue l’hashing di sequenze di token, recupera una piccola raccolta di righe di embedding e le combina con lo stato nascosto del modello.

Il paper sulla memoria condizionale originale descrive questo approccio come una seconda forma di sparsità. La Mixture-of-Experts, o MoE, attiva solo una parte del calcolo del modello per ogni token. Engram attiva solo una minuscola parte di una tabella di memoria molto più grande.

Questa distinzione determina il modo in cui l’hardware può servire il modello. Un esperto MoE contiene matrici di pesi utilizzate per un calcolo sostanziale. Spostarne uno tra livelli di storage può richiedere grandi trasferimenti esattamente nel momento sbagliato.

Gli indirizzi Engram sono diversi. Dipendono dagli ID dei token e dalla loro sequenza locale, anziché da uno stato nascosto intermedio. Un runtime può sapere quali righe gli servono prima che i livelli successivi del modello abbiano terminato il calcolo.

Questa prevedibilità crea una finestra di prefetch. Il server può recuperare righe dalla memoria host mentre la GPU gestisce le operazioni precedenti. Se il recupero termina entro quella finestra, il modello evita gran parte della latenza normalmente associata all’offloading.

La ricerca pubblicata da DeepSeek ha portato una tabella Engram sperimentale a 27 miliardi di parametri. In confronti controllati, gli autori hanno riportato miglioramenti rispetto a una baseline MoE con parametri e calcolo equivalenti. I miglioramenti dichiarati hanno riguardato conoscenza fattuale, ragionamento, codice, matematica e recupero su contesti lunghi.

Questi dati provenivano da modelli di ricerca, non dall’esatto sistema di produzione testato da SemiAnalysis. Spiegano comunque perché Engram non possa essere trattato come metadato opzionale. Diventa parte del percorso di ragionamento del modello addestrato.

SemiAnalysis ha rafforzato questo punto rimuovendo Engram durante l’inferenza. Secondo la sua analisi, nella precedente ablazione del paper i benchmark fattuali hanno mantenuto solo dal 29 al 44 percento delle prestazioni originali. La comprensione del testo ha mantenuto dall’81 al 93 percento.

Questa perdita non dimostra che Engram superi ogni modello convenzionale. La rete è stata addestrata a dipendere dal proprio modulo di memoria. Rimuovere tale modulo crea una discrepanza tra addestramento e inferenza.

L’esperimento mostra però che gli operatori non possono semplicemente eliminare la tabella quando la memoria diventa insufficiente. Devono servirla in modo efficiente, comprimerla o collocarla altrove.

DeepSeek-V4.1-Flash rende concreto il problema del posizionamento. DeepSeek afferma che il modello dispone di un backbone MoE da 552 miliardi di parametri, con 8 miliardi di parametri attivi durante l’elaborazione dell’input e 16 miliardi durante la generazione dell’output. Engram aggiunge un altro grande pool di memoria condizionale.

Il rilascio di V4.1-Flash afferma inoltre che la KV cache richiede un quarto dell’HBM e un ottavo dello storage SSD del predecessore. La KV cache memorizza lo stato di attenzione riutilizzabile dei token precedenti. È separata da Engram, ma entrambe le funzionalità ridefiniscono i requisiti di memoria del server.

SemiAnalysis ha utilizzato circa 189 GiB per la tabella Engram del modello. Eppure ogni posizione di token elaborata richiedeva soltanto 24 righe su due livelli Engram. Ciò rappresentava circa 12,4 KiB nell’intero modello, o 3,1 KiB per GPU in una configurazione a quattro GPU.

La tabella è enorme, ma la lettura attiva è minuscola. Questa asimmetria è la ragione per cui l’offloading di DeepSeek Engram funziona.

L’offloading su DRAM mette sotto pressione il design interamente in HBM

Engram indebolisce il legame tra numero totale di parametri e capacità HBM richiesta, anche quando la larghezza di banda della GPU rimane essenziale.

L’HBM possiede due proprietà preziose per l’inferenza AI. Offre un’elevata larghezza di banda e si trova vicino al calcolo della GPU. Questi vantaggi la rendono la sede naturale per pesi consultati di frequente e per una KV cache in crescita.

La capacità resta tuttavia costosa a livello di sistema. Un operatore spesso aggiunge GPU perché un modello non entra in memoria, anche quando il carico di lavoro non richiede tutta la loro potenza di calcolo. Gli acceleratori aggiuntivi introducono quindi costi di comunicazione e complessità operativa.

Engram offre un modo per separare capacità e calcolo. Il server può mantenere in HBM livelli densi, esperti attivi e stato sensibile alla latenza. Può collocare la tabella di memoria sparsa nella DRAM dell’host.

SemiAnalysis ha testato questa configurazione tramite Unified Virtual Addressing, o UVA. UVA consente a una GPU di indirizzare memoria host pinnata in un unico spazio di indirizzamento condiviso. Lo stesso kernel GPU selezionava e dequantizzava le righe Engram da HBM o DRAM.

Non si trattava di un ordinario offloading gestito dalla CPU. La GPU accedeva direttamente all’allocazione host pinnata. L’esecuzione asincrona ha consentito di sovrapporre il recupero ad altro lavoro del modello.

Il risultato sorprendente è apparso sulla B300 di Nvidia. SemiAnalysis ha riportato che lo spostamento di Engram nella DRAM ha consentito alla configurazione di passare dal parallelismo tensoriale a quattro vie a quello a due vie.

Il parallelismo tensoriale divide le operazioni del modello tra più GPU. Può permettere l’esecuzione di un modello di grandi dimensioni, ma ogni divisione aggiunge sincronizzazione e comunicazione. Ridurre la suddivisione può quindi compensare il livello di memoria più lento.

Secondo il test, la frontiera di throughput e interattività della B300 risultante è migliorata fino a 1,6 volte. Riportare la tabella in HBM non ha prodotto un miglioramento misurabile oltre la variazione tra esecuzioni in quello stack software iniziale.

Questa scoperta ribalta l’argomento più semplice della gerarchia di memoria. L’HBM rendeva il singolo lookup più veloce, ma tali lookup rappresentavano solo una parte dell’intero percorso di serving. Engram consumava capacità che altrimenti avrebbe potuto supportare KV cache, batching o una replica più piccola.

La DRAM ha migliorato l’intero sistema modificandone la topologia. Il vantaggio non derivava dal fatto che la DRAM superasse l’HBM nella velocità di accesso pura.

Questa è la principale pressione sul design dei sistemi GPU. Gli operatori hanno tradizionalmente valutato l’adattamento del modello sommando dimensione del checkpoint, stato di runtime e margine di sicurezza. Engram richiede loro di classificare la memoria in base al modello di accesso.

I pesi caldi, densi e ad alta intensità di larghezza di banda continuano a favorire l’HBM. Righe sparse prevedibili possono tollerare la DRAM quando il calcolo nasconde il trasferimento. Le righe della coda lunga potrebbero infine risiedere su NVMe, a condizione che caching e overhead software restino sotto controllo.

Il cambiamento ha implicazioni per i fornitori di memoria. Engram non pone fine alla domanda di HBM. Gli esperimenti di SemiAnalysis suggeriscono invece che, per alcune configurazioni di inferenza, la larghezza di banda possa contare più della capacità HBM massima.

Allo stesso tempo, la DRAM del server diventa parte dell’inviluppo prestazionale del serving del modello. La pianificazione della capacità deve tenere conto di allocazioni pinnate, canali di memoria, comportamento PCIe e contesa tra repliche.

Anche NVMe acquisisce un potenziale ruolo oltre alla conservazione di checkpoint e KV cache. Il suo mercato indirizzabile cresce se i parametri del modello vengono serviti attivamente dallo storage locale. Tuttavia, questa opportunità dipende dalla capacità del software di rendere economicamente utili le letture dallo storage.

I vincitori immediati non sono necessariamente i fornitori che vendono il pool di memoria più grande. Sono i sistemi che coordinano più livelli senza bloccare acceleratori costosi.

Per gli acquirenti di infrastruttura AI, la dimensione totale del modello diventa un segnale di procurement meno utile. Parametri attivi, byte recuperati per token, distanza di prefetch e topologia delle repliche offrono indicazioni più utili.

Un sistema da 748 miliardi di parametri può imporre requisiti hardware molto diversi rispetto a un modello denso di dimensioni analoghe. DeepSeek-V4.1-Flash combina un backbone sparso con memoria condizionale e una KV cache ridotta. Ciascuna parte mette sotto pressione una risorsa diversa.

Questa complessità rende anche più difficili i confronti. Un benchmark che misura solo i token al secondo può nascondere la latenza a singoli livelli di concorrenza. Un risultato sui costi può cambiare quando una configurazione aggiunge GPU esclusivamente per la capacità di memoria.

Il confronto più utile mette in relazione throughput e interattività visibile all’utente. Poi chiede quanto lavoro utile produca ogni server completo, non quanto rapidamente venga eseguito un singolo kernel isolato.

Perché Engram funziona al di fuori della memoria GPU

L’indirizzamento deterministico offre al runtime il tempo di recuperare la memoria, mentre l’accesso sparso mantiene ogni trasferimento abbastanza piccolo da sovrapporsi al calcolo.

Engram parte dagli N-gram, ovvero brevi sequenze di token adiacenti. L’architettura comprime il vocabolario del tokenizer, esegue l’hashing di sequenze locali tramite più teste e mappa tali hash a righe apprese.

La compressione del vocabolario è importante perché i tokenizer assegnano spesso ID diversi a testo visivamente simile. Maiuscole, spaziature e forme Unicode possono frammentare gli schemi ripetuti. Il paper riporta una riduzione del 23 percento del vocabolario effettivo per un vocabolario da 128.000 token.

Gli embedding recuperati non entrano invariati nel modello. Un gate consapevole del contesto controlla quanto ogni lookup influenzi lo stato nascosto corrente. Una convoluzione leggera aggiunge contesto vicino prima che il contributo della memoria raggiunga i livelli successivi.

Questo design aiuta a spiegare sia il valore di Engram sia i suoi limiti. La tabella memorizza schemi statistici riutilizzabili, ma il modello decide comunque quanto utilizzarli. Non è un database convenzionale contenente record fattuali puliti.

SemiAnalysis ha analizzato gli schemi ad alto gate in DeepSeek-V4.1-Flash. Ha trovato nomi, frammenti di codice, formulazioni relazionali, licenze, frammenti bibliografici e testo standardizzato del web. Un esempio insolito faceva riferimento alla serie di giochi Ace Attorney.

Questi risultati suggeriscono che la tabella ottimizzi la previsione del token successivo, non i giudizi umani su quale conoscenza sia preziosa. La formattazione ripetuta può diventare utile se fornisce una scorciatoia predittiva.

Questa scoperta complica il caching. Un gate forte non identifica necessariamente una riga a cui si accede di frequente. Una riga può avere un valore elevato quando viene recuperata, ma comparire raramente nel traffico di produzione.

Il runtime non può inoltre evitare ogni lookup debole dopo averne osservato il gate. Il calcolo del gate richiede la chiave corrispondente, che ha già attivato il recupero. Saltare quella lettura richiederebbe un predittore separato che operi prima dell’accesso alla memoria.

La frequenza di accesso dovrebbe comunque seguire una distribuzione a coda lunga. Le parole comuni, i pattern di programmazione e la sintassi di routine dovrebbero comparire più spesso delle entità rare. Questo rende plausibile una cache multilivello.

Le righe richieste più di frequente potrebbero rimanere in HBM. Un set di lavoro più ampio potrebbe risiedere nella DRAM dell'host. Le righe rare potrebbero stare su NVMe e passare a livelli più veloci quando il traffico le rende utili.

La ricerca sulla memoria CXL estende la stessa idea oltre la DRAM collegata direttamente a un singolo server. Gli autori propongono di condividere in pool la memoria Engram tramite Compute Express Link, che supporta un accesso granulare a dispositivi di memoria condivisa.

La proposta resta ricerca, non una dimostrazione dell'economia di produzione. CXL introduce proprie considerazioni su latenza, topologia e software. Mostra comunque come la memoria condizionale modifichi i confini del sistema.

Un operatore potrebbe scalare il pool di lookup separatamente dal calcolo GPU. Diversi acceleratori potrebbero condividere la capacità anziché duplicare l'intera tabella all'interno di ogni replica GPU.

Il prefetching è il meccanismo centrale in tutte queste architetture. I layer Engram non possono essere collocati troppo presto se occorre nascondere la latenza dello storage. Una maggiore quantità di calcolo precedente crea una finestra di recupero più lunga.

La qualità del modello può spingere nella direzione opposta. Un intervento della memoria nelle fasi iniziali aiuta la rete a non sprecare i primi layer ricostruendo pattern locali comuni. Posizionare Engram troppo tardi può indebolire questo vantaggio.

Questo crea un autentico problema di codesign. I ricercatori dei modelli scelgono i layer di inserimento, le dimensioni delle tabelle, il comportamento dell'hashing e i gate. Gli ingegneri runtime progettano code di prefetch, caching, kernel e percorsi di trasferimento attorno a tali scelte.

I team hardware decidono quindi quanta banda e capacità debba fornire ogni livello. Nessuna di queste decisioni può essere ottimizzata in modo indipendente.

Il paper di DeepSeek ha riportato una relazione a U tra i parametri assegnati al calcolo MoE e quelli assegnati alla memoria Engram. Troppa poca memoria lasciava i pattern ripetuti alla rete neurale di base. Troppa memoria riduceva il calcolo disponibile per altri compiti.

Il risultato invita a non considerare Engram come capacità economica illimitata. Più righe di tabella possono migliorare la validation loss, ma solo all'interno di un sistema equilibrato. Anche la qualità dei dati di addestramento determina ciò che quelle righe apprendono.

L'implicazione architetturale più ampia è importante. Scalare non significa più collocare ogni nuovo parametro accanto all'aritmetica GPU. Un modello può aggiungere capacità tramite recupero sparso prevedibile, riservando la costosa banda alle elaborazioni dinamiche.

L'offloading su SSD non è ancora la risposta economica

Il primo esperimento con NVMe ha ridotto la capacità DRAM impegnata, ma il suo percorso dati non ottimizzato ha perso contro la DRAM pinned sia in velocità sia in efficienza.

SemiAnalysis ha sostituito l'allocazione Engram da 189 GiB con file mappati in memoria su SSD locali. Un file mappato in memoria permette al sistema operativo di esporre lo storage attraverso pagine di memoria virtuale. Le pagine consultate di recente possono rimanere nella cache del filesystem.

Questo approccio offre flessibilità operativa. Il sistema operativo può recuperare le pagine in cache quando altre applicazioni necessitano di memoria. Gli operatori evitano di mantenere permanentemente in DRAM l'intera tabella Engram.

Tuttavia, una cache di pagine calda non rende il percorso SSD equivalente all'offload nativo verso DRAM. Il prototipo trasferiva comunque gli identificatori delle righe alla CPU, eliminava i duplicati, raccoglieva le righe in buffer pinned e le copiava indietro.

Successivamente dequantizzava le righe selezionate sulla GPU. Questi passaggi venivano eseguiti tra segmenti dell'esecuzione GPU anziché tramite il kernel UVA diretto usato per la memoria host pinned.

Ogni passaggio aggiunge coordinamento. Pianificazione CPU, trasferimenti di identificatori, raccolta delle righe, gestione dei buffer e copie GPU possono costare più della lettura fisica dallo storage. Un file in cache può quindi restare indietro rispetto alla DRAM pinned anche quando nessuna richiesta raggiunge la memoria flash NAND.

I risultati su B200 hanno evidenziato questo divario. A circa 125 token al secondo per utente, la configurazione DRAM ha prodotto 121 milioni di token totali per unità di spesa. Il percorso SSD ne ha prodotti 52 milioni.

La DRAM ha quindi fornito circa 2,3 volte più token nel confronto misurato. Ha inoltre superato le configurazioni SSD osservate nell'interattività P90, che misura l'esperienza delle richieste più lente nella coda di distribuzione.

I ricercatori non hanno potuto abilitare GPUDirect Storage, o GDS, per il test. GDS può trasferire dati tra NVMe e memoria GPU con minore coinvolgimento della CPU. La sua assenza limita ciò che l'esperimento può dire di un percorso storage ottimizzato.

Il risultato non dovrebbe essere presentato come prova che NVMe non possa servire Engram. Mostra che supporti di storage economici non generano automaticamente inferenza economica.

Le quattro GPU B200 sono rimaste nel server. Così come CPU, rete, alimentazione e la maggior parte dell'infrastruttura di supporto. Sostituire la DRAM con SSD ha ridotto un requisito di capacità senza ridurre le parti costose della configurazione.

Un vantaggio economico richiede un secondo effetto. L'offloading su SSD deve consentire un server più economico, ospitare più repliche produttive, supportare un modello più grande o liberare DRAM per un altro carico di lavoro di valore.

Il prototipo non ha ottenuto nessuno di questi risultati nella configurazione misurata. La sua cache del filesystem potrebbe inoltre consumare gran parte della DRAM che il backing su file era destinato a risparmiare.

La località del carico di lavoro introduce un'altra incertezza. Un servizio stabile con prompt ripetuti potrebbe mantenere una cache calda utile. Un carico di lavoro agentico diversificato potrebbe toccare una gamma più ampia di N-grammi e generare più cache miss nello storage.

Il batching modifica nuovamente l'equazione. Più richieste possono riutilizzare righe all'interno di un batch, mentre la deduplicazione riduce i trasferimenti. Batch più grandi, però, aumentano anche i requisiti della cache KV e possono alterare la latenza.

Le sole specifiche hardware degli SSD non prevedranno il risultato. Latenza di lettura casuale, profondità della coda, comportamento del filesystem, dimensione delle pagine, overhead CPU e politica di cache contribuiscono tutti al risultato.

I sistemi di raccomandazione offrono un utile precedente storico. Da anni servono grandi tabelle di embedding da memoria a livelli. Alcuni sistemi memorizzano in cache le righe più popolari nella DRAM e collocano la coda lunga sugli SSD.

Il traffico Engram dei modelli linguistici è abbastanza simile da poter mutuare alcune idee, ma non è identico. La generazione autoregressiva impone una stretta latenza sequenziale. Un ritardo in una posizione token può bloccare le posizioni successive.

AgentX rende questa preoccupazione più evidente. Rappresenta traffico di coding agentico a contesto lungo e multi-turno, anziché un singolo breve prompt sintetico. Questi carichi alternano un'elaborazione sostanziale dell'input a una generazione sensibile alla latenza.

Il caso dello storage migliorerà solo quando il software tratterà Engram come una primitiva di serving di prima classe. Un file generico mappato in memoria è utile per la sperimentazione, ma lascia troppo lavoro nel percorso controllato dalla CPU.

Le architetture future richiedono I/O diretto, code asincrone, caching consapevole delle righe e pianificazioni di prefetch prevedibili. Potrebbero inoltre richiedere layout di storage allineati alle righe quantizzate di Engram.

NVMe resta quindi un'opportunità, non l'impostazione predefinita attuale. La DRAM ha già dimostrato che il tiering può migliorare il sistema. Gli SSD necessitano ancora di uno stack di serving progettato attorno al pattern di accesso sparso del modello.

AgentX mostra il vantaggio software attorno alle nuove architetture

Engram cambia il posizionamento della memoria, ma il supporto software al lancio determina ancora quale acceleratore possa trasformare l'architettura in un servizio utilizzabile.

SemiAnalysis ha valutato DeepSeek-V4.1-Flash su sistemi Nvidia H100, H200, B200, B300, GB200 e GB300. Ha inoltre testato MI355X di AMD tramite il framework InferenceX.

Le misurazioni di InferenceX utilizzano hardware reale e confrontano il throughput con l'interattività. AgentX fornisce un carico di lavoro di coding a contesto lungo pensato per assomigliare a sessioni ripetute orientate agli strumenti.

Secondo SemiAnalysis, il percorso vLLM di Nvidia funzionava su tutte e sei le piattaforme Nvidia testate al lancio del modello. L'immagine container di riferimento di AMD non era disponibile pubblicamente nelle prime 23 ore.

Il supporto AMD è arrivato in seguito, ma il divario iniziale di prestazioni è rimasto significativo nelle misurazioni dell'analista. Sette giorni dopo il rilascio, SemiAnalysis ha collocato le prestazioni MI355X per unità di spesa tra due e quattro volte dietro B200.

Si tratta di affermazioni sensibili al fornitore provenienti da un'unica organizzazione di benchmarking. Dipendono da ipotesi cloud, versioni runtime, quantizzazione, topologia e rapidi cambiamenti del software. Non dovrebbero essere generalizzate a ogni modello o carico di lavoro AMD.

Rivelano però un vincolo importante. Un'architettura può essere progettata per l'offloading, ma il deployment dipende ancora da kernel, graph capture, indirizzamento della memoria, quantizzazione e pianificazione distribuita.

L'offloading DeepSeek Engram richiede più di una banda PCIe adeguata. Il runtime deve sovrapporre i trasferimenti senza interrompere i grafi di decoding. Deve selezionare e dequantizzare efficientemente le righe su ciascuna piattaforma.

Un nuovo modello mette quindi alla prova un ecosistema di acceleratori prima che i team hardware abbiano mesi per ottimizzarlo. La familiarità dei manutentori e pipeline di rilascio funzionanti diventano parte delle prestazioni.

Questa dinamica rafforza la posizione software di Nvidia anche quando l'architettura del modello riduce la capacità HBM richiesta per replica. Meno GPU per replica possono ridurre la comunicazione, ma ogni GPU rimanente necessita di kernel maturi e integrazione runtime.

L'effetto sulla domanda totale di acceleratori non è lineare. Un uso migliore della memoria può ridurre il numero di GPU richieste per una replica del modello. Costi di serving inferiori possono anche espandere la domanda, rendendo economicamente sostenibili più applicazioni.

Engram potrebbe incoraggiare modelli più grandi perché la memoria condizionale scala separatamente dal calcolo attivo. Gli operatori potrebbero usare la HBM risparmiata per più sessioni concorrenti anziché acquistare meno acceleratori.

Secondo i materiali di rilascio, DeepSeek ha inoltre ridotto i requisiti della cache KV in V4.1-Flash. L'offload Engram e la compressione KV liberano memoria da due direzioni diverse.

Questa combinazione è importante per l'inferenza agentica. Gli agenti conservano lunghe cronologie, output di strumenti, codice e piani intermedi. La loro cache KV può occupare capacità significativa anche quando i pesi del modello sono già contenuti.

Un server che sposta le tabelle di lookup sparse nella DRAM può dedicare più HBM a queste sessioni attive. Il vantaggio pratico può emergere come maggiore concorrenza, non come un modello fisico più piccolo.

La visione scettica resta necessaria. La riproduzione di Engram di SemiAnalysis ha usato codice e impostazioni di addestramento rilasciati perché DeepSeek non ha pubblicato i due modelli di ricerca addestrati del paper originale. Il comportamento in produzione può differire dagli esperimenti di scaling controllati.

Il percorso SSD era esplicitamente non ottimizzato. I risultati Nvidia e AMD hanno catturato stack software iniziali che cambieranno. Persino il risultato DRAM più forte dipendeva da una specifica topologia B300 e da uno specifico fronte di carico di lavoro.

Engram conserva anche ciò che l'addestramento premia. Una maggiore capacità può preservare boilerplate e pattern incidentali insieme a entità utili o codice. Una migliore allocazione della memoria non garantisce una migliore selezione dei dati.

Le evidenze supportano una conclusione più circoscritta. La memoria condizionale è tecnicamente compatibile con livelli di memoria inferiori e la DRAM può migliorare le prestazioni complete di serving. Non stabilisce ancora una configurazione universale.

Tre segnali decideranno l'impatto di DRAM e NVMe

La fase successiva dipende dal serving SSD ottimizzato, da guadagni topologici ripetibili e da un ampio supporto runtime oltre il rilascio di un singolo modello.

Il primo segnale è un'implementazione NVMe ottimizzata che utilizzi un percorso diretto orientato alla GPU. Il confronto importante non è la banda di picco dell'SSD. È il fronte completo di throughput e interattività P90 rispetto alla DRAM pinned.

Il supporto per GPUDirect Storage eliminerebbe una parte del percorso di andata e ritorno della CPU. La deduplicazione nativa delle righe, il prefetching asincrono e layout di storage consapevoli di Engram potrebbero rimuovere ulteriore overhead.

Se un percorso ottimizzato si avvicina alle prestazioni DRAM riducendo materialmente la memoria host richiesta, l'opportunità NVMe diventerà credibile. Se l'SSD in cache resterà molto indietro, Engram rafforzerà invece la domanda di DRAM.

Il secondo segnale è se topologie di replica più piccole si ripetono su hardware e carichi di lavoro diversi. Il passaggio di SemiAnalysis sul B300 da parallelismo tensoriale a quattro vie a due vie ha prodotto il risultato più significativo.

Test indipendenti dovrebbero esaminare B200, H200, MI355X e i sistemi futuri. Dovrebbero includere diverse lunghezze di contesto, dimensioni dei batch, livelli di concorrenza e stati della cache.

Guadagni ripetuti confermerebbero che l'offload di Engram modifica l'economia dei server riducendo la comunicazione. L'incapacità di riprodurli circoscriverebbe il risultato a una sola configurazione iniziale.

Il terzo segnale è l'adozione nell'ecosistema. DeepSeek-V4.1-Flash offre un test visibile, ma una memoria simile a Engram deve diffondersi in più famiglie di modelli e motori di serving per rimodellare la domanda di hardware.

Il rapporto di SemiAnalysis indica meccanismi N-gram correlati nei modelli LongCat e Qwen. I ricercatori hanno inoltre proposto capacità Engram condivisa tramite CXL. Questi approcci necessitano di un supporto stabile in vLLM, SGLang e nei runtime dei fornitori.

Un'adozione ampia rafforzerebbe la domanda di server bilanciati, con maggiore banda DRAM, NVMe locali performanti e interconnessioni flessibili. Un'adozione limitata lascerebbe Engram come un'importante ottimizzazione specifica di DeepSeek.

Gli sviluppatori dovrebbero monitorare le configurazioni di deployment, non i titoli sui parametri. Gli acquirenti aziendali dovrebbero richiedere prestazioni alle proprie lunghezze di contesto e ai propri obiettivi di latenza. I team infrastrutturali dovrebbero misurare separatamente gli stati di cache fredda, calda e mista.

I knowledge worker sperimenteranno il risultato indirettamente. Un migliore posizionamento della memoria può supportare sessioni più lunghe, minore latenza e un accesso più ampio a modelli avanzati. Questi vantaggi contano solo quando le applicazioni complete li utilizzano in modo affidabile.

I team che valutano sistemi di IA dovrebbero conservare le proprie evidenze insieme alle affermazioni dei benchmark. Una base di conoscenza ingegneristica ricercabile può mantenere collegati model card, versioni dei runtime e risultati dei test interni.

L'offload di DeepSeek Engram non segna la fine dell'inferenza guidata da HBM. È la prova che l'architettura del modello può decidere anzitutto quali parametri meritino HBM. La prossima domanda è se NVMe ottimizzati e memoria condivisa possano replicare il risultato della DRAM senza trasferire il collo di bottiglia nel software.