Scope & boundaries
This guide covers the environment where your own models are built and trained — notebooks, feature engineering, experiment tracking and the compute beneath them.
It does not cover foundation models you consume rather than train (Generative AI & LLM Platforms), the lifecycle after a model exists — deployment, monitoring, retraining (MLOps Platforms), or the human work and the workforce economics behind training data (AI Data Labeling & Annotation Services).
Executive Summary
Choose an ML platform by where your data already sits and who will build the models, then test how one model travels from experiment to monitored production on your own data.
An ML platform is the software a company uses to build, train, deploy and monitor its own machine learning models. It holds the notebooks and training compute, records experiments, keeps a registry of approved models, serves those models to applications, and watches them for drift once they run. Databricks defines an ML platform as the combined infrastructure, tooling, and governance layer that supports the full ML lifecycle, from raw data to production models.
Choose on five things: where your data lives, since training next to it avoids copying it; who builds the models, data scientists in code or analysts in a visual tool; how a model is approved, deployed and rolled back; how drift is detected and retraining starts; and what the price meter counts as usage grows.
The vendors divide by where they start: the three cloud providers’ ML services, a lakehouse platform, a data cloud, a visual and code platform for mixed teams, an automated modeling and governance platform, and an experiment tracking tool that runs beside any of them. Several product names in this market have changed, and section 5 records each change from the vendor’s own pages. Running models after deployment is covered in more depth in the MLOps Platforms guide.
What Does an ML Platform Do?
An ML platform carries a model from raw data to a monitored prediction service, and back to retraining when the model drifts. The model code is the small part. Google Cloud states that only a small fraction of a real-world ML system is composed of the ML code. The rest is data collection and checks, feature pipelines, training compute, a model registry, serving and monitoring.
Google Cloud states that the real challenge isn't building an ML model, but building an integrated ML system and continuously operating it in production. A paper published by NeurIPS states that machine learning offers a fantastically powerful toolkit for building useful complex prediction systems quickly, argues that it is dangerous to think of these quick wins as coming for free, and finds that it is common to incur massive ongoing maintenance costs in real-world ML systems. An ML platform makes that maintenance routine: the same steps, run the same way, with a record of each run.
Models also degrade after release in ways ordinary software does not. Google Cloud states that ML models can lose performance not only because of suboptimal coding but also because of constantly evolving data profiles. The platform needs monitoring that compares live inputs and predictions with the data the model was trained on, and a way to retrain and redeploy when the two drift apart.
Maturity is measured by how much of the cycle runs without hand-offs. Google Cloud calls a process in which building and deploying ML models is entirely manual the basic level of maturity, or level 0. Google Cloud describes a disconnection between ML and operations in which the process separates the data scientists who create the model from the engineers who serve the model as a prediction service. Google Cloud states that the goal of level 1 is to perform continuous training of the model by automating the ML pipeline. Most buyers are moving from level 0 to level 1, and the platform should make that step without a rewrite.
Governance requirements usually come from outside the data science team. NIST states that the AI Risk Management Framework (AI RMF) is intended for voluntary use and to improve the ability to incorporate trustworthiness considerations into the design, development, use, and evaluation of AI products, services, and systems. Map the controls your risk team expects, such as approval before deployment, lineage and model documentation, to the platform features that produce the evidence for each.
Can You Build an ML Platform From Open Source?
Yes, and many commercial platforms run the same open-source projects underneath. A self-built platform usually combines an experiment tracker and model registry, a pipeline orchestrator, a feature store, a serving layer and monitoring, on Kubernetes or cloud compute. Assembling the first version takes weeks. Patching, upgrading, securing and supporting it takes a platform team for as long as the models run.
The two most common foundations are run as open, foundation-backed projects. MLflow states that it is backed by the Linux Foundation and has been fully committed to open source for 5+ years. Kubeflow states that it is composed of modular, open source projects that form the Kubernetes-native stack for data and AI workloads.
Commercial platforms read and write the same formats, which limits lock-in when a model has to move. Dataiku lists exporting models to Python, Java, MLflow and PMML for scoring outside of DSS. Ask every vendor which open-source components it runs, which versions, how quickly it adopts new releases, and whether your experiment history and models export in an open format.
Building fits a company with a platform team that already runs Kubernetes, a small number of model types, and engineers who will own the stack for years. Buying fits a company that wants data scientists to start on a supported service, needs approval and audit records quickly, or cannot staff on-call cover for the platform itself.
| Component | What it does | Cost when you build it | Ask a vendor |
|---|---|---|---|
| Experiment tracking | Records parameters, metrics and artifacts for every training run | A tracking server, its database and storage, kept highly available | Can runs be exported with their artifacts in an open format? |
| Model registry | Holds versioned models with stage, owner and approval status | Access rules and an approval step you write and maintain | Is the approval logged, and can the author of a model approve it? |
| Pipeline orchestration | Runs data preparation, training, evaluation and deployment as one job | Scheduler upgrades and failed-run alerting | Which triggers start a retraining run: schedule, new data, a drift alert? |
| Feature store | Serves the same features to training and to live predictions | Offline and online stores kept in step | How does it prevent skew between training and serving features? |
| Serving | Hosts models as endpoints or batch jobs | Autoscaling, GPU scheduling and rollback | Does it support canary or split traffic, and automatic rollback? |
| Monitoring | Tracks drift, data quality and model performance | Baselines, alert rules and dashboards per model | Which drift metrics are built in, and where do alerts go? |
What Should You Compare in ML Platforms?
Compare platforms on the path a model takes after the notebook: how it is registered and approved, how it is deployed and rolled back, and how it is watched in production. Training features matter less in a shortlist, because every platform here trains models with the common open-source frameworks.
Registry and approval. A registry records each model version with its owner, stage and approval status, and the approval is evidence for an audit. AWS states that SageMaker Model Registry automatically logs approval workflows for audit and compliance. Databricks states that the model registry in Unity Catalog provides centralized governance and manages the model lifecycle, including deployments. Snowflake states that the Snowflake Model Registry allows for the logging and management of all your ML models, regardless of whether they are trained on Snowflake or other platforms. Ask whether the registry accepts models trained elsewhere, since most companies already have some.
Release and rollback. A new model version should reach some traffic before all of it. Microsoft states that traffic can be split across multiple deployments, allowing new model versions to be tested on some traffic first, with more traffic after confidence in the new model is established. DataRobot states that you can compare experimental models with deployed ones on production data and hot swap them in without downtime. Ask how a release is reversed, and how long the previous version stays available.
Monitoring and features. Drift detection needs a baseline from training data and an alert that reaches someone who can act. Snowflake states that ML Observability lets you track models in production, monitor performance and drift metrics, and set alerts for performance thresholds. DataRobot states that it sends automated alerts for data drift, latency, or service degradation. Training-serving skew is a related failure, where a model sees features computed differently in production than in training. Snowflake states that the Snowflake Feature Store supports both batch and low-latency online feature retrieval and ensures consistency between training and inference to reduce training-serving skew.
| Capability | What to test | Why it matters |
|---|---|---|
| Where training runs | Training next to the data you already store, without copying it out | Data copies add cost, delay and another place to secure |
| Notebooks and tools | The languages, notebooks and IDEs your team already uses | Decides how fast existing data scientists become productive |
| Experiment tracking | Parameters, metrics and artifacts for every run, comparable across runs | Lets a result be reproduced months later |
| Model registry | Versions, stages, owners and logged approvals, including models trained elsewhere | The approval record is audit evidence |
| Deployment | Real-time endpoints, batch scoring, split traffic and rollback | Decides how safely a new version reaches users |
| Monitoring | Drift, data quality and performance alerts with a baseline per model | Catches models that degrade after release |
| Feature store | One definition of each feature for training and serving | Prevents training-serving skew |
| Access and lineage | Roles, audit logs and lineage from source data to deployed model | Answers who changed what, and what a model was trained on |
Vendors in ML Platforms
Representative vendors include AWS SageMaker (Amazon SageMaker AI), Azure Machine Learning, Databricks Mosaic AI, Dataiku, DataRobot, Google Vertex AI (Gemini Enterprise Agent Platform), Snowflake Cortex and Weights & Biases (CoreWeave Forge). The list is alphabetical, is not a ranking, and is not for sale. How we choose vendors
Each vendor below is placed by the product it starts from. Several names changed recently, and the roster prints a former name beside the current one where badges and older pages still use it.
The three cloud providers sell ML services inside their clouds. AWS states that on December 03, 2024, Amazon SageMaker was renamed to Amazon SageMaker AI. AWS states that on December 03, 2024, Amazon released the next generation of Amazon SageMaker, a unified platform for data, analytics, and AI. The name now covers both products, so confirm which one a proposal prices. AWS advises using Bedrock for serverless access to frontier and open-weight models through a single API with pay-per-token pricing, and SageMaker AI when you need full control over model weights, training infrastructure, serving runtimes and GPU types. AWS states that governance is built into every stage, including MLflow tracking, a Model Registry with IAM-enforced approval gates, Clarify for bias detection and Model Monitor for drift.
Google states that with the introduction of Gemini Enterprise Agent Platform some Vertex AI products and features have been renamed, and lists Vertex AI Platform under its new name, Gemini Enterprise Agent Platform. Google states that Gemini platform provides purpose-built MLOps tools for data scientists and ML engineers to automate, standardize, and manage ML projects. Google lists Pipelines to orchestrate workflows, Model Registry to manage any model, Feature Store to serve, share and reuse ML features, and monitoring of models for input skew and drift. Google states that notebooks in Gemini platform, including Colab Enterprise or Workbench, are natively integrated with BigQuery, providing a single surface across all data and AI workloads.
Microsoft describes Azure Machine Learning as a cloud service that accelerates and manages the machine learning (ML) project lifecycle. Microsoft states that both Azure Machine Learning studio and Microsoft Foundry allow you to work with LLMs. Microsoft states that Prompt flow in Microsoft Foundry and Azure Machine Learning will be retired on April 20, 2027, and is no longer recommended for new development. Check whether any current project depends on it.
The data platforms bring model training to data that is already stored with them. Databricks announced that OpenAI GPT 5 models are now generally available in Mosaic AI Model Serving. In its current machine learning documentation, Databricks lists Model Serving to deploy custom models and LLMs as REST endpoints with automatic scaling and GPU support. Databricks states that Foundation Model Fine-tuning has reached end of life and is no longer supported, and recommends AI Runtime, a serverless, GPU-backed environment, for training and fine-tuning foundation models. Snowflake describes Snowflake ML as an integrated set of capabilities for end-to-end machine learning in a single platform on top of your governed data. Snowflake states that Cortex AI lets you build gen AI applications directly in SQL or via APIs.
Two platforms are built for teams that mix analysts and data scientists. Dataiku states that it gives business experts and engineers one place to build the models, AI, and agents a business runs on, from raw data to production AI. Dataiku states that its Visual ML and AutoML let analysts and data scientists build, validate, and compare models using code-free and assisted workflows. Dataiku states that Dataiku DSS can be downloaded and installed on your own Linux server, deployed either on-premises or on any cloud. Dataiku states that it connects to Snowflake, Databricks, Redshift, S3, APIs, and enterprise systems. DataRobot states that it lets you explore and test hundreds of models and variations to find the most accurate for your use case. DataRobot describes orchestrating compute dynamically to deploy agents anywhere: edge, cloud, or on-prem. DataRobot states that it automates adherence to regulations like the EU AI Act with centralized oversight, pre-built policies, and customizable documentation for all your AI assets.
Experiment tracking runs beside whichever platform trains the model. Weights & Biases states that it is now part of CoreWeave Forge. CoreWeave states that CoreWeave Forge is the development layer of the CoreWeave platform, bringing together the former Weights & Biases, OpenPipe, and Marimo products in one connected environment. CoreWeave tells existing Weights & Biases account holders that their credentials, projects, and wandb.ai links carry over, and that Weights & Biases Models is now a part of CoreWeave Forge. On the Weights & Biases Models page, CoreWeave states that flexible deployment options provide control across managed cloud, private cloud, on premises, and hybrid environments.
| Vendor | Approach | Where it fits |
|---|---|---|
| DataRobot | Automated modeling and governance | Automated model testing, deployment, drift alerts and compliance documentation |
| AWS SageMaker (Amazon SageMaker AI) | Cloud provider ML service | Managed training, registry with approval gates, endpoints and drift monitoring on AWS |
| Azure Machine Learning | Cloud provider ML service | ML lifecycle service on Azure, billed for the compute and Azure services it uses |
| Google Vertex AI (Gemini Enterprise Agent Platform) | Cloud provider ML service | Pipelines, registry, feature store and monitoring, with notebooks integrated with BigQuery |
| Snowflake Cortex | Data cloud | Snowflake ML for training and serving, and Cortex AI for gen AI in SQL |
| Weights & Biases (CoreWeave Forge) | Experiment tracking and registry | Experiment tracking, sweeps and registry beside any training environment |
| Databricks Mosaic AI | Lakehouse platform | Model Serving, MLflow and the Unity Catalog registry on the Databricks platform |
| Dataiku | Visual and code platform | Visual ML, AutoML and code with governance, self-managed or on Dataiku Cloud |
Eight vendors across six approaches; AWS, Microsoft and Google share the cloud provider approach. All eight vendors from the previous edition stay, each now described from its own pages. The approaches were chosen first and the vendors selected to represent them; no row is for sale. The roster check for this edition covered 18 companies and open-source projects, and any vendor among them can describe its own product in the Spotlight below.
How Are ML Platforms Priced?
Vendors meter different units: compute time, normalized processing units, consumption credits, or seats. Ask every vendor to price the same year of work: the training runs you expect, the endpoints that stay online, the data you store, and the number of people who build models.
AWS states that with SageMaker AI you pay only for what you use, choosing between on-demand pricing with no minimum fees or upfront commitments and Amazon SageMaker Savings Plans in exchange for a commitment to a consistent amount of usage. Microsoft states that there is no additional charge to use Azure Machine Learning, but that along with compute you incur separate charges for other Azure services consumed, such as Azure Blob Storage, Azure Key Vault, Azure Container Registry and Azure Application Insights. Google states that a node hour represents the time a virtual machine spends running your prediction job or waiting in an active state, as an endpoint with one or more models deployed, to handle prediction or explanation requests. An endpoint that waits for requests is billed while it waits.
Databricks defines a Databricks Unit (DBU) as a normalized unit of processing power on the Databricks Lakehouse Platform used for measurement and pricing purposes. Snowflake states that it operates on a consumption-based pricing model. On the data platforms, the bill depends on the size and runtime of the compute you choose, so model the training schedule before you compare quotes.
Experiment tracking is usually priced by plan. CoreWeave lists its Pro plan, for professionals working to optimize AI applications and models, starting at $60/month, billed monthly. CoreWeave states that CoreWeave Forge Pro is designed for early-stage teams and organizations with fewer than 50 employees. Larger organizations should expect an enterprise quote. The visual and automated modeling platforms in this guide publish no list prices on the pages checked for it, so ask for a quote on the same workload.
| Meter | You pay for | Grows with | Where it goes wrong |
|---|---|---|---|
| Instance time | Each notebook, training job and endpoint by the time it runs | Training frequency and endpoints online | Idle notebooks and endpoints left running |
| Normalized processing units | Units consumed by each workload, at a rate per unit | Data volume and compute size | A large cluster chosen for a small job |
| Consumption credits | Credits drawn by compute and storage | Warehouse size and runtime | Feature pipelines refreshing more often than needed |
| Seats or plans | Each user, or a plan with set limits | Team size | Plan limits that force the next tier |
| Underlying cloud services | Storage, registries, key management and logging used by the platform | Models, artifacts and logs kept | Costs billed outside the platform line and missed in the budget |
How Do You Roll Out an ML Platform?
Start with one team and one model that already runs in production somewhere, so the pilot has a baseline to beat. Most of the effort goes into access to data, the approval process and moving existing models, not into training. The phases below assume a first production release in about four months.
Connect the platform to the pilot data under your existing access rules. Set up workspaces, roles, cost alerts and the registry, and decide who may approve a model for production.
Retrain one existing model on the platform. Track every run, register the result, and have someone other than its author approve it. Compare accuracy and cost with the current version.
Deploy the model to part of the traffic, set drift and performance alerts from its training baseline, and rehearse a rollback. Route alerts to the team that will act on them.
Move further models in order of business value. Automate retraining for models whose data changes often, retire old serving paths, and review platform costs each month.
What should you ask vendors about ML Platforms?
Put these questions in the RFP, and ask for each answer to be shown on your pilot model rather than on a vendor demo.
-
Is most of your data on one cloud or one data platform?Yes Start with that provider’s ML service or the data platform’s own ML features, and test them against one alternative.No Weight platforms that run on several clouds and connect to your data where it is.
-
Will analysts build models as well as data scientists?Yes Include a visual and code platform, and check that both groups share one registry and approval process.No Weight notebook, code and pipeline features, and experiment tracking.
-
Do auditors or model risk reviewers check your models?Yes Weight logged approvals, lineage and generated documentation, and confirm which plan includes them.No Weight release speed, drift alerts and cost control.