Publié le 21 mai 2026 · Lecture : 18 min

Benchmark Ollama 2026 : quel LLM local choisir selon votre GPU ? RTX 3060, 4070, 4090, 5090 et Apple M4

1. Méthodologie du benchmark

Comparer des LLMs locaux requiert une rigueur méthodologique stricte : les chiffres publiés sur des forums varient souvent du simple au double selon le matériel, le driver, la taille du contexte et la quantization. Voici les conventions utilisées dans cet article.

2. Tableau principal : VRAM + tokens/s (RTX 4090)

Ce tableau couvre les 11 modèles les plus utilisés sur Ollama en 2026, classés par taille croissante. Les tokens/s sont mesurés sur RTX 4090 24 GB avec Q4_K_M et num_ctx=4096.

Mesures indicatives — à reproduire localement. Tok/s sur RTX 4090 24 GB, Q4_K_M, num_ctx=4096, Ollama version récente. Intervalle ±20% selon système, pilotes et longueur de prompt. Sources : Ollama Hub, rapports techniques officiels, r/LocalLLaMA.

3. Benchmarks de qualité — MMLU et HumanEval

La vitesse ne dit rien de la qualité. Un modèle 3× plus lent peut valoir la peine s'il réduit les erreurs sur votre tâche. Voici les chiffres de qualité issus des rapports techniques officiels.

3.1 MMLU — connaissances académiques multidisciplinaires

Le Massive Multitask Language Understanding (MMLU) couvre 57 matières académiques (droit, médecine, mathématiques, histoire...) via des QCM à 4 choix. Un score de 50% correspond au hasard, 100% à la perfection. Les LLMs grand public se situent entre 60% et 90%.

3.2 HumanEval — génération de code Python

HumanEval (OpenAI) teste la capacité à compléter des fonctions Python à partir d'une docstring et de tests unitaires. Le score pass@1 indique le pourcentage de problèmes résolus correctement du premier coup.

4. Guide de sélection par GPU

En pratique, le choix du modèle se fait d'abord par contrainte VRAM. Voici les recommandations concrètes par GPU.

5. Apple Silicon — M3 et M4

L'Apple Silicon (M3, M4, M4 Pro, M4 Max) représente une alternative sérieuse aux GPU NVIDIA pour l'inférence locale. La mémoire unifiée (shared entre CPU et GPU) permet d'utiliser toute la RAM comme VRAM effective, sans les pénalités de transfert PCIe.

6. Quantization : Q4, Q5, Q8 — que choisir ?

La quantization réduit la précision numérique des poids du modèle pour diminuer la VRAM nécessaire. Comprendre les formats disponibles permet de choisir le bon compromis pour votre usage.

6.1 Comprendre K_M vs K_S

Les formats K_M (Medium) et K_S (Small) sont des variantes de la quantization Q-K (K-means calibration). La différence est dans les couches qui reçoivent un traitement spécial : K_M applique une quantization 6 bits aux couches d'attention (les plus sensibles à la précision) et 4 bits aux couches feedforward. K_S utilise du 4 bits partout. Résultat : K_M est légèrement plus grand (~5%) mais nettement meilleur sur les tâches de raisonnement.

6.2 Passer d'une quantization à l'autre avec Ollama

# Télécharger une quantization spécifique
ollama pull qwen3:8b:q8_0      # Q8 — qualité maximale
ollama pull qwen3:8b:q4_k_m   # Q4_K_M — défaut (identique à qwen3:8b)
ollama pull qwen3:8b:q5_k_m   # Q5_K_M — bon compromis

# Vérifier la quantization d'un modèle chargé
ollama show qwen3:8b --verbose

7. Configuration avancée Ollama

Les performances par défaut d'Ollama sont loin d'être optimales. Ces paramètres permettent d'extraire le maximum de votre matériel.

7.1 Variables d'environnement clés

# Linux / macOS — à ajouter dans ~/.bashrc ou ~/.zshrc

