MemT-1.0: memória de IA dentro do modelo é incrível (testei a ideia)

Autoria: Prompt Engineer 48 · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: MemT-1.0: AI Memory INSIDE the Model Is CRAZY (I Tested the Idea) · Canal: Prompt Engineer 48 · 11:54 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Modelos locais e open source, RAG, busca e recuperação de informação

Resumo

O vídeo apresenta o MemT-1.0, um projeto de memória nativa que mantém um estado de tamanho fixo dentro do modelo, em vez de guardar toda a conversa ou buscar notas externas. O apresentador explica as alegações dos autores, as limitações de licença e hardware e por que não conseguiu executar o modelo. Em seguida, compara, numa simulação própria que não reproduz a arquitetura do MemT, histórico completo, busca em arquivos e memória vetorial de tamanho fixo. A simulação mostra que o estado compacto pode preservar correções até atingir seu limite, enquanto a recuperação por busca pode devolver informações antigas com confiança. A conclusão é que a memória nativa é promissora, mas sistemas pesquisáveis continuam úteis quando é necessário recuperar detalhes exatos de conversas longas.

Pontos-chave

O MemT-1.0 propõe manter a memória dentro da computação do modelo, em um estado de tamanho constante atualizado a cada turno.
Segundo o repositório, a memória nativa usa cerca de 66 vezes menos armazenamento persistente que um cache de contexto completo com 128.000 tokens.
O repositório informa que sistemas de memória textual ainda têm vantagem geral, especialmente para recuperar evidências detalhadas em históricos longos.
O apresentador não executou o MemT: seu laptop tem uma RTX 4060 com 8 GB, enquanto o exemplo do repositório requer um servidor Linux com CUDA e usa duas GPUs.
A licença do software do repositório é Polyform non-commercial; os termos das weights ainda não estavam publicados no momento descrito.
Na simulação, o histórico completo preserva os fatos enquanto eles cabem na context window, mas o custo cresce com a conversa.
A busca TF-IDF da simulação às vezes recupera informações antigas após correções; aumentar de três para oito notas recuperadas melhora os resultados.
A memória vetorial de tamanho fixo preserva bem os fatos na simulação enquanto não é sobrecarregada; além da capacidade, as informações se misturam.
A simulação é um experimento simplificado, não uma reprodução da arquitetura nem dos resultados do MemT-1.0.
O apresentador recomenda manter uma janela curta de conversa recente, guardar fatos duradouros em um sistema pesquisável e tratar correções deliberadamente.

Capítulos

Início	Capítulo	Resumo
00:00	O que é o MemT-1.0	O vídeo apresenta a proposta de memória nativa, os modelos disponíveis, as alegações do projeto e suas condições de licença.
03:07	Como a memória nativa funciona e o que foi testado	O apresentador descreve o estado persistente, os requisitos para executar o modelo e o experimento simplificado que compara três abordagens.
05:40	Resultados da simulação de memória	A comparação mostra os limites do histórico completo, os erros de recuperação de notas antigas e a capacidade limitada da memória vetorial.
09:18	Limites e recomendações práticas	O apresentador discute a capacidade do estado, as perguntas ainda em aberto sobre o MemT e estratégias práticas para sistemas de memória.

Citações

66 vezes menos armazenamento de memória. — 00:00

O estado permanece constante em tamanho e continua funcionando sem o texto original. — 03:07

Sistemas de memória textual ainda lideram no geral. — 04:07

Uma memória de tamanho fixo tem uma capacidade e, quando você a sobrecarrega, as coisas antigas não são apagadas: elas se misturam. — 08:46

Memória nativa do modelo é algo para acompanhar, não para implementar nesta semana. — 11:23

Conceitos e entidades

