Train and Finetune Models Without Managing GPUs: Introducing AI Runtime

Summary

This video introduces AI Runtime, a new serverless GPU training experience on the Databricks Data and AI platform that gives data scientists on-demand access to H100 GPUs for training and fine-tuning deep learning models without managing infrastructure.
A live demo shows fine-tuning a fraud detection model using Unsloth on serverless H100 GPUs, with MLflow tracking deep learning metrics, Genie Code diagnosing throughput issues in real time, and the trained model deployed to a serverless H100 endpoint at 1,024 QPS.
Three key shifts driving the need for AI Runtime are the broad industry move to transformer architectures across all ML workloads, the rise of open-source generative AI, and new fine-tuning techniques that require more sophisticated GPU compute at scale.

Train and Finetune Models Without Managing GPUs: Introducing AI Runtime

Enterprise AI is entering a new era. Organizations are moving beyond small models to train and fine-tune increasingly sophisticated AI systems—from foundation models and recommendation engines to forecasting, computer vision, and reinforcement learning workloads. Yet scaling AI often means managing GPUs, distributed training, and complex infrastructure. In this video, we'll introduce AI Runtime, Databricks' new serverless GPU training experience. Powered by on-demand GPUs and tightly integrated with Lakehouse data, AI Runtime gives data scientists and ML engineers instant access to high-performance compute for training and fine-tuning models at scale. We'll cover the latest trends in deep learning, transformer architectures, and open-source foundation models, and demonstrate how AI Runtime works seamlessly with PyTorch, Hugging Face, and other leading frameworks. You'll also see how Databricks delivers a unified deep learning experience across MLflow, Lakeflow, Unity Catalog, Genie Code, and Notebooks. Join us to learn how to accelerate experimentation, optimize GPU workloads, leverage coding agents, and move from idea to production faster with AI Runtime—with no infrastructure management required.
Talk By: Ben Doan, Sr. Machine Learning Solutions Architect, Databricks ; Tejas Sundaresan, Staff Product Manager, Databricks ;

Chapters

FAQs

What is AI Runtime in Databricks?

AI Runtime is a new serverless GPU training experience on the Databricks Data and AI platform that provides on-demand access to H100 GPUs for training and fine-tuning deep learning models. This video introduces it as a solution that lets data scientists run PyTorch and Hugging Face workloads at scale without provisioning or managing GPU clusters.

How does Genie Code help with model training and debugging?

This video shows Genie Code diagnosing training throughput issues in real time by analyzing MLflow metrics and identifying bottlenecks in the training loop. It also demonstrates Genie Code assisting with model serving monitoring and failure debugging after the trained model is deployed to a serverless endpoint.

What deep learning workloads does AI Runtime support?

AI Runtime supports the full range of modern deep learning workflows including transformer fine-tuning, recommendation model training, NLP, multimodal AI, and agentic model training. This video focuses on fine-tuning for fraud detection, demonstrating the workflow with Unsloth, MLflow metric tracking, and multi-GPU throughput comparisons.

What is on the roadmap for AI Runtime on Databricks?

The roadmap for AI Runtime includes support for custom Docker images, reinforcement learning fine-tuning, and intelligent pool management for more efficient GPU utilization. This video previews these capabilities as upcoming additions following the initial AI Runtime launch.

Full transcript

