Databricks launches DBRX, a 132B open model
Databricks introduces DBRX, an open mixture-of-experts model with 132 billion total parameters. It activates 36 billion per query, raising the bar for enterprise open models.
On March 27, 2024, Databricks released DBRX, a mixture-of-experts language model with 132 billion total parameters and 36 billion active on any input. The technical launch report documents architecture, data, evaluations and speed conditions; comparisons remain vendor measurements and must travel with their protocol.
DBRX arrives as open models—those whose weights can be downloaded and run outside their creator’s infrastructure—have become an increasingly serious alternative to the closed APIs offered by OpenAI, Google, and Anthropic. For businesses, that distinction matters: it lets them adapt the model to their own data and decide where processing takes place.
A large model that doesn’t activate its full capacity
DBRX uses a mixture-of-experts architecture, or MoE. Rather than using all its parameters for every piece of text, the model contains 16 specialized networks—the experts—and activates four of them to process each token, the smallest unit of text handled by a language model.
The result is 132 billion parameters in total, but 36 billion active at each generation step. Parameters are the values a model adjusts during training to learn patterns in language, code, or mathematics. Activating fewer of them does not necessarily mean knowing less: it allows the model to reserve capacity for different tasks and reduce the computation required for each response.
The technique is not new. Google has used it in some of its research, and Mistral popularized it among open models with Mixtral 8x7B. DBRX’s difference lies in its scale and the number of experts selected per token. Databricks says the model was trained on 12 trillion tokens and supports a 32,000-token context window, enough to analyze lengthy documents or sustain long conversations.
Better results than leading open models
The company has released two variants: DBRX Base, aimed at developers and researchers who want to fine-tune it for a specific task, and DBRX Instruct, designed to follow instructions in a conversational format.
According to results published by Databricks, DBRX Instruct outperforms open models such as Llama 2 70B, Mixtral Instruct, and Grok-1 on standard tests of language understanding, programming, and mathematical reasoning. On HumanEval, a Python code-generation test, it scores 70.1%; on MMLU, a battery of academic and professional questions, it achieves 73.7%.
Benchmarks should be interpreted with caution. They are useful for comparing models on controlled tasks, but they do not guarantee that one will perform better in a real-world enterprise setting, where data quality, tool integration, security, and the cost of serving millions of queries all matter. Even so, the figures place DBRX among the most capable open models available today.
Conditional openness with an enterprise focus
Databricks is distributing DBRX’s weights under its own license, the Databricks Open Model License, and has made them available through Hugging Face. The license allows the model to be used, modified, and distributed, including for commercial purposes, although it is not a standard open-source software license such as Apache 2.0. Companies should review its terms before incorporating the model into a product.
The launch fits Databricks’ business, which focuses on enterprise data and machine-learning platforms. An open model can run on a customer’s infrastructure, be fine-tuned with internal information, and connect to its analytics systems. But running a model of this size still requires substantial infrastructure, even if the mixture-of-experts architecture reduces computation compared with an equivalent dense model.
DBRX does not erase the advantage held by large closed models, which tend to offer more polished products, integrated tools, and managed operations. It does narrow the gap. For organizations that need greater control over their data or want to avoid relying entirely on a single API, the new model expands the available options.
Total, active and memory answer different questions
In a mixture of experts, total parameters describe what must be stored and active parameters approximate what participates for each token. Actual memory adds cache, activations and serving overhead. A model with fewer active parameters may therefore still need many GPUs to reside. A fair comparison fixes hardware, precision, input length, batch and concurrent users.
The router chooses experts for each token. This allows specialisation but raises a question: if domains or languages activate different routes, does quality change? Evaluation should split results by language and task, inspect expert load and avoid treating the model average as every group’s performance.
How to read published advantages
The DBRX report specifies inference conditions: optimised infrastructure, precision and user arrival pattern. “Up to” marks an extreme in that enclosure. Reproduction requires the same model, tokenizer, request size, output and parallelism. Changing one condition may reverse the comparison.
Code and knowledge benchmarks are a starting map, not enterprise acceptance. Build tests from in-house documents, queries and programs, add a verifier and calculate cost per correct task. Preserve failures too. A high figure without an error distribution does not identify where review is required.
Keep the licence and artefacts with the exact revision. Downloadable weights enable inspection and adaptation, while training data are described only in aggregate. Audit openness by layer: weights, code, data, licence, evaluation and reproducibility.
The transferable skill is to compare expert models through stored total, active compute, protocol, in-house quality and licence. That record prevents “132 billion” from acting as a universal score and shows whether DBRX fits a particular infrastructure.
A deployment record prevents false comparisons
Identify DBRX Base or Instruct before downloading. The base variant continues text and serves as a tuning point; Instruct attempts to follow requests. Their evaluations are not interchangeable. Record tokenizer, context and weight format too because files with the same architecture may require different resources and behaviour.
For retrieval, build a collection with versions, duplicates and irrelevant documents. Log the passages selected by search and the citations used by the model. This separates retrieval failure from synthesis failure. Scoring only the final answer may lead a team to replace the model when the index was at fault.
Safety for a downloaded model belongs to its operator. Design limits, authentication, logging and incident response; the absence of a vendor API does not remove abuse. Open artefacts expand inspection and operational responsibility.
Finally, repeat evaluation after quantisation, tuning or an inference-engine change. Every modification creates a variant. Preserving results by revision turns adaptation freedom into evidence and avoids inheriting scores that no longer describe the deployed system.
The acceptance report ends with an explicit decision: run, tune, serve by API or reject. Each option states memory, cost, owner and open risks. This prevents evaluation becoming a collection of figures without operational consequence.
An update does not silently replace the model. The new version enters as a candidate and repeats the protocol before inheriting the use.
The same record names a task DBRX does not pass. A known limit supports review or another model; hiding it under an average makes failure recur in production.
This article was produced with artificial intelligence under human editorial oversight.
