Performances et mémoire

Chronicler est lent pour l'une de ces trois raisons, par ordre de probabilité :

1. Il n'y a pas de carte graphique, ou il y en a une et elle n'est pas utilisée.
2. Docker n'a pas assez de mémoire, et le modèle se recharge sans arrêt.
3. Le modèle est trop gros pour la machine et déborde sur le disque.

Traitez-les dans cet ordre. Accélération GPU couvre le premier point, cette page couvre les autres.

1. Donner plus de mémoire à Docker

C'est le réglage que l'on vise quand on dit « allouer plus de RAM », et il se trouve dans Docker, pas dans Chronicler. Rien dans le fichier compose ne peut l'augmenter.

[wsl2]
memory=16GB
processors=8
swap=8GB

wsl --shutdown

free -h

Vérifiez ce que Docker a réellement obtenu :

docker info --format "{{.MemTotal}}"

En dessous de 4 Gio, le backend sera tué dès le chargement d'un modèle.

2. Régler le runtime du modèle

Ces valeurs vont dans le .env à côté de votre fichier compose. Chacune est facultative : omise, le réglage par défaut d'Ollama s'applique. Lancez docker compose up -d après modification.

OLLAMA_KEEP_ALIVE — celui qui vaut le détour

Ollama décharge le modèle cinq minutes après la dernière question. La question suivante repaie le chargement complet : une à trois minutes sur processeur, quelques secondes sur carte graphique. Sur un serveur dédié, rien ne justifie de repayer cela.

OLLAMA_KEEP_ALIVE=-1

-1 garde le modèle résident en permanence. Le coût est exactement la mémoire du modèle (3 à 20 Go selon le modèle), occupée même quand personne ne demande rien. Sur une machine partagée qui a d'autres tâches, préférez 2h.

OLLAMA_NUM_PARALLEL — pour plusieurs personnes à la fois

Chaque emplacement parallèle a sa propre mémoire de contexte, en plus du poids du modèle. Doubler la valeur double à peu près cette mémoire. À un ou deux utilisateurs, n'y touchez pas ; la valeur 1 libère aussi de la mémoire sur une petite machine.

OLLAMA_NUM_PARALLEL=4

Utile seulement avec de la mémoire disponible. Si la machine est déjà juste, davantage d'emplacements ralentit tout au lieu d'accélérer.

OLLAMA_MAX_LOADED_MODELS

Chronicler génère avec un seul modèle : ne pas y toucher convient à presque tout le monde. La valeur 1 sur une petite machine garantit qu'un second modèle ne s'installera jamais en mémoire.

OLLAMA_CONTEXT_LENGTH

Mentionné pour être complet. Le modifier n'est presque jamais la solution recherchée.

3. Régler la base de données

Également dans .env. Les valeurs par défaut sont celles de PostgreSQL, connues pour leur prudence.

POSTGRES_SHARED_BUFFERS=2GB
POSTGRES_WORK_MEM=32MB

Une règle empirique répandue pour shared_buffers est 25 % de la mémoire que vous acceptez de donner à la base. work_mem est alloué par tri, pas par connexion : une grande valeur multipliée par de nombreuses requêtes simultanées est la façon classique d'épuiser la mémoire. 32 Mo est généreux, 1 Go est une erreur.

À ne considérer qu'à partir de plusieurs milliers de documents. En dessous, la valeur par défaut suffit et c'est le modèle qui limite.

4. Choisir un modèle à la bonne taille

Un modèle qui ne tient pas est le pire cas : il déborde sur le disque et chaque réponse prend des minutes. Adaptez le modèle à la mémoire réellement disponible — voir Modèles. Plus petit et résident bat plus gros et qui déborde, à chaque fois.

Exemples concrets

OLLAMA_KEEP_ALIVE=30m
OLLAMA_NUM_PARALLEL=1

OLLAMA_KEEP_ALIVE=-1
OLLAMA_NUM_PARALLEL=2
POSTGRES_SHARED_BUFFERS=2GB
POSTGRES_WORK_MEM=16MB

OLLAMA_KEEP_ALIVE=-1
OLLAMA_NUM_PARALLEL=4
POSTGRES_SHARED_BUFFERS=4GB
POSTGRES_WORK_MEM=32MB

Vérifier ce que vous avez changé

docker compose config | grep -A6 "OLLAMA_"        # ce que compose a résolu
docker exec chronicler-ollama env | grep OLLAMA   # ce que le conteneur a reçu
docker exec chronicler-postgres psql -U chronicler -d chronicler_app -c 'show shared_buffers;'
docker stats --no-stream                          # ce que tout cela consomme

Un réglage absent du .env n'apparaîtra pas du tout dans le conteneur. C'est normal : cela signifie que la valeur par défaut du runtime s'applique.

De la vitesse qui ne tient pas à la mémoire

• Cadrez vos questions. Une conversation limitée à trois documents est bien plus rapide qu'une conversation ouverte sur tout.
• Indexez aux heures creuses. Les imports en masse, surtout scannés, se disputent le processeur avec les conversations.
• Utilisez un SSD. Charger un modèle de 20 Go depuis un disque mécanique est une mauvaise minute.