DeepSeek VL

Les modèles d’IA vision-langage open source comme DeepSeek-VL et DeepSeek-VL2 attirent l’attention des développeurs car ils promettent d’analyser simultanément des images et du texte, à l’instar de GPT-4 Vision. Lancé en 2024, DeepSeek-VL a été conçu pour des tâches multimodales réalistes : lecture de documents PDF scannés, OCR de texte imprimé, interprétation de graphiques, etc. Sa nouvelle génération DeepSeek-VL2 (fin 2024) a poussé plus loin ces capacités, en améliorant la précision sur l’OCR, la compréhension de tableaux ou pages web, et même la localisation d’objets dans l’image.

En pratique, ces modèles permettent d’imaginer des applications concrètes : extraction automatisée de données depuis des factures ou formulaires scannés, analyse d’une capture d’écran d’interface, comparaison visuelle de produits avant/après, moteur de recherche d’images par description, etc. Tout cela sans passer par une API propriétaire et en pouvant héberger le modèle sur son propre environnement. Ce guide vous propose d’explorer comment utiliser DeepSeek-VL et VL2 en 2026, avec un angle résolument développeur : on va comparer les deux versions, expliquer comment les déployer en local, détailler les cas d’usages couverts (OCR, tableaux, grounding d’objets…), fournir des exemples de code reproductibles, et vous aider à choisir la variante la mieux adaptée à votre projet.

TL;DR: DeepSeek-VL (2024) et DeepSeek-VL2 (2024 fin) sont des modèles vision+langage open source de DeepSeek, capables de décrire des images, lire du texte dans les images (OCR), comprendre des documents structurés (tables, graphiques) et localiser des objets via langage. VL2 apporte une architecture améliorée (encodage tiling haute résolution, LLM en Mixture-of-Experts) offrant de meilleures performances sur l’OCR, le grounding et le multitâche multimodal. Aucun de ces modèles n’est intégré à l’API cloud officielle DeepSeek (centrée texte) à date. Vous devez donc les déployer vous-même (via Transformers/PyTorch) avec un GPU adapté (Tiny : ~1,0B de paramètres activés ; Small : ~2,8B ; DeepSeek-VL2 : ~4,5B. Le script d’inférence simple de deepseek-vl2-small peut demander ~80 Go de VRAM, avec une exécution possible sur GPU 40 Go via incremental prefilling, plus lente). Ce guide vous explique comment choisir la variante, quelles tâches sont réalisables, donne du code d’inférence (image unique, multiple images), et décrit trois scénarios tests (OCR d’une facture, analyse d’un graphique, compréhension d’une UI). Enfin, on aborde honnêtement les limites (VRAM, latence, parsing des réponses OCR/grounding) et dans quels cas privilégier d’autres solutions plus simples.

Table des matières

• DeepSeek-VL vs DeepSeek-VL2 : ce qui change concrètement
• DeepSeek-VL/VL2 vs API cloud DeepSeek : ne pas confondre
• Cas d’usage concrets pris en charge
  • OCR de documents scannés
  • Compréhension de tableaux et graphiques
  • Analyse de captures d’écran d’interface (UI)
  • Visual grounding (localisation d’objets par description)
  • Comparaison de plusieurs images
• Choisir la bonne variante (Tiny, Small, DeepSeek-VL2)
• Contraintes matérielles et déploiement local
• Exemple de code 1 : inférence simple sur une image
• Exemple de code 2 : conversation avec plusieurs images
• Trois mini-expériences reproductibles
  1. Facture scannée (OCR)
  2. Graphique de données
  3. Capture d’écran d’application
• Limites et pièges à connaître
• Quand utiliser VL/VL2… et quand préférer autre chose
• Conclusion – DeepSeek-VL(2) dans votre projet
• FAQ – Foire aux questions
• Sources officielles

DeepSeek-VL vs DeepSeek-VL2 : ce qui change concrètement

DeepSeek-VL est le premier modèle vision-langage de DeepSeek, dévoilé en mars 2024. Il s’appuie sur un backbone de langage de grande taille (versions 1,3 milliard et 7 milliards de paramètres) couplé à un encodeur visuel hybride capable d’ingérer des images haute résolution (jusqu’à 1024×1024) tout en restant efficace. Concrètement, l’encodeur combine deux approches : une première passe pour la sémantique globale de l’image, et une seconde passe pour capturer les détails fins (petit texte, éléments minuscules). Les sorties visuelles sont projetées dans l’espace du modèle langage, permettant à l’IA de raisonner sur l’image et le texte conjointement. DeepSeek-VL a été affiné sur des instructions multimodales couvrant des scénarios utilisateurs réels (par ex. lire une page web, expliquer un diagramme) plutôt que de simples sets académiques. Chaque variante existe en version Base (génération neutre) et Chat (tournée conversation).

DeepSeek-VL2, publié fin 2024, représente une évolution majeure sur plusieurs points. D’abord, il adopte une architecture à Mixture-of-Experts (MoE) côté langage : le backbone LLM utilise plusieurs experts spécialisés activés dynamiquement, au lieu d’un modèle dense classique. Cela permet à VL2 d’afficher des performances équivalentes ou supérieures aux modèles ouverts existants, avec moins de paramètres activés (4,5B actifs pour DeepSeek-VL2). Ensuite, côté vision, DeepSeek-VL2 introduit un encodage haute résolution par découpage dynamique (dynamic tiling) : l’image est redimensionnée puis découpée en tuiles de 384×384 pixels (plus une tuile globale). Chaque tuile passe dans le même encodeur visuel (un modèle type ViT optimisé) avant de réunir les features. Ce procédé capture beaucoup plus de détails sur de grandes images (documents A4, plans, interfaces…) sans exploser le nombre de tokens visuels. En parallèle, le LLM utilise une technique de Multi-Head Latent Attention (MLA) qui compresse les caches d’attention en vecteurs latents, ce qui accélère l’inférence malgré la séquence multimodale plus longue. Au final, DeepSeek-VL2 maîtrise mieux les cas exigeant de l’ultra-haute résolution (OCR de très petits caractères, localisation précise dans une image) tout en étant plus efficace et plus rapide pour générer des réponses longues.

En termes de versions et tailles, DeepSeek-VL2 abandonne le schéma base/chat pour offrir directement des modèles utilisables en conversation. La famille se décline en trois variantes : DeepSeek-VL2-Tiny, DeepSeek-VL2-Small et DeepSeek-VL2, correspondant à environ 1,0 Md, 2,8 Mds et 4,5 Mds de paramètres activés respectivement. (Le nombre total de paramètres physiques est plus élevé que le nombre de paramètres activés, car l’architecture MoE n’active qu’une partie des experts à chaque requête.) À titre de comparaison, DeepSeek-VL proposait deux tailles d’environ 1,3 Md et 7 Mds (dense). Selon les sources officielles, la série DeepSeek-VL2 atteint des performances compétitives face à des modèles open source denses ou MoE de taille équivalente ou supérieure, notamment grâce à son architecture MoE. Autre amélioration notable : VL2 a étendu son domaine de compétences. Là où VL1 excellait déjà sur l’OCR, les pages web, les diagrammes et images naturelles, VL2 ajoute une maîtrise avancée des questions visuelles complexes (raisonnement logique sur image) et du visual grounding (localisation d’éléments décrits). Par exemple, DeepSeek-VL2 sait répondre à des requêtes de localisation en renvoyant des coordonnées précises de bounding box, ce que DeepSeek-VL gérait moins explicitement.

