Ollama avancé : modèles quantifiés et fine-tuning local — tutoriel 2026

Introduction

Ollama est devenu en 2024-2025 le point d’entrée par excellence pour quiconque veut faire tourner un grand modèle de langage directement sur sa machine, sans dépendre d’une API externe et sans débourser un centime de frais d’inférence. Derrière cette apparente simplicité se cache une architecture solide : Ollama est fondamentalement un wrapper autour de llama.cpp, le moteur d’inférence C++ ultra-optimisé pour les CPU et GPU grand-public. Là où llama.cpp demande de compiler des binaires, de gérer des arguments en ligne de commande et de convertir soi-même les poids, Ollama encapsule tout cela derrière une CLI propre, un daemon qui écoute sur le port 11434 et une API REST compatible OpenAI. Le résultat est qu’un développeur peut passer de zéro à un LLM Mistral 7B fonctionnel en moins de dix minutes sur n’importe quel système d’exploitation moderne.

Mais Ollama fait bien plus que simplement lancer des modèles. Ce tutoriel vous emmène au-delà de ollama run mistral : vous apprendrez à choisir le bon niveau de quantification GGUF pour votre matériel, à créer des Modelfile personnalisés qui transforment un modèle généraliste en assistant métier, à exposer l’API locale à des outils comme LiteLLM ou OpenWebUI, et à aller jusqu’au fine-tuning LoRA avec Unsloth pour adapter le modèle à votre corpus. Une section entière est dédiée aux embeddings pour construire un pipeline RAG (Retrieval-Augmented Generation). Enfin, nous adaptons chaque étape au contexte réel d’une PME en Afrique de l’Ouest, où la bande passante est limitée, les GPU cloud sont coûteux, et les besoins métiers s’articulent souvent autour du droit OHADA ou de la comptabilité SYSCOHADA.

Prérequis

Avant de commencer, assurez-vous que votre environnement répond aux exigences minimales. La contrainte principale est la mémoire RAM : Ollama charge les poids du modèle entièrement en mémoire vive (ou VRAM si vous avez un GPU compatible), et un modèle 7B quantifié en Q4 occupe environ 4,1 Go. Pour avoir de la marge — le système, le processus Ollama lui-même et votre application consommant chacun de la RAM — 16 Go de RAM minimum sont requis. Avec 8 Go, vous pourrez faire tourner des modèles 3B mais vous serez limité pour le 7B.

• OS : Linux (Ubuntu 20.04+, Debian 11+, Fedora 38+), macOS 13+ (Apple Silicon ou Intel), Windows 10/11 (via WSL2 ou installeur natif)
• RAM : 16 Go minimum, 32 Go recommandé pour le fine-tuning Unsloth
• Stockage : 10 Go libres minimum (les modèles pèsent entre 2 Go et 8 Go selon la quantification)
• CPU : tout processeur moderne 64 bits, AVX2 préférable pour les performances
• GPU : optionnel mais fortement recommandé — NVIDIA avec CUDA 11.8+ ou AMD avec ROCm, Apple Silicon (Metal natif)
• Outils : curl, Python 3.10+ (pour Unsloth et les scripts RAG), git
• Temps estimé : environ 30 minutes pour les étapes 1 à 5, 1h30 supplémentaire si vous faites les étapes 6 et 7

Si vous êtes sur Windows sans WSL2, nous vous conseillons d’installer WSL2 avec Ubuntu 22.04 avant de continuer — les commandes de ce tutoriel sont écrites pour un environnement Unix et fonctionneront telles quelles dans ce contexte. L’installeur Windows natif d’Ollama existe mais le workflow Docker/Python est plus fluide sous Linux.

Étape 1 — Comprendre la quantification GGUF : Q2, Q4, Q8

