Wer nach „Dify-Preisen“ sucht, vergleicht oft drei Dinge gleichzeitig: die Kosten des Cloud-Abos, die Modellaufrufe und die Serverrechnung beim Selbstbetrieb. Diese drei Beträge müssen getrennt kalkuliert werden, sonst entstehen falsche Schlüsse wie „Cloud ist teuer“ oder „Selbstbetrieb ist kostenlos“.

Dify ist eine Orchestrierungsschicht und produziert keine Modelle. Ob Cloud oder Selbstbetrieb: Die Modellkosten bestehen immer separat. Im Folgenden werden Plattform-, Modell- und Betriebskosten getrennt und eine Schätzreihenfolge beschrieben. Preise und Kontingente ändern sich; konkrete Zahlen stehen auf den offiziellen Seiten und den Modellpreisen.

Hinweis: Dify ist eine Marke des Rechteinhabers LangGenius, Inc. Dieser Artikel ist eine unabhängige technische Darstellung; es besteht keine Zugehörigkeit oder Vertretungsbeziehung zum Dify-Team. Andere genannte Produktnamen gehören ihren jeweiligen Rechteinhabern.

1. Die Rechnung in vier Schichten zerlegen

Kostenschicht Dify Cloud Selbstbetrieb Leicht übersehen
Plattform Abo mit Mitgliederzahl, Funktionen und Kontingent Community Edition ohne Abo, aber an Lizenzbedingungen gebunden Abo monatlich oder jährlich; Lizenz für kommerzielle Szenarien prüfen
Modell Eingebaute AI-Credits oder eigener Anbieter-Key Eigener Anbieter-Key oder einheitliches Gateway Abrechnung nach Tokens, Bildern oder Aufrufen
Infrastruktur Im Abo enthalten Server, Datenbank, Vektordatenbank, Objektspeicher, Bandbreite Erscheint einzeln in der Cloud-Rechnung
Betrieb Vom Plattformbetreiber getragen Upgrades, Backups, Monitoring, Sicherheit, Bereitschaft Personalkosten werden oft als null angesetzt

Cloud bündelt Infrastruktur und Betrieb im Abo, Selbstbetrieb gibt beide Ebenen zurück. Für den Vergleich müssen alle vier Schichten dieselbe Basis haben: entweder Gesamtkosten über drei Jahre oder monatliche Ausgaben. Abopreis gegen Serverpreis zu stellen, ergibt keine sinnvolle Aussage.

2. Dify Cloud: Das Abo kauft Kontingent und Entlastung

Das Cloud-Abo wird pro Workspace berechnet und bestimmt Mitgliederobergrenze, Funktionen und Kontingent. Nach der Dokumentation von Oktober 2026 gibt es die Stufen Sandbox, Professional und Team; Sandbox ist kostenfrei und enthält einmalige AI-Credits, die nach Verbrauch nicht aufgefüllt werden; die beiden höheren Stufen bieten mehr Kontingent. Maßgeblich ist die Dify-Preisseite.

Zwei Quoten werden leicht mit der Abogebühr verwechselt:

  • AI-Credits: für die in der Plattform eingebauten Modelle; nach Verbrauch kann auf einen eigenen Anbieter-Key gewechselt werden, die Kosten laufen dann über das Modellkonto.
  • Wissensdatenbank-Speicher: wird nach Vektorbelegung berechnet, nicht nach Dateigröße; nur hochwertige Indizes belegen Speicher, wirtschaftliche Indizes nicht.

Der Platzbedarf eines Dokuments hängt von Blockgröße, Eltern-Kind-Segmentierung und Embedding-Dimension ab. Jeder Unterblock eines Elternblocks ist ein Vektor; ein hochdimensionales Modell kann pro Block doppelt so viel belegen wie ein niedrigdimensionales. Ist das Kontingent erschöpft, werden neue Dokumente, Blockbearbeitungen und Neuindexierungen blockiert; bestehende Wissensdatenbanken bleiben durchsuchbar, aber es muss gekürzt oder upgegradet werden.

Cloud eignet sich, wenn kein Serverbetrieb gewünscht ist und das Team überschaubar bleibt; das Risiko liegt im Kontingent: Wachsende Wissensdatenbanken, mehr Mitglieder oder aufgebrauchte Credits können ein Upgrade auslösen.

3. Selbstbetrieb: kein Abo heißt nicht günstig

Die Community Edition lässt sich selbst betreiben, die Softwaregebühr ist null, aber die Lizenz ist kein bedingungsloses Apache 2.0: Ohne schriftliche Erlaubnis darf kein mandantenfähiges SaaS betrieben werden; bei Nutzung des Frontends dürfen Logo und Copyright nicht entfernt oder verändert werden; die übliche kommerzielle Nutzung ist erlaubt. Wer Dify als verkauftes SaaS verpacken will, sollte die Lizenz vorher bewerten lassen.