MemT-1.0 (modelo): Modelo apresentado como uma abordagem de memória nativa que atualiza um estado interno de tamanho fixo ao longo da conversa.
MemT (repo): Repositório do projeto que descreve a implementação, os requisitos e as alegações sobre a memória nativa.
MemTensor (empresa): Organização associada à equipe e ao projeto MemT, conforme a transcrição.
Qwen (modelo): Modelo citado como backbone do MemT-1.0 Nano.
DeepSeek (modelo): Modelo citado como backbone do MemT-1.0 Flash.
KV cache (conceito): Armazenamento de chaves e valores dos tokens vistos, que cresce com o histórico mantido pelo modelo.
TF-IDF (conceito): Método de recuperação textual usado no experimento simplificado para selecionar notas relevantes.
Gated DeltaNet (conceito): Mecanismo citado como base da regra simplificada usada para atualizar a memória vetorial no experimento.
RunPod (empresa): Serviço de GPUs mencionado pelo apresentador como recurso que utiliza.
Prompt Engineer (pessoa): Nome usado pelo apresentador ao se despedir no fim do vídeo.

Tradução completa (pt-BR)

00:00 66 vezes menos armazenamento de memória. Essa frase está na página do repositório do Mem T e diz que, com 128.000 tokens de histórico, esse modelo armazena cerca de 66 vezes menos do que um cache de contexto completo normal. Agora, pense em como seu assistente de IA se lembra de você hoje. Ou ele relê todo o seu chat a cada vez, o que fica mais lento e custa mais a cada mensagem, ou despeja notas em arquivos, faz buscas nelas e responde com base no que a busca por acaso encontrou. O Mem T tenta uma terceira abordagem: a memória vive dentro da própria computação do modelo. Sem transcrição,

00:31 sem banco de dados. Não consigo executar o modelo real no meu laptop, e vou mostrar por quê. Então, construí a versão mais simples das três ideias, dei 100 fatos para cada uma, alterei alguns desses fatos depois e fiz as mesmas perguntas novamente após 3.000 mensagens. Uma delas esqueceu quase tudo. Uma me deu respostas antigas com total confiança, e outra fez algo que eu não esperava. >> [música] >> Um rápido choque de realidade. Primeiro, o artigo se chama Mem T1 towards memory native evolution, foi enviado em 19 de outubro de 2026 por uma grande equipe, com 74 autores na listagem do archive, da Mem Tensor. O código foi disponibilizado

01:03 publicamente no dia seguinte. Quando olhei, o repo tinha cerca de 370 estrelas, 17 forks e ainda não tinha releases: algo muito inicial, bem inicial. Dois modelos: Mem T1.0 Nano, construído sobre uma base Quen. O repo o chama de modelo de 36 bilhões de parâmetros, mas apenas cerca de 3 bilhões ficam ativos para cada token; e Mem T1.0 Flash, construído sobre uma base DeepSeek, com 288 bilhões no total e 17 bilhões ativos. Então, quando ouvir falar de um modelo de 36 bilhões, lembre-se de que é uma mistura de especialistas. A parte de parâmetros de memória do

01:34 Nano. Mais uma coisa, e acho que importa: você verá open source nas manchetes, mas leia a licença. O software do repositório usa a licença Polyform não comercial; o uso comercial não é permitido, e os pesos do modelo nem sequer são cobertos por essa licença. A página diz que os termos deles serão divulgados junto com os lançamentos. Então, publicado e disponível para leitura, sim. Livre para qualquer uso, ainda não. Estou dizendo isso agora para você não ser pego de surpresa depois. Isso não torna a ideia menos interessante. Vamos olhar para a ideia. Aqui estão os três estilos. Primeiro, em ações simples; depois, os nomes. Estilo um: manter tudo. Cada mensagem permanece, e o modelo relê tudo. Esse é o histórico completo da conversa. Em um transformer, o modelo mantém uma chave e um

02:06 valor para cada token que viu. Um cache de chave e valor, então a memória cresce a cada palavra. Recordação perfeita dentro da janela, mas o custo cresce junto e, quando a janela fica cheia, as coisas mais antigas caem pela borda. Estilo dois: anotar e consultar. Cada mensagem vai para um arquivo ou banco de dados. Quando você pergunta algo, uma busca encontra alguns trechos relevantes e o modelo os lê. É assim que a maioria dos produtos de memória funciona hoje. É barato armazenar e fácil de inspecionar, mas só pode responder com base no que a busca encontra. O estilo três é o estranho. Um bloco de números de tamanho fixo que é atualizado após cada mensagem. Não é uma transcrição, é um estado