La quantification est le mécanisme qui permet de faire tenir un modèle de plusieurs milliards de paramètres sur du matériel grand public. Pour comprendre pourquoi c’est nécessaire, un seul chiffre : Mistral 7B en précision complète float32 pèse environ 28 Go. En float16 (la norme pour l’entraînement), il pèse 14 Go — toujours trop pour la plupart des machines de bureau. La quantification réduit la précision numérique de chaque paramètre : au lieu de stocker chaque poids en 32 ou 16 bits, on le stocke en 8, 4 ou même 2 bits, avec une légère perte de qualité mais un gain énorme en taille et en vitesse.

Le format GGUF (successor du format GGML) est le standard utilisé par llama.cpp et donc Ollama. Il encapsule dans un seul fichier binaire les poids quantifiés, les hyperparamètres du modèle et les métadonnées nécessaires à l’inférence. Les niveaux de quantification les plus courants sont :

• Q2_K : 2 bits par poids — compression maximale, ~1,5 Go pour un 7B, mais qualité nettement dégradée. Réservé aux machines avec vraiment très peu de RAM (6-8 Go). Les réponses deviennent incohérentes sur des tâches complexes.
• Q4_K_M : 4 bits par poids, variante Medium — le meilleur compromis taille/qualité. Un Mistral 7B Q4_K_M pèse environ 4,1 Go et délivre une qualité proche du float16 pour la grande majorité des tâches. C’est le niveau recommandé pour une utilisation professionnelle sur CPU.
• Q4_K_S : 4 bits, variante Small — légèrement plus petit (~3,9 Go) avec une qualité un tout petit peu inférieure à Q4_K_M. Acceptable si vous êtes en limite de RAM.
• Q6_K : 6 bits — très proche du float16 en qualité, ~6 Go pour un 7B. Recommandé si vous avez 16 Go de RAM et voulez maximiser la fidélité.
• Q8_0 : 8 bits — quasi-identique au float16, ~7,7 Go pour un 7B. Principalement utile sur GPU où la VRAM est abondante et la vitesse prime.

Pour une PME qui fait tourner un assistant sur un serveur sans GPU, Q4_K_M est le choix par défaut. La règle pratique est simple : si votre machine a exactement 16 Go de RAM, choisissez Q4_K_M ou Q4_K_S. Si vous avez 32 Go, vous pouvez monter jusqu’à Q6_K ou même tester des modèles 13B en Q4. N’utilisez Q2 qu’en dernier recours, car la perte de qualité sur des tâches de rédaction juridique ou comptable peut produire des résultats trompeurs.

Ollama gère automatiquement le téléchargement du bon niveau de quantification lorsque vous tirez un modèle depuis sa librairie. Vous pouvez aussi spécifier un tag explicite pour cibler un niveau précis, comme nous le verrons à l’étape 2.

Étape 2 — Installer Ollama et tirer Mistral 7B

L’installation d’Ollama sur Linux se fait via un script d’installation officiel qui détecte automatiquement votre architecture, installe le binaire, configure un service systemd et ajoute les dépendances CUDA si un GPU NVIDIA est détecté. C’est la méthode recommandée car elle gère aussi les mises à jour futures via le même mécanisme.

# Installation via le script officiel (Linux / macOS)
curl -fsSL https://ollama.com/install.sh | sh

# Vérifier que le service est actif
systemctl status ollama

# Vérifier la version installée
ollama --version

Après l’installation, le daemon Ollama démarre automatiquement en arrière-plan et écoute sur http://localhost:11434. Si le service ne démarre pas automatiquement, lancez ollama serve dans un terminal dédié. Sur macOS, Ollama s’installe comme une application native avec une icône dans la barre de menu. Sur Windows, l’installeur téléchargeable sur ollama.com crée un service équivalent.

# Tirer Mistral 7B (niveau Q4_K_M par défaut)
ollama pull mistral

# Tirer une quantification spécifique (Q4 ou Q8)
ollama pull mistral:7b-instruct-q4_K_M
ollama pull mistral:7b-instruct-q8_0

