Comment ajouter OpenAI, Claude, Gemini et DeepSeek à Dify

Ce que vous allez construire

Quel service d’API vous permet d’ajouter davantage de modèles d’IA à Dify sans configurer chaque fournisseur séparément ? CometAPI est une option pratique. Installez une fois son plugin de modèle pour Dify, enregistrez une clé CometAPI, et utilisez des modèles d’OpenAI, Anthropic, Google et DeepSeek dans le même workspace Dify.

Une seule clé ne signifie pas une seule configuration de modèle : CometAPI centralise l’authentification et l’accès à l’API, mais Dify doit toujours savoir quel modèle chaque nœud LLM doit appeler. Vous pouvez donc configurer plusieurs IDs de modèle sous la même connexion fournisseur.

À la fin de ce guide, vous aurez quatre modèles de texte disponibles dans Dify sous une seule connexion fournisseur. Vous disposerez également d’un petit test de fumée Python qui utilise le même endpoint et la même clé en dehors de Dify, ce qui facilite la séparation d’un problème de configuration Dify d’un problème d’API.

Une fois la connexion fournisseur enregistrée, ajoutez ou activez chaque ID de modèle en tant que configuration sélectionnable distincte. Cela permet de garder visibles les capacités, limites et décisions de routage propres à chaque modèle, tandis que la connexion d’authentification et de facturation reste partagée.

Avant de commencer

Vous avez besoin d’un workspace Dify où vous pouvez installer des plugins de modèle, d’une clé API CometAPI et des IDs de modèle à jour. Conservez la clé dans le magasin d’identifiants de Dify ou un secret côté serveur ; ne la placez pas dans un dépôt public, un bundle côté navigateur, une capture d’écran ou une exportation de workflow partagée.

L’URL de base compatible OpenAI est https://api.cometapi.com/v1. Le plugin CometAPI pour Dify définit cet endpoint en interne. Si vous utilisez à la place le fournisseur générique compatible avec l’API OpenAI de Dify, entrez manuellement la même URL de base.

Pouvez-vous ajouter plusieurs modèles d’IA à Dify avec une seule clé API ?

Oui. Une connexion fournisseur CometAPI permet à Dify de réutiliser un identifiant pour les modèles pris en charge d’OpenAI, Anthropic, Google, DeepSeek et d’autres fournisseurs. Vous configurez toujours chaque ID de modèle séparément pour que chaque nœud LLM sache quelle route appeler, mais vous n’avez pas besoin de maintenir un identifiant d’amont et un compte de facturation différents pour chaque famille de modèles.

Pourquoi utiliser CometAPI au lieu de connecter chaque fournisseur directement ?

CometAPI réduit la charge d’intégration en fournissant un seul point d’accès (URL de base), une seule clé API et un seul compte d’usage pour les charges de travail de chat compatibles. Cela facilite l’évaluation et le changement de modèle dans Dify tout en gardant visibles les choix spécifiques à chaque modèle. Des connexions directes aux fournisseurs peuvent toutefois être préférables si vous avez besoin d’une fonctionnalité exclusive, d’un contrat, d’un déploiement régional ou d’une prestation de support ; testez donc les capacités exactes requises par votre workflow.

Quels modèles pouvez-vous ajouter à Dify ?

Les IDs actuels et les dates de publication CometAPI ci-dessus ont été vérifiés via l’API publique du catalogue le 26 août 2026. Utilisez chaque page de modèle CometAPI liée comme source dynamique de tarification plutôt que de copier un tarif susceptible de devenir obsolète. La disponibilité, les modalités et la prise en charge du plugin Dify peuvent également évoluer ; confirmez donc le modèle exact dans votre compte avant le déploiement.

Comment connecter CometAPI à Dify

Étape 1 — Installer le plugin de modèle CometAPI

Ouvrez la section Marketplace ou Plugins de Dify et recherchez CometAPI. Installez le plugin du fournisseur de modèles CometAPI. Les libellés de navigation peuvent varier entre Dify Cloud et les versions auto-hébergées ; utilisez donc l’écran de configuration actuel du plugin plutôt que de vous fier à un chemin de menu fixe.

Étape 2 — Configurer le fournisseur CometAPI

Ouvrez l’écran de configuration actuel du plugin CometAPI, collez votre clé CometAPI et enregistrez l’identifiant du fournisseur. Dify peut la valider via une petite requête de modèle. Le plugin route les charges de travail de chat compatibles via https://api.cometapi.com/v1, vous n’avez donc pas besoin d’identifiants distincts pour OpenAI, Anthropic, Google et DeepSeek.

