Databricks Mosaic AI: Welche KI-Bausteine dazugehören und wann sie sinnvoll sind
Die Kernaussagen auf einen Blick.
- Databricks Mosaic AI ist kein einzelnes Produkt, sondern der Sammelbegriff für mehrere KI- und ML-Bausteine in Databricks: Foundation Model APIs, Model Serving, Vector Search, MLflow, AI Gateway, Agent Bricks, Agent Framework, Training, Evaluation und Monitoring.
- Der größte Vorteil entsteht, wenn Daten, Modelle, Prompts, Suche, Bewertung und Modellaufrufe auf derselben Plattform zusammenlaufen und über Unity Catalog, MLflow und das Unity AI Gateway nachvollziehbar verwaltet werden.
- Vor dem produktiven Einsatz sollten drei Dinge geklärt sein: Unity Catalog ist als Governance-Schicht eingerichtet, Modelle und Versionen werden über MLflow verwaltet und die Kosten je Baustein sind verstanden (Token, DBUs oder im Workspace enthalten).
- Mein Vorschlag: Mosaic AI je Anwendungsfall prüfen, welche Bausteine gebraucht werden und ob Databricks gegenüber Bedrock, Azure OpenAI, Vertex AI, Snowflake Cortex oder spezialisierten Anbietern wirklich einfacher, günstiger oder besser kontrollierbar ist.
Inhaltsverzeichnis
Mosaic AI ist mehr als ein Modell-Endpoint
In vielen Architekturgesprächen passiert dasselbe. Mosaic AI wird schnell als wichtiger Teil der Databricks-Entscheidung genannt. Produktfolien zeigen viele KI-Bausteine rund um das Lakehouse. In Preisübersichten tauchen gleichzeitig Tokens, DBUs und enthaltene Workspace-Funktionen auf, deren Zuordnung nicht immer unmittelbar verständlich ist. Daraus soll dann eine belastbare GenAI-Planung entstehen.
Sobald es konkreter wird, entstehen schnell offene Fragen. Es ist nicht immer geklärt, welche Komponenten produktiv verfügbar sind und welche noch Preview sind. Auch die Kosten der einzelnen Dienste sind häufig noch nicht sauber getrennt. Zusätzlich fehlen klare Aussagen zu den technischen Voraussetzungen für den produktiven Einsatz. So lässt sich Mosaic AI kaum fair mit Bedrock, Azure OpenAI oder Vertex AI vergleichen.
Drei Fragen stehen in jedem dieser Gespräche im Raum:
Welche Dienste sind im gewählten Databricks-Angebot wirklich enthalten? Welche Bausteine braucht der erste Anwendungsfall wirklich und welche können zunächst unberücksichtigt bleiben? Bringt der Databricks-Ansatz gegenüber einem Cloud-Provider-Setup wirklich einen messbaren Vorteil, oder sprechen Kosten, Modellangebot und regionale Verfügbarkeit eher für einen spezialisierten Anbieter?
Werden diese Fragen nicht vor dem nächsten Pilot geklärt, entstehen schnell parallele Kosten und Lücken bei Nachvollziehbarkeit, Logging und Verantwortung. Solche Lücken können spätere Governance- und Auditaufwände deutlich erhöhen.
Was ist Databricks Mosaic AI?
Mosaic AI ist der Sammelbegriff für verschiedene KI- und ML-Funktionen in Databricks. Dazu gehören Bausteine für klassisches Machine Learning, generative KI, Modellbetrieb und Governance. Die Funktionen sind einzelne Dienste innerhalb des Databricks Workspace. Jeder Baustein hat eigene Voraussetzungen, Verfügbarkeit und Kostenlogik. Mosaic AI ist keine eigene Plattform neben Databricks.
Der Name kommt aus der MosaicML-Übernahme durch Databricks im Jahr 2023 (Pressemitteilung). Mit der Übernahme kamen unter anderem Trainingswerkzeuge, Modelltechnologie und das MosaicML-Team zu Databricks. Diese Technologien wurden mit bestehenden Databricks-Diensten wie MLflow, Model Serving und Feature Engineering integriert. Später kamen weitere Bausteine wie Foundation Model APIs, Unity AI Gateway, Vector Search und Agentenwerkzeuge hinzu. DBRX machte das KI-Angebot von Databricks zusätzlich sichtbarer (DBRX-Veröffentlichung).
Die Bausteine lassen sich grob in drei Gruppen einteilen: Modelle und Modellzugänge, Bereitstellung und Inferenz sowie Entwicklung, Evaluation, Monitoring und Governance. Diese Einteilung hilft, Nutzen, Reifegrad und Kosten sauber zu trennen.
Mosaic AI ist der Generative-AI- und ML-Teil: eingebettet in den breiteren Databricks-AI-Stack.
Agent-Entwicklung, Serving und Gateway bilden den Mosaic-AI-Kern; klassisches Machine Learning und AI-powered Analytics laufen als eigene Säulen daneben.
- Agent Bricks (auto-optimierte Agents)
- Agent Framework (Custom Agents, RAG)
- Vector Search (serverlose Vektor-DB)
- Model Serving (250.000+ QPS)
- AI Gateway (Multi-Provider, Guardrails)
- MLflow 3.0 (Tracing, Evaluation, Registry)
- AutoML (Feature-Eng., Hyperparameter)
- Distributed Training (Ray, DeepSpeed)
- AI Runtime (TensorFlow, PyTorch, GPU)
- Feature Store (Unity Catalog)
- Models in Unity Catalog (Registry)
- MLOps Workflows (Lakeflow Jobs)
- AI/BI Genie (natürliche Sprache → SQL)
- AI/BI Dashboards (3.000+ Kunden)
- Databricks One (unified Portal, GA)
- AI Functions (3x schneller, 4x günstiger)
- ai_parse_document (multimodal)
- Metric Views (zentrale KPI-Definitionen)
Databricks positioniert Mosaic AI als Plattform für KI-Anwendungen aus mehreren Bausteinen (Compound AI Systems im Sinne der Berkeley-BAIR-Definition von 2024). Produktive GenAI-Anwendungen bestehen fast nie nur aus einem Modellendpoint. Deshalb besteht Mosaic AI aus mehreren Diensten, die je nach Anwendungsfall kombiniert werden. Einzelne Modelle und Bausteine können je nach Bedarf ausgetauscht werden. Unity Catalog, MLflow und das Unity AI Gateway schaffen dabei eine gemeinsame Verwaltung von Berechtigungen, Modellen und Nachvollziehbarkeit.
Wichtig ist: Mosaic AI ist nicht ein einzelnes Lizenzprodukt mit einem einheitlichen Preis, kein dauerhaft feststehender Funktionsumfang und keine unveränderliche Liste unterstützter Modelle. Neue Bausteine und Modelle kommen hinzu, Verfügbarkeitsstufen ändern sich und Abrechnungsmodelle können angepasst werden. Als festes Lizenzpaket lässt sich Mosaic AI deshalb schlecht bewerten. Sinnvoller ist: jeden Baustein einzeln nach Nutzen, Reifegrad, Verfügbarkeit und Kosten prüfen.
Wie diese Bausteine in den breiteren Databricks-Hub eingebettet sind, klären wir im Databricks-Überblick.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Welche Mosaic-AI-Komponente braucht man wofür?
Eine Übersicht hilft dabei, die Bausteine nach Funktion und Einsatzgebiet einzuordnen. Für die Entscheidung sind vor allem drei Fragen wichtig: Abrechnung, technische Voraussetzungen und vergleichbare Angebote bei anderen Anbietern. Diese Informationen bilden die Grundlage für eine realistische Kosten- und Architekturentscheidung.
| Komponente | Wofür es genutzt wird | Abrechnung | Voraussetzung | Vergleichbare Angebote |
|---|---|---|---|---|
| Foundation Model APIs | Modellendpoints mit Abrechnung pro Token für Llama, Claude, GPT, Mistral, DBRX | Pay-per-Token | Workspace mit aktivierter Region | Bedrock, Vertex Model Garden, Azure OpenAI |
| Mosaic AI Model Serving | Betrieb eigener Modelle und Fine-Tunes | DBU (provisioned/serverless) | MLflow-Registry, Unity Catalog | SageMaker Endpoints, Vertex Endpoints |
| Unity AI Gateway | Routing, Limits, Logging und Schutzregeln vor Modellaufrufen | inkludiert im Serving-Tarif | Workspace-Tier Premium oder Enterprise | LiteLLM, Portkey, AWS Bedrock Guardrails |
| Mosaic AI Vector Search | Vektorindex in Unity Catalog, der sich mit Delta-Tabellen synchronisieren kann | DBU (Compute-Endpoint) | Unity Catalog Pflicht | OpenSearch Vector, Pinecone, Vertex Vector Search |
| Agent Bricks | vorgefertigte Agent-Bausteine für typische Anwendungsfälle | DBU (Preview) | Unity Catalog, Vector Search | Bedrock Agents, Vertex AI Agent Builder |
| Mosaic AI Agent Framework | Framework für eigene Agents mit Tool-Calling und MCP-Anbindung | DBU (Serving + Compute) | MLflow, Unity Catalog | LangChain, Strands, Agent SDK |
| Mosaic AI Tool Catalog | zentrale Registry für SQL-, Python-, Endpoint- und Retriever-Funktionen; nativ ins Function-Calling im Model Serving verdrahtet | DBU (Aufruf-Compute) | Unity Catalog | Bedrock Agents Action Groups, Vertex Extensions |
| Mosaic AI Agent Evaluation (Quality Lab) | LLM-gestützte Bewertung von Antworten mit kuratierten Metriken plus UI für menschliches Reviewer-Feedback | DBU (Eval-Compute) | MLflow Tracking | LangSmith, Braintrust, Vertex Eval |
| Mosaic AI Playground | Oberfläche zum Vergleichen von Modellen und Prompts | im Workspace inkludiert | Workspace-Zugriff | Bedrock Playground, Vertex Studio |
| Managed MLflow | Tracking, Registry, Prompts und Deployments | inkludiert | Unity Catalog (für UC-Registry) | SageMaker Experiments, Vertex Experiments |
| Mosaic AI Training | Managed Training, Fine-Tuning und Weitertraining | DBU (GPU-Compute) | Storage-Setup, Quota | SageMaker Training, Vertex Training |
| Feature Store | Feature-Tabellen und Online-Zugriffe für klassische ML-Anwendungen | DBU (Online-Store) | Unity Catalog | SageMaker Feature Store, Vertex Feature Store |
| Lakehouse Monitoring | Monitoring für Datenqualität, Drift, Modelle und Antworten | DBU (Monitoring-Compute) | Unity Catalog | SageMaker Model Monitor, Vertex Model Monitoring |
Was kostet Mosaic AI?
Die Kosten lassen sich grob in drei Arten aufteilen. Bei Foundation Model APIs wird je nach Modell nach Input- und Output-Tokens abgerechnet (Foundation Model Serving Pricing). Die Preise hängen von Modellfamilie und Anbieter ab und sollten anhand der aktuellen Preisliste verglichen werden. Bei dauerhaft hoher und gleichmäßiger Nutzung kann reservierte Kapazität günstiger oder besser planbar sein und damit eine DBU-basierte Abrechnung sinnvoller machen.
Viele rechenintensive Dienste werden über DBUs abgerechnet. Das betrifft vor allem Bausteine, die eigene Rechenressourcen für Serving, Suche, Training, Evaluation oder Monitoring bereitstellen. Die tatsächlichen Kosten hängen von Cloud, Region, Workspace-Tier und eingesetzter Rechenleistung ab. Für produktive KI-Anwendungen werden häufig Funktionen benötigt, die erst in höheren Workspace-Angeboten verfügbar sind. Ein Enterprise-Angebot kann bei erweiterten Netzwerk-, Sicherheits- und Governance-Anforderungen erforderlich sein.
Für die Kostensteuerung müssen alle Kosten eines Anwendungsfalls zusammen betrachtet werden. Je nach Architektur entstehen Kosten für Datenverarbeitung, Vektorsuche, Modellaufrufe, Evaluation und Monitoring. Eine FinOps-Auswertung sollte diese Kostenblöcke getrennt erfassen und dem jeweiligen Anwendungsfall zuordnen. Eine reine Gesamtsumme hilft dafür wenig. Wie der Unity AI Gateway dabei als zentraler Logging- und Routing-Punkt wirkt, vertiefen wir im Unity AI Gateway.
Pay-per-Token
Foundation Model APIs werden nach Input- und Output-Tokens abgerechnet, je nach Modellfamilie und Anbieter.
DBU-Abrechnung
Model Serving, Vector Search, Agent Framework, Training, Evaluation und Monitoring laufen über DBUs, abhängig von Cloud, Region und Workspace-Tier.
Im Workspace-Tier inkludiert
Playground und Teile der Eval-Funktionen sind je nach Tier (Standard, Premium, Enterprise) bereits enthalten.
Routing, Logging, Schutzregeln und Kostenkontrolle für Modellaufrufe
Je mehr produktive KI-Anwendungen entstehen, desto wichtiger wird das Unity AI Gateway. Der Bedarf entsteht vor allem dann, wenn mehrere Anwendungen unterschiedliche Modelle nutzen. Markttrends allein reichen dafür aber nicht als Entscheidungsgrundlage. Der konkrete Bedarf entsteht, wenn mehrere Teams und Anwendungen unterschiedliche Modelle und Anbieter nutzen. Dann braucht es zentrale Limits, Routing, Logging, Datenschutzregeln und einheitliche Authentifizierung.
Das Gateway kann vor interne und externe Modellendpoints geschaltet werden. Das hat zwei Konsequenzen. Erstens können geloggte Modellaufrufe als Grundlage für Evaluation und Monitoring dienen. Ein separates Logging-System ist dafür nicht zwingend nötig. Zweitens kann ein Modell- oder Anbieterwechsel zentral über Routingregeln gesteuert werden. Anwendungen können dabei dieselbe Schnittstelle weiter nutzen, sofern die unterstützten Funktionen kompatibel bleiben.
Das Gateway nimmt aber nicht die Entscheidung ab, welches Modell für welchen Anwendungsfall verwendet werden soll. Die operative Frage lautet weiter, welches Modell für welchen Anwendungsfall, mit welcher Latenz-Toleranz und welchem Token-Budget. Es hilft dabei, diese Entscheidung technisch konsistent umzusetzen und zu kontrollieren.
Wie sich Routing-Regeln, Logging und Schutzregeln im Detail konfigurieren lassen, vertiefen wir im Cluster zum Unity AI Gateway.
Unity Catalog und MLflow als Grundlage für produktive KI-Anwendungen
Databricks Unity Catalog bildet die Grundlage für Berechtigungen, Datenherkunft und viele KI-Komponenten. Vector Search legt seine Indizes in Unity Catalog ab und braucht dort Berechtigungen, Tags und Lineage. Das Agent Framework registriert Tools und Functions in Unity Catalog. Modelle aus der MLflow Registry liegen in einem Unity-Catalog-Schema mit Versions-Aliases. Ohne Unity Catalog fehlen viele Governance- und Integrationsfunktionen oder sind nur eingeschränkt nutzbar.
Modelle, Versionen und Experimente sollten zentral über MLflow und die Model Registry verwaltet werden. Für jedes produktive Modell sollte eine nachvollziehbare Version mit Metadaten, Evaluation und Herkunft dokumentiert sein. Wird die Registry erst später eingeführt, müssen bestehende Übergabe- und Deploymentprozesse häufig nachträglich umgebaut werden. Wie Modell-Registry, Tracking und Prompt-Management in einem Lifecycle zusammenspielen, erklären wir in Managed MLflow.
Diese Punkte gehören zur Plattformgrundlage und tragen über einzelne Anwendungsfälle hinaus.
Wann Mosaic AI statt Bedrock, Azure OpenAI oder Vertex AI?
Die Entscheidung hängt vor allem an der Ausgangslage, weniger an einzelnen Features.
Mosaic AI passt besonders dann, wenn die Daten schon in Databricks liegen und Daten, Modellversionen und Modellantworten zusammen nachvollziehbar sein müssen. Unity Catalog, MLflow und Gateway bilden genau diese Kette ab. Dann braucht es keine zusätzliche Plattform für Identitäten, Rechte und Logging. In regulierten Branchen ist das oft ausschlaggebend.
Vier Achsen entscheiden: Governance, Agents, MLOps, Gateway.
Unity Catalog, Agent Bricks, MLflow und AI Gateway laufen in einer Schicht; bei Bedrock, Azure OpenAI und Vertex AI verteilen sich dieselben Funktionen auf mehrere Dienste.
Auch beim Mix aus eigenen Modellen und externen Foundation Models lohnt sich eine gemeinsame Verwaltung. Die Model Registry hält unterschiedliche Modelltypen und Versionen zusammen. Das Gateway steuert Aufrufe zwischen internen und externen Modellen. Die Abrechnung bleibt zwar je Dienst unterschiedlich, lässt sich aber auf derselben Plattform auswerten.
Zwei Kundenbeispiele zeigen, was das bringen kann. FactSet hat die Qualität seiner KI-Anwendung durch mehrere spezialisierte Bausteine deutlich verbessert. FordDirect hat einen Chatbot auf Basis eigener Daten gebaut. Beide Beispiele stehen für engere Integration von Daten, Retrieval, Modellen und Governance: weniger Systemwechsel, schnellere Änderungen, bessere Nachvollziehbarkeit. Solche Ergebnisse hängen aber stark vom Anwendungsfall ab.
Ein Cloud-Provider-Setup passt besser, wenn die Daten und Pipelines schon vollständig in einem anderen Cloud-Stack laufen, ein benötigtes Modell nur dort verfügbar ist oder das reine Inferenzvolumen so groß ist, dass ein spezialisierter Anbieter wirtschaftlicher arbeitet.
Eine grobe Orientierung: Liegt die Datenplattform schon in Databricks und ist Governance wichtig, sollte Mosaic AI die erste Wahl sein. Geht es um exklusive Modelle, spricht mehr für den jeweiligen Cloud-Provider. Bei viel Inferenz und wenig Governance-Bedarf kann ein spezialisierter Anbieter günstiger sein. Sind die Unterschiede gering, ist die bestehende Plattform meist einfacher als ein neuer Stack.
Wie wir die Frage in einem konkreten Vergleichsartikel auflösen, klären wir im Vergleich Databricks vs. Snowflake und im Vergleich Databricks vs. Microsoft Fabric.
Welche Plattform passt zu welchem KI-Setup?
Mosaic AI und Snowflake Cortex bündeln beide KI-Funktionen auf einer Datenplattform, setzen aber andere Schwerpunkte. Snowflake Cortex bietet eine schlankere Komponentenliste mit klarem Fokus auf gehostete Modelle und Modellaufrufe direkt aus SQL. Mosaic AI ist breiter aufgestellt mit eigenen Fine-Tunes, Mosaic AI Training, dem Agent Framework, dem Tool Catalog und einer offenen MLflow-Integration.
Snowflake Cortex wählen, wenn
- Anwendungsfälle überwiegend SQL-getrieben sind und Modellaufrufe direkt im SQL-Statement laufen sollen
- kein eigenes Serving-Setup oder eine separate Model-Registry aufgebaut werden soll
- vor allem Analysten und nicht ML-Engineers die Modelle direkt aufrufen
Mosaic AI wählen, wenn
- eigene Modelle, Fine-Tunes oder Mosaic AI Training gebraucht werden
- Agent-Anwendungen mit Tool-Calling und mehreren Planungsschritten entstehen
- ein produktiver KI-Lifecycle mit offener MLflow-Integration und Versionierung nötig ist
Datenherkunft, Modellversionen, Evaluation und Monitoring
Je nach Risiko und Einsatzgebiet können Anforderungen an Dokumentation, Datenherkunft, Modellversionen und laufende Überwachung entstehen. Dazu können regelmäßige Qualitätsprüfungen und Monitoringprozesse gehören. Diese Nachvollziehbarkeit lässt sich grundsätzlich auch mit mehreren Plattformen umsetzen. Mit mehreren Anbietern entsteht dafür aber meist zusätzliche Integrationsarbeit.
In Databricks können viele dieser Informationen zusammenlaufen in Unity Catalog, MLflow, Gateway-Logs und Monitoringtabellen: Daten und Vector-Indizes in Unity Catalog mit Tags und Lineage, Modelle in der MLflow-Registry mit Versions-Aliases und Eval-Historie, Prompts und Antworten über das Unity AI Gateway zentral geloggt, Drift- und Qualitäts-Metriken in Lakehouse Monitoring auf denselben Tabellen. Dadurch lassen sich Auditfragen mit weniger Systemwechseln und einer konsistenteren Datenbasis bearbeiten.
Drei Schichten tragen die Nachvollziehbarkeit: Daten, Modelle, Betrieb.
Unity Catalog und Lineage bilden die Datenschicht, Gateway, MLflow und Model Registry die Modellschicht, Lakehouse Monitoring und System Tables die Betriebs- und Auditschicht.
Bei mehreren Anbietern liegen Identitäten, Logs, Modelle und Daten oft verteilt in mehreren Systemen mit eigenen Audit-Anbindungen. Der daraus entstehende Aufwand hängt vom regulatorischen Umfeld, der bestehenden Architektur und dem Reifegrad der Organisation ab. In stark regulierten Branchen kann eine integrierte Governance-Struktur besonders wertvoll sein.
Welche Bausteine braucht der erste produktive Use Case?
Pflicht für jeden Use Case
Unity Catalog, Managed MLflow, eine Schicht für Modellaufrufe und ein dokumentierter Bewertungsprozess.
Abhängig vom Anwendungsfall
Vector Search für RAG, Agent Framework und Tool Catalog für Tool-Calling, Unity AI Gateway bei mehreren Teams und Modellen.
Später ergänzbar
Mosaic AI Training, Feature Store und Lakehouse Monitoring, sinnvoll, sobald Fine-Tuning, klassische ML-Pipelines oder Drift-Monitoring gebraucht werden.
Für jeden produktiven Anwendungsfall braucht es mindestens Unity Catalog als Governance-Schicht, Managed MLflow für Tracking und Registry, eine Schicht für Modellaufrufe (Foundation Model APIs für gehostete Modelle oder Mosaic AI Model Serving für eigene Modelle) und einen dokumentierten Bewertungsprozess. Ohne diese vier Bausteine entstehen Lücken bei Nachvollziehbarkeit, Betrieb oder Verantwortung.
Drei Bausteine hängen vom Anwendungsfall ab. Mosaic AI Vector Search wird benötigt, sobald RAG oder semantische Suche gebraucht wird. Mosaic AI Agent Framework und Tool Catalog werden benötigt, sobald die Anwendung Tools aufrufen oder mehrere Schritte planen soll. Das Unity AI Gateway wird relevant, sobald mehrere Teams oder Anwendungen unterschiedliche Modelle und Anbieter nutzen.
Später ergänzbar sind Mosaic AI Training, Feature Store und Lakehouse Monitoring. Diese Komponenten entfalten ihren Wert oft erst, wenn die Plattform eine eigene Fine-Tuning-Strategie verfolgt, klassische ML-Pipelines parallel betreibt oder Drift-Monitoring auf produktiven Antworten braucht. Für den ersten Anwendungsfall lassen sie sich bewusst auf eine spätere Iteration legen.
Diese Priorisierung hilft zu vermeiden, dass ein erster Anwendungsfall mit zu vielen Bausteinen gleichzeitig startet und am Setup-Aufwand scheitert.
Grenzen von Databricks Mosaic AI
Mosaic AI bietet viele integrierte KI- und ML-Funktionen. Ob sie für einen konkreten Anwendungsfall reichen, muss dennoch einzeln geprüft werden.
Neue Modelle sind nicht immer sofort verfügbar
Neue Modellversionen können in Databricks später verfügbar sein als beim Anbieter selbst und sollten aktuell überprüft werden. Wer neue Modelle unmittelbar zum Veröffentlichungszeitpunkt benötigt, muss gegebenenfalls einen externen Anbieter ergänzen.
Tokenpreise bei reiner Inferenz
Spezialisierte Inference-Anbieter können bei bestimmten Open-Weight-Modellen niedrigere Preise anbieten, vor allem bei sehr hohem Volumen und wenig Integrationsbedarf. Ein externer Anbieter lässt sich trotzdem über ein zentrales Gateway anbinden, sodass Protokollierung und Zugriffskontrolle erhalten bleiben.
Edge- und On-Premises-Inferenz
Modellaufrufe direkt auf Endgeräten oder im eigenen Rechenzentrum liegen außerhalb des typischen Mosaic-AI-Betriebs und brauchen eine separate Inferenzlaufzeit. Databricks kann in solchen Architekturen weiterhin für Training, Evaluation und zentrale Governance genutzt werden.
Diese Grenzen sprechen nicht grundsätzlich gegen Mosaic AI, müssen aber in die Architekturentscheidung einfließen. Häufig ist eine Kombination aus Databricks und wenigen externen Diensten sinnvoll. Externe Komponenten sollten dort ergänzt werden, wo Verfügbarkeit, Kosten oder Funktionsumfang nicht ausreichen.
Eine frühe strukturierte Bewertung reduziert insbesondere zwei Risiken: mehrere Plattformen mit ähnlichen Funktionen und unklarer Verantwortung sowie eine unvollständige Nachvollziehbarkeit von Daten, Modellen und Inferenz.
Fazit
Databricks Mosaic AI ist besonders sinnvoll, wenn Daten und Pipelines bereits in Databricks liegen.
Zusätzlichen Nutzen bringt Mosaic AI, wenn Modellversionen, Datenherkunft und Modellantworten gemeinsam nachvollziehbar sein müssen. Auch mehrere Anwendungen und Verantwortliche sprechen für zentrales Routing, Logging und klare Regeln. Dann kann der integrierte Ansatz einfacher sein als ein zusätzlicher Anbieter-Stack. Der wichtigste Vorteil liegt darin, bestehende Daten-, Identitäts- und Governance-Strukturen weiterzuverwenden.
Besonders relevant ist Mosaic AI für Unternehmen, die mehrere GenAI-Piloten umgesetzt haben, aber noch keinen sauberen Weg in den produktiven Betrieb haben. In solchen Umgebungen fehlen häufig mehrere zentrale Grundlagen: zentrale Modell- und Versionsverwaltung, ein einheitlicher Zugriffspfad mit Logging und Regeln sowie ein wiederverwendbarer Bewertungsprozess. Viele dieser Anforderungen lassen sich mit bestehenden Databricks-Komponenten umsetzen, wodurch zusätzliche Werkzeuge teilweise vermieden werden können.
Wenn Databricks-Integration und Governance kaum eine Rolle spielen oder ein benötigtes Modell nur bei einem anderen Anbieter verfügbar ist, kann eine andere Plattform besser passen. In diesem Fall sollte zunächst geprüft werden, welche Plattform bereits die stärkste technische und organisatorische Grundlage bietet.
Für jede benötigte Funktion sollte bewertet werden, ob Mosaic AI sie technisch, wirtschaftlich und organisatorisch ausreichend abdeckt. Dabei sollte transparent dokumentiert werden, welche Anforderungen erfüllt sind und wo Lücken bestehen. Notwendige externe Modelle oder Dienste können anschließend gezielt über ein zentrales Gateway ergänzt werden. Ein solcher Vergleich ist belastbarer als eine reine Produktliste.
Der größte Nutzen entsteht, wenn Daten, Modellversionen, Inferenz und Evaluation innerhalb einer gemeinsamen Governance-Struktur verwaltet werden.
Die Entscheidung sollte an einem konkreten produktiven Anwendungsfall mit echten Daten geprüft werden.
Passt Mosaic AI zu euren GenAI-Use-Cases?
- welche Anwendungsfälle gute Kandidaten für Mosaic AI sind und welche besser über einen anderen Anbieter laufen
- welche Risiken bei Governance, Datenherkunft und AI Act vor dem nächsten Pilot geprüft werden müssen
- welche Plattformvoraussetzungen (Unity Catalog, MLflow-Registry, Workspace-Tier) für euren ersten produktiven Anwendungsfall fehlen
FAQ
Databricks Mosaic AI ist der Sammelbegriff für die KI-Bausteine, die nach der MosaicML-Übernahme 2023 in Databricks eingebaut wurden. Darunter laufen Foundation Model APIs, Model Serving, Unity AI Gateway, Vector Search, Agent Bricks, Agent Framework, Tool Catalog, Agent Evaluation mit dem Mosaic AI Quality Lab, AI Playground, Managed MLflow, Mosaic AI Training, Feature Store und Lakehouse Monitoring. Es gibt keine einzelne Mosaic-AI-Lizenz; was es gibt, ist mehrere Bausteine mit unterschiedlichen Abrechnungsarten nebeneinander. Databricks selbst positioniert die Klammer als Plattform für KI-Anwendungen aus mehreren Bausteinen.
