Databricks opens managed GPU training to general use with AI Runtime

Databricks customers can now train models on managed GPUs inside the same platform that holds their enterprise data. The company made AI Runtime generally available on October 21, 2026, combining on-demand computing with training tools and access controls. The service puts Databricks in charge of provisioning and maintaining the GPU infrastructure, rather than customers.

Getting from code to running GPUs

AI Runtime, or AIR, handles GPU procurement, cluster configuration and networking. Databricks says it supports training across multiple machines and can scale workloads to hundreds of GPUs. Before assigning work, it checks GPU health; it also monitors running jobs and tests idle equipment to detect and remove unhealthy machines.

Its fast-start mechanism combines GPU pools kept ready for use with software images that load in stages. Instead of waiting for an entire container image—the packaged software environment—to download, a workload starts while the remaining image data loads in the background. Databricks says this lets even clusters with dozens of GPUs start in seconds.

Teams can use prebuilt environments or bring their own containers and code, including workloads using Ray, a framework for distributed computing. Environment caching lets them reuse an environment after building it once. Built-in data loaders also stream and cache training data, reducing time spent waiting for data to reach the GPUs.

One customer example illustrates the performance claim—and its boundary. In a testimonial published by Databricks, Superhuman researcher Kostia Omelianchuk described moving from eight A100 GPUs on one machine to 16 H100 GPUs across multiple machines. Training fell from roughly seven days to 48 hours. That comparison changes both the GPU count and hardware generation, so it does not isolate AIR’s software contribution.

Finding failures across a training job

The service also brings training diagnostics into MLflow, Databricks’ experiment-tracking tool. Logs stream seconds after a job is submitted, and a dedicated viewer supports investigation across multiple training machines. Genie Code analyzes those logs, identifies issues and recommends next steps inside Databricks, according to the company.

Access is not limited to one development interface. AIR connects interactive work with scheduled pipelines through several routes:

• Command line: submit a first GPU workload with a single command.
• Notebooks and code editors: access GPUs interactively while developing training code.
• Lakeflow: coordinate GPU jobs with upstream and downstream pipelines, with priority and pre-emption controls for scheduling.

Permissions extend beyond the training data

AIR extends Unity Catalog’s data-access rules to GPU workloads. Those permissions cover not just input data, but also logs and checkpoints—the saved training state used to resume a job. Databricks presents this shared control layer as a way to avoid fragmented permissions and unnecessary data copies when training infrastructure sits apart from enterprise data.

Workload isolation operates at the virtual-machine level. AIR also supports PrivateLink for private connectivity and controls on outbound network traffic. These are separate parts of the security design: permissions govern access to data and training artifacts, while isolation and networking controls govern the environment where code runs.

The same platform also records AIR usage and costs in Databricks billing tables. Workload-level records let teams identify which training runs consume their GPU budget. Databricks says hundreds of companies already use AIR, naming Robinhood, Merck and FactSet among them; general availability follows that existing customer use rather than marking the service’s first training jobs.