En résumé, DeepSeek-VL2 apporte une architecture plus puissante et efficiente et élargit les capacités multimodales. Pour un développeur, cela signifie potentiellement de meilleurs résultats sur des tâches comme la lecture de documents complexes, la compréhension de graphiques ou l’analyse d’interfaces, à condition de disposer de l’infrastructure pour faire tourner ces nouveaux modèles (point abordé plus loin).

DeepSeek-VL/VL2 vs API cloud officielle DeepSeek : ne pas confondre

Il est important de distinguer les modèles open source DeepSeek-VL/VL2 et l’API cloud DeepSeek officielle. DeepSeek (l’entreprise) propose en effet une plateforme API payante, mais celle-ci met en avant pour l’instant des modèles textuels : par exemple deepseek-chat et deepseek-reasoner correspondent au modèle de langage DeepSeek-V3.2 (128k de contexte). la documentation publique de l’API DeepSeek n’expose que les modèles deepseek-chat et deepseek-reasoner (DeepSeek-V3.2, 128K de contexte). Aucun support public d’entrée image n’y est documenté à ce jour. La documentation officielle ne mentionne pas de service d’OCR ou de vision disponible côté cloud, se concentrant sur les LLM de conversation et de raisonnement. Autrement dit, DeepSeek-VL et VL2 ne sont pas accessibles via l’API DeepSeek comme peuvent l’être GPT-4 Vision via l’API OpenAI ou les services Vision d’autres fournisseurs.

Cela signifie que si vous souhaitez utiliser ces modèles multimodaux dans votre application, vous devrez les déployer par vous-même (on-premise ou sur votre infra cloud) à partir des poids open source disponibles. La bonne nouvelle est que DeepSeek-AI fournit les modèles gratuitement sur des hubs comme GitHub et Hugging Face, avec une licence autorisant les usages commerciaux (nous y reviendrons). Il ne faut donc pas confondre DeepSeek-VL/VL2 (modèles open source à auto-héberger, soutenus par la communauté DeepSeek) et DeepSeek Chat/Platform (services officiels de DeepSeek Inc. pour le NLP, sans vision).

Ce que la documentation officielle confirme : Les dépôts officiels GitHub indiquent que DeepSeek-VL/VL2 prennent bien en charge l’OCR, la compréhension de documents/tableaux, le VQA (questions sur image), le visual grounding et d’autres tâches visuelles complexes. Ils fournissent également des démos Gradio en ligne (via Hugging Face Spaces) pour tester les modèles, et soulignent que les modèles sont publiés sous une licence permettant un usage commercial dans des conditions données.

Ce qu’elle ne documente pas publiquement : À ce jour, aucune API vision n’est proposée sur le cloud DeepSeek ; l’usage de DeepSeek-VL(2) passe par le téléchargement des modèles. Le repository DeepSeek-VL2 documente le format de sortie de grounding et fournit des indications pour parser les coordonnées retournées via les balises <|det|>, mais l’intégration applicative reste à gérer côté développeur. Enfin, aucun benchmark chiffré n’est donné dans la doc pour comparer VL vs VL2 sur des cas précis ; il faut se référer aux papiers de recherche pour les détails de performances.

Cas d’usage où ces modèles sont pertinents

L’intérêt principal de DeepSeek-VL et VL2 est de gérer des tâches multimodales variées via de simples invites en langage naturel. Voici les cas d’usage concrets pour lesquels ces modèles sont particulièrement adaptés :

OCR de documents et scans

Une application évidente est l’OCR intelligent sur des images contenant du texte. DeepSeek-VL/VL2 peuvent non seulement extraire le texte présent dans une image, mais aussi comprendre sa structure et répondre à des questions sur le document. Par exemple, donné une photo ou un scan de facture, le modèle peut renvoyer tout le texte reconnu (un peu comme un OCR classique) ou bien directement extraire des champs précis (total, date, numéro de facture) si on le lui demande en langage naturel. Ces modèles ont été entraînés sur des données de PDF numérisés, formulaires, pages imprimées, etc., ce qui les rend assez performants sur les documents structurés (même avec tableaux ou colonnes). DeepSeek-VL2 en particulier excelle sur les mises en page complexes où il faut conserver du contexte (par ex. lire un tableau dense avec entête et valeurs associées), là où un simple OCR renverrait du texte brut désordonné. Ce cas d’usage est précieux pour digitaliser des processus : traitement automatique de factures, extraction de texte de cartes de visite, lecture de panneaux ou d’étiquettes produits en situation réelle, etc. Plutôt que d’utiliser un OCR traditionnel suivi d’une étape de parsing manuelle, DeepSeek-VL2 peut comprendre le document et fournir directement l’information voulue en langage naturel. Par exemple, « Quel est le montant total et la TVA sur cette facture ? » sur l’image d’une facture pourrait générer une réponse du modèle du type : « Le montant total TTC est 1234,00 € et la TVA est 20% soit 205,67 € ».

Compréhension de tableaux et graphiques

Au-delà du texte brut, DeepSeek-VL/VL2 savent interpréter des représentations visuelles de données – un atout considérable pour analyser des rapports ou tableaux de bord. Par exemple, sur l’image d’un graphique (courbe, histogramme…), le modèle peut décrire la tendance et les conclusions qu’on peut en tirer. Si on fournit un diagramme de ventes mensuelles, il pourra répondre « Les ventes montrent une tendance à la hausse, atteignant un pic en décembre ». Cette compétence repose sur l’entraînement effectué sur des tableaux, graphiques et figures scientifiques. De même, présenté avec la photo d’un tableau imprimé ou d’un écran de tableur, DeepSeek-VL2 peut retrouver certaines valeurs ou résumer ce que le tableau contient. Il comprend les notions de lignes/colonnes et des intitulés, ce qui lui permet de répondre à des questions du type « Quelle est la valeur maximale dans ce tableau et à quelle catégorie correspond-elle ? ». Bien sûr, la précision dépend de la clarté de l’image et de la lisibilité, mais la capacité du modèle à relier visuellement des éléments de tableau à des questions textuelles est un net avantage. Pour un développeur, cela ouvre des possibilités en Business Intelligence automatisée : on peut imaginer alimenter le modèle avec des captures de tableaux de bord (ou exporter en image des graphiques générés dynamiquement) et laisser l’IA produire un commentaire ou répondre aux interrogations de l’utilisateur sur ces données.

