Modelo de memória da Tencent “supera Claude Opus 5”. Aluguei uma GPU para conferir
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: Tencent’s Memory Model “Beats Claude Opus 5”. I Rented a GPU to Check · Canal: Prompt Engineer 48 · 11:44 · Assistir no YouTube
Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Engenharia de prompts e contexto, Infraestrutura e hardware de IA, Modelos locais e open source
A Tencent apresenta o High Memory, um modelo de 30 bilhões de parâmetros voltado a escrever e atualizar memórias para agents, e afirma que ele iguala ou supera Claude Opus 5 em média. O vídeo explica como o modelo funciona e mostra como executá-lo em uma GPU alugada, usando uma conversão comunitária quantizada e llama.cpp. Em cinco testes próprios, o modelo lidou bem com conflitos, ruído e recuperação de informações, mas apagou fatos verdadeiros sem contradição em dois casos. O autor considera o modelo promissor, mas recomenda verificar as atualizações e registrar as exclusões antes de confiar nele em aplicações importantes.
Pontos-chave
Seção intitulada “Pontos-chave”- O High Memory foi treinado para decidir quais informações adicionar, atualizar ou excluir de uma memória.
- A Tencent relata uma média de 55,49 pontos para o modelo, ante 54,62 para Claude Opus 5; são resultados do próprio fornecedor, não uma avaliação independente.
- O modelo tem 30 bilhões de parâmetros, dos quais cerca de 3 bilhões são ativados por token, mas todos precisam caber na memória da GPU.
- O autor executou uma conversão comunitária em GGUF com llama.cpp, usando uma GPU A40 alugada no RunPod.
- Nos testes próprios, duas de cinco atualizações apagaram fatos verdadeiros que não haviam sido contraditos.
- O modelo resolveu corretamente um conflito de datas, ignorou mensagens irrelevantes e recuperou informações atualizadas em outro teste.
- O autor sugere instruir o modelo a não apagar memórias sem contradição e registrar todas as exclusões, mas não testou essa solução.
- O experimento custou menos de 30 centavos, e o autor lembra que é preciso encerrar a instância para não continuar pagando.
Capítulos
Seção intitulada “Capítulos”| Início | Capítulo | Resumo |
|---|---|---|
| 00:01 | O desafio de manter memórias corretas | O vídeo apresenta o problema de atualizar fatos sem apagar informações verdadeiras e resume as alegações da Tencent sobre o High Memory. |
| 03:11 | Preparação e execução do modelo | O autor explica a conversão comunitária, aluga uma GPU no RunPod e configura o modelo com llama.cpp. |
| 06:49 | Cinco testes de atualização de memória | O modelo é testado em correções, preferências, informações conflitantes, mensagens irrelevantes e recuperação de dados atualizados. |
| 10:38 | Resultados, limitações e recomendações | O autor destaca as exclusões indevidas, sugere salvaguardas ainda não testadas e comenta o custo do experimento. |
Citações
Seção intitulada “Citações”Salvar fatos é fácil. Decidir o que manter, reescrever ou descartar é a parte difícil. — 00:01
Trate isso como uma alegação, não como uma conclusão. — 02:10
Eu só disse que mudei de cidade. Isso é uma perda real de um fato verdadeiro. — 07:51
Nunca apague uma memória, a menos que a nova mensagem a contradiga. — 11:09
Conceitos e entidades
Seção intitulada “Conceitos e entidades”- High Memory (modelo): Modelo da Tencent de 30 bilhões de parâmetros desenvolvido para escrever e atualizar memórias de agents.
- Claude Opus 5 (modelo): Modelo usado como comparação nos resultados de escrita de memória relatados pela Tencent.
- Tencent (empresa): Empresa que lançou o High Memory e publicou os resultados de avaliação mencionados no vídeo.
- Mem0 (ferramenta): Framework de memória para agents citado como exemplo de sistema com um processo de escrita de memórias.
- Memos (ferramenta): Framework de memória para agents citado no vídeo.
- llama.cpp (ferramenta): Ferramenta usada para executar a conversão quantizada do modelo e disponibilizar uma API compatível com OpenAI.
- GGUF (conceito): Formato usado pela conversão comunitária do modelo para execução com llama.cpp.
- RunPod (empresa): Serviço usado para alugar a GPU A40 durante o experimento.
- A40 (ferramenta): GPU com 48 GB de memória usada para executar o modelo no experimento.
- Repatski (pessoa): Membro da comunidade que criou as versões GGUF quantizadas mencionadas no vídeo.
Tradução completa (pt-BR)
Seção intitulada “Tradução completa (pt-BR)”00:01 Aqui está uma conversa registrada na memória pelo modelo de memória high da Tencent, rodando em uma GPU que aluguei. Na primeira mensagem, digo que moro em Seattle e trabalho como engenheiro de back-end. Algumas mensagens depois, digo que me mudei para Austin. Agora, veja o banco de memória no final. Seattle sumiu e Austin está lá, como queremos. Mas a parte sobre eu ser engenheiro de back-end, que nunca alterei, também desapareceu. Esse pequeno deslize é toda a história da memória de agent. Salvar fatos é fácil. Decidir o que manter, o que reescrever e o que descartar é a parte difícil.
00:34 E um pequeno erro aí significa que seu agent esquece silenciosamente algo verdadeiro. A Tencent lançou um modelo de 30 bilhões de parâmetros, cerca de 3 bilhões ativos, que faz apenas esse trabalho. Eles dizem que ele iguala ou supera Claude Opus 5 como escritor de memória. Então, aluguei uma GPU, mostrei cada clique e executei cinco testes. Algumas coisas foram impressionantes, outras nem tanto. Aqui está o model card: high memory, 30B, A3B, licença Apache 2.0. É uma mistura
01:04 de experts. Então, apenas cerca de 3 bilhões de parâmetros trabalham em cada token. Esse detalhe da mistura de experts importa para o que vem a seguir. O modelo tem 128 experts pequenos por camada, e cada token usa apenas oito deles, além de um expert compartilhado. Portanto, a computação por token é como a de um modelo de 3 bilhões de parâmetros. Mas todos os 30 bilhões de parâmetros ainda precisam ficar na memória, porque qualquer token pode precisar de qualquer expert. Rápido para executar, grande para armazenar. Não é um chatbot. Frameworks de memória
01:37 como MemZero ou Memos têm um caminho de escrita. Depois da conversa, um modelo de linguagem a lê e decide o que vai para o banco de memória. A Tencent treinou esse modelo para ser esse escritor, primeiro destilando de um modelo professor, depois com reinforcement learning que pontua o próprio banco de memória. Por que se dar ao trabalho? Porque, sem uma camada de memória, um agent ou relê toda a conversa a cada vez, o que fica caro, ou a esquece. Com uma, você mantém declarações curtas, como “o usuário mora em Austin”, e depois recupera apenas as poucas que são relevantes. A qualidade dessas declarações é decidida no momento
02:10 certo, e essa é a etapa que este modelo substitui. Agora, os números entre quatro frameworks de memória: a Tencent relata uma pontuação média de 55,49; Claude Opus 5, ocupando a mesma função de escritor, obtém 54,62. Essa é a medição da própria empresa, feita em uma subamostra de 20%, então trate-a como uma alegação, não como um veredito. Mas, olhando mais de perto, na configuração do Mem0, Opus fica bem à frente no Loco M: 69 a 60.
02:41 O high memory vence no LongMemEval, 73 a 66. Então, não é melhor em tudo; vence na média por menos de um ponto. Um detalhe de que gosto: EverMem ficou de fora do treinamento e, ainda assim, o modelo alcança 56,89, contra 54,04. Essa é a melhor indicação. Ele generaliza, de acordo com os próprios números do autor. Consigo executá-lo aqui? Meu laptop tem uma RTX 4060 com 8 GB. O checkpoint oficial
03:11 tem 30 bilhões de parâmetros em BF16, cerca de 60 GB; não vai rolar. Um membro da comunidade chamado Repatski criou versões GGUF. O arquivo Q5 tem 21,4 GB e o Q4 tem 18,2. Importante: esta é uma conversão feita pela comunidade, não um lançamento oficial da Tencent, e o próprio card diz que um pequeno teste em inglês acertou completamente 23 de 34 casos. Armazenamento extra e duplicatas foram os problemas mais comuns. Tenha isso em mente ao ver meus resultados.
03:45 Uma observação rápida sobre o rótulo Q5: significa que os pesos são armazenados com cerca de 5,5 bits, em vez de 16, fazendo com que 60 gigabytes virem 21. No teste do próprio conversor, as quatro quantizações, de Q4 a Q8, tiveram pontuações quase iguais. Então escolhi Q5, o padrão recomendado pelo card. Com o arquivo do modelo e a memória de trabalho, preciso de uma GPU com mais de 24 gigabytes, então vamos alugar. Abra o console do RunPod, vá até pods e pressione deploy. A tela importante é a lista de GPUs. Ordeno por RAM, porque é isso que determina
04:17 se o modelo cabe ou não. A A40 tem 48 gigabytes e custava 59 centavos por hora na secure cloud. Uma 4090 é mais rápida, mas seus 24 gigabytes deixam pouco espaço para este arquivo, e ela custa mais. Com 48, tenho espaço de sobra. O template padrão do PyTorch serve. A única mudança que faço é no disco do container. 30 gigabytes é pouco para um modelo de 20 gigabytes mais as ferramentas de build, então
04:48 defino 60. O total fica em cerca de 60 centavos por hora. Há dois detalhes na tela que vale conhecer. A cobrança é por milissegundo, então um teste curto custa muito pouco, e o disco do container é apagado quando um pod é parado. Assim, para um experimento descartável como este, trato o pod como descartável e baixo o modelo novamente a cada vez. Deploy. Ele fica em execução em segundos, e o SSH funciona com uma chave que já está na minha conta.
05:29 Agora, o modelo. Baixo o arquivo Q5 e o template de chat com o cliente Hugging Face, 20 gigabytes, e o download terminou em cerca de meio minuto. Depois, llama.cpp. Compilo a revisão exata indicada pelo card do GGUF, porque versões mais antigas não conhecem essa arquitetura — e foi aqui que as coisas deram errado. Vou mostrar. A compilação falhou porque o compilador CUDA não estava no PATH. Uma linha resolveu o problema e, então, compilou.
06:15 A porta 8081 para iniciar o servidor já estava sendo usada pelo próprio proxy do RunPod. Mudei para 8090. São detalhes pequenos, mas fazem parte da configuração real. Usei as configurações do model card: sem modo de raciocínio, temperatura zero, e o escritor de memória deve ser consistente, não criativo. Ele carregou usando cerca de 24 GB de VRAM com um contexto de 32.000 tokens. Uma observação sobre por que usar llama.cpp: o model card oficial mostra o VLLM com os pesos completos, o que exige uma GPU muito maior.
06:49 O arquivo GGUF permite que o llama.cpp execute o mesmo modelo com cerca de 21 GB e expõe uma API no estilo OpenAI, com a qual meu script de teste se comunica. Uma observação sobre o método: não estou usando mem zero nem memos aqui. Escrevi um prompt de atualização simples. O modelo vê o banco de memória atual e uma mensagem nova e retorna operações de adição, atualização ou exclusão. Portanto, estes são meus testes, não o benchmark do 10 Cents. Todos os testes funcionam da mesma maneira. Você vê a mensagem ser enviada,
07:19 depois, as operações escolhidas pelo modelo e, em seguida, o banco de memória após cada etapa. Nunca edito essas saídas. O arquivo completo com os resultados está na descrição. Teste um: uma correção. Digo Seattle e engenheiro de back-end. Depois, faço um comentário sobre o tempo chuvoso, que ele ignora corretamente. Então digo que me mudei para Austin. >> O banco agora diz que me mudei para Austin e comecei um novo emprego em uma startup. Seattle desapareceu,
07:51 ótimo, mas meu trabalho como engenheiro de back-end também desapareceu. Eu só disse que mudei de cidade. Isso é uma perda real de um fato verdadeiro. Teste dois: uma preferência que muda. Primeiro, digo que sou vegetariano; depois, que cozinho comida italiana nos fins de semana; então digo que voltei a comer peixe, mas nenhuma outra carne. Ele atualiza a dieta corretamente: vegetariano, exceto peixe. Mas veja o
08:24 banco: a memória sobre cozinhar comida italiana foi apagada. Nada na minha mensagem pediu isso. É a segunda vez que ele descarta um fato válido durante uma atualização. Teste três: declarações conflitantes. O prazo é sexta-feira, dia 7. Meu cliente diz terça-feira, dia 4; depois, digo que meu gerente decidiu manter a sexta-feira.
08:55 Este está correto. Depois da mensagem do cliente, ele atualiza para terça-feira; depois da minha correção, apaga essa informação e registra sexta-feira, dia 7: uma memória com a informação mais recente. Teste quatro: esquecer de propósito. Digo Rust e Neovim; depois, uma fala de filme, uma pergunta sobre o tempo e uma piada. Nada disso são fatos sobre mim. Então menciono meu cachorro, Biscuit.
09:26 Perfeito neste caso. A fala, a pergunta e a piada não geram operação alguma. O banco mantém Rust, Neovim e o cachorro, nada mais. É exatamente isso que um bom escritor deve fazer. Teste cinco, o que importa. São 11 mensagens, com mudanças ao longo do caminho. O café vira chá verde. A reunião individual passa para quarta-feira, às 4:00. Estou me mudando para Bangalore e vendo o MacBook para comprar meu laptop Windows. Então faço quatro perguntas sobre o banco final.
10:04 Chá verde, quarta-feira às 4:00, Bangalore para um cargo de líder de equipe e o laptop Windows. Os quatro estão corretos e não há duplicatas. A memória do laptop ainda carrega o histórico antigo do MacBook, o que é desnecessário, mas a resposta está certa. Então, o que funcionou? Atualizar um conflito, descartar ruído e recuperar o valor mais recente: tudo deu certo. A velocidade também foi tranquila. Cada atualização de memória levou entre um décimo e seis décimos de segundo na A40.
10:38 O que não deu certo? Em dois dos cinco testes, uma atualização apagou silenciosamente um fato verdadeiro que nada havia contradito. Para um agent que se lembra de você por meses, essa é a falha que mais dói, porque você não vai percebê-la. Lembre-se do que é isto: cinco conversas curtas, uma quantização feita pela comunidade e meu próprio prompt simples. Isso não diz nada sobre as pontuações do benchmark, mas combina com o que o cartão do modelo alerta. Então, considero este modelo promissor e verifico as atualizações antes de confiar a ele qualquer coisa importante. Se
11:09 eu estivesse usando isso em um agent real, acrescentaria uma regra ao prompt de atualização dizendo para nunca apagar uma memória, a menos que a nova mensagem a contradiga, e registraria cada exclusão. Não testei essa correção, então considere-a uma ideia para experimentar, não um resultado. Quem deveria se importar? Qualquer pessoa que esteja criando um agent com Mem Zero ou Memos e pagando por um modelo grande a cada gravação de memória. A novidade aqui é um modelo open source pequeno que consegue fazer esse trabalho. E a parte que as pessoas esquecem: quando terminei, encerrei o pod e verifiquei que nada tinha ficado em execução. Um pod esquecido é o verdadeiro custo de alugar uma GPU.
11:44 O pod ficou em execução por menos de meia hora, mais ou menos, a cerca de 60 centavos por hora. O experimento inteiro custou menos de 30 centavos. A página de cobrança mostra o valor exato depois que ele é lançado. Se você está procurando GPUs baratas e confiáveis, uso RunPod, e o link está na descrição. Se quiser que eu integre este modelo a um framework de agent real e o teste direito, diga nos comentários qual você prefere.
Transcrição original
[00:01] Here’s one chat written into memory by Tencent’s high memory model running on a GPU I rented. In the first message, I say I live in Seattle and work as a back-end engineer. A few messages later, I say I moved to Austin. Now, look at the memory bank at the end. Seattle is gone and Austin is there, which is what we want. But the back-end engineer part, which I never changed, disappeared with it. That tiny slip is the whole story of agent memory. Saving facts is easy. Deciding what to keep, what to rewrite, and what to throw away is the hard part.
[00:34] And a small mistake there means your agent quietly forgets something true. Tencent released a 30 billion parameter model, about 3 billion active, that does only that job. They say it matches or beats Claude Opus 5 as as a memory writer. So, I rented a GPU, showed every click, and ran five tests. Some of it was impressive and some of it wasn’t. Here’s the model card, high memory, 30B, A3B, Apache 2.0 license. It’s a mixture
[01:04] of experts. So, only about 3 billion parameters work on each token. That mixture of experts detail matters for what comes next. The model has 128 small experts per layer, and each token only uses eight of them plus one shared expert. So, the compute per token is like a 3 billion parameter model. But all 30 billion parameters still have to sit in memory because any token might need any expert. Fast to run, big to store. It isn’t a chatbot. Memory
[01:37] frameworks like MemZero or Memos have a write path. After conversation, a language model reads it and decides what goes into the memory bank. Tencent trained this model to be that writer first by distilling from a teacher model, then with reinforcement learning that scores the memory bank itself. Why bother? Because without a memory layer, an agent either rereads the whole conversation every time, which gets expensive, or forgets it. With one, you keep short statements like user lives in Austin, and later you retrieve only the few that are relevant. The quality of those statements is decided at right
[02:10] time, and that is the step this model replaces. Now the number across four memory frameworks, Tencent reports an average score of 55.49, Claude Opus 5 in the same writer seat gets 54.62. That’s the vendor’s own measurement on a 20% subsample, so treat it as a claim and not a verdict. Look closer though, on the Mem0 setup, Opus is well ahead on Loco M 69 to 60.
[02:41] High memory wins on long Mem eval 73 to 66. So it isn’t better at everything, it wins on average by less than one point. One detail I like, Ever Mem was held out of training and the model still scores 56.89 against 54.04. That’s the best hint. It generalizes again by the author’s own numbers. Can I run it here? My laptop has an RTX 4060 with 8 GB. The official checkpoint
[03:11] is 30 billion parameters in BF16, roughly 60 GB, not happening. A community member called Repatski made GGF versions. The Q5 file is 21.4 GB and Q4 is 18.2. Important, this is a community conversion, not an official Tencent release, and its own card says a small English test got 23 of 34 cases fully right. Extra storage and duplicates were the common faults. Keep that in mind when you see my results.
[03:45] Quick note on that Q5 label, it means the weights are stored at about 5 and 1/2 bits instead of 16, which is how 60-gigabytes becomes 21. On the converter’s own test, the four quantizations from Q4 to Q8 scored almost the same, so I went with Q5, the default that card recommends. With the model file plus working memory, I want a card with more than 24 gigabytes, so we rent. Open the RunPod console, go to pods, and press deploy. The screen that matters is the GPU list. I sort by RAM because that decides
[04:17] whether the model fits at all. The A40 has 48 gigabytes and cost 59 cents an hour on the secure cloud. A 4090 is faster, but it’s 24 gigabytes is tight for this file, and it costs more. 48 gives me room. The default PyTorch template is fine. The one change I make is container disk. 30 gigabytes is too small for a 20-gigabyte model plus build tools, so I
[04:48] set 60. The total is about 60 cents an hour. Two details on the screen worth knowing. Billing is per millisecond, so a short test costs very little, and the container disk is erased when a pod is stopped. So, for a throwaway experiment like this, I treat the pod as disposable and download the model fresh each time. Deploy. It’s running in seconds, and SSH works with a key already on my account.
[05:29] Now, the model. I download the Q5 file and its chat template with Hugging Face client, 20 gigabytes, and it landed in about half a minute. Then llama.cpp. I build the exact revision the GGF card names because older builds don’t know this architecture and this is where things went wrong. So I’ll show it. The build failed because the CUDA compiler wasn’t on the path. One line fixed it and then it compiled.
[06:15] Starting the server port 8081 was already taken by RunPod’s own proxy. I moved it to 8090. Small things but they’re the real setup. I used the model card settings, no think mode, temperature zero, and memory writer should be repeatable, not creative. It loaded using about 24 GB of VRAM at a 32,000 token context. A word on why llama.cpp, the official model card shows VLLM with the full
[06:49] weights which needs a much bigger GPU. The GGUF file lets llama.cpp run the same model in about 21 GB and it exposes an OpenAI style API that my test script talks to. One note on method, I’m not using mem zero or memos here. I wrote a simple update prompt. The model sees the current memory bank and a new message and returns add, update, or delete operations. So these are my tests, not 10 cents benchmark. Each test works the same way. You see the message go in,
[07:19] then the operations the model chose, then the memory bank after each step. I never edit those outputs. The full results file is in the description. Test one, a correction. I say Seattle and back end engineer. Then a rainy weather comment which it ignores correctly. Then I say I moved to Austin. >> The bank now says I moved to Austin with a new job at a startup. Seattle is gone,
[07:51] good, but my job as a back-end engineer is gone, too. I only said I changed cities. That’s a real loss of a true fact. Test two, a changing preference. First vegetarian, then I cook Italian on weekends, then I say I started eating fish again, but no other meat. It updates the diet correctly, vegetarian except fish. But look at the
[08:24] bank, the Italian cooking memory has been deleted. Nothing in my message asked for that. Second time it dropped a valid fact during an update. Test three, conflicting statements. The deadline is Friday the 7th. My client says Tuesday the 4th, then I tell it my manager decided to keep Friday.
[08:55] This one is clean. After the client message, it updates to Tuesday, and after my correction, it deletes that and writes Friday the 7th, one memory latest truth. Test four, forgetting on purpose. I say Rust and Neovim, then a movie quote, a weather question, and a joke. None of those are facts about me. Then I mention my dog Biscuit.
[09:26] Perfect here. Quote, question, and joke produce no operations at all. The bank holds Rust, Neovim, and the dog, nothing else. This is exactly what a good writer should do. Test five, the one that matters. 11 messages with changes along the way. Coffee becomes green tea. The one-on-one moves to Wednesday at 4:00. I’m moving to Bangalore and I sell the MacBook for my Windows laptop. Then I ask four questions from the final bank.
[10:04] Green tea, Wednesday at 4:00, Bangalore for a team lead role, and the Windows laptop. All four correct and no duplicates. The laptop memory still carries the old MacBook history, which is clutter, but the answer is right. So, what held up? Updating a conflict, discarding noise, and recalling the latest value all worked. Speed was easy, too. Each memory update took between a tenth and six tenths of a second on the A40.
[10:38] What didn’t? In two of five tests, an update silently deleted a true fact that nothing had contradicted. For an agent that remembers you for months, that’s the failure that hurts because you won’t notice it. Remember what this is. Five small conversations, a community quantization, and my own simple prompt. It says nothing about the benchmark scores, but it does match what the GG of card warns about. So, I treat this model as promising and check its updates before trusting it with anything important. If
[11:09] I were using this in a real agent, I would add a rule to the update prompt that says never delete a memory unless the new message contradicts it, and I would log every delete. I haven’t tested that fix, so take it as an idea to try, not a result. Who should care? Anyone building an agent on Mem Zero or Memos who pays a big model for every memory write. A small open model that does this job at all is the news here. And the part people forget when I finish, I terminated the pod and checked that nothing was left running. A forgotten pod is the real cost of renting a GPU.
[11:44] The pod ran for under half an hour or so at about 60 cents an hour. The whole experiment cost under 30 cents. The billing page shows the exact figure once it posts. If you’re looking for cheap and reliable GPUs, I use RunPod and the link is in the description. If you want me to plug this model into a real agent framework and test it properly, tell me which one in the comments.