02:36 comprimido. Pense em uma folha de papel que você continua reescrevendo. Ela nunca fica maior, mas, para escrever algo novo, você precisa espremer ou borrar algo antigo. O Mem-T é o estilo três integrado ao modelo. O repo descreve um bloco de memória nativo que funciona ao lado da atenção normal. Uma memória local, que é uma matriz que muda conforme a conversa avança, e um bloco com projeções e portas treinadas: uma porta de apagamento, uma porta de escrita e uma porta de esquecimento. Durante uma resposta, o modelo lê essa memória e a incorpora à atenção normal. Ao final de cada turno, uma atualização gated delta net grava o novo turno no estado. Estou usando aqui a formulação do próprio repo. O artigo tem

03:07 os detalhes, e não verifiquei nada além do que está na página. O que sei pelo readme é a característica principal: o estado permanece sempre do mesmo tamanho e continua funcionando sem o texto original. Tamanho constante: guardem essa expressão, porque ela é tanto o superpoder quanto a limitação. Veja como é usar, diretamente do readme. Você inicia um servidor, abre uma sessão e ativa uma opção: enable memory. Depois de cada resposta, o modelo grava aquele turno na memória latente e limpa o texto simples da conversa do contexto. Quando termina, você chama save state e obtém um snapshot. Na semana seguinte, você passa esse snapshot de volta como estado, e o

03:37 modelo continua sem a transcrição. Essa é toda a promessa em duas chamadas de função. A limitação, segundo o readme, é que precisa de um servidor Linux com CUDA, e o exemplo do Nano usa 2 GB de memória unificada. Então, por enquanto, é coisa de laboratório e servidor. O que os autores realmente afirmam? Encontrei três coisas. Uma: cerca de 66 vezes menos armazenamento persistente do que um cache de contexto completo com 128.000 tokens de histórico. Duas: para o Nano, cerca de 1,86 vez mais rápido de ponta a ponta no mesmo comprimento. Isso vem da página do resumo no archive. Três: em 11 benchmarks de memória, o Flash fica em primeiro e o Nano em segundo entre os métodos de memória paramétrica que eles

04:07 avaliaram. Leia a última frase devagar: entre os métodos paramétricos, não em comparação com tudo. E eles mesmos dizem isso. O repo afirma que os sistemas de memória textual ainda lideram no geral, especialmente em históricos longos que exigem a recuperação de evidências detalhadas. Gosto que tenham registrado isso. É a versão honesta da história. A abordagem nativa do modelo é muito mais barata de carregar e é competitiva, mas a velha abordagem de buscar nas notas ainda vence quando você precisa do detalhe exato. Observe também que o número 66 vezes é uma comparação com um cache KV completo, não com um arquivo de texto, que é minúsculo. Então, esse número 66 não significa que é melhor do que a

04:38 recuperação; significa que é muito mais barato do que reler tudo. São afirmações diferentes. Mais duas coisas do resumo. Os autores dizem que os modelos preservam em grande parte as capacidades gerais. Ou seja, adicionar memória não estragou todo o resto, embora “em grande parte” esteja fazendo bastante trabalho nessa frase. E o repo descreve uma configuração de codificação agentic em que a experiência recuperada é armazenada na memória nativa e lida por meio da atenção de memória, em vez de ser colada no prompt. Não vi esses resultados, então estou apenas contando o que é alegado. Consigo executá-lo? Não. E aqui está a prova. Esta é minha máquina: uma GPU de laptop RTX 4060, com 8 GB. O readme pede um servidor Linux

05:09 com Nvidia CUDA, e o exemplo do Nano usa duas GPUs. A página não informa um número de VRAM, então aqui vai minha conta. 36 bilhões de parâmetros em BF16, com dois bytes cada, dão cerca de 72 GB só para os pesos. Mesmo com apenas 3 bilhões ativos, o conjunto completo de arquivos do modelo ainda precisa ficar em algum lugar. Eu poderia alugar uma GPU na nuvem, mas os termos dos pesos ainda não foram publicados, e eu estaria pagando para descobrir algo que os autores já relataram no artigo, então não fiz isso. Isto não contém nenhuma saída do Mem T. Tudo daqui em diante é meu próprio experimento pequeno, criado para mostrar as compensações, e não reproduz a arquitetura do Mem T.