Analyse de captures d’écran d’interface (UI)

Un autre cas d’utilisation pertinent est l’analyse des captures d’écran d’applications ou de pages web. DeepSeek-VL2 a été entraîné non seulement sur des images naturelles, mais aussi sur des captures d’écrans et interfaces graphiques (GUI). Il peut reconnaître des éléments d’UI tels que des boutons, menus, icônes, champs de formulaire, etc., et comprendre l’agencement général. Par exemple, en fournissant une capture d’écran d’une application SaaS, on peut demander « Quels sont les principaux sections ou onglets visibles sur cette interface ? ». Le modèle pourrait répondre « En haut se trouve une barre de navigation avec les onglets Dashboard, Rapports, Utilisateurs… À gauche un menu latéral avec des sections (Vue d’ensemble, Statistiques, Paramètres), et la partie centrale affiche un graphique de ventes mensuelles… ». Ce niveau de compréhension structurelle est très utile pour des tâches comme la documentation automatique (décrire une interface logiciel), les tests UI (vérifier la présence de tel élément), ou l’accessibilité (générer une description textuelle de ce qui est affiché pour un utilisateur malvoyant). DeepSeek-VL2 peut servir de base à un assistant capable d’orienter un utilisateur dans une application sur la base de screenshots, ou d’analyser des retours écran. Il est à noter que le modèle ne renvoie pas de format JSON structuré des éléments d’UI ; il produit une description en langage naturel ou répond aux questions posées. Néanmoins, sa formation sur des données de type interface (pages web, formulaires) lui donne une compréhension qu’un modèle visuel générique n’aurait pas. Par exemple, sur une capture d’un panneau d’administration, le modèle peut identifier des zones comme le menu latéral, les onglets ou un graphique principal si l’image est suffisamment lisible.

Visual grounding (localisation d’objets par description)

La fonctionnalité de visual grounding est la capacité du modèle à localiser, dans une image, un élément qu’on décrit textuellement. Par exemple : « le modèle peut-il surligner l’extincteur rouge dans l’image ? ». DeepSeek-VL2 supporte nativement ce mode : il retourne alors les coordonnées de la bounding box de l’objet en question, encodées dans sa réponse. Techniquement, cela se fait via des tokens spéciaux introduits dans la conversation. On entoure la description de l’objet cible par <|ref|> ... <|/ref|> dans la question utilisateur, et le modèle inclura dans sa réponse le même identifiant <|ref|> suivi d’un token <|det|> contenant le rectangle détecté. Par exemple :

• User : <image> <|ref|>The red fire extinguisher<|/ref|>
• Assistant : <|ref|>The red fire extinguisher<|/ref|><|det|>[[x1, y1, x2, y2]]<|/det|>

Ici, [[x1, y1, x2, y2]] sont les coordonnées du coin haut-gauche et bas-droit de l’extincteur identifié. Bien sûr, ces coordonnées sont fournies en texte brut (le modèle reste un LM), à vous ensuite de les parser et de les utiliser (par ex. tracer un rectangle sur l’image côté application). DeepSeek-VL première génération pouvait décrire des objets mais ne renvoyait pas explicitement de coordonnées dans ce format. VL2 a clairement été entraîné pour ce language-based detection. Cela permet d’implémenter facilement des fonctionnalités du type « trouver dans l’image tel objet » ou de l’annotation automatique d’images : on demande « Décris et localise tous les objets de la scène », et le modèle peut retourner chaque objet mentionné accompagné de sa bbox. C’est notamment très utile en robotique (ex : « bras robot, prends l’outil mentionné »), en vision industrielle (repérer une pièce défectueuse décrite) ou pour créer rapidement des ensembles de données annotées à partir de descriptions. On soulignera que le modèle n’est pas un détecteur entraîné à la manière d’un YOLO : les coordonnées produites sont approximatives et dépendent de sa compréhension. Il peut se tromper si l’objet est mal décrit ou ambigu. Cependant, dans de nombreux cas simples (objets bien visibles et description sans équivoque), le grounding via DeepSeek-VL2 fonctionne et évite d’entraîner un détecteur spécifique.

Comparaison de plusieurs images

Enfin, DeepSeek-VL/VL2 savent gérer des conversations multi-images, c’est-à-dire raisonner sur plusieurs visuels fournis en entrée. On peut par exemple demander au modèle de comparer deux images ou d’identifier des différences entre elles. Ce cas d’usage s’applique aux scénarios avant/après (par ex. suivi de chantier, ou comparaison d’un produit neuf vs usagé) ou à la vérification de conformité (comparaison visuelle à un standard). Concrètement, on peut donner deux (ou plusieurs) images au modèle dans la même requête et poser une question englobant ces images. Par exemple : « <image> Image A … <image> Image B … Quelles différences y a-t-il entre A et B ? ». DeepSeek-VL2 va alors analyser chaque image et produire une réponse combinée du style « L’Image A montre le produit avant nettoyage avec des taches visibles, tandis que l’Image B le montre après nettoyage, sans taches et avec une couleur plus brillante. ». Le modèle peut aussi répondre à des questions du type « Laquelle de ces deux photos contient le plus de personnes ? » ou « Dans laquelle des deux images le produit semble plus grand ? ». Techniquement, VL2 peut accepter plusieurs images en entrée car son format de conversation prévoit une liste "images": ["img1.png", "img2.png", ...]. Lors de l’encodage, les images seront traitées chacune en tokenisation visuelle (éventuellement sans tiling au-delà de 2 images). Les auteurs indiquent toutefois que pour ≥ 3 images, ils désactivent le tiling et utilisent un padding à 384×384 par image pour simplifier. Donc le modèle gère le multi-image, mais les performances optimales (via tiling haute résol.) sont pour 1 ou 2 images à la fois. Malgré cela, cela suffit pour de la comparaison par paires ou même une petite série chronologique. En un seul appel, on peut avoir un raisonnement sur plusieurs images conjointement, une capacité qu’on ne trouve pas dans les OCR ou analyseurs traditionnels. En résumé, DeepSeek-VL2 peut agréger un contexte visuel multiple – très utile pour des pipelines où l’on veut donner un exemple visuel et une image cible, afin que le modèle trouve des similitudes ou applique un raisonnement analogique (par ex. « Compte les objets sur l’Image B en t’aidant de l’exemple sur l’Image A » – on parle alors de few-shot learning visuel).

Choisir la bonne variante : Tiny vs Small vs DeepSeek-VL2

DeepSeek-VL2 étant disponible en trois variantes, laquelle choisir pour votre projet ? La réponse va dépendre de vos contraintes de performance vs ressources.

