Foundation Model APIs: Definition, Modi, Abgrenzung

Foundation Model APIs sind das Databricks-Angebot, mit dem eine Anwendung große vortrainierte KI-Modelle wie GPT, Claude, Gemini, Llama, Mistral oder DBRX über einen einheitlichen Endpoint im Databricks-Arbeitsbereich (Workspace) aufruft. Die Abrechnung läuft entweder pro verbrauchtem Token (Pay-per-Token) oder über reservierte Kapazität mit garantierter Latenz (Provisioned Throughput); Berechtigungen, Kosten und Audit-Spuren landen in Unity Catalog.

Was sind Foundation Model APIs?

Foundation Model APIs bündeln den Zugriff auf große KI-Modelle in einem einzigen Aufruf-Format. Für jedes Modell einen eigenen Anbieter-Vertrag, einen eigenen API-Schlüssel und einen eigenen Abrechnungs-Kanal aufzubauen, entfällt: die Anwendung im Databricks-Arbeitsbereich ruft einen Endpoint auf (die feste Adresse eines Modells) und bekommt die Antwort zurück. Ob das Modell dahinter GPT von OpenAI, Claude von Anthropic, Gemini von Google, ein offenes Llama-Modell von Meta, ein Mistral-Modell oder das von Databricks selbst trainierte DBRX ist, sieht der Aufrufer nicht. Der Zugangsweg bleibt gleich. Die APIs sprechen ein OpenAI-kompatibles Format für Chat und Text-Vervollständigung, dazu ein Databricks-eigenes SDK.

Der Baustein hat sich als eigene Kategorie etabliert, weil produktive LLM-Anwendungen im Betrieb an denselben Anforderungen scheitern wie andere Datenprodukte: Zugangsdaten müssen sicher verwaltet, Nutzung muss abgerechnet, Zugriffe müssen nachvollziehbar protokolliert werden. Ein direkter Aufruf an einen externen Anbieter läuft an all dem vorbei; jeder API-Schlüssel, jede Kostenrechnung und jede Audit-Spur entsteht dann außerhalb der Data-Intelligence-Plattform. Foundation Model APIs holen diese Aufrufe in denselben Governance-, Abrechnungs- und Audit-Kreis wie Tabellen, Notebooks und Jobs. Berechtigungen laufen über Unity Catalog, Verbrauch landet in den System Tables unter system.serving.*, und ein davorgeschalteter [Unity AI Gateway](/insights/databricks/artificial-intelligence/unity-ai-gateway/) ergänzt Rate-Limits, Content-Filter und semantisches Caching.

Betrieblich unterscheiden Foundation Model APIs zwei Modelle. Pay-per-Token nutzt geteilte Kapazität und rechnet pro Input- und Output-Token ab, ohne Kapazitäts-Commitment; ideal für Entwicklung, Prototyping und unregelmäßige Nutzung. Provisioned Throughput reserviert dedizierte Rechenkapazität für einen Endpoint mit garantierten Token pro Sekunde und planbaren Kosten pro DBU-Stunde. Der Provisioned-Modus ist der Standardweg für produktive Workloads, für feingetunte Modelle und für Anwendungsfälle mit Latenz-Zusagen. Externe Anbieter-Modelle werden über das Konzept „External Models" an dieselbe Endpoint-Familie angeschlossen, sodass Aufrufer aus Sicht der Anwendung keinen Unterschied zwischen einem intern gehosteten und einem via Databricks vermittelten Modell sehen.

Abgrenzung zu Foundation Models, Model Serving, AI Gateway und Provider-APIs

Der Begriff wird häufig mit angrenzenden Bausteinen vermischt. Die relevanten Trennlinien:

Nachbar-Begriff	Verhältnis zu Foundation Model APIs
Foundation Models	Die Modell-Klasse selbst (GPT, Claude, Llama, DBRX). Foundation Model APIs sind der Databricks-Bezugsweg zu genau diesen Modellen: Modelle sind das Training, die APIs sind der Inferenz-Zugang.
Model Serving	Die generische Databricks-Plattform, auf der Foundation Model APIs laufen. Model Serving hostet beliebige Modelle (klassisches ML, Deep Learning, LLMs); Foundation Model APIs sind der spezialisierte Zweig für vortrainierte LLMs mit fertigen Endpoints und Provider-Anbindung.
Unity AI Gateway	Die Governance-/Kontrollschicht vor den Endpoints, mit Rate-Limits, PII-Filter, semantischem Caching und einheitlichem Audit-Trail. Foundation Model APIs liefern die Modell-Inferenz, der Gateway steuert Zugriff und Absicherung darauf.
Provider-eigene APIs (OpenAI, Anthropic direkt)	Direkter Aufruf an api.openai.com oder Anthropic mit separatem Account, separater Kostenrechnung, ohne Unity-Catalog-Zugriff, ohne System-Tables-Auswertung. Foundation Model APIs bündeln denselben Modell-Zugang in der Databricks-Rechnung und Governance.
Mosaic AI Training	Trainiert oder feintuned Foundation Models mit Continued Pretraining und Instruction Tuning. Foundation Model APIs sind die Konsum-Seite; ein trainiertes oder feingetuntes Modell landet später als Provisioned-Throughput-Endpoint.

