DeepSeek V4 Flash Vision : qu’est-ce que c’est et comment l’utiliser

TL;DR

DeepSeek-V4.1-Flash est le modèle Flash multimodal actuellement proposé par l’API DeepSeek sous l’ID de modèle deepseek-flash. Il prend en charge un contexte de 1M de tokens, jusqu’à 384K de sortie et l’entrée d’images ; selon le guide Vision actuel, chaque image utilise au plus 1024 tokens après redimensionnement automatique.

Sa meilleure position demeure la vision orientée agents : inspection de captures d’écran, graphiques, interfaces et documents basés sur des images avant de poursuivre avec du code ou des outils. Les résultats de benchmark plus loin dans cet article appartiennent au lancement Vision-Exp désormais retiré et doivent être considérés comme des preuves historiques rapportées par le fournisseur, non comme un benchmark récent de DeepSeek-V4.1-Flash.

CometAPI conserve actuellement deepseek-v4-flash-vision-exp comme ID de modèle dans son catalogue, tandis que l’API directe de DeepSeek recommande deepseek-flash et traite la requête avec DeepSeek-V4.1-Flash. Commencez par une requête texte+image, puis évaluez la route exacte sur vos propres captures d’écran et tâches visuelles.

Points clés

• Route actuelle : DeepSeek-V4.1-Flash est le modèle Flash multimodal actif. Le nom retiré deepseek-v4-flash-vision-exp n’est accepté que comme alias de compatibilité sur l’API DeepSeek.
• Grand espace de travail texte : contexte de 1M de tokens et jusqu’à 384K de sortie pour des documents longs, des dépôts de code, des historiques d’outils et des images dans une même conversation.
• Comptabilisation d’images actuelle : DeepSeek redimensionne automatiquement chaque image et la plafonne à 1024 tokens d’entrée. Les images en dessous d’environ 544×544 pixels au total sont agrandies ; les plus grandes sont redimensionnées vers environ 1300×1300 pixels au total.
• Vision orientée agents : la comparaison officielle met l’accent sur les workflows de captures d’écran, graphiques, navigateur, codage et outils visuels plutôt que sur la génération d’images.
• Large prise en charge d’interfaces : DeepSeek documente les interfaces d’API prises en charge : Chat Completions, Messages compatibles Anthropic et Responses API. Les exemples CometAPI ci-dessous utilisent Chat Completions.
• Prudence en production : alias de routes, redimensionnement automatique des images et résultats de benchmark sensibles au harnais rendent indispensable un test spécifique à la charge.

Qu’est-ce que DeepSeek-V4-Flash-Vision ?

La documentation actuelle de DeepSeek identifie deepseek-flash comme DeepSeek-V4.1-Flash, avec une entrée texte+image et une sortie texte. Le modèle Vision-Exp plus ancien a été retiré ; ses noms de modèles hérités sont des alias de compatibilité acheminés vers le modèle Flash actuel.

Le cas d’usage visé est l’agent multimodal. Un agent visuel peut inspecter une application rendue, identifier un bouton ou un défaut de mise en page, raisonner sur l’action suivante, appeler un outil, puis examiner la capture d’écran suivante. Le même schéma s’applique à l’analyse de graphiques, à l’assurance qualité visuelle, à l’extraction de documents et aux agents de navigation et de codage qui doivent comparer une référence de conception avec une page rendue.

Note de nommage : pour l’API directe de DeepSeek, utilisez deepseek-flash ; il correspond actuellement à DeepSeek-V4.1-Flash. Les noms hérités deepseek-v4-flash et deepseek-v4-flash-vision-exp sont encore acceptés par DeepSeek, mais les modèles correspondants sont retirés et les requêtes sont servies par DeepSeek-V4.1-Flash. CometAPI continue d’exposer deepseek-v4-flash-vision-exp comme sa propre route de catalogue.

Caractéristiques techniques

Les champs d’architecture ci-dessus proviennent de la configuration officielle. L’interface du dépôt liste un checkpoint à 305B paramètres, mais DeepSeek ne publie pas séparément un nombre de paramètres activés pour le modèle vision complet. Il est plus sûr de déclarer la valeur du dépôt que de supposer que le V4-Flash texte seul conserve inchangé le nombre de paramètres activés après ajout de la pile visuelle.

Fonctionnement de l’architecture héritée de DeepSeek-V4-Flash-Vision-Exp

Backbone texte V4-Flash