• DeepSeek-VL2-Tiny : c’est le plus petit (~1 milliard de paramètres activés). Il est idéal pour débuter ou pour des déploiements à ressources limitées. Malgré son qualificatif Tiny, il repose sur une architecture MoE 3B et offre donc déjà des performances solides en OCR, VQA, etc., supérieures à la première génération 1.3B. Choisissez Tiny pour un prototype local ou un déploiement plus léger, à valider selon votre GPU, votre dtype et votre niveau d’optimisation. Il répondra correctement aux questions simples sur des images pas trop complexes. En revanche, il peut montrer ses limites sur des tâches très pointues ou des images surchargées d’information (documents très longs, texte minuscule flou, etc.).
• DeepSeek-VL2-Small : c’est le modèle intermédiaire (~2,8 Mds param. actifs). Il offre un meilleur compromis qualité/ressources si vous disposez d’un GPU à très grande mémoire ou d’une stratégie de déploiement optimisée. En pratique, l’inférence simple de deepseek-vl2-small peut demander environ 80 Go de mémoire GPU, même si le repository documente aussi une exécution sur GPU 40 Go via incremental prefilling, avec une latence plus élevée. En retour, vous obtenez un modèle MoE 16B qui surpasse la plupart des modèles multimodaux open source existants de taille comparable. VL2-Small sera pertinent si votre application a besoin d’une compréhension visuelle fine et fiable : par exemple extraction de données à haute précision, interprétation de graphiques complexes avec texte, etc. C’est un bon choix pour un POC avancé ou une petite mise en prod interne, à condition de pouvoir allouer une machine GPU haute mémoire. Notez que l’inférence peut devenir sensiblement plus lente selon la mémoire disponible, le nombre d’images, le dtype et la stratégie de déploiement ; des optimisations comme la quantization ou un serving dédié peuvent aider.
• DeepSeek-VL2 : la version complète (~4,5 Mds actifs, MoE 27B). C’est la variante la plus ambitieuse de la famille, présentée dans le papier comme très compétitive sur les benchmarks publics à sa sortie. Elle est cependant extrêmement exigeante : ses besoins mémoire sont supérieurs à ceux de deepseek-vl2-small et doivent être validés sur l’infrastructure visée (on n’a pas de chiffre exact, mais “even larger” que 80 Go selon les auteurs). En pratique, DeepSeek-VL2 est surtout un modèle de recherche : à moins d’avoir une infrastructure GPU multi-nœuds, il sera difficile à exploiter. Vous pourriez envisager de le faire tourner sur un serveur multi-A100 via pipeline parallelism. À réserver donc aux cas où la qualité prime sur tout – par exemple, si vous comptez analyser des données sensibles en masse et voulez maximiser chaque point de performance, ou pour repousser les limites en R&D. Pour la plupart des projets, VL2-Small suffira, sauf peut-être si vous visez un usage très spécifique où chaque détail compte (ex : répondre à des questions médicales sur imagerie + texte, où l’erreur n’est pas permise).

Quid de la génération précédente DeepSeek-VL (7B et 1.3B) ? Ces modèles restent disponibles et peuvent être plus simples à déployer que deepseek-vl2-small dans certains contextes. Si votre hardware ne permet pas VL2-Small et que Tiny ne vous suffit pas en précision, utiliser DeepSeek-VL-7B-chat peut être une alternative viable. Il offre déjà un large panel de capacités (OCR, VQA) même si sans le raffinement de VL2. En revanche, si vous pouvez faire tourner VL2-Tiny, celui-ci aura généralement des performances supérieures au VL-1.3B et comparables au VL-7B sur beaucoup de tâches courantes, grâce aux améliorations d’architecture.

En résumé : pour tester ou embarquer en local modestement → tentez VL2-Tiny. Pour un service sérieux en backend et si vous avez la VRAM → visez VL2-Small. Et réservez DeepSeek-VL2 aux expérimentations poussées. N’oublions pas aussi la question de l’échelle : un modèle plus petit sera moins coûteux si vous devez servir des centaines de requêtes par seconde (puisque vous devrez peut-être instancier plusieurs modèles en parallèle). Parfois, il vaut mieux un Tiny rapide qu’un DeepSeek-VL2 difficile à déployer. L’idéal est de prototyper sur Tiny vos cas d’usage, puis d’évaluer l’apport de Small/DeepSeek-VL2 sur un sous-ensemble de requêtes difficiles pour décider si le gain de qualité vaut le coût. Les besoins exacts en VRAM dépendent fortement de la configuration (dtype, quantization, batch size) et doivent être validés sur votre infrastructure.

Contraintes matérielles et déploiement local

Avant de se lancer, un développeur doit connaître les exigences matérielles de ces modèles et comment les déployer. Voici les points clés :

• Taille des modèles et VRAM : Comme évoqué, deepseek-vl2-small peut demander environ 80 Go de mémoire GPU dans un scénario d’inférence simple, tandis que le repository documente aussi une exécution sur GPU 40 Go via incremental prefilling, plus lente. DeepSeek-VL2-Tiny est nettement plus maniable, mais les besoins exacts en VRAM dépendent du dtype, de la quantization, du nombre d’images et de votre stack d’inférence. Pour DeepSeek-VL 7B, évitez d’annoncer un seuil fixe sans l’avoir mesuré sur votre propre environnement. Conclusion : vérifiez la mémoire de votre GPU et choisissez la variante en conséquence. Sans GPU, l’inférence reste possible mais généralement trop lente pour un usage pratique continu.
• Installation : Les modèles sont disponibles sur Hugging Face Hub (deepseek-ai/…) et le code source sur GitHub. Vous pouvez soit utiliser l’API Transformers de Hugging Face avec trust_remote_code=True (les repos contiennent les classes custom), soit cloner le repo GitHub et faire un pip install -e . pour avoir le package deepseek_vl ou deepseek_vl2. Il vous faudra Python 3.8+ et PyTorch installé avec support GPU. Les dépendances incluent transformers et torchvision (pour le chargement d’images PIL). Assurez-vous d’avoir une version de Transformers compatible (les dernières 4.x fonctionnent).
• Chargement et optimisation : Par défaut, chargez le modèle en bfloat16 ou float16 pour économiser la VRAM (les exemples utilisent model.to(torch.bfloat16)). Si vous êtes sur GPU NVIDIA standard, utilisez float16 (FP16). Vous pouvez aussi tenter les optimisations comme DeepSpeed-Inference, Accelerate, ou l’export vers ONNX/TensorRT pour accélérer les temps de réponse en production. DeepSeek-VL2 supporte le kv-caching optimisé (MLA) donc il est déjà plus efficace sur les longues sorties. N’hésitez pas à limiter max_new_tokens lors de la génération pour contrôler la latence.
• Contexte et taille d’entrée : Les modèles ont une limite de contexte d’environ 4096 tokens. Une image encodée en patchs viendra consommer une partie de ce budget. Dans DeepSeek-VL, le papier décrit un encodage visuel compact pour les images haute résolution ; dans DeepSeek-VL2, le budget visuel dépend du dynamic tiling et du nombre d’images envoyées. Avec VL2 et le tiling, une grande image 1024px peut produire quelques centaines de tokens (chaque tuile 384px produit un nombre fixe de tokens via ViT). Ça signifie que vous ne pouvez pas mettre trop d’images ou trop de texte à la fois. Par exemple, 3–4 images + une question longue pourraient approcher la limite. Tenez-en compte dans vos prompts : concentrez-vous sur l’essentiel (par ex. ne collez pas tout le texte OCR d’un doc dans la question, demandez plutôt directement ce qui vous intéresse).
• Outils d’intégration : Vous pouvez utiliser les outils classiques pour LLM : par exemple, Hugging Face propose un pipeline VisualQuestionAnswering – toutefois dans notre cas les classes étant custom, il est souvent plus simple d’utiliser directement AutoModelForCausalLM + AutoProcessor (ou la classe Processor dédiée) pour construire l’entrée. Des librairies comme LangChain commencent à supporter les LLM multimodaux : vous pourriez intégrer DeepSeek-VL2 comme un tool spécialisé vision dans un agent. DeepSeek fournit aussi un script Gradio dans le repo pour lancer une demo web locale facilement. Enfin, pour aller plus loin en production, le repository DeepSeek-VL2 recommande notamment des solutions de serving comme vLLM, SGLang ou LMDeploy.

