Kumo Relational predicts from linked tables without training a new model for each task. NVIDIA's docs say the hosted route sends sampled records to the endpoint, while the Snowflake route keeps data inside the customer's account.
Predicting churn, fraud or demand usually means building a separate model for each question. NVIDIA now offers one pretrained model that reads linked tables and takes examples with each request.
Where the data goes will matter more than accuracy when a bank first approves a route. NVIDIA's documentation for Kumo Relational says its hosted route, a packaged inference service called a NIM, sends the records selected for each request to the NIM endpoint.
Snowflake says its own route keeps data inside its perimeter. Enterprises will choose on that boundary, not on benchmarks, and the only benchmark on offer comes from the model's builders.
Kumo Relational is a pretrained model that predicts from linked tables. It learns each task from examples sent with the request, so no new model is trained per question.
The Hugging Face card says it handles classification and regression and combines row embeddings with relational message passing. NVIDIA's docs describe the flow as related tables, then a relational graph, then a prediction task.
The NIM takes a sample of rows and returns predictions. The model adapts through the examples in the request and does not update its weights, which the docs call in context learning.
The NIM and Snowflake data paths
On the NIM route, the client samples records and sends them to the endpoint, so the endpoint operator sees those rows. NVIDIA's docs add that data boundary and security controls depend on where the NIM and connector are deployed.
The docs also say to use HTTPS when an API key or sensitive data crosses a network boundary. Where the NIM runs is the customer's choice, so someone has to make and approve that decision.
The Snowflake route removes the hosting decision. Snowflake's post says customers can use Kumo Relational and Kumo Engine in Snowflake Notebooks. It says training, scoring and data all stay inside Snowflake's security and governance perimeter. Predictions are written back to Snowflake tables.
Snowflake says Kumo learns from tables, the keys that connect them and the timing of events. Teams need not flatten that structure into one wide table. Snowflake lists churn, fraud detection, demand forecasting and product recommendation as core tasks.
Snowflake also pitches ease of use. It says NVIDIA's verified agent skills for its CoCo assistant let teams describe a prediction task in plain language and receive a runnable notebook. That widens the pool of people who can start a model, and each of them works inside the account's existing controls.
Snowflake's worked example is a training job. It trains a graph model with Kumo Engine to predict which active customers will buy again within 90 days, using four tables. The NIM uses the in context flow instead.
Where a separate party operates the NIM endpoint, two parties see the rows. Snowflake says its route keeps them inside the customer's account.
Snowflake says the work runs on GPU compute pools in its container runtime, governed by the same controls as its other resources. The customer relies on Snowflake's GPUs instead of running an endpoint. Snowflake's post gives no price for that.
The research model and its licences
Kumo Relational is built on a research model from April. NVIDIA's blog of 21 October announced a Kumo family of open weight models and libraries for structured business data. The Hugging Face model card says Kumo Relational is based on KumoRFM-2.
The paper on KumoRFM-2 was submitted to arXiv on 14 April. Its authors include Jure Leskovec and Matthias Fey.
What arrived on 21 October is the family launch. It brought the Kumo Engine library, a NIM on build.nvidia.com and partner routes with Snowflake and Databricks.
The weights were already on Hugging Face. They have been there since early October, and the repository's first release commit is dated 28 September.
Kumo Relational sits under two licences. Kumo Relational finetunes pretrained TabICLv2 weights, which carry a BSD-3-Clause licence. Its own weights are released under OpenMDW 1.1, and the card does not call the model open source.
NVIDIA calls Kumo Engine an open library stack. Snowflake calls it an open source package for training graph neural networks at scale.
What the accuracy evidence shows
The accuracy evidence is limited compared with the adoption list. NVIDIA names Cognite, Coinbase, Databricks, DoorDash, Revolut and Tubi among the first to work with Kumo models.
NVIDIA also says Snowflake customers are already using them. Snowflake lists Affirm, National Oilwell Varco, VideoAmp and Yieldmo as customers benefiting. None of those statements comes with a number.
The one number is from the April paper. Its authors say KumoRFM-2 outperforms supervised and foundational approaches by up to 8% across 41 benchmarks. That is a ceiling from the people who built the model.
That paper describes the base model, not the released weights, which finetune TabICLv2. The model card carries no benchmark table.
Trained models still win on a single task with enough data, and NVIDIA keeps that door open. Its docs let a customer train its own task specific model with Kumo Engine, and the paper says the model can be fine tuned.
Gradient boosted trees can also win on one well funded task. The in context model wins on the long tail of questions that never justify a dedicated model.
Each request on that long tail ships context rows, so approval turns on data classes, not on the model. Snowflake's post also quotes Vanja Josifovski, NVIDIA's vice president of graph engineering. He says the most accurate predictions come from learning on relational structure directly rather than discarding it.
Snowflake's notebooks route is live. NVIDIA's developer page for Kumo lists a Databricks setup guide for Kumo Engine.
Until a customer publishes accuracy or latency on its own tables, the data path is the clearest difference a risk team can weigh. A bank will approve the route that keeps rows in the account first, and a published result on a customer's own tables is what would reopen that choice.