# Nombre de layers GPU — défaut : auto (toutes si VRAM suffisante)
export OLLAMA_NUM_GPU=99       # Force tout en GPU, pas de déchargement CPU

# Threads CPU pour les layers déchargées sur CPU
export OLLAMA_NUM_THREAD=8    # Égal au nombre de cœurs physiques P-cores

# Timeout avant déchargement du modèle de la VRAM (défaut : 5min)
export OLLAMA_KEEP_ALIVE=-1   # -1 = garder en VRAM indéfiniment

# Flash Attention — accélère l'attention sur les longs contextes
export OLLAMA_FLASH_ATTENTION=1

# KV cache en FP16 (défaut FP32) — divise par 2 la mémoire du cache
export OLLAMA_KV_CACHE_TYPE=f16  # si supporté par votre version

7.2 Options par requête (num_ctx, temperature)

import ollama

response = ollama.chat(
    model="qwen3:8b",
    messages=[{"role": "user", "content": "Explique les transformers en 3 points."}],
    options={
        "num_ctx": 4096,      # Contexte : plus petit = plus rapide
        "num_gpu": 99,        # Forcer tout sur GPU
        "temperature": 0.7,   # 0.7 pour usage général, 0.6 pour code/raisonnement
        "top_p": 0.9,
        "repeat_penalty": 1.1,
        "num_predict": 512,  # Limite la longueur de réponse
        "seed": 42,           # Reproductibilité pour les benchmarks
    }
)

7.3 Modelfile pour une configuration persistante

# Créer un Modelfile
# cat Modelfile
FROM qwen3:8b

# Paramètres fixes pour ce déploiement
PARAMETER num_ctx 8192
PARAMETER temperature 0.6
PARAMETER repeat_penalty 1.1

SYSTEM """Tu es un assistant expert en Python. Réponds en français, concisément."""

# Créer le modèle personnalisé
ollama create mon-qwen3-python -f Modelfile
ollama run mon-qwen3-python

8. Code Python pour benchmarker soi-même

Le script ci-dessous mesure les tokens/s de façon reproductible sur votre propre configuration. Il tourne plusieurs modèles en séquence et exporte les résultats.

"""
benchmark_ollama.py — Mesure tokens/s pour plusieurs modèles Ollama
pip install ollama
"""
import ollama
import time
import json
from statistics import mean, stdev

# Modèles à benchmarker — ajustez selon vos modèles téléchargés
MODELS = [
    "llama3.2:3b",
    "qwen3:4b",
    "llama3.1:8b",
    "qwen3:8b",
    "qwen3:14b",
]

# Prompt de test standard (longueur fixe pour comparabilité)
PROMPT = """Explique en détail le principe de l'attention multi-têtes dans les transformers. 
Décris le mécanisme mathématique, les queries, keys et values, 
et pourquoi l'attention scaled dot-product est préférable à l'attention simple."""

NUM_RUNS = 3          # Runs par modèle pour la moyenne
NUM_CTX = 4096        # Contexte fixe pour comparabilité