# Lister les modèles locaux téléchargés
ollama list

# Premier test rapide
ollama run mistral "Explique en deux phrases le droit OHADA"

Le téléchargement de Mistral 7B Q4_K_M représente environ 4,1 Go. Sur une connexion ADSL à 2 Mbps (situation courante en Afrique de l’Ouest), cela prend environ 4 à 5 heures — nous abordons les stratégies pour mitiger ce point dans la section d’adaptation ouest-africaine. Une fois le modèle téléchargé, toutes les inférences sont 100% locales et ne nécessitent plus de connexion. La commande ollama run ouvre un REPL interactif si aucun prompt n’est passé en argument ; avec un argument, elle exécute le prompt et retourne la réponse en mode non-interactif.

Étape 3 — Modelfile custom : system prompt et paramètres

Un Modelfile est l’équivalent Ollama d’un Dockerfile : un fichier texte qui déclare depuis quel modèle de base construire, quel system prompt injecter à chaque conversation, et quels paramètres d’inférence appliquer. C’est le mécanisme fondamental pour transformer un LLM généraliste en assistant métier spécialisé — par exemple, un assistant comptable pour une PME utilisant le plan comptable SYSCOHADA révisé.

# Fichier : Modelfile.syscohada

# Modèle de base (GGUF local ou tag Ollama)
FROM mistral:7b-instruct-q4_K_M

# System prompt injecté à chaque conversation
SYSTEM """
Tu es un assistant comptable et juridique spécialisé dans le droit OHADA
et le référentiel comptable SYSCOHADA révisé (2017). Tu assistes des
comptables, directeurs financiers et juristes d'entreprises basées en
Afrique de l'Ouest. Tes réponses sont précises, citent les articles
pertinents du droit OHADA quand applicable, et utilisent la terminologie
du plan comptable SYSCOHADA. Tu ne donnes pas de conseils juridiques
formels mais tu fournis des explications pédagogiques claires.
"""

# Paramètres d'inférence
PARAMETER temperature 0.3
PARAMETER top_p 0.9
PARAMETER top_k 40
PARAMETER num_predict 2048
PARAMETER num_ctx 4096

# Template de prompt (format Mistral Instruct)
TEMPLATE """{{ if .System }}[INST] {{ .System }}{{ end }}
[INST] {{ .Prompt }} [/INST]
"""

La directive PARAMETER temperature 0.3 est délibérément basse pour un assistant comptable : on veut des réponses factuelles et reproductibles, pas créatives. Pour un assistant de rédaction ou de brainstorming, on monterait à 0.7-0.9. Le paramètre num_ctx 4096 définit la fenêtre de contexte en tokens — augmentez-le à 8192 si votre machine supporte la charge, car les documents comptables sont souvent longs. Construisez et testez votre modèle personnalisé avec les commandes suivantes.

# Construire le modèle personnalisé depuis le Modelfile
ollama create syscohada-assistant -f ./Modelfile.syscohada

# Vérifier qu'il apparaît dans la liste
ollama list

# Tester
ollama run syscohada-assistant "Quelle est la structure des comptes de classe 4 en SYSCOHADA ?"

Si la construction réussit, vous verrez votre modèle syscohada-assistant:latest dans ollama list avec sa taille et sa date de création. Notez que le Modelfile ne re-quantifie pas le modèle de base — il crée simplement une configuration qui référence le modèle de base, donc l’espace disque utilisé est minimal (quelques Ko pour la config). Vous pouvez créer autant de variantes métier que vous voulez à partir du même modèle de base téléchargé une seule fois.

Étape 4 — API REST locale port 11434

Le daemon Ollama expose une API REST sur http://localhost:11434 dès son démarrage. Cette API offre deux surfaces compatibles : l’API native Ollama et une surface compatible OpenAI (ajoutée dans Ollama 0.1.14). La compatibilité OpenAI est particulièrement précieuse car elle permet d’utiliser des bibliothèques et outils existants (LangChain, LlamaIndex, OpenAI SDK) sans modification en pointant simplement l’URL de base vers Ollama.

