Meilleurs modèles de vision locaux 2026 : Gemma 4, Qwen3-VL, LLaVA & configuration Ollama

Faits rapides

• Ce que font les VLM : Entrée image + texte → sortie texte. Pas des générateurs d'images — ces modèles *comprennent* les images.
• Support Ollama : Gemma 4, Qwen3.8, Qwen3.5, Qwen3-VL, Llama 3.2 Vision, MiniCPM-V, LLaVA et Moondream sont dans la bibliothèque officielle d'Ollama ; InternVL, PaliGemma 2 et SmolVLM nécessitent des builds communautaires.
• Plus petits modèles utilisables : Moondream 2 (1,8B, 1,7 Go à télécharger), Qwen3-VL 2B (1,9 Go) et Qwen3.5 0.8B (1,2–1,3 Go).
• Plus grands modèles locaux pratiques : Qwen3.5 122B (81 Go) sur un Mac de 128 Go et Llama 3.2 Vision 90B (55 Go) sur un Mac de 96 Go+ (Apple M-Series) ou multi-GPU ; Qwen3-VL 235B exige 143 Go.
• Format d'entrée image : JPEG, PNG, WebP. Résolution maximale variable selon le modèle (1024×1024 à 4096×4096).
• Audio et vidéo : Gemma 4 E2B, E4B et 12B acceptent aussi l'audio ; toutes les tailles de Gemma 4 et Qwen3.8 traitent la vidéo image par image.
• Précision OCR : Qwen3.8 27B ≈ Qwen3-VL 8B ≈ Qwen3.5 9B > Gemma 4 > MiniCPM-V > LLaVA 1.6 13B > LLaVA 1.6 7B > Moondream 2.
• Multimodal = plus lent : Les VLM ajoutent un encodeur visuel au LLM — ~30–60 % plus lent qu'un modèle texte seul de même taille.

Qu'est-ce qu'un modèle vision-langage (VLM) ?

• Différence avec les générateurs d'images : Stable Diffusion, FLUX et DALL-E 3 génèrent des images à partir de texte. Les VLM sont des modèles image-vers-texte — ils décrivent, analysent et répondent à des questions sur les images.
• Différence avec l'OCR classique : L'OCR traditionnel (Tesseract) extrait du texte par reconnaissance de motifs. Les VLM comprennent le contexte — ils peuvent expliquer une table, répondre à des questions sur un graphique.
• Pourquoi les exécuter localement : Documents privés (dossiers médicaux, scans juridiques, relevés financiers), captures d'écran propriétaires, ou workflows où l'envoi d'images à des API cloud soulève des problèmes de conformité.
• Ce qu'ils ne peuvent pas faire : Générer des images, exécuter du code visible dans les captures d'écran, ou accéder à internet.

Modèles de vision locaux disponibles — Tableau comparatif

Comparaison illustrative : extraction de facture

Support multi-images

• MiniCPM-V accepte jusqu'à 4 images par prompt ; Qwen3-VL jusqu'à 8. LLaVA et Moondream n'acceptent qu'une image à la fois.
• Quand le multi-images est utile : Envoyer toutes les pages d'un PDF multi-pages, comparer deux photos de produit, analyser des captures avant/après dans un seul prompt.

Configuration via Ollama — étape par étape

• Étape 1 — Installer Ollama : Téléchargez depuis ollama.com pour macOS, Linux ou Windows. Installation en moins de 2 minutes.
• Étape 2 — Télécharger un modèle : ollama pull gemma4:e4b (6,6–9,5 Go à télécharger) pour les cartes de 8 Go, ollama pull qwen3-vl:8b (6,2 Go) pour l'OCR, ou ollama pull moondream (1,8B, 1,7 Go) pour les configs limitées en VRAM.
• Étape 3 — Utiliser via CLI : ollama run gemma4:e4b "Qu'y a-t-il dans cette image ? /chemin/photo.jpg" — placez le chemin de l'image dans le prompt ; ollama run n'a pas d'option --image.
• Étape 4 — Utiliser l'API HTTP : POST vers http://localhost:11434/api/generate avec l'image encodée en base64 dans le tableau images. Ajoutez un schéma JSON dans le champ format pour obtenir une sortie structurée.
• Étape 5 — Exemple Python : Utiliser la bibliothèque requests avec l'encodage base64 — voir le bloc de code ci-dessous.

import base64
import requests

def ask_vision_model(image_path: str, prompt: str, model: str = "gemma4:e4b") -> str:
    with open(image_path, "rb") as f:
        image_b64 = base64.b64encode(f.read()).decode("utf-8")

    response = requests.post(
        "http://localhost:11434/api/generate",
        json={
            "model": model,
            "prompt": prompt,
            "images": [image_b64],
            "stream": False,
        },
    )
    return response.json()["response"]