05:40 Aqui está o teste: um fluxo de 3.000 mensagens de chat. Dentro dele, 100 fatos, como “o código de acesso ao cofre 25 é 8013”. Depois, 25 desses fatos são corrigidos. Metade das correções usa as mesmas palavras: “Correção: o código de acesso ao cofre tal agora é…”. A outra metade é reformulada: “Atualização sobre o cofre tal: a nova senha é…”, porque pessoas de verdade não repetem exatamente as mesmas palavras. Também incluí 300 mensagens como “o cofre 17 foi repintado de azul”, que compartilham palavras com os fatos reais, mas não são fatos reais. O restante é conversa fiada. Então, pergunto o código atual de cada cofre nas mensagens 500,

06:10 1.000, 2.000 e 3.000, em 10 fluxos aleatórios. Faço a média de três concorrentes: histórico completo com uma context window que posso reduzir; recuperação de arquivos, uma busca TF-IDF real que seleciona as poucas notas mais relevantes, e o leitor pega o resultado mais recente; e métricas de memória de tamanho fixo, atualizadas com uma regra gated delta. Essa é a ideia de atualização por trás da gated DeltaNet. Antes de gravar um valor novo em uma chave, subtraia o que já está armazenado nela. Assim, uma correção sobrescreve o valor anterior em vez de se acumular sobre ele. Agora, para ser sincero, os leitores são regras simples, não um modelo de linguagem. Portanto, isso mede o que cada memória mantém, não o quão bem um modelo consegue lê-la. O

06:41 A memória comprimida recebe um codificador perfeito que já sabe que senha e código são a mesma coisa. E os tamanhos do cache usam uma configuração de modelo substituta: 48 camadas, 8 cabeças KB, FP16, não memtensors. Isso é um brinquedo que mostra as compensações. Não é uma réplica. Deixe-me mostrar a sobrescrita, porque essa é a parte engenhosa. A memória é apenas uma grade de números. Uma chave, digamos, código do Cofre 25, escolhe uma direção nessa grade. Para ler, multiplico a grade pela chave e decodifico o que sai. Para escrever uma correção, primeiro leio o que está armazenado no momento sob essa chave, subtraio esse valor e, em vez disso, adiciono o novo. Uma linha de código: o código antigo

07:13 é cancelado, não empilhado sobre o novo. É por isso que as correções não produziram respostas desatualizadas nessa memória. Mas duas chaves diferentes nunca são perfeitamente separadas. Em uma grade pequena, elas se sobrepõem um pouco, e cada gravação afeta as vizinhas. Com 100 fatos e mais 300 gravações quase iguais, esse efeito se acumula. Guardem essa ideia para os resultados. Primeiro, o histórico completo: dê a ele uma context window de 8.000 tokens, uma configuração local comum, e observe: na mensagem 500, 100%; na 1.000, 76%; na 2.000, 18%; na 3.000, 0%. Todos os fatos tinham saído da context window. Dê a ele 32.000 tokens e ele nunca esquece. 100% em todos os

07:45 checkpoints, incluindo as correções. Claro que sim. Ele consegue ver tudo. O custo é que importa. Com 3.000 mensagens e minha configuração substituta, esse cache tem cerca de 6 GB, e só cresce. Recuperação: armazenamento minúsculo, cerca de um décimo de megabyte, perfeito até as correções chegarem. Então, com os três melhores resultados, cai para 92,7% na mensagem 2.000 e 90,7% na 3.000. E olhe o tipo de erro. Não é “não sei”, é a resposta antiga. 9,3 respostas desatualizadas por execução. Aqui vai um exemplo: código original do Cofre 25, 8013. Mais tarde, uma atualização no