En somme, prévoyez une bonne GPU et un peu de temps pour configurer l’environnement. Ce n’est pas aussi plug-and-play qu’une API REST, mais l’investissement en vaut la peine pour avoir une IA vision-langage complète sur votre machine.

Exemple de code 1 : inférence simple sur une image

Voyons un exemple d’inférence minimaliste avec DeepSeek-VL2 (variante Tiny, pour rester accessible). L’objectif est de charger le modèle et de lui faire décrire une image ou répondre à une question sur une image.

import torch
from transformers import AutoModelForCausalLM
from deepseek_vl2.models import DeepseekVLV2Processor
from deepseek_vl2.utils.io import load_pil_images

# Charger le processor et le modèle pré-entraîné (Tiny) depuis Hugging Face
model_path = "deepseek-ai/deepseek-vl2-tiny"

vl_chat_processor = DeepseekVLV2Processor.from_pretrained(model_path)
tokenizer = vl_chat_processor.tokenizer

vl_gpt = AutoModelForCausalLM.from_pretrained(
    model_path,
    trust_remote_code=True,
    torch_dtype=torch.bfloat16
).cuda().eval()

conversation = [
    {
        "role": "<|User|>",
        "content": "<image>\nDécris en détail ce document scanné.",
        "images": ["./exemple_facture.jpg"],
    },
    {"role": "<|Assistant|>", "content": ""},
]

pil_images = load_pil_images(conversation)
prepare_inputs = vl_chat_processor(
    conversations=conversation,
    images=pil_images,
    force_batchify=True,
    system_prompt=""
).to(vl_gpt.device)

inputs_embeds = vl_gpt.prepare_inputs_embeds(**prepare_inputs)

outputs = vl_gpt.language.generate(
    inputs_embeds=inputs_embeds,
    attention_mask=prepare_inputs.attention_mask,
    pad_token_id=tokenizer.eos_token_id,
    bos_token_id=tokenizer.bos_token_id,
    eos_token_id=tokenizer.eos_token_id,
    max_new_tokens=256,
    do_sample=False,
    use_cache=True
)

answer = tokenizer.decode(outputs[0].cpu().tolist(), skip_special_tokens=True)
print(answer)

Dans cet exemple, on utilise la classe DeepseekVLV2Processor du package officiel pour préparer l’entrée. On fournit une liste conversation qui imite un dialogue utilisateur/assistant : l’utilisateur insère un placeholder <image> dans sa question, et on associe l’image './exemple_facture.jpg' correspondante. La question ici est « Décris en détail ce document scanné. » (cela pourrait être *« Quel est le total de la facture ? », etc.). Après génération, on décode la réponse en texte.

Le modèle Tiny va sortir par exemple une description du document (dans notre test, il pourrait lister « Il s’agit d’une facture avec le logo de la société en haut, un tableau listant des articles avec leurs prix, un montant total en gras en bas… »). Avec une question plus ciblée, la réponse serait plus concise. Vous pouvez ajuster les paramètres de génération (température, etc.) via model.generate comme pour n’importe quel LLM.

(NB : Ici, le flux suit la logique du quick start officiel de DeepSeek-VL2 : préparation des entrées avec le processor, création des embeddings via prepare_inputs_embeds, puis génération via vl_gpt.language.generate(...).)

Exemple de code 2 : conversation avec plusieurs images

Pour illustrer le mode multi-image, prenons un scénario où l’utilisateur fournit deux images et pose une question les comparant. Par exemple, deux photos d’un produit avant et après un processus, et la question « Quelles différences voyez-vous entre ces deux images ? ».

conversation = [
    {
        "role": "<|User|>",
        "content": "Image 1: <image>\nImage 2: <image>\nQuelles différences voyez-vous entre ces deux images ?",
        "images": ["./avant.png", "./apres.png"],
    },
    {"role": "<|Assistant|>", "content": ""},
]

pil_images = load_pil_images(conversation)
prepare_inputs = vl_chat_processor(
    conversations=conversation,
    images=pil_images,
    force_batchify=True,
    system_prompt=""
).to(vl_gpt.device)

inputs_embeds = vl_gpt.prepare_inputs_embeds(**prepare_inputs)

outputs = vl_gpt.language.generate(
    inputs_embeds=inputs_embeds,
    attention_mask=prepare_inputs.attention_mask,
    pad_token_id=tokenizer.eos_token_id,
    bos_token_id=tokenizer.bos_token_id,
    eos_token_id=tokenizer.eos_token_id,
    max_new_tokens=200,
    do_sample=False,
    use_cache=True
)

print(tokenizer.decode(outputs[0].cpu().tolist(), skip_special_tokens=True))

Ici, la question de l’utilisateur contient deux placeholders <image> consécutifs – le modèle associera le premier à 'avant.png' et le second à 'apres.png' dans la liste. La réponse typique du modèle pourrait être : « La première image montre le produit avant l’opération : il est sale et couvert de poussière. La deuxième image le montre après : il semble nettoyé, plus brillant, sans poussière visible. ». DeepSeek-VL2 sait comparer et agréger des informations sur plusieurs images dans sa réponse.

Remarques : L’argument do_sample=False force une réponse déterministe (greedy) ce qui peut éviter des élucubrations dans ce contexte de comparaison objective. Si vous avez besoin de localisation explicite d’un objet, utilisez plutôt le schéma <|ref|> ... <|/ref|> documenté pour le grounding, plutôt qu’un simple prompt multi-image descriptif. Enfin, veillez à ne pas abuser du nombre d’images : bien que le code supporte 3+ images, les performances peuvent chuter (et le processor passera alors en mode sans tiling au-delà de 2 images).

