Saiga Llama 3 8B con 10 GB de VRAM: cómo en Habr lograron un 93 % de precisión con «Guerra y paz»

Habr AI ha publicado un análisis práctico de cómo ejecutar Saiga Llama 3 8B en una RTX 3080 doméstica con 10 GB de memoria de vídeo para resumir los dos primeros tomos de «Guerra y paz». El experimento mostró que el principal problema de un LLM local en esta tarea no es solo la memoria limitada, sino también las alucinaciones en hechos, nombres y cronología.

Ejecución con 10 GB

El autor montó un pipeline en torno a IlyaGusev/saiga_llama3_8b con cuantización de 4 bits y ejecutó el modelo en una RTX 3080 doméstica con 10 GB de VRAM. El texto completo de los dos tomos no cabía en memoria, así que hubo que dividir la novela por capítulos y limitar el tamaño de cada fragmento. Tras una serie de pruebas, el compromiso viable fue de unos 7500 caracteres por fragmento: con menos se perdía demasiado contexto, y con más crecía el riesgo de fallos y de desbordamiento de la VRAM. El stack usó transformers y bitsandbytes, y el autor comprobó la precisión de los resúmenes con Gemini.

Por el camino surgieron efectos secundarios inesperados: Qwen2.5-7B-Instruct llegó a devolver, en lugar de un resumen, un largo fragmento de código Python con consejos sobre bibliotecas. La idea de la «ventana deslizante», en la que el modelo resume un resumen ya hecho, también se descartó pronto: la calidad se degradaba como en el juego del teléfono descompuesto y el tiempo de procesamiento acababa siendo notablemente mayor.

De dónde salieron las alucinaciones

El prompt ingenuo parecía funcionar al principio: el modelo daba resúmenes cortos de 3–5 frases, pero enseguida empezaba a confundir apellidos, parentescos y cronología. Pierre Bezújov podía convertirse de repente en hijo de los Rostov, y el príncipe Vasili Kurguin en su padre. Cuando se añadió al prompt de sistema una base de personajes con reglas estrictas, los errores no desaparecieron, sino que se desplazaron: la red empezó a formular con más seguridad conclusiones factualmente erróneas sobre capítulos concretos.

El fallo más revelador afectó a Nikolái Rostov. En el episodio posterior a la batalla de Schöngrabern, el modelo decidió que el héroe había muerto, aunque en el texto solo está herido y más tarde sigue en la trama. El autor lo atribuye a un sesgo en las probabilidades: Tolstói describe durante mucho tiempo el dolor, la sangre y la sensación de muerte cercana, mientras que la breve confirmación de que Rostov está vivo llega después y pesa menos para el modelo. La comprobación de logits mostró que un prompt sí puede desplazar de forma radical la elección del siguiente token.

«¡Prohibido matar a los héroes!

Nikolái Rostov sobrevive en Schöngrabern».

Lo que realmente ayudó

En la versión final del pipeline, las reglas se volvieron muy directas: contrastar los apellidos con la base de personajes, no inventar tramas románticas, recordar que la acción transcurre en 1805 y avisar con honestidad si un pasaje se corta antes del desenlace. Al mismo tiempo, el autor ajustó los parámetros de generación: temperatura 0,1, top_p 0,85 y repetition_penalty 1,15. La idea era simple: menos creatividad, menos tentación de completar a Tolstói por cuenta propia. Y la respuesta es más estable.

• Cuantización de 4 bits en lugar de carga completa
• División del texto por capítulos con un límite de unos 7500 caracteres
• Prompt de sistema estricto con base de personajes
• Temperatura baja y top_p limitado
• Posprocesamiento de errores poco frecuentes en apellidos

Este conjunto de medidas no hizo el sistema infalible, pero redujo de forma drástica el número de alucinaciones críticas. La evaluación final con Gemini 3 Flash dio una precisión factual media de en torno al 93 %, y la mayoría de los capítulos se mantuvo en un rango del 90–98 %. Los fallos más llamativos quedaron a nivel de tokens y morfemas: en un punto apareció «Pierre Bezdarovski», un híbrido del apellido Bezújov y la palabra rusa para «mediocre». El autor considera que estos fallos raros son más fáciles de atrapar con posprocesamiento que complicando aún más el prompt.

Qué significa

Este caso muestra algo importante para los LLM locales: incluso en una tarjeta gráfica de consumo se puede montar un pipeline útil para textos largos, pero el éxito depende de algo más que del modelo y del volumen de VRAM. A menudo deciden las instrucciones estrictas, el control de la generación y el posprocesamiento, es decir, la ingeniería en torno al LLM, y no un botón mágico de «léeme el libro».