Choisir un modèle Ollama sans saturer sa machine
Choisir un modèle Ollama n’est pas une course au modèle le plus gros. Le bon choix dépend de trois facteurs : la tâche, la mémoire disponible et la vitesse acceptable. Un modèle léger peut être meilleur pour de l’extraction rapide, tandis qu’un modèle plus lourd peut mieux tenir une consigne longue.
1. Partir de l’usage
Classez votre besoin avant de chercher un nom de modèle. Pour du résumé court, un modèle général compact suffit souvent. Pour du code, cherchez un modèle orienté programmation. Pour une extraction JSON stricte, privilégiez un modèle régulier et testez la stabilité du format. Pour une conversation locale privée, l’important devient la fluidité plus que le benchmark théorique.
2. Vérifier le matériel
La FAQ Ollama traite la compatibilité GPU, mais il faut aussi raisonner en RAM et VRAM. Si la machine swap ou devient inutilisable, le modèle est trop gros pour votre usage quotidien. Commencez avec une taille raisonnable, puis augmentez seulement si le résultat est insuffisant. Gardez un fichier de test fixe : même prompt, même document, même attente. Cela évite de juger un modèle sur une impression.
3. Installer et tester un modèle
Depuis le terminal, téléchargez un modèle choisi dans la bibliothèque Ollama, puis lancez un test court :
ollama pull MODELE:TAG
ollama run MODELE:TAG "Résume ce texte en 5 puces actionnables."Ensuite, observez les modèles en cours et ce qui tourne réellement. La documentation CLI Ollama liste les commandes utiles, dont la liste des modèles actifs. Pour auditer une machine, utilisez :
ollama ps
ollama list4. Comparer proprement
Testez trois critères : qualité de réponse, temps avant le premier token, respect du format demandé. Ne comparez pas un modèle sur une seule question ouverte. Faites plutôt un mini-banc : un résumé, une extraction JSON, une reformulation, une question de code. Notez le temps observé et les erreurs. Si le petit modèle réussit, gardez-le.
5. Ce qu’il ne faut pas faire
N’installez pas des modèles au hasard “pour voir” sur une machine limitée. Ne supprimez pas un modèle pendant qu’un service l’utilise. Ne confondez pas modèle installé et modèle chargé. Et surtout, ne choisissez pas uniquement au nombre de paramètres : la spécialisation, la quantification et votre machine comptent autant.
Règle pratique
Pour un poste local, partez petit, mesurez, puis montez. Pour un serveur partagé, documentez le modèle par défaut, la raison du choix et le test minimal qui valide qu’il répond encore correctement après mise à jour.
Table de décision rapide
Pour un usage rédactionnel court, testez un modèle général compact. Pour expliquer du code, prenez un modèle spécialisé code. Pour une extraction JSON, choisissez le modèle qui respecte le mieux le format, même s’il écrit moins joliment. Pour une machine sans GPU puissant, privilégiez la régularité et la vitesse plutôt que la taille maximale.
Gardez une note locale avec le modèle choisi, sa taille, le cas d’usage et le prompt de test. Le jour où la machine change ou qu’un modèle est mis à jour, vous pourrez comparer avec une base stable.
Fixer le tag, la licence et le contexte
Remplacez MODELE:TAG par un identifiant réellement présent dans la bibliothèque Ollama ; ce texte est un emplacement à renseigner, pas un modèle téléchargeable. Notez le tag choisi, la quantification, la licence et la taille de contexte utilisée. Une licence de logiciel et une licence de poids de modèle ne sont pas interchangeables.
Un modèle peut tenir en mémoire avec un court message puis dépasser les ressources disponibles avec un document long ou plusieurs requêtes. Ne transformez pas la taille du téléchargement en estimation de RAM exacte. Votre fiche de comparaison doit conserver les mêmes entrées, les réglages et les erreurs observées. Aucun benchmark matériel n’a été exécuté pour ce guide.