Dify mit lokalem LLM: vLLM und Ollama als Modellanbieter, Wissensbasis und Lizenz

Dify an ein Modell auf dem eigenen GPU-Server anbinden

Dify bindet ein lokales LLM über ein Modellanbieter-Plugin an: den Anbieter OpenAI-API-compatible für vLLM oder einen anderen Server mit OpenAI-artiger API und den Ollama-Anbieter für Ollama. Sie tragen Basis-URL, Modellname und Grenzwerte ein, und Dify bietet das Modell dann allen Apps im Workspace an, für Chat, Workflows, Agenten und die Wissensbasis. Dify selbst läuft auf CPUs; die Modelle laufen auf dem GPU-Server.

Teams setzen Dify als internen Baukasten für Chat-Assistenten, Workflows und Suche in Dokumenten ein. Dieser Artikel behandelt, was sich ändert, wenn die Modelle auf eigener Hardware laufen: die Felder, die entscheiden, ob lange Kontexte und Tool Calls funktionieren, die Modelle für die Wissensbasis, wo Dify läuft, wie der GPU-Server dimensioniert wird und was die Lizenz von Dify sagt. Namen und Standardwerte stammen aus der Dokumentation und den Plugin-Schemas, gelesen am 24. Oktober 2026, als v1.17.1 die neueste Version war. Das Gegenstück für Automatisierung ist unser Leitfaden zu n8n mit lokalem LLM, ein Chat-Frontend für die Belegschaft behandelt unsere private ChatGPT-Alternative.

vLLM über den Anbieter OpenAI-API-compatible

vLLM stellt eine OpenAI-kompatible API unter /v1 bereit. Installieren Sie in Dify den Anbieter OpenAI-API-compatible aus dem Marketplace (Plugin-Version 0.0.42 am 24. Oktober 2026), legen Sie ein Modell vom Typ LLM an und füllen Sie die Felder unten aus. Das Schema des Anbieters nennt LLM, Text Embedding, Rerank, Speech-to-Text und Text-to-Speech, ein Plugin deckt also den ganzen Stack auf einem vLLM-Server ab.

Schema openai_api_compatible.yaml der offiziellen Dify-Plugins und Marketplace-Seite des Plugins (0.0.42, Stand 26. März 2026), gelesen am 24. Oktober 2026; die rechte Spalte ist unsere Empfehlung.

Zwei Standardwerte sorgen für die meisten Supportfälle am Anfang. Mit einer Kontextgröße von 4096 plant Dify Prompts, als hätte das Modell 4.096 Tokens, obwohl vLLM vielleicht 32K oder mehr bereitstellt; tragen Sie den Wert von --max-model-len ein, der zugleich bestimmt, wie viele Gespräche voller Länge auf die Karte passen. Bleibt Function Call Type auf Not Support, ist das Modell als eines ohne Tool Calling angelegt, und seine Agenten nutzen dann nach unserer Lesart der Agenten-Dokumentation die unten beschriebene ReAct-Strategie.

Tool Calls brauchen beide Seiten. Die Dokumentation von vLLM nennt --enable-auto-tool-choice für die automatische Tool-Auswahl zwingend, zusammen mit dem --tool-call-parser der Modellfamilie, etwa openai für gpt-oss und hermes für Qwen3. Unser Artikel zu den Tool-Calling-Parsern von vLLM listet die Parser und ihre Grenzen je Modell.

Die Agenten-Einstellungen von Dify zeigen, welche Strategie gilt: „Function Calling“ für Modelle mit eigener Tool-Unterstützung und „ReAct“ für die übrigen, die Dify über eine Prompting-Strategie führt. Dify empfiehlt „models that are strong at reasoning and natively support tool calling“. Maximum Iterations begrenzt die Zyklen aus Denken, Handeln und Beobachten je Anfrage, und jeder Zyklus ist ein Modellaufruf; für die GPU-Dimensionierung kann eine Agentenanfrage also mehrere Anfragen nacheinander bedeuten.

Ollama als Anbieter

