Saiga Llama 3 8B sur 10 GB VRAM : Comment Habr a Atteint 93% de Précision sur Guerre et Paix

Sur Habr AI, une analyse pratique du lancement de Saiga Llama 3 8B sur une RTX 3080 domestique avec 10GB de VRAM pour résumer les deux premiers tomes de "Guerre et Paix" a été publiée. L'expérience a montré que le principal problème avec un LLM local dans une telle tâche n'est pas seulement la mémoire limitée, mais aussi les hallucinations au niveau des faits, des noms et de la chronologie.

Lancer sur 10GB

L'auteur a construit un pipeline autour de IlyaGusev/saiga_llama3_8b avec quantification 4 bits et a exécuté le modèle sur une RTX 3080 domestique avec 10GB de VRAM. Le texte complet de deux tomes ne pouvait pas tenir en mémoire, donc le roman a dû être divisé par chapitres et la taille de chaque fragment devait être limitée. Après une série d'exécutions, un compromis fonctionnel est devenu environ 7500 caractères par morceau : moins de contexte était perdu, plus le risque d'crashes et de débordement de VRAM augmentait.

La pile utilisait transformers et bitsandbytes, et l'auteur vérifiait la précision des résumés via Gemini. En chemin, des effets secondaires inattendus ont émergé : Qwen2.5-7B-Instruct a une fois produit un long morceau de code Python avec des recommandations de bibliothèques au lieu d'un résumé.

L'idée d'une "fenêtre glissante", où le modèle résume un résumé déjà préparé, a été rapidement abandonnée : la qualité s'est dégradée selon le principe du téléphone cassé, et le temps de traitement finissait par être notablement plus long.

D'Où Venaient les Hallucinations

Un prompt naïf semblait initialement fonctionner : le modèle produisait de courts résumés de 3-5 phrases, mais commençait rapidement à confondre les noms de famille, les relations familiales et la chronologie. Pierre Bezoukhov pouvait soudainement devenir le fils des Rostov, et le Prince Vasily Kuragin—son père. Quand une base de données de personnages avec des règles strictes a été ajoutée au prompt système, les erreurs n'ont pas disparu ; elles se sont déplacées : le réseau a commencé à formuler avec plus de confiance des conclusions factuellement incorrectes sur des chapitres individuels.

L'échec le plus frappant s'est produit avec Nikolai Rostov. Dans l'épisode après la bataille de Schengrabern, le modèle a décidé que le héros était mort, bien qu'dans le texte il soit seulement blessé et continue la trame plus tard. L'auteur explique cela comme un biais dans les probabilités : Tolstoï décrit longuement la douleur, le sang et le sentiment de mort imminente, tandis que la brève confirmation que Rostov est vivant apparaît plus tard et pèse moins pour le modèle.

La vérification des logits a montré que le prompt pouvait en effet décaler radicalement le choix du prochain token.

"Ne tuer pas les héros !

Nikolai Rostov survit à Schengrabern".

Ce Qui a Vraiment Aidé

Dans la version fonctionnelle du pipeline, les règles sont devenues extrêmement directes : vérifier les noms de famille avec la base de données des personnages, ne pas inventer de lignes romantiques, se souvenir que l'action se déroule en 1805, et écrire honnêtement si un extrait s'arrête avant la résolution. En parallèle, l'auteur a réduit les paramètres de génération—température 0,1, top_p 0,85 et repetition_penalty 1,15. L'idée était simple : moins de créativité, moins de tentation de continuer Tolstoï soi-même. Et plus la réponse était stable.

• Quantification 4 bits au lieu de chargement à taille complète
• Découpe de texte par chapitres avec une limite d'environ 7500 caractères
• Prompt système strict avec base de données de personnages
• Température basse et top_p limité
• Post-traitement des erreurs rares dans les noms de famille

Un tel ensemble de mesures n'a pas rendu le système sans erreur, mais a considérablement réduit le nombre d'hallucinations critiques. L'évaluation finale via Gemini 3 Flash a donné une précision factuelle moyenne d'environ 93%, la plupart des chapitres se situant dans la plage 90-98%. Les erreurs les plus frappantes sont restées au niveau des tokens et des morphèmes : en un endroit "Pierre Bezdarovsky" a apparu, un hybride du nom de famille Bezoukhov et du mot "sans talent". L'auteur pense que de telles rares défaillances sont plus faciles à attraper en post-traitement que de compliquer encore davantage le prompt.

Ce Que Cela Signifie

Ce cas montre quelque chose d'important pour les LLM locales : même sur une carte graphique de consommateur, vous pouvez construire un pipeline utile pour les textes longs, mais le succès dépend non seulement du modèle et de la quantité de VRAM. Souvent, ce qui décide, ce sont les instructions strictes, le contrôle de la génération et le post-traitement—c'est-à-dire l'ingénierie autour du LLM, et non un bouton magique "lis le livre pour moi".