Foundation Model APIs auf Databricks: Wann sich eine zentrale LLM-Inferenz lohnt
Die Kernaussagen auf einen Blick.
- Foundation Model APIs stellen Sprachmodelle über verwaltete Endpoints in Databricks bereit. Abrechnung und Berechtigungen werden über die Databricks-Plattform verwaltet und können dem jeweiligen Endpoint zugeordnet werden.
- Die zentrale Entscheidung betrifft den künftigen Betriebsweg für LLM-Aufrufe. Abgewogen werden die Integration in Databricks, regionale Datenverarbeitung und zentrale Kostenkontrolle gegen eine möglicherweise größere Modellauswahl bei externen Anbietern.
- Für den Betrieb stehen mehrere Bereitstellungsmodelle mit unterschiedlichen Kosten- und Lastprofilen zur Verfügung. Eine nutzungsabhängige Abrechnung eignet sich häufig für den Einstieg und schwankende Lasten.
- Reservierte Kapazität kann sinnvoll werden, wenn das Anfragevolumen dauerhaft hoch und ausreichend planbar ist. Externe Modelle können über das Unity AI Gateway zentral eingebunden werden.
- Für interne LLM-Anwendungen sollte geprüft werden, ob Foundation Model APIs als bevorzugter Zugriffsweg geeignet sind.
- Spezialisierte oder proprietäre Modelle können ergänzend über External Models angebunden werden. Reservierte Kapazität sollte erst nach einer belastbaren Messung des tatsächlichen Lastprofils gewählt werden.
Inhaltsverzeichnis
Vier Teams, vier Modellzugänge, kein Überblick
Mehrere Fachbereiche nutzen eigene Verträge und Zugänge, ohne eine gemeinsame Sicht auf Kosten, Nutzung und Datenflüsse. Das Marketing verwendet einen eigenen Zugang für Textgenerierung. Der Support nutzt einen separaten Vertrag für Klassifikationsaufgaben. Ein Entwicklungsteam arbeitet mit weiteren Zugangsdaten. Parallel verwendet ein Vertriebsprojekt einen zusätzlichen Anbieterzugang. Bei einer späteren Compliance-Prüfung muss nachvollzogen werden, welche Daten in einem bestimmten Zeitraum an externe Anbieter übermittelt wurden. Ohne zentrale Protokollierung lässt sich diese Frage häufig nur unvollständig beantworten.
Dieses Muster tritt häufig auf, wenn erste LLM-Piloten in den regulären Betrieb übergehen. Jeder Fachbereich verwaltet eigene Verträge und Anbieterbeziehungen. Zugangsdaten werden getrennt gepflegt. Auch Protokollierung und Monitoring unterscheiden sich von Anwendung zu Anwendung. Was für einen ersten Test praktikabel war, führt mit wachsender Nutzung zu fehlenden gemeinsamen Standards.
Typische Fragen, die in dieser Konstellation auftreten:
Datenübermittlung
Es muss klar geregelt sein, welche Daten an welche Modellanbieter übermittelt werden dürfen.
Kostenzuordnung
Nutzungskosten müssen den jeweiligen Anwendungen, Teams und Kostenstellen zugeordnet werden können.
Wechselprozess
Für Preisänderungen oder die Einstellung einer Modellversion braucht es einen geregelten Wechselprozess.
PII-Erkennung
Es muss festgelegt sein, ob und wie personenbezogene Daten vor einem externen Aufruf erkannt und behandelt werden.
Modellvergleich
Modelle verschiedener Anbieter sollten mit denselben Testfällen und Qualitätskriterien verglichen werden können.
Mehrere getrennte Anbieterzugänge ergeben noch keine einheitliche Betriebs- und Governance-Architektur. Mit wachsender Nutzung wird deshalb eine gemeinsame Plattformentscheidung notwendig. Dabei muss festgelegt werden, wie Modellzugriff, Logging, Kosten und Berechtigungen künftig organisiert werden.
Was sind die Foundation Model APIs in Databricks?
Foundation Model APIs ermöglichen den verwalteten Zugriff auf Sprach- und Embedding-Modelle über Databricks. Anwendungen können Modelle nutzen, ohne selbst eine vollständige GPU- und Serving-Infrastruktur aufzubauen. Der Zugriff erfolgt über Model-Serving-Endpoints innerhalb der Databricks-Umgebung. Bereitstellung, Zugriff und Abrechnung sind in das Databricks-Serving-Modell integriert.
Für Anwendungen bedeutet das konkret: Die Anwendung ruft einen Databricks-Endpoint über eine einheitliche Schnittstelle auf. Der Endpoint kann auf ein von Databricks gehostetes Open-Weight-Modell verweisen. Alternativ kann für geeignete Workloads reservierte Kapazität eingesetzt werden. Auch externe Anbieter lassen sich über einen zentral verwalteten Proxy anbinden. Viele Endpoints können über eine OpenAI-kompatible Schnittstelle angesprochen werden. Nutzungs- und Abrechnungsdaten lassen sich über die Plattform auswerten. Zugriffe können mit den Identitäts- und Berechtigungsmechanismen der Databricks-Plattform gesteuert werden.
Für die Architektur ist entscheidend, was sich dadurch gegenüber einem direkten Anbieterzugang verändert. Foundation Model APIs sind mehr als lediglich eine alternative URL für Modellaufrufe. Sie verlagern Modellzugriff, Logging und Steuerung stärker in die Databricks-Plattform. Bei gehosteten Modellen kann die Verarbeitung innerhalb der vorgesehenen Databricks-Region erfolgen; die konkrete Datenresidenz sollte für Region und Modell geprüft werden. Modellzugriffe können in ein gemeinsames Identitäts- und Berechtigungskonzept eingebunden werden. Die Nutzung kann gemeinsam mit den übrigen Databricks-Kosten ausgewertet werden. Darin liegen sowohl der Integrationsvorteil als auch die stärkere Bindung an die Plattform. Die direkt verfügbare Modellauswahl ist kuratiert und kann kleiner sein als bei spezialisierten Modellplattformen. Auch die Kosten sollten anhand aktueller Preise und des konkreten Lastprofils verglichen werden.
Auf gleicher Ebene wie die Foundation Model APIs liegen die Stack-Geschwister Model Serving und Unity AI Gateway. Wie der gesamte Mosaic-AI-Stack auf Databricks aufgebaut ist, zeigen wir im Überblick zu Artificial Intelligence auf Databricks. Wie der Deployment-Layer für eigene Modelle funktioniert, klären wir im Überblick zu Model Serving auf Databricks. Wie die zentrale Governance- und Routing-Schicht für externe Modelle aussieht, zeigen wir im Überblick zu Unity AI Gateway auf Databricks.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Welche Modelle sind verfügbar?
Bei der Einführung stellt sich häufig zuerst die Frage nach den verfügbaren Modellen. Die Auswahl folgt jedoch einem anderen Prinzip als bei einem offenen Modellmarktplatz. Unterschieden wird zwischen direkt gehosteten Modellen und externen Modellen, die über einen Proxy eingebunden werden.
Für nutzungsabhängige Endpoints stellt Databricks eine ausgewählte Gruppe von Open-Weight- und Embedding-Modellen bereit. Welche Modellfamilien und Versionen aktuell unterstützt werden, sollte direkt in der Dokumentation oder im Workspace geprüft werden. Der Katalog wird regelmäßig verändert und erweitert. Für Architekturentscheidungen ist daher immer der aktuelle Stand in der eigenen Region maßgeblich.
External Models verwenden einen Databricks-Endpoint als zentralen Zugang zu externen Modellanbietern. Vertrag, Preise und Datenverarbeitung bleiben grundsätzlich an die Bedingungen des jeweiligen Anbieters gebunden. Zugangsdaten können zentral in der Databricks-Secret-Verwaltung hinterlegt werden. Die Anwendung selbst verwendet weiterhin eine einheitliche Databricks-Schnittstelle. Aus Anwendungssicht können sich gehostete und externe Modelle ähnlich ansprechen lassen. Modellspezifische Funktionen, Parameter und Antwortformate können sich dennoch unterscheiden.
| Kategorie | Bezugsmodus | Beispiele (Stand 2026) |
|---|---|---|
| Frontier-Chat- und Reasoning-Modelle | Pay-per-Token (gehostete Databricks-Endpoints) | OpenAI GPT-5.x, Anthropic Claude Sonnet 4.6 und Opus 4.7, Google Gemini 3 Pro |
| Open-Weight-Sprachmodelle | Pay-per-Token (gehostete Databricks-Endpoints) | Llama 4 Maverick, Llama 3.3 70B, Qwen 3.5, GPT OSS 120B, Gemma 3 |
| Embeddings | Pay-per-Token (gehostete Databricks-Endpoints) | GTE Large, BGE Large, Qwen3-Embedding |
| Externe Anbieter über Proxy | External Models (Unity AI Gateway) | jeder vertraglich gebundene Drittanbieter, etwa OpenAI, Anthropic, Google Vertex oder Cohere |
| Eigenes feingetuntes Modell | Reservierte Kapazität (Provisioned Throughput) | jedes via MLflow registrierte Foundation-Modell |
Die grundlegende Zuordnung lässt sich einfach strukturieren. Für unterstützte Open-Weight-Modelle mit schwankender Last bietet sich zunächst eine nutzungsabhängige Bereitstellung an. Spezialisierte proprietäre Modelle können über External Models zentral eingebunden werden. Eigene angepasste Modelle oder dauerhaft hohe Lasten können eine dedizierte Bereitstellung rechtfertigen.
Die drei Bereitstellungsmodelle
Hinter der einheitlichen Schnittstelle stehen verschiedene Betriebs- und Abrechnungsmodelle. Jedes Modell eignet sich für ein anderes Last- und Anforderungsprofil. Sie unterscheiden sich bei Planbarkeit, Kosten und Anbieterabhängigkeit. Die folgende Tabelle dient als kompakte Orientierung für die Architekturentscheidung.
| Bezugsmodus | Use Case | Abrechnung | Modell-Katalog | Latenz-Charakter |
|---|---|---|---|---|
| Pay-per-Token | Erste Use Cases, variable Token-Last, schnelle Iteration | pro Input-/Output-Token in DBUs | gehostete Open- und Frontier-Modelle (Llama 3.3 und 4, Qwen 3.5, GPT-5.x, Claude 4.x, Gemini 3) plus Embeddings (GTE, BGE) | geteilte Endpoints, gute Latenz bei niedriger Last |
| Reservierte Kapazität (Provisioned Throughput) | Produktiv-Workloads mit planbarer Token-Last | dedizierter Endpoint, planbarer DBU-Preis pro Stunde | gehostete Modelle und eigene MLflow-Modelle | dedizierte Kapazität, konstante Latenz |
| External Models | Vertraglich gebundene Drittanbieter oder spezialisierte Modelle außerhalb des Pay-per-Token-Katalogs | Provider-Preis plus Databricks-Overhead | beliebige externe Anbieter über Proxy, etwa eigene Verträge mit OpenAI, Anthropic, Cohere oder Azure OpenAI | abhängig vom Provider, plus Hop |
Für erste Anwendungsfälle ist eine nutzungsabhängige Abrechnung häufig der einfachste Einstieg. Es muss keine feste Kapazität reserviert werden, und Änderungen lassen sich schnell testen. Das passt besonders zu Pilotprojekten und Anwendungen mit noch unklarem Nutzungsprofil. Der Listenpreis pro 1 Million Tokens dokumentiert Databricks auf der Foundation Model Serving Pricing-Seite je nach Modell und Region.
Reservierte Kapazität wird interessant, wenn die Nutzung über einen längeren Zeitraum stabil und ausreichend hoch ist. Abgerechnet wird die bereitgestellte Kapazität statt ausschließlich der tatsächlich verarbeiteten Tokens. Bei hoher Auslastung können Kosten und Antwortzeiten dadurch besser planbar werden. Ungenutzte Kapazität verursacht jedoch weiterhin Kosten. Die Wirtschaftlichkeit hängt deshalb stark von der tatsächlichen Auslastung ab.
External Models verbinden die zentrale Databricks-Steuerung mit externen Modellanbietern. Ein Anthropic-Claude-Aufruf läuft beispielsweise über einen Databricks-Endpoint, der Schlüssel liegt in Databricks Secrets. Aufrufe können in ein einheitliches Logging- und Monitoringkonzept eingebunden werden. Dies ist ein geeigneter Weg, um externe Modelle in zentrale Berechtigungs-, Logging- und Routingprozesse aufzunehmen. Das Unity AI Gateway kann zusätzlich Routing, Nutzungslimits und weitere Richtlinien übernehmen.
Was kostet die Inferenz?
Die Kosten sollten früh und anhand eines realistischen Lastprofils betrachtet werden. Nutzungsabhängige Preise können über oder unter den Angeboten externer Anbieter liegen und ändern sich je nach Modell, Region und Vertrag. Pauschale Faktoren sollten durch einen aktuellen Preisvergleich ersetzt werden. Die jeweils aktuellen Listenpreise dokumentiert Databricks auf der Foundation Model Serving Pricing-Seite. Betrachtet man nur den Listenpreis pro Token, können externe Anbieter wirtschaftlicher erscheinen.
Für eine vollständige Bewertung müssen jedoch weitere Kosten- und Betriebsfaktoren einbezogen werden. Drei Punkte beeinflussen die Gesamtrechnung wesentlich.
Abrechnungsmodell-Wechsel
Bei dauerhaft hohem, gleichmäßigem Tokenvolumen kann reservierte Kapazität den Stückpreis senken. Bei geringem oder schwankendem Volumen bleibt Pay-per-Token meist flexibler.
Gemeinsame Kostenauswertung
Nutzungsdaten lassen sich über Systemtabellen und Endpoint-Metadaten auswerten, mit sauberem Tagging nach Anwendung, Zeitraum und Team.
Zusätzliche Betriebskosten
Direkte Anbieterzugänge brauchen eigene Vertragsverwaltung, Secrets, Logging und Kostenreporting, Aufwände, die ein reiner Tokenvergleich nicht zeigt.
Für frühe Projektphasen und unklare Lastprofile ist eine nutzungsabhängige Abrechnung häufig sinnvoll. Reservierte Kapazität sollte erst auf Basis stabiler Messdaten gewählt werden. External Models bleiben für Workloads sinnvoll, in denen das spezialisierte externe Modell die treibende Anforderung ist.
Wie greifen Berechtigungen und Unity AI Gateway?
Neben den Kosten ist Governance ein zentraler Grund für eine gemeinsame Inferenzplattform. Getrennte Anbieterzugänge führen häufig zu unterschiedlichen Authentifizierungs- und Berechtigungsmodellen. Auch Auditprotokolle und Datenschutzprüfungen sind dann nicht automatisch vereinheitlicht. Foundation Model APIs können diese Funktionen stärker in die Databricks-Plattform integrieren.
Drei Mechanismen sind dabei besonders relevant. Zugriffsrechte können für einzelne Serving-Endpoints vergeben werden. Endpoint- und Modellberechtigungen sollten mit den Databricks-Identitäten und den zugehörigen Modellobjekten abgestimmt werden. Die genaue Berechtigungsstruktur hängt von Endpoint, Workspace und Unity-Catalog-Konfiguration ab. Nicht autorisierte Aufrufe sollten klar abgelehnt und in den Zugriffsprotokollen sichtbar werden.
Zweitens können Inference Tables produktive Aufrufe protokollieren. Je nach Konfiguration werden Anfragen, Antworten, Modellversionen und weitere Metadaten gespeichert. Dabei muss bewusst festgelegt werden, welche Inhalte aus Datenschutz- und Speichergründen protokolliert werden dürfen. Microsoft Learn beschreibt das Inference-Tables-Modell als Standard-Audit-Quelle für Model Serving. Protokolle sollten in ein geregeltes Berechtigungs-, Aufbewahrungs- und Auditkonzept eingebunden sein. Innerhalb von Unity Catalog können sie für Evaluation, Monitoring und Prüfungen weiterverwendet werden.
Drittens ergänzt das Unity AI Gateway die einzelnen Modellendpoints um zentrale Steuerungsfunktionen. Das Gateway kann als gemeinsamer Zugang vor internen und externen Endpoints eingesetzt werden. Dort lassen sich unter anderem Nutzungslimits, Routing, Logging und Sicherheitsregeln umsetzen. Model Endpoints und Gateway erfüllen unterschiedliche, sich ergänzende Aufgaben. Sie sollten daher nicht als alternative Produkte betrachtet werden. Wie die Routing-, Logging- und Guardrails-Logik im Detail funktioniert, klären wir im Überblick zu Unity AI Gateway auf Databricks.
Wie nutzt man die APIs in RAG und Agenten?
RAG gehört zu den häufigsten Einsatzmustern für produktive LLM-Anwendungen. Ein Vektorindex stellt relevante Dokumentabschnitte bereit. Das Sprachmodell erzeugt auf Basis dieses Kontexts eine Antwort. MLflow und Inference Tables können Modellaufrufe und Evaluationen dokumentieren. Ein definiertes Testset sollte regelmäßig gegen die eingesetzten Modelle ausgeführt werden. Foundation Model APIs übernehmen in dieser Architektur den Modellzugriff für die Generierung.
Drei Integrationswege sind besonders verbreitet.
SQL via ai_query()
Ein Modellendpoint lässt sich direkt aus SQL aufrufen, etwa für eine Klassifikations-Spalte über 10.000 Tickets, ganz ohne separate Python-Anwendung.
Python-Anwendungen
Endpoints lassen sich über eine OpenAI-kompatible oder native Databricks-Schnittstelle ansprechen; wie austauschbar der Client ist, hängt von genutzten Modellfunktionen und Parametern ab.
Agentenarchitekturen
Der Endpoint wird als Modell- oder Werkzeugkomponente eingebunden, MLflow erfasst dabei Traces, Runs und Evaluationsinformationen.
Für produktive Anwendungen sollte Logging von Beginn an eingeplant werden. Inference Tables können produktive Aufrufe automatisiert dokumentieren. MLflow Tracing kann die einzelnen Schritte mehrstufiger Abläufe nachvollziehbar machen. Die Model Registry verwaltet Versionen und Freigabestände. Wie der Generations-Layer mit Retrieval, Re-Ranking und Eval-Loop zusammenspielt, zeigen wir im Überblick zu Retrieval Augmented Generation auf Databricks.
Antwortzeiten hängen von Modell, Last, Region und Bereitstellungsform ab. Geteilte nutzungsabhängige Endpoints können bei normaler Last ausreichend schnell sein. Die Latenz kann unter hoher oder schwankender Last stärker variieren. Reservierte Kapazität kann eine planbarere Leistung bieten. Die bereitgestellte Kapazität wird jedoch unabhängig von der tatsächlichen Nutzung berechnet. Für eine Klassifikations-Pipeline mit Batch-Charakter ist die Variation in der Regel weniger relevant, für einen synchronen Customer-Service-Bot kann sie entscheidend sein.
Regionale Verarbeitung und Compliance
Regionale Datenverarbeitung kann ein wichtiger Grund für die Nutzung gehosteter Modelle in Databricks sein. Bei Databricks-gehosteten Modellen sollte geprüft werden, in welcher Region die Inferenz tatsächlich verarbeitet wird. Ein EU-Workspace kann je nach Modell und Angebot eine Verarbeitung innerhalb der vorgesehenen Region ermöglichen; dies sollte vertraglich und technisch bestätigt werden. Microsoft Learn dokumentiert das Datenverarbeitungs-Modell für Databricks-gehostete Foundation-Modelle.
Für die Compliance ergeben sich daraus drei mögliche Vorteile.
Einfachere Datenschutzbewertung
Ein klar dokumentierter regionaler Datenfluss vereinfacht die Bewertung, sofern das gebuchte Angebot vertraglich zum LLM-Dienst passt.
Kein zusätzlicher Anbietervertrag
Bei gehosteten Modellen kann ein separater Vertrag mit einem externen Modellanbieter entfallen.
Branchenspezifische Vorgaben
Regional gehostete Modelle lassen sich oft leichter mit branchenspezifischen Compliance-Anforderungen vereinbaren.
Bei External Models findet die eigentliche Verarbeitung weiterhin beim externen Anbieter statt. Databricks kann Zugriff und Protokollierung zentralisieren. Datenresidenz und Verarbeitung richten sich jedoch nach dem jeweiligen Providervertrag.
Für sensible Workloads sollten gehostete und externe Modelle anhand konkreter Datenschutz- und Vertragsanforderungen verglichen werden. Externe Modelle können sinnvoll sein, wenn ihre fachlichen Vorteile die zusätzlichen Daten- und Vertragsanforderungen rechtfertigen.
Wann braucht es externe Anbieter oder eigenes Hosting?
Foundation Model APIs sind nicht automatisch für jeden Anwendungsfall die beste Wahl. Drei typische Situationen können für eine andere Lösung sprechen.
Frühere Feature-Verfügbarkeit
Neue Modellgenerationen stehen zuerst beim ursprünglichen Anbieter bereit, bevor sie in kuratierte Plattformkataloge aufgenommen werden. External Models oder ein direkter Anbieterzugang überbrücken diese Lücke.
Bestehende Enterprise-Verträge
Ausgehandelte Enterprise-Konditionen können bei hohen Volumina wirtschaftlich attraktiv bleiben. External Models legen die Plattform-Governance über den bestehenden Vertrag.
Eigenes GPU-Hosting
Teams mit vorhandener GPU-Infrastruktur und harten Latenzanforderungen können Self-Hosting prüfen, sofern ein dauerhaftes Betriebsmodell dahintersteht.
Wie Modell-Auswahl entlang Latenz, Domäne und Lizenz funktioniert, zeigen wir im Überblick zu Large Language Models auf Databricks.
Als allgemeine Orientierung kann gelten: Foundation Model APIs für unterstützte Modelle mit hohem Integrations- und Governance-Bedarf. External Models für proprietäre oder spezialisierte Modelle. Direkte Anbieterzugänge oder eigenes Hosting nur, wenn Qualität, Kosten oder Technik einen klaren Vorteil zeigen.
Was Foundation Model APIs nicht ersetzen
Foundation Model APIs stellen Modelle bereit, wählen sie aber nicht fachlich für den Anwendungsfall aus. Die Eignung eines Modells muss weiterhin separat bewertet werden. Modellauswahl, Lizenzprüfung und Evaluation erfolgen vor der produktiven Bereitstellung.
Die Auswahl richtet sich nach Aufgabe, Sprache, Domäne, Qualität, Latenz und Kosten. Es muss geprüft werden, ob ein Open-Weight- oder proprietäres Modell die Anforderungen besser erfüllt. Die Plattform stellt nur die technischen Zugriffswege bereit. Eine standardisierte Schnittstelle kann spätere Wechsel und Vergleiche erleichtern. Wie die Auswahl entlang Modell-Familien funktioniert, zeigen wir im Überblick zu Large Language Models auf Databricks.
Auch Databricks-eigene und selbst angepasste Modelle sollten nach denselben Kriterien bewertet werden. DBRX ist eine von Databricks veröffentlichte Modellfamilie. Ob DBRX für einen bestimmten Workload geeignet ist, sollte durch aktuelle, anwendungsspezifische Tests entschieden werden. Wie DBRX im Verhältnis zu anderen Foundation-Modellen positioniert ist, klären wir im Überblick zu DBRX auf Databricks.
Foundation Model APIs können Modellwechsel stärker in eine zentrale Endpoint- und Routingkonfiguration verlagern. Die Anwendung kann weitgehend unverändert bleiben, solange Schnittstelle und benötigte Modellfunktionen kompatibel sind. Der wesentliche Nutzen liegt damit in Standardisierung, Steuerung und Austauschbarkeit.
Grenzen
Foundation Model APIs sind keine universelle Lösung für alle LLM-Anforderungen. Ihr Nutzen hängt davon ab, ob die übrige Databricks-Integration für den jeweiligen Anwendungsfall relevant ist.
Kuratierter Modellkatalog
Die direkt verfügbaren Modelle bilden nur eine ausgewählte Teilmenge des Gesamtmarktes ab. Spezialisierte Modelle müssen gegebenenfalls selbst bereitgestellt oder über einen externen Endpoint integriert werden.
Pay-per-Token nicht immer günstigst
Der wirtschaftliche Nutzen muss aus Tokenpreis, Betriebsaufwand, Governance und Datenverarbeitung gemeinsam berechnet werden. Zählt nur der reine Modellpreis, können andere Anbieter günstiger sein.
Reservierte Kapazität nur bei Auslastung
Nicht ausgelastete Kapazität führt zu unnötigen laufenden Kosten. Vor der Entscheidung sollte ein ausreichend langer und repräsentativer Messzeitraum vorliegen.
External Models: Fremdverarbeitung
Daten werden entsprechend den Bedingungen des externen Anbieters verarbeitet. Für sensible Workloads muss geprüft werden, welche gehostete oder externe Variante die regulatorischen Anforderungen erfüllt.
Voller Nutzen nur mit Unity-Stack
Der volle Nutzen entsteht vor allem zusammen mit Unity Catalog, Unity AI Gateway, MLflow und Inference Tables. Ohne diese Integrationen lohnt der kritische Vergleich mit direkten Anbieterzugängen.
Foundation Model APIs ersetzen weder Modellauswahl noch Daten-, RAG- oder Evaluationsstrategie. Sie können eine bereits getroffene Entscheidung standardisiert bereitstellen und zentraler betreiben.
Fazit
Foundation Model APIs werden besonders relevant, wenn mehrere LLM-Anwendungen aus Pilotprojekten in einen gemeinsamen produktiven Betrieb überführt werden.
Ein einzelner Pilot kann zunächst auch über einen direkten Anbieterzugang umgesetzt werden. Mit mehreren Anwendungen werden Datenflüsse, Berechtigungen und Kosten jedoch zunehmend schwerer gemeinsam zu steuern. Spätestens bei einer Compliance- oder Auditprüfung wird eine zentrale Nachvollziehbarkeit erforderlich.
Der größte Integrationsvorteil entsteht, wenn Unity Catalog und Databricks bereits als zentrale Datenplattform genutzt werden. Auch mehrere parallel arbeitende Teams und Anwendungen sprechen für einen gemeinsamen Modellzugang. Kosten, Modellnutzung und Datenübermittlung können dann zentraler ausgewertet werden. Typische Hinweise auf fehlende gemeinsame Standards sind:
- Mehrere Anbieterzugänge ohne zentrale Kosten- und Nutzungsübersicht
- Unklare oder nur manuell rekonstruierbare Datenflüsse
- Modellvergleiche, die fest in einzelne Anwendungen eingebaut sind und nicht über wiederverwendbare Endpoints laufen.
Bei nur einem kleinen Pilotprojekt kann der Aufbau einer vollständigen Inferenzplattform noch zu früh sein. Mit weiteren produktiven Anwendungen steigt der Nutzen einer zentralen Lösung deutlich. Ohne bestehende Databricks-Daten- und Governance-Struktur fällt ein wesentlicher Vorteil weg.
Für interne Anwendungen sollte ein standardisierter Modellzugang über Foundation Model APIs geprüft und dokumentiert werden. Spezialisierte externe Modelle können ergänzend über External Models angebunden werden. Reservierte Kapazität sollte erst nach einer belastbaren Kosten- und Lastanalyse eingesetzt werden. Eine frühe Standardisierung ist meist deutlich einfacher als die spätere Migration zahlreicher unabhängig entwickelter Anwendungen.
Die Entscheidung für Foundation Model APIs betrifft nicht nur die Wahl eines Modells. Es geht darum, ob Modellzugriff, Kosten und Governance zentral über die Plattform gesteuert werden oder dauerhaft von einzelnen Fachbereichen und ihren jeweiligen Anbieterbeziehungen abhängen.
FAQ
Foundation Model APIs sind die verwaltete LLM-Inferenz-Schicht der Databricks-Plattform. Anwendungen rufen Modelle über Endpoints im eigenen Workspace auf, mit OpenAI-kompatiblem Protokoll, DBU-Abrechnung und Unity-Catalog-Berechtigungen. Die Inferenz läuft in der Region des Workspaces, gehostete Modelle wie Llama 3 oder DBRX kommen direkt aus dem Pay-per-Token-Katalog.
