Warum Anbieter von LLM-Tracing-Tools jetzt KI-Gateways entwickeln

2026 ergänzten LangSmith, Langfuse, Opik und Braintrust ihre Angebote jeweils um ein Gateway, das den Modellanbietern vorgeschaltet ist. Der Hauptgrund dafür ist die Kontrolle: Ein Tracing-Tool kann einen Modellaufruf lediglich aufzeichnen, während ein Gateway ihn unterbinden kann.

Zwei Tools für unterschiedliche Aufgaben

In den vergangenen zwei Jahren setzten viele Teams für Anwendungen mit großen Sprachmodellen (LLMs) zwei separate Tools ein. Ein Gateway befand sich zwischen der Anwendung und den Modellanbietern. Es verwahrte die API-Schlüssel der Anbieter, übersetzte zwischen den Anbieter-APIs und wiederholte fehlgeschlagene Aufrufe. LiteLLM, ein Open-Source-Proxy, wurde für diese Aufgabe häufig eingesetzt. Neben der Anwendung kam ein Tracing-Tool wie LangSmith oder Langfuse zum Einsatz. Es zeichnete jeden Modellaufruf, Tool-Aufruf und Abrufschritt auf, damit Entwickler sehen konnten, was ein Agent getan hatte.

Diese Aufgabenteilung war sinnvoll: Ein Gateway muss schnell sein und die API jedes Anbieters unterstützen, während ein Tracing-Tool eine gute Benutzeroberfläche, Speicherplatz für große Nutzdaten und ein SDK benötigt, das sich in den Anwendungscode einbinden lässt. Langfuse dokumentiert die Verwendung zweier Tools weiterhin und bietet eine Integration des LiteLLM-Proxys, die jeden Aufruf über den Proxy an Langfuse weiterleitet. 2026 begannen die Tracing-Anbieter, selbst Gateways zu entwickeln.

Vier Markteinführungen in sechs Monaten

LangChain kündigte das LangSmith-LLM-Gateway im Mai 2026 als private Betaversion an und öffnete es am 30. Juli für die öffentliche Beta. Inzwischen ist es auch Teil von LangSmith-Bereitstellungen in der eigenen Cloud-Umgebung. Braintrust stellte seinen früheren KI-Proxy ein und verwies Nutzer auf ein neues Gateway, das sich in der Vorschau befindet und bis zur allgemeinen Verfügbarkeit kostenlos ist. Comet veröffentlichte das Opik-LLM-Gateway als Beta-Endpunkt, der Anfragen im OpenAI-Format entgegennimmt. Am 4. November öffnete Langfuse sein KI-Gateway für die öffentliche Beta – sowohl in Langfuse Cloud als auch für selbst gehostete Bereitstellungen. Das Gateway steht unter der MIT-Lizenz und ist in Rust geschrieben.

MLflow, ursprünglich ein Tool für den Lebenszyklus von maschinellem Lernen und kein Tracing-Tool, bietet schon länger ein KI-Gateway mit Budgetwarnungen und -limits.

Gateways gibt es schon seit Jahren, und die Risiken ihres Betriebs sind gut dokumentiert. Die neuen Gateways stammen von Unternehmen, deren Geschäft auf der Aufzeichnung von Modellaufrufen beruhte und die nun wollen, dass jeder Aufruf zuerst über sie läuft.

Warum ein Budget den Anfragepfad braucht

Ein Tracing-Tool zeichnet einen Modellaufruf erst auf, nachdem der Anbieter geantwortet hat und die Tokens bezahlt wurden. Das reicht aus, um ein Ausgabendiagramm zu erstellen, aber das Tracing-Tool kann die Ausgaben nicht stoppen. Um das Budget eines Teams durchzusetzen, ein Modell zu sperren oder ein Geheimnis aus einer Eingabeaufforderung zu entfernen, muss die Anfrage geprüft werden, bevor sie den Anbieter erreicht. Das kann nur die Komponente tun, die sich im Anfragepfad befindet.

LangChain führt dieses Argument in seinem Beitrag zur Markteinführung an. Das Unternehmen beschreibt, wie Teams ein separates Gateway, ein Produkt für Sicherheitsrichtlinien und ein Observability-Tool miteinander kombinieren, und erklärt, dass sich Probleme durch die Durchsetzung von Richtlinien auf Anfrageebene verhindern lassen. Wenn ein Aufruf das Budget überschreiten würde, antwortet das Gateway mit dem HTTP-Statuscode 402, statt ihn an den Anbieter weiterzuleiten.

Ein einziger Zugangspunkt erfasst jeden Aufruf

Der zweite Grund ist die Abdeckung. Ein SDK zeichnet nur die Codepfade auf, die jemand instrumentiert hat. Außerhalb dieser Pfade bleiben Fehler von Agenten oft unbemerkt. Ein Skript auf einem Laptop, ein Notebook oder ein Coding-Agent, der einen kopierten API-Schlüssel verwendet, hinterlässt keine Spur. Ein Gateway, das die Anbieterschlüssel verwahrt, sieht jeden Aufruf, weil es keinen anderen Weg zum Anbieter gibt.