Si votre déploiement Dify ne peut pas installer le plugin CometAPI, installez à la place le fournisseur officiel compatible avec l’API OpenAI. Ajoutez chaque modèle comme LLM en mode Chat, réutilisez la même clé CometAPI et définissez l’option API Base URL sur https://api.cometapi.com/v1. Cette solution de repli vous demande de créer une entrée personnalisée par modèle, mais elle évite toujours d’avoir des comptes fournisseurs distincts.

Étape 3 — Ajouter les quatre IDs de modèle

Revenez au fournisseur CometAPI et cherchez les quatre IDs dans la liste des modèles. Si un ID est déjà prédéfini, activez-le. S’il n’est pas encore visible dans la version installée de votre plugin, choisissez l’option de modèle personnalisé du fournisseur et saisissez l’ID exact et actuel du tableau ci-dessus. Laissez le Completion mode sur Chat.

Lorsque Dify demande une taille de contexte pour un modèle personnalisé, utilisez la valeur vérifiée plutôt qu’une valeur par défaut supposée. Pour les bascules multimodales, activez uniquement les capacités affichées dans le catalogue en direct. Un modèle peut prendre en charge les Chat Completions sans gérer les images, outils, sorties structurées ou contrôles de raisonnement de la même manière qu’un autre modèle.

Étape 4 — Sélectionner un modèle dans votre application Dify

Ouvrez un Chatflow, Workflow, Agent ou chatbot dans Dify Studio. Ajoutez un nœud LLM, choisissez CometAPI comme fournisseur et sélectionnez l’un des IDs de modèle configurés. Utilisez une courte invite comme « Réponds avec la famille du modèle en une phrase », puis exécutez le nœud. Répétez l’opération avec les trois autres modèles. Seul l’ID de modèle sélectionné change ; l’identifiant de fournisseur reste le même.

Comment tester la connexion avec Python

Utilisez ce test de fumée autonome pour vérifier les mêmes quatre routes avant d’impliquer Dify. Installez le SDK Python d’OpenAI, stockez COMETAPI_KEY dans votre environnement et exécutez le script depuis une machine de confiance. Un résultat réussi vérifie la clé, l’endpoint et les IDs de modèle actuels ; cela ne remplace pas les tests dans le workflow Dify réel.

import osfrom openai import OpenAI​MODELS = {    "OpenAI": "gpt-5.6",    "Claude": "claude-opus-5",    "Gemini": "gemini-3.7-flash",    "DeepSeek": "deepseek-v4-flash",}​client = OpenAI(    api_key=os.environ["COMETAPI_KEY"],    base_url="https://api.cometapi.com/v1",    timeout=30.0,    max_retries=2,)​for family, model in MODELS.items():    try:        response = client.chat.completions.create(            model=model,            messages=[                {"role": "user", "content": "Reply with one short sentence."}            ],        )        text = response.choices[0].message.content or ""        print(f"{family}: OK | {response.model} | {text[:80]}")    except Exception as error:        print(f"{family}: ERROR | {type(error).__name__} | {error}")

Gardez ce test en dehors de votre workflow Dify. Son rôle est de vérifier la clé, l’endpoint et l’ID du modèle. Une fois qu’un modèle réussit ici, un échec dans Dify provient plus probablement de la configuration du plugin, des paramètres de capacité du modèle ou du workflow lui-même.

Comment vérifier la disponibilité des modèles avant le déploiement

Vous pouvez vérifier la disponibilité des modèles via le répertoire actuel des modèles CometAPI ou l’API Models avant le déploiement. Confirmez que l’ID du modèle exact apparaît dans votre compte, puis exécutez une petite requête authentifiée avant de l’ajouter à un workflow de production Dify.

Avec votre propre clé, un appel non-streaming réussi renvoie un objet Chat Completions. La formulation générée variera, mais la réponse doit contenir les champs suivants :

{  "id": "chatcmpl-...",  "object": "chat.completion",  "model": "the-routed-model-id",  "choices": [    {      "index": 0,      "message": {        "role": "assistant",        "content": "..."      },      "finish_reason": "stop"    }  ],  "usage": {    "prompt_tokens": 0,    "completion_tokens": 0,    "total_tokens": 0  }}

Dans Dify, le signal de réussite équivalent est un nœud LLM complété avec du texte dans le panneau de sortie. Consultez les journaux d’exécution de Dify pour le modèle sélectionné, le temps écoulé, l’usage de tokens et toute erreur normalisée du fournisseur.

Comment choisir le bon modèle pour Dify

