Como rodar modelos uncensored locais em GPUs de 8 GB

Modelos uncensored locais cabem em GPUs modestas porque a quantização ternária comprime um modelo de 27 bilhões de parâmetros de cerca de 54 GB para um arquivo de 5,95 GB. A edição de pesos que remove as recusas chama-se abliteration, e a escolha do arquivo certo depende da memória que sobra para o cache de contexto.

O que são modelos uncensored locais e por que eles existem

Modelos uncensored locais são cópias de modelos de linguagem abertos, quantizados para caber em GPU e editados para reduzir as recusas de segurança. A proposta do vídeo do canal Claude Code, publicado em outubro de 2026, é mapear uma escolha para GPUs de 8, 12, 16 e 24 GB.

Duas técnicas sustentam essa viabilidade. A primeira é a quantização, que reduz os bits por peso e encolhe o arquivo. A segunda é a abliteration, que edita os pesos para que o modelo não consiga mais escrever a direção interna associada à recusa.

Antes de escolher, o autor do vídeo deixa um aviso honesto: um modelo sem recusas responde o que você pedir, então a responsabilidade pela solicitação é sua. Rode esses arquivos apenas na sua máquina e trate o conteúdo como material de estudo.

Como a quantização ternária comprime um modelo de 27B para 5,95 GB

A conta básica é simples: tamanho do arquivo = parâmetros × bits por peso ÷ 8. A 16 bits, um modelo de 27 bilhões de parâmetros precisa de cerca de 54 GB. A 4 bits, o formato Q4_K_M do llama.cpp usa 4,8944 bits por peso, o que dá aproximadamente 16,5 GB — um arquivo para GPU de 24 GB, não de 8 GB.

O arquivo de 5,95 GB citado no vídeo usa cerca de 1,8 bits por peso (5,95 × 8 ÷ 27 ≈ 1,76). Os arquivos são descritos como ternários: cada peso assume um de três valores, o que equivale a cerca de 1,6 bits. Os arquivos disponíveis rodam a 1,8 e 2,1 bits, e as fontes do vídeo não explicam para onde vão os bits extras.

A segunda técnica é a precisão mista por tensor. Os builds GSQRCO do autor "0B_Server_Ex" dão a cada um dos 851 tensores seu próprio tipo de quantização, de 2,50 a 3,50 bits por peso. Segundo o model card, o arquivo IQ3S de 11,80 GB fica a menos de 1% da precisão total no WikiText 2, contra 1,9% do IQ3S uniforme de 12,42 GB. São medições do próprio autor, não independentes.

Como a abliteration remove a recusa editando os pesos

A base científica vem do artigo de Arditi e colegas, de 2024, Refusal in Language Models Is Mediated by a Single Direction. Os autores registraram as ativações de 128 prompts nocivos e 128 inofensivos, subtraíram as médias e obtiveram um vetor — a direção de recusa — no residual stream, o vetor que carrega o estado de cada token entre as camadas.

Em vez de subtrair o componente em tempo de execução, o artigo edita os pesos que escrevem no residual stream, removendo deles a projeção na direção de recusa. Depois disso, o modelo não consegue mais escrever esse vetor. No Llama 3 de 70 bilhões, a recusa caiu de cerca de 99% para 4%, e o MMLU passou de 79,9 para 79,8. Em TruthfulQA, a queda variou de 1,0 a 3,5 pontos entre os 13 modelos testados, que iam até 72 bilhões de parâmetros.

O guia de Maxime Labonne sobre abliteration segue a mesma receita em quatro passos: registrar ativações, calcular a diferença das médias, escolher a melhor direção única e editar os pesos. Labonne mediu quedas em todos os benchmarks que testou e recuperou a maior parte com um treinamento adicional chamado DPO. O custo da edição depende do modelo e do teste.

Heretic: automatizando a edição com Optuna e KL divergence

A ferramenta Heretic automatiza a escolha de onde e quão forte ablar. Ela edita duas matrizes por camada, a projeção de saída da atenção e a projeção down do MLP, ambas escritas no residual stream. Cada matriz recebe a própria direção de recusa daquela camada.

Para decidir os ajustes, o Heretic usa o otimizador Optuna com TPE, que aprende quais configurações funcionam melhor. Ele minimiza dois números ao mesmo tempo: a contagem de recusas e a divergência KL em relação ao modelo original. A KL mede o quanto as previsões de próximo token mudaram; um valor baixo indica que o modelo ainda se comporta como o original em texto normal.

