Model Serving auf Databricks: Welche Endpoint-Architektur sich für produktive Inferenz eignet
Die Kernaussagen auf einen Blick.
- Databricks Model Serving stellt Modelle aus der Databricks-Plattform für produktive Anfragen bereit. Über REST-Endpunkte lassen sich klassische ML-Modelle, Foundation Models, eigene Sprachmodelle und externe Modelle aufrufen. Die verschiedenen Bereitstellungsformen unterscheiden sich deutlich bei Kosten, Skalierung und Antwortzeit.
- Eine der wichtigsten Entscheidungen ist die Wahl der passenden Endpoint-Klasse für den jeweiligen Workload: Zur Auswahl stehen Custom Model Serving, Foundation Model APIs (Pay-per-Token oder Provisioned Throughput) und External Models.
- Scale-to-Zero reduziert Kosten in Phasen ohne Last, führt beim nächsten Aufruf jedoch zu einer zusätzlichen Startzeit. Reservierter Durchsatz bietet planbarere Leistung, verursacht aber auch bei geringer Nutzung laufende Kosten.
- Für jeden Anwendungsfall sollte die Endpoint-Klasse anhand von Lastprofil, Latenzanforderung und Kostenmodell ausgewählt werden. Das Unity AI Gateway sollte bei produktiven GenAI-Anwendungen frühzeitig für Routing, Richtlinien und zentrale Kontrolle eingeplant werden. Inference Tables sollten bei produktiven Endpoints von Beginn an berücksichtigt werden.
Inhaltsverzeichnis
Der Endpoint entscheidet über Kosten, Latenz und Audit
Mehrere Modelle werden produktiv genutzt, ohne dass klar dokumentiert ist, welche Anwendungen und Teams darauf zugreifen. Ein Forecast-Modell läuft beispielsweise in einem selbst verwalteten Container auf AKS, dessen Aufbau und Betrieb nur unvollständig dokumentiert sind. Ein GenAI-Prototyp greift möglicherweise direkt aus einer Anwendung auf einen externen Modellanbieter zu. Die Zugangsdaten liegen dabei im ungünstigsten Fall in einer lokalen Konfiguration statt in einer zentralen Secret-Verwaltung. Ein weiterer Endpoint wird mit dauerhaft reservierter Kapazität betrieben, obwohl die Nutzung stark von der Tageszeit abhängt. In den Nachtstunden wird die bereitgestellte Kapazität kaum genutzt.
Die Auswirkungen werden häufig erst bei der monatlichen Kostenanalyse sichtbar. Die Inferenzkosten steigen, lassen sich aber nicht eindeutig einzelnen Anwendungsfällen oder Teams zuordnen. Bei einer Prüfung kann nicht nachvollzogen werden, welche Eingaben in einem bestimmten Zeitraum an externe Modellanbieter übermittelt wurden. Der erste Aufruf eines Chatbots am Morgen dauert unerwartet lange oder läuft in ein Timeout. Der Grund ist, dass der Endpoint während der Nacht vollständig heruntergefahren wurde. Beim erneuten Start muss das Modell zunächst geladen werden, bevor eine Antwort möglich ist.
Kostenzuordnung
Jedem Team und Anwendungsfall müssen die verursachten Inferenzkosten eindeutig zugeordnet werden können.
Modellversion nachvollziehen
Für jede produktive Antwort muss die verwendete Modellversion erkennbar sein.
Kritische Abhängigkeiten kennen
Welche Endpoints oder externen Anbieter eine kritische Abhängigkeit darstellen, muss bekannt sein.
Externe Aufrufe protokollieren
Alle Aufrufe an externe Modellanbieter sollten zentral protokolliert und überprüfbar sein.
Wer Model Serving nur als letzten technischen Deployment-Schritt betrachtet, übersieht die Auswirkungen auf Betrieb, Kosten und Governance. Die Architektur der Endpoints beeinflusst Startzeiten, Kosten, Rollout-Verfahren und die Nachvollziehbarkeit zwischen Modellversion und Antwort. Ohne einheitliche Regeln entstehen schwer zuzuordnende Kosten und eine Modelllandschaft, die sich nur eingeschränkt prüfen und betreiben lässt.
Was ist Databricks Model Serving?
Databricks Model Serving stellt trainierte Modelle für produktive Echtzeitanfragen bereit. Die Plattform kann Modelle aus der an Unity Catalog angebundenen Model Registry laden. Anschließend werden sie über HTTPS-Endpunkte zugänglich gemacht. Anwendungen können diese Endpunkte über REST oder eine OpenAI-kompatible Schnittstelle ansprechen. Die zugrunde liegende Rechenleistung wird von Databricks verwaltet. Die Anzahl der laufenden Instanzen kann automatisch an die Last angepasst werden. Berechtigungen und Herkunftsinformationen lassen sich in die Governance von Unity Catalog integrieren.
Jeder Endpoint kann seine bereitgestellte Kapazität automatisch an das aktuelle Anfragevolumen anpassen. Eine Replica entspricht einer aktiven Instanz des Modells. Die konfigurierte Parallelität legt fest, wie viele Anfragen eine Instanz gleichzeitig verarbeitet. Zusätzlich können Inference Tables aktiviert werden. Anfragen und Antworten werden dann in einer Delta-Tabelle protokolliert. Je nach Konfiguration enthält sie Eingabe, Ausgabe, Modellversion, Zeitstempel und weitere Nutzungsmetriken. Dadurch können Evaluation und Audit auf denselben Plattformdaten aufbauen wie die Modellbereitstellung. Ein separates Logging-System ist dafür nicht zwingend erforderlich.
Die Rolle innerhalb der Architektur ist klar definiert. Model Serving übernimmt die Bereitstellung von Modellen, die zuvor in Databricks oder außerhalb trainiert wurden. Die gewünschte Modellversion wird aus der Registry geladen und über einen Endpoint verfügbar gemacht. Für zentrale Richtlinien, Routing und Providersteuerung kann das Unity AI Gateway vor diesen Endpoints eingesetzt werden. Wie das Trainings- und Registry-Modell darunter aufgebaut ist, zeigen wir im Überblick zu Artificial Intelligence auf Databricks.
Die Pipeline verläuft in drei Stufen: MLflow Models verpackt das trainierte Artefakt aus beliebigen Frameworks (scikit-learn, XGBoost, PyTorch, TensorFlow, Keras, Custom) in ein einheitliches Modell-Format mit Flavors für unterschiedliche Deployment-Optionen. Die MLflow Model Registry verwaltet anschließend den Lifecycle in den Stufen Staging, Production und Archived: versionierte Einträge wandern über einen Promote-Schritt von Staging nach Production, ältere Versionen rutschen nach Archived. Databricks Model Serving stellt zuletzt die aktive Version aus der Registry als REST-Endpunkt bereit, den nachgelagerte Anwendungen, Reports und weitere Consumer ansprechen.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Welche Endpoint-Typen gibt es?
Die verschiedenen Endpoint-Arten lassen sich über ähnliche Schnittstellen ansprechen. Sie unterscheiden sich jedoch bei Modellherkunft, Infrastruktur, Skalierung und Abrechnung. Grundsätzlich lassen sich drei Klassen unterscheiden.
Custom Model Serving stellt selbst trainierte oder angepasste Modelle aus der Model Registry bereit. Dazu gehören Modelle, die das eigene Team trainiert, feinabgestimmt oder als benutzerdefiniertes MLflow-Modell verpackt hat. Typische Beispiele sind klassische ML-Modelle (sklearn, XGBoost, PyTorch), eigene Sprachmodelle und benutzerdefinierte Modellpakete. Je nach Modell kann CPU- oder GPU-Compute eingesetzt werden. Bei geeigneten Workloads kann der Endpoint in Phasen ohne Nutzung vollständig herunterskalieren. Diese Variante eignet sich für Modelle, deren Training und Artefakte selbst verwaltet werden.
Foundation Model APIs stellen von Databricks gehostete Foundation Models bereit (Llama, Mistral, DBRX, weitere). Das Team muss dafür keine eigene Modellinfrastruktur betreiben. Für die Nutzung stehen unterschiedliche Abrechnungs- und Kapazitätsmodelle zur Verfügung. Beim nutzungsabhängigen Modell (Pay-per-Token) wird nach verarbeiteten Eingabe- und Ausgabetokens abgerechnet. Es muss keine feste Kapazität im Voraus reserviert werden. Das eignet sich besonders für schwankende Nutzung, frühe Projektphasen und kleinere Volumina. Provisioned Throughput reserviert eine definierte Verarbeitungskapazität. Dafür wird dem Anwendungsfall feste Rechenkapazität zugewiesen. Die Leistung ist dadurch besser planbar und wird weniger von gemeinsam genutzter Kapazität beeinflusst.
External Models binden proprietäre Modelle externer Anbieter über einen Databricks-Endpoint ein (OpenAI, Anthropic, Google, AWS Bedrock, Azure OpenAI). Die Anwendung kommuniziert weiterhin nur mit einer Databricks-Schnittstelle. Zugangsdaten für den Anbieter werden zentral und getrennt vom Anwendungscode verwaltet. Aufrufe können dadurch einheitlich protokolliert und kontrolliert werden. Diese Variante ist sinnvoll, wenn ein proprietäres Modell nicht selbst gehostet werden kann oder soll. Sie bietet sich außerdem an, wenn der externe Dienst die benötigte Qualität oder Betriebsleistung bereits bereitstellt.
| Endpoint-Klasse | Latenz-Klasse | Cold Start | Kosten-Charakter | Use Case |
|---|---|---|---|---|
| Custom Model (CPU) | 50–300 ms p95 | bei Scale-to-Zero ja | DBU pro Replica-Stunde | klassisches ML, Custom-Container |
| Custom Model (GPU) | 100–500 ms p95 | bei Scale-to-Zero ja | DBU pro GPU-Replica-Stunde | eigene LLMs, große Modelle |
| Foundation Pay-per-Token | 200–800 ms p95 | nein | pro Input-/Output-Token | unregelmäßige Last, GenAI-Prototypen |
| Foundation Provisioned | 100–400 ms p95 | nein | pro reservierter Kapazität rund um die Uhr | hohe Dauer-Last, garantierte Latenz |
| External Model | 300–1500 ms p95 | nein | Provider-Tarif + Databricks-Gebühr | proprietäre Modelle (GPT-4, Claude, Gemini) |
Die angegebenen Werte dienen lediglich als grobe Orientierung. Tatsächliche Startzeiten, Latenzen und Preise hängen von Modell, Region, Cloud und aktueller Plattformkonfiguration ab. Vor einer produktiven Entscheidung sollten deshalb aktuelle Messwerte und Preisangaben herangezogen werden.
Wie skalieren die Endpoints?
Die Skalierung wird vor allem über drei Parameter gesteuert. Min Replicas bestimmt, wie viele Instanzen mindestens aktiv bleiben. Max Replicas begrenzt die maximale Anzahl gleichzeitig laufender Instanzen. Die Concurrency legt fest, wie viele Anfragen eine einzelne Instanz parallel verarbeitet. Mit einer Mindestanzahl von null kann ein Endpoint bei längerer Inaktivität vollständig heruntergefahren werden. Nach einer Phase ohne Anfragen werden keine aktiven Instanzen mehr vorgehalten. Beim nächsten Aufruf wird die benötigte Kapazität erneut gestartet.
Der wichtigste Vorteil von Scale-to-Zero sind geringere Kosten in ungenutzten Zeiten. Bei einem Endpoint, der nur während eines Teils des Tages genutzt wird, muss nicht rund um die Uhr eine Instanz aktiv bleiben. Scale-to-Zero eignet sich unter anderem für interne Anwendungen, Tests und selten genutzte Inferenzprozesse. Dafür entsteht beim erneuten Hochfahren eine zusätzliche Wartezeit.
Mit mindestens einer Replica bleibt das Modell dauerhaft geladen und unmittelbar ansprechbar. Dadurch entfällt die Startverzögerung nach längeren Phasen ohne Nutzung. Diese Konfiguration eignet sich für kundennahe oder anderweitig zeitkritische Anwendungen, latenzkritische Empfehlungs-Modelle oder Use Cases mit unregelmäßiger, aber zeitkritischer Last. Als erste Orientierung kann das Last- und Latenzprofil herangezogen werden.
Scale-to-Zero wählen, wenn
- Das Anfragevolumen gering und unregelmäßig ist
- Eine Cold-Start-Verzögerung beim ersten Aufruf tolerierbar ist
- Interne Anwendungen, Tests oder selten genutzte Inferenzprozesse betroffen sind
Dauerhafte Replicas oder reservierten Durchsatz wählen, wenn
- Verbindliche, sehr niedrige Latenzanforderungen gelten
- Kundennahe oder anderweitig zeitkritische Anwendungen betroffen sind
- Latenzkritische Empfehlungs-Modelle mit harter Zusage laufen
Wann sich die Engine-Trennung für Online-Features und Echtzeit-Inferenz lohnt, klären wir im Überblick zu Real-Time-ML auf Databricks.
Die Parallelität pro Replica wird bei der Optimierung häufig zu wenig berücksichtigt. Standardwerte sind häufig vorsichtig gewählt. Bei kleinen und schnellen Modellen kann dadurch mehr Kapazität bereitgestellt werden als notwendig. Eine höhere Parallelität kann die benötigte Zahl aktiver Instanzen reduzieren. Das kann Kosten senken und vorhandene CPU- oder GPU-Ressourcen besser auslasten.
Wann sind Cold Starts vertretbar?
Als Cold Start wird die zusätzliche Zeit bezeichnet, die ein heruntergefahrener Endpoint bis zur ersten Antwort benötigt. Dazu gehören das Starten der Laufzeit, das Laden des Modells und gegebenenfalls erste Initialisierungsschritte. Bei klassischen Modellen kann die Startzeit je nach Paketgröße und Laufzeit wenige Sekunden betragen. Bei großen Sprachmodellen auf GPUs kann das Laden deutlich länger dauern. Die tatsächliche Dauer muss für das konkrete Modell und die jeweilige Region gemessen werden.
Ob eine Startverzögerung akzeptabel ist, hängt vor allem von der Art der Nutzung ab. Bei Batch-Prozessen fällt eine einmalige Startzeit meist kaum ins Gewicht. Interne interaktive Anwendungen können eine gelegentliche Verzögerung akzeptieren, sofern sie transparent behandelt wird. Bei kundenbezogenen Echtzeitanwendungen kann ein Cold Start dagegen die Nutzererfahrung oder technische SLAs verletzen.
Für zeitkritische Anwendungen kommen mehrere Betriebsmodelle infrage.
Dauerhaft laufende Replica
Mindestens eine Replica hält das Modell geladen. Kurze Antwortzeiten, aber laufende Kosten auch in ungenutzten Phasen.
Reservierter Durchsatz
Besser planbare Leistung für hohe und gleichmäßige Lasten. Die reservierte Kapazität wird unabhängig von der tatsächlichen Nutzung berechnet.
Warm-up-Aufrufe
Regelmäßige Test-Aufrufe halten einen Endpoint zeitweise aktiv. Muss selbst geplant, überwacht und an das Lastprofil angepasst werden.
Eine Kombination aus Scale-to-Zero und gezielten Warm-up-Aufrufen kann bei zeitlich begrenzter Nutzung sinnvoll sein. Sie sollte jedoch nur nach einer Prüfung des realen Nutzungsprofils eingesetzt werden. Ein dauerhaft reservierter Endpoint mit geringer durchschnittlicher Auslastung kann unnötig hohe laufende Kosten verursachen. Bei klaren Geschäftszeiten kann eine bedarfsgerechtere Skalierung wirtschaftlicher sein, sofern die benötigte Antwortzeit weiterhin eingehalten wird.
Mehrere Modelle über einen Endpoint
Ein Model-Serving-Endpoint kann mehrere bereitgestellte Modelle oder Modellversionen enthalten. Databricks bezeichnet diese bereitgestellten Einheiten als Served Entities. Mehrere Versionen können über dieselbe Endpoint-Adresse angesprochen werden. Die Anwendung muss die interne Verteilung nicht selbst verwalten. Das ermöglicht insbesondere drei Einsatzmuster.
Für A/B-Tests kann der eingehende Traffic prozentual auf mehrere Modelle verteilt werden. Ein größerer Anteil kann beispielsweise an die bestehende Version und ein kleinerer an eine neue Version gehen (etwa 80 zu 20 Prozent). Inference Tables dokumentieren, welche Version die jeweilige Anfrage verarbeitet hat. Anschließend können Qualität, Kosten und Antwortzeit beider Varianten verglichen werden. Erfüllt die neue Version die definierten Anforderungen, kann ihr Traffic-Anteil schrittweise erhöht werden. Bei schlechteren Ergebnissen lässt sich der Anteil wieder reduzieren. Für die aufrufende Anwendung bleibt die Schnittstelle unverändert.
Canary-Rollouts führen eine neue Version zunächst nur für einen kleinen Teil der Anfragen ein. Fünf oder zehn Prozent gehen auf die neue Version, der Rest bleibt auf der alten. Bleiben technische und fachliche Kennzahlen im erwarteten Bereich, kann der Anteil kontrolliert erhöht werden. Bei Problemen lässt sich der Traffic kurzfristig wieder vollständig auf die bisherige Version lenken. Dieses Vorgehen eignet sich besonders für sensible Modelländerungen in kundenbezogenen Anwendungen.
Ein weiteres Einsatzmuster ist die Auswahl unterschiedlicher Modelle je nach Anfrage. Einfache Aufgaben können an ein kleineres und günstigeres Modell geleitet werden. Komplexere Anfragen können ein leistungsfähigeres Modell verwenden. Die Entscheidung kann innerhalb der Serving-Konfiguration oder in einer vorgeschalteten Routing-Komponente getroffen werden. Wie diese vorgelagerte Schicht aussieht, klären wir im Überblick zu Unity AI Gateway auf Databricks.
Für eine klare Kosten- und Verantwortungszuordnung ist ein eigener Endpoint pro Anwendungsfall häufig sinnvoll. Ein gemeinsamer Endpoint für viele unabhängige Anwendungen erschwert dagegen Tests, Berechtigungen und Kostenzuordnung.
Was übernimmt das Unity AI Gateway?
Model Serving übernimmt die technische Bereitstellung der Modelle. Das Unity AI Gateway kann als zentrale Zugriffsebene vor den Modellendpoints eingesetzt werden. Dort lassen sich unter anderem Kontingente, Rate Limits, Protokollierung, Datenschutzprüfungen und Provider-Routing zentral steuern. Model Serving und Unity AI Gateway erfüllen unterschiedliche Aufgaben. Zusammen ermöglichen sie einen kontrollierteren Betrieb produktiver KI-Anwendungen.
Ohne vorgeschaltetes Gateway kommuniziert jede Anwendung unmittelbar mit dem jeweiligen Modellendpoint. Protokollierung und Richtlinien müssen dann für jeden Endpoint separat eingerichtet werden. Ein Wechsel des Modells kann Anpassungen an der Endpoint-Konfiguration oder in der Anwendung erfordern. Bei wenigen Endpoints bleibt dieses Vorgehen noch überschaubar. Mit wachsender Zahl von Anwendungen, Modellen und Anbietern steigt der Verwaltungsaufwand jedoch deutlich. Ohne zentrale Verwaltung können sich Zugangsdaten auf mehrere Anwendungen und Teams verteilen. Die verursachten Kosten lassen sich dann nur mit zusätzlichem Aufwand einzelnen Anwendungsfällen zuordnen. Auch Datenschutzprüfungen werden mehrfach implementiert oder bleiben uneinheitlich.
Mit einem Gateway können alle Modellaufrufe über einen zentralen Einstiegspunkt geführt werden. Die Anwendung adressiert das Gateway, während die Zuordnung zum eigentlichen Modell zentral konfiguriert wird. Ein Modell- oder Providerwechsel kann dadurch häufig ohne Änderung am Anwendungscode erfolgen. Datenschutzregeln und Guardrails lassen sich an einer Stelle definieren und überwachen. Nutzung und Tokenverbrauch können mit Anwendungsfall, Team oder Kostenstelle verknüpft werden.
Der geeignete Zeitpunkt für die Einführung hängt von der Größe der Modelllandschaft ab.
Gateway einführen, wenn
- Mehrere Anwendungen, Modelle oder Anbieter zentral gesteuert werden sollen
- Kosten und Zugangsdaten team- und anwendungsübergreifend zugeordnet werden müssen
- Datenschutzregeln und Guardrails einheitlich durchgesetzt werden sollen
Ohne Gateway vertretbar, wenn
- Ein einzelner, klar abgegrenzter Endpoint betrieben wird
- Protokollierung und Richtlinien pro Endpoint noch überschaubar bleiben
Eine nachträgliche Einführung erfordert häufig Anpassungen an bestehenden Anwendungen und Zugangspfaden. Eine frühe Berücksichtigung reduziert diese späteren Umstellungen.
Inference Tables für Eval und Audit
Inference Tables verbinden die produktive Nutzung eines Modells mit nachgelagerten Qualitäts- und Auditprozessen. Modellanfragen und -antworten können als Datensätze in einer Delta-Tabelle in Unity Catalog gespeichert werden. Die Tabelle enthält Input, Output, Modell-Version, Caller-Identität, Token-Verbrauch, Latenz und Zeitstempel. Damit können Zugriffsrechte, Aufbewahrung und Datenherkunft mit den bestehenden Unity-Catalog-Mechanismen verwaltet werden.
Besonders relevant sind drei Anwendungsbereiche.
Evaluationspipelines
Neue Modellversionen gegen reale historische Anfragen prüfen, ergänzt synthetische Testdaten, ersetzt aber kein kuratiertes Goldset.
Drift-Erkennung
Veränderungen in Art und Verteilung der Eingaben über Zeit analysieren. Ändern sich Themen oder Nutzergruppen, leidet oft die Modellqualität.
Audit & Nachvollziehbarkeit
Produktive Entscheidungen per Abfrage rekonstruieren, je nach Risikoklasse und Regulierung eine Pflichtanforderung.
Die Nutzung von Inference Tables erfordert klare Betriebs- und Datenschutzregeln. Aufbewahrungsfristen, Zugriffsrechte und Speicherkosten sollten vor der Aktivierung festgelegt werden. Bei personenbezogenen oder vertraulichen Eingaben muss geprüft werden, welche Inhalte gespeichert, maskiert oder ausgeschlossen werden. Ohne ein solches Konzept kann die Protokollierung selbst zu einem Datenschutz- und Governance-Risiko werden.
Wie verbindet man Model Serving und Model Registry?
Ein Endpoint stellt eine bestimmte Modellversion oder eine logisch benannte Modellrolle aus der Model Registry bereit. Die Registry ist in Unity Catalog integriert. Jede Modellversion kann mit Berechtigungen, Herkunftsinformationen und Metadaten verwaltet werden. Ein neuer Trainingslauf kann das Ergebnis als weitere Modellversion registrieren. Wie diese Verbindung im Detail funktioniert, zeigen wir im Überblick zu Mosaic AI Model Registry.
Der Rollout sollte über klar definierte Aliases oder andere versionierte Freigabemechanismen gesteuert werden. Ein Endpoint kann auf eine feste Version oder auf einen Alias wie @champion verweisen.
Kandidat kennzeichnen und testen
Eine neue Modellversion wird registriert und als Kandidat gegen definierte Testfälle geprüft, bevor sie produktiv geschaltet wird.
Alias auf neue Version setzen
Nach erfolgreicher Freigabe wird der produktive Alias (etwa @champion) auf die neue Version umgehängt. Die Modelladresse des Endpoints bleibt unverändert.
Rollback bei Bedarf
Bei Problemen zeigt der produktive Alias wieder auf die zuvor freigegebene Version, ohne Änderung an der aufrufenden Anwendung.
Voraussetzung ist ein verbindlicher Freigabeprozess für Aliases und Modellversionen. Direkt eingetragene Versionsnummern sollten nur eingesetzt werden, wenn genau diese feste Bindung gewünscht ist.
Inference Tables ergänzen diese Versionierung um Daten aus dem produktiven Betrieb. Für jede protokollierte Anfrage kann die verwendete Modellversion festgehalten werden. Neue Versionen lassen sich damit gezielt gegen reale Nutzungsmuster prüfen. Synthetische und kuratierte Testsets können dadurch sinnvoll ergänzt werden.
Was kostet Model Serving?
Das Abrechnungsmodell hängt von der gewählten Endpoint-Klasse ab. Grundsätzlich lassen sich drei Kostenarten unterscheiden. Bei Custom Model Serving entstehen Kosten für die Laufzeit der aktiven CPU- oder GPU-Replicas. Foundation Model APIs können nutzungsabhängig nach Ein- und Ausgabetokens abgerechnet werden. Bei reserviertem Durchsatz wird die bereitgestellte Kapazität unabhängig von der tatsächlichen Nutzung berechnet. Bei External Models können sowohl Kosten des externen Anbieters als auch Gebühren für die Databricks-Integration anfallen.
Eine belastbare Kostenzuordnung setzt eine klare Endpoint-Struktur und einheitliche Tags voraus. Ein eigener Endpoint pro Anwendungsfall erleichtert die Zuordnung zu Team, Kostenstelle und Produkt. Dazu sollten standardisierte Tags für Verantwortlichkeit, Kostenstelle und Anwendungsart gepflegt werden. Systemtabellen können die abgerechnete Nutzung für Auswertungen bereitstellen. Darauf aufbauend lässt sich ein Kosten-Dashboard je Anwendungsfall erstellen. Werden mehrere unabhängige Anwendungen über denselben Endpoint betrieben, wird eine eindeutige Kostenzuordnung deutlich schwieriger.
Konkrete DBU- und Token-Preise stehen auf der Databricks-Preisseite und sind je nach Region, Cloud-Anbieter und aktuellem Pricing-Stand zu prüfen. Für eine realistische Kostenschätzung ist je Anwendungsfall ein Lastprofil erforderlich. Dazu gehören Anfragevolumen, Tokenmengen, Tagesverteilung und gewünschte Antwortzeit. Pauschale Annahmen ohne reale Lastdaten führen häufig schon im ersten Betriebsmonat zu deutlichen Abweichungen.
Netzwerk, Sicherheit und Governance
Model-Serving-Endpoints werden über HTTPS aufgerufen und benötigen eine authentifizierte Identität.
Service Principals statt Personal Token
Technische Identitäten für App-zu-Endpoint-Kommunikation, nicht an den Lebenszyklus einzelner Mitarbeiter gebunden, mit gezielt vergebenen Rechten.
Private Link für Netzwerkpfade
Zugriff auf private Cloud- oder Unternehmensverbindungen beschränken. Ausgehende Netzwerkregeln legen fest, welche externen Dienste ein Endpoint erreichen darf.
Berechtigungen über Unity Catalog
Modell- und Datenrechte aufeinander abgestimmt vergeben. Ohne Verknüpfung von Trainingslauf und Datenquelle bleibt ein Endpoint nur eingeschränkt auditierbar.
Audit-Trail über Inference Tables
Jede Anfrage einer authentifizierten Identität zuordnen und per Abfrage auswerten, bei External Models inklusive verarbeitendem Anbieter.
Wann ist Model Serving die falsche Wahl?
Databricks Model Serving ist nicht für jeden Inferenz-Workload automatisch die beste Wahl. Drei typische Situationen können für eine Alternative sprechen.
Keine produktive Databricks-Plattform
Ohne Unity Catalog, Model Registry und Lineage im Bestand fehlt der zentrale Integrationsvorteil: bestehende Kubernetes-, SageMaker- oder Vertex-AI-Strukturen sind oft wirtschaftlicher.
Sehr spezielle Compute- oder Provider-Anforderungen
Spezialisierte Beschleuniger, individuelle Laufzeiten oder extrem niedrige Latenzanforderungen sprechen eher für selbst betriebene Runtimes wie vLLM oder TGI.
Edge-Inferenz oder Embedded-Use-Case
Modelle auf mobilen Geräten, Sensoren oder Edge-Systemen brauchen eine lokale Laufzeit, etwa ONNX Runtime oder TensorFlow Lite statt eines zentralen Cloud-Endpoints.
Eine Migration zu Databricks Model Serving ist besonders sinnvoll, wenn mehrere Voraussetzungen zusammenkommen. Trainings- und Inferenzdaten werden bereits in Databricks verwaltet. Die Zahl produktiver Modelle steigt und benötigt eine einheitliche Betriebsplattform. Audit, Kostenkontrolle, Berechtigungen und Datenschutz gewinnen an Bedeutung. Fehlen diese Vorteile, kann die Migration mehr Aufwand verursachen als der bestehende Betrieb.
Die Migration lässt sich schrittweise durchführen. Zunächst wird das Modell in der Model Registry registriert. Anschließend kann ein neuer Endpoint parallel zur bisherigen Bereitstellung eingerichtet werden. Ein Teil des Traffics wird kontrolliert auf den neuen Endpoint umgeleitet. Protokollierte Anfragen ermöglichen den Vergleich von Antwortzeit und Ergebnisqualität. Solange die bisherige Lösung verfügbar bleibt, kann bei Problemen zurückgeschaltet werden.
Grenzen
Databricks Model Serving deckt viele Inferenzszenarien ab, hat aber klare Grenzen. Wer Anforderungen und Betriebsmodell nicht passend auswählt, verlagert bestehende Probleme lediglich auf eine neue Plattform.
Scale-to-Zero ohne Startverzögerung
Vollständiges Herunterskalieren und sofortige Antwort ohne Ladezeit schließen sich aus. Latenzkritische Use Cases brauchen Min Replicas größer null oder reservierten Durchsatz.
Reservierte Kapazität passt sich nicht an
Die reservierte Leistung wird für den vereinbarten Zeitraum dauerhaft vorgehalten und abgerechnet: geringe Nutzung senkt die Kosten nicht automatisch.
Custom-Pakete erhöhen die Komplexität
Paketgröße, Startzeit, Speicherbedarf und Abhängigkeiten müssen selbst verwaltet werden. Große Pakete verlängern bei Scale-to-Zero besonders die Startzeit.
Regionale Foundation-Model-Verfügbarkeit
Nicht jedes gewünschte Modell steht in jeder Region und Bereitstellungsklasse zur Verfügung, vor Projektbeginn konkret prüfen.
Externe Anbieter bleiben eine Abhängigkeit
Bei External Models wirken sich Störungen oder hohe Latenzen des Anbieters unmittelbar auf den Endpoint aus. Fallback- und Routing-Regeln lassen sich im Unity AI Gateway zentral absichern.
Auch eine verwaltete Plattform ersetzt keine Analyse von Last, Latenz, Verfügbarkeit und Kosten. Sie erleichtert jedoch Messung, Steuerung und spätere Anpassungen.
Fazit
Databricks Model Serving ist eine zentrale Betriebsentscheidung für produktive ML- und GenAI-Anwendungen.
Endpoint-Klasse, Skalierung und Routing beeinflussen gemeinsam Antwortzeit, Kosten, Rollouts und Nachvollziehbarkeit. Wird die Endpoint-Architektur als Teil der Plattform geplant, lassen sich Betrieb und Kosten einheitlich steuern. Wird sie nur als technische Bereitstellung betrachtet, entstehen schnell unklare Kosten und schwer nachvollziehbare Modellabhängigkeiten.
Drei Anzeichen deuten auf eine ungeeignete Endpoint-Struktur hin. Die Inferenzkosten steigen, können aber keinem Anwendungsfall eindeutig zugeordnet werden. Prompts, aufgerufene Modelle und erzeugte Antworten lassen sich für Prüfungen nicht vollständig rekonstruieren. Der erste Aufruf nach längerer Inaktivität überschreitet regelmäßig die erwartete Antwortzeit.
Drei Maßnahmen verbessern die Situation. Die Endpoint-Klasse sollte für jeden Anwendungsfall anhand des tatsächlichen Last- und Latenzprofils ausgewählt werden: Selten genutzte klassische Modelle können beispielsweise mit Custom Model Serving und bedarfsgerechter Skalierung betrieben werden. Für frühe GenAI-Anwendungen mit schwankender Nutzung kann eine tokenbasierte Abrechnung sinnvoll sein. Bei zeitkritischen Anwendungen sollten dauerhaft aktive Kapazitäten oder reservierter Durchsatz geprüft werden. Proprietäre Modelle lassen sich über External Models zentral anbinden. Das Unity AI Gateway sollte frühzeitig eingeplant werden, sobald mehrere Modelle, Anbieter oder zentrale Richtlinien absehbar sind. Für produktive Endpoints sollte eine geeignete Protokollierung über Inference Tables vorgesehen werden.
Vor der nächsten produktiven Bereitstellung sollten Endpoint-Klasse, Lastprofil, Latenzanforderung und Kostenmodell je Anwendungsfall dokumentiert werden. Für eine wachsende Modelllandschaft sollte ein zentraler Gateway-Ansatz als Standard geprüft werden. Logging, Aufbewahrung und Berechtigungen für Inference Tables sollten von Beginn an mitgeplant werden. Eine frühe Festlegung verursacht überschaubaren Aufwand, während die nachträgliche Bereinigung einer gewachsenen Endpoint-Landschaft deutlich komplexer ist.
Die technische Bereitstellung eines Modells ist in der Regel nicht die eigentliche Herausforderung. Entscheidend ist, ob die Endpoint-Architektur dauerhaft zum Nutzungsprofil passt. Kosten sollten eindeutig zugeordnet, Antwortzeiten realistisch geplant und verwendete Modellversionen zuverlässig nachvollzogen werden können.
FAQ
Databricks Model Serving ist die produktive Inferenz-Schicht des Lakehouse. Sie stellt Modelle aus dem Unity-Catalog-gebundenen Model Registry als HTTPS-Endpoints bereit, die über REST oder OpenAI-kompatible Aufrufe erreichbar sind. Die Endpoints laufen auf serverloser Compute, skalieren automatisch und sind in dieselbe Berechtigungs- und Lineage-Logik eingebunden wie alle anderen Unity-Catalog-Objekte.