Langfuse entwickelt sein Gateway nach diesem Prinzip. Laut der Gateway-Dokumentation ist jeder Gateway-Schlüssel einem Nutzer oder einem Dienstkonto zugeordnet und kann Metadaten wie ein Team oder eine Kostenstelle enthalten. Nur das Gateway verwahrt die Zugangsdaten des Anbieters, und Administratoren genehmigen, welche Modelle mit den jeweiligen Zugangsdaten aufgerufen werden dürfen. LangSmith veröffentlicht Einrichtungsanleitungen, um Claude Code, Codex und Gemini CLI über sein Gateway weiterzuleiten. Diese Agenten rufen Modelle vom Rechner eines Entwicklers aus auf und befinden sich damit außerhalb des Tracing-Codes jeder Anwendung.

Was das Gateway eines Tracing-Tools zusätzlich bietet

Die Tracing-Anbieter führen auch das umgekehrte Argument an: Ein eigenständiges Gateway reicht für sich genommen nicht aus. Im Beitrag zur Markteinführung erklärt Langfuse, ein eigenständiges Gateway könne nur Tokens und Kosten erfassen, während das eigene Gateway jeden Aufruf in einen vollständigen Trace einbinde. Das Gateway von Langfuse akzeptiert einen W3C-Traceparent-Header, sodass ein darüber laufender Aufruf in den Trace aufgenommen wird, den die Anwendung bereits begonnen hat. Standardmäßig erfasst es Nutzung und Kosten, nicht aber den Inhalt von Eingaben und Antworten.

Das ist das überzeugendste technische Argument dafür, das Gateway in das Tracing-Tool zu integrieren. Ein eigenständiges Gateway sieht lediglich eine flache Liste von Generierungen. Ein Tracing-Tool erfasst über sein SDK bereits die Tool-Aufrufe und Abrufschritte des Agenten und kann jeden Gateway-Aufruf in diese Struktur einordnen.

Es gibt auch eine wirtschaftliche Perspektive, die die Anbieter selbst nicht ausdrücklich benennen. Wer das Gateway betreibt, verwaltet die Anbieterschlüssel und den Ausgabenbericht – und diesen Bericht lesen die Finanz- und Plattformteams. Dadurch lässt sich ein Gateway schwerer ersetzen als ein Tool zur Anzeige von Traces. LangSmith und Langfuse nutzen diese Position bereits auf unterschiedliche Weise: LangSmith verkauft Gateway Credits, mit denen Kunden gehostete Modelle wie Kimi ohne eigenen Anbieterschlüssel aufrufen können. Laut den FAQ von Langfuse verkauft das Unternehmen hingegen keine Tokens weiter.

Was die Beta-Gateways noch nicht können

Diese Gateways sind noch jung, und die Anbieter dokumentieren selbst, wo ihre Grenzen liegen. Das Gateway von Langfuse unterstützt derzeit nur OpenAI und Anthropic; Amazon Bedrock, Google Vertex AI und Google AI Studio stehen auf der Roadmap. Ausweichmöglichkeiten zwischen Anbietern und feste Ausgabenlimits pro Team, Nutzer oder Schlüssel sind geplant, aber noch nicht verfügbar. Vorerst bietet das Gateway ein Ausgaben-Dashboard und Benachrichtigungen. In der Dokumentation werden weder Ratenbegrenzungen noch das Zwischenspeichern von Antworten beschrieben.

Das Langfuse-Gateway konvertiert nicht zwischen API-Formaten, sodass ein OpenAI-Client nur OpenAI-Modelle aufrufen kann. Die selbst gehostete Version ruft ausschließlich offizielle Anbieter-URLs auf. Azure OpenAI, Bedrock und ein interner Proxy kommen damit vorerst nicht infrage. Comet beschreibt das Opik-Gateway als für Entwicklung und Tests konzipiert. Braintrust hat keine Preise für sein Gateway bekannt gegeben.

Das Gateway von LangSmith kann bereits mehr als die anderen. Laut Dokumentation gehören Ausweichmöglichkeiten, Ausgabenlimits, Ratenbegrenzungen und Datenrichtlinien zu den derzeit verfügbaren Funktionen. Außerdem unterstützt es die Formate OpenAI Chat Completions, OpenAI Responses und Anthropic Messages. Im Mai waren Ausweichmöglichkeiten und Ratenbegrenzungen noch als geplante Funktionen aufgeführt; sie kamen also während der Beta hinzu. Das Produkt ist insgesamt weiterhin als Beta gekennzeichnet.

Lasttests zeigen eine andere Art von Schwachstelle. Ein selbst gehosteter Benchmark des Langfuse-Gateways, von LiteLLM und AcruxCore ergab, dass das Langfuse-Gateway pro Aufruf weniger Latenz verursachte als LiteLLM. Mit den standardmäßigen Docker-Einstellungen schlug es jedoch bei 739 von 1.000 gleichzeitigen Streams fehl, weil der Prozess Docker-Standardlimit von 1.024 geöffneten Dateien beibehielt. Eine Zeile in der Compose-Datei von Langfuse behob das Problem.

Im Vergleich zu diesen Betas unterstützt LiteLLM, ein seit Jahren eigenständiges Gateway, mehr als 100 Anbieter und bietet bereits virtuelle Schlüssel, Ausgabenüberwachung, Leitplanken, Lastverteilung und ein Administrations-Dashboard. LiteLLM stellt außerdem den Anfragepfad von Python auf Rust um. Das Rust-KI-Gateway befindet sich in der Beta, und das LiteLLM-Team rechnet damit, dass Anfragen im Stil von Anthropic unter /v1/messages bis zum 1. Dezember vollständig in Rust verarbeitet werden – bei etwa 20-mal geringerer Latenz. Einige Open-Source-Plattformen wie MLflow und AcruxCore bieten bereits Gateway und Tracing in einem Produkt.

Warum es sinnvoll sein kann, sie getrennt zu halten

Die Integration des Gateways in den Tracer hat Nachteile; der größte davon ist die enge Kopplung. Bei einem separaten Gateway kann ein Team den Tracing-Anbieter wechseln, indem es einen Logging-Callback ändert. Ist der Tracer zugleich das Gateway, müssen auch die Basis-URL, die Schlüssel und die Modellkennungen aller Dienste geändert werden. Langfuse schreibt Modellkennungen beispielsweise im Format credential:model.

Der Tracer wird außerdem zu einer Laufzeitabhängigkeit. Fällt ein Tracing-Backend aus, verliert das Team seine Traces. Fällt ein Gateway aus, schlagen Modellaufrufe fehl. Ein Tracing-Anbieter, der das Gateway betreibt, muss nun die Verfügbarkeit kritischer Infrastruktur gewährleisten.

Auch Sicherheitsanbieter wollen an derselben Stelle im Anfragepfad sitzen. Palo Alto Networks hat die Übernahme von Portkey, einem eigenständigen Gateway, im Mai 2026 abgeschlossen und Portkey zum KI-Gateway seiner Prisma-AIRS-Plattform gemacht. Ein Sicherheitsteam möchte das Gateway möglicherweise lieber selbst kontrollieren, statt es in einem Observability-Tool zu betreiben. Gateways sind auch für Angreifer zu einem Ziel geworden, wie der Vorfall in der Lieferkette von LiteLLM im März zeigte.

So können Teams eine Entscheidung treffen

Teams können damit beginnen, aufzulisten, was vor einem Modellaufruf geschehen muss. Benötigen sie nur Einblick, genügt ein neben dem Anfragepfad laufender Tracer, der keine Laufzeitabhängigkeit mit sich bringt. Brauchen sie außerdem Budgets, Schlüsselrichtlinien oder eine Freigabe von Modellen, benötigen sie ein Gateway irgendeiner Art.

Als Nächstes sollten Teams die Anbieterabdeckung prüfen. Sie sollten alle Anbieter und API-Formate auflisten, die sie in der Produktion aufrufen – einschließlich Azure OpenAI und Bedrock – und diese Liste mit der derzeitigen Unterstützung der einzelnen Gateways abgleichen, nicht mit deren Roadmap.

Teams, die LiteLLM bereits einsetzen, haben wenig Grund zu wechseln, solange ein Beta-Gateway nichts bietet, was ihnen fehlt. Der wesentliche Vorteil eines Gateways im Tracer ist, dass ein Gateway-Aufruf im Agenten-Trace erscheint; dieser Vorteil muss einen Wechsel rechtfertigen. Teams, die neu anfangen, können das Gateway als eigene Ebene beibehalten, selbst wenn ein Anbieter beide Produkte bereitstellt. Sind Basis-URL und Schlüssel in einem Konfigurationsmodul hinterlegt, lässt sich später durch eine Konfigurationsänderung statt durch eine Codeänderung wechseln.

Die meisten dieser Gateways sind als Beta oder Vorschau gekennzeichnet, daher dürfte die Liste ihrer Schwächen schnell kürzer werden. Offen bleibt, wer in einem typischen Unternehmen den Anfragepfad kontrollieren wird: das Observability-Team, das Plattformteam, das ein eigenständiges Gateway betreibt, oder das Sicherheitsteam. In diesem Jahr haben LangSmith und Langfuse eigene Gateways entwickelt, und Palo Alto Networks hat eines gekauft. In vielen Technologie-Stacks läuft der Anfragepfad jedoch weiterhin über LiteLLM.