Le côté langage conserve les thèmes de conception V4 qui rendent réalisable le travail d’agent à long contexte. Le dépôt officiel documente les composants d’architecture V4 : routage MoE parcimonieux, attention DFlash, Hyper-Connections et DSpark. Cela rend la version plus inspectable qu’un modèle uniquement API, même si le déploiement local reste exigeant à cette échelle.

Encodeur et aligneur visuels

Pour le checkpoint Vision-Exp retiré, la configuration publiée utilisait un encodeur visuel à 32 couches, une taille de patch de 14, une largeur visuelle de 1,024, 16 têtes d’attention visuelle et une représentation d’image de 384 tokens. Ces détails décrivent le checkpoint historique et ne doivent pas être supposés documenter la pile de service actuelle de DeepSeek-V4.1-Flash.

Limite actuelle de 1024 tokens par image

Les règles de tokenisation vision actuelles de DeepSeek mettent à l’échelle les images en dessous d’environ 544×544 pixels totaux à la hausse et les plus grandes à la baisse tout en préservant le ratio d’aspect. Les grandes entrées sont redimensionnées vers une aire de pixels proche de 1300×1300, produisant un plafond de 1024 tokens par image. Une image 2000×2000 et une image 5000×5000 consomment donc le même nombre de tokens d’image après redimensionnement.

Implication pratique : recadrez la région contenant les petites étiquettes, le code ou les contrôles UI avant d’envoyer l’image. Une résolution source plus élevée ne contourne pas le plafond actuel de 1024 tokens.

Performances de benchmark de Vision-Exp (héritées)

L’évaluation officielle compare le modèle vision avec DeepSeek-V4-Flash-0731 et Claude Opus 4.8 sur des tâches d’agents texte et multimodaux. Le modèle vision s’améliore généralement par rapport au modèle Flash texte seul tout en restant compétitif, mais pas systématiquement supérieur, au concurrent axé sur les capacités.

Comparaison officielle de benchmarks pour les évaluations d’agents texte et multimodaux. Source : publication officielle de DeepSeek

* Dans ApexBench et Agents' Last Exam, le V4-Flash texte seul a ignoré les éléments multimodaux de l’entrée. DeepSeek a évalué ses tâches d’agent texte avec DeepSeek Harness en mode minimal, effort de raisonnement maximal, température 1.0 et top_p 0.95.

Note benchmark : ce sont des résultats de lancement rapportés par DeepSeek, non une reproduction indépendante. Les scores d’agents sont particulièrement sensibles au harnais, aux définitions d’outils, au budget de tokens et à la politique de retry ; ils doivent donc être traités comme des indications.

Interprétation des résultats de benchmark

Le résultat le plus net est l’amélioration par rapport au V4-Flash texte seul lorsque la preuve visuelle compte. ApexBench passe de 26.2 à 36.5, et le modèle vision ajoute des résultats compétitifs à Chartography et ZeroBench que le modèle texte seul ne rapporte pas. Le modèle s’améliore aussi sur plusieurs tâches d’agent texte, notamment Terminal Bench 2.1, NL2Repo, DeepSWE, Toolathlon-Verified et DSBench-Hard, bien que Cybergym soit légèrement inférieur.

Face à Opus 4.8, le résultat est mitigé. Vision-Exp est supérieur sur DeepSWE, Agents' Last Exam et ZeroBench dans ce tableau, tandis que le modèle concurrent est supérieur sur Terminal Bench, NL2Repo, Cybergym, Toolathlon, DSBench-Hard, ApexBench et Chartography. La revendication de benchmark multimodal de DeepSeek est donc directionnelle plutôt qu’une preuve d’équivalence générale sur toutes les dimensions de vision, de raisonnement ou de fiabilité.

DeepSeek-V4.1-Flash vs DeepSeek-V4-Flash-Vision-Exp vs Claude Opus 4.8 vs Gemini 3.7 Flash

Choisissez Vision-Exp lorsque la perception d’image doit être ajoutée à une boucle d’agent peu coûteuse. Choisissez V4 Flash lorsque chaque entrée est textuelle et que le débit importe plus que la compréhension visuelle. Opus 4.8 reste l’option axée sur les capacités dans la propre comparaison de DeepSeek, tandis que Gemini 3.7 Flash est l’alternative multimodale plus large lorsque la vidéo, l’audio, les PDFs et les outils Google comptent.

Que peut faire DeepSeek-V4-Flash-Vision ?

