Configuration matérielle requise
L'interface de chat normale de Libre WebUI est légère. La majeure partie des ressources est consommée par les modèles Ollama locaux ; les tâches Work adossées à des conteneurs ajoutent des besoins distincts en CPU, mémoire, processus, images et stockage de projets.
Tableau de référence
| Matériel | Modèles locaux envisageables | Remarques |
|---|---|---|
| 8 GB de RAM, CPU uniquement | 1B-4B quantifiés | Adapté aux tests et aux chats légers |
| 16 GB de RAM, CPU uniquement | 4B-8B quantifiés | Utilisable, plus lent qu'un GPU |
| 8 GB de VRAM | 4B-8B quantifiés | Bonne configuration locale quotidienne |
| 12-16 GB de VRAM | 8B-14B quantifiés | Excellente gamme pour une station de travail |
| 24 GB de VRAM | 14B-32B quantifiés | Usage local haut de gamme |
| 48 GB+ de VRAM ou grande mémoire unifiée | 32B-70B quantifiés | Expérimentation avec de grands modèles |
La vitesse réelle dépend de l'architecture du modèle, de la quantification, de la longueur du contexte, des pilotes du GPU et des autres processus en cours d'exécution.
Bons modèles pour commencer
ollama pull gemma4:12b
ollama pull qwen3.8:27b
ollama pull gemma4:26b
ollama pull nomic-embed-text
Utilisez nomic-embed-text pour les plongements vectoriels de documents, et non comme modèle de chat.
VRAM et RAM
La VRAM est le facteur le plus déterminant pour la vitesse d'un modèle local. Si le modèle tient dans la VRAM, les réponses sont beaucoup plus rapides. S'il déborde dans la RAM système, il peut continuer à fonctionner, mais sera plus lent.
La RAM système intervient dans l'inférence sur CPU, le déchargement vers le GPU, les longues fenêtres de contexte et l'exécution du reste de l'application.
Apple Silicon
Apple Silicon utilise une mémoire unifiée : la mémoire des modèles provient donc de la même réserve que celle du système d'exploitation et des applications. Les machines dotées d'une grande quantité de mémoire unifiée peuvent exécuter des modèles quantifiés plus grands que ne le laisserait penser leur quantité de VRAM GPU sur un système à GPU distinct.
Conservez suffisamment de mémoire libre pour le navigateur, le serveur et le système d'exploitation.
NVIDIA
Les GPU NVIDIA offrent généralement la meilleure compatibilité pour l'inférence locale grâce à CUDA. Utilisez des pilotes à jour et vérifiez l'accès de Docker au GPU si Ollama s'exécute dans des conteneurs.
AMD et Intel
La prise en charge d'AMD et d'Intel dépend d'Ollama et des pilotes disponibles sur votre plateforme. L'inférence sur CPU reste disponible en l'absence d'accélération GPU.
Réduire l'utilisation de la mémoire
- Utilisez des modèles plus petits.
- Utilisez la quantification Q4 plutôt que Q8.
- Réduisez la longueur du contexte.
- Déchargez les modèles que vous n'utilisez pas.
- Distinguez le modèle de plongements vectoriels de documents du choix du modèle de chat.
Capacité de l'environnement d'exécution Work
Work ajoute les ressources des conteneurs à celles de la WebUI et du processus de modèle. Chaque conteneur de tâche actif dispose par défaut de :
- 2 GB de mémoire ;
- 2 CPU ; et
- 256 processus.
Par défaut, le serveur autorise deux tâches actives adossées à des conteneurs sur l'ensemble de l'instance et une par administrateur. Il s'agit de limites, et non de réservations, mais les personnes qui exploitent le système doivent prévoir les ressources nécessaires à la WebUI, au navigateur, à Docker, à Ollama et au conteneur de la tâche simultanément. Sur Apple Silicon, tous se disputent en définitive la même réserve de mémoire unifiée.
Utiliser Ollama Cloud ou une extension configurée pour un modèle distant peut éviter de charger un grand modèle dans la RAM ou la VRAM locale. Cela ne supprime ni l'exigence de Docker ni les ressources nécessaires au conteneur Work.
Chaque tâche Work possède aussi un volume nommé Docker pour les fichiers générés et les dépendances locales. Les volumes ne disposent actuellement d'aucun quota de disque par tâche ; l'installation de paquets ou les projets générés peuvent donc épuiser le stockage Docker. Surveillez la racine des données Docker, définissez des limites au niveau de l'hôte lorsqu'elles sont disponibles et sauvegardez les volumes des tâches séparément de la base de données Libre WebUI.
Ne réglez les paramètres WORK_MEMORY_LIMIT, WORK_CPU_LIMIT, WORK_PIDS_LIMIT et
WORK_MAX_ACTIVE_RUNTIMES_* qu'après avoir mesuré l'hôte du serveur. Consultez la
référence des variables d'environnement pour connaître les valeurs par défaut.