# Test via l'endpoint natif Ollama (génération)
curl http://localhost:11434/api/generate \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "syscohada-assistant",
    "prompt": "Définition du principe de continuité d exploitation en SYSCOHADA",
    "stream": false
  }'

# Test via l'endpoint compatible OpenAI
curl http://localhost:11434/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer ollama' \
  -d '{
    "model": "syscohada-assistant",
    "messages": [
      {"role": "user", "content": "Expliquez le compte 401 Fournisseurs"}
    ]
  }'

# Lister les modèles disponibles via l'API
curl http://localhost:11434/v1/models

L’endpoint /api/generate est l’API native pour les completions simples ; /v1/chat/completions suit le format OpenAI pour les échanges multi-tours. Par défaut, stream: true renvoie les tokens au fur et à mesure (Server-Sent Events) — mettez stream: false pour obtenir la réponse complète en une seule requête JSON, plus pratique pour les scripts. Si vous souhaitez exposer Ollama sur le réseau local (par exemple pour que plusieurs postes de travail partagent un seul serveur), démarrez avec OLLAMA_HOST=0.0.0.0:11434 ollama serve et configurez votre pare-feu pour n’autoriser que les adresses IP de votre LAN.

Étape 5 — Connecter LiteLLM et OpenWebUI

Une fois l’API REST en place, deux outils complémentaires enrichissent considérablement l’expérience. LiteLLM est un proxy qui unifie plusieurs fournisseurs LLM derrière une surface API OpenAI unique — il vous permet de basculer de Ollama à Claude ou GPT-4 en changeant une variable d’environnement, sans modifier votre code applicatif. OpenWebUI (anciennement Open WebUI) est une interface conversationnelle complète, hébergeable localement, qui offre gestion des conversations, upload de fichiers, RAG intégré et gestion multi-utilisateurs.

# docker-compose.yml pour LiteLLM avec Ollama comme backend
version: '3.8'
services:
  litellm:
    image: ghcr.io/berriai/litellm:main-latest
    ports:
      - "4000:4000"
    environment:
      - LITELLM_MASTER_KEY=sk-mon-secret-interne
    volumes:
      - ./litellm_config.yaml:/app/config.yaml
    command: ["--config", "/app/config.yaml", "--port", "4000"]

# litellm_config.yaml
model_list:
  - model_name: mistral-local
    litellm_params:
      model: ollama/syscohada-assistant
      api_base: http://host.docker.internal:11434
  - model_name: mistral-q8
    litellm_params:
      model: ollama/mistral:7b-instruct-q8_0
      api_base: http://host.docker.internal:11434

Avec cette configuration, tout outil pointant vers http://localhost:4000/v1 avec la clé sk-mon-secret-interne peut utiliser vos modèles Ollama locaux comme s’ils étaient des modèles OpenAI. C’est idéal pour intégrer un LLM local dans une application existante qui utilise déjà l’OpenAI SDK.

# OpenWebUI via Docker (se connecte automatiquement à Ollama local)
docker run -d \
  --name open-webui \
  -p 3000:8080 \
  --add-host=host.docker.internal:host-gateway \
  -e OLLAMA_BASE_URL=http://host.docker.internal:11434 \
  -v open-webui:/app/backend/data \
  ghcr.io/open-webui/open-webui:main

# Accéder à l'interface : http://localhost:3000

OpenWebUI détecte automatiquement tous les modèles disponibles dans Ollama et les propose dans un menu déroulant. Créez un compte administrateur à la première connexion, puis invitez vos collègues — OpenWebUI gère les utilisateurs, l’historique des conversations et peut servir une équipe complète depuis un seul serveur partagé. La fonction RAG intégrée permet d’uploader des PDF et de les inclure dans le contexte des réponses, ce qui est particulièrement utile pour analyser des contrats OHADA ou des bilans comptables.