• Screenshot-to-code et revue d’UI : comparer une page rendue avec une conception, identifier des problèmes de mise en page ou d’accessibilité et générer des conseils de mise en œuvre.
• Agents de navigation visuels : utiliser des captures comme observations lorsque le DOM ou les données d’accessibilité sont incomplètes, puis sélectionner l’action d’outil suivante.
• Analyse de graphiques et tableaux de bord : expliquer les tendances, identifier les anomalies et relier les métriques visibles à un flux de travail texte ou outil plus large.
• Compréhension de documents basés sur des images : extraire des informations de formulaires scannés, diagrammes, diapositives, tableaux et captures avant un traitement structuré.
• Agents de codage multimodaux : combiner code source, captures de bugs, états d’IDE et rendus dans une seule boucle de débogage.
• Assurance qualité visuelle : comparer des captures produit entre appareils, détecter des éléments manquants et générer des rapports de défauts structurés.
• Comparaison multi-images : évaluer une séquence de captures ou des designs alternatifs dans une seule requête, sous réserve des limites de taille et de nombre d’images.

Exemple officiel d’agent visuel issu de la page de lancement de DeepSeek (GIF animé dans Word). Source : publication officielle de DeepSeek

Tarification et disponibilité

DeepSeek facture les tokens d’image avec les tokens d’entrée texte. Son tableau de prix officiel utilise des tarifs “peak” et “off-peak”, tandis que la page modèle CometAPI publie un prix de route unique actuel. Les chiffres ne doivent pas être réduits à un prix générique, car la route la moins chère change selon la fenêtre horaire de DeepSeek.

Tous les prix sont en USD par 1M de tokens. Les tarifs Flash actuels de DeepSeek sont de $0.003/$0.15/$0.60 en off-peak et $0.006/$0.30/$1.20 en peak pour entrée cache-hit, entrée cache-miss et sortie respectivement. CometAPI liste actuellement $0.352 par 1M de tokens d’entrée et environ $1.06 par 1M de tokens de sortie pour sa route de compatibilité. Les images utilisent au plus 1024 tokens d’entrée chacune sur l’API actuelle de DeepSeek ; vérifiez toujours les prix de route en direct avant un usage en production.

Note tarification : les prix des modèles peuvent changer. Maintenez les chiffres liés aux pages de prix en direct et revérifiez-les juste avant la publication ou le déploiement en production.

Comment utiliser DeepSeek-V4-Flash-Vision avec CometAPI

CometAPI liste actuellement deepseek-v4-flash-vision-exp via son endpoint compatible OpenAI /v1/chat/completions, donc les exemples CometAPI conservent cet ID de catalogue. Pour l’API directe de DeepSeek, utilisez deepseek-flash à la place.

Étape 1 : Créer une clé API

1. Créez ou connectez-vous à un compte CometAPI.
2. Ouvrez la console des tokens API et créez une clé.
3. Stockez-la dans la variable d’environnement COMETAPI_KEY. Ne placez jamais une clé de production dans du code côté client ni ne la validez dans le contrôle de version.

export COMETAPI_KEY="your-cometapi-key"

Étape 2 : Envoyer une image Base64 avec cURL

Base64 est utile pour les fichiers locaux et les tâches côté serveur où l’image est déjà en mémoire. Remplacez l’espace réservé par les octets d’image encodés, sans ajouter d’espaces ni de sauts de ligne.

curl https://api.cometapi.com/v1/chat/completions \
  -H "Authorization: Bearer $COMETAPI_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek-v4-flash-vision-exp",
    "messages": [
      {
        "role": "user",
        "content": [
          {
            "type": "text",
            "text": "Read this dashboard and return the three most important findings."
          },
          {
            "type": "image_url",
            "image_url": {
              "url": "data:image/png;base64;<BASE64_DATA>"
            }
          }
        ]
      }
    ],
    "max_tokens": 1200
  }'

Étape 3 : Analyser une image locale avec Python

Le SDK Python OpenAI peut appeler CometAPI en changeant l’URL de base. Utilisez extra_body pour les contrôles de “thinking” spécifiques à DeepSeek lorsque votre SDK ne les expose pas directement.

import base64
import os

from openai import OpenAI

client = OpenAI(
    api_key=os.environ["COMETAPI_KEY"],
    base_url="https://api.cometapi.com/v1",
)

with open("dashboard.png", "rb") as image_file:
    encoded = base64.b64encode(image_file.read()).decode("utf-8")

response = client.chat.completions.create(
    model="deepseek-v4-flash-vision-exp",
    messages=[
        {
            "role": "user",
            "content": [
                {
                    "type": "text",
                    "text": (
                        "Analyze the chart. Return JSON with keys: trend, "
                        "anomalies, evidence, and confidence."
                    ),
                },
                {
                    "type": "image_url",
                    "image_url": {
                        "url": f"data:image/png;base64,{encoded}"
                    },
                },
            ],
        }
    ],
    max_tokens=1500,
    extra_body={
        "thinking": {"type": "enabled"},
        "reasoning_effort": "high",
    },
)