Trois mini-expériences reproductibles

Passons à des scénarios concrets que vous pouvez tester vous-même pour évaluer DeepSeek-VL/VL2. Ces expériences ne nécessitent pas de fine-tuning, juste d’inférer le modèle sur vos propres images avec des requêtes bien choisies.

1. Facture scannée (OCR) – But : vérifier que le modèle extrait correctement des informations d’une facture. Scénario : Prenez une photo ou scan d’une facture (par ex. en PDF converti en image). Posez au modèle des questions ciblées, par exemple « Quel est le numéro de facture et le total TTC ? ». Résultat attendu : Le modèle devrait restituer le numéro (ex : FA-2026-00123) et le montant total (ex : 1 234,00 € TTC), éventuellement en phrase complète. Vous pouvez comparer avec la vérité terrain de la facture. Attendez-vous à ce qu’il reproduise les chiffres fidèlement s’ils sont bien lisibles. S’il y a des champs libellés (TVA, adresse client), vous pouvez aussi demander « Qui est l’expéditeur de cette facture ? » etc. L’intérêt est de voir que le modèle ne se contente pas d’un OCR brut mais peut interpréter le document – par exemple il comprendra qu’un gros nombre en bas correspond au total si la question porte là-dessus. Sur une facture simple et lisible, VL2-Tiny peut, dans ce type de scénario, restituer le numéro et le montant total avec une réponse en langage naturel. Par exemple, il peut répondre avec une phrase du type : « Le numéro de facture est INV-10045 et le montant total TTC est 259,80 € » si les informations sont clairement visibles. En cas d’erreur, essayez de rephraser la question (le modèle peut parfois confondre HT/TTC si on n’est pas clair, ou halluciner une donnée manquante – c’est rare mais possible).
2. Graphique de données – But : voir comment le modèle analyse un graphique ou tableau visuel. Scénario : Fournissez-lui une image de graphique (par ex. un diagramme linéaire des ventes mensuelles, ou un camembert de répartition). Posez la question « Quelle tendance ce graphique montre-t-il ? » ou « Que représente ce graphique ? ». Résultat attendu : Le modèle devrait répondre avec une description de la tendance (ex : « Le graphique montre une augmentation régulière des ventes de janvier à juin, avec un pic en juin. ») ainsi que l’interprétation contextuelle si possible (ex : « Cela suggère une croissance soutenue du chiffre d’affaires sur le premier semestre. »). S’il s’agit d’un graphique à barres comparant des catégories, il pourrait dire quelle catégorie est la plus haute, etc. Sur un tableau de chiffres en image, une question possible est « Quel est le taux de croissance en 2025 ? » et le modèle doit alors trouver la cellule correspondante. Ces cas testent la capacité de lecture combinée texte+graphique. DeepSeek-VL2 a été renforcé sur ces tâches (données de ChartQA, etc.), donc il est à l’aise pour décrire des graphiques en langue naturelle. Dans ce type de scénario, il peut résumer un graphique et identifier les tendances principales.
3. Capture d’écran d’application – But : évaluer la compréhension d’une interface utilisateur. Scénario : Prenez la capture d’un écran d’application web ou mobile (par ex. la page d’accueil d’un dashboard analytics, ou l’écran d’un formulaire paramètre). Demandez « Que permet de faire cette interface ? » ou « Quels sont les éléments principaux affichés ? ». Résultat attendu : Le modèle devrait reconnaître les composants UI et en déduire la fonction générale. Par exemple, pour un dashboard, il peut répondre « On voit un menu à gauche avec les sections Dashboard, Utilisateurs, Paramètres… L’interface semble permettre de visualiser des statistiques de ventes (graphique principal) et de gérer des utilisateurs (icône de profil en haut). ». Si vous demandez « Où se trouve le bouton d’exportation ? », il peut répondre « En haut à droite de l’écran, il y a un bouton “Exporter”. » (s’il le voit effectivement). Ces tests montrent comment l’IA comprend le but d’une page et la décrit comme le ferait un humain. DeepSeek-VL2 mentionne explicitement la perception des interfaces GUI parmi ses compétences, et le modèle peut par exemple identifier certains boutons d’après leur icône (disquette pour « Save », etc.). Gardez à l’esprit qu’il n’a pas de base de connaissances sur chaque logiciel : il se fie juste à l’image. Donc s’il y a du texte sur l’UI, il peut le lire (grâce à l’OCR) et s’en servir pour sa réponse. En revanche, s’il voit un symbole inconnu, il devinera peut-être mal sa fonction. Cela reste un outil formidable pour documenter une UI automatiquement ou créer un assistant guidant l’utilisateur dans une appli (« Cliquez sur le menu Profil en haut pour accéder à vos informations. » – ce genre de conseil est générable via ce modèle).

Ces expériences sont un bon moyen de cerner les forces du modèle dans des situations réelles. N’hésitez pas à en essayer d’autres (ex : « Comprendre une meme humoristique », « Lire un problème de maths écrit à la main » si vous avez de telles images, etc.). Vous verrez que dans la plupart des cas, le modèle fournit des réponses pertinentes en langage naturel, ce qui évite d’avoir à post-traiter de l’OCR brut ou des données purement visuelles. Vous obtenez directement une interprétation de l’image.

Limites honnêtes

Aucun modèle n’est parfait, et DeepSeek-VL/VL2 ont aussi leurs limites qu’il vaut mieux connaître à l’avance :