[Foundation Models](/insights/glossar/foundation-models/) sind die zugrunde liegende Modell-Klasse: großmaßstäblich vortrainierte, aufgaben-offene Modelle. Foundation Model APIs sind kein Modell und keine eigene Modell-Familie, sondern der API-Zugriff auf diese Modelle innerhalb des Databricks-Kontexts. Ein Modell wie GPT-4 oder Llama 3 existiert unabhängig; die Foundation Model APIs sind die Verpackung, in der es im Databricks-Workspace zugänglich wird.

Das darunterliegende [Model Serving](/insights/glossar/model-serving/) ist die generische Serving-Plattform von Databricks. Sie hostet auch klassische ML-Modelle aus MLflow-Registry-Läufen, Deep-Learning-Modelle und selbst-trainierte LLMs mit eigenen Gewichten. Foundation Model APIs sind der spezialisierte Endpoint-Typ innerhalb dieser Plattform, in dem vortrainierte Foundation Models mit fertigem Aufruf-Schema und ohne eigenes Deployment bereitstehen. Model Serving ist die Ebene, Foundation Model APIs sind ein Produkt auf dieser Ebene.

Ein [AI Gateway](/insights/glossar/ai-gateway/), bei Databricks als Unity AI Gateway realisiert, sitzt eine Schicht darüber. Der Gateway kennt kein Modell und keine Gewichte, arbeitet nur auf der Ebene der Aufrufe: er prüft Token, wendet Rate-Limits und Content-Filter an, schreibt einen strukturierten Audit-Trail und leitet die Anfrage an den Endpoint weiter. Foundation Model APIs sind der Endpoint, den der Gateway aufruft. Beide Bausteine ergänzen einander: ohne Gateway laufen die APIs ohne zentrale Kontrolle, ohne die APIs hat der Gateway nichts, worauf er zeigen kann.

Provider-eigene APIs (OpenAI, Anthropic, Google Vertex AI im Direktaufruf) liefern dieselben Modelle, allerdings außerhalb des Databricks-Kontexts. Zugangsdaten, Kosten und Audit-Spuren entstehen dort in separaten Systemen. Foundation Model APIs binden dieselben Anbieter über das Konzept „External Models" ein, sodass die Aufrufe im Databricks-Governance-Kreis bleiben und über System Tables abgerechnet werden können.

[Mosaic AI Training](/insights/glossar/mosaic-ai-training/) schließlich ist die Trainings-Seite: Continued Pretraining, Fine-Tuning und Instruction Tuning eines Foundation Models auf eigenen Daten. Das Ergebnis dieser Trainings-Pipeline wird typischerweise wieder als Foundation-Model-APIs-Endpoint im Provisioned-Throughput-Modus bereitgestellt. Training und Inferenz sind zwei getrennte Bausteine, die über den Endpoint zusammenlaufen.

Beispiel: interner Chat-Assistent mit Wechsel von Pay-per-Token zu Provisioned Throughput

Ein Team baut auf Databricks einen internen Wissens-Assistenten. In der Entwicklungs-Phase greift die Anwendung auf einen Pay-per-Token-Endpoint zu, konkret etwa databricks-meta-llama-3-1-70b-instruct oder databricks-claude-sonnet-4. Kein Provisioning, keine Kapazitäts-Reservierung, Kosten fallen pro verarbeitetem Token an. Das passt zu unregelmäßiger Entwickler-Nutzung, in der Endpoints stundenweise idle bleiben.

Für den Rollout an einige tausend Mitarbeiter wechselt der produktive Endpoint auf Provisioned Throughput. Die Kapazität wird in Token pro Sekunde reserviert, Latenz und Kosten werden über die DBU-Rate planbar. Der Verbrauch landet in system.serving.endpoint_usage und lässt sich pro Anwendung und Kostenstelle auswerten. Berechtigungen für den Endpoint laufen über Unity Catalog; nur Gruppen mit expliziter Zuweisung dürfen den Chat-Endpoint aufrufen.

Ein vorgeschalteter Unity AI Gateway übernimmt die Rate-Limits pro Team, einen PII-Filter auf den Prompts und das strukturierte Prompt-/Antwort-Logging in ein Audit-Log. Die aufrufende Anwendung selbst ändert sich beim Wechsel von Entwicklung auf Produktion nicht; nur der Endpoint-Name und das Betriebsmodell darunter sind andere. Später kommt ein mit [Mosaic AI Training](/insights/glossar/mosaic-ai-training/) auf firmeneigenen Handbüchern feingetuntes Llama-Modell hinzu; es läuft ebenfalls als Provisioned-Throughput-Endpoint hinter derselben Foundation-Model-APIs-Adresse und wird über eine Routing-Regel am Gateway für bestimmte Anfrage-Typen bevorzugt.