def benchmark_model(model: str, n_runs: int = 3) -> dict:
    """Mesure les tokens/s d'un modèle sur plusieurs runs."""
    results = []
    
    # Warm-up : premier run non compté (chargement du modèle)
    try:
        ollama.generate(
            model=model,
            prompt="test",
            options={"num_predict": 5, "num_ctx": 512}
        )
    except Exception as e:
        return {"model": model, "error": str(e)}
    
    for i in range(n_runs):
        start = time.perf_counter()
        
        resp = ollama.generate(
            model=model,
            prompt=PROMPT,
            options={
                "num_ctx": NUM_CTX,
                "num_predict": 256,
                "temperature": 0.0,  # Deterministe
                "seed": 42,
            }
        )
        
        elapsed = time.perf_counter() - start
        
        # Ollama fournit aussi eval_count et eval_duration dans la réponse
        eval_count = resp.get("eval_count", 0)
        eval_duration_ns = resp.get("eval_duration", 1)
        
        # Tokens/s depuis les métadonnées Ollama (plus précis)
        toks_per_s = eval_count / (eval_duration_ns / 1e9) if eval_duration_ns > 0 else 0
        
        results.append({
            "run": i + 1,
            "tokens_generated": eval_count,
            "elapsed_s": round(elapsed, 2),
            "tokens_per_s": round(toks_per_s, 1),
        })
        print(f"  Run {i+1}/{n_runs}: {toks_per_s:.1f} tok/s ({eval_count} tokens, {elapsed:.2f}s)")
    
    tps_values = [r["tokens_per_s"] for r in results]
    return {
        "model": model,
        "runs": results,
        "mean_tps": round(mean(tps_values), 1),
        "std_tps": round(stdev(tps_values), 1) if len(tps_values) > 1 else 0,
        "min_tps": round(min(tps_values), 1),
        "max_tps": round(max(tps_values), 1),
    }


def run_benchmark():
    all_results = []
    
    print(f"Benchmark Ollama — {len(MODELS)} modèles, {NUM_RUNS} runs chacun\n")
    
    for model in MODELS:
        print(f"\n{'='*50}\nModèle : {model}")
        result = benchmark_model(model, NUM_RUNS)
        all_results.append(result)
        
        if "error" not in result:
            print(f"  --> Moyenne : {result['mean_tps']} ± {result['std_tps']} tok/s")
    
    # Résumé trié par vitesse
    print("\n\n=== RÉSULTATS TRIÉS PAR VITESSE ===")
    valid = [r for r in all_results if "error" not in r]
    valid.sort(key=lambda x: x["mean_tps"], reverse=True)
    
    for r in valid:
        print(f"  {r['model']:25s} {r['mean_tps']:6.1f} tok/s  (min:{r['min_tps']} max:{r['max_tps']})")
    
    # Export JSON
    with open("benchmark_results.json", "w") as f:
        json.dump(all_results, f, indent=2, ensure_ascii=False)
    print("\nRésultats exportés dans benchmark_results.json")


if __name__ == "__main__":
    run_benchmark()

9. Benchmarks en contexte RAG

Les benchmarks tokens/s sur des prompts courts ne reflètent pas les performances réelles dans un pipeline RAG, où les contextes sont typiquement de 2 000 à 8 000 tokens. La vitesse décroît avec la taille du KV cache.

Estimations sur RTX 4090, Q4_K_M. La dégradation avec le contexte est liée à la croissance linéaire du KV cache. OLLAMA_FLASH_ATTENTION=1 réduit cette dégradation de 15 à 25%.

"""Pipeline RAG minimal avec Ollama — mesure des performances"""
import ollama
import time

def rag_query(model: str, documents: list[str], question: str) -> dict:
    """Requête RAG avec mesure de performance."""
    context = "\n\n".join(documents)
    
    prompt = f"""Réponds uniquement à partir des documents suivants.

Documents :
{context}

Question : {question}

Réponse :"""
    
    start = time.perf_counter()
    resp = ollama.generate(
        model=model,
        prompt=prompt,
        options={
            "num_ctx": 8192,
            "temperature": 0.1,
            "num_predict": 512,
        }
    )
    elapsed = time.perf_counter() - start
    
    tps = resp.get("eval_count", 0) / (resp.get("eval_duration", 1) / 1e9)
    
    return {
        "response": resp["response"],
        "tokens_per_s": round(tps, 1),
        "total_time_s": round(elapsed, 2),
        "context_tokens": resp.get("prompt_eval_count", 0),
    }

10. Analyse modèle par modèle

10.1 llama3.1:8b — la référence équilibrée

Le llama3.1:8b de Meta reste la valeur sûre de la catégorie 8B. Avec 4.9 GB en Q4_K_M, il tient dans presque tous les GPU récents. Son point fort est la constance : bonnes performances en anglais et en français, excellent support tool use, intégration native dans LangChain et LlamaIndex. MMLU à 73.0% et HumanEval à 62.0%. Contexte de 128K tokens.