# Exemple d'utilisation
result = ask_vision_model("facture.png", "Extraire toutes les lignes et les montants totaux de cette facture.")
print(result)

Cas d'usage 1 : OCR et extraction de documents

• Ce qui fonctionne bien : Factures scannées, captures de PDF, notes manuscrites en lettres d'imprimerie, tableaux avec bordures claires.
• Ce qui fonctionne moins bien : Écriture cursive, scans sous 150 DPI, JPEG très compressés, textes superposés.
• Meilleurs modèles pour l'OCR : Qwen3-VL 8B et Qwen3.5 9B (classe 6–8 Go), Qwen3.8 27B (18 Go, 91,1 sur OmniDocBench 1.5 selon sa fiche modèle), Gemma 4 pour les types de documents mixtes.
• Prompt engineering pour l'OCR : « Extraire tout le texte de ce document tel qu'il est écrit. » Ou : « Retourner le contenu de cette facture en JSON avec les champs : fournisseur, date, lignes[], total. »
• Vs OCR classique : Les VLM sont plus lents mais plus sémantiques. Tesseract est plus rapide pour l'extraction de texte brut. Utiliser les VLM pour l'extraction de données structurées.

Cas d'usage 2 : Questions-réponses sur images

• Description de scènes : « Qu'y a-t-il sur cette photo ? » — objets, personnes, activités, décor.
• Catalogage de produits : Traiter des photos avec un template : « Décrire couleur, forme, matière, état. » Utile pour l'inventaire e-commerce sans API cloud.
• Accessibilité : Générer des textes alternatifs pour les images à grande échelle.
• Meilleurs modèles : Gemma 4 12B ou 26B A4B pour les Q&A sur photos. Qwen3.5 4B ou LLaVA 1.6 7B pour le traitement en volume, quand la vitesse prime sur la précision.
• Vitesse : La vitesse dépend du modèle, du GPU et de la longueur des descriptions — testez un échantillon de 20 images sur votre propre matériel avant de lancer un lot de milliers.

Cas d'usage 3 : Analyse de captures d'écran et UI

