La descarga de DeepSeek Engram lleva la memoria de IA más allá de HBM

La descarga de DeepSeek Engram ha trasladado 189 GiB de memoria de modelo fuera de la HBM de la GPU, y las pruebas con DRAM a veces superaron una configuración íntegramente basada en HBM. El resultado cuestiona un supuesto básico de la infraestructura para modelos grandes. La memoria más rápida no es automáticamente la mejor ubicación para cada parámetro.

SemiAnalysis publicó los nuevos experimentos el 18 de septiembre, utilizando DeepSeek-V4.1-Flash y su marco de servicio InferenceX. Sus pruebas ubicaron las tablas Engram en DRAM del host o en archivos mapeados en memoria en unidades NVMe locales. La ruta de DRAM mejoró una configuración B300 al reducir el paralelismo tensorial, mientras que la primera implementación con SSD siguió siendo más lenta y menos económica.

Esta distinción importa. Engram no elimina la demanda de GPUs Nvidia ni de memoria de alto ancho de banda. Cambia qué parámetros del modelo merecen esa capacidad escasa. Por tanto, la competencia a corto plazo no es HBM frente a SSD. Es un modelo de despliegue íntegramente en HBM frente a un sistema escalonado que asigna distintas cargas de trabajo a HBM, DRAM y almacenamiento.

La descarga de DeepSeek Engram cambia la ubicación de los parámetros

El cambio central es arquitectónico: un gran bloque de memoria aprendida puede salir de HBM sin obligar a todo el modelo a comportarse como una red neuronal descargada.

DeepSeek introdujo Engram como un módulo de memoria condicional para modelos de lenguaje. Amplía las incrustaciones ordinarias de tokens con búsquedas aprendidas para patrones recurrentes de varios tokens. Estos patrones pueden incluir nombres, fragmentos de código, texto repetitivo y expresiones relacionales comunes.

Un Transformer convencional suele reconstruir esos patrones locales mediante capas de atención y de alimentación directa. Engram proporciona al modelo una ruta de búsqueda independiente. Genera hashes de secuencias de tokens, recupera una pequeña colección de filas de incrustaciones y las combina con el estado oculto del modelo.

El artículo original sobre memoria condicional describe este enfoque como una segunda forma de dispersión. Mixture-of-Experts, o MoE, activa solo una parte del cómputo del modelo para cada token. Engram activa solo una fracción minúscula de una tabla de memoria mucho mayor.

Esta distinción determina cómo el hardware puede servir al modelo. Un experto MoE contiene matrices de pesos utilizadas para un cómputo sustancial. Mover una de ellas entre niveles de almacenamiento puede requerir transferencias grandes justo en el peor momento.

Las direcciones de Engram son diferentes. Dependen de los ID de los tokens y de su secuencia local, en lugar de un estado oculto intermedio. Un entorno de ejecución puede saber qué filas necesita antes de que las capas posteriores del modelo terminen de calcular.

Esa previsibilidad crea una ventana de precarga. El servidor puede recuperar filas de la memoria del host mientras la GPU procesa operaciones anteriores. Si la recuperación termina dentro de esa ventana, el modelo evita gran parte de la latencia normalmente asociada con la descarga.

La investigación publicada de DeepSeek escaló una tabla experimental Engram hasta 27.000 millones de parámetros. En comparaciones controladas, los autores informaron mejoras frente a una base MoE con parámetros y cómputo equivalentes. Las mejoras reportadas abarcaron conocimiento factual, razonamiento, código, matemáticas y recuperación de contexto largo.

Esas cifras procedían de modelos de investigación, no del sistema de producción exacto probado por SemiAnalysis. Aun así, explican por qué Engram no puede tratarse como metadatos opcionales. Se convierte en parte de la ruta de razonamiento del modelo entrenado.

SemiAnalysis reforzó ese punto al eliminar Engram durante la inferencia. Según su análisis, los benchmarks factuales conservaron solo entre el 29 y el 44 por ciento de su rendimiento original en la ablación del artículo anterior. La comprensión lectora conservó entre el 81 y el 93 por ciento.

Esa pérdida no demuestra que Engram supere a todos los modelos convencionales. La red fue entrenada para depender de su módulo de memoria. Eliminar ese módulo crea una desalineación entre el entrenamiento y la inferencia.