No exemplo do Readme com o Gemma 3 de 12 bilhões, o Heretic alcançou 3 recusas em 100 prompts a 0,16 de KL, contra 0,45 a 1,04 das ablações manuais. A execução leva cerca de 20 a 30 minutos em GPUs de consumo. Um dos model cards citados no vídeo relata a fusão de um LoRA do Heretic que alterou 34 dos 851 tensores, com KL de 0,0135. São números reportados pelos próprios autores.

O imposto oculto: cache de contexto e MTP na sua VRAM

Os pesos são só parte do que a GPU segura. Para cada token na janela de contexto, o cache guarda as chaves e valores que as camadas de atenção calcularam, e esse cache cresce a cada token na memória de vídeo. Um model card citado no vídeo dá um exemplo prático: numa GPU de 16 GB, com arquivo de 13 a 13,3 GB, cabem cerca de 110.000 tokens sem MTP e 80.000 com ele ligado.

MTP, ou multi-token prediction, é uma parte extra do modelo que antecipa tokens futuros para acelerar a geração. Ela consome memória, custa cerca de 30.000 tokens de contexto no exemplo acima e deixa o arquivo maior: no build Bonsai V2, o arquivo passa de 7,21 GB para 7,66 GB.

A ideia por trás do MTP é o speculative decoding descrito por Leviathan e colegas em 2022 no artigo Fast Inference from Transformers via Speculative Decoding: um rascunhador propõe vários tokens e o modelo principal valida todos numa única passada em lote, mais barata do que gerar um por um. O artigo original relatou aceleração de 2 a 3 vezes no T5-XXL, com saídas idênticas. Nos builds do vídeo, as alegações variam de 1,3x a 3,02x de throughput — todas medições dos próprios autores.

Alguns modelos misturam atenção com camadas que guardam um resumo de tamanho fixo, em vez de cache crescente. No Qwen 3.8 citado no vídeo, o apresentador estima que apenas 16 das camadas mantêm cache de chaves e valores, o que reduziria o custo de contexto longo. Sem o tamanho exato do cache por token no model card, ele recomenda usar os números do build de 16 GB como referência.

Escolhas por faixa de GPU: 8, 12, 16 e 24 GB

A regra de encaixe em uma linha: tamanho do arquivo + cache + arquivos de visão deve ficar abaixo da memória da sua GPU. O arquivo de 5,95 GB com visão Q8 (629 MB) numa GPU de 8 GB deixa cerca de 1,4 GB — pouco para contexto longo, então use janelas menores.

A tabela abaixo resume as escolhas principais conforme apresentadas no vídeo de outubro de 2026. Os tamanhos vêm das páginas dos modelos; as velocidades são execuções do modelo base relatadas pelo autor do vídeo e por outros donos, não testes dos builds exatos.

FAQ

• Quantos GB precisa um modelo de 27 bilhões de parâmetros? A 16 bits, cerca de 54 GB. Com quantização Q4 de cerca de 4,9 bits por peso, o arquivo cai para perto de 16,5 GB, e builds ternários chegam a 5,95 GB, cerca de 1,8 bits por peso.

• Modelo uncensored é igual a zero recusas garantidas? Não. Cada contagem de recusas é um teste próprio do autor, no próprio conjunto de prompts, sem replicação independente citada. Um "zero de 100" não é comparável a um "zero de 465" de outro model card.

• Abliteration destrói a qualidade do modelo? O custo depende do modelo e do teste. No artigo de 2024, o MMLU do Llama 3 70B caiu de 79,9 para 79,8, mas Maxime Labonne mediu quedas maiores e recuperou a maior parte com DPO. Ferramentas como o Heretic minimizam a divergência KL justamente para limitar esse dano.

• Posso rodar esses modelos totalmente offline? Sim, a execução é local na sua GPU, e alguns builds exigem forks específicos do llama.cpp. Lembre que offline não elimina a responsabilidade sobre o que você pede ao modelo.

• Por que meu modelo não cabe mesmo com arquivo menor que a VRAM? Porque o arquivo não é tudo: o cache de contexto, a cabeça de MTP e eventuais arquivos de visão também ocupam memória de vídeo. Some tudo antes de comparar com a capacidade da placa.

Source video