Modelo de programação de 12B em uma GPU de laptop com 8 GB? Eu testei

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: 12B Coding Model on an 8GB Laptop GPU? I Tested It · Canal: Prompt Engineer 48 · 07:29 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Inferência e otimização de modelos, Modelos de IA, Modelos locais e open source

Resumo

O vídeo testa o Mellum 2.1, modelo de programação da JetBrains com 12 bilhões de parâmetros, em um laptop com GPU de 8 GB, usando Ollama e a quantização Q4_K_M. Apesar de não caber inteiramente na VRAM disponível, o modelo divide as camadas entre GPU e memória do sistema e gera cerca de 57 tokens por segundo. Ele passa em testes de código, corrige um jogo Snake a partir de uma descrição do problema e faz uma chamada de ferramenta simples, mas o apresentador não testa loops longos de agente nem o contexto máximo. Os resultados indicam que é uma opção local viável, embora o Qwen 3.5 9B supere o modelo em alguns benchmarks citados.

Pontos-chave

O Mellum 2.1 tem 12 bilhões de parâmetros no total, com 2,5 bilhões ativos por token, e usa uma arquitetura de mixture of experts.
O modelo tem context window de 131.072 tokens e licença Apache 2.0.
A quantização Q4_K_M ocupa 8,1 GB, então o modelo não cabe totalmente na GPU de 8 GB usada no teste.
Com as camadas divididas entre GPU e memória do sistema, o modelo manteve uma velocidade de aproximadamente 57 tokens por segundo.
O modelo criou uma função Python para combinar intervalos e passou nos cinco testes assert usados pelo apresentador.
A primeira versão do jogo Snake tinha um erro; após receber apenas a descrição do sintoma, o modelo corrigiu uma linha e o jogo passou a funcionar.
Em uma chamada simples de ferramenta, escolheu executar wc -l readme.md para contar as linhas do arquivo.
O teste não avaliou loops longos de agente, o benchmark SWE-bench por conta própria nem o uso da context window máxima.
Segundo os números apresentados, o Qwen 3.5 9B fica à frente em alguns benchmarks, enquanto o Mellum 2.1 tem vantagem em várias métricas de programação.

Capítulos

Início	Capítulo	Resumo
00:00	Apresentação do Mellum 2.1 e benchmarks	O apresentador apresenta o modelo e compara os resultados divulgados pela JetBrains com os de outros modelos.
02:06	Execução local e quantização	O modelo é carregado com Ollama em uma GPU de 8 GB, usando Q4_K_M e divisão de camadas entre GPU e memória do sistema.
03:10	Testes de programação e correção de erros	O modelo resolve um exercício de intervalos, cria e corrige um jogo Snake e faz uma chamada simples de ferramenta.
05:18	Raciocínio, velocidade e limitações do teste	O apresentador avalia respostas de conhecimento e matemática, comenta a velocidade e delimita o que não testou antes de concluir.

Citações

12 bilhões de parâmetros rodando nesta GPU de laptop com 8 GB a cerca de 57 tokens por segundo. — 00:00

O que posso testar é se ele roda e se acerta as coisas. — 02:06

Ele estava quebrado na primeira tentativa e foi corrigido na segunda apenas com a descrição do sintoma. — 04:44

Se você tem um laptop com 8 GB e quer um modelo local de programação que pensa, este funciona. — 06:22

Conceitos e entidades

Mellum 2.1 (modelo): Modelo de programação da JetBrains testado localmente, com 12 bilhões de parâmetros totais e 2,5 bilhões ativos por token.
JetBrains (empresa): Empresa responsável pelo Mellum 2.1 e pelos resultados de benchmark apresentados no vídeo.
Ollama (ferramenta): Ferramenta usada para baixar e executar localmente a versão quantizada do modelo.
Q4_K_M (conceito): Quantização recomendada no vídeo para executar o modelo, com tamanho informado de 8,1 GB.
GGUF (conceito): Formato de arquivo de modelo citado na página de quantizações.
Qwen3.5 9B (modelo): Modelo comparado ao Mellum 2.1, com resultados superiores em alguns dos benchmarks mencionados.
SWE-bench (conceito): Benchmark de programação cujos resultados para o Mellum 2.1 foram informados pela JetBrains, mas não reproduzidos pelo apresentador.
LiveCodeBench (conceito): Benchmark de programação no qual o Mellum 2.1 obteve pontuação superior à do modelo comparado, segundo os dados exibidos.
Apache License 2.0 (conceito): Licença indicada para o Mellum 2.1, que permite uso comercial.