El experimento sí muestra que los operadores no pueden simplemente eliminar la tabla cuando escasea la memoria. Deben servirla eficientemente, comprimirla o ubicarla en otro lugar.

DeepSeek-V4.1-Flash concreta el problema de ubicación. DeepSeek afirma que el modelo cuenta con una arquitectura MoE de 552.000 millones de parámetros, con 8.000 millones de parámetros activos durante el procesamiento de entrada y 16.000 millones durante la generación de salida. Engram añade otro gran conjunto de memoria condicional.

El lanzamiento de V4.1-Flash también afirma que requiere una caché KV de una cuarta parte de la HBM y una octava parte del almacenamiento SSD de su predecesor. La caché KV almacena estados de atención reutilizables de tokens anteriores. Es independiente de Engram, pero ambas funciones remodelan los requisitos de memoria del servidor.

SemiAnalysis utilizó aproximadamente 189 GiB para la tabla Engram del modelo. Sin embargo, cada posición de token procesada solicitaba solo 24 filas en dos capas Engram. Eso representaba unos 12,4 KiB en todo el modelo, o 3,1 KiB por GPU en una configuración de cuatro GPUs.

La tabla es enorme, pero la lectura activa es diminuta. Esa asimetría es la razón por la que la descarga de DeepSeek Engram funciona.

La descarga a DRAM presiona el diseño íntegramente basado en HBM

Engram debilita el vínculo entre el número total de parámetros y la capacidad HBM necesaria, incluso cuando el ancho de banda de la GPU sigue siendo esencial.

HBM tiene dos propiedades valiosas para la inferencia de IA. Ofrece alto ancho de banda y se encuentra cerca del cómputo de la GPU. Estas ventajas la convierten en el lugar natural para pesos de acceso frecuente y una caché KV creciente.

Sin embargo, la capacidad sigue siendo costosa en términos de sistema. Un operador suele añadir GPUs porque un modelo no cabe, incluso cuando la carga de trabajo no necesita toda su capacidad de cómputo. Los aceleradores adicionales introducen entonces costes de comunicación y complejidad operativa.

Engram ofrece una forma de separar la capacidad del cómputo. El servidor puede mantener las capas densas, los expertos activos y el estado sensible a la latencia en HBM. Puede colocar la tabla de memoria dispersa en DRAM del host.

SemiAnalysis probó esta disposición mediante Unified Virtual Addressing, o UVA. UVA permite que una GPU direccione memoria del host fijada dentro de un único espacio de direcciones compartido. El mismo kernel de GPU seleccionó y desquantizó filas Engram desde HBM o DRAM.

No se trataba de una descarga convencional gestionada por CPU. La GPU accedía directamente a la asignación fijada del host. La ejecución asíncrona permitió que la recuperación se solapara con otro trabajo del modelo.

El resultado sorprendente apareció en la B300 de Nvidia. SemiAnalysis informó que mover Engram a DRAM permitió que su configuración pasara de paralelismo tensorial de cuatro vías a uno de dos vías.

El paralelismo tensorial divide las operaciones del modelo entre varias GPUs. Puede permitir que un modelo grande quepa, pero cada división añade sincronización y comunicación. Por ello, reducir la división puede compensar el nivel de memoria más lento.

Según la prueba, la frontera de rendimiento e interactividad de la B300 resultante mejoró hasta 1,6 veces. Devolver la tabla a HBM no produjo una mejora medible más allá de la variación entre ejecuciones en esa pila de software temprana.

Este hallazgo invierte el argumento más simple sobre la jerarquía de memoria. HBM aceleró cada búsqueda individual, pero esas búsquedas representaban solo una parte de la ruta completa de servicio. Engram consumía capacidad que de otro modo podría sostener caché KV, procesamiento por lotes o una réplica más pequeña.

La DRAM mejoró todo el sistema al cambiar su topología. El beneficio no procedía de que la DRAM superara a HBM en velocidad de acceso bruta.

Esta es la principal presión sobre el diseño de sistemas GPU. Tradicionalmente, los operadores han evaluado si un modelo cabe sumando el tamaño del checkpoint, el estado de ejecución y un margen de seguridad. Engram exige clasificar la memoria según su patrón de acceso.

