Modèles
Le catalogue
Tous ces modèles lisent aussi les images, car le même modèle répond aux questions et effectue l'OCR assisté par IA sur les pages scannées. Vous n'en exécutez jamais qu'un.
| Modèle | Requiert | Téléchargement | Points forts |
|---|---|---|---|
gemma4:e2b | 8 Go de RAM, sans GPU | ~7 Go | Le modèle par défaut. Conversation et OCR les plus rapides, bon en français et en arabe. Plus faible sur les tableaux denses. |
gemma4:e4b | 16 Go de RAM, sans GPU | ~10 Go | Meilleur raisonnement et meilleure OCR que E2B, nettement plus lent sur processeur. |
gemma4:12b | 10 Go de VRAM, 16 Go de RAM | ~8 Go | Contexte long, raisonnement solide et bonne lecture des tableaux denses. |
gemma4:26b | 20 Go de VRAM, 32 Go de RAM | ~18 Go | Meilleure qualité de réponse sur les documents longs. |
gemma4:31b | 24 Go de VRAM, 32 Go de RAM | ~20 Go | Le plus grand palier, le plus lent par réponse. |
Les deux premiers fonctionnent sans carte graphique. Les autres en exigent une.
Changer de modèle
Admin → Modèle affiche ce que le serveur a détecté, ce qu'il recommande et le catalogue. Tout ce que votre matériel ne peut pas exécuter est grisé.
Choisir un modèle et « Utiliser ce modèle »
Le téléchargement démarre aussitôt, avec une barre de progression. C'est plusieurs gigaoctets : laissez faire.
Attendre la fin
Le nouveau modèle ne devient actif qu'une fois téléchargé : les conversations continuent sur l'ancien entre-temps.
L'ancien est supprimé
Une fois la bascule faite, le modèle remplacé est supprimé pour récupérer l'espace disque.
Aucun redémarrage n'est nécessaire, et vos documents comme votre index restent intacts : seul le composant qui rédige les réponses a changé.
Les modèles GPU sont grisés
La sonde matérielle s'exécute dans le conteneur backend, auquel aucun accès à la
carte graphique n'est donné : seul le conteneur Ollama l'obtient. Le backend est
donc informé de la carte que vous avez, via CHRONICLER_GPU_VRAM_GB dans votre
.env.
Si les modèles GPU ci-dessus sont grisés sur une machine qui a une carte, c'est que cette clé manque :
Select-String "CHRONICLER_GPU_VRAM_GB" .env
grep CHRONICLER_GPU_VRAM_GB .env
Relancez le script de détection
pour l'écrire, puis docker compose up -d. Elle n'est renseignée que sur le
profil nvidia : si COMPOSE_PROFILES vaut cpu ou amd, les modèles
compatibles processeur sont réellement les seuls que votre pile peut servir, et
la console a raison de s'y limiter.
Le modèle d'indexation est figé
Les réponses viennent du modèle de génération ci-dessus, mais trouver les bons passages est le travail d'un modèle d'indexation distinct. Celui-là n'est pas modifiable : chaque document indexé l'a été avec lui, et en changer invaliderait silencieusement l'ensemble. Il est intégré à l'image : rien à télécharger, et il fonctionne sans aucun accès Internet.
Réindexer
Admin → Modèle → Tout réindexer reconstruit l'index de recherche de tous les documents.
C'est rarement nécessaire - après une restauration ancienne, ou si les résultats semblent faux. C'est lourd : sur une grande bibliothèque, le serveur sera occupé longtemps. À lancer en dehors des heures de travail.
Bien choisir
- Sur processeur, restez petit.
gemma4:e2bqui répond en 40 secondes vaut mieux quegemma4:e4bqui répond en quatre minutes. - Sur carte graphique, prenez le plus grand modèle qui tient confortablement en VRAM. Un modèle qui tient presque déborde en mémoire système et devient bien plus lent.
- Pour les documents scannés et les tableaux, les paliers à partir de 12B lisent nettement mieux les pages structurées.
- Testez avec vos propres documents. Les comparatifs ne connaissent pas vos contrats.