• Workflows développeur : Envoyer des captures de messages d'erreur : « Qu'est-ce qui ne va pas dans cette capture et comment le corriger ? »
• Génération de rapports de bugs : Créer automatiquement des descriptions de bugs à partir de captures d'écran.
• Monitoring de tableaux de bord : Analyser des captures pour détecter des anomalies.
• Tests d'accessibilité : Comparer des captures avant et après des modifications UI.
• Meilleurs modèles : InternVL 2.5 8B (build communautaire, solide sur l'UI), Gemma 4 et Qwen3-VL (support Ollama officiel, appel d'outils pour les workflows d'agents).

Cas d'usage 4 : Lecture de graphiques

• Ce qui fonctionne : Lire les étiquettes d'axes, identifier les tendances, comparer des hauteurs de barres.
• Ce qui est peu fiable : Extraction numérique précise sur des graphiques continus, pourcentages de diagrammes circulaires sans étiquettes.
• Stratégie de prompt : « Décris la tendance » fonctionne mieux que « Quelle est la valeur exacte en mars 2026 ? »
• Meilleurs modèles : InternVL 2.5 (compréhension solide des graphiques), Gemma 4 et Qwen3-VL (bons sur les graphiques bien étiquetés).
• Limite : Aucun VLM local n'extrait de façon fiable des valeurs précises de graphiques complexes en 2026.

Cas d'usage 5 : Analyse d'images vidéo

• Extraction d'images : ffmpeg -i video.mp4 -vf fps=1 frames/frame_%04d.jpg
• Analyse image par image : Envoyer chaque image au modèle avec un prompt cohérent.
• Résumé global : Collecter toutes les descriptions et les envoyer à un LLM texte.
• Cas d'usage : Revue de caméras de sécurité, analyse d'enregistrements de cours, inspection qualité en fabrication.
• Meilleurs modèles : Gemma 4 ou Qwen3.8 pour la qualité (tous deux acceptent nativement la vidéo image par image), Qwen3.5 4B ou LLaVA 1.6 7B pour la vitesse (débit d'images plus élevé).
• Réalité des performances : À ~1–3 secondes par image, une vidéo de 10 minutes (600 images) prend environ 10–30 minutes à traiter, selon le modèle et le GPU.

import base64
import subprocess
import os
import requests

def extract_frames(video_path: str, output_dir: str, fps: int = 1) -> list[str]:
    os.makedirs(output_dir, exist_ok=True)
    subprocess.run([
        "ffmpeg", "-i", video_path,
        "-vf", f"fps={fps}",
        f"{output_dir}/frame_%04d.jpg",
        "-y"
    ], check=True)
    return sorted([
        os.path.join(output_dir, f)
        for f in os.listdir(output_dir)
        if f.endswith(".jpg")
    ])

def analyze_frame(image_path: str, model: str = "gemma4:e4b") -> str:
    with open(image_path, "rb") as f:
        image_b64 = base64.b64encode(f.read()).decode("utf-8")
    response = requests.post(
        "http://localhost:11434/api/generate",
        json={
            "model": model,
            "prompt": "Describe what is happening in this frame in one sentence.",
            "images": [image_b64],
            "stream": False,
        },
    )
    return response.json()["response"]

frames = extract_frames("cours.mp4", "frames/", fps=1)
descriptions = [analyze_frame(f) for f in frames]
print("\n".join(f"[{i+1}s] {d}" for i, d in enumerate(descriptions)))

VRAM et réalité des performances

Modèles de vision locaux vs GPT-5.5 Vision

• Documents structurés (factures, formulaires) : Appréciation éditoriale, pas un benchmark mesuré : les bons modèles locaux s'approchent de GPT-5.5 Vision sur des documents propres et bien formatés — suffisant pour la production une fois la sortie validée.
• Scènes complexes, images ambiguës : Les modèles locaux restent nettement en retrait de GPT-5.5 Vision sur les images au contexte inhabituel, à l'éclairage difficile ou au contenu ambigu (appréciation éditoriale, non mesurée).
• Reconnaissance de l'écriture manuscrite : Modèles locaux nettement plus faibles, surtout pour le cursif.
• Extraction de données de graphiques : Peu fiable sur les deux, mais GPT-5.5 plus précis sur les valeurs numériques.
• Coût : GPT-5.5 Vision à 0,01–0,03 $ par image vs 0 $ en local. 10 000 images/mois = 100–300 $ économisés.
• Confidentialité : Traitement local — aucune image n'est envoyée aux serveurs OpenAI. La CNIL recommande le traitement local pour les données professionnelles sensibles.
• Vitesse : Les modèles locaux produisent environ 8–35 tokens/s sur une RTX 4070 selon leur taille (estimations indicatives, voir le tableau ci-dessus) ; la vitesse dans le cloud varie selon le fournisseur et la charge, mais le traitement local n'a pas de latence réseau pour les lots.

LLaVA en détail

• Architecture : Encodeur visuel CLIP ViT-L/14 + décodeur texte Llama-2 ou Mistral, reliés par une couche de projection linéaire.
• LLaVA 1.5 vs 1.6 : La version 1.6 (début 2024) a ajouté le support haute résolution via le découpage dynamique, améliorant significativement l'OCR et la lecture de graphiques.
• Entraînement : Instruction-tuning sur LLaVA-Instruct-150K — conversations visuelles générées à partir de légendes d'images.
• Points forts : Large base de connaissances, bien documenté, grande communauté, intégration Ollama étendue.
• Points faibles : OCR moins précis que Qwen3-VL et MiniCPM-V, analyse UI moins bonne qu'InternVL 2.5, dépassé globalement par Gemma 4 et la famille Qwen3.
• Pourquoi toujours recommandé : La plus grande communauté, le plus de tutoriels et d'exemples de prompts de tous les VLM locaux.
• Avis complet : LLaVA : avis (2026) — l'avis dédié de PromptQuorum, avec la nuance de licence Apache-2.0 plus modèle de base et de vraies commandes Ollama.

Qwen3-VL, Qwen3.5 et Qwen3.8 — Meilleur OCR et multilingue

• Architecture : Résolution dynamique jusqu'à 4096×4096 — bien supérieure à LLaVA 1.6 (672×672) ou Llama 3.2 Vision (1120×1120).
• OCR multilingue : Meilleure classe pour le chinois, japonais, coréen et anglais. Données d'entraînement multilingues étendues.
• Quelle taille : Qwen3-VL 8B est un téléchargement de 6,2 Go et convient aux cartes de 8 Go ; Qwen3.5 9B fait 6,6–7,6 Go ; Qwen3.8 27B fait 18 Go et demande une carte de 24 Go ; Qwen3-VL 32B fait 21 Go. Qwen3-VL n'a pas de variante 72B sur Ollama.
• Qwen3-VL 4B : téléchargement de 3,3 Go (contexte 256K), intermédiaire entre les builds 2B (1,9 Go) et 8B (6,2 Go) pour les cartes d'environ 4–6 Go de VRAM.
• Installation Ollama : ollama pull qwen3-vl:8b, ollama pull qwen3.5:9b ou ollama pull qwen3.8 — tous dans la bibliothèque de modèles Ollama.
• Multi-images : Jusqu'à 8 images par requête — capacité maximale de cette comparaison.
• Pages des modèles : Qwen3-VL sur Ollama, Qwen3.8-27B sur Hugging Face

Choisir son modèle de vision

• Moins de 4 Go de VRAM : Qwen3.5 2B (2,7–3,1 Go), Qwen3-VL 2B (1,9 Go) ou Moondream 2 (1,7 Go) sont les options pratiques. PaliGemma 2 (3B) et SmolVLM (2,2B) sont des alternatives en build communautaire. Aucun n'est adapté à l'OCR de texte dense.
• 6–8 Go de VRAM : Gemma 4 E4B pour les Q&R générales sur photos, Qwen3-VL 8B ou Qwen3.5 9B pour l'OCR de documents et le texte multilingue, LLaVA 1.6 7B quand le soutien de la communauté compte.
• 12–16 Go de VRAM : Gemma 4 12B (7,7–8,0 Go à télécharger) est la recommandation claire — de solides scores de vision pour sa taille, avec entrée audio et fenêtre de contexte de 256K. LLaVA 1.6 13B et InternVL 2.5 8B (captures d'écran UI et code) y tiennent aussi.
• 24 Go de VRAM : Gemma 4 26B A4B (16–19 Go), Gemma 4 31B (19–20 Go), Qwen3.8 27B (18 Go) ou Qwen3-VL 32B (21 Go) — l'option locale la plus proche de la qualité de vision du cloud.
• 96+ Go de mémoire unifiée (Apple M-Max/Ultra, multi-GPU) : Qwen3.5 122B (81 Go, exige un Mac de 128 Go) ou Llama 3.2 Vision 90B (55 Go) pour les plus grands modèles locaux ; tous deux exigent un matériel à forte mémoire et sont plus lents par token que les modèles de la classe 24 Go.
• Toujours vérifier les chiffres : Croiser toute valeur numérique extraite de graphiques avec les données source.

Questions fréquemment posées

Sources

• Fiche modèle Gemma 4 sur Hugging Face — licence Apache 2.0 de Google, modalités prises en charge par taille et résultats MMMU Pro.
• Gemma 4 sur Ollama — tags, tailles de téléchargement et fenêtres de contexte.
• Qwen3.8-27B sur Hugging Face — licence Apache 2.0, contexte de 262K, résultat OmniDocBench 1.5.
• Qwen3.5 sur Ollama et Qwen3-VL sur Ollama — tailles et tailles de téléchargement.
• Llama 3.2 Vision sur Ollama et issue Ollama #16547 — fiche du modèle et erreur de chargement mllama signalée.
• Page du projet LLaVA — Fiches modèles LLaVA 1.5 et 1.6, détails d'architecture et description du jeu de données.
• MiniCPM-V sur Ollama et OpenBMB sur Hugging Face — fiches modèles et benchmarks OCR.
• Moondream sur Ollama et Moondream sur GitHub — téléchargement du modèle et scripts d'inférence.
• InternVL 2.5 sur Hugging Face — Fiche modèle OpenGVLab et benchmarks documents et UI.
• Documentation Ollama — Support des modèles vision, sorties structurées, référence API et bibliothèque de modèles.
• PaliGemma 2 sur Hugging Face — Fiche modèle PaliGemma 2 3B de Google.
• SmolVLM sur Hugging Face — Fiche modèle SmolVLM de HuggingFace.
• Documentation multimodale de llama.cpp — modèles de vision pris en charge et utilisation de llama-server.
• Modèles pris en charge par vLLM — architectures multimodales que vLLM peut servir.
• Tags Gemma 4 sur Ollama — tailles des builds q4_K_M, q8_0, bf16, QAT et MLX.

Lectures complémentaires

• Quels modèles Ollama prennent en charge la vision ? — réponse rapide sur les modèles de la bibliothèque Ollama qui acceptent des images, avec les besoins en VRAM.
• Modèles de vision Ollama (2026) — un guide pratique et concentré pour exécuter des modèles de vision spécifiquement via Ollama : syntaxe CLI/API réelle et modèles réellement présents dans sa bibliothèque.
• VLM dans les cameras et sur les drones 2026 -- Les bases du VLM de bureau sont ici ; pour un deploiement embarque camera/drone, voir ce guide dedie au edge computing.
• Pipeline IA multimodale locale 2026 — Combiner modèles de vision, STT et TTS en une stack locale complète.
• Reconnaissance vocale locale 2026 : Whisper.cpp vs faster-whisper — Ajouter la saisie vocale en complément de la vision.
• TTS local et clonage vocal 2026 — Ajouter la synthèse vocale pour lire les réponses VLM.
• Installer Ollama — Prérequis : configuration et paramétrage d'Ollama.
• Guide matériel LLM local — Exigences VRAM et RAM pour l'inférence de modèles vision.