Wer nach „LangChain-Preisen“ sucht, möchte oft einen Stückpreis finden. LangChain ist jedoch ein Open-Source-Framework; die Rechnung entsteht durch Modell-API, Embedding-Dienst, Vektordatenbank und Observability-Plattform. Wer alles vermischt, kommt leicht zu zwei falschen Schlüssen: „Das Framework ist kostenlos, also ist es günstig“ oder „Mit Agenten gerät alles außer Kontrolle“.

Dieser Artikel nennt keine Preise, die veralten, sondern liefert eine Methode zum Aufteilen, Schätzen und Begrenzen der Kosten. Modellpreise entnehmen Sie den Modellpreisen, kommerzielle Tarife den Seiten der jeweiligen Anbieter.

Hinweis: LangChain ist eine Marke von LangChain, Inc. Dieser Artikel dient der Kostenbetrachtung; es besteht keine Zugehörigkeit oder Kooperation mit LangChain, Inc. Open-Source-Lizenzen, kommerzielle Produkte und Preise können sich ändern; maßgeblich sind das offizielle Repository und die Produktseiten.

1. „LangChain-Preise“ bestehen aus vier Teilen

Aufgeteilt umfasst die Rechnung üblicherweise Framework und Bibliotheken, Modellaufrufe, Retrieval und Speicherung sowie Observability und Deployment. Die Abrechnung unterscheidet sich grundlegend:

Kostenblock Abrechnung Wann sie anfällt Leicht übersehen
Framework und Bibliotheken Open Source, meist keine Lizenzgebühr Installation und Upgrade Kommerzielle Observability-, Evaluations- oder Deployment-Produkte kosten extra
Modellaufrufe Input- und Output-Tokens Bei jeder Anfrage Retries und mehrstufige Aufrufe werden mehrfach berechnet
Embedding Meist Input-Tokens Beim Aufbau und bei jeder Abfrage Ein Modellwechsel erfordert oft einen neuen Index
Vektordatenbank und Server Abo oder Ressourcenverbrauch Dauerbetrieb Auch ungenutzte Instanzen können Kosten erzeugen
Observability und Evaluation Tarif, Sitzplätze oder Verbrauch Nach Aktivierung der Nachverfolgung Sampling und Aufbewahrung beeinflussen die Kosten

Bei den meisten Teams dominieren Modellaufrufe, aber der Stückpreis allein genügt nicht. Projekte mit geringem Aufrufvolumen, die dauerhaft eine Vektordatenbank und ständig laufende Dienste betreiben, spüren die Infrastruktur deutlicher.

2. Framework kostenlos heißt nicht niedrige Gesamtkosten

Das Open-Source-Framework von LangChain erhebt in der Regel keine Lizenzgebühr, aber „kostenlos“ beschreibt nur die Lizenz, nicht die Betriebskosten. Hinzu kommen Modell-Tokens, Embeddings, Vektordatenbank, Server, Observability-Plattform und Wartungspersonal; die ersten beiden wachsen mit dem Aufrufvolumen.

Ob es günstiger ist, entscheidet der Gesamtaufwand für dieselbe Aufgabe, nicht der Preis des Frameworks. Selbst gebaute Orchestrierung spart Plattformgebühren, kostet aber Wartungszeit; eine gehostete Plattform reduziert den Betrieb, die Rechnung folgt jedoch dem Verbrauch.

3. Chain und Agent vervielfachen Tokens

Bei einer einfachen Konversation entsprechen die Kosten ungefähr „Input plus Output“. Chain und Agent verhalten sich anders: Jeder Schritt kann System-Prompt, Verlauf, Tool-Beschreibungen und das Ergebnis des vorherigen Schritts erneut mitschicken.

Angenommen, ein Schritt hat 4.000 Input- und 600 Output-Tokens und durchläuft im Schnitt sechs Schritte, dann entspricht der Input fast sechs Kontexten statt einem. Wächst der Verlauf mit jedem Schritt, werden die späteren Schritte noch länger. Drei typische Verstärker:

  • Tool-Aufruf-Schleifen: Tool aufrufen, Ergebnis lesen, Modell erneut aufrufen – je mehr Runden, desto mehr wiederholter Kontext.
  • Multi-Agenten-Zusammenarbeit: Jeder Sub-Agent hat eigenen Prompt und Kontext; bei der Zusammenführung wird das Ergebnis erneut kopiert.
  • Fehler-Wiederholungen: Timeouts, Rate-Limits und Formatfehler lösen Retries aus; fehlgeschlagene Anfragen können ebenfalls berechnet werden.

Die Kontrolle besteht nicht darin, Agenten zu meiden, sondern die Schleife zu begrenzen: maximale Schritte, Timeout, gekürzte Tool-Ausgaben und stabile Anweisungen im Präfix, damit Caching greift. recursion_limit in LangGraph und die maximale Iterationszahl des Agent-Executors sollten in der Produktion explizit gesetzt sein.