08:16 Cofre 25: a nova senha é 4855. A pergunta diz “código de acesso”, a atualização diz “senha”. A busca favorece a formulação original, encontra a linha antiga e responde com ela, com confiança. Se deixar que recupere oito notas em vez de três, a precisão volta a 99,9%. Então, isso pode ser corrigido com uma busca maior e mais tokens para ler. Mas o padrão da falha é real. A recuperação só sabe o que a busca encontra. Agora, na memória de tamanho fixo, o único ajuste é o tamanho do estado. Com 256 por 256 números, meio megabyte, ela mantém

08:46 100% em todos os checkpoints e 99,9% na mensagem 3.000. Incluindo as correções, porque a regra do delta sobrescreve. Meio megabyte contra 6 gigabytes. Essa é a parte que eu não esperava. Agora, o porém: reduza para 228 por 128 e ela começa a se apagar à medida que as gravações se acumulam. 99,6%, 88%, 69%, 55%; com 64, cai para 3% no fim. Com 32, nada. Não aparece uma mensagem de erro, a memória simplesmente fica borrada. Uma memória de tamanho fixo tem uma capacidade e, quando você a sobrecarrega, as coisas antigas não são apagadas: elas se misturam. Esse é o custo de ter tamanho constante.

09:18 Mais um teste, porque uma memória borrada levanta uma pergunta óbvia. Quantos fatos cabem em um determinado tamanho? Gravei fatos diretamente no estado, sem conversa, e contei quantos conseguia ler de volta. Com 256 por 256, ela armazena tudo até cerca de 200 fatos. 99% com 300; depois, cai para 75% com 500 e 36% com 1.000. Dobre a largura para 512 e ela armazena 500 perfeitamente e 89% de 1.000. A regra prática para a capacidade do meu brinquedo é que ela corresponde aproximadamente à largura do estado, não à sua área. Dobre a largura, dobre os fatos. Um modelo real treinado pode lidar com isso de outra forma, e não consigo dizer com base

09:49 no que vi aqui. Mas a lição continua valendo: tamanho constante significa um limite, e nada avisa quando você o atinge. Uma rápida verificação de plausibilidade desse 66: usando minha configuração substituta, 128.000 tokens de cache dão cerca de 25 gigabytes. Divida por 66 e você obtém aproximadamente 380 megabytes. Essa é a minha conta com a minha configuração, não um número medido pela MNT, então não cite isso como dado. Mas mostra a escala. Um histórico passa a ser algo que você poderia salvar por usuário, por sessão, por projeto, como salvaria um documento. O repo literalmente tem uma chamada safe state que grava a memória no disco e a restaura depois, sem a transcrição. Esse é o custo real aqui.

10:21 Então, o que tiramos disso? O histórico completo é o mais preciso e é o que fica mais caro a cada mensagem. A recuperação é barata e fácil de inspecionar, mas falha ao devolver notas antigas ou erradas com toda a confiança. Um estado de tamanho fixo é o mais barato de armazenar, e funciona bem até ficar sobrecarregado; aí, fica borrado. O MemT real não é meu brinquedo. Ele aprende o que escrever e o que esquecer dentro de um modelo de 36 ou 288 bilhões, e é treinado com muitos dados. O que meu brinquedo pode mostrar é por que a ressalva dos próprios autores faz sentido: quando você precisa de um detalhe exato de um histórico longo, um armazenamento que você possa pesquisar

10:52 é difícil de superar. Minha própria leitura — e esta é a minha interpretação, não a do artigo — é que há uma diferença prática que não consigo testar aqui. Se a memória fica dentro de um estado, você não pode abrir um arquivo e editar uma memória. Ainda não vi uma resposta no artigo para a questão de como o MemT lida com o esquecimento ou a remoção de um único fato; vale a pena conferir no artigo. E as questões em aberto são as chatas e importantes: a licença dos pesos, os números por benchmark — que o repo só mostra em uma figura — e se ele funciona em hardware que seja comum para alguém que não seja um laboratório. Se você testar em um servidor real, conte o que descobrir. Se estiver construindo algo hoje, aqui está o que este brinquedo sugere. Mantenha uma context window curta das conversas recentes, porque ela é perfeita e

