Zum Inhalt springen

DBRX

DBRX ist ein offenes Mixture-of-Experts-LLM von Databricks (März 2024). Definition, MoE-Architektur, Varianten und Abgrenzung zu Llama, Mixtral und GPT.

DBRX ist ein großes Sprachmodell (Large Language Model, LLM) von Databricks, veröffentlicht am 27. März 2024. Das Modell nutzt eine Mixture-of-Experts-Architektur (MoE, ein Bauprinzip, bei dem das Netz aus mehreren Teilnetzen besteht und pro Anfrage nur einige dieser Experten aktiv rechnen). Insgesamt hat DBRX 132 Milliarden Parameter (die trainierten Zahlenwerte des Modells), pro verarbeitetem Wortbaustein sind nur rund 36 Milliarden davon aktiv. DBRX gibt es in zwei Ausgaben: DBRX Base als reines Grundmodell und DBRX Instruct als Version, die auf das Beantworten von Anweisungen trainiert wurde. Beide stehen unter der Databricks Open Model License mit offen zugänglichen Modellgewichten, also frei herunterladbaren Zahlenwerten des trainierten Modells.

Was ist DBRX?

DBRX ist ein Sprachmodell nach dem Transformer-Prinzip (die heute übliche Netz-Bauart hinter Modellen wie GPT-4 oder Llama). Entwickelt und trainiert hat es das Mosaic-Research-Team bei Databricks. Die Veröffentlichung im [Databricks-Blog vom März 2024](https://www.databricks.com/blog/introducing-dbrx-new-state-art-open-llm) markierte den Punkt, an dem Databricks nach der Übernahme des Trainings-Spezialisten MosaicML im Jahr 2023 selbst als Anbieter eines eigenen Sprachmodells auftrat. Der Name DBRX kombiniert das Databricks-Kürzel mit einer Modell-Versionierung; auf der Modell-Plattform Hugging Face erscheint es unter databricks/dbrx-base und databricks/dbrx-instruct.

Architektonisch ist DBRX ein fein-granulares MoE-Modell. Das Netz besteht aus 16 Experten pro Transformer-Layer; für jedes Eingabe-Token wählt ein Routing-Netzwerk 4 der 16 Experten aus, deren gewichtete Ausgabe die Layer-Berechnung ergibt. Das Modell hat damit insgesamt 132 Milliarden Parameter, aber pro Token werden nur rund 36 Milliarden davon aktiv genutzt. Die Kontextlänge liegt bei 32.768 Tokens. Als Tokenizer verwendet DBRX den Tiktoken-Tokenizer von GPT-4. Trainiert wurde das Modell auf 12 Billionen Tokens einer kuratierten Text- und Code-Mischung, laut Modellkarte deutlich datenqualitätsgetrieben (Filtern, Dedup, Curriculum) im Vergleich zu früheren Databricks-Modellen wie MPT.

Der Grund für die Existenz des Modells ist eine strategische Positionierung. Databricks hatte mit dem Kauf von MosaicML das Foundation-Model-Training in den eigenen Stack integriert und wollte ein hochwertiges, offenes Modell anbieten, das Kunden im eigenen Databricks-Workspace hosten oder als Foundation Model API konsumieren können. DBRX war bei seiner Veröffentlichung nach den Benchmark-Zahlen von Databricks das leistungsstärkste offene LLM auf mehreren gängigen Evaluations-Sets (MMLU für allgemeines Wissen, HumanEval für Code-Generierung, GSM8K für mathematisches Reasoning) und übertraf dort Llama 2 70B, Mixtral 8x7B und Grok-1. Diese Führungsposition unter offenen Modellen war zeitlich begrenzt: Meta veröffentlichte im April 2024 Llama 3, kurz darauf folgten weitere Modell-Familien (Llama 3.1, Qwen 2 und Qwen 2.5, Mixtral 8x22B), die die Benchmark-Landschaft neu geordnet haben.

Die Lizenz ist die [Databricks Open Model License](https://www.databricks.com/legal/open-model-license), eine offene Lizenz für kommerzielle Nutzung mit einer Nutzungsobergrenze analog zur Llama-2-Klausel: Unternehmen mit mehr als 700 Millionen monatlich aktiven Nutzern benötigen eine gesonderte Lizenz. Für die meisten produktiven Enterprise-Anwendungen ist die Lizenz damit unproblematisch.

Abgrenzung zu Llama, Mixtral, Qwen und proprietären LLMs

Der Begriff DBRX wird häufig in einer Reihe mit anderen offenen LLMs genannt oder mit proprietären LLMs wie GPT-4 verglichen. Die relevanten Trennlinien:

Modell / KlasseArchitekturZugriffVerhältnis zu DBRX
Llama 2/3/3.1Dichter Decoder-only-TransformerOffene Gewichte (Meta Community License)Alternative offene Modelle; dichte statt MoE-Architektur
Mixtral 8x7B / 8x22BMixture-of-Experts (8 Experten, 2 aktiv)Offene Gewichte (Apache 2.0)Gleiche Modellklasse (MoE), gröbere Experten-Granularität
Qwen 2/2.5Dichter Decoder-only-TransformerOffene Gewichte (Tongyi Qianwen License)Alternative offene Modell-Familie aus dem Alibaba-Ökosystem
GPT-4, Claude, GeminiProprietär, Architektur unveröffentlichtNur API-Zugriff, keine GewichteGeschlossene Alternative, keine Selbst-Hosting-Option
MPT (Databricks/MosaicML)Dichter Decoder-only-TransformerOffene Gewichte (Apache 2.0)Vorgänger-Familie im gleichen Haus, keine MoE-Architektur

Gegen Llama 2/3 und Qwen unterscheidet sich DBRX architektonisch durch die MoE-Struktur: pro Token werden nur 36 Milliarden der 132 Milliarden Parameter aktiv, was die Inferenz-Kosten deutlich unter denen eines gleich großen dichten Modells hält. Ein dichtes 132-B-Modell würde bei jeder Token-Vorhersage alle Parameter durchlaufen; DBRX aktiviert einen kleinen Teil und erreicht damit bei vielen Aufgaben die Qualität deutlich größerer dichter Modelle bei niedrigeren Rechenkosten pro Token.

Gegen Mixtral, das ebenfalls MoE ist, unterscheidet sich DBRX durch die Anzahl der Experten und die Feinheit des Routings. Mixtral 8x7B hat 8 Experten und aktiviert 2 pro Token; DBRX hat 16 Experten und aktiviert 4 pro Token. Diese feinere Granularität ergibt mehr mögliche Experten-Kombinationen und laut Databricks-Analyse eine bessere Spezialisierung. Die Idee ist nicht neu; DeepSeek-MoE und andere Arbeiten hatten das Muster bereits gezeigt, DBRX war eine der ersten großangelegten produktiven Umsetzungen.

Gegen proprietäre LLMs wie GPT-4, Claude oder Gemini liegt der Unterschied nicht in der Architektur (die dort nicht öffentlich ist), sondern im Zugriffsmodell. Bei DBRX sind die Gewichte herunterladbar, das Modell kann im eigenen Cloud-Konto ausgerollt werden, Fine-Tuning und Continued Pretraining sind auf dem gleichen Modellstand möglich, und die Inferenz läuft ohne Daten-Abfluss zu einem Modellanbieter. Bei proprietären LLMs ist der Zugang auf API-Aufrufe beschränkt, das Modell bleibt beim Anbieter, und die Modellversion kann ohne Vorwarnung vom Anbieter geändert werden.

Beispiel: DBRX als Foundation Model API in einer RAG-Anwendung

Ein typischer produktiver Einsatz zeigt, wo DBRX im Modell-Stack sitzt. In einem internen Wissensassistenten auf Databricks-Basis wird DBRX Instruct als Antwort-Generator hinter einer [Retrieval-Augmented-Generation-Pipeline](/insights/databricks/artificial-intelligence/retrieval-augmented-generation/) betrieben. Die Anwendung erhält eine Nutzerfrage, ein Embedding-Modell erzeugt daraus einen Vektor, ein Vektor-Index liefert die relevantesten Dokument-Abschnitte, und DBRX Instruct formuliert aus Frage und Abschnitten die finale Antwort.

Für den Betrieb stehen zwei Wege offen. Der erste ist die Nutzung von DBRX über die [Foundation Model APIs](/insights/databricks/artificial-intelligence/foundation-model-apis/) als Pay-per-Token-Endpoint. Der Endpunkt ist im Workspace bereitgestellt, es fallen keine Infrastruktur-Kosten für die Bereitstellung an, die Abrechnung erfolgt nach verbrauchten Input- und Output-Tokens. Der zweite Weg ist das Selbst-Hosting: das Modell wird über Model Serving als dedizierter Endpoint bereitgestellt, mit fester GPU-Kapazität und vorhersagbaren Kosten pro Stunde. Dieser Weg lohnt sich bei hohem, konstantem Anfrage-Volumen und bei Anforderungen, die einen dedizierten, isolierten Compute erfordern.

Als Grundlagenmodell eignet sich DBRX Base als Ausgangspunkt für Anpassungen. Über [Mosaic AI Training](/insights/databricks/artificial-intelligence/mosaic-ai-training/) lassen sich Continued Pretraining auf domänenspezifischen Korpora oder Fine-Tuning auf aufgabenspezifischen Datensätzen ausführen. Das entstehende Modell trägt die MoE-Architektur weiter, hat aber Wissen und Sprachmuster der Zieldomäne stärker verankert. Die typische Kombination in Enterprise-Anwendungen ist DBRX Instruct als Antwort-Generator mit RAG für aktuelle Fakten und optional ein Fine-Tuning-Schritt, wenn Sprachregister oder Fachterminologie das erfordern.

DBRX im eigenen Unternehmen umsetzen?

Wir zeigen, wie sich das in deiner Systemlandschaft konkret abbilden lässt.

Gespräch vereinbaren