Saiga Llama 3 8B em 10 GB VRAM: Como a Habr Alcançou 93% de Precisão em Guerra e Paz
Saiga Llama 3 8B foi executado com sucesso em uma RTX 3080 com 10 GB VRAM e comprimiu dois volumes de Guerra e Paz em um resumo de 18 mil palavras. O…
Processado por IA de Habr AI; editado por Hamidun News
No Habr AI, foi publicada uma análise prática de como executar Saiga Llama 3 8B em uma RTX 3080 caseira com 10GB de VRAM para resumir os dois primeiros volumes de "Guerra e Paz". O experimento mostrou que o principal problema com LLM local em tal tarefa não é apenas memória limitada, mas também alucinações no nível de fatos, nomes e cronologia.
Executando em 10GB
O autor construiu um pipeline em torno de IlyaGusev/saiga_llama3_8b com quantização de 4 bits e executou o modelo em uma RTX 3080 caseira com 10GB de VRAM. O texto completo de dois volumes não cabia na memória, então o romance teve que ser dividido por capítulos e o tamanho de cada fragmento tinha que ser limitado. Após uma série de testes, um compromisso funcional tornou-se aproximadamente 7500 caracteres por pedaço: menos contexto era perdido, mais crescia o risco de falhas e transbordamento de VRAM.
A pilha usava transformers e bitsandbytes, e o autor verificou a precisão dos resumos através do Gemini. No caminho, surgiram efeitos colaterais inesperados: Qwen2.5-7B-Instruct uma vez produziu um longo trecho de código Python com recomendações de bibliotecas em vez de um resumo.
A ideia de uma "janela deslizante", onde o modelo resume um resumo já preparado, foi rapidamente abandonada: a qualidade se degradava segundo o princípio do telefone quebrado, e o tempo de processamento acabava ficando notavelmente maior.
De Onde Vieram as Alucinações
Um prompt ingênuo inicialmente parecia funcionar: o modelo produzia resumos curtos de 3-5 frases, mas rapidamente começava a confundir sobrenomes, relacionamentos familiares e cronologia. Pierre Bezukhov poderia de repente se tornar filho dos Rostov, e o Príncipe Vasily Kuragin—seu pai. Quando um banco de dados de personagens com regras rígidas foi adicionado ao prompt do sistema, os erros não desapareceram; eles se deslocaram: a rede começou a formular com mais confiança conclusões factualmente incorretas sobre capítulos individuais.
A falha mais impressionante ocorreu com Nikolai Rostov. No episódio após a batalha de Schengrabern, o modelo decidiu que o herói havia morrido, embora no texto ele estivesse apenas ferido e mais tarde continua a trama. O autor explica isso como uma inclinação nas probabilidades: Tolstoy descreve longamente dor, 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 verificação de logits mostrou que o prompt poderia de fato deslocar radicalmente a escolha do próximo token.
"Não mate os heróis!
Nikolai Rostov sobrevive em Schengrabern".
O Que Realmente Ajudou
Na versão funcional do pipeline, as regras se tornaram extremamente diretas: corresponder sobrenomes com o banco de dados de personagens, não inventar linhas românticas, lembrar que a ação ocorre em 1805, e escrever honestamente se um trecho termina antes da resolução. Em paralelo, o autor reduziu 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 continuar Tolstoy por si mesmo. E quanto mais estável a resposta.
- Quantização de 4 bits em vez de carregamento em tamanho completo
- Divisão de texto por capítulos com limite de aproximadamente 7500 caracteres
- Prompt de sistema rígido com banco de dados de personagens
- Temperatura baixa e top_p limitado
- Pós-processamento de erros raros em sobrenomes
Tal 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 através do Gemini 3 Flash deu uma precisão factual média de cerca de 93%, com a maioria dos capítulos se mantendo na faixa de 90-98%. Os erros mais impressionantes permaneceram no nível de tokens e morfemas: em um lugar "Pierre Bezdarovsky" apareceu, um híbrido do sobrenome Bezukhov e a palavra "sem talento". O autor acredita que tais falhas raras são mais fáceis de capturar no pós-processamento do que complicar ainda mais o prompt.
O Que Isso Significa
Este caso mostra algo importante para LLMs locais: mesmo em uma placa gráfica de consumidor, você pode construir um pipeline útil para textos longos, mas o sucesso depende não apenas do modelo e da quantidade de VRAM. Muitas vezes, instruções rígidas, controle de geração e pós-processamento decidem—ou seja, engenharia em torno da LLM, não um botão mágico "leia o livro para mim".
Quer parar de ler sobre IA e começar a usar?
AI News é um feed curado de notícias de IA. A Hamidun Academy ensina você a usar IA no trabalho.