11:23 barata em tamanhos pequenos. Coloque fatos duradouros em um armazenamento, mas trate as correções de propósito. Quando um fato mudar, grave-o de modo que a nova versão prevaleça, recupere mais de três notas e fique atento à falha de mistura, porque ela parece uma resposta confiante. A memória nativa do modelo é algo para acompanhar, não algo para fazer deploy nesta semana, porque os termos dos pesos ainda não foram divulgados e ninguém mostrou isso em um laptop. Se você está procurando GPUs baratas e confiáveis, eu uso RunPod, e o link está na descrição. Todos os links também estão na descrição: o repo, o artigo e meu código para este experimento. Uma pergunta para os comentários: você confiaria em uma IA que se lembra de você, mas

11:54 não consegue mostrar a transcrição? Eu sou Prompt Engineer. Até a próxima.

Transcrição original

[00:00] 66 times less memory storage. That sentence is on the Mem T repo page and it says that at 128,000 tokens of history, this model stores about 66 times less than a normal full context cache. Now, think about how your AI assistant remembers you today. Either it rereads your entire chat every single time, which gets slower and costs more with every message, or it dumps notes into files and searches them and then answers from whatever the search happened to find. Mem T tries a third thing, the memory lives inside the model’s own computation. No transcript,

[00:31] no database. I can’t run the real model on my laptop and I’ll show you why. So, I built the simplest version of all three ideas, gave each one 100 facts, changed some of those facts later, and asked them again after 3,000 messages. One of them forgot almost everything. One gave me old answers with total confidence and one did something I did not expect. >> [music] >> Quick reality check. First, the paper is called Mem T1 towards memory native evolution, submitted October 19th, 2026 by a big team, 74 authors on the archive listing from Mem Tensor. The code went

[01:03] public the next day. When I looked, the repo had about 370 stars, 17 forks, and no releases yet, early, very early. Two models, Mem T1.0 Nano, built on a Quen backbone. The repo calls it 36 billion parameters, but only about 3 billion are active for each token, and Mem T1.0 Flash, built on a DeepSeek backbone, 288 billion total, 17 billion active. So, when you hear a 36 billion model, remember it’s a mixture of experts. The memory part on parameters for

[01:34] Nano. One more thing, and I think it matters, you’ll see open source in the headlines, read the license. The repository software is Polyform non-commercial, commercial use is not permitted, and the model weights are not covered by that license at all. The page says their terms will come with the releases. So, published and readable, yes. Free for any use, not yet. I’m saying that now, so you’re not surprised later. It doesn’t make the idea less interesting. Let’s look at the idea. Here are the three styles. In plain actions first names second. Style one, keep everything every message stays and the model rereads the lot. That is the full conversation history. In a transformer the model keeps a key and a

[02:06] value for every token it has seen. A key value cache so the memory grows with every word. Perfect recall inside the window, but the cost grows with it and when the window is full the oldest things fall off the edge. Style two, write it down and look it up. Every message goes into a file or a database. When you ask something a search finds a few relevant pieces and the model reads those. This is how most memory products work today. Cheap to store, easy to inspect, but it can only answer from what the search finds. Style three is the odd one. One block of numbers fixed size that gets updated after every message. Not a transcript, a compressed

[02:36] state. Think of one sheet of paper you keep rewriting. It never gets longer, but writing something new has to squeeze out or blur something old. Mem-T is style three built into the model. The repo describes a native memory block that runs next to the normal attention. A local memory, which is a matrix that changes as the conversation goes and a block with trained projections and gates. An erase gate, a write gate, a forget gate. During a reply the model reads from that memory and adds it into its normal attention. At the end of each turn a gated delta net update writes the new turn into the state. I’m using the repo’s own wording here. The paper has

[03:07] the details and I haven’t verified those beyond the page. What I do know from the read me is the headline property. The state stays constant in size and it keeps working without the original text. Constant size, hold on to that word because it is both the superpower and the catch. Here’s what using it looks like straight from the read me. You start a server, open a session and turn on one switch enable memory. After each reply the model writes that turn into its latent memory and then clears the plain text conversation out of context. When you’re done you call save state and get a snapshot. Next week you pass that snapshot back in as the state and the