• Besoins en calcul et latence : Comme souligné, ces modèles sont très lourds. Sans GPU adéquat, l’inférence sera extrêmement lente. Même avec une bonne GPU, générer des réponses de plusieurs centaines de tokens peut prendre plusieurs secondes (moins rapide qu’un modèle purement textuel du même gabarit, car l’encodage visuel ajoute un surcoût). En l’état, une API web temps réel à grande échelle avec DeepSeek-VL2 serait coûteuse. Il faut envisager des optimisations ou accepter une latence notable selon la taille du modèle, le hardware et les paramètres d’inférence. L’inférence batchée est possible (traiter plusieurs images en parallèle) mais limité par la VRAM. En production, on pourrait mettre en place un cache des résultats pour les images identiques ou recourir à un pipeline mixte (ex : OCR classique puis question à un LLM) sur certaines requêtes pour accélérer.
• Mémoire et déploiement : Déployer DeepSeek-VL2 en production est un défi (multi-GPU obligé). Même VL2-Small nécessite du matériel peu courant (A100 80Go ou équivalent). Cela peut freiner son utilisation en entreprise si on n’a pas ces GPU. Des initiatives comme les poids quantifiés (4-bit, 8-bit) peuvent aider à réduire l’empreinte à ~50% avec impact minimal sur la qualité, c’est à considérer. De plus, charger le modèle consomme du temps et de la mémoire : veillez à ne charger qu’une fois et à réutiliser l’instance (ne pas recharger à chaque requête !). Enfin, notez que la consommation CPU/RAM n’est pas triviale non plus : transformer une image en tensor et tokeniser peut prendre quelques centaines de ms sur CPU.
• Réponses non structurées : DeepSeek-VL/VL2, comme tous les LLM multimodaux actuels, produit du texte libre en sortie. Pour certaines applications, c’est un inconvénient : par exemple, si on veut extraire 5 champs précis d’un document, il faudra peut-être parser la réponse texte de l’IA (ou orienter fortement le prompt pour qu’elle réponde sous forme de liste JSON, ce qui est possible mais pas garanti). Idem pour le grounding : obtenir <|det|>[[x,y,x2,y2]] est utile mais il faut ensuite convertir ce string en objets BoundingBox. Contrairement à un OCR traditionnel qui pourrait vous donner directement un format structuré (hOCR, ALTO XML…), ici il y a une étape d’interprétation de la réponse IA à prévoir. Cela ajoute un risque d’erreur si le modèle s’exprime de façon inattendue. Il faut donc tester sur suffisamment d’exemples et éventuellement fixer un format de sortie avec un prompt approprié (par ex. « Réponds par les chiffres uniquement » pour avoir juste un montant). Même avec ça, le modèle peut dévier ; ça reste de la génération libre.
• Hallucinations et erreurs : Bien que globalement fiables sur des questions factuelles liées à l’image, ces modèles peuvent parfois halluciner des éléments non présents, surtout si le prompt les y encourage. Par exemple, si on demande « Que dit la troisième étape du mode d’emploi sur l’image ? » et qu’en réalité l’image n’a que deux étapes, le modèle pourrait inventer une “troisième étape” plausible. Il faut donc, en tant que développeur, mettre en place des garde-fous selon l’importance : validation croisée avec un OCR brut pour vérifier que le texte renvoyé existait bien, ou informer l’utilisateur que la réponse peut contenir des erreurs. De même, sur l’OCR de textes très petits ou flous, le modèle peut mal lire et pourtant répondre avec assurance. Sur un texte très petit ou mal scanné, le modèle peut restituer certains caractères de manière erronée sans forcément signaler d’incertitude. La prudence est de mise pour les cas critiques (ex : lecture de posologie sur une ordonnance ; mieux vaut vérifier deux fois).
• Localisation approximative : Concernant le visual grounding, il faut noter que la précision des coordonnées dépend de la qualité de l’image et de la description. Le modèle n’a pas de vision géométrique fine : les boxes qu’il donne englobent généralement l’objet, mais pas toujours parfaitement serrées. Pour un usage comme l’annotation automatique, cela peut nécessiter un post-traitement (par ex. recadrer un peu la box via un algorithme d’ajustement, ou passer ensuite l’image recadrée dans un détecteur spécialisé pour affiner). Par ailleurs, s’il y a plusieurs objets similaires et qu’on demande « montre-moi le chat dans l’image » alors qu’il y en a deux, le modèle choisira arbitrairement l’un des chats pour la box. Il ne gère pas, en une seule requête, de renvoyer toutes les instances sauf si on lui demande explicitement de lister tous les objets. Bref, ce n’est pas un panacée pour le detection multi-objets exhaustive, mais c’est suffisant pour des besoins ponctuels ou interactifs (où l’utilisateur peut préciser au besoin).
• Maintenance et mise à jour : DeepSeek-VL2 est un projet open source, donc les poids sont figés à une date (fin 2024). Si votre domaine évolue (nouveau jargon, nouveaux modèles de document en 2025+), le modèle ne les connaîtra pas forcément. Par exemple, si un nouveau format de QR code apparaît, il ne saura pas le lire. Contrairement à une API cloud où les modèles sont régulièrement améliorés, ici vous aurez la même version jusqu’à ce que vous-même décidiez de l’affiner ou qu’une communauté le fasse. Il est possible de fine-tuner ces modèles sur vos données (en respectant la licence), mais c’est non trivial (taille oblige). Gardez aussi en tête que peu de ressources existent sur le debug ou support communautaire par rapport à des outils plus répandus ; en cas de bug dans le code, il faudra souvent fouiller GitHub Issues.

En somme, transparence avec les utilisateurs finaux et validation technique sont importantes. Utiliser DeepSeek-VL/VL2 vous affranchit des limites des API externes, mais cela vous rend responsable de bien configurer et vérifier ce que l’IA sort. Mieux vaut être au courant des pièges courants (par exemple, demander la sortie en anglais vs français : le modèle aura tendance à répondre dans la langue de la question, mais s’il a vu peu de français pendant son tuning, ses réponses en français pourraient être un peu moins fluides). Nous recommandons de tester largement sur vos cas d’utilisation spécifiques, et éventuellement de combiner plusieurs approches (ex : utiliser VL2 pour la compréhension globale et un OCR classique pour les très petits textes, puis faire le rapprochement entre les deux).

Recommandations : quand utiliser VL/VL2 et quand préférer autre chose

Quand utiliser DeepSeek-VL/VL2 : Si votre projet implique une composante visuelle complexe qui gagne à être traitée de manière contextuelle et flexible, ces modèles sont tout indiqués. Par exemple : extraire automatiquement du sens depuis des documents hétérogènes (mélange de texte et de schémas), construire un chatbot capable de répondre sur des images fournies par l’utilisateur, générer des rapports en langage naturel à partir de visualisations, etc. Dès que vous avez besoin d’enchaîner de la vision et du langage de façon fluide, un modèle comme VL2 brille. Il excelle pour les prototypes où vous voulez rapidement tester une idée multimodale sans entraîner de modèles spécialisés pour chaque tâche. Autre atout : si vos données sont sensibles ou privées, héberger en interne un modèle open source comme DeepSeek-VL2 évite d’envoyer des images sur des API tierces. Vous gardez le contrôle des données. Enfin, si vous envisagez des usages multi-tâches (un même modèle qui fait OCR, description, Q&R, etc.), c’est plus simple d’avoir une seule IA généraliste comme VL/VL2 que de combiner plusieurs algorithmes (ex : Tesseract + règles + modèle de QA… tout ça peut être remplacé par une seule requête à VL2).

Quand préférer autre chose : À l’inverse, si votre besoin est très ciblé et circonscrit, un outil spécialisé fera souvent mieux l’affaire avec moins de ressources. Par exemple, pour du OCR pur sur des documents standardisés en grande quantité, une solution OCR dédiée (ABBYY, Tesseract, Google Vision API…) sera plus facile à mettre en place et plus optimisée. En 2026, des modèles spécialisés comme DeepSeek-OCR et DeepSeek-OCR-2 peuvent aussi être plus adaptés que VL/VL2 pour des pipelines OCR intensifs, ces derniers restant plus polyvalents pour la compréhension multimodale. De même, pour la détection d’objets multiples dans des images (par ex. compter le nombre de voitures dans des milliers d’images), un détecteur entraîné (YOLO, Faster R-CNN) sera plus rapide et précis, là où un LLM multimodal serait lent et pas forcément exhaustif. Si votre application ne requiert pas de raisonnement linguistique et qu’une simple extraction suffit, les méthodes traditionnelles ou plus légères suffisent souvent. Par exemple, extraire du texte imprimé d’un document — un OCR classique + un petit script pour trouver le total peut suffire et sera bien plus rapide que charger un grand modèle multimodal. Il faut voir DeepSeek-VL/VL2 comme un couteau suisse multimodal : utile pour des tâches variées ou mal définies, et pour garder de la flexibilité en posant des questions libres sur l’image. Mais si vous avez une tâche unique, répétitive et stable, un outil taillé sur mesure sera généralement plus efficient.