Los pesos calientes, densos e intensivos en ancho de banda siguen favoreciendo HBM. Las filas dispersas predecibles pueden tolerar DRAM cuando el cómputo oculta la transferencia. Las filas de larga cola podrían acabar en NVMe, siempre que la caché y la sobrecarga de software permanezcan controladas.

El cambio tiene implicaciones para los proveedores de memoria. Engram no pone fin a la demanda de HBM. Los experimentos de SemiAnalysis sugieren, en cambio, que el ancho de banda puede importar más que la capacidad HBM máxima para algunas configuraciones de inferencia.

Al mismo tiempo, la DRAM del servidor pasa a formar parte de la envolvente de rendimiento del servicio de modelos. La planificación de capacidad debe considerar asignaciones fijadas, canales de memoria, comportamiento de PCIe y contención entre réplicas.

NVMe también obtiene un papel potencial más allá de almacenar checkpoints y caché KV. Su mercado direccionable crece si los parámetros del modelo pasan a servirse activamente desde almacenamiento local. Sin embargo, esa oportunidad depende de que el software haga económicamente útiles las lecturas de almacenamiento.

Los ganadores inmediatos no son necesariamente los proveedores que venden el mayor conjunto de memoria. Son los sistemas que coordinan varios niveles sin detener aceleradores costosos.

Para los compradores de infraestructura de IA, el tamaño total del modelo se convierte en una señal de compra menos útil. Los parámetros activos, los bytes recuperados por token, la distancia de precarga y la topología de réplicas ofrecen una orientación más útil.

Un sistema de 748.000 millones de parámetros puede imponer requisitos de hardware muy distintos a los de un modelo denso de tamaño similar. DeepSeek-V4.1-Flash combina una arquitectura dispersa con memoria condicional y una caché KV reducida. Cada parte somete a presión un recurso diferente.

Esa complejidad también dificulta las comparaciones. Un benchmark que mide únicamente tokens por segundo puede ocultar la latencia en niveles de concurrencia individuales. Un resultado de costes puede cambiar cuando una configuración añade GPUs únicamente por capacidad de memoria.

La comparación más útil relaciona el rendimiento con la interactividad visible para el usuario. Después pregunta cuánto trabajo útil produce cada servidor completo, no con qué rapidez se ejecuta un kernel aislado.

Por qué Engram funciona fuera de la memoria de la GPU

El direccionamiento determinista da al entorno de ejecución tiempo para recuperar memoria, mientras que el acceso disperso mantiene cada transferencia lo bastante pequeña como para solaparse con el cómputo.

Engram comienza con N-grams, que son secuencias cortas de tokens adyacentes. La arquitectura comprime el vocabulario del tokenizador, genera hashes de secuencias locales mediante múltiples cabezas y asigna esos hashes a filas aprendidas.

La compresión del vocabulario importa porque los tokenizadores suelen asignar distintos ID a texto visualmente similar. Las mayúsculas, el espaciado y las formas Unicode pueden fragmentar patrones repetidos. El artículo informa de una reducción del 23 por ciento en el vocabulario efectivo para un vocabulario de 128.000 tokens.

Las incrustaciones recuperadas no entran al modelo sin cambios. Una compuerta consciente del contexto controla cuánto influye cada búsqueda en el estado oculto actual. Una convolución ligera añade contexto cercano antes de que la contribución de memoria llegue a capas posteriores.

Este diseño ayuda a explicar tanto el valor como las limitaciones de Engram. La tabla almacena patrones estadísticos reutilizables, pero el modelo aún decide cuánto utilizarlos. No es una base de datos convencional que contenga registros factuales limpios.

SemiAnalysis examinó patrones de compuerta alta en DeepSeek-V4.1-Flash. Encontró nombres, fragmentos de código, formulaciones relacionales, licencias, fragmentos bibliográficos y texto repetitivo web. Un ejemplo inusual hacía referencia a la serie de juegos Ace Attorney.

Estos resultados sugieren que la tabla optimiza la predicción del siguiente token, no los juicios humanos sobre conocimiento valioso. El formato repetido puede resultar útil si proporciona un atajo de predicción.

Este hallazgo complica la caché. Una compuerta fuerte no identifica necesariamente una fila a la que se accede con frecuencia. Una fila puede tener gran valor cuando se recupera, pero aparecer raramente en el tráfico de producción.

