Saiga Llama 3 8B com 10 GB de VRAM: como o Habr chegou a 93% de precisão com «Guerra e Paz»

O Habr AI publicou uma análise prática de como rodar o Saiga Llama 3 8B em uma RTX 3080 doméstica com 10 GB de memória de vídeo para resumir os dois primeiros volumes de «Guerra e Paz». O experimento mostrou que o principal problema de um LLM local nessa tarefa não é apenas a memória limitada, mas também as alucinações em fatos, nomes e cronologia.

Rodando com 10 GB

O autor montou um pipeline em torno do IlyaGusev/saiga_llama3_8b com quantização de 4 bits e executou o modelo em uma RTX 3080 doméstica com 10 GB de VRAM. O texto completo dos dois volumes não cabia na memória, então foi preciso dividir o romance por capítulos e limitar o tamanho de cada trecho. Depois de uma série de testes, o meio-termo viável ficou em cerca de 7500 caracteres por trecho: com menos, perdia-se contexto demais; com mais, crescia o risco de falhas e de estouro da VRAM. A stack usou transformers e bitsandbytes, e o autor verificou a precisão dos resumos com o Gemini.

Pelo caminho surgiram efeitos colaterais inesperados: o Qwen2.5-7B-Instruct chegou a entregar, em vez de um resumo, um longo trecho de código Python com dicas de bibliotecas. A ideia da «janela deslizante», em que o modelo resume um resumo já pronto, também foi descartada rápido: a qualidade se degradava como no telefone sem fio, e o tempo de processamento acabava ficando bem maior.

De onde vieram as alucinações

O prompt ingênuo parecia funcionar no começo: o modelo gerava resumos curtos de 3–5 frases, mas logo passava a confundir sobrenomes, relações de parentesco e cronologia. Pierre Bezukhov podia virar de repente filho dos Rostov, e o príncipe Vassili Kuraguin, seu pai. Quando se acrescentou ao prompt de sistema uma base de personagens com regras rígidas, os erros não sumiram, mas mudaram de lugar: a rede passou a formular com mais confiança conclusões factualmente erradas sobre capítulos específicos.

A falha mais reveladora envolveu Nikolai Rostov. No episódio depois da batalha de Schöngrabern, o modelo concluiu que o herói havia morrido, embora no texto ele esteja apenas ferido e siga na trama mais adiante. O autor explica isso como um desvio nas probabilidades: Tolstói descreve por muito tempo a dor, o sangue e a sensação de morte iminente, enquanto a breve confirmação de que Rostov está vivo aparece depois e pesa menos para o modelo. A checagem dos logits mostrou que um prompt pode, sim, deslocar radicalmente a escolha do próximo token.

«É proibido matar os heróis!

Nikolai Rostov sobrevive em Schöngrabern».

O que realmente ajudou

Na versão final do pipeline, as regras ficaram bem diretas: conferir os sobrenomes com a base de personagens, não inventar tramas românticas, lembrar que a ação se passa em 1805 e avisar com honestidade quando um trecho for interrompido antes do desfecho. Em paralelo, o autor apertou os parâmetros de geração: temperatura 0,1, top_p 0,85 e repetition_penalty 1,15. A ideia era simples: menos criatividade, menos tentação de completar Tolstói por conta própria. E a resposta fica mais estável.

• Quantização de 4 bits em vez de carregamento completo
• Divisão do texto por capítulos com limite de cerca de 7500 caracteres
• Prompt de sistema rígido com base de personagens
• Temperatura baixa e top_p limitado
• Pós-processamento de erros raros em sobrenomes

Esse conjunto de medidas não tornou o sistema livre de erros, mas reduziu drasticamente o número de alucinações críticas. A avaliação final com o Gemini 3 Flash deu uma precisão factual média de cerca de 93%, e a maior parte dos capítulos ficou na faixa de 90–98%. Os deslizes mais chamativos ficaram no nível de tokens e morfemas: em um ponto apareceu «Pierre Bezdarovski», um híbrido do sobrenome Bezukhov com a palavra russa para «medíocre». O autor acredita que falhas raras assim são mais fáceis de pegar com pós-processamento do que complicando ainda mais o prompt.

O que isso significa

Esse caso mostra algo importante para LLMs locais: mesmo em uma placa de vídeo de consumo é possível montar um pipeline útil para textos longos, mas o sucesso depende de mais do que o modelo e a quantidade de VRAM. Muitas vezes o que decide são instruções rígidas, controle da geração e pós-processamento, ou seja, a engenharia em volta do LLM, e não um botão mágico de «leia o livro por mim».