Der Ollama-Anbieter (Plugin 0.1.3 am 24. Oktober 2026) fragt nach dem Modellnamen, wie Ollama ihn führt, der Basis-URL, dem Modelltyp, der Kontextlänge, der maximalen Tokenzahl und ob das Modell Bilder versteht. Die Ollama-Anleitung von Dify nennt als Basis-URL die Adresse des Ollama-Hosts mit Port 11434 und, wenn Dify in Docker läuft, eine Adresse im lokalen Netz oder http://host.docker.internal:11434, denn localhost ist im Container der Container selbst. Ihr Beispiel für die Kontextlänge ist 4096; setzen Sie den Wert, auf den Modell und Ollama eingestellt sind.

Ollama bindet standardmäßig an 127.0.0.1, Port 11434, und OLLAMA_HOST ändert das; das Container-Image von Ollama setzt OLLAMA_HOST=0.0.0.0, im Container lauscht es also auf allen Schnittstellen. Die lokale API von Ollama hat keine Authentifizierung; wenn sie im Netz lauscht, erlauben Sie Port 11434 nur vom Dify-Host aus, wie unser Leitfaden GPU-Server absichern erklärt. Für Embeddings stellen Sie den Modelltyp auf Text Embedding. Rerank-Modelle unterstützt Ollama nicht, und die Plugin-Seite verweist dafür auf vLLM, llama.cpp, Text Embeddings Inference oder Xinference. Unser Vergleich der Serving-Engines behandelt die Wahl zwischen vLLM und Ollama.

Wir liefern den GPU-Server und richten vLLM mit den Modellen und Parsern ein, die Ihre Dify-Apps brauchen; schicken Sie uns die geplanten Apps, ihre Nutzer und die vorgesehenen Modelle, und unser Team antwortet mit einer Konfiguration.

Embedding- und Rerank-Modelle für die Wissensbasis

Die Wissensbasis von Dify indexiert Dokumente auf eine von zwei Arten. High Quality „uses an embedding model to convert content chunks into vector representations“ und bietet Vektor-, Volltext- und hybride Suche. Economical nutzt zehn Schlüsselwörter je Chunk und kein Embedding-Modell, „at the expense of reduced retrieval accuracy“. Eine Wissensbasis, die als High Quality angelegt wurde, lässt sich später nicht auf Economical umstellen; Economical lässt sich hochstufen.

Die hybride Suche verbindet Vektor- und Volltextergebnisse entweder mit Gewichten, ohne Rerank-Modell, oder mit einem Rerank-Modell, das die Passagen sortiert. Rerank ist ab Werk aus; Top K steht standardmäßig auf 3, der Score-Schwellenwert auf 0,5. Zu den Standardmodellen des Workspace unter Default Models gehören ein System-Reasoning-Modell, ein Embedding-Modell und ein Rerank-Modell.

Dokumentation von Dify zu Wissensbasis und Umgebungsvariablen, gelesen am 24. Oktober 2026; Endpunkte von vLLM wie in unserem Leitfaden zu Embedding- und Reranker-Servern.

vLLM betreibt Embedding- und Scoring-Modelle in seinem Pooling-Runner mit /v1/embeddings, /v1/score und /v1/rerank. Sein --api-key schützt nur Pfade unter /v1, /v2, /inference und /cohere, nicht die Routen /rerank, /score und /pooling außerhalb davon; dieser Server sollte also nur vom Dify-Host erreichbar sein. Auswahl und Dimensionierung der beiden Modelle behandelt unser Leitfaden zu den GPU-Anforderungen von Embedding und Reranker; die kleinen Modelle passen in rund 15 GB, eine 24-GB-Karte wie die L4 fasst sie also. VECTOR_STORE steht ab Werk auf Weaviate, und Dify nennt rund drei Dutzend Alternativen, bei deren Wahl unser Vergleich der Vektordatenbanken hilft. Warum die Suche und nicht das Modell über die Qualität der Antworten entscheidet, erklärt RAG auf Firmendaten.

Dify neben dem GPU-Server betreiben