Tradução completa (pt-BR)

00:00 12 bilhões de parâmetros rodando nesta GPU de laptop com 8 GB a cerca de 57 tokens por segundo. Este é o modelo de raciocínio Mellum 2.1, da JetBrains, e você pode vê-lo raciocinando aqui mesmo no meu sistema local. E, só para deixar claro, nada disso está rodando em uma GPU alugada. Vamos testar e vou mostrar onde ele falha. Sou engenheiro de prompts e testei isso no meu próprio laptop. Então, tudo o que você vai ver a seguir é real. Certo, este é o cartão do modelo no Hugging Face. É o Mellum 2.1, com 12 bilhões de parâmetros no total, mas é uma

00:32 mistura de especialistas, então apenas 2,5 bilhões ficam ativos para cada token. Se você olhar aqui, há 64 especialistas, e oito deles são ativados por token. A context window é de 131.072 tokens, e a licença é Apache 2.0, então você pode usá-lo comercialmente. Agora, a JetBrains diz que a arquitetura não mudou em relação ao Mellum 2. O que mudou foi o pós-treinamento. A maior parte do trabalho foi dedicada ao aprendizado por reforço em repos reais, com shell e ferramentas de arquivos, e a recompensa é dada quando os testes passam. Certo, aqui estão os números

01:03 divulgados pela JetBrains — e lembre-se de que são autodeclarados — no SWE-bench Verified, o Mellum 2.1 obteve 47,0, e o antigo Mellum 2 obteve 2,0. No LiveCodeBench versão 6, fez 82,0; no AIME, 83,3; e no TerminalBench 2.1, 17,4. Mas, se você olhar a coluna à direita, o Qwen 3.59B está à frente em vários desses testes. Ele fez 50,0 no SWE-bench Verified, 86,7 no AIME e 77,8 no GPQA Diamond, enquanto o Mellum fez

01:34 64,6. Onde o Mellum vence é na seção de programação: LiveCodeBench, 82,0 contra 75,4; HumanEval+, 91,5 contra 89,6; e MBPP+, 79,4 contra 69,8. Ele também vence no uso de ferramentas do BFCL versão 4, com 62,3 contra 58,5, e supera o Gemma 4E4B em todas as linhas de programação desta tabela. Então, a leitura honesta é esta: ele fica em segundo lugar, bem próximo de um modelo 9B na maioria desses testes, com menos parâmetros ativos, e é open source sob a licença Apache

02:06 2.0. E os números de uso de agentes foram obtidos no próprio harness da JetBrains, então não posso confirmá-los no meu laptop. O que posso testar é se ele roda e se acerta as respostas. Guarde o número de velocidade, porque há uma surpresa sobre como ele cabe em 8 GB. Para rodá-lo localmente, a JetBrains tem um repo GGUF, e estes são os tamanhos. BF16 tem 24,3 GB, Q8 tem 12,9, e o Q4KM que eles recomendam tem 8,1 GB. Minha placa tem 8 GB de VRAM, e três desses gigabytes já estavam

02:39 sendo usados por outros aplicativos, então ele não vai caber inteiramente. O que vou fazer é baixar o Q4KM com um comando do Ollama e executá-lo. Depois que carrega, o Ollama PS indica 25% de CPU e 75% de GPU. Então, as camadas ficam divididas entre minha GPU e a memória do sistema e, como apenas 2,5 bilhões de parâmetros ficam ativos por token, ele ainda consegue acompanhar. O primeiro carregamento levou cerca de 32 segundos. A página do GGUF também informa quanta qualidade cada quantização preserva em relação ao original BF16. O Q4KM tem divergência KL de