Par ailleurs, n’oubliez pas la question de la langue : si vous avez besoin d’une compréhension fine dans une langue très peu représentée dans les données d’entraînement (par ex. lire du texte en arabe manuscrit ou interpréter un document juridique en français avec jargon pointu), DeepSeek-VL(2) pourrait être moins performant qu’un modèle entraîné spécifiquement sur cette langue ou ces documents. On pourrait alors combiner un OCR multi-langue externe pour la partie texte, et utiliser le LLM juste pour faire le raisonnement sur la traduction du texte. Ce genre d’hybride est parfois plus judicieux.

Enfin, pour des besoins de génération d’images (par exemple créer des visuels à partir de texte), DeepSeek-VL/VL2 ne sait pas le faire – ce sont uniquement des modèles d’analyse d’images. Si c’est la création qui vous intéresse, tournez-vous plutôt vers d’autres modèles de la famille (DeepSeek a par exemple un modèle nommé Janus pour image→texte et texte→image) ou des générateurs type Stable Diffusion, MidJourney, etc.

En résumé : utilisez VL/VL2 pour la polyvalence multimodale et le compréhension contextuelle, mais pour des tâches verticales ultra-optimisées, gardez en tête les solutions spécialisées. Parfois, la bonne solution combine les deux : par exemple, un pipeline d’analyse documentaire pourrait d’abord passer l’image dans un OCR rapide pour extraire le texte brut, puis fournir ce texte + l’image à DeepSeek-VL2 pour qu’il réponde à une question complexe en s’appuyant sur le texte et la mise en page visuelle. À vous d’évaluer le rapport bénéfice/complexité selon votre cas d’usage.

Conclusion : DeepSeek-VL(2) dans votre projet

DeepSeek-VL et VL2 démontrent qu’un modèle open source peut offrir des capacités vision-langage avancées comparables aux solutions propriétaires. Pour un développeur, ils représentent une opportunité de créer de nouvelles expériences utilisateurs : des assistants capables de voir et lire, des analytiques augmentés, de l’automatisation documentaire intelligente, etc. Ce guide vous a montré un aperçu de quoi ces modèles peuvent faire (et ne pas faire) en 2026, et comment commencer à les utiliser concrètement.

En adoptant DeepSeek-VL/VL2, vous gagnez en indépendance vis-à-vis des APIs fermées, mais vous prenez en charge la partie déploiement. Avec les bonnes ressources (GPU et optimisation logicielle), cela en vaut la peine pour des projets nécessitant de garder la donnée en interne ou de pousser les capacités de l’IA plus loin que les services standard. N’hésitez pas à vous appuyer sur les exemples de code fournis et à reproduire les mini-expériences proposées pour vous faire la main. Ensuite, il vous sera plus aisé de construire votre pipeline sur mesure : par exemple en intégrant DeepSeek-VL2 dans votre application via l’API Transformers, ou en l’associant à vos outils existants (voir notre guide How to Build Your Own App with DeepSeek pour une approche générale).

À l’avenir, on peut anticiper que DeepSeek (la société) sortira peut-être une version API vision ou de nouveaux modèles multimodaux encore plus efficaces. En attendant, DeepSeek-VL2 reste une option open source très compétitive pour de nombreux cas d’usage multimodaux en mode self-hosted. Que vous soyez full-stack dev curieux de tester un chatbot visuel sur votre site, data scientist cherchant à extraire des insights de documents scannés, ou CTO voulant évaluer une solution self-hosted pour de l’OCR intelligent, ces modèles méritent votre attention.

En conclusion, DeepSeek-VL et VL2 offrent aux développeurs francophones une base open source solide pour explorer l’IA multimodale. En revanche, le déploiement demande des ressources adaptées, et le comportement multilingue — notamment en français — doit être validé sur vos propres données. Avec ce guide, vous disposez des bases pour les explorer et les évaluer dans votre contexte. À vous de jouer : essayez-les sur vos propres images, ajustez les prompts, et voyez comment ils peuvent transformer la façon dont votre application comprend le monde visuel. Bonne implémentation !

(Pour aller plus loin, consultez également notre page sur les outils pour développeurs compatibles avec DeepSeek et le focus sur le modèle texte DeepSeek V3.2 si vous combinez vision et conversation.)

FAQ

Sources officielles

• GitHub – DeepSeek-VL (2024) – Repository officiel du modèle DeepSeek-VL (1.3B & 7B) avec code, instructions et paper : DeepSeek-VL: Towards Real-World Vision-Language Understanding.
• GitHub – DeepSeek-VL2 (2024) – Repository officiel de la série DeepSeek-VL2 (DeepSeek-VL2-Tiny, DeepSeek-VL2-Small, DeepSeek-VL2) et paper associé : DeepSeek-VL2: Mixture-of-Experts Vision-Language Models for Advanced Multimodal Understanding.
• ArXiv – DeepSeek-VL (mars 2024) – Article de recherche détaillant la conception de DeepSeek-VL, son entraînement (données web, OCR, etc.) et ses performances sur divers benchmarks.
• ArXiv – DeepSeek-VL2 (déc. 2024) – Article de recherche pour DeepSeek-VL2, décrivant les améliorations (dynamic tiling, MoE, MLA) et montrant les gains sur des tasks comme DocVQA, OCRBench, RefCOCO….
• Hugging Face – deepseek-ai – Page du compte officiel DeepSeek-AI sur Hugging Face contenant les modèles à télécharger (ex : deepseek-ai/deepseek-vl2-tiny, deepseek-ai/deepseek-vl-7b-chat…) . On y trouve souvent le model card avec des exemples.
• DeepSeek API Docs – Documentation officielle de l’API DeepSeek (section Models & Pricing) confirmant que seuls les modèles texte (DeepSeek V3.2) sont exposés via l’API en 2026.
• GitHub – DeepSeek-OCR (2025) – Repository officiel d’un modèle spécialisé OCR / document parsing utile pour comparer une approche dédiée face à VL/VL2 sur les flux documentaires.
• GitHub – DeepSeek-OCR-2 (2026) – Repository officiel de la génération suivante DeepSeek-OCR-2, à considérer lorsque le besoin principal est l’OCR ou l’extraction documentaire spécialisée.