[00:08] Hi everyone, my name is Tis and I'm a product manager at data bricks. Uh my name is Ben. I am a solutions architect at data bicks. >> And we're really excited today to share about how you can train and fine-tune on data bricks without having to manage GPUs with the new launch of AI runtime
[00:22] at summit this year. So just a quick safe harbor agreement before we kind of discuss our roadmap. And uh just a quick reminder to please complete your surveys. Your feedback is
[00:34] super super valuable in helping us shape these sessions for next summit. And so we really really appreciate if you could fill these surveys out. So today we're going to cover four main topics. One is we're going to first talk a little bit about how deep learning is
[00:47] changing. Um what are the shifts in the industry that are really motivating us to build a new GPU platform here at data bricks called AI runtime. Then we're going to introduce that AI runtime platform. Uh and then thirdly is Ben is
[00:59] going to go into a pretty detailed demo on how you can train, fine-tune and serve a model end to end using data bricks. And then lastly is we'll close out with what's coming next in terms of the road map for deep learning.
[01:12] So first how is deep learning really changing in the industry. There are three big shifts that we're tracking on our side at data bricks. One is the shift to transformers. The second is the rise of open source generative AI. And
[01:24] thirdly is new tools and techniques that enable customers to build more advanced deep learning models. And I'll get into a little bit on each of them. So the first is almost every significant ML
[01:36] workload that we see on data bricks has a transformer variant that is reaching state-of-the-art results across search. You might want to have custom rankers in forecasting. You might want to pre-train or use a transformer-based forecasting
[01:49] model. In the personalization space, we're seeing deep learning recommenders shift into transformer architectures as well. Then of course on the unstructured data side with NLP, multimodal AI, and even agents that are now getting
[02:01] fine-tuned. So it's very clear there's a strong shift in the industry towards larger, more complex models. And what's driving that is that customers are getting better results, higher quality when they're able to leverage these architectures on larger and larger data
[02:15] sets that they have inside their lakehouse. And we're seeing this across various industries. In the healthcare life sciences side, there's a large shift to use AI for drug discovery. In financial services, fraud detection models are
[02:28] moving to transformers. In the entertainment space, there's new personalization, search and uh models coming out. And on the retail and consumer side, a lot of the core recommenders and supply chain management models are also moving to this
[02:40] architecture. So generally, there's a large shift in the industry to
[02:54] mark and just in the last year, it's become 2 million. And so it's very clear there's a large kind of adoption curve around using open source generative models on your own data. And all of those also require another shift in deep
[03:06] learning stacks. And the third is a set of new frameworks and tools that are now available to machine learning teams. on on the framework side, you know, products like Onslaught or TRL, PEFT within
[03:20] HuggingFace are rapidly rapidly getting adoption to tens of thousands of GitHub stars over the course of just a few months. And then there's also not just new frameworks available for teams, but also new techniques to actually uh for
[03:32] example do reinforcement fine-tuning on agents to improve quality and get better economics. So data scientists now today have a really nice plethora of tools across frameworks and uh other techniques to actually build more
[03:45] models. So the net effect of all of these three shifts within deep learning is that there's an increased demand for GPUs. There's more models, larger models, more techniques and experiments done and all of that is driving the need
[03:58] for a new GPU platform. And that's where AI runtime comes in. So uh deep learning teams are struggling in kind of three contexts. The first is that GPUs are really unreliable and
[04:10] expensive. The second is that we're seeing distributed training is really difficult. And then the third is that enterprise governance and scale is hard. And we'll get into a little bit on each three of these pain points.
[04:24] So AI runtime is our new deep learning stack on data bricks. It was just announced today at keynote uh with several wonderful design partners. It brings GPUs into serverless. So now serverless compute and data bricks has
[04:36] A10s and H100s on demand. And they're preconfigured with things like RDMMA and GPU resiliency. And all of this sits native into the data bricks lakehouse. You can access your data directly and leverage these GPUs.
[04:49] So there's three problems we outlined. I'll cover a little bit more about how AI runtime solves each one of them. So first is that GPU infrastructure is really hard to manage. So often times teams struggle with procuring GPUs. Then
[05:02] the GPUs themselves can fail if the data center for example overheats. Uh a lot of these GPUs in order to train require really complex networking setups. Things like RDMA, Infiniband. And lastly is
[05:14] when GPUs are not working well, they're really really hard to debug. And AI runtime solves each of those. Once it brings serverless to GPUs. It's builds a resiliency layer built into the entire
[05:26] platform so that we detect when GPUs fail and recycle them ourselves. It comes preconfigured with nickel and RDMA so that you can actually do multiode training without having to worry about setting up networking. And then it has a
[05:38] full robust logging layer built in that makes these GPU workloads really observable. So that was problem number one. Problem number two is that actually setting up distributed training even after you have the GPUs is still really
[05:50] difficult. You're stuck setting up environments and dealing with uh package conflicts. Uh and to solve that AR runtime comes with a built-in runtime for deep learning. The second is that distributed training actually has a really high learning curve. You have to
[06:03] figure out how to set up networks and GPU nodes that communicate to each other. And with AI runtime, we try to make single node training as simple as multiode training. And so Ben will cover that in the demo, how we've built an SDK
[06:15] around GPUs to make it really simple. Thirdly is that GPUs are really hard to debug. Even training scripts, for example, require you to go to the depths of maybe this CUDA error or this out of memory error. And so we're launching
[06:27] actually a new ML flow version targeted towards deep learning. And it's all agent driven to make debugging really simple. And Ben will also cover that. And then lastly is the full ML life cycle for deep learning is actually really difficult. It's not just about
[06:40] training a model, but it's going from training and your data to then serving and experiment management. And with AI runtime, it all sits directly within data bricks ML platform. So it's all unified and really easy to manage.
[06:53] And then the final challenge is that actually getting governance and scale to work on GPUs is really difficult. So oftentimes what we're seeing customers is that they're copying data from one system to a GPU cluster. Uh they're
[07:05] actually not getting the best GPU utilization on their GPUs. They're figuring out capacity and it's really difficult across different teams and deep learning workloads bring a unique set of performance challenges. Checkpointing, data loading, all are
[07:18] really really difficult AIO problems. And so with AI runtime, we've also optimized that full layer and we'll get to that a little bit later in the presentation. And so here's a great example of just a few features coming in. So of course the
[07:31] deep learning runtime, it comes with basic support for things like HuggyFace and PyTorch. It also comes with a full soup to nuts deep learning tool set across how you train to how you experiment then how you debug and then of course agents are available across
[07:44] the entire workflow to make that experience easier through our genie code integration. So here's an example of how you can connect to AI runtime just directly in the notebook. You can specify an accelerator. In this case I'm connecting to an H100 and then it just
[07:57] seamlessly works in serverless. So no cluster configuration or procurement. It just works out of the box. And of course and secondly uh these u these GPUs are not just available in notebooks but you
[08:09] can access them via a CLI and fully within lakeflow as well. And then it has agent assistance built in. So this is an example where Genieode can go in and actually debug while your GPU workload might have hit a memory
[08:21] issue and uh Genie code is available to help with your GPU workloads across notebooks and also ML flow. And then lastly on the performance side before we get into the demo. So there's three layers of performance
[08:33] optimizations we've built into the system. On the infrastructure side, we've optimized the container build process. So it's really low latency. It spins up quickly and so every minute counts when it comes to expensive GPUs and we've optimized that process. The
[08:47] second is on data set performance. So we're coming in with optimized file formats for deep learning and as a result also Unity catalog supports high performance data loading. And then lastly is on the workflow side. So, we have agents that can debug, optimize,
[09:00] and track GPU performance all built in within the data bricks platform. And with that, I'll turn it over to Ben to go through a demo. >> Um, all right. Awesome. So, um, I think actually I'm going to start off the
[09:12] demo. A quick show of hands. Who here has fine-tuned an LLM on their own hardware before? Okay, actually, there's like a decent like a third of you. Okay, awesome. Um,
[09:25] yeah. Yeah. So, I'm actually going to start the demo with um a actually a project from about 18 months ago. So, this was before air was a thing. Um and uh basically what we were doing with
[09:37] this specific project um we were using FSDP to fine-tune a two billion parameter Quen model um on a p5 cluster that we had on AWS. Um, and so the reason why I'm I'm kind of showing you
[09:49] guys this is kind of to highlight like there's a ton of code here. Um, and there's actually a ton of stuff that has nothing to do with training, right? So you see here there's like a bunch of scripts to uh monitor and check on the
[10:01] health of your cluster. Um, there is there's bash scripts actually launch the cluster itself. Um, there's some modules to actually hook up and report the metrics to MLflow. Um, so there's actually like a ton of overhead here
[10:15] just to kind of hook up your, you know, your your scaffolding and your infrastructure to your training code. And the training code itself is actually just like these four Python modules at the bottom. Um, and you know, as a data scientist, like this sucks, right? I
[10:28] don't really care about any of this. Um, I really like all I really want to do is I kind of want to, you know, uh, configure my training code and my parameters and then look at my experiments to see like if the changes I've made have actually affected my my
[10:41] performance at all. Um, and so the reason why I'm kind of showing you guys this is like this is like a really good uh kind of uh frame for like one of the key motivators behind uh AI runtime and
[10:53] and kind of like why we we kind of made it as a product. Um, okay. So, switching over to the demo now. Um, so in this demo, we're going to uh fine-tune a
[11:05] Quinnet 3 model um for an advanced fraud detection use case. Um, so for as as a bank, you know, I might want to uh do more than just a basic fraud detection
[11:18] on very high risk or high visibility transactions. Um, and so basically what the uh model contract is for this use case is we're actually going to take a uh bunch of credit card transactions um
[11:31] and we're going to fine-tune a model to not only flag the fraud risk but then also offer up a triage as well as a uh analyst interpretable rationale as to why the fraud score was uh given. Um and
[11:46] so because we're doing this for fraud detection, this is also something that you know requires uh serving at very low latency and high QPS. So we'll actually deploy it to some infrastructure and run a load test at you know a few thousand
[11:58] QPS to show you the support that we have um for that. Um okay so first things first uh we're going to attach to a serverless GPU. Um so you know like TA
[12:11] just mentioned connecting to a GPU is super easy. I just go into this environment panel. I select my 8 by H100 and then now I have access to eight H100s. I didn't have to go back and forth with my cloud provider. I didn't
[12:23] have to, you know, um beg him for uh to increase my quota. Um I simply just uh selected it here and now I am connected. Um so first beautiful thing about air is uh you have access to your GPUs right
[12:36] off the bat. Um now that we are connected we can just validate that we have the GPUs and then we can um actually look at our training data. Um
[12:49] so whoops not sure why that happened but uh regardless we can basically actually run Spark on this cluster. I'm not 100% sure
[13:01] what happened there. Um but um kind of just to call out, we're going to be loading in some uh fraud data and then basically running it um uh through our unsloth fine-tuning harness. Um so now
[13:15] to dive into the training code, um I'm going to kind of open up the training directory here. And so you guys can actually see uh relative to what I showed you guys at the beginning um the
[13:28] uh training code is actually much much smaller in terms of pure code overhead. Right? All we have is we have a training configuration YAML file um as well as a
[13:40] um a couple utilities um and then the actual training uh code itself um which I more or less lifted from Unsloth. Um so um you guys can you we can actually
[13:52] port in any custom fine-tuning library that we want here. I use unsloth but you can actually there's we have support for any of them. Um and to actually run the training what we can do is we can actually um wrap or we can bring in our
[14:07] training script and then basically uh wrap it in this distributed decorator to uh give it access to uh you know our H100s. Um, so you know, typically you
[14:19] would run something when you're experimenting on a single GPU. Um, but bumping it up to multiple GPUs is as simple as changing this G this parameter. Um, and then we can even bump it to 16 which will actually give us another H100. Um, and so this is the
[14:33] second really really nice thing about air is if we want to distribute our training code, um, we just change this parameter and this will give us the ability to, uh, distribute, uh, large
[14:45] training workloads. Um, I'll go ahead and I'll kick this off, but this will take a few minutes. So, what I'll actually do while this is running is I will move into uh the ML flow uh UI to kind of go through a few uh training
[14:59] runs that I had historically or that I ran earlier today. Um, let's see. Let's click into this one. Um, so first things first, um, first thing to call out is that the
[15:11] integration with MLFlow came right out of the box, right? I didn't have any scaffolding code to hook up uh the training code or report any metrics. Uh we kind of just get these really awesome uh GPU utilization
[15:24] uh metrics and other GPU level metrics uh right out the bat. Um we also get the classic model metrics that you guys are probably familiar with with MLflow. Um,
[15:36] and then finally, we can do things like we can uh compare runs with each other the same way that we did uh kind of with MLflow with the ML flow that that you guys probably know and love. Um, so here I'm just going to compare some runs just
[15:48] to validate a few things, right? So, you know, we increased the GPUs by let me zoom out here.
[16:01] You know, we we, you know, increase the GPUs by eight. And so one of the things that we definitely want to make sure that we can validate is that the sample size or the the sample throughput for our training run has increased by a
[16:13] factor of eight. Um so this is a little cut off at the bottom here but um you can see basically what we're comparing is a single GPU run versus 8GPU run and we can see an an eightfold throughput uh
[16:26] in the samples uh in the training sample uh uh throughput. Um cool. And so some of you guys that are maybe a little bit observant um probably are
[16:40] looking at this and you're thinking to yourself, uh 16 samples per second is like really slow for eight GPUs, um eight H100s actually. Um and to that I would say you're you're absolutely right. Um, and so this kind of takes us
[16:53] to the the next really cool thing that we wanted to kind of highlight with Air. Um, is the full Genie code uh integration with Air and the MLFlow and the MLFlow experiment experience. Um, so
[17:05] here what I actually did was I pulled up um a conversation that I actually had with Genie to help me troubleshoot my uh throughput issues on my training runs. Um, so I basically was like 16 seems very slow. Um, helped me diagnose the
[17:18] training throughput. And if we look at the steps that Genie took, you can see that Genie actually uh looked into my training code and configuration um and then actually pulled the experiment that
[17:30] you see here on the left and then basically gave me a bunch of recommendations on how to improve the training performance on my GPU cluster. Um so this is like super super helpful.
[17:42] This is just like another way that we enhance the model training experience with agents here on data bricks. Um, and it even goes as so far as it can actually um I can actually tell Genie to apply the optimizations to my training code and then rerun. Um, so yeah, so
[17:56] this is uh kind of from the training perspective what uh it may what what a typical workflow might look like on the AI runtime. Um, switching gears to a little bit. Um, we actually uh
[18:10] everything that you just saw in the notebook is also available via CLI. Um, so, uh, here is like basically the exact same code that I showed you guys earlier with the training script and the training configuration.
[18:23] Um, and you can see here with the CLI, let me zoom in a little bit. Um, we can look at all of the previous runs that we had submitted via the CLI,
[18:36] which will take a second. So, here are all of our runs. Um, and then we can also submit one. And so what this will do is this will take our training YAML as well as our script
[18:49] and it will actually run it on the AI runtime GPUs. Um, and then as a data bricks job and so we can click in click through this job link um and we can actually see
[19:02] our GPUs our runs coming up. So yeah, so here's the runs um and then also we have logs that are also exported. is you can also monitor the GPUs as well. Um,
[19:14] for anyone that's a fan of Ray, so if we have any Ray fans in the house, we also have um wh we also have um support for Ray, so you can actually set up um array
[19:27] configuration and training script and then also run that on AI runtime. And then we also have support for uh custom Docker images coming out as well. So if you're interested in deploying a custom DCS image, um you can add that to your
[19:39] AI runtime configuration and then submit the job that way. Um okay, so that's the CLI experience. Like I mentioned, it's basically I changed nothing from a coding perspective between the notebook
[19:51] and the CLI. Uh I can just submit and run and everything works right out the box. Um okay, cool. So I have trained my model. So the next thing I want to do is I want to Whoops. I have trained my
[20:05] model and so the next thing I want to do is I want to deploy it to an endpoint. Um so here um I have a model logged to Unity catalog. Um and so what I can do is I can now serve this model to uh next
[20:19] generation uh GPU hardware. Um so we click this we'll actually see this will take us to a model serving UI. Um and then from there you'll see that um we
[20:32] actually have access to deploy to uh H100's here as well. This is a slightly smaller model so we don't necessarily need it. Um but if you're training a very very large LLM um then you can
[20:44] actually select this you can deploy your your large fine-tune family um on our H100 hardware. Again no uh provisioning or no procurement cycle needed. Uh this is just available with our serverless
[20:56] GPUs. Um I actually already have a model deployed here. Um so what we can do is we can just pull this up. Um we can hit it with an example query. Um you can see that it is taking in a uh description of
[21:12] uh the input credit card and the and a few additional data points and then basically generating our risk score, our action, our triage action and then the rationale behind it. Um the other thing
[21:26] that's really nice as well is um we can provision this to support uh a typical fraud use case. So fraud, you know, you're processing thousands of transactions per second. Um and so actually you see here uh we've
[21:38] provisioned the concurrency to be this is a little bit hard to see, but this is roughly a,024 concurrency to support that high workload. Um and we're actually going to run a load test now. So, um, I'm going
[21:50] to run this and I'm going to run this. And what this is going to do is this is going to hit our endpoint with a Spark
[22:02] CL or from a Spark cluster simulating roughly a thousand QPS. Um, and so while this is running and loading, I'm going to go back to the endpoint and I'm going to kind of show a few a few more couple interesting things as well. Um, so the
[22:17] other thing I wanted to call out is just like our MLflow uh experience, our model serving experience is also now very very tightly integrated in um with uh Genie code. Um so what you can actually see
[22:29] Oh, I think we're starting to see some transactions come in. Um but what you can actually see is um I can actually have Genie give me an overview of the model that I just served. Um as well as things like cost estimations. Um and
[22:42] then you can also give some recommendations. In this case, it actually said you've been you're running a you know 1024 concurrency which is pretty big. Um you may want to consider uh you know uh scaling it back or or
[22:54] adding autoscaling to it to save money. So Genie is integrated tightly in with the model serving experience. And it can also do things like help you troubleshoot model build failures. Um,
[23:06] so I'm sure anyone who's deployed an LLM on a GPU before has had to deal with the mess of logs or the the challenges that comes with deploying your model on a GPU endpoint. Um, and so what I'm going to do is I'm actually going to pull up
[23:21] a model that I previously deployed that failed. So here we go. Um, so this model failed. Um, the reason why was I left out a dependency. Um, and so if we
[23:33] actually go into the service logs, we can see the the error and and and uh we would, you know, in the old way, we would pull this error uh out of the logs, we would copy and paste it into uh Google and then we would try to run down
[23:46] what this actually means and then we would be miserable because CUDA errors are like notoriously not super well documented and then we would ask our manager and our manager would not be in office and then I would be like, "Okay, guess my day is ruined." Um but now with
[24:00] Genie code um one of the beautiful things that we can do is we can actually have Genie look at the logs for us and help us troubleshoot. Um, so if we actually look at like the what Genie is actually doing here is actually going into the service logs and then pulling
[24:13] documentation to understand like what is happening with the model failure and it'll actually give us recommended fixes as well and uh I can actually have it uh implement the fixes and then actually
[24:25] redeploy the endpoint uh as uh to actually uh solve the issue. Um, cool. So from there
[24:37] I think the yeah I think from there I think that those are like the major points I wanted to cover in the demo. Um is primarily just um primarily just uh that we were able to um you know attach
[24:52] ourselves to uh GPU hardware um next generation GPU hardware. We were able to scale up the training from one to eight to potentially even 16 GPUs across multiple nodes. Um when uh as we trained
[25:06] the model, we could do things like use Genie code to actually uh plug into the experiment and use Agentic Assistance to help us optimize and improve our model training experience. Um and our code
[25:19] actually um and then finally um we deployed it to an endpoint um that we could then hit uh with you know production level scale like roughly a thousand queries per second. And Genie
[25:31] is also there to help us troubleshoot our model deployment errors and give us a summary of the model traffic as well. Um so yeah, so that kind of concludes my demo. Um one other thing to call out as well is actually all of this is
[25:44] available on GitHub. Um so if you have air enabled in your data bricks workspace, um you can actually pull the code down and this is all standalone. I'm using an open source data set. Um so you can actually run this completely as
[25:56] is most if you have air enabled. Um, cool. Yeah. So, that's the demo. Um, I'll hand it back over now to Tis. >> Cool. Thanks, Ben. Awesome demo.
[26:16] >> So, I'll share a little bit of a preview on like where things are headed with AI runtime after summit. So, the first Ben touched upon briefly was Docker image support. So, right now that's currently in private preview, but we're expecting it to come to beta really soon. And the
[26:28] goal here is for deep learning libraries, especially if you're looking to git uh you know, git clone something from a research library somewhere, uh you'll be able to leverage AI runtime and serverless GPUs with custom docker images. And so you'll have the ability
[26:41] to kind of have that flexibility on your environment. A second is around RL. And so a big uh interest area of interest for us is how do we help customers optimize their agent use cases? And you know reinforce and fine-tuning has become a very very
[26:55] uh top of- mind kind of endeavor for a lot of companies. And so we were as part of uh our efforts within Carl which is a technique pioneered by our research team. We're working with some customers on how do we optimize their agents from
[27:07] a cost and latency point of view. And the final is on uh intelligent pool management. So you might as a team have maybe dozens or hundreds of GPU workloads running on AI runtime. And
[27:19] we're building dashboarding and tooling natively built into data bricks to help identify workloads where there could be optimizations possible. So optimizations in terms of performance or queuing or other things. And so all of that uh is
[27:31] uh coming to the platform later this year. And so just to kind of summarize the talk a few takeaways we really think 2026 due to all those shifts we mentioned earlier requires a rethink of
[27:44] the deep learning stack. And that's what motivated us to build AI runtime. And so AI runtime is a tool now available in public preview. Uh it accelerates the deep learning life cycle across managed infrastructure agents to help build a
[27:57] developer experience making distributed training easier and helping you get great performance on your GPU workloads. It's available today in public preview and here is a QR code that leads us to uh the documentation.
[28:09] Uh thank you all for coming to the talk. We really really appreciate it. Uh I know it's the final day of the conference and thanks again for uh your time here. >>

Learn more about the Databricks Data and AI platform.

The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.