El entorno de ejecución tampoco puede evitar todas las búsquedas débiles después de ver su compuerta. Calcular la compuerta requiere la clave correspondiente, que ya ha activado la recuperación. Omitir esa lectura requeriría un predictor independiente que opere antes del acceso a memoria.

La frecuencia de acceso debería seguir una distribución de cola larga. Las palabras comunes, los patrones de programación y la sintaxis rutinaria deberían aparecer con más frecuencia que las entidades poco comunes. Esto hace plausible una caché multinivel.

Las filas solicitadas con frecuencia podrían permanecer en HBM. Un conjunto de trabajo mayor podría mantenerse en la DRAM del host. Las filas poco comunes podrían residir en NVMe y pasar a niveles más rápidos cuando el tráfico las vuelva útiles.

La investigación sobre memoria CXL extiende la misma idea más allá de la DRAM conectada directamente a un único servidor. Sus autores proponen agrupar la memoria Engram mediante Compute Express Link, que admite acceso granular a dispositivos de memoria compartida.

La propuesta sigue siendo investigación, no una demostración de viabilidad económica en producción. CXL añade sus propias consideraciones de latencia, topología y software. Aun así, ilustra cómo la memoria condicional modifica los límites del sistema.

Un operador podría escalar el conjunto de búsquedas por separado del cómputo GPU. Varios aceleradores podrían compartir capacidad en lugar de duplicar la tabla completa dentro de cada réplica de GPU.

La precarga es el mecanismo central en todos estos diseños. Las capas Engram no pueden ubicarse arbitrariamente al principio si es necesario ocultar la latencia de almacenamiento. Más cómputo previo crea una ventana más larga para la recuperación.

La calidad del modelo puede empujar en la dirección contraria. La intervención temprana de la memoria ayuda a la red a evitar gastar sus primeras capas reconstruyendo patrones locales comunes. Colocar Engram demasiado tarde puede debilitar esa ventaja.

Esto genera un verdadero problema de codiseño. Los investigadores de modelos eligen las capas de inserción, las dimensiones de las tablas, el comportamiento del hashing y las compuertas. Los ingenieros de runtime diseñan colas de precarga, cachés, kernels y rutas de transferencia en torno a esas decisiones.

Después, los equipos de hardware deciden cuánto ancho de banda y capacidad debe proporcionar cada nivel. Ninguna de estas decisiones puede optimizarse de forma independiente.

El artículo de DeepSeek informó una relación en forma de U entre los parámetros asignados al cómputo MoE y los parámetros asignados a la memoria Engram. Demasiada poca memoria dejaba los patrones repetidos en la red neuronal principal. Demasiada memoria reducía el cómputo disponible para otras tareas.

Ese resultado desaconseja tratar Engram como una capacidad barata e ilimitada. Más filas en la tabla pueden mejorar la pérdida de validación, pero solo dentro de un sistema equilibrado. La calidad de los datos de entrenamiento también determina qué aprenden esas filas.

La implicación arquitectónica más amplia es importante. Escalar ya no significa colocar cada nuevo parámetro junto a la aritmética de la GPU. Un modelo puede añadir capacidad mediante recuperación dispersa y predecible, mientras reserva el costoso ancho de banda para el cómputo dinámico.

La descarga a SSD aún no es la opción barata

El primer experimento con NVMe ahorró capacidad de DRAM comprometida, pero su ruta de datos sin optimizar quedó por detrás de la DRAM fijada tanto en velocidad como en eficiencia.

SemiAnalysis sustituyó la asignación de 189 GiB de Engram por archivos mapeados en memoria en SSD locales. Un archivo mapeado en memoria permite al sistema operativo exponer el almacenamiento mediante páginas de memoria virtual. Las páginas a las que se accedió recientemente pueden permanecer en la caché del sistema de archivos.

Este enfoque ofrece flexibilidad operativa. El sistema operativo puede recuperar páginas en caché cuando otras aplicaciones necesitan memoria. Los operadores evitan fijar permanentemente la tabla Engram completa en DRAM.