Ein vollständiger Selbstbetrieb umfasst mindestens api, worker, web, plugin_daemon, PostgreSQL, Redis, Vektordatenbank, nginx und Sandbox-Dienste. Die offizielle Mindestkonfiguration von 2 CPU-Kernen und 4 GiB Arbeitsspeicher reicht nur zum Testen; für die Produktion muss nach Parallelität, Dokumentmenge und Indexgröße neu dimensioniert werden.

Kostenpositionen:

  • Rechenleistung: Anwendung, Plugins, Sandbox-Dienste.
  • Datenbank: PostgreSQL-Speicher, Backups und Hochverfügbarkeit.
  • Vektordatenbank: Arbeitsspeicher und Festplatte sind die großen Posten; Skalierung ist nicht billig.
  • Speicher und Netzwerk: Objektspeicher, Backups, Bandbreite, Load Balancer, Zertifikate.
  • Betriebspersonal: Upgrades, Plugin-Kompatibilität, Sicherheitspatches, Monitoring, Bereitschaft.
  • Umgebungskopien: je eine für Test, Staging und Produktion.

Die letzten beiden Punkte werden am häufigsten vergessen. Die „Ersparnis“ des Selbstbetriebs wird mit Personal erkauft; ohne verantwortliche Betriebskraft kann das Gesparte durch Ausfälle und Überstunden zurückkommen.

4. Modellaufrufe: der wirklich mit dem Volumen wachsende Teil

Modellaufrufe werden nach Verbrauch abgerechnet und wachsen linear mit dem Geschäftsvolumen. In Dify erzeugt jede Ausführung eines LLM-Nodes, jeder Tool-Aufruf eines Agenten, jedes Rerank und jedes Embedding Kosten beim Upstream.

Drei Verstärker:

  1. Mehrstufige Orchestrierung: Agenten und Workflows tragen System-Prompt, Verlauf und abgerufene Fragmente in spätere Schritte; je mehr Schritte, desto steiler der Input.
  2. Langer Kontext: Ein ganzes Dokument oder viele abgerufene Fragmente im Prompt können die Einzelkosten stärker bestimmen als der Modellpreis.
  3. Retries und Fehler: Timeouts, 429 und 5xx können Wiederholungen auslösen; ob doppelt berechnet wird, hängt vom Upstream ab. Das Budget sollte den schlechtesten Fall einplanen.

Die Steuerung ist überschaubar: kleine Modelle für Klassifikation, Umschreibung und Extraktion, starke Modelle für die finale Generierung; Zahl der abgerufenen Fragmente und Länge der Einzelfragmente begrenzen; Ausgaben begrenzen; identische Anfragen deduplizieren. Streaming verkürzt nur die Wartezeit und senkt nicht die Output-Token-Abrechnung.

5. RAG und Wissensdatenbank: einmalige plus laufende Kosten

Die Kosten der Wissensdatenbank teilen sich in Aufbau und Abfrage.

Beim Aufbau wird das Embedding nach Input-Tokens berechnet; Blocküberlappung, Kopf- und Fußzeilen sowie wiederholte Vorlagen werden mitgezählt. Ein Modellwechsel, geänderte Dimensionen oder neue Chunking-Regeln erfordern meist eine vollständige Neu-Einbettung – einmalig, aber möglicherweise erheblich. In der Abfragephase fallen mindestens Vektorisierung der Frage und Vektorsuche an, dazu eventuell Reranking und ein langer Generierungs-Input.

Die richtige Reihenfolge zur Kostensenkung: zuerst Text bereinigen, dann semantisch chunken und die Überlappung auf ein sinnvolles Maß begrenzen, anschließend inkrementell indexieren und erst zuletzt ein günstigeres Embedding-Modell erwägen. Umgekehrt bleibt häufig ein etwas billigeres Modell, während schmutziger Text und doppelte Indizes unverändert bleiben; die Rechnung bewegt sich kaum und die Trefferqualität sinkt.

Wirtschaftliche Indizes belegen keinen Vektorspeicher, arbeiten aber mit anderem Retrieval; die Wirkung sollte mit dem eigenen Fragensatz geprüft werden. In Kundendienst-, Vertrags- oder Regulierungsszenarien, die empfindlich auf Trefferqualität reagieren, nicht allein wegen Speicherkosten umstellen.

6. Workflows, Caching und Budgetgrenzen

Nicht nach „Läufen“ budgetieren. Zwei Ausführungen können sich bei den Modellaufrufen um ein Vielfaches unterscheiden: Die eine durchläuft nur Klassifikation und Vorlagenantwort, die andere mehrere Retrieval-Runden, Reranking und Langtext-Generierung. Die Schätzeinheit sollte „durchschnittliche Tokens pro Lauf“ mal „Läufe pro Monat“ sein.

Caching spart oft direkter als ein Modellwechsel:

  • Gleiche Fragen mit wiederverwendeten Antworten und sinnvoller Ablaufzeit.
  • Häufige Suchanfragen mit zwischengespeicherten Retrieval-Ergebnissen, die bei Dokumentupdates über die Wissensdatenbank invalidiert werden.
  • Embedding-Ergebnisse identischer Texte zwischenspeichern, um doppelte Vektorisierung zu vermeiden.
  • Stark zeitgebundene, personalisierte oder sensible Antworten nicht cachen.