Étape 6 — Fine-tuning LoRA via Unsloth : concept et import Modelfile

Le fine-tuning consiste à réentraîner partiellement un modèle sur un corpus spécialisé pour améliorer ses performances sur des tâches précises. LoRA (Low-Rank Adaptation) est la technique dominante pour le fine-tuning efficace : au lieu de modifier tous les milliards de paramètres du modèle, on entraîne uniquement de petites matrices d’adaptation (les adapteurs LoRA) qui représentent typiquement 0,1 % à 1 % des paramètres totaux. Cela réduit drastiquement les besoins en mémoire GPU et en temps de calcul.

Unsloth est la bibliothèque Python qui rend ce processus accessible : elle optimise les noyaux d’attention CUDA pour que le fine-tuning d’un modèle 7B tienne dans 8 Go de VRAM (contre 16-24 Go avec les implémentations naïves), et elle exporte directement en GGUF pour un import immédiat dans Ollama. Sur CPU uniquement, Unsloth peut faire le fine-tuning mais c’est extrêmement lent — comptez plusieurs jours pour un corpus de taille modérée. Un GPU NVIDIA avec 8 Go de VRAM minimum est très fortement recommandé pour cette étape.

# Installer Unsloth dans un environnement virtuel Python
python3 -m venv unsloth-env
source unsloth-env/bin/activate
pip install unsloth

# Vérifier que CUDA est disponible
python -c "import torch; print(torch.cuda.is_available())"

# Script minimal de fine-tuning LoRA avec Unsloth
from unsloth import FastLanguageModel
import torch

# Charger le modèle de base en 4-bit
model, tokenizer = FastLanguageModel.from_pretrained(
    model_name = "unsloth/mistral-7b-instruct-v0.3-bnb-4bit",
    max_seq_length = 4096,
    dtype = None,          # auto-détection float16/bfloat16
    load_in_4bit = True,
)

# Ajouter les adapteurs LoRA
model = FastLanguageModel.get_peft_model(
    model,
    r = 16,                # rang LoRA — 8 à 32 selon la tâche
    target_modules = ["q_proj", "k_proj", "v_proj", "o_proj"],
    lora_alpha = 16,
    lora_dropout = 0.05,
    bias = "none",
    use_gradient_checkpointing = True,
)

# ... [votre dataset OHADA au format Alpaca] ...

# Export vers GGUF Q4_K_M
model.save_pretrained_gguf(
    "syscohada-finetuned",
    tokenizer,
    quantization_method = "q4_k_m"
)

Une fois le fichier GGUF exporté (il se trouvera dans le répertoire syscohada-finetuned/), vous l’importez dans Ollama via un Modelfile qui pointe vers le fichier local au lieu d’un modèle de la librairie. C’est le pont entre Unsloth et Ollama.

# Modelfile.finetuned — import du GGUF local
FROM ./syscohada-finetuned/unsloth.Q4_K_M.gguf

SYSTEM "Tu es un assistant OHADA/SYSCOHADA fine-tuné sur corpus juridique et comptable."

PARAMETER temperature 0.2
PARAMETER num_ctx 4096

# Construire et tester le modèle fine-tuné
ollama create syscohada-ft -f ./Modelfile.finetuned
ollama run syscohada-ft "Quelles sont les obligations de publication des comptes annuels selon l OHADA ?"

Une note importante sur la conformité du corpus : le fine-tuning ne doit être réalisé que sur des données de sources licites et à contenu halal. Pour une PME ouest-africaine, les corpus idéaux incluent l’Acte uniforme OHADA sur les sociétés commerciales, le référentiel SYSCOHADA révisé, les jurisprudences de la CCJA, et vos propres documents internes (contrats, rapports financiers). N’utilisez jamais un corpus dont vous ne contrôlez pas la provenance.