Sin embargo, una caché de páginas caliente no hace que la ruta SSD sea equivalente a una descarga nativa a DRAM. El prototipo seguía trasladando los identificadores de filas a la CPU, eliminando duplicados, reuniendo filas en búferes fijados y copiándolas de vuelta.

Después desquantizaba las filas seleccionadas en la GPU. Estos pasos se ejecutaban entre segmentos de la ejecución de la GPU, en lugar de mediante el kernel UVA directo utilizado para la memoria del host fijada.

Cada paso añade coordinación. La planificación de CPU, las transferencias de identificadores, la recopilación de filas, la gestión de búferes y las copias a la GPU pueden costar más que la lectura física del almacenamiento. Por tanto, un archivo en caché puede quedar por detrás de la DRAM fijada incluso cuando ninguna solicitud llega a la memoria flash NAND.

Los resultados de B200 expusieron esa brecha. Con cerca de 125 tokens por segundo para cada usuario, la configuración de DRAM produjo 121 millones de tokens totales por unidad de gasto. La ruta SSD produjo 52 millones.

Por tanto, la DRAM entregó aproximadamente 2,3 veces más tokens en esa comparación medida. También superó a las configuraciones SSD observadas en interactividad P90, que mide la experiencia de las solicitudes más lentas cerca de la cola.

Los investigadores no pudieron habilitar GPUDirect Storage, o GDS, para la prueba. GDS puede mover datos entre NVMe y la memoria GPU con menor participación de la CPU. Su ausencia limita lo que el experimento puede decir sobre una ruta de almacenamiento optimizada.

El resultado no debe presentarse como prueba de que NVMe no puede servir a Engram. Muestra que un medio de almacenamiento barato no crea automáticamente una inferencia barata.

Las cuatro GPU B200 permanecieron en el servidor. También la CPU, la red, la alimentación y la mayor parte de la infraestructura de soporte. Sustituir DRAM por SSD redujo un requisito de capacidad sin reducir las partes costosas de la configuración.

Una ganancia económica exige un segundo efecto. La descarga a SSD debe permitir un servidor más barato, alojar más réplicas productivas, admitir un modelo más grande o liberar DRAM para otra carga de trabajo valiosa.

El prototipo no logró ninguno de esos resultados en su configuración medida. Su caché del sistema de archivos también podría consumir gran parte de la DRAM que el respaldo mediante archivos pretendía ahorrar.

La localidad de la carga de trabajo genera otra incertidumbre. Un servicio estable con prompts repetidos podría mantener una caché caliente útil. Una carga de trabajo diversa de agentes podría tocar una gama más amplia de N-gramas y producir más fallos de almacenamiento.

El procesamiento por lotes vuelve a cambiar la ecuación. Varias solicitudes pueden reutilizar filas dentro de un lote, mientras que la deduplicación reduce las transferencias. Sin embargo, los lotes más grandes también aumentan los requisitos de caché KV y pueden alterar la latencia.

Las especificaciones del hardware SSD por sí solas no predecirán el resultado. La latencia de lectura aleatoria, la profundidad de cola, el comportamiento del sistema de archivos, el tamaño de página, la sobrecarga de CPU y la política de caché contribuyen al resultado.

Los sistemas de recomendación ofrecen un precedente histórico útil. Han servido grandes tablas de embeddings desde memoria por niveles durante años. Algunos sistemas almacenan en caché las filas populares en DRAM mientras colocan la cola larga en SSD.

El tráfico de Engram en modelos de lenguaje es lo bastante similar como para aprovechar esas ideas, pero no es idéntico. La generación autorregresiva impone una latencia secuencial estricta. Un retraso en una posición de token puede bloquear las posiciones posteriores.

AgentX hace más visible esta preocupación. Representa tráfico de programación agéntica de contexto largo y múltiples turnos, en lugar de un único prompt sintético corto. Estas cargas de trabajo alternan un procesamiento de entrada considerable con una generación sensible a la latencia.

El caso del almacenamiento mejorará solo cuando el software trate Engram como una primitiva de servicio de primera clase. Un archivo genérico mapeado en memoria resulta útil para experimentar, pero deja demasiado trabajo en la ruta controlada por la CPU.

Los diseños futuros necesitan E/S directa, colas asíncronas, caché consciente de filas y calendarios de precarga predecibles. También pueden requerir diseños de almacenamiento alineados con las filas cuantizadas de Engram.

