Saiga Llama 3 8B avec 10 Go de VRAM : comment Habr a atteint 93 % de précision sur « Guerre et Paix »

Habr AI a publié une analyse pratique de l'exécution de Saiga Llama 3 8B sur une RTX 3080 domestique de 10 Go de mémoire vidéo pour résumer les deux premiers tomes de « Guerre et Paix ». L'expérience montre que le principal problème d'un LLM local sur cette tâche n'est pas seulement la mémoire limitée, mais aussi les hallucinations sur les faits, les noms et la chronologie.

Exécution avec 10 Go

L'auteur a construit un pipeline autour de IlyaGusev/saiga_llama3_8b avec une quantification en 4 bits et a fait tourner le modèle sur une RTX 3080 domestique de 10 Go de VRAM. Le texte intégral des deux tomes ne tenait pas en mémoire : il a donc fallu découper le roman par chapitres et plafonner la taille de chaque fragment. Après une série d'essais, le compromis viable s'est établi à environ 7500 caractères par fragment : en dessous, trop de contexte se perdait ; au-dessus, le risque de plantage et de dépassement de la VRAM augmentait. La pile utilisait transformers et bitsandbytes, et l'auteur a vérifié la précision des résumés avec Gemini.

Des effets de bord inattendus sont apparus en chemin : Qwen2.5-7B-Instruct a un jour produit, au lieu d'un résumé, un long morceau de code Python assorti de conseils sur des bibliothèques. L'idée de la « fenêtre glissante », où le modèle résume un résumé déjà produit, a elle aussi été vite abandonnée : la qualité se dégradait comme au jeu du téléphone arabe, et le temps de traitement devenait nettement plus long.

D'où viennent les hallucinations

Le prompt naïf semblait fonctionner au début : le modèle produisait de courts résumés de 3 à 5 phrases, mais confondait vite les noms de famille, les liens de parenté et la chronologie. Pierre Bézoukhov pouvait soudain devenir un fils des Rostov, et le prince Vassili Kouraguine son père. Quand on a ajouté au prompt système une base de personnages assortie de règles strictes, les erreurs n'ont pas disparu mais se sont déplacées : le réseau s'est mis à formuler avec plus d'assurance des conclusions factuellement fausses sur certains chapitres.

L'échec le plus parlant concerne Nikolaï Rostov. Dans l'épisode qui suit la bataille de Schöngrabern, le modèle a décidé que le héros était mort, alors que dans le texte il est seulement blessé et reste dans l'intrigue par la suite. L'auteur y voit un biais de probabilités : Tolstoï décrit longuement la douleur, le sang et la sensation de mort imminente, tandis que la brève confirmation que Rostov est vivant arrive plus tard et pèse moins pour le modèle. La vérification des logits a montré qu'un prompt peut effectivement décaler radicalement le choix du token suivant.

« Il est interdit de tuer les héros !

Nikolaï Rostov survit à Schöngrabern ».

Ce qui a vraiment aidé

Dans la version finale du pipeline, les règles sont devenues très directes : vérifier les noms de famille dans la base de personnages, ne pas inventer d'intrigues amoureuses, se rappeler que l'action se déroule en 1805 et signaler honnêtement quand un passage s'interrompt avant le dénouement. En parallèle, l'auteur a resserré les paramètres de génération : température de 0,1, top_p de 0,85 et repetition_penalty de 1,15. L'idée était simple : moins de créativité, moins de tentation de compléter Tolstoï de son propre chef. Et la réponse est plus stable.

• Quantification en 4 bits au lieu d'un chargement en pleine taille
• Découpage du texte par chapitres avec une limite d'environ 7500 caractères
• Prompt système strict avec base de personnages
• Température basse et top_p limité
• Post-traitement des rares erreurs sur les noms de famille

Cet ensemble de mesures n'a pas rendu le système infaillible, mais il a fortement réduit le nombre d'hallucinations critiques. L'évaluation finale avec Gemini 3 Flash a donné une précision factuelle moyenne d'environ 93 %, et la plupart des chapitres se sont maintenus entre 90 et 98 %. Les ratés les plus spectaculaires sont restés au niveau des tokens et des morphèmes : à un endroit est apparu « Pierre Bezdarovski », un hybride du nom Bezoukhov et du mot russe signifiant « médiocre ». L'auteur estime que ces rares défaillances se rattrapent plus facilement par post-traitement qu'en compliquant encore le prompt.

Ce que cela signifie

Ce cas montre une chose importante pour les LLM locaux : même sur une carte graphique grand public, on peut construire un pipeline utile pour les textes longs, mais le succès ne dépend pas que du modèle et du volume de VRAM. Ce sont souvent des instructions strictes, le contrôle de la génération et le post-traitement qui tranchent, autrement dit l'ingénierie autour du LLM, et non un bouton magique « lis le livre à ma place ».