O Offloading do DeepSeek Engram Leva a Memória de IA Além da HBM
O offloading do DeepSeek Engram deslocou 189 GiB de memória do modelo para fora da HBM da GPU, com testes em DRAM superando, em alguns casos, uma configuração inteiramente baseada em HBM. O resultado questiona uma premissa básica da infraestrutura para grandes modelos. A memória mais rápida não é automaticamente o melhor local para todos os parâmetros.
A SemiAnalysis publicou os novos experimentos em 18 de setembro, usando o DeepSeek-V4.1-Flash e seu framework de serving InferenceX. Seus testes colocaram tabelas Engram em DRAM do host ou em arquivos mapeados em memória em unidades NVMe locais. O caminho via DRAM melhorou uma configuração B300 ao reduzir o paralelismo de tensor, enquanto a primeira implementação com SSD permaneceu mais lenta e menos econômica.
Essa distinção importa. O Engram não elimina a demanda por GPUs Nvidia ou memória de alta largura de banda. Ele muda quais parâmetros do modelo merecem essa capacidade escassa. A disputa de curto prazo, portanto, não é HBM versus SSD. Trata-se de um modelo de implantação inteiramente em HBM versus um sistema em camadas que atribui diferentes cargas de trabalho à HBM, à DRAM e ao armazenamento.
O Offloading do DeepSeek Engram Muda a Alocação de Parâmetros
A mudança central é arquitetural: um grande bloco de memória aprendida pode sair da HBM sem obrigar todo o modelo a se comportar como uma rede neural com offloading.
A DeepSeek apresentou o Engram como um módulo de memória condicional para modelos de linguagem. Ele amplia embeddings de tokens comuns com consultas aprendidas para padrões recorrentes de múltiplos tokens. Esses padrões podem incluir nomes, fragmentos de código, texto padronizado e expressões relacionais frequentes.
Um Transformer convencional frequentemente reconstrói esses padrões locais por meio de camadas de atenção e feed-forward. O Engram oferece ao modelo um caminho de consulta separado. Ele aplica hash a sequências de tokens, recupera uma pequena coleção de linhas de embeddings e as combina com o estado oculto do modelo.
O artigo original sobre memória condicional descreve essa abordagem como uma segunda forma de esparsidade. Mixture-of-Experts, ou MoE, ativa apenas parte da computação do modelo para cada token. O Engram ativa apenas uma fração minúscula de uma tabela de memória muito maior.
Essa distinção determina como o hardware pode servir o modelo. Um especialista MoE contém matrizes de pesos usadas para computação substancial. Movê-lo entre camadas de armazenamento pode exigir grandes transferências exatamente no momento errado.
Os endereços do Engram são diferentes. Eles dependem dos IDs dos tokens e de sua sequência local, em vez de um estado oculto intermediário. Um runtime pode saber quais linhas precisa antes que as camadas posteriores do modelo terminem de calcular.
Essa previsibilidade cria uma janela de pré-busca. O servidor pode recuperar linhas da memória do host enquanto a GPU executa operações anteriores. Se a recuperação terminar nessa janela, o modelo evita boa parte da latência normalmente associada ao offloading.
A pesquisa publicada pela DeepSeek escalou uma tabela experimental Engram para 27 bilhões de parâmetros. Em comparações controladas, os autores relataram ganhos sobre uma linha de base MoE com parâmetros e computação equivalentes. As melhorias reportadas abrangeram conhecimento factual, raciocínio, código, matemática e recuperação em contexto longo.
Esses números vieram de modelos de pesquisa, não do sistema de produção exato testado pela SemiAnalysis. Ainda assim, explicam por que o Engram não pode ser tratado como metadado opcional. Ele passa a integrar o caminho de raciocínio do modelo treinado.
A SemiAnalysis reforçou esse ponto ao remover o Engram durante a inferência. Segundo sua análise, os benchmarks factuais retiveram apenas 29% a 44% de seu desempenho original na ablação do artigo anterior. A compreensão de leitura reteve de 81% a 93%.
Essa perda não prova que o Engram supera todos os modelos convencionais. A rede foi treinada para depender de seu módulo de memória. Remover esse módulo cria uma incompatibilidade entre treinamento e inferência.
O experimento mostra, contudo, que os operadores não podem simplesmente excluir a tabela quando a memória se torna limitada. Eles precisam servi-la com eficiência, comprimi-la ou colocá-la em outro local.
O DeepSeek-V4.1-Flash torna concreto o problema de alocação. A DeepSeek afirma que o modelo tem uma espinha dorsal MoE de 552 bilhões de parâmetros, com 8 bilhões de parâmetros ativos durante o processamento de entrada e 16 bilhões durante a geração de saída. O Engram adiciona outro grande conjunto de memória condicional.
O lançamento do V4.1-Flash também afirma que o cache KV requer um quarto da HBM e um oitavo do armazenamento SSD de seu antecessor. O cache KV armazena estados de atenção reutilizáveis de tokens anteriores. Ele é separado do Engram, mas ambos os recursos remodelam os requisitos de memória do servidor.
A SemiAnalysis usou aproximadamente 189 GiB para a tabela Engram do modelo. Ainda assim, cada posição de token processada solicitava apenas 24 linhas em duas camadas Engram. Isso representava cerca de 12,4 KiB em todo o modelo, ou 3,1 KiB por GPU em uma configuração com quatro GPUs.
A tabela é enorme, mas a leitura ativa é minúscula. Essa assimetria é o motivo pelo qual o offloading do DeepSeek Engram funciona.
O Offloading para DRAM Pressiona o Design Inteiramente em HBM
O Engram enfraquece a ligação entre a contagem total de parâmetros e a capacidade de HBM necessária, mesmo quando a largura de banda da GPU continua essencial.
A HBM tem duas propriedades valiosas para a inferência de IA. Ela oferece alta largura de banda e fica próxima à computação da GPU. Essas vantagens fazem dela o local natural para pesos acessados com frequência e para um cache KV crescente.
A capacidade continua cara em termos de sistema, no entanto. Um operador muitas vezes adiciona GPUs porque um modelo não cabe, mesmo quando a carga de trabalho não exige toda a sua capacidade computacional. Os aceleradores extras então introduzem custos de comunicação e complexidade operacional.
O Engram oferece uma forma de separar capacidade e computação. O servidor pode manter camadas densas, especialistas ativos e estado sensível à latência na HBM. Pode colocar a tabela de memória esparsa na DRAM do host.
A SemiAnalysis testou esse arranjo por meio de Unified Virtual Addressing, ou UVA. O UVA permite que uma GPU enderece memória do host fixada em um único espaço de endereços compartilhado. O mesmo kernel da GPU selecionou e desquantizou linhas Engram a partir de HBM ou DRAM.
Não se tratava de offloading comum gerenciado pela CPU. A GPU acessava diretamente a alocação fixada no host. A execução assíncrona permitiu sobrepor a recuperação a outro trabalho do modelo.
O resultado surpreendente surgiu na B300 da Nvidia. A SemiAnalysis relatou que mover o Engram para a DRAM permitiu que sua configuração passasse de paralelismo de tensor em quatro vias para duas vias.
O paralelismo de tensor divide operações do modelo entre várias GPUs. Ele pode fazer um modelo grande caber, mas cada divisão adiciona sincronização e comunicação. Reduzir essa divisão pode, portanto, compensar a camada de memória mais lenta.
Segundo o teste, a fronteira de throughput e interatividade da B300 resultante melhorou em até 1,6 vez. Mover a tabela de volta para a HBM não trouxe uma melhoria mensurável além da variação entre execuções naquela pilha de software inicial.
Essa descoberta inverte o argumento mais simples da hierarquia de memória. A HBM tornou cada consulta individual mais rápida, mas essas consultas representavam apenas uma parte do caminho completo de serving. O Engram consumia capacidade que poderia, de outro modo, sustentar cache KV, batching ou uma réplica menor.
A DRAM melhorou o sistema como um todo ao mudar sua topologia. O benefício não veio da DRAM superar a HBM em velocidade bruta de acesso.
Essa é a principal pressão sobre o design de sistemas com GPU. Tradicionalmente, os operadores avaliam se um modelo cabe somando o tamanho do checkpoint, o estado de runtime e uma margem de segurança. O Engram exige que classifiquem a memória segundo o padrão de acesso.
Pesos quentes, densos e intensivos em largura de banda continuam favorecendo a HBM. Linhas esparsas previsíveis podem tolerar a DRAM quando a computação esconde a transferência. Linhas de cauda longa podem eventualmente ficar em NVMe, desde que o cache e a sobrecarga de software permaneçam controlados.
A mudança tem implicações para fornecedores de memória. O Engram não encerra a demanda por HBM. Os experimentos da SemiAnalysis sugerem, em vez disso, que a largura de banda pode importar mais do que a capacidade máxima de HBM para algumas configurações de inferência.
Ao mesmo tempo, a DRAM do servidor passa a fazer parte do envelope de desempenho do serving de modelos. O planejamento de capacidade deve considerar alocações fixadas, canais de memória, comportamento do PCIe e contenção entre réplicas.
O NVMe também ganha um possível papel além de armazenar checkpoints e cache KV. Seu mercado endereçável cresce se parâmetros de modelos passarem a ser servidos ativamente a partir do armazenamento local. Essa oportunidade, porém, depende de o software tornar as leituras de armazenamento economicamente úteis.
Os vencedores imediatos não são necessariamente os fornecedores que vendem o maior pool de memória. São os sistemas que coordenam várias camadas sem paralisar aceleradores caros.
Para compradores de infraestrutura de IA, o tamanho total do modelo se torna um sinal de aquisição menos útil. Parâmetros ativos, bytes recuperados por token, distância de pré-busca e topologia de réplicas oferecem orientações mais úteis.
Um sistema de 748 bilhões de parâmetros pode impor requisitos de hardware muito diferentes de um modelo denso de tamanho semelhante. O DeepSeek-V4.1-Flash combina uma espinha dorsal esparsa com memória condicional e um cache KV reduzido. Cada parte pressiona um recurso diferente.
Essa complexidade também torna as comparações mais difíceis. Um benchmark que mede apenas tokens por segundo pode ocultar a latência em níveis individuais de concorrência. Um resultado de custo pode mudar quando uma configuração adiciona GPUs exclusivamente para capacidade de memória.
A comparação mais útil mapeia o throughput em relação à interatividade visível ao usuário. Em seguida, pergunta quanto trabalho útil cada servidor completo produz, e não com que rapidez um kernel isolado é executado.
Por Que o Engram Funciona Fora da Memória da GPU
O endereçamento determinístico dá ao runtime tempo para buscar memória, enquanto o acesso esparso mantém cada transferência pequena o bastante para se sobrepor à computação.
O Engram começa com N-grams, que são sequências curtas de tokens adjacentes. A arquitetura comprime o vocabulário do tokenizador, aplica hash a sequências locais por meio de múltiplas cabeças e mapeia esses hashes para linhas aprendidas.
A compressão de vocabulário importa porque tokenizadores frequentemente atribuem IDs diferentes a textos visualmente semelhantes. Capitalização, espaçamento e formas Unicode podem fragmentar padrões repetidos. O artigo relata uma redução de 23% no vocabulário efetivo para um vocabulário de 128.000 tokens.
Os embeddings recuperados não entram no modelo sem alterações. Um gate sensível ao contexto controla quanto cada consulta influencia o estado oculto atual. Uma convolução leve adiciona contexto próximo antes que a contribuição de memória alcance camadas posteriores.
Esse design ajuda a explicar tanto o valor quanto as limitações do Engram. A tabela armazena padrões estatísticos reutilizáveis, mas o modelo ainda decide quanto usá-los. Ela não é um banco de dados convencional contendo registros factuais limpos.
A SemiAnalysis examinou padrões de gate alto no DeepSeek-V4.1-Flash. Encontrou nomes, fragmentos de código, redação relacional, licenças, fragmentos bibliográficos e texto padronizado da web. Um exemplo incomum fazia referência à série de jogos Ace Attorney.
Esses resultados sugerem que a tabela otimiza a previsão do próximo token, e não julgamentos humanos sobre conhecimento valioso. Formatação repetida pode se tornar útil se fornecer um atalho de previsão.
Essa descoberta complica o cache. Um gate forte não identifica necessariamente uma linha acessada com frequência. Uma linha pode ter alto valor quando recuperada, mas aparecer raramente no tráfego de produção.
O runtime também não pode evitar todas as consultas fracas depois de observar seu gate. Calcular o gate exige a chave correspondente, que já acionou a recuperação. Ignorar essa leitura exigiria um preditor separado que opere antes do acesso à memória.
A frequência de acesso ainda deve seguir uma distribuição de cauda longa. Palavras comuns, padrões de programação e sintaxe rotineira devem aparecer com mais frequência do que entidades raras. Isso torna plausível um cache multinível.
As linhas solicitadas com frequência poderiam permanecer na HBM. Um conjunto de trabalho maior poderia ficar na DRAM do host. Linhas raras poderiam residir em NVMe e entrar em níveis mais rápidos à medida que o tráfego as torna úteis.
A pesquisa sobre memória CXL estende a mesma ideia além da DRAM diretamente conectada a um único servidor. Seus autores propõem agrupar a memória Engram por meio do Compute Express Link, que oferece suporte a acesso granular a dispositivos de memória compartilhada.
A proposta continua sendo pesquisa, não uma prova da viabilidade econômica em produção. O CXL adiciona suas próprias considerações de latência, topologia e software. Ainda assim, ela ilustra como a memória condicional altera os limites do sistema.
Um operador poderia escalar o pool de consultas separadamente da computação em GPU. Vários aceleradores poderiam compartilhar capacidade em vez de duplicar a tabela inteira dentro de cada réplica de GPU.
A pré-busca é o mecanismo central nesses projetos. As camadas Engram não podem ficar arbitrariamente cedo se for necessário ocultar a latência de armazenamento. Mais computação precedente cria uma janela maior para recuperação.
A qualidade do modelo pode puxar na direção oposta. A intervenção precoce da memória ajuda a rede a evitar gastar suas primeiras camadas reconstruindo padrões locais comuns. Posicionar o Engram tarde demais pode enfraquecer esse benefício.
Isso cria um problema real de codesign. Pesquisadores de modelos escolhem camadas de inserção, dimensões de tabela, comportamento de hashing e gates. Engenheiros de runtime projetam filas de pré-busca, cache, kernels e caminhos de transferência em torno dessas escolhas.
As equipes de hardware então decidem quanta largura de banda e capacidade cada nível deve fornecer. Nenhuma dessas decisões pode ser otimizada de forma independente.
O artigo da DeepSeek relatou uma relação em forma de U entre os parâmetros alocados à computação MoE e os parâmetros alocados à memória Engram. Pouca memória deixava padrões repetidos para o backbone neural. Memória demais reduzia a computação disponível para outras tarefas.
Esse resultado desaconselha tratar o Engram como capacidade barata ilimitada. Mais linhas na tabela podem melhorar a perda de validação, mas apenas dentro de um sistema equilibrado. A qualidade dos dados de treinamento também determina o que essas linhas aprendem.
A implicação arquitetural mais ampla é importante. Escalar já não significa colocar cada novo parâmetro ao lado da aritmética da GPU. Um modelo pode adicionar capacidade por meio de recuperação esparsa previsível, enquanto reserva largura de banda cara para computação dinâmica.
O Offloading para SSD Ainda Não É a Resposta Barata
O primeiro experimento com NVMe economizou capacidade de DRAM comprometida, mas seu caminho de dados não otimizado perdeu para a DRAM fixada tanto em velocidade quanto em eficiência.
A SemiAnalysis substituiu a alocação de 189 GiB de Engram por arquivos mapeados em memória em SSDs locais. Um arquivo mapeado em memória permite que o sistema operacional exponha o armazenamento por meio de páginas de memória virtual. Páginas acessadas recentemente podem permanecer no cache do sistema de arquivos.
Essa abordagem oferece flexibilidade operacional. O sistema operacional pode recuperar páginas em cache quando outros aplicativos precisam de memória. Os operadores evitam fixar permanentemente a tabela Engram completa na DRAM.
No entanto, um cache de páginas aquecido não torna o caminho via SSD equivalente ao offload nativo para DRAM. O protótipo ainda transferia identificadores de linhas para a CPU, removia duplicatas, reunia linhas em buffers fixados e as copiava de volta.
Em seguida, desquantizava as linhas selecionadas na GPU. Essas etapas eram executadas entre segmentos de execução da GPU, em vez de pelo kernel UVA direto usado para memória do host fixada.
Cada etapa adiciona coordenação. Agendamento da CPU, transferências de identificadores, coleta de linhas, gerenciamento de buffers e cópias para a GPU podem custar mais do que a leitura física do armazenamento. Assim, um arquivo em cache pode ficar atrás da DRAM fixada mesmo quando nenhuma solicitação alcança a memória NAND.
Os resultados com B200 evidenciaram essa diferença. Com cerca de 125 tokens por segundo para cada usuário, a configuração de DRAM produziu 121 milhões de tokens totais por unidade de gasto. O caminho via SSD produziu 52 milhões.
Portanto, a DRAM entregou aproximadamente 2,3 vezes mais tokens nessa comparação medida. Ela também superou as configurações de SSD observadas em interatividade P90, que mede a experiência de solicitações mais lentas próximas à cauda.
Os pesquisadores não conseguiram habilitar o GPUDirect Storage, ou GDS, para o teste. O GDS pode mover dados entre NVMe e memória da GPU com menos envolvimento da CPU. Sua ausência limita o que o experimento revela sobre um caminho de armazenamento otimizado.
O resultado não deve ser apresentado como prova de que o NVMe não pode atender ao Engram. Ele mostra que mídia de armazenamento barata não cria automaticamente inferência barata.
As quatro GPUs B200 permaneceram no servidor. O mesmo vale para a CPU, a rede, a energia e a maior parte da infraestrutura de suporte. Substituir DRAM por SSD reduziu uma exigência de capacidade sem reduzir as partes caras da configuração.
Um ganho econômico exige um segundo efeito. O offloading para SSD precisa viabilizar um servidor mais barato, acomodar mais réplicas produtivas, suportar um modelo maior ou liberar DRAM para outra carga de trabalho valiosa.
O protótipo não alcançou nenhum desses resultados em sua configuração medida. Seu cache do sistema de arquivos também poderia consumir grande parte da DRAM que o suporte em arquivo pretendia economizar.
A localidade da carga de trabalho cria outra incerteza. Um serviço estável com prompts repetidos pode manter um cache aquecido útil. Uma carga de trabalho diversificada de agentes pode acessar uma gama maior de N-grams e gerar mais falhas de armazenamento.
O batching altera novamente a equação. Várias solicitações podem reutilizar linhas dentro de um lote, enquanto a desduplicação reduz transferências. Porém, lotes maiores também aumentam os requisitos de cache KV e podem alterar a latência.
As especificações de hardware do SSD, por si só, não preveem o resultado. Latência de leitura aleatória, profundidade de fila, comportamento do sistema de arquivos, tamanho de página, sobrecarga da CPU e política de cache contribuem.
Os sistemas de recomendação oferecem um precedente histórico útil. Eles servem grandes tabelas de embeddings a partir de memória em camadas há anos. Alguns sistemas armazenam em cache linhas populares na DRAM, enquanto colocam a cauda longa em SSDs.
O tráfego de Engram em modelos de linguagem é suficientemente parecido para aproveitar essas ideias, mas não é idêntico. A geração autorregressiva impõe uma latência sequencial rigorosa. Um atraso na posição de um token pode interromper posições posteriores.
O AgentX torna essa preocupação mais visível. Ele representa tráfego de programação agentiva de longo contexto e múltiplos turnos, em vez de um prompt sintético curto. Essas cargas alternam processamento substancial de entrada com geração sensível à latência.
O caso do armazenamento só melhorará quando o software tratar o Engram como uma primitiva de serving de primeira classe. Um arquivo genérico mapeado em memória é útil para experimentação, mas deixa trabalho demais no caminho controlado pela CPU.
Projetos futuros precisam de I/O direto, filas assíncronas, cache orientado a linhas e cronogramas previsíveis de pré-busca. Eles também podem exigir layouts de armazenamento alinhados às linhas quantizadas do Engram.
Portanto, o NVMe continua sendo uma oportunidade, e não o padrão atual. A DRAM já demonstrou que o uso de camadas pode melhorar o sistema. O SSD ainda precisa de uma stack de serving projetada em torno do padrão de acesso esparso do modelo.
AgentX Mostra a Vantagem de Software em Torno de Novas Arquiteturas
O Engram altera o posicionamento da memória, mas o suporte de software no lançamento ainda determina qual acelerador pode transformar a arquitetura em um serviço utilizável.
A SemiAnalysis avaliou o DeepSeek-V4.1-Flash em sistemas Nvidia H100, H200, B200, B300, GB200 e GB300. Também testou o MI355X da AMD por meio do framework InferenceX.
As medições do InferenceX usam hardware real e registram o throughput em relação à interatividade. O AgentX fornece uma carga de programação de longo contexto projetada para se assemelhar a sessões repetidas orientadas por ferramentas.
Segundo a SemiAnalysis, o caminho vLLM da Nvidia funcionava em todas as seis plataformas Nvidia testadas quando o modelo foi lançado. A imagem de contêiner citada da AMD não estava disponível publicamente durante as primeiras 23 horas.
O suporte da AMD chegou depois, mas a diferença inicial de desempenho continuou significativa nas medições do analista. Sete dias após o lançamento, a SemiAnalysis posicionou o desempenho do MI355X por unidade de gasto entre duas e quatro vezes atrás do B200.
Essas são afirmações sensíveis a fornecedores, vindas de uma única organização de benchmarking. Elas dependem de premissas de nuvem, versões de runtime, quantização, topologia e rápidas mudanças de software. Não devem ser generalizadas para todos os modelos ou cargas de trabalho da AMD.
Elas revelam uma restrição importante. Uma arquitetura pode ser projetada para offloading, mas a implantação ainda depende de kernels, captura de grafos, endereçamento de memória, quantização e agendamento distribuído.
O offloading de Engram da DeepSeek exige mais do que largura de banda PCIe adequada. O runtime deve sobrepor transferências sem quebrar grafos de decodificação. Ele precisa selecionar e desquantizar linhas eficientemente em cada plataforma.
Assim, um novo modelo testa o ecossistema de aceleradores antes que as equipes de hardware tenham meses para ajustá-lo. Familiaridade dos mantenedores e pipelines de lançamento funcionais tornam-se parte do desempenho.
Essa dinâmica reforça a posição de software da Nvidia mesmo quando a arquitetura do modelo reduz a capacidade de HBM necessária por réplica. Menos GPUs por réplica podem reduzir a comunicação, mas cada GPU restante precisa de kernels maduros e integração de runtime.
O efeito sobre a demanda total por aceleradores não é direto. Melhor uso de memória pode reduzir o número de GPUs necessário para uma réplica de modelo. Custos menores de serving também podem expandir a demanda ao tornar mais aplicações economicamente viáveis.
O Engram poderia incentivar modelos maiores porque a memória condicional escala separadamente da computação ativa. Os operadores poderiam usar a HBM economizada para mais sessões simultâneas, em vez de comprar menos aceleradores.
A DeepSeek também reduziu os requisitos de cache KV no V4.1-Flash, segundo seus materiais de lançamento. O offload de Engram e a compressão de KV liberam memória em duas direções diferentes.
Essa combinação importa para a inferência agentiva. Agentes carregam históricos longos, saídas de ferramentas, código e planos intermediários. Seu cache KV pode ocupar capacidade substancial mesmo quando os pesos do modelo já cabem.
Um servidor que transfere tabelas de consulta esparsa para a DRAM pode dedicar mais HBM a essas sessões ativas. O benefício prático pode surgir como maior concorrência, e não como um modelo físico menor.
A visão cética continua necessária. A reprodução de Engram da SemiAnalysis usou código e configurações de treinamento divulgados, porque a DeepSeek não lançou os dois modelos de pesquisa treinados do artigo original. O comportamento em produção pode diferir de experimentos controlados de escalonamento.
O caminho via SSD foi explicitamente não otimizado. Os resultados da Nvidia e da AMD capturaram stacks iniciais de software que mudarão. Até mesmo o resultado mais forte com DRAM dependeu de uma topologia B300 específica e de uma fronteira de carga de trabalho.
O Engram também armazena aquilo que o treinamento recompensa. Mais capacidade pode preservar boilerplate e padrões incidentais ao lado de entidades ou código úteis. Melhor alocação de memória não garante melhor seleção de dados.
As evidências sustentam uma conclusão mais restrita. A memória condicional é tecnicamente compatível com níveis de memória mais baratos, e a DRAM pode melhorar o desempenho completo de serving. Ainda não estabelece uma configuração universal.
Três Sinais Decidirão o Impacto da DRAM e do NVMe
A próxima fase depende de serving de SSD otimizado, ganhos de topologia reproduzíveis e amplo suporte de runtime além de um único lançamento de modelo.
O primeiro sinal é uma implementação NVMe otimizada que use um caminho direto orientado à GPU. A comparação importante não é a largura de banda máxima do SSD. É a fronteira completa de throughput e interatividade P90 em relação à DRAM fixada.
O suporte ao GPUDirect Storage eliminaria parte do percurso de ida e volta pela CPU. A desduplicação nativa de linhas, a pré-busca assíncrona e layouts de armazenamento conscientes do Engram poderiam remover ainda mais sobrecarga.
Se um caminho otimizado se aproximar do desempenho da DRAM enquanto reduz materialmente a memória do host necessária, a oportunidade do NVMe se tornará crível. Se o SSD em cache continuar muito atrás, o Engram reforçará a demanda por DRAM.
O segundo sinal é verificar se topologias de réplica menores se repetem em diferentes hardwares e cargas de trabalho. A mudança da SemiAnalysis no B300, de paralelismo de tensor em quatro vias para duas vias, produziu o resultado mais relevante.
Testes independentes devem analisar B200, H200, MI355X e sistemas futuros. Eles devem incluir diferentes comprimentos de contexto, tamanhos de lote, níveis de concorrência e estados de cache.
Ganhos repetidos confirmariam que o offload do Engram altera a economia dos servidores ao reduzir a comunicação. A incapacidade de reproduzi-los limitaria a descoberta a uma configuração inicial específica.
O terceiro sinal é a adoção pelo ecossistema. DeepSeek-V4.1-Flash oferece um teste visível, mas uma memória semelhante ao Engram precisa se disseminar por mais famílias de modelos e motores de serving para remodelar a demanda por hardware.
O relatório da SemiAnalysis aponta para mecanismos de N-gram relacionados nos modelos LongCat e Qwen. Pesquisadores também propuseram capacidade Engram compartilhada por meio de CXL. Essas abordagens precisam de suporte estável em vLLM, SGLang e runtimes de fornecedores.
Uma adoção ampla fortaleceria a demanda por servidores equilibrados, com maior largura de banda de DRAM, NVMe local capaz e interconexões flexíveis. A adoção limitada deixaria o Engram como uma otimização importante, mas específica do DeepSeek.
Desenvolvedores devem acompanhar receitas de implantação, não manchetes sobre parâmetros. Compradores corporativos devem solicitar desempenho nos seus próprios comprimentos de contexto e metas de latência. Equipes de infraestrutura devem medir separadamente estados de cache frio, aquecido e misto.
Profissionais do conhecimento perceberão o resultado indiretamente. Um melhor posicionamento da memória pode viabilizar sessões mais longas, menor latência e acesso mais amplo a modelos capazes. Esses benefícios só importam quando aplicações completas os utilizam de forma confiável.
Equipes que avaliam sistemas de IA devem preservar suas próprias evidências junto às alegações de benchmark. Uma base de conhecimento de engenharia pesquisável pode manter conectados os cartões de modelo, as versões de runtime e os resultados de testes internos.
O offload do DeepSeek Engram não representa o fim da inferência liderada por HBM. É uma evidência de que a arquitetura do modelo pode decidir, em primeiro lugar, quais parâmetros merecem HBM. A próxima questão é se NVMe otimizado e memória compartilhada podem repetir o resultado da DRAM sem transferir o gargalo para o software.