print(response.choices[0].message.content)

Étape 4 : Utiliser une URL d’image publique avec JavaScript

Une URL d’image maintient la requête JSON compacte, mais l’URL doit être publiquement accessible par le modèle amont. Évitez les liens temporaires, privés ou protégés par authentification, sauf si votre application convertit d’abord l’image en Base64.

const response = await fetch(
  "https://api.cometapi.com/v1/chat/completions",
  {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.COMETAPI_KEY}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      model: "deepseek-v4-flash-vision-exp",
      messages: [
        {
          role: "user",
          content: [
            {
              type: "text",
              text: "Identify the UI issue and propose a concrete CSS fix.",
            },
            {
              type: "image_url",
              image_url: {
                url: "https://example.com/screenshot.png",
              },
            },
          ],
        },
      ],
      max_tokens: 1200,
    }),
  }
);

if (!response.ok) {
  throw new Error(`CometAPI request failed: ${response.status}`);
}

const data = await response.json();
console.log(data.choices[0].message.content);

Étape 5 : Envoyer plusieurs images

Placez plusieurs blocs image_url dans le même message utilisateur et indiquez au modèle comment les étiqueter. Des étiquettes explicites réduisent les références croisées accidentelles entre images.

{
  "model": "deepseek-v4-flash-vision-exp",
  "messages": [
    {
      "role": "user",
      "content": [
        {
          "type": "text",
          "text": "Compare Image A and Image B. List every visible regression."
        },
        {
          "type": "image_url",
          "image_url": {"url": "https://example.com/image-a.png"}
        },
        {
          "type": "image_url",
          "image_url": {"url": "https://example.com/image-b.png"}
        }
      ]
    }
  ],
  "max_tokens": 1800
}

Méthodes d’entrée et limites

L’API officielle de DeepSeek prend également en charge des références d’images réutilisables via file_id par son Files API. Le chemin rapide CometAPI documenté ici utilise des blocs image_url avec une URL publique ou une URL de données Base64. Vérifiez la prise en charge de l’upload et du passage de file_id propres au fournisseur avant de compter sur ce workflow via une route d’agrégation.

Comment concevoir des prompts efficaces

Un prompt d’agent visuel fiable doit indiquer ce qu’est l’image, quelles preuves inspecter, quelle action entreprendre et quel contrat de sortie respecter. Des prompts vagues comme describe this image laissent trop de liberté et rendent les résultats plus difficiles à valider.

• Contexte : identifiez la capture, le graphique, le document ou l’interface et son rôle dans le workflow.
• Tâche : précisez la décision, le diagnostic, la comparaison ou l’extraction qui compte.
• Preuves : exigez des preuves visibles, des étiquettes, des coordonnées, des valeurs ou du texte d’UI cité.
• Contraintes : interdisez les hypothèses non prises en charge et indiquez comment gérer les détails illisibles.
• Sortie : définissez des clés JSON, une checklist, des niveaux de sévérité ou une autre structure vérifiable par machine.

You are reviewing a web application screenshot.

Task: identify layout, accessibility, and state-consistency defects.
Evidence: cite the visible element, label, position, or color that supports each finding.
Constraints: do not infer hidden DOM state; mark unreadable text as uncertain.
Output: return JSON with arrays named critical, major, minor, and follow_up_checks.

Bonnes pratiques de production

• Recadrez avant l’envoi lorsque de petits textes ou contrôles comptent ; le plafond de tokens d’image fait que l’arrière-plan inutile consomme une résolution visuelle précieuse.
• Testez l’effort de “thinking” au lieu d’activer max pour chaque requête. Une simple OCR ou classification nécessite souvent moins de raisonnement qu’un diagnostic UI multi-étapes.
• Exigez des preuves dans chaque constat structuré. Cela facilite le rejet automatique d’allégations visuelles halluciné(e)s.
• Séparez perception et action dans une automatisation à haut risque. Laissez le modèle décrire l’état, validez-le, puis permettez à une couche d’outils contrôlée d’agir.
• Protégez les URLs d’image car une URL publique peut exposer des captures sensibles. Préférez le Base64 côté serveur pour les données privées et appliquez votre propre politique de rétention.
• Évaluez bout en bout avec la même capture, le même prompt, les mêmes outils, retries et critères de succès utilisés en production.
• Suivez les changements expérimentaux en épinglant prompts et données d’évaluation. Une endpoint -exp peut changer de comportement plus vite qu’un modèle en disponibilité générale.
• Journalisez les IDs de requête et les échecs afin de distinguer erreurs fournisseur, erreurs modèle et erreurs de parsing applicatif.

