Faites tourner vos apps Dify sur un endpoint compatible OpenAI-API.

Réponse rapide : installez le fournisseur, ajoutez les modèles par id.

Dans Dify, ouvrez Settings et allez dans Model Provider. Depuis Dify 1.0, les fournisseurs sont des plugins : trouvez OpenAI-API-compatible (publié par langgenius) dans la liste ou installez-le depuis le Marketplace, puis cliquez sur Add Model sur sa carte. La boîte de dialogue est par modèle : choisissez le Model Type (LLM pour les chat models), saisissez l'id exact du catalogue dans Model Name, collez votre clé dans API Key, et réglez API Base URL sur https://api.apisrouter.com/v1. Laissez Completion mode sur Chat, puis réglez Model context size et Upper bound for max tokens sur les limites documentées de l'id que vous ajoutez. Enregistrez, et le modèle apparaît dans la liste du fournisseur, sélectionnable depuis le menu déroulant de modèle de chaque app. Répétez la boîte de dialogue pour chaque id voulu ; deux minutes par modèle, une seule fois.

Model Type:                LLM
Model Name:                claude-sonnet-4-6
API Key:                   sk-YOUR-APISROUTER-KEY
API Base URL:              https://api.apisrouter.com/v1
Completion mode:           Chat
Model context size:        200000
Upper bound for max tokens: 64000

Comment Dify parle à un fournisseur compatible.

Dify (langgenius sur GitHub, environ 149 000 étoiles) est la principale plateforme open source d'applications LLM : workflows visuels, nœuds d'agents, pipelines RAG sur des bases de connaissances, et applications publiées avec leurs propres endpoints API. Chaque nœud LLM de cette pile se résout vers un modèle enregistré sous un fournisseur. Le fournisseur OpenAI-API-compatible est délibérément générique. Chaque modèle que vous ajoutez est un enregistrement autonome, id, endpoint, clé, limites, et Dify envoie des requêtes chat-completions standard vers la base URL configurée avec votre Model Name comme chaîne de modèle. Rien dans la requête ne se soucie de quel fournisseur a entraîné le modèle, donc claude-sonnet-4-6 et deepseek-v4-pro sont ici tout aussi valides que n'importe quel id GPT, et différents modèles peuvent même pointer vers différents endpoints si jamais vous en avez besoin. L'enregistrement par modèle qui ressemble à de la friction est aussi la surface de contrôle : les valeurs de context size et de max-tokens que vous saisissez sont ce que l'orchestrateur de Dify utilise pour budgétiser les prompts, tronquer l'historique de conversation et valider les réglages des nœuds. Saisissez des chiffres honnêtes tirés de la documentation du modèle. Surestimer le contexte produit des requêtes que l'endpoint rejette ; le sous-estimer tronque silencieusement le contexte que vos nœuds RAG ont travaillé à récupérer.

Les champs qui font le vrai travail.

Model Name est la valeur qui circule sur le fil : elle doit correspondre au listing /v1/models de la passerelle caractère pour caractère, puisqu'elle voyage dans chaque requête. Le nom d'affichage optionnel ne fait que renommer l'interface. Completion mode doit rester sur Chat pour chaque modèle du catalogue actuel ; l'option Completion existe pour les anciens endpoints de complétion de texte et produit des requêtes malformées contre des chat models. Model context size et Upper bound for max tokens sont la paire que l'on bâcle par précipitation. Context size est la fenêtre totale du modèle ; l'upper bound plafonne combien de tokens de sortie un nœud peut demander. Dify règle les deux par défaut à 4096, ce qui est très en dessous de ce que supportent les modèles actuels, et laisser les défauts handicape silencieusement le RAG sur documents longs et la génération longue. Réglez-les depuis la documentation du modèle, pas par habitude. Les sélecteurs de capacités comptent quand vos apps les utilisent : Vision Support uniquement pour les ids qui acceptent une entrée image, et le réglage function-call pour correspondre au support d'usage d'outils du modèle, puisque les nœuds d'agents s'appuient dessus. Une revendication de capacité erronée échoue à l'exécution à l'intérieur du workflow, un endroit plus lent à déboguer que cette boîte de dialogue. Si votre espace de travail utilise aussi des modèles d'embedding ou de rerank, le même fournisseur les enregistre sous leurs propres entrées Model Type contre la même base URL ; confirmez que les ids spécifiques sont servis par l'endpoint avant d'y câbler les réglages de base de connaissances.

curl -s https://api.apisrouter.com/v1/models \
  -H "Authorization: Bearer $APISROUTER_API_KEY" | head -50
# register these ids verbatim as Model Name entries

Choisir des modèles pour les workflows et les agents.

Les pages de synthèse propres à Dify montrent les tokens par app, mais la vue d'usage par clé dans la console APIsRouter ajoute la répartition par modèle sur toutes les apps, sur une seule page, le chiffre qui décide quel id garde sa place.

• Les nœuds LLM de workflow sont du volume : des étapes de classification, extraction, routage, résumé qui se déclenchent à chaque exécution. claude-haiku-4-5-20251001, gpt-5.4-mini et gemini-3.5-flash gardent le coût par exécution stable.
• Les nœuds d'agents et les étapes de raisonnement complexe méritent claude-sonnet-4-6, et son usage d'outils fiable compte plus dans les agents que les scores de benchmark bruts.
• Les nœuds de réponse RAG portent du contexte récupéré à chaque appel, donc le tarif d'entrée domine ; deepseek-v4-pro vaut la peine d'être testé là où la récupération est lourde et les réponses longues.
• Enregistrez un id rapide et un id puissant pour le même rôle et testez-les en A/B par nœud : dans Dify, changer le modèle d'un nœud est un menu déroulant, pas une migration.
• Les apps publiées héritent des choix de modèle de leurs nœuds, donc la décision de menu déroulant que vous prenez dans l'éditeur est l'économie unitaire de l'app que vous livrez.

Paiement à l'usage · en dessous du tarif officiel

Selected models are priced below official list prices. Exact input, output, cache, and per-request prices are shown for each model.

Modes d'échec spécifiques à Dify.

Un fournisseur absent de la liste signifie que le plugin n'est pas installé : depuis Dify 1.0, le fournisseur OpenAI-API-compatible est livré comme plugin du Marketplace, et les instances auto-hébergées fraîches démarrent sans lui. Installez-le une fois par espace de travail. Un modèle qui s'enregistre mais échoue à la première utilisation tient généralement à l'une de ces trois choses : un Model Name qui ne correspond pas à l'orthographe du catalogue, une base URL à qui il manque son /v1 (Dify ajoute des chemins de route comme /chat/completions à ce que vous saisissez), ou des valeurs de contexte/max-tokens au-delà de ce que le modèle accepte. L'erreur apparaît dans le journal de l'app ou du workflow ; la correction se fait de retour dans la boîte de dialogue Add Model. Des nœuds d'agents qui échouent alors que de simples nœuds de chat fonctionnent pointent vers le réglage de capacité function-calling, ou vers un modèle dont l'usage d'outils ne répond pas à ce qu'attend la stratégie de l'agent. Testez d'abord les agents contre claude-sonnet-4-6 pour séparer les problèmes de configuration du choix de modèle. Et sur les instances auto-hébergées derrière des règles d'egress strictes, rappelez-vous que c'est le conteneur api de Dify qui doit atteindre l'endpoint, pas votre navigateur ; un curl depuis l'intérieur de ce conteneur règle rapidement les questions de connectivité.

Qui route Dify via une passerelle.

• Les équipes qui construisent des apps LLM et veulent Claude, GPT, Gemini et DeepSeek sélectionnables par nœud sans maintenir un compte fournisseur par provider.
• Les auto-hébergeurs qui font tourner Dify pour des outils internes, où une seule clé dans un seul fournisseur garde toute la dépense cloud de l'espace de travail sur un seul journal d'usage.
• Les créateurs qui comparent des modèles sur de vrais workflows : chaque candidat est une boîte de dialogue Add Model et un changement de menu déroulant, pas une nouvelle intégration.
• Les développeurs sans accès à la facturation d'un fournisseur donné. Un accès basé sur la recharge, sans exigence de carte, supprime la dépendance à une inscription par fournisseur.
• Les agences qui livrent des apps clients sur Dify et ont besoin de clés par projet pour que la dépense modèle de chaque client se rapporte d'elle-même.

Vérifiez l'endpoint et déboguez la première exécution.

Faites d'abord un curl sur le listing de modèles et enregistrez les ids depuis sa sortie ; les Model Names saisis à la main sont la première cause d'erreurs not-found parce que le champ est du texte libre. Lancez ensuite une completion de chat contre l'id que vous avez enregistré, avec la même clé. Dans Dify, testez dans une app jetable avant de câbler des workflows de production : ajoutez un nœud LLM, sélectionnez le nouveau modèle, exécutez une fois. Les erreurs d'authentification renvoient au champ API Key ; not-found au Model Name ; les erreurs de connexion à la base URL ou à l'egress du conteneur ; les erreurs de longueur aux valeurs de contexte et de max-tokens. Une fois les exécutions en circulation, la console APIsRouter affiche le modèle par requête, le nombre de tokens et la dépense. Les workflows multiplient les appels LLM d'une façon difficile à estimer à l'œil depuis l'éditeur, et le journal d'usage est l'endroit où le vrai profil de tokens d'un pipeline à cinq nœuds devient visible, par modèle, par jour.

curl -s https://api.apisrouter.com/v1/chat/completions \
  -H "Authorization: Bearer $APISROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"claude-haiku-4-5-20251001",
       "messages":[{"role":"user","content":"ping"}]}'

Questions fréquentes