Étape 7 — Embedding models pour RAG

Les embeddings sont des représentations vectorielles de texte qui capturent le sens sémantique d’un passage. Dans un pipeline RAG (Retrieval-Augmented Generation), on encode d’abord tous vos documents en vecteurs, on stocke ces vecteurs dans une base vectorielle (ChromaDB, pgvector, Qdrant), puis lors d’une requête utilisateur, on encode la question, on cherche les passages les plus proches sémantiquement, et on les injecte dans le contexte du LLM pour que sa réponse soit ancrée dans vos données réelles. Ollama supporte nativement les modèles d’embedding, ce qui simplifie grandement ce pipeline.

# Télécharger des modèles d'embedding via Ollama
ollama pull nomic-embed-text      # 274 Mo, anglais-centrique, rapide
ollama pull mxbai-embed-large     # 670 Mo, meilleur en anglais

# Générer un embedding via l'API REST
curl http://localhost:11434/api/embeddings \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "nomic-embed-text",
    "prompt": "Acte uniforme portant organisation des procédures collectives d apurement du passif"
  }'

# Pipeline RAG minimal avec ChromaDB et Ollama embeddings
import chromadb
import requests
import json

# Fonction d'embedding via Ollama
def get_embedding(text, model="nomic-embed-text"):
    response = requests.post(
        "http://localhost:11434/api/embeddings",
        json={"model": model, "prompt": text}
    )
    return response.json()["embedding"]

# Initialiser ChromaDB (base vectorielle locale)
client = chromadb.Client()
collection = client.create_collection("ohada-docs")

# Indexer des passages de documents
passages = [
    "Article 13 AUDSC : Le capital social doit être intégralement souscrit...",
    "SYSCOHADA Classe 4 : Les comptes de tiers enregistrent les créances...",
]
for i, passage in enumerate(passages):
    collection.add(
        documents=[passage],
        embeddings=[get_embedding(passage)],
        ids=[f"doc_{i}"]
    )

# Requête RAG
query = "Qu'est-ce que le capital social minimal ?"
results = collection.query(
    query_embeddings=[get_embedding(query)],
    n_results=2
)
print(results["documents"])

Pour un corpus multilingue mêlant le français, le wolof, le dioula ou d’autres langues d’Afrique de l’Ouest, le modèle BAAI/bge-m3 (disponible sur Hugging Face) est une référence : il supporte plus de 100 langues avec des performances excellentes sur le français et les langues africaines ayant du texte disponible en ligne. Bien qu’il ne soit pas directement disponible dans la librairie Ollama, vous pouvez l’utiliser via la bibliothèque Python sentence-transformers et construire le pipeline RAG avec les mêmes primitives ChromaDB. Pour la plupart des cas d’usage professionnels franco-africains, nomic-embed-text via Ollama reste la solution la plus simple à déployer et offre des résultats satisfaisants sur les corpus en français standard.

Erreurs fréquentes

Adaptation au contexte ouest-africain

La réalité d’une PME ou d’une startup tech à Dakar, Abidjan, Bamako ou Ouagadougou diffère significativement des conditions supposées par la plupart des tutoriels anglophones. Voici comment adapter chaque aspect de ce tutoriel à ces contraintes réelles.

Matériel et RAM. La bonne nouvelle est qu’un CPU moderne avec 16 Go de RAM suffit pour faire tourner Mistral 7B Q4_K_M à une vitesse acceptable pour des usages professionnels — entre 4 et 10 tokens par seconde selon le processeur. Un Intel Core i7 de 10e génération ou un Ryzen 5 5600 produira environ 6-8 tokens/s, ce qui représente quelques secondes par réponse courte. C’est tout à fait utilisable pour un assistant interne qui aide un comptable à rédiger des courriers ou à retrouver des références OHADA. Pas besoin de louer un GPU cloud pour cette charge de travail.