Die Docker-Compose-Anleitung von Dify verlangt mindestens 2 CPU-Kerne und 4 GiB RAM, unter Linux Docker 19.03 oder neuer und Docker Compose 2.24.0 oder neuer. Der Stack startet API, Worker, Web-Frontend, Plugin-Daemon und Agent-Backend mit PostgreSQL, Redis, Weaviate, nginx, zwei SSRF-Proxys und zwei Sandboxes. Vor dem ersten Start verlangt die Anleitung ein erzeugtes Token in DIFY_AGENT_LOCAL_SANDBOX_AUTH_TOKEN; der erste Administrator wird unter /install angelegt.

Betreiben Sie Dify auf einer eigenen virtuellen Maschine oder einem kleinen eigenen Server und überlassen Sie den GPU-Server den Modellen. So bleiben die Updates beider getrennt, und die Firewall kann nur den Dify-Host an die Modell-Ports lassen. Ändern Sie vor dem Livebetrieb die Werte, auf die die Referenz der Umgebungsvariablen hinweist:

• SECRET_KEY „must be replaced for production“; er signiert Sitzungen und Tokens und verschlüsselt gespeicherte OAuth-Zugangsdaten, und eine spätere Änderung meldet alle Nutzer ab
• INIT_PASSWORD schützt die Seite /install, bis der erste Administrator angelegt ist
• CHECK_UPDATE_URL, standardmäßig https://updates.dify.ai, kann in Air-gapped-Umgebungen leer bleiben, wie unser Artikel zu Telemetrie in selbst betriebenen KI-Tools erklärt
• UPLOAD_FILE_SIZE_LIMIT liegt für Dokumente standardmäßig bei 15 MB

Dify leitet seine ausgehenden HTTP-Anfragen, unter anderem aus HTTP-Knoten und beim Laden von Bildern, über einen SSRF-Proxy, der interne und private IP-Bereiche sperrt. Ein Workflow, der ein internes System aufrufen soll, braucht daher eine bewusste Entscheidung zur Proxy-Konfiguration, getroffen mit Ihrem Sicherheitsteam. Die Workspace-Rollen sind Owner, Admin, Editor und Member; Owner und Admins verwalten die Modellanbieter, und die Dokumentation warnt, dass API-Schlüssel der Anbieter „grant workspace-wide model access“.

Den GPU-Server für Dify-Apps dimensionieren

Dimensionieren Sie den GPU-Server nach den Anfragen, die zur Spitzenzeit gleichzeitig laufen, gezählt am Modellserver. Eine Chat-App erzeugt eine Modellanfrage je Nachricht, ein Workflow eine je LLM-Knoten, ein Agent bis zu Maximum Iterations je Frage, und jede Abfrage der Wissensbasis fügt einen Embedding-Aufruf hinzu, mit Rerank zusätzlich einen Scoring-Aufruf.

NVIDIA RTX PRO 6000 Blackwell Server Edition. Unsere Schätzung nach der Regel für Nutzer je Karte (0,9 × 95,6 GiB vom Treiber gemeldet − 3 GiB je Karte − 60,8 GiB Gewichte), 1,125 GiB 16-Bit-KV-Cache je Gespräch mit 32.768 Tokens, wie in unserem Leitfaden zum Server mit vier Karten.

Die Tabelle geht von der NVIDIA RTX PRO 6000 Blackwell Server Edition mit 96 GB je Karte aus. Unsere Regel für Nutzer je Karte nimmt 90 Prozent des Speichers, den der Treiber meldet, zieht je Karte 3 GiB und die Gewichte ab und teilt den Rest durch den KV-Cache je Gespräch; die Herleitung steht in Wie viele Nutzer schafft eine RTX PRO 6000?. Das sind gleichzeitige Gespräche voller Länge, weit weniger als die Zahl der Mitarbeitenden mit Zugang; wie dieses Verhältnis bei einer großen Belegschaft aussieht, zeigt unser Leitfaden zu Open WebUI für 1.000 Nutzer. Ein Einstiegsserver mit zwei RTX PRO 6000 Server Edition trägt einen Pilot mit mehreren Dify-Apps; ein Knoten mit vier Karten, beschrieben in unserem Artikel zum Server mit vier RTX PRO 6000 Server Edition, schafft Platz für weitere Apps, ein Embedding-Modell und einen Reranker neben dem Hauptmodell.

Die Lizenz von Dify: was die Bedingungen sagen

