作者：nTokenX｜发布日期：2026-09-02｜更新日期：2026-09-02
Databricks AI Gateway is now best understood as Unity AI Gateway: Databricks’ governance layer for model traffic, agents, and tools. In practice, it lets teams control who can use AI services, route requests, apply guardrails, and monitor usage from one control plane. Databricks’ current overview explains that it covers Databricks-hosted foundation models, external providers, MCP servers, and agents through Unity Catalog governance.Databricks Unity AI Gateway overview
What Databricks AI Gateway is
Databricks AI Gateway is a governed routing and policy layer for enterprise AI. It is not just a proxy. It sits between callers and AI destinations so the platform can apply identity, access control, rate limits, guardrails, observability, and spend controls in a central place. Databricks describes the system as built on Unity Catalog, which means model services, agents, MCP services, and tools are treated as securable objects rather than ad hoc endpoints.
A useful mental model is this: the gateway governs what can be called, how it can be called, and what happens after each call. Databricks also supports native access to hosted foundation models in system.ai, plus external providers through bring-your-own-key connections, so the same governance layer can cover both native and third-party traffic.Databricks AI governance guide
What it governs today
The current product scope is broader than many older summaries suggest. Databricks documents three especially important pieces:
- Model services in Unity Catalog, including ready-to-use model APIs in
system.ai - External providers such as OpenAI and Anthropic, governed through one control point
- Agents and MCP tools, which now sit in the same governance plane as model traffic
A model service can reference one or more destinations, and Databricks can route each request to the right destination with fallback support. That matters because it lets a single governed service mix Databricks-hosted models and external model provider services. It also means the gateway is about more than access control; it is also about traffic shaping and operational resilience.Databricks model services doc
Legacy AI Gateway vs. Unity AI Gateway
This is the part most search results blur together. Databricks has a legacy AI Gateway tied to serving endpoints, and a newer Unity AI Gateway that is the current control plane. The legacy path focused on endpoint-level governance, while the new version extends governance to runtime interactions across models, agents, MCP servers, and tools.
Databricks’ migration guidance is clear: new accounts and workspaces should start fresh with Unity AI Gateway, while existing legacy workloads can be migrated when needed.Migration guide
The practical difference
| Question | Unity AI Gateway | Legacy AI Gateway |
|---|---|---|
| Need governance for models, agents, and tools together | Yes | Limited |
| Need traffic splitting or fallbacks | Yes | More limited |
| Need modern Unity Catalog-based governance | Yes | Partial |
| Starting a new workspace | Recommended | Not the default path |
The takeaway is simple: if the project is new, follow the Unity AI Gateway path. If an old serving endpoint already exists, treat legacy AI Gateway as a migration topic, not the main destination.
When Databricks AI Gateway is the right fit
Databricks AI Gateway is strongest when Databricks is already the system of record for data, identity, and governance. It fits best if the AI workload lives close to lakehouse data, needs Unity Catalog permissions, or must be controlled by the same admins who govern data assets.
It is also a strong fit when you need:
- Rate limits and budgets for specific users, teams, or projects
- Guardrails on requests and responses
- Audit trails for prompts, outputs, and usage
- Fallbacks to reduce outage risk
- Unified access to Databricks-hosted and external model providers
A useful signal: if the main problem is “who can call which AI service, with what policy, and under what budget,” Databricks AI Gateway is usually the right tool.
When a unified multi-model API gateway is the better fit
Sometimes the real problem is different. If your app is outside Databricks and the goal is to normalize access across multiple vendors with one app-facing API, a unified multi-model API gateway may fit better than a Databricks-native governance layer.
That is the kind of pattern nTokenX covers in the model relay architecture guide and the Unified AI API practical guide. In that model, one API key can call GPT, Claude, Gemini, and Grok through a single front door, which is useful when the app needs provider portability more than Databricks-native governance.
A fast decision rule
- Choose Databricks AI Gateway if governance, Unity Catalog, and Databricks-native AI operations are the priority.
- Choose a unified multi-model API if application portability and provider abstraction are the priority.
- Use both if Databricks governs the internal AI estate but external apps still need a separate normalization layer.
For a broader gateway comparison framework, see nTokenX’s AI Gateway architecture and selection framework.
A practical implementation checklist
Databricks’ current docs make the rollout path fairly concrete:
- Confirm whether you are starting fresh or migrating. New workspaces should generally start on Unity AI Gateway.
- Choose the model surface. Use
system.aiwhen Databricks-hosted model APIs are enough; use external provider services when you need BYOK or provider-specific access. - Decide how you will call it. Databricks supports unified OpenAI-compatible APIs, native provider APIs, and SQL/query-based access for supported cases.
- Turn on the controls that matter. Rate limits, guardrails, inference tables, and budgets each solve a different operational problem.
- Instrument usage early. Databricks logs requests and responses to inference tables in Unity Catalog Delta tables for monitoring and debugging, and budgets help control monthly spend.Inference tables Budgets
A strong implementation usually starts with one model service, one owner, one budget, and one monitoring view. That keeps the governance model understandable before it expands to more teams or more providers.
Common mistakes to avoid
The most common mistake is treating Databricks AI Gateway like a simple reverse proxy. It is more useful than that, but also more opinionated: it works best when model access, permissions, and logging are modeled as first-class governed assets.
Another mistake is assuming the legacy endpoint flow and Unity AI Gateway are interchangeable. They are not. If you are launching something new, the modern path is the one to optimize for. A third mistake is using Databricks AI Gateway when the app really needs a provider-agnostic edge layer. In that case, a unified API gateway can reduce code churn and keep the application portable.
FAQ
Is Databricks AI Gateway the same as Unity AI Gateway?
In current Databricks documentation, Unity AI Gateway is the modern product name and scope. The older AI Gateway model-serving-endpoint flow still exists mainly for migration and legacy workloads.
Can Databricks AI Gateway govern external model providers?
Yes. Databricks documents support for external providers such as OpenAI and Anthropic through bring-your-own-key style connections and model provider services.
Does Databricks AI Gateway support routing and fallbacks?
Yes. Databricks describes traffic splitting, fallbacks, rate limits, and budget controls as part of the current Unity AI Gateway capability set.
Do new workspaces need the legacy AI Gateway path?
No. Databricks’ migration guidance says new accounts and workspaces should start with Unity AI Gateway rather than the legacy path.
When should a unified multi-model API be used instead?
Use it when your main need is one app-facing API for multiple model vendors, especially if the app is outside Databricks and provider portability matters more than lakehouse-native governance.
Bottom line
If the search intent is “What is Databricks AI Gateway?”, the short answer is that it is Databricks’ governed control plane for AI traffic, not just a model endpoint feature. It now spans model services, external providers, agents, tools, guardrails, usage tracking, and budget control. If your stack is already centered on Databricks, it is the natural choice. If your priority is one portable API across many model vendors, a unified multi-model gateway may be the better fit.