[03:37] model carries on without the transcript. That’s the whole promise in two function calls. The catch, per the read me it needs a Linux server with CUDA and the nano example uses 2GB US. So for now this is lab and server territory. What do the authors actually claim? Three things I could find. One, about 66 times less persistent storage than a full context cache at 128,000 tokens of history. Two for nano, around 1.86 times faster end-to-end at the same length. That’s from the archive abstract page. Three across 11 memory benchmarks, Flash ranks first and nano second among the parametric memory methods they

[04:07] evaluated. Read that last sentence slowly. Among the parametric methods, not against everything. And they say so themselves. The repo states that textual memory systems still lead overall, especially on long histories that need detailed evidence retrieval. I like that they wrote it down. It’s the honest version of the story. The model native approach is much cheaper to carry around and it’s competitive, but the old school search the notes approach still wins when you need the exact detail. Also notice what the 66 times is compared against a full KV cache, not against a text file, which is tiny. So, this 66 number doesn’t say better than

[04:38] retrieval, it says much cheaper than rereading everything. Those are different claims. Two more things from the abstract. The authors say the models largely preserve general capabilities. So, adding memory didn’t wreck everything else, though largely is doing some work in that sentence. And the repo describes an agentic coding setup where retrieved experience is stored in the native memory and read through memory attention instead of being pasted into the prompt. seen those results, so I’m only telling you what’s claimed. Can I run it? No. And here’s the proof. This is my machine, an RTX 4060 laptop GPU, 8 GB. The readme asks for a Linux server

[05:09] with Nvidia CUDA, and the nano example uses two GPUs. The page doesn’t give a VRAM number, so here’s my own arithmetic. 36 billion parameters in BF16 is two bytes each, about 72 GB for weights alone. Even with only 3 billion active, the whole export set still has to live somewhere. I could rent a cloud GPU, but the weights terms aren’t published yet and I’d be paying to find out something the authors already reported in their paper, so I didn’t. This doesn’t contain a single Mem T output. Everything after this point is my own small experiment built to show the tradeoffs, and it does not reproduce Mem T’s architecture.

[05:40] Here’s the test, a stream of 3,000 chat messages. Inside it, 100 facts like the access code for vault 25 is 8013. Later, 25 of those get corrected. Half of the corrections use the same words. Correction, the access code for vault whatever is now. The other half are reworded. Update on vault whatever new passcode is, because real people don’t repeat themselves word for word. I also threw in 300 like vault 17 was repainted blue, which shares words with the real facts, but isn’t one. The rest is chitchat. Then I ask for every Vault’s current code at message 500

[06:10] 1,000, 2,000, and 3,000 10 random streams. Average three contestants’ full history with a context window I can shrink. File retrieval, a real TF-IDF search that pulls the top few notes, and the reader takes the newest hit and a fixed-size memory metrics written with a gated delta rule. That’s the update idea behind gated DeltaNet. Before writing a new value to a key, subtract what’s already stored under it. So, a correction overwrites instead of piling up. Now, honestly, the readers are simple rules, not a language model, so this measures what each memory keeps, not how well a model reads. The

[06:41] compressed memory gets a perfect encoder that already knows passcode and code are the same thing. And the cash sizes use a stand-in model config. 48 layers, 8 KB heads, FP16, not memtensors. This is a toy that shows tradeoffs. It is not a replica. Let me show the override because it’s the clever bit. The memory is just a grid of numbers. A key, say Vault 25 code, picks a direction in that grid. To read, I multiply the grid by the key and decode what comes out. To write a correction, I first read what’s currently stored under that key, subtract it, and add the new value instead. One line of code, the old code

[07:13] is canceled, not stacked on top of the new one. That’s why corrections didn’t produce stale answers in this memory. But two different keys are never perfectly separate. In a small grid, they overlap a little, and every write nudges its neighbors with 100 facts plus 300 near miss writes. That nudging adds up. Hold that thought for the results. Full history first, give it an 8,000 token window, a normal local setup, and watch at message 500 100% at 1,000 76, at 2,000 18, at 3,000 0. Every fact had scrolled off the edge. Give it 32,000 tokens, and it never forgets. 100% every

