Dify-Apps auf einem OpenAI-API-compatible-Endpoint betreiben.

Kurzantwort: Provider installieren, Modelle per ID hinzufügen.

Öffne in Dify die Settings und geh zu Model Provider. Seit Dify 1.0 sind Provider Plugins: finde OpenAI-API-compatible (veröffentlicht von langgenius) in der Liste, oder installiere es aus dem Marketplace, und klicke dann auf der Karte auf Add Model. Der Dialog ist pro Modell: wähle den Model Type (LLM für Chat-Modelle), gib die exakte Katalog-ID in Model Name ein, füge deinen Key in API Key ein, und setze API Base URL auf https://api.apisrouter.com/v1. Lass Completion mode auf Chat, und setze dann Model context size und Upper bound for max tokens auf die dokumentierten Limits der ID, die du hinzufügst. Speichern, und das Modell erscheint in der Liste des Providers, wählbar aus dem Model-Dropdown jeder App. Wiederhole den Dialog für jede gewünschte ID; zwei Minuten pro Modell, einmalig.

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

Wie Dify mit einem kompatiblen Provider spricht.

Dify (langgenius auf GitHub, rund 149.000 Stars) ist die führende Open-Source-LLM-App-Plattform: visuelle Workflows, Agent-Nodes, RAG-Pipelines über Knowledge Bases und veröffentlichte Apps mit eigenen API-Endpoints. Jeder LLM-Node in diesem Stack löst sich zu einem unter irgendeinem Provider registrierten Modell auf. Der OpenAI-API-compatible-Provider ist bewusst generisch. Jedes hinzugefügte Modell ist ein in sich geschlossener Datensatz, ID, Endpoint, Key, Limits, und Dify schickt Standard-Chat-Completions-Requests an die konfigurierte Base URL mit deinem Model Name als model-String. Nichts im Request kümmert sich darum, welcher Vendor das Modell trainiert hat, also sind claude-sonnet-4-6 und deepseek-v4-pro hier so gültig wie jede GPT-ID, und verschiedene Modelle können sogar auf verschiedene Endpoints zeigen, falls du das je brauchst. Die Per-Modell-Registrierung, die sich wie Reibung anfühlt, ist auch die Steuerungsfläche: die Werte für Context Size und Max Tokens, die du einträgst, sind das, womit Difys Orchestrator Prompts budgetiert, Chat-Verlauf kürzt und Node-Einstellungen validiert. Trag ehrliche Zahlen aus der Modell-Dokumentation ein. Überschätzter Context erzeugt Requests, die der Endpoint ablehnt; unterschätzter kürzt still den Kontext, den deine RAG-Nodes sich mühsam beschafft haben.

Die Felder, die echte Arbeit leisten.

Model Name ist der Wire-Wert: er muss zeichengenau zur /v1/models-Liste des Gateways passen, da er in jedem Request mitreist. Der optionale Model-Display-Name beschriftet nur die UI um. Completion mode sollte für jedes Modell im aktuellen Katalog auf Chat bleiben; die Option Completion existiert für legacy Text-Completion-Endpoints und produziert gegen Chat-Modelle fehlerhafte Requests. Model context size und Upper bound for max tokens sind das Paar, das man übereilt ausfüllt. Context Size ist das Gesamtfenster des Modells; die Obergrenze deckelt, wie viele Output-Token ein Node anfordern darf. Dify setzt beide standardmäßig auf 4096, weit unter dem, was aktuelle Modelle unterstützen, und die Defaults zu belassen lähmt still langes Dokumenten-RAG und Long-Form-Generierung. Setze sie aus der Modell-Dokumentation, nicht aus Gewohnheit. Die Capability-Selektoren zählen, wenn deine Apps sie nutzen: Vision Support nur für IDs, die Bild-Input akzeptieren, und die Function-Call-Einstellung passend zur Tool-Use-Unterstützung des Modells, da Agent-Nodes darauf angewiesen sind. Eine falsche Capability-Angabe scheitert zur Laufzeit im Workflow, ein deutlich langsamerer Ort zum Debuggen als dieser Dialog. Nutzt dein Workspace auch Embedding- oder Rerank-Modelle, registriert derselbe Provider sie unter eigenen Model-Type-Einträgen gegen dieselbe Base URL; bestätige, dass die spezifischen IDs vom Endpoint bedient werden, bevor du Knowledge-Base-Einstellungen darauf verdrahtest.

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

Modelle für Workflows und Agents wählen.

Difys eigene Übersichtsseiten zeigen Token pro App, aber die Nutzungsansicht pro Key in der APIsRouter-Konsole ergänzt den Per-Modell-Split über alle Apps auf einer Seite, die Zahl, die entscheidet, welche ID den Slot behält.

• Workflow-LLM-Nodes sind Volumen: Klassifizierung, Extraktion, Routing, Zusammenfassungs-Steps, die bei jedem Run feuern. claude-haiku-4-5-20251001, gpt-5.4-mini und gemini-3.5-flash halten die Kosten pro Run flach.
• Agent-Nodes und komplexe Reasoning-Steps verdienen sich claude-sonnet-4-6, und dessen verlässliches Tool-Use zählt in Agents mehr als reine Benchmark-Werte.
• RAG-Antwort-Nodes tragen bei jedem Call abgerufenen Kontext, also dominiert Input-Pricing; deepseek-v4-pro lohnt einen Test, wo Retrieval schwer und Antworten lang sind.
• Registriere eine schnelle und eine starke ID für dieselbe Rolle und A/B-teste sie pro Node: in Dify ist ein Modellwechsel an einem Node ein Dropdown, keine Migration.
• Veröffentlichte Apps erben die Modellwahl ihrer Nodes, also ist die Dropdown-Entscheidung, die du im Editor triffst, die Unit Economics der App, die du ausshippst.

Nutzungsbasiert · unter offiziellem Preis

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

Fehlerbilder speziell für Dify.

Fehlt der Provider in der Liste, ist das Plugin nicht installiert: seit Dify 1.0 liefert der OpenAI-API-compatible-Provider als Marketplace-Plugin, und frische Self-hosted-Instanzen starten ohne es. Installiere es einmal pro Workspace. Ein Modell, das speichert, aber bei erster Nutzung Fehler wirft, ist meist eines von drei Dingen: ein Model Name, der nicht zur Katalog-Schreibweise passt, eine Base URL ohne ihr /v1 (Dify hängt Routenpfade wie /chat/completions an das an, was du einträgst), oder Context-/Max-Token-Werte über dem, was das Modell akzeptiert. Der Fehler zeigt sich im App- oder Workflow-Log; die Korrektur liegt zurück im Add-Model-Dialog. Scheitern Agent-Nodes, während einfache Chat-Nodes funktionieren, verweist das auf die Function-Calling-Capability-Einstellung, oder auf ein Modell, dessen Tool-Use nicht das erfüllt, was die Agent-Strategie erwartet. Teste Agents zuerst gegen claude-sonnet-4-6, um Konfigurationsprobleme von Modellwahl zu trennen. Und bei Self-hosted-Instanzen hinter strengen Egress-Regeln: denk daran, dass es der Dify-api-Container ist, der den Endpoint erreichen muss, nicht dein Browser; ein curl von innerhalb dieses Containers klärt Konnektivitätsfragen schnell.

Wer Dify über ein Gateway routet.

• Teams, die LLM-Apps bauen und Claude, GPT, Gemini und DeepSeek pro Node wählbar wollen, ohne ein Vendor-Konto pro Provider zu pflegen.
• Self-Hoster, die Dify für interne Tools betreiben, wo ein Key in einem Provider den gesamten Cloud-Spend des Workspace auf einem Nutzungslog hält.
• Builder, die Modelle an echten Workflows vergleichen: jeder Kandidat ist ein Add-Model-Dialog und ein Dropdown-Wechsel, keine neue Integration.
• Entwickler ohne Zugang zum Billing eines bestimmten Vendors. Guthabenbasierter Zugang ohne Kartenpflicht entfernt die Sign-up-Abhängigkeit pro Provider.
• Agenturen, die Client-Apps auf Dify ausliefern und Per-Projekt-Keys brauchen, damit sich der Modell-Spend jedes Clients selbst berichtet.

Endpoint verifizieren und den ersten Run debuggen.

Curle zuerst die Modell-Liste und registriere IDs aus ihrer Ausgabe; handgetippte Model Names sind die häufigste Ursache für Not-found-Fehler, weil das Feld Freitext ist. Führe dann eine Chat Completion gegen die registrierte ID mit demselben Key aus. Teste in Dify in einer Scratch-App, bevor du Produktions-Workflows verdrahtest: füge einen LLM-Node hinzu, wähle das neue Modell, run einmal. Authentifizierungsfehler verweisen auf das API-Key-Feld; Not-found auf Model Name; Connection-Fehler auf die Base URL oder Container-Egress; Längenfehler auf Context- und Max-Token-Werte. Sobald Runs laufen, zeigt die APIsRouter-Konsole Modell, Token-Zahlen und Ausgaben pro Anfrage. Workflows vervielfachen LLM-Calls auf eine Weise, die vom Editor aus schwer abzuschätzen ist, und das Nutzungslog ist, wo das reale Token-Profil einer Fünf-Node-Pipeline sichtbar wird, pro Modell, pro Tag.

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"}]}'

Häufige Fragen