10.2 qwen3:8b — meilleur sur le code

Le qwen3:8b (Alibaba) dépasse le llama3.1:8b sur les tâches de code (HumanEval 73.2% vs 62.0%) et de raisonnement, au prix d'une VRAM légèrement supérieure (5.2 GB). Selon le modèle et le template Ollama utilisé, le mode thinking peut être activé via le format attendu par le modèle. Son vocabulaire de 151K tokens le rend aussi plus efficace sur les langues non-latines.

10.3 gemma3:12b — multimodal unique dans sa catégorie

Le gemma3:12b (Google DeepMind) est le seul modèle de cette liste avec des capacités de vision (analyse d'images) sous Ollama. Avec 8.1 GB VRAM et 50–65 tok/s sur RTX 4090, c'est le meilleur choix si vous avez besoin de traiter des images localement. Ses benchmarks texte (MMLU 72.8%) sont solides mais légèrement inférieurs à qwen3:8b.

10.4 phi4:14b — champion MMLU de sa taille

Microsoft phi4:14b atteint 84.8% MMLU et 82.6% HumanEval — des scores proches de modèles deux fois plus grands. Son secret : un entraînement intensif sur des données synthétiques de haute qualité (textbooks, exercices STEM). Attention : fenêtre de contexte limitée à 16K tokens (vs 128K pour qwen3:14b).

10.5 qwen3:32b — roi du 24 GB

Sur une RTX 4090 ou RTX 3090, le qwen3:32b (20 GB Q4_K_M) est le meilleur choix absolu. MMLU à 87.0%, HumanEval à 86.5%, contexte 128K. Avec thinking mode, il rivalise avec des API cloud pour les tâches de raisonnement complexe. La vitesse de 20–28 tok/s est acceptable pour un usage interactif.

10.6 mistral:7b — choix legacy encore valide

Le mistral:7b est un modèle mature (2023) qui reste pertinent pour les intégrations existantes. Il est légèrement en retrait sur MMLU (64.2%) et HumanEval (40.2%) comparé aux 8B récents, mais très rapide (95–120 tok/s) et bien supporté par tous les frameworks. À utiliser si votre code est déjà écrit pour Mistral.

11. Inférence CPU seule : ce qu'il faut savoir

Sans GPU dédié, Ollama utilise llama.cpp en mode CPU. Les performances sont drastiquement inférieures mais restent fonctionnelles pour les petits modèles.

# Forcer l'inférence CPU uniquement (même si GPU présent)
export OLLAMA_NUM_GPU=0

# Optimiser le nombre de threads CPU
export OLLAMA_NUM_THREAD=16    # Mettre le nombre de cœurs physiques

# Sous Windows PowerShell
$env:OLLAMA_NUM_GPU="0"
$env:OLLAMA_NUM_THREAD="16"

12. Évolutions attendues en 2026

Le paysage des LLMs locaux évolue rapidement. Plusieurs tendances se dessinent pour la deuxième moitié de 2026.

FAQ

Conclusion

Le choix du bon LLM local dépend avant tout de votre GPU. Avec 12 GB de VRAM (RTX 3060), le llama3.1:8b ou qwen3:8b offrent un excellent point d'entrée à 40–85 tok/s. Avec 16 GB (RTX 4070), le qwen3:14b ou phi4:14b franchissent un palier qualitatif significatif. Avec 24 GB (RTX 4090), le qwen3:32b rivalise sérieusement avec les APIs cloud pour les tâches de code et de raisonnement.

La quantization Q4_K_M reste le meilleur compromis par défaut — une perte de 1 à 2% sur les benchmarks pour une réduction de VRAM par 4. Activez OLLAMA_FLASH_ATTENTION=1 et OLLAMA_KEEP_ALIVE=-1 pour optimiser les performances sans effort.