MLOps Overview | NVIDIA Kumo

Turn on MLOps to keep a record of every model your Kumo Engine code trains and every batch of predictions it makes. Kumo stores each artifact under one location you choose, records each training and prediction run in your experiment tracker, and, when you name a registry, registers each trained model there. With these records you can answer which model and which data produced a table of scores, compare versions of a model, and promote a new version to production.

MLOps requires Kumo Engine 1.1.0 or newer.

You keep your existing code. You create one kumo.MLOps configuration and run your workflow inside with kumo.mlops(cfg):. This section continues from Training: you need a graph, a predictive query, and a model plan that train successfully.

What Kumo Records

With MLOps turned on, the calls you already make store their results under an artifact root, such as s3://<bucket>/kumo:

Call	What is stored
`graph.snapshot()`	The graph snapshot
`query.generate_training_table()`	The training table
`trainer.fit()`	The model bundle
`trainer.predict()`	The prediction run: its scores and the rows it skipped

Each stored artifact also records where it came from, so a model leads back to its training table, graph snapshot, and source table versions.

The experiment tracker records each fit and each prediction run as a run, with parameters, metrics, and a run card that summarizes the result. When you name a model registry, it receives each trained model as a new version, and Kumo moves an alias, such as candidate, to it.

How the Pieces Fit Together

A model moves through the same loop on every platform:

Fit. trainer.fit() inside the block stores the model and records the fit, with its per-epoch curves and holdout metrics.
Register. With a registry configured, the fit registers the model as a new version and moves your registration alias to it.
Promote. You compare the new version with the one in production and move the serving alias, such as champion, when it is better.
Score. A scheduled job loads the model by its serving alias and calls trainer.predict(), which stores and records the prediction run, as described in Score in Batch.
Monitor. You compare a prediction run’s scores with the model’s holdout scores and with earlier runs, and measure realized accuracy once outcomes are known, as described in Monitor Predictions.

Supported Platforms

Platform	Experiment tracking	Model registry
Self-managed MLflow	Any MLflow tracking server	The server’s MLflow Model Registry
Databricks	MLflow in the Databricks workspace	Unity Catalog
Amazon SageMaker	SageMaker managed MLflow: a tracking server or an MLflow App	The same server’s or app’s registry
Snowflake (preview)	Snowflake Experiment Tracking	Snowflake Model Registry

Snowflake support is in preview: it uses Snowflake ML APIs that are themselves in preview, and its behavior can change.

The artifact root can be on local or mounted disk, Amazon S3, Google Cloud Storage, a Unity Catalog volume, or a Snowflake internal stage. The artifact root and the tracker do not need to be on the same platform; for example, a fit on your own GPU machine can store its model in S3 and record its run in Databricks.

Next Steps

To run fits and scoring as scheduled jobs, start from a recipe: Databricks Jobs, SageMaker Pipelines, or Snowflake Tasks (preview). MLOps Reference lists the stored layout, manifest fields, and drift definitions.

Turn On MLOps

Choose an artifact root, wrap your workflow in a block, and read stored artifacts back.

Track Runs

Record fits and prediction runs in MLflow or Snowflake and read what each run shows.

Score in Batch

Score a registered model with trainer.predict() so every batch is recorded.

Monitor Predictions

Compare scores with the holdout and earlier runs, and measure realized accuracy.

Warehouse Monitors

Chart exported evaluations in Databricks or Snowflake monitoring.