4. RAG: Embeddings und Kontextinjektion

RAG-Kosten entstehen in zwei Phasen. Beim Aufbau der Wissensbasis werden Dokumente in Blöcke zerlegt und blockweise vektorisiert; die Kosten hängen von Blockzahl, Blockgröße und Überlappung ab. In der Abfragephase wird die Frage vektorisiert, und mehrere gefundene Blöcke werden als Kontext in den Prompt eingefügt.

Drei Stellen werden leicht unterschätzt:

  • Neuindexierung: Ein Wechsel des Embedding-Modells, eine geänderte Chunking-Strategie oder Datenbereinigung können alle Vektoren neu berechnen lassen.
  • Kontextaufblähung: Ein höheres top_k für bessere Trefferquote trägt in jeder Runde mehr Originaltext mit; die Input-Tokens steigen.
  • Reranking-Modell: Eine zusätzliche Reranking-Stufe verbessert oft die Relevanz, verursacht aber weitere Aufrufe und Latenz.

Günstiger wird es, wenn zuerst die Retrieval-Qualität und dann die Menge optimiert wird: Chunking verbessern, deduplizieren, Metadatenfilter ergänzen, mit Reranking schwach relevante Blöcke entfernen und erst zuletzt ein günstigeres Modell erwägen. Abrechnung von Embedding und RAG steht in den weiterführenden Artikeln am Ende.

5. Caching: Gespart wird das wiederholte Präfix

Caching wirkt auf zwei Ebenen mit unterschiedlicher Funktion.

Die erste Ebene ist der Präfix-Cache des Modellanbieters. Bei identischem Anfragebeginn ist das Lesen aus dem Cache meist günstiger als neuer Input; Unterstützung, Rabatt und Aufbewahrungszeit unterscheiden sich je Anbieter. Wichtig: System-Prompt, Rollendefinition und feste Dokumente nach vorn, die aktuelle Frage und temporäre Daten nach hinten; häufige Änderungen früher Nachrichten oder ein Modellwechsel machen den Cache ungültig.

Die zweite Ebene ist Anwendungs-Cache. LangChain bietet Mechanismen wie set_llm_cache, mit denen identische Anfragen im Speicher, in SQLite oder Redis zwischengespeichert werden; Umfang und Unterstützung hängen von Integrationspaket und Version ab, bei Chat-Modellen besonders auf die Dokumentation achten. Das eignet sich für stabile, stark wiederholte Antworten, nicht für stark personalisierte oder Echtzeitanfragen. Ob es sich lohnt, entscheidet die Trefferquote, nicht das bloße Aktivieren.

6. Die Schätzung als nachrechenbare Formel

Budgets nicht nach Gefühl aufstellen. In sechs Schritten ein Kostenmodell aufbauen:

  1. Alle Modellaufrufpfade der Anwendung auflisten, einschließlich Hauptablauf, Retries, Zusammenfassungen und Titelerzeugung.
  2. Über Callbacks oder Verbrauchsfelder der Antwort die Input- und Output-Tokens je Schritt messen.
  3. Durchschnittliche Schrittzahl pro erfolgreicher Aufgabe und Anteil der Fehler-Wiederholungen ermitteln.
  4. Den Stückpreis von der Preisseite lesen und einheitlich in „Einheiten pro Million Tokens“ umrechnen.
  5. Embedding-, Vektordatenbank-, Server- und Observability-Kosten addieren.
  6. Mit der echten Rechnung des ersten Monats kalibrieren und Annahmen zu Schritten und Retries korrigieren.

Die folgende Funktion rechnet nur; der Stückpreis wird von Ihnen eingetragen:

import os

# Preise von der Preisseite in Umgebungsvariablen, Einheit: pro Million Tokens
IN = float(os.environ["PRICE_IN_PER_MTOK"])
OUT = float(os.environ["PRICE_OUT_PER_MTOK"])

def task_cost(input_per_step: int, output_per_step: int, steps: int,
              retry_rate: float = 0.1) -> float:
    calls = steps * (1 + retry_rate)
    return (input_per_step * calls * IN + output_per_step * calls * OUT) / 1_000_000

# Beispiel: 4.000 Input und 600 Output pro Schritt, 6 Schritte, 10 % Retries
print(round(task_cost(4000, 600, 6), 4))

Auf die Einheiten achten: Viele Preisseiten nennen den Preis pro Million Tokens; im Code wird mit dem Stückpreis multipliziert und durch eine Million geteilt, damit keine Vermischung mit „pro Tausend Tokens“ entsteht.

7. Budgetgrenzen: Überschreitungen vorher abfangen

Eine Schätzung kann nur prognostizieren, Limits fangen ab. Auf zwei Ebenen ansetzen:

  • Im Gateway pro Key Budget, Modell-Whitelist und Ratenlimit setzen und Keys nach Projekt oder Umgebung trennen.
  • In der Anwendung max_tokens, Anfrage-Timeout und Retry-Obergrenzen setzen; max_tokens begrenzt nur die Ausgabe, lange Kontexte brauchen eigene Kontrolle.
  • Für Agenten maximale Schritte und Rekursionsgrenze definieren, damit Tool-Aufrufe nicht in Schleifen laufen.
  • Pro Nutzer oder Mandant ein Tageslimit setzen, damit eine einzelne fehlerhafte Anfrage nicht das Gesamtbudget kippt.
  • Verbrauchswarnungen konfigurieren und bei Schwellenwerten die Verantwortlichen benachrichtigen.

Budgetgrenzen sind kein Misstrauen gegenüber dem Team, sondern verwandeln eine unvorhersehbare Rechnung in eine vorhersehbare Grenze; Test-Keys und CI-Keys benötigen sie besonders.

8. Observability und Auswertung: Stückkosten pro Aufgabe

Eine Gesamtrechnung zeigt nur, wie viel ausgegeben wurde, nicht wofür. Nach Aufgabe, Modell und Aufrufkette aufschlüsseln:

  • Antwortnachrichten von LangChain enthalten oft usage_metadata mit Input-, Output- und Gesamttokens; die Felder können je Anbieter abweichen.
  • Callback-Handler können vor und nach jedem Modellaufruf Dauer, Modellname und Verbrauch protokollieren und an bestehende Logsysteme anbinden.
  • Observability-Plattformen wie LangSmith zeigen vollständige Aufrufketten; ob und mit welchem Sampling sie aktiviert werden und wie der Tarif aussieht, sollte das Team nach Bedarf bewerten.

Bei der Auswertung zählen die „durchschnittlichen Kosten pro erfolgreicher Aufgabe“, nicht „Kosten pro Aufruf“. Erstere enthalten Fehler-Wiederholungen und manuelle Eingriffe und nähern sich dem realen Unit Economics. Bei hohem Volumen sollte das Tracing gesampelt werden, damit Observability nicht selbst zum Kostenfaktor wird.

Häufige Fragen

Kostet LangChain selbst Geld?

Das Open-Source-Framework erhebt in der Regel keine Lizenzgebühr und steht unter MIT-Lizenz. Kommerzielle Produkte wie LangSmith oder Deployment-Plattformen werden separat berechnet. Maßgeblich sind das offizielle Repository und die Produktseiten.

Warum ist der lokale Test günstig, die Rechnung nach dem Start aber hoch?

Lokale Tests haben wenig Volumen, kurze Kontexte und wenige Fehler. In der Produktion steigen Parallelität, Retries, lange Sitzungen, Tool-Schleifen und Retrieval-Kontext und vervielfachen die Tokens. Wer den echten Verbrauch pro Aufgabe misst und mit dem Produktionsvolumen multipliziert, erklärt die Differenz meist.

Wie lassen sich Agent-Kosten schätzen?

Zuerst Input und Output eines Schritts messen, dann durchschnittliche Schrittzahl und Retry-Quote pro Aufgabe bestimmen und mit „Schritte × Verbrauch pro Schritt“ rechnen. Bei wachsendem Verlauf ist der tatsächliche Input höher. Der Schleife Grenzen setzen und mit echten Tracing-Daten kalibrieren.

Wofür ist RAG hauptsächlich teuer?

Meist für die Kontext-Tokens in der Generierungsphase, danach für die Embeddings beim Aufbau. Retrieval und Vektordatenbank kosten ebenfalls, sind aber selten der größte Posten. Anpassungen an top_k, Chunking und Reranking wirken meist schneller als ein Modellwechsel.

Spart Caching immer Geld?

Nein. Der Nutzen hängt vom Anteil wiederholter Anfragen und der Stabilität des Präfixes ab. Bei verstreuten, stark personalisierten oder häufig aktualisierten Anfragen ist die Trefferquote niedrig. Zuerst die Trefferquote anhand der Logs schätzen, dann über Caching entscheiden.

Nächste Schritte

Die Kosten von LangChain lassen sich in vier Rechnungen zerlegen: Das Framework ist meist kostenlos, Modelle werden nach Tokens abgerechnet, Retrieval und Infrastruktur laufen kontinuierlich, Observability und Deployment richten sich nach dem Tarif. Die Reihenfolge lautet messen, schätzen, begrenzen und zuletzt mit der echten Rechnung kalibrieren. Für einen einheitlichen Modellzugang, Verbrauchsstatistik pro Key und Budgetverwaltung können Sie sich im ZSQH AI Gateway registrieren; Modelle und Preise entnehmen Sie den Modellpreisen.

Weiterlesen: