Unity AI Gateway auf Databricks: Wie sich Modellzugriffe, Kosten und Governance zentral steuern lassen

Verschiedene Anwendungen greifen über getrennte Zugänge auf unterschiedliche Modellanbieter zu, während die Kosten nur als Gesamtsumme sichtbar werden. Die Nutzungskosten steigen mit der Zahl der Anwendungen. Ohne gemeinsame Metadaten lassen sie sich einzelnen Anwendungsfällen nur schwer zuordnen.

Dieses Muster tritt häufig auf, wenn mehrere GenAI-Anwendungen unabhängig voneinander produktiv betrieben werden. Verträge, Zugangsdaten und technische Integrationen werden dezentral verwaltet. Auch Logging, Monitoring und Kostenberichte entstehen mehrfach. Ein sinnvoller Pilotansatz führt dadurch später zu fehlenden gemeinsamen Standards.

Vor diesem Hintergrund stellen sich typischerweise mehrere Fragen:

Verteilte Anbieterzugänge sind nicht nur ein Kostenproblem. Sie zeigen fehlende Standards bei Zugriff, Logging, Governance und Verantwortlichkeit.

Die Architektur lässt sich grob in drei Ebenen unterteilen. Auf der untersten Ebene stehen eigene, gehostete oder externe Modelle. Model Serving und External Models stellen diese Modelle über aufrufbare Endpoints bereit. Der Gateway kann als gemeinsame Zugriffsebene vor diesen Endpoints liegen. Anwendungen adressieren einen zentral verwalteten Zugang. Dort können Limits, Protokollierung, Sicherheitsregeln und Routing umgesetzt werden.

Die Anwendung bleibt dadurch von den Zugangsdaten und der direkten Anbieterintegration entkoppelt. Die Auswahl des Zielmodells kann stärker über zentrale Konfiguration statt über fest verdrahteten Anwendungscode erfolgen. Das erleichtert spätere Modell- und Providerwechsel.

Auf gleicher Ebene wie der Gateway liegen die Stack-Geschwister Model Serving und Foundation Model APIs. Wie der gesamte Mosaic-AI-Stack auf Databricks aufgebaut ist und wo der Gateway darin sitzt, zeigen wir im Überblick zu Artificial Intelligence auf Databricks. Wie Foundation Model APIs gehostete Modelle bereitstellen, klären wir im Überblick zu Foundation Model APIs auf Databricks. Den Inference-Layer zeigen wir im Überblick zu Model Serving auf Databricks.

External Models stellen externe Modellanbieter über einen Databricks-Endpoint bereit. Die Anwendung kann dadurch stärker vom konkreten Anbieter entkoppelt werden. Welche Anbieter und Modellversionen unterstützt werden, hängt vom aktuellen Produktstand und der jeweiligen Region ab. Ein Providerwechsel kann häufig über Endpoint- und Routingkonfiguration erfolgen, sofern Schnittstelle und genutzte Funktionen kompatibel sind.

Zugangsdaten können zentral gespeichert und vom Anwendungscode getrennt werden. Ein Teil der Anbieterabhängigkeit verschiebt sich damit von der Anwendung in die Plattformkonfiguration. Teams, die eine Anwendung über Foundation Model APIs entwickeln und später feststellen, dass ein externes Modell besser passt, können in vielen Fällen die Endpoint-Konfiguration anpassen.

Externe Anwendungen benötigen weiterhin eine sichere Netzwerk- und Identitätsverbindung zum Databricks-Endpoint. Die Reichweite des Gateway hängt deshalb wesentlich von der vorhandenen Netzwerk- und Anwendungsarchitektur ab.

Die Kosten einer stark gekoppelten Architektur werden häufig erst beim ersten Provider- oder Modellwechsel sichtbar. Direkte SDK- und Anbieterabhängigkeiten führen dann zu Änderungen in mehreren Anwendungen.

Mit einem standardisierten Gateway kann ein Teil dieser Änderung zentral erfolgen. Das Zielmodell kann über Endpoint- oder Routingkonfiguration angepasst werden. Eine vollständig codefreie Umstellung ist jedoch nur möglich, wenn Funktionen, Parameter und Antwortformate kompatibel bleiben.

Über den zentralen Zugang lassen sich weitere Muster umsetzen:

Der Nutzen ist am größten, wenn Anwendungen von Beginn an über den zentralen Zugang entwickelt werden. Eine spätere Einführung erfordert häufig die Anpassung bestehender Clients, Authentifizierung und Konfigurationen.

Eine klare Trennung nach Anwendungsfall erleichtert Routing, Berechtigungen und Kostenanalyse. Ein gemeinsamer Endpoint für viele unabhängige Anwendungen begrenzt die Möglichkeit, Regeln gezielt pro Use Case anzuwenden.

Mit der Umbenennung von Mosaic AI Gateway zu Unity AI Gateway hat Databricks den Funktionsumfang über reine Modellaufrufe hinaus erweitert. Neben Sprachmodellen lassen sich auch Agenten, MCP-Server und deren Tools über dieselbe Schicht erfassen und steuern. Ein Teil dieser Funktionen ist je nach Region und Release noch in Preview und sollte vor produktiven Zusagen anhand der aktuellen Dokumentation geprüft werden.

Sobald Agenten eigenständig weitere Systeme aufrufen, reicht ein reiner Modellkatalog nicht mehr aus. Ein zentraler Katalog erfasst auch AI-Services, Agenten, MCP-Server und die von ihnen genutzten Tools als verwaltete Objekte in Unity Catalog. Damit bleibt nachvollziehbar:

Ohne ein solches Inventar verteilt sich eine wachsende Agentenlandschaft auf einzelne Repositories und Zugänge. Spätestens bei Sicherheitsprüfungen und Audits wird dann unklar, welche Agenten existieren und worauf sie zugreifen.

Ein Gateway, das nur Aufrufe weiterleitet, legt nicht fest, was ein Agent tatsächlich tun darf. Identitätsbezogene Richtlinien setzen genau hier an: Sie bestimmen pro Identität (Nutzer, Service-Principal oder Agent), welche Modelle, Daten und Tools verwendet werden dürfen und welche Aktionen zulässig sind.

Weil diese Richtlinien an Databricks-Identitäten und Unity Catalog hängen, gelten dieselben Berechtigungen wie für die übrigen Plattformobjekte. Ein Agent erhält dadurch nicht mehr Rechte als die Identität, unter der er läuft. Die Richtlinie bleibt eine technische Leitplanke. Welche Aktion in einem Geschäftsprozess erlaubt ist, muss weiterhin fachlich entschieden werden.

Für Agenten genügt das Logging einzelner Modellaufrufe nicht. Entscheidend ist der gesamte Ablauf: welche Tools ein Agent in welcher Reihenfolge aufgerufen hat, welche Eingaben und Ausgaben dabei entstanden sind und wie viele Token jeder Schritt verbraucht hat.

Unity AI Gateway kann diese Schritte als Traces erfassen. Die Daten landen in von Unity Catalog verwalteten Inference-Tabellen und folgen denselben Berechtigungs- und Aufbewahrungsregeln wie andere Tabellen. Darauf lassen sich Auswertungen und Alarme aufsetzen, etwa über Lakewatch für Nutzung, Fehlerraten und auffällige Tool-Aktivität. Welche Felder pro Aufruf gespeichert werden, hängt von Konfiguration, Datenschutzregeln und Aufbewahrungskonzept ab.

Guardrails greifen nicht nur auf einen einzelnen Prompt und die zugehörige Antwort. Sie lassen sich über die gesamte Interaktion eines Agenten legen, also auch über Zwischenschritte und Tool-Aufrufe. Neben den eingebauten Detektoren und selbst definierten Regeln können auch Guardrails von Drittanbietern eingebunden werden. So bleiben Sicherheits- und Compliance-Regeln wirksam, unabhängig davon, ob eine Antwort direkt vom Modell oder über mehrere Agentenschritte entsteht.

Wie die Modell-Auswahl entlang dieser Achsen funktioniert, zeigen wir im Überblick zu Large Language Models auf Databricks.

Der Gateway setzt diese Entscheidungen technisch um und macht spätere Änderungen einfacher. Die Anwendung kann weitgehend entkoppelt bleiben, sofern die verwendeten Modellfunktionen kompatibel sind. Der zentrale Nutzen liegt in Standardisierung, Steuerbarkeit und besserer Austauschbarkeit.