03:10 0,075 e corresponde ao token mais provável em 88,0% das vezes, enquanto o Q8 fica em 96,1% e o MXFP41, em 85,6%. Então, o Q4KM é uma troca real, não é de graça. Uma coisa a observar aqui: aquele primeiro prompt foi lento, cerca de 36 segundos, porque o modelo ainda estava aquecendo. Depois disso, estabiliza em cerca de 57 tokens por segundo. O primeiro teste é de código puro. Pedi uma função Python para mesclar intervalos, em que intervalos que se tocam, como de um a três e de três a cinco, precisam ser mesclados. Ele pensou um pouco e escreveu a função: 615 tokens em cerca de 26 segundos. E não me limitei a ler o código. Executei cinco asserts, incluindo a lista vazia e o caso dos intervalos que se tocam, e você pode ver que todos passam. Então, é um bom começo na parte de programação. Em seguida, pedi um jogo completo de Snake em um único arquivo HTML, com canvas, teclas de seta, pontuação, fim de jogo, reinício com a barra de espaço e aumento da velocidade conforme a pontuação. Ele escreveu 3.147 tokens em cerca de 56 segundos, e o arquivo

03:40 intervalos como de um a três e de três a cinco precisam ser mesclados. Ele pensou um pouco e escreveu a função, com 615 tokens, em cerca de 26 segundos. Então, não apenas li o código: executei-o com cinco asserções, incluindo a lista vazia e o caso de intervalos encostados, e você pode ver que todas passaram. Então, é um bom começo para a parte de programação. Em seguida, pedi um jogo completo da cobrinha em um único arquivo HTML, com canvas, teclas de seta, pontuação, fim de jogo, reinício com a barra de espaço e aumento de velocidade conforme a pontuação subisse. Ele escreveu 3.147 tokens em cerca de 56 segundos, e o arquivo

04:11 tem apenas cerca de 3,5 kilobytes. Abri no Chrome, e o canvas é desenhado e a pontuação aparece, mas nada se move. Então, esta primeira versão está quebrada. Li o código, e o bug está em uma linha. A cobra começa com direção zero, então, no primeiro movimento, é como se ela batesse em si mesma, e o jogo acaba antes mesmo de você apertar qualquer coisa. Então, disse apenas o que observei: “Nada se move, e as teclas de seta não fazem nada.” Ele pensou por cerca de 24.000 caracteres, 7.700 tokens, em 158 segundos, e alterou aquela linha. Aí a cobra começa a se mover para a direita. Depois, eu

04:44 joguei a versão corrigida usando um pequeno script que pressiona as teclas de seta de verdade, e ela fez 12 pontos em 24 segundos sem morrer. Então, não funcionou na primeira tentativa, mas foi corrigida na segunda com base apenas em um sintoma. Isso é importante para agents. Dei a ele duas ferramentas, executar shell e ler arquivo, e perguntei quantas linhas há em readme.md. Ele escolheu executar shell e enviou o comando wc -l readme.md com os argumentos no formato correto. Isso levou cerca de 10 segundos. É uma chamada correta, então é um bom sinal. Mas foi só uma chamada. Não executei um longo loop de agent, então não posso dizer como ele se sai ao longo de 50 etapas em um repo real.

05:18 Agora, duas verificações rápidas. Primeiro, uma armadilha. Perguntei o que retorna um dataframe do pandas do Nike — um método que não existe. Ele disse que o método não existe e que chamá-lo gera um erro de atributo, em vez de inventar um tipo de retorno. Era essa a resposta que eu queria. Depois, um problema de matemática com resposta conhecida: “Quantos números inteiros até 1.000 são divisíveis por três ou cinco, mas não por 15?” A resposta é 401, e ele chegou a 401 em cerca de 15 segundos e 838 tokens. Uma coisa sobre

05:48 este modelo é que ele sempre pensa primeiro, e você pode ler tudo. No problema de matemática, escreveu cerca de 2.200 caracteres de raciocínio, e a resposta em si tinha três caracteres: 401. No jogo de Snake, escreveu cerca de 6.000 caracteres de raciocínio e depois aproximadamente 3.500 caracteres de código. Então, boa parte desses 57 tokens por segundo é raciocínio, não a resposta, e é por isso que o jogo de Snake levou 56 segundos. Agora, a velocidade se manteve quase constante nos cinco testes. Medi 55,9, 57,0, 57,1, 57,1 e 57,1 tokens por

06:22 segundo. Então, ele não ficou mais lento em respostas de até cerca de 3.000 tokens. A execução de correção, com uma conversa mais longa, ficou em 54. Não medi além disso. Então, aqui está o que não testei. Não forcei o contexto de 128K, porque, nesse tamanho, o uso de memória vai ser muito maior do que os meus 8 gigabytes comportam. Não executei o SWE-Bench por conta própria e não rodei loops longos de agent. Se você tem um laptop com 8 gigabytes e quer um modelo de programação local que pense, este funciona. Se precisa das melhores pontuações com agents, a própria tabela da JetBrains diz que um Qwen 9B ainda fica um pouco à frente no SWE-Bench.

06:58 Se você está procurando GPUs baratas e confiáveis, eu uso o RunPod, e o link está na descrição. Então, neste vídeo, vimos como rodar o Mellum 2.1 localmente em um laptop com 8 gigabytes usando o Ollama e o que ele fez com código, ferramentas e raciocínio. Se tiver interesse, experimente o Q4KM no seu próprio sistema e me conte como foi. Modelo usado: JetBrains Mellum 2.1 12B A2.5B thinking. A seguir, vou fazer um teste de

07:29 contexto longo, então confira o próximo vídeo. Se quiser mais testes honestos de modelos locais como este, inscreva-se e nos vemos no próximo vídeo.

Transcrição original

[00:00] 12 billion parameters running on this 8 GB laptop GPU at about 57 tokens a second. This is JetBrains new Mel 2.1 thinking model, and you can see it reasoning right here on my local system. Now, mind you, nothing here is on a rented GPU. Let’s go ahead and test this out, and I’ll show you where it breaks to. I’m prompt engineer, and I tested this on my own laptop. So, everything you see next is real. All right, this is the model card on Hugging Face. It’s Mel 2.1 12 billion parameters in total, but is a

[00:32] mixture of experts, so only 2.5 billion are active for each token. If you look here, there are 64 experts, and eight of them are activated per token. The context window is 131,072 tokens, and the license is Apache 2.0, so you can use it commercially. Now, JetBrains says the architecture did not change from Mel 2. What changed is the post-training. Most of the work went into reinforcement learning in real repositories with a shell and file tools, and the reward is when the tests pass. Okay, so here are the numbers

[01:03] JetBrains reports, and mind you, these are self-reported on SWE-bench. Verified, Mel 2.1 gets 47.0, and the old Mel 2 got 2.0. LiveCodeBench version 6 is 82.0, AIME is 83.3, and TerminalBench 2.1 is 17.4. But, if you look at the column on the right, Qwen 3.59B is ahead on several of these. It has 50.0 on SWE-bench. Verified, 86.7 on AIME, and 77.8 on GPQA Diamond, where Mel has

[01:34] 64.6. Where Mel wins is the coding block LiveCodeBench 82.0 against 75.4, HumanEval+ 91.5 against 89.6, and MBPP+ 79.4 against 69.8. It also wins on BFCL version 4 tool use 62.3 against 58.5, and it beats Gemma 4E4B on every coding row in this table. So, the honest read is this, it’s a close second to a 9B model on most of these with fewer active parameters and it’s open under Apache

[02:06] 2.0. And the agentic numbers were run in JetBrains’ own harness, so I can’t confirm those on my laptop. What I can test is whether it runs and whether it it gets things right. Hold on to the speed number because there’s a surprise about how it fits in 8 GB. Now, for running it locally, JetBrains has a GBUF repo and these are the sizes. BF16 is 24.3 GB, Q8 is 12.9 and the Q4KM they recommend is 8.1 GB. My card has 8 GB of VRAM and three of those were already