Commencez par la charge de travail plutôt que par le nom du fournisseur. Utilisez un modèle de pointe pour un raisonnement difficile, un grand codebase ou des réponses à forte valeur ; choisissez un modèle plus rapide pour le chat interactif et les étapes de workflow répétées ; et utilisez un modèle texte moins coûteux pour la classification, l’extraction ou d’autres tâches bornées. Comparez les modèles avec le même ensemble d’invites et consignez la qualité des réponses, la latence, l’usage de tokens, le comportement des outils et le coût par exécution réussie. Confirmez également que la route sélectionnée prend en charge chaque entrée et fonctionnalité requises. Une connexion CometAPI partagée simplifie les changements, mais elle n’unifie pas les limites de contexte, les entrées multimodales, les outils, les sorties structurées ou les contrôles de raisonnement entre les modèles.

Scénarios de dépannage courants et solutions

Dify rejette l’identifiant avec 401. Recopiez la clé depuis le tableau de bord CometAPI et supprimez tout espace en tête ou en fin. N’incluez pas le mot Bearer dans le champ API Key de Dify ; le plugin construit l’en-tête d’autorisation.

Le fournisseur générique renvoie 404 ou du HTML. Utilisez l’URL de base complète https://api.cometapi.com/v1. Omettre /v1 ou ajouter /chat/completions à l’URL de base de Dify peut produire un chemin final erroné.

Le modèle n’apparaît pas dans Dify. Mettez à jour le plugin CometAPI, puis comparez l’ID avec le catalogue en direct. Si l’ID actuel n’est pas prédéfini, ajoutez-le comme modèle personnalisé sous le même fournisseur CometAPI. Ne substituez pas un nom de modèle qui y ressemble.

Une requête texte fonctionne mais les images ou les outils échouent. La compatibilité OpenAI décrit la surface de requête, pas un comportement d’API identique. Revérifiez les modalités listées pour le modèle et les paramètres de vision, d’appel d’outils, de sortie structurée et de raisonnement du plugin.

La requête dépasse la fenêtre de contexte. Confirmez la taille de contexte du modèle personnalisé dans Dify, raccourcissez les documents récupérés et l’historique de conversation, et réservez de la place pour la sortie. Un contexte plus grand dans le catalogue n’élimine pas les limites du workflow Dify ni les règles de tokens propres aux fournisseurs.

Vous recevez des 429 ou des 5xx intermittents. Retentez les 429, les expirations (timeout) et les erreurs serveur transitoires avec un backoff exponentiel et du jitter. Ne réessayez pas automatiquement les erreurs d’authentification, de modèle invalide ou de requête mal formée.

Notes de production

Conservez les secrets côté serveur. Utilisez des clés CometAPI distinctes pour le développement et la production, définissez des quotas raisonnables, faites tourner les clés exposées et évitez d’exporter de vrais identifiants avec des apps Dify.

Figez un ID de modèle testé. Ne remplacez pas silencieusement un modèle parce qu’un nom plus récent apparaît dans le catalogue. Les capacités, la latence, le style de sortie et le prix peuvent varier entre versions, même avec le même fournisseur.

Mesurez par route. Enregistrez l’ID du modèle, la latence, l’usage de tokens, le code d’erreur et la version de l’app Dify pour chaque appel en production. Cela permet de comparer les modèles et d’enquêter sur les variations de coût sans se fier aux impressions.

Concevez les mécanismes de repli en fonction des capacités. Utilisez un modèle moins coûteux pour le trafic de routine et un modèle plus puissant pour l’escalade, mais associez uniquement des modèles qui prennent en charge les mêmes entrées et outils requis. Retentez les défaillances transitoires avant de changer de modèle, plafonnez le budget de latence total et testez chaque route de repli. Consultez le guide de repli de modèle de CometAPI pour un schéma de production.

Revérifiez les prix avant le lancement. Les tarifs de cet article sont un instantané daté, pas un contrat. Consultez le guide de tarification et le répertoire en direct des modèles avant de définir un budget ou de publier des informations de coût.

FAQ

Comment ajouter OpenAI à Dify via CometAPI ?

Installez le plugin de fournisseur de modèles CometAPI, enregistrez votre clé CometAPI et ajoutez gpt-5.6 comme modèle LLM sélectionnable. Choisissez le mode Chat lorsque Dify demande un mode de complétion, puis exécutez une courte invite texte avant d’activer le modèle dans un workflow de production. Le catalogue CometAPI actuel répertorie la route pour les charges de travail de chat compatibles et Responses, mais la prise en charge côté plugin Dify peut varier selon les versions. Si l’ID n’est pas prédéfini, mettez à jour le plugin ou utilisez son option de modèle personnalisé. Gardez l’identifiant de fournisseur partagé inchangé et validez séparément toute entrée image, appel d’outils, sortie structurée et paramètres de raisonnement avant de compter dessus.

Comment ajouter Claude à Dify via CometAPI ?