Téléchargement des modèles avec une connexion lente. Un modèle de 4 Go sur une connexion à 2 Mbps prend environ 4-5 heures. Stratégies : (1) lancer le téléchargement la nuit ou en heures creuses via nohup ollama pull mistral & pour qu’il continue en arrière-plan ; (2) si vous avez un collègue à Dakar ou Abidjan avec une meilleure connexion, le fichier GGUF peut être copié via une clé USB ou un disque externe — Ollama stocke les modèles dans ~/.ollama/models/ et vous pouvez les copier d’une machine à l’autre ; (3) utiliser une connexion mobile 4G pour le téléchargement initial si disponible.

Fine-tuning sur corpus FR-OHADA/SYSCOHADA. L’un des cas d’usage les plus pertinents pour l’Afrique de l’Ouest francophone est le fine-tuning d’un LLM sur le corpus juridique OHADA. Les textes de l’OHADA (17 Actes uniformes) sont disponibles en libre accès sur ohada.com et représentent un corpus d’environ 2 000 pages structurées en français juridique. Le référentiel SYSCOHADA révisé (2017) est également public. Un fine-tuning LoRA de Mistral 7B sur ce corpus, avec 500-2000 paires question-réponse annotées par un expert comptable ou juriste, peut produire un assistant qui cite correctement les articles et comprend la terminologie spécifique — ce que le modèle de base fait approximativement mais pas avec la précision nécessaire pour un usage professionnel.

Embeddings multilingues pour les contextes multi-langues. Dans les pays d’Afrique de l’Ouest, les documents professionnels sont principalement en français mais les échanges oraux — et parfois écrits informels — mêlent le wolof, le bambara, le dioula, le mooré ou le fon. Pour un RAG qui doit traiter des emails ou des notes en langues mélangées, BAAI/bge-m3 (via pip install sentence-transformers et BAAI/bge-m3 depuis Hugging Face) est le choix le plus robuste : il a été entraîné sur plus de 100 langues et gère correctement le code-switching français/wolof qu’on retrouve fréquemment dans les communications professionnelles sénégalaises.

Économie GPU cloud. Si vous avez besoin de GPU pour le fine-tuning Unsloth, les options abordables depuis l’Afrique incluent : Google Colab Pro (moins de 10 USD/mois, T4/V100 disponibles), Vast.ai (locations GPU à la demande, souvent 0.20-0.40 USD/h pour un RTX 3090), et Paperspace Gradient. L’idée est de n’utiliser le GPU cloud que pour la phase de fine-tuning (quelques heures), puis d’exporter le GGUF et de faire tourner l’inférence sur votre serveur local CPU — le meilleur des deux mondes en termes de coût.

Tutoriels frères

• Installer et configurer OpenWebUI en production — tutoriel complet 2026 — interface conversationnelle multi-utilisateurs pour votre stack LLM local
• LiteLLM proxy : unifier LLM locaux et cloud derrière une API unique (2026) — gérer Ollama, Claude et GPT-4 depuis un seul endpoint
• RAG avec ChromaDB et LangChain : interroger vos documents locaux (2026) — construire un pipeline RAG complet sur vos propres données

Pour aller plus loin

• Retour au guide général : LLM en self-hosted pour PME francophone : OpenWebUI, LiteLLM, vLLM (2026)
• ollama.com — documentation officielle, librairie de modèles, changelog
• github.com/ollama/ollama — code source, issues, Modelfile reference
• github.com/unslothai/unsloth — documentation Unsloth, exemples de fine-tuning LoRA
• huggingface.co/BAAI/bge-m3 — modèle d’embedding multilingue pour RAG
• Tutoriel suivant recommandé dans la série : RAG avec ChromaDB — interroger vos documents OHADA localement

FAQ

Q : Quelle est la différence entre Ollama et llama.cpp directement ?