Die LICENSE-Datei von Dify trägt den Titel „Open Source License“ und beginnt mit: „Dify is licensed under a modified version of the Apache License 2.0, with the following additional conditions:“. Die Bedingungen im englischen Wortlaut der Datei auf GitHub, gelesen am 24. Oktober 2026:

• „1. Dify may be utilized commercially, including as a backend service for other applications or as an application development platform for enterprises. Should the conditions below be met, a commercial license must be obtained from the producer:“
• „a. Multi-tenant service: Unless explicitly authorized by Dify in writing, you may not use the Dify source code to operate a multi-tenant environment.“
• „Tenant Definition: Within the context of Dify, one tenant corresponds to one workspace. The workspace provides a separated area for each tenant's data and configurations.“
• „b. LOGO and copyright information: In the process of using Dify's frontend, you may not remove or modify the LOGO or copyright information in the Dify console or applications. This restriction is inapplicable to uses of Dify that do not involve its frontend.“
• Das Frontend „includes all components located in the web/ directory when running Dify from the raw source code, or the "web" image when running Dify with Docker.“
• „2. As a contributor, you should agree that: a. The producer can adjust the open-source agreement to be more strict or relaxed as deemed necessary. b. Your contributed code may be used for commercial purposes, including but not limited to its cloud business operations.“
• „Apart from the specific conditions mentioned above, all other rights and restrictions follow the Apache License 2.0.“

Die Datei sagt außerdem „The interactive design of this product is protected by appearance patent.“ und trägt „© 2025 LangGenius, Inc.“

Die Bedingungen hängen an Workspaces und am Frontend. Die Workspace-Seite von Dify sagt, dass „One workspace is created during installation“, und nennt mehrere Workspaces zur vollständigen Trennung eine Funktion von Dify Enterprise. Ob eine geplante Nutzung als Betrieb einer Multi-Tenant-Umgebung gilt, etwa für verbundene Unternehmen oder als Dienst für Kunden mit je eigenem Workspace, und ob ein umgestaltetes Frontend geplant ist, klären Sie vor dem Rollout mit Ihrer Rechtsberatung; eine rechtliche Bewertung geben wir nicht. Unsere Übersicht zu offenen LLM-Lizenzen für Unternehmen behandelt die Lizenzen der Modelle selbst.

Updates und Sicherheitsreleases

Die neueste Version am 24. Oktober 2026 war v1.17.1 vom 10. September. Ihre Release Notes verlangen bei selbst betriebenen Installationen mit dem mitgelieferten Weaviate ein stufenweises Update von 1.27.0 auf 1.39.2, weil „skipping minors is unsupported“. v1.17.0 nannte Sicherheitsverbesserungen, darunter Schutz der Anmeldung, Eingrenzung von Ressourcen sowie Härtung gegen SSRF und ausgehenden Verkehr, und benannte Umgebungsvariablen um. v1.16.1 stellte die lokale Sandbox des Agenten hinter einen Forward Proxy und führte DIFY_AGENT_API_TOKEN ein, dessen Standardwert im Produktivbetrieb ersetzt werden muss.

Die Compose-Anleitung sagt „Upgrade steps may vary between releases“: Lesen Sie die Release Notes jeder Version, vergleichen Sie .env.example mit Ihrer .env und übertragen Sie eigene Änderungen in die neue docker-compose.yaml, statt die alte zu behalten. Sichern Sie PostgreSQL und die Vektordatenbank vor jedem Update.

Was wir liefern

Sie können den GPU-Server für Ihre Dify-Apps bei uns kaufen: Unser Team dimensioniert die Konfiguration nach Ihrer Arbeitslast und Ihrem Budget und antwortet innerhalb eines Werktages. Wir bauen KI-Server auf Bestellung mit zwei bis acht Karten, vor der Lieferung montiert und getestet, auf Wunsch mit Betriebssystem, Treibern, CUDA und Container-Runtime. Die Einrichtung von vLLM mit Ihren Modellen, der Embedding- und Rerank-Dienste und der Anbindung an Dify gehört zu unserem Service Private AI/ML. Schreiben Sie uns Ihre Dify-Version und die eingesetzten Modelle.

FAQ