Sous la même connexion fournisseur CometAPI, ajoutez claude-opus-5 comme modèle LLM distinct et sélectionnez-le dans le nœud Dify qui a besoin de Claude. Le catalogue CometAPI documente actuellement les routes Anthropic Messages et chat compatible OpenAI pour ce modèle. Dify a toujours besoin de sa propre entrée de modèle, car l’ID Claude, les entrées prises en charge, les limites de tokens et le comportement diffèrent de la route OpenAI. Testez une réponse simple et une tâche longue ou assistée par outils représentative, puis inspectez le journal d’exécution Dify pour le modèle réel, la latence, l’usage de tokens et les erreurs normalisées avant d’en faire la valeur par défaut.

Comment ajouter Gemini à Dify via CometAPI ?

Ajoutez gemini-3.7-flash sous le fournisseur CometAPI existant, puis choisissez cette entrée dans le nœud LLM Dify concerné. CometAPI répertorie actuellement à la fois la route native Gemini generating-content et une route de chat compatible OpenAI. Pour un workflow de chat Dify basique, commencez par du texte uniquement et confirmez une exécution réussie avant de tester les entrées images, PDF, audio ou vidéo. Ces modalités peuvent dépendre de la version du plugin et de la configuration du nœud, même si le catalogue du modèle les mentionne. Conservez Gemini comme configuration de modèle distincte pour définir des limites appropriées et comparer sa vitesse, sa qualité et son coût avec les autres routes.

Comment ajouter DeepSeek à Dify via CometAPI ?

Créez une entrée de modèle Dify distincte pour deepseek-v4-flash tout en réutilisant le même identifiant de fournisseur CometAPI. Le catalogue CometAPI répertorie actuellement cette route pour des charges de travail de chat texte-à-texte ; ne copiez donc pas les paramètres image depuis les configurations OpenAI, Claude ou Gemini. Testez d’abord une courte invite texte, puis la tâche de codage ou de raisonnement que vous prévoyez réellement d’exécuter. Si le modèle est absent dans Dify, mettez à jour le plugin ou ajoutez l’ID exact et actuel via l’option de modèle personnalisé. Revérifiez la page du modèle en direct pour la tarification dynamique et la disponibilité avant de router du trafic de production.

Puis-je utiliser OpenAI, Claude, Gemini et DeepSeek dans le même workflow Dify ?

Oui. Chaque nœud LLM peut utiliser un fournisseur/modèle différent. Avec CometAPI, les modèles pris en charge peuvent partager le même identifiant de fournisseur tandis que le workflow sélectionne différents IDs de modèle.

Une seule clé CometAPI peut-elle vraiment couvrir OpenAI, Claude, Gemini et DeepSeek dans Dify ?

Oui. Le plugin de modèle CometAPI pour Dify stocke un identifiant de fournisseur et l’utilise pour les modèles pris en charge de ces familles. Vous sélectionnez ou ajoutez toujours chaque ID de modèle afin que Dify sache quel modèle appeler.

Dois-je saisir l’URL de base CometAPI dans Dify ?

Pas lorsque vous utilisez le plugin dédié CometAPI ; il définit https://api.cometapi.com/v1 en interne. Saisissez cette URL de base manuellement uniquement lorsque vous utilisez le fournisseur générique compatible avec l’API OpenAI de Dify.

Dify prend-il en charge Claude via une API compatible OpenAI ?

Dify peut fonctionner avec des fournisseurs de modèles compatibles avec l’API OpenAI, mais la compatibilité ne rend pas le comportement de l’API Claude identique à celui d’OpenAI. Validez les paramètres et capacités pris en charge par le modèle avant d’activer les outils, la sortie structurée, la vision ou des fonctionnalités spécifiques au raisonnement.

Puis-je utiliser les mêmes paramètres Dify pour chaque modèle ?

Non. L’endpoint et la clé peuvent être partagés, mais les limites de contexte, les modalités, la prise en charge des outils, les contrôles de raisonnement, la latence et les prix restent spécifiques à chaque modèle. Traitez chaque mappage de modèle comme une configuration testée.

Quel modèle dois-je définir comme valeur par défaut ?

Décidez après avoir testé vos propres invites. Un modèle à faible coût peut gérer la classification ou la réécriture de routine, tandis qu’un modèle plus puissant peut gérer un raisonnement complexe ou des réponses à plus forte valeur. Évitez une affirmation universelle de « meilleur » sans données de charge de travail.

Conclusion

CometAPI permet à un workspace Dify d’utiliser OpenAI, Claude, Gemini et DeepSeek via un identifiant de fournisseur unique et un endpoint d’API unifié pour les charges de travail de chat compatibles. La mise en place est courte : installez le plugin de modèle, enregistrez la clé, mappez les IDs de modèle actuels et testez chaque route. Le fonctionnement reste spécifique à chaque modèle — les capacités, le contexte, la tarification et le comportement de repli doivent être vérifiés plutôt que supposés.