Budgetgrenzen gehören an drei Stellen: Kontingent und Rechnungswarnungen in Cloud, Nutzungslimits beim Anbieter, falls vorhanden, sowie Statistiken und Alarme pro Key im Gateway. Jeder Anwendung oder Umgebung einen eigenen Key geben, damit Rechnungen dem Geschäft zuordenbar sind; sonst steht am Monatsende nur eine große Zahl. Schwellen lassen sich bei 50, 80 und 90 Prozent setzen; beim Erreichen zuerst unkritische Workflows herunterstufen und dann über einen Modellwechsel nachdenken.

7. Ein wiederverwendbarer Schätzrahmen

In dieser Reihenfolge schätzen.

  1. Anwendungen und Workflows auflisten und markieren, welche Modelle aufrufen und welche nur Retrieval betreiben.
  2. Aus den Logs der letzten zwei Wochen den echten Token-Verbrauch entnehmen und durchschnittlichen Input und Output pro Lauf berechnen.
  3. Monatliche Läufe schätzen und Spitzen von Nebenzeiten unterscheiden.
  4. Aufbau und Neu-Einbettung separat planen und nicht in die monatlichen Inferenzkosten mischen.
  5. Infrastrukturrechnung eintragen: Server, Datenbank, Vektordatenbank, Speicher, Bandbreite.
  6. Betriebspersonal und mindestens 20 Prozent Puffer ergänzen und mit der echten Rechnung des ersten Monats korrigieren.
# Schätzrahmen: Stückpreise leer lassen und aus Preisseite bzw. Rechnung eintragen
runs_per_month = 30_000
input_tokens_per_run = 3_000
output_tokens_per_run = 500
embed_tokens_per_index = 20_000_000
reindex_times_per_month = 1

input_price_per_1k = 0.0   # Preis pro 1.000 Input-Tokens eintragen
output_price_per_1k = 0.0  # Preis pro 1.000 Output-Tokens eintragen
embed_price_per_1k = 0.0   # Embedding-Preis pro 1.000 Tokens eintragen

model_cost = (
    runs_per_month * input_tokens_per_run / 1000 * input_price_per_1k
    + runs_per_month * output_tokens_per_run / 1000 * output_price_per_1k
)
embed_cost = embed_tokens_per_index * reindex_times_per_month / 1000 * embed_price_per_1k
print(model_cost + embed_cost)

Der Rahmen erfasst nur Modell und Embedding; Infrastruktur und Personal kommen hinzu. Stückpreise nicht aus Werbeseiten übernehmen, sondern den Modellpreisen und der Cloud-Rechnung entnehmen.

Häufige Fragen

Erhebt Dify selbst Modellaufrufgebühren?

Dify ist eine Orchestrierungsplattform; Modellaufrufe werden vom Anbieter berechnet. Cloud kann eingebaute Credits bieten, danach wird der eigene Key genutzt; beim Selbstbetrieb läuft alles über das eigene Modellkonto. Maßgeblich ist die Rechnungsseite.

Ist selbst betriebenes Dify vollständig kostenlos?

Die Community Edition hat keine Abogebühr, aber Server, Datenbank, Vektordatenbank, Bandbreite, Backups und Betrieb liegen bei Ihnen. Mit Personal gerechnet ist Selbstbetrieb in kleinen Szenarien nicht zwingend günstiger als Cloud.

Lässt sich das Cloud-Abo mit Modell-API-Kosten verrechnen?

In der Regel nicht direkt. Das Abo deckt Plattformfunktionen und Kontingent, Modellkosten werden über das Anbieterkonto abgerechnet, und eingebaute Credits haben begrenzten Umfang. Vor dem Einkauf beide Rechnungen getrennt prüfen.

Warum ist der Wissensdatenbank-Speicher viel größer als die Originaldateien?

Weil nach Vektorzahl abgerechnet wird, nicht nach Dateigröße. Feinere Blöcke, mehr Eltern-Kind-Segmente und höhere Embedding-Dimensionen erhöhen die Belegung; wirtschaftliche Indizes belegen keinen Speicher, liefern aber andere Retrieval-Ergebnisse.

Bei begrenztem Budget: Wo zuerst kürzen?

Zuerst bei unnötigem Kontext und doppelten Aufrufen: Prompts komprimieren, Zahl der abgerufenen Fragmente begrenzen, Ausgaben limitieren, deduplizieren und cachen; danach über kleinere Modelle oder einen anderen Tarif nachdenken. Die Modellqualität direkt zu senken, belastet die Erfahrung am stärksten.

Nächste Schritte

Sind die vier Kostenschichten geklärt, fällt die Wahl leichter: mit echten Logs die monatlichen Tokens schätzen und dann Cloud-Abo, Selbstbetriebsaufwand und nutzungsabhängige Gateway-Kosten zusammenzählen. Für einen einheitlichen Zugang und Abrechnung nach Verbrauch können Sie sich im ZSQH AI Gateway registrieren; Modellumfang und Preise entnehmen Sie den Modellpreisen.

Weiterlesen: