Saiga Llama 3 8B en 10 GB VRAM: Cómo Habr Logró 93% de Precisión en Guerra y Paz

En Habr AI se publicó un análisis práctico de cómo ejecutar Saiga Llama 3 8B en una RTX 3080 casera con 10GB de VRAM para resumir los dos primeros volúmenes de "Guerra y Paz". El experimento mostró que el principal problema con un LLM local en tal tarea no es solo la memoria limitada, sino también alucinaciones a nivel de hechos, nombres y cronología.

Ejecutando en 10GB

El autor construyó un pipeline alrededor de IlyaGusev/saiga_llama3_8b con cuantización de 4 bits y ejecutó el modelo en una RTX 3080 casera con 10GB de VRAM. El texto completo de dos volúmenes no cabía en memoria, así que la novela tuvo que dividirse por capítulos y el tamaño de cada fragmento tuvo que ser limitado. Después de una serie de ejecuciones, un compromiso funcional fue aproximadamente 7500 caracteres por fragmento: se perdía menos contexto, pero más crecía el riesgo de fallos y desbordamiento de VRAM.

La pila usaba transformers y bitsandbytes, y el autor verificaba la precisión de los resúmenes a través de Gemini. En el camino surgieron efectos secundarios inesperados: Qwen2.5-7B-Instruct una vez produjo un largo fragmento de código Python con recomendaciones de bibliotecas en lugar de un resumen.

La idea de una "ventana deslizante", donde el modelo resume un resumen ya preparado, fue rápidamente abandonada: la calidad se degradaba según el principio del teléfono roto, y el tiempo de procesamiento resultaba notablemente mayor.

De Dónde Vinieron las Alucinaciones

Un prompt ingenuo inicialmente parecía funcionar: el modelo producía resúmenes cortos de 3-5 oraciones, pero rápidamente comenzaba a confundir apellidos, relaciones familiares y cronología. Pierre Bezukhov podría de repente convertirse en hijo de los Rostov, y el Príncipe Vasily Kuragin—su padre. Cuando se agregó una base de datos de personajes con reglas estrictas al prompt del sistema, los errores no desaparecieron; se desplazaron: la red comenzó a formular con más confianza conclusiones factualmente incorrectas sobre capítulos individuales.

El fallo más notable ocurrió con Nikolai Rostov. En el episodio después de la batalla de Schengrabern, el modelo decidió que el héroe había muerto, aunque en el texto solo estaba herido y más tarde continúa la trama. El autor explica esto como un sesgo en las probabilidades: Tolstoy describe largamente el dolor, la sangre y la sensación de muerte inminente, mientras que la breve confirmación de que Rostov está vivo aparece después y pesa menos para el modelo.

La verificación de logits mostró que el prompt de hecho podría desplazar radicalmente la elección del siguiente token.

"¡No matar a los héroes!

Nikolai Rostov sobrevive en Schengrabern".

Lo Que Realmente Ayudó

En la versión funcional del pipeline, las reglas se volvieron extremadamente directas: verificar apellidos con la base de datos de personajes, no inventar líneas románticas, recordar que la acción ocurre en 1805, y escribir honestamente si un fragmento termina antes de la resolución. En paralelo, el autor redujo 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 continuar a Tolstoy por cuenta propia. Y cuanto más estable la respuesta.

• Cuantización de 4 bits en lugar de carga de tamaño completo
• División de texto por capítulos con límite de aproximadamente 7500 caracteres
• Prompt de sistema rígido con base de datos de personajes
• Temperatura baja y top_p limitado
• Posprocesamiento de errores raros en apellidos

Tal conjunto de medidas no hizo el sistema libre de errores, pero redujo drásticamente el número de alucinaciones críticas. La evaluación final a través de Gemini 3 Flash dio una precisión factual promedio de alrededor del 93%, con la mayoría de los capítulos manteniéndose en el rango del 90-98%. Los errores más notables se mantuvieron a nivel de tokens y morfemas: en un lugar apareció "Pierre Bezdarovsky", un híbrido del apellido Bezukhov y la palabra "sin talento". El autor cree que tales fallos raros son más fáciles de detectar en el posprocesamiento que complicar aún más el prompt.

Lo Que Esto Significa

Este caso muestra algo importante para LLMs locales: incluso en una tarjeta gráfica de consumidor, puedes construir un pipeline útil para textos largos, pero el éxito depende no solo del modelo y de la cantidad de VRAM. A menudo, instrucciones rígidas, control de generación y posprocesamiento deciden—es decir, ingeniería alrededor de LLM, no un botón mágico "lee el libro por mí".