[07:45] checkpoint, corrections included. Of course, it does. It can see everything. The bill is the point. At 3,000 messages with my stand-in config, that cash is about 6 GB, and it only goes up. Retrieval, tiny storage about a tenth of a megabyte, perfect until the corrections arrive. Then with the top three results, it falls to 92.7% at message 2,000 and 90.7 at 3,000. And look at the kind of mistake. It’s not I don’t know, it’s the old answer. 9.3 stale answers per run. Here’s one, vault 25 original code 8013. Later update on

[08:16] vault 25, new passcode is 4855. The question says access code, the update says passcode. The search favors the original wording, finds the old line and answers with it confidently. Let it pull eight notes instead of three and it recovers to 99.9. So, this is fixable with a bigger search and more tokens to read. But, the shape of the failure is real. Retrieval only knows what the search finds. Now, the fixed-size memory, the size of the state is the only dialed. At 256 by 256 numbers, half a megabyte, it holds

[08:46] 100% at every checkpoint and 99.9 at 3,000. Corrections included because the delta rule overrides half a megabyte against 6 gigabytes. That’s the part I did not expect. Now, the catch, shrink it 228 by 128 and it starts fading as writes pile up. 99.6 88 69 55% at 64 3% by the end. At 32, nothing. There’s no error message, it just gets blurry. A fixed-size memory has a capacity and when you overload it, old things don’t get deleted, they get mixed together. That’s what constant size costs you.

[09:18] One more test because a blurry memory raises an obvious question. How many facts can a given size hold? I wrote facts straight into the state, no chatter, and counted how many it could read back. At 256 by 256, it holds everything up to about 200 facts. 99% at 300, then drops to 75% at 500 and 36 at 1,000. Double the width to 512 and it holds 500 perfectly and 89% of 1,000. The rule of thumb in my toy capacity is roughly the width of the state, not its area. Double the width, double the facts. A real trained model may handle this differently and I can’t tell from

[09:49] here. But, the lesson stands, constant size means a ceiling and nothing warns you when you hit it. Quick sanity check on that 66, using my stand-in config, 128,000 tokens of cache is about 25 gigabytes. Divide by 66 and you get roughly 380 megabytes. That’s my arithmetic with my config, not MNT’s measured number, so don’t quote it. But, it shows the scale. One history becomes something you could save per user, per session, per project, the way you’d save a document. The repo literally has a safe state call that writes the memory to disk and restores it later without the transcript. That’s the real price here.

[10:21] So, what do we take from this? Full history is the most accurate, and it’s the one that costs more with every message. Retrieval is cheap and easy to inspect, but it fails by returning old or wrong notes with a straight face. A fixed-size state is the cheapest to carry, and it holds up well until you overload it, and then it blurs. Real Mem T is not my toy. It learns what to write and what to forget inside a 36 or 288 billion model, and it’s trained on a lot of data. What my toy can tell you is why the authors’ own caveat makes sense when you need an exact detail from a long history. A store you can search

[10:52] is hard to beat. My own read, and this is my interpretation, not the paper’s, there’s a practical difference I can’t test here. If memory sits inside a state, you can’t open a file and edit one memory. How Mem T handles forgetting or removing a single fact, I haven’t seen answered on the page, worth checking in the paper. And the open questions are the boring, important ones, the weights license, the per benchmark numbers, which the repo only shows in a figure, whether it runs on hardware that’s normal for anyone but a lab. If you try it on a real server, tell me what you find. If you’re building something today, here’s what this toy suggests. Keep a short window of recent chat because it’s perfect and

[11:23] cheap at small sizes. Put durable facts in a store, but handle corrections on purpose. When a fact changes, write it so the new version wins, and retrieve more than three notes, and watch for the mix-up failure because it looks like a confident answer. Model native memory is something to watch, not something to deploy this week cuz the weights terms aren’t out, and nobody has shown it on a laptop. If you’re looking for cheap and reliable GPUs, I use RunPod, and the link is in the description. All the links are in the description, too, the repo, the paper, and my code for this experiment. Question for the comments, would you trust an AI that remembers you, but

[11:54] can’t show you the transcript? I’m Prompt Engineer. See you in the next one.