[02:39] used by other apps, so it won’t fit fully. What I’m going to do is pull the Q4KM with Ollama one command and go ahead and run it. Once it loads, Ollama PS says 25% CPU and 75% GPU. So, the layers split between my GPU and my system memory and because only 2.5 billion parameters are active per token, it still keeps up. First load took about 32 seconds. The GGOF page also lists how much quality each quant keeps against the BF16 original. Q4KM has a KL

[03:10] divergence of 0.075 and matches the top token 88.0% of the time while Q8 is at 96.1% and the MXFP41 is at 85.6. So, Q4KM is a real trade, not free. The one thing to mind here, that first prompt was slow about 36 seconds because the model was still warming up. After that, it settles to about 57 tokens a second. First test is plain code. I asked for a Python function merge intervals where touching

[03:40] intervals like one to three and three to five have to merge. It thought for a bit and wrote the function 615 tokens in about 26 seconds and then I did not just read it. I ran it against five asserts including the empty list and the touching case and you can see all pass. So, that’s a good start for the coding side. Next, I asked for a full snake game in a single HTML file, canvas, arrow keys, score, game over, restart on space, and speed going up with the score. It wrote 3,147 tokens in about 56 seconds and the file

[04:11] is only about 3.5 kilobytes. I opened it in Chrome and the canvas draws and the score shows but nothing moves. So, this first draft is broken. I read the code and the bug is one line. The snake starts with direction zero, so the very first move counts as the snake hitting itself and it’s game over before you press anything. So, I told it only what I saw, “Nothing moves and the arrow keys do nothing.” It thought for about 24,000 characters, 7,700 tokens in 158 seconds and it changed that one line. So, the snake starts moving right. Then, I

[04:44] played the fixed version with a small script that presses the real arrow keys and it scored 12 in 24 seconds without dying. So, it was broken on the first try and fixed on the second from a symptom alone. This one matters for agents. I gave it two tools, run shell and read file, and asked how many lines are in readme.md. It picked run shell and send the command wc -l readme.md with the right argument shape. That took about 10 seconds. That’s one clean call, so it’s a good sign. But, it’s one call. I did not run a long agent loop, so I can’t tell you how it does across 50 steps in a real

[05:18] repo. Now, two quick checks. First, a trap. I asked what pandas dataframe from Nike returns, a method that does not exist. It said the method does not exist and that calling it raises an attribute error instead of making up a return type. That’s the answer I wanted. Then, a math one with a known answer, “How many integers up to 1,000 are divisible by three or five but not 15?” The answer is 401 and it got 401 in about 15 seconds and 838 tokens. One thing about

[05:48] this model is that it always thinks first and you can read all of it. On the math puzzle it wrote about 2,200 characters of thinking and the answer itself was three characters 401. On the snake game it wrote about 6,000 characters of thinking and then about three and a half thousand characters of code. So good part of those 57 tokens a second is thinking and not the answer and that’s why the snake game took 56 seconds. Now the speed stayed almost flat across all five tests. I measured 55.9, 57.0, 57.1, 57.1 and 57.1 tokens a

[06:22] second. So it did not slow down on outputs up to about 3,000 tokens. The repair run with a longer conversation came in at 54. Past that I did not measure. So here’s what I did not test. I did not push the 128K context because at that size the memory use is going to be a lot higher than my 80 gigabytes can take. I did not run SWE-Bench myself and I did not run long agent loops. If you have an 8 gigabyte laptop and you want a local coding model that thinks this runs. If you need top agent scores, JetBrains own table says a 9B QN is

[06:58] still a bit ahead on SWE-Bench. If you’re looking for cheap and reliable GPUs, I use RunPod and the link is in the description. So in this video we saw how to run Melom 2.1 locally on an 8 gigabyte laptop with Ollama and what it did on code, tools and reasoning. If you’re interested go ahead and try the Q4KM on your own system and let me know how it goes. Model used JetBrains Melom 2.1 12B A2.5B thinking. Next up I’ll push a long

[07:29] context test so check out the next video. If you want more honest local model tests like this one, subscribe and I’ll see you in the next video.