Por tanto, NVMe sigue siendo una oportunidad y no la opción predeterminada actual. La DRAM ya ha demostrado que la organización por niveles puede mejorar el sistema. El SSD todavía necesita una pila de servicio diseñada en torno al patrón de acceso disperso del modelo.

AgentX muestra la barrera de software en torno a nuevas arquitecturas

Engram modifica la ubicación de la memoria, pero el soporte de software desde el día de lanzamiento sigue determinando qué acelerador puede convertir la arquitectura en un servicio utilizable.

SemiAnalysis evaluó DeepSeek-V4.1-Flash en sistemas Nvidia H100, H200, B200, B300, GB200 y GB300. También probó MI355X de AMD mediante el framework InferenceX.

Las mediciones de InferenceX utilizan hardware real y comparan el rendimiento con la interactividad. AgentX aporta una carga de trabajo de programación de contexto largo diseñada para parecerse a sesiones repetidas orientadas a herramientas.

Según SemiAnalysis, la ruta vLLM de Nvidia funcionó en las seis plataformas Nvidia probadas cuando se lanzó el modelo. La imagen de contenedor referenciada de AMD no estuvo disponible públicamente durante las primeras 23 horas.

El soporte de AMD llegó después, pero la brecha inicial de rendimiento siguió siendo significativa en las mediciones del analista. Siete días después del lanzamiento, SemiAnalysis situó el rendimiento del MI355X por unidad de gasto entre dos y cuatro veces por detrás del B200.

Son afirmaciones sensibles al proveedor procedentes de una sola organización de benchmarking. Dependen de supuestos de nube, versiones de runtime, cuantización, topología y cambios rápidos de software. No deberían generalizarse a todos los modelos ni a todas las cargas de trabajo de AMD.

Sí revelan una restricción importante. Una arquitectura puede diseñarse para descarga, pero el despliegue sigue dependiendo de kernels, captura de grafos, direccionamiento de memoria, cuantización y planificación distribuida.

La descarga de DeepSeek Engram necesita más que un ancho de banda PCIe adecuado. El runtime debe solapar transferencias sin romper los grafos de decodificación. Debe seleccionar y desquantizar filas eficientemente en cada plataforma.

Por tanto, un modelo nuevo pone a prueba un ecosistema de aceleradores antes de que los equipos de hardware tengan meses para ajustarlo. La familiaridad de los mantenedores y los canales de lanzamiento operativos pasan a formar parte del rendimiento.

Esta dinámica refuerza la posición de software de Nvidia incluso cuando la arquitectura del modelo reduce la capacidad HBM necesaria por réplica. Menos GPU por réplica pueden reducir la comunicación, pero cada GPU restante necesita kernels maduros e integración con el runtime.

El efecto sobre la demanda total de aceleradores no es directo. Un mejor uso de la memoria puede reducir el número de GPU necesarias para una réplica de modelo. Unos costes de servicio más bajos también pueden ampliar la demanda al hacer económicamente viables más aplicaciones.

Engram podría fomentar modelos más grandes porque la memoria condicional escala por separado del cómputo activo. Los operadores podrían utilizar la HBM ahorrada para más sesiones simultáneas en lugar de comprar menos aceleradores.

DeepSeek también ha reducido los requisitos de caché KV en V4.1-Flash, según sus materiales de lanzamiento. La descarga de Engram y la compresión de KV liberan memoria desde dos direcciones distintas.

Esa combinación importa para la inferencia agéntica. Los agentes acumulan historiales largos, salidas de herramientas, código y planes intermedios. Su caché KV puede ocupar una capacidad considerable incluso cuando los pesos del modelo ya caben.

Un servidor que mueve tablas de búsqueda dispersa a DRAM puede dedicar más HBM a esas sesiones activas. El beneficio práctico puede aparecer como mayor concurrencia, no como un modelo físico más pequeño.

La visión escéptica sigue siendo necesaria. La reproducción de Engram de SemiAnalysis utilizó código y configuraciones de entrenamiento publicados porque DeepSeek no lanzó los dos modelos de investigación entrenados del artículo original. El comportamiento en producción puede diferir de los experimentos controlados de escalado.