Ollama encapsule llama.cpp dans un daemon avec API REST, gestion automatique des modèles (téléchargement, stockage, versioning) et une CLI simple. llama.cpp vous donne plus de contrôle bas-niveau (paramètres d’inférence très fins, GGML/GGUF custom) mais demande plus de configuration. Pour une équipe, Ollama est presque toujours le meilleur choix. Pour de la recherche sur l’inférence ou des modèles très exotiques, llama.cpp directement peut valoir la peine.

Q : Puis-je utiliser des modèles téléchargés depuis Hugging Face avec Ollama ?

Oui, si le modèle est disponible au format GGUF. De nombreux modèles HuggingFace ont une version GGUF uploadée par la communauté (cherchez le suffixe -GGUF dans les dépôts). Téléchargez le fichier .gguf, créez un Modelfile avec FROM /chemin/vers/model.gguf, puis ollama create mon-model -f ./Modelfile. Si le modèle n’est qu’en safetensors, vous devrez d’abord le convertir en GGUF via les scripts de llama.cpp (convert.py + quantize).

Q : Est-ce que le fine-tuning via Unsloth modifie le modèle de base téléchargé par Ollama ?

Non. Unsloth travaille sur des poids téléchargés depuis Hugging Face dans votre environnement Python, indépendamment d’Ollama. Vous produisez un nouveau fichier GGUF que vous importez ensuite dans Ollama via un nouveau Modelfile. Le modèle original d’Ollama reste intact. Vous pouvez avoir en parallèle mistral:7b-instruct-q4_K_M (généraliste) et syscohada-ft:latest (fine-tuné) dans ollama list.

Q : Quelle est la taille minimale de dataset recommandée pour un fine-tuning LoRA utile ?

Pour un cas d’usage métier ciblé (par exemple, améliorer la précision sur les termes OHADA), 500 à 1 000 paires question-réponse de haute qualité suffisent généralement pour observer une amélioration notable. La qualité prime sur la quantité : un corpus de 200 exemples précis et annotés par un expert vaut mieux que 2 000 exemples générés automatiquement avec des approximations. Pour un changement de comportement plus profond (style de réponse, format, langue), comptez 2 000 à 5 000 exemples.

Q : Comment partager un modèle Ollama avec toute mon équipe sans que chacun le télécharge ?

Deux approches : (1) Serveur partagé — installer Ollama sur un serveur accessible en LAN, démarrer avec OLLAMA_HOST=0.0.0.0:11434 ollama serve, et pointer tous les clients vers l’IP du serveur. (2) Copie physique — copier le répertoire ~/.ollama/models/ sur une clé USB ou disque externe et copier-coller sur chaque machine. Les fichiers GGUF sont portables entre machines de même architecture.

Q : Ollama supporte-t-il les modèles multimodaux (texte + image) ?

Oui, depuis la version 0.1.15, Ollama supporte les modèles multimodaux comme LLaVA et BakLLaVA. Vous pouvez passer des images en base64 via l’API /api/generate avec le champ images. Ces modèles sont plus lourds (LLaVA 7B Q4 pèse environ 4,5 Go) et nécessitent plus de RAM. Pour un usage purement texte (RAG sur documents PDF, assistant comptable), les modèles texte-seul restent plus performants et moins gourmands.

Q : Comment savoir si mon GPU est bien utilisé par Ollama ?

Pendant une inférence, lancez nvidia-smi dans un autre terminal — vous devriez voir la VRAM utilisée augmenter et les GPU Utilization monter. Ollama affiche aussi dans ses logs (journalctl -u ollama -f) les informations de chargement, notamment combien de couches du modèle ont été chargées sur GPU vs CPU. Si toutes les couches sont sur GPU, vous bénéficiez de l’accélération maximale. Si certaines couches restent sur CPU (message offloading X layers to GPU), la VRAM est partiellement utilisée — c’est normal si votre VRAM est plus petite que le modèle.