Limites

La limitation la plus importante est la transparence des routes : le nom hérit é Vision-Exp peut encore être accepté même si la requête est servie par DeepSeek-V4.1-Flash. Journalisez le fournisseur, l’ID de modèle demandé, les métadonnées de modèle renvoyées et l’ID de requête ; utilisez des portes d’évaluation explicites avant d’attribuer des actions autonomes. Les scores de lancement historiques ne remplacent pas des tests reproductibles sur la route visée.

La seconde limitation est le détail visuel. Le redimensionnement automatique et le plafond actuel de 1024 tokens par image rendent les coûts prévisibles mais peuvent toujours supprimer de petits textes, des marques fines de graphiques ou des éléments d’interface denses. Recadrez, tuiliez ou zoomez la région pertinente et préservez l’image originale pour revue humaine.

Le modèle renvoie uniquement du texte. Il peut analyser une image et proposer du code ou des actions structurées, mais il ne génère ni n’édite des images. Il accepte également les images uniquement dans les messages utilisateur, et la documentation officielle indique que du contenu image dans les messages system ou assistant renvoie une erreur 400.

Enfin, le déploiement local est lourd en infrastructure. Le dépôt officiel liste un modèle à 305B paramètres et fournit un code d’inférence de référence plutôt qu’un runtime léger clé en main. Pour la plupart des équipes, l’évaluation via API managée est le point de départ pratique.

Erreurs courantes et correctifs

FAQ

DeepSeek-V4-Flash-Vision est-il identique à DeepSeek-V4-Flash ?

Non. Vision-Exp ajoute l’entrée d’images native et un entraînement multimodal. La route Flash texte seule n’offre pas la même perception visuelle.

Quel ID de modèle dois-je utiliser ?

Utilisez deepseek-flash sur l’API directe de DeepSeek. Sur CometAPI, utilisez l’ID de catalogue deepseek-v4-flash-vision-exp tant que cette route reste disponible.

Peut-il analyser plusieurs images ?

Oui. DeepSeek documente jusqu’à 600 images par requête, sous réserve des limites de taille et de dimensions. Les limites pratiques peuvent être plus basses dans une application, car la latence et la clarté du prompt se dégradent à mesure que l’ensemble d’images grandit.

Combien de tokens une image utilise-t-elle ?

Sur l’API actuelle de DeepSeek, les images sont redimensionnées et converties en tokens avec un maximum de 1024 tokens par image. Les images multiples sont comptées indépendamment.

Prend-il en charge la génération d’images ?

Non. Il accepte du texte et des images et renvoie du texte.

Est-il prêt pour la production ?

Oui, mais seulement après une évaluation spécifique à la route. Utilisez monitoring, solutions de repli, tests d’acceptation spécifiques à la tâche et journalisation des routes modèles, car les alias hérités peuvent se résoudre à DeepSeek-V4.1-Flash.

Dois-je utiliser CometAPI ou l’API directe de DeepSeek ?

CometAPI est utile quand une seule clé, une seule couche de facturation et un changement de modèle facile importent. L’accès direct DeepSeek peut être préférable lorsque vous avez besoin de fonctionnalités spécifiques au fournisseur comme les sémantiques officielles du Files API ou la tarification off-peak. Testez les deux routes sur la même charge de travail.

Conclusion

DeepSeek-V4.1-Flash est désormais la route Flash multimodale active sur l’API de DeepSeek. Son contexte de 1M, un plafond de sortie de 384K, la prise en charge multi-interface et un plafond de 1024 tokens par image en font une option attrayante pour la compréhension de captures d’écran, l’analyse de graphiques, le codage visuel et l’automatisation de navigateur ou d’IHM. L’architecture Vision-Exp et les benchmarks de lancement dans cet article sont conservés comme contexte historique.

La décision doit rester pilotée par la charge de travail. Les preuves publiques de benchmark pour le modèle Vision-Exp retiré sont principalement rapportées par le fournisseur, les alias de routes actuels peuvent masquer le modèle qui sert la requête, et le redimensionnement d’images peut toujours limiter les tâches à détails fins. Testez la route du fournisseur exacte sur des images représentatives, mesurez le coût par tâche réussie plutôt que le prix par token seul, et gardez une solution de repli jusqu’à ce que la route prouve sa fiabilité dans votre harnais de production.