La ruta SSD no estaba optimizada de forma explícita. Los resultados de Nvidia y AMD capturaron pilas de software iniciales que cambiarán. Incluso el resultado más sólido con DRAM dependía de una topología B300 y una frontera de carga de trabajo específicas.

Engram también almacena aquello que el entrenamiento recompensa. Una mayor capacidad puede preservar texto repetitivo y patrones incidentales junto con entidades o código útiles. Una mejor asignación de memoria no garantiza una mejor selección de datos.

La evidencia respalda una conclusión más acotada. La memoria condicional es técnicamente compatible con niveles de memoria más baratos, y la DRAM puede mejorar el rendimiento completo del servicio. Aún no establece una configuración universal.

Tres señales decidirán el impacto de DRAM y NVMe

La siguiente fase depende de un servicio SSD optimizado, ganancias de topología repetibles y un amplio soporte de runtime más allá de un único lanzamiento de modelo.

La primera señal es una implementación NVMe optimizada que utilice una ruta directa orientada a GPU. La comparación importante no es el ancho de banda máximo del SSD. Es la frontera completa de rendimiento e interactividad P90 frente a la DRAM fijada.

El soporte para GPUDirect Storage eliminaría parte del recorrido de ida y vuelta por la CPU. La deduplicación nativa de filas, la precarga asíncrona y los diseños de almacenamiento conscientes de Engram podrían eliminar aún más sobrecarga.

Si una ruta optimizada se acerca al rendimiento de la DRAM mientras reduce de forma significativa la memoria del host necesaria, la oportunidad de NVMe será creíble. Si el SSD en caché sigue muy por detrás, Engram reforzará en cambio la demanda de DRAM.

La segunda señal es si las topologías de réplicas más pequeñas se repiten en distintos tipos de hardware y cargas de trabajo. El cambio de SemiAnalysis en B300, de paralelismo tensorial de cuatro vías a dos vías, produjo el resultado más relevante.

Las pruebas independientes deberían examinar B200, H200, MI355X y sistemas futuros. Deberían incluir distintas longitudes de contexto, tamaños de lote, niveles de concurrencia y estados de caché.

Las mejoras repetidas confirmarían que la descarga de Engram transforma la economía de los servidores al reducir la comunicación. Si no se reprodujeran, el hallazgo quedaría limitado a una configuración inicial concreta.

La tercera señal es la adopción en el ecosistema. DeepSeek-V4.1-Flash ofrece una prueba visible, pero una memoria similar a Engram debe extenderse a más familias de modelos y motores de servicio para transformar la demanda de hardware.

El informe de SemiAnalysis señala mecanismos relacionados de N-gramas en los modelos LongCat y Qwen. Los investigadores también han propuesto capacidad Engram agrupada mediante CXL. Estos enfoques necesitan soporte estable en vLLM, SGLang y los runtimes de los proveedores.

Una adopción amplia reforzaría la demanda de servidores equilibrados con mayor ancho de banda de DRAM, NVMe local capaz e interconexiones flexibles. Una adopción limitada dejaría a Engram como una optimización importante específica de DeepSeek.

Los desarrolladores deberían seguir las recetas de implementación, no los titulares sobre parámetros. Los compradores empresariales deberían solicitar rendimiento con sus propias longitudes de contexto y objetivos de latencia. Los equipos de infraestructura deberían medir por separado los estados de caché frío, cálido y mixto.

Los trabajadores del conocimiento experimentarán el resultado de forma indirecta. Una mejor ubicación de la memoria puede permitir sesiones más largas, menor latencia y un acceso más amplio a modelos capaces. Esos beneficios solo importan cuando las aplicaciones completas los utilizan de forma fiable.

Los equipos que evalúan sistemas de IA deberían conservar sus propias evidencias junto con las afirmaciones de los benchmarks. Una base de conocimientos de ingeniería con búsqueda puede mantener conectadas las tarjetas de modelo, las versiones de los runtimes y los resultados de pruebas internas.

La descarga de DeepSeek Engram no supone el fin de la inferencia liderada por HBM. Es una prueba de que la arquitectura del modelo puede determinar, en primer lugar, qué parámetros merecen HBM. La siguiente pregunta es si NVMe optimizado y memoria compartida pueden repetir el resultado de la DRAM sin trasladar el cuello de botella al software.