Training a model now happens next to your data or behind an API. What stays yours is the evaluation
Databricks made AI Runtime generally available, AWS turned training loops into SageMaker API calls, and Snowflake opened ML Jobs to custom containers. GPU training is becoming a platform service.
Listen to this article · 5 min
AI-generated narration of the full article.

For most enterprises, training or adapting a model has meant building a second platform: a GPU cluster, a scheduler, container images, checkpoint storage, and a copy of the training data that left the governed environment where it normally lives. That second platform is expensive to run and hard to audit, and it is one reason so many fine-tuning projects never reach production.
Three announcements in two days, October 21 and 22, point to that second platform disappearing into the first.
Three ways to rent the training stack
Databricks AI Runtime is generally available. It brings serverless GPUs into the Databricks platform, with launches in seconds, multinode training, your own containers and Ray, and observability in MLflow. Unity Catalog permissions apply to the training data, the checkpoints and the logs, workloads run with VM-level isolation, and usage shows up in Databricks’ billing tables by workload. Databricks says hundreds of companies use it, among them Robinhood, PicPay, Merck and FactSet.
AWS turned the training loop into API calls. SageMaker AI’s new training session APIs, generally available in N. Virginia, Oregon and Mumbai, let developers write their own post-training algorithm, for example a custom reward for reinforcement learning, by calling operations such as forward_backward(), optim_step() and sample() against a live session. SageMaker handles GPU allocation, distributed execution, recovery and checkpoints, and bills per token processed. Separately, AWS added Muse Glimmer, Qwen 3.8 27B and Ministral 3 to its managed customization service, with supervised fine-tuning, preference optimization and reinforcement fine-tuning.
Snowflake opened ML Jobs to custom containers. Teams can now build, validate and register their own runtime images and run ML Jobs on them, generally available since October 22, with the same option still in preview for notebooks.
| You control | The platform takes over | |
|---|---|---|
| Databricks AI Runtime | Code, containers, frameworks, data access policy | GPU capacity, health checks, launch, isolation, billing records |
| SageMaker training session APIs | The training algorithm itself, step by step | Cluster, distribution, recovery, checkpoints, per-token billing |
| SageMaker managed customization | Data, model choice, technique | Almost everything else |
| Snowflake ML Jobs, custom images | Dependencies and packages in the image | Compute and the governed data perimeter |
| All of them | Evaluation, data provenance, the decision to deploy | Nothing |
The change is where models get built
These are different products with one direction: training is becoming a governed service of the data platform or the cloud, rather than a separate cluster a team owns. For enterprises, the most important effect is not speed. It is that the training data no longer has to leave the place where its access rules, lineage and audit trail already live. A fine-tuned model built inside Unity Catalog or a Snowflake account inherits the controls of the data it learned from, which is an easier conversation with a privacy office than a copy on a GPU vendor’s storage.
There is a second driver, and Databricks names it: coding agents now launch training experiments. When an agent can start a hundred runs overnight, as we saw in agents running experiments at Third Moment, the infrastructure has to be fast to start, cheap to stop, and governed without a person approving each job.
What does not get easier
Evaluation. None of these services tells you whether the trained model is better at your task. Microsoft’s own test, where a small model improved 85% at extraction and the frontier still won, is the reminder: customization is a bet that has to be measured against prompting a stronger model, on your data, before it goes anywhere near production.
Cost discipline. Serverless GPUs remove idle clusters, not consumption. Per-token or per-second billing makes a runaway experiment loop visible, but only if someone reads the billing records. Agent-launched training needs the same budgets with alerts as agent-launched inference.
Responsibility for custom images. A custom container is your software supply chain. Snowflake’s custom images and Databricks’ bring-your-own containers move dependency updates and vulnerability management to your team.
Regions. SageMaker’s training session APIs launched in three regions, none in Europe or South America, and its managed customization in four. Where training runs is a data residency decision, and today the choice is narrower than the announcements suggest.
The practical order
If your company is considering fine-tuning or post-training this year, the sequence that holds up is: write the evaluation first, on your own examples; try the cheapest adaptation, often a better prompt or retrieval; train only when the evaluation says prompting has plateaued; and run training where the data’s governance already applies. The platforms have made the third step much easier. The first one is still yours.