What is NVIDIA Kumo Relational?
NVIDIA Kumo Relational is a pretrained relational foundation model for predictive machine-learning tasks over connected database tables. Its focus is not conversation or text generation. Instead, it analyzes structured data such as customers, accounts, transactions, products, events or other entities connected through primary-key and foreign-key relationships.
A conventional tabular model often expects a carefully prepared flat table for one specific task. Kumo Relational is intended to work with a relational representation in which several tables retain their connections. NVIDIA describes this representation as a relational graph: rows become entities or records, and table relationships become links that help provide context for a prediction.
The model can use labeled context examples supplied with a prediction request. In practical terms, an application can provide historical rows for which the outcome is known, then ask for predictions on new rows. Predictive Query Language, or PQL, is used to describe the prediction target and the relevant context. NVIDIA provides access through a Kumo Relational NIM inference service, a Python client and REST endpoints.
Where it fits in NVIDIA's model lineup
Kumo Relational belongs to NVIDIA's Kumo family of relational foundation-model technology and is distributed as an NVIDIA NIM. The supplied NVIDIA API reference identifies the model as Kumo Relational and lists NIM version 1.0.0. The same reference reports 31 million parameters.
This positioning matters because Kumo Relational is not a smaller language model intended to compete on chat, writing or coding. It is a specialized model for structured relational prediction. Its value comes from using table structure and relationships directly, rather than forcing a database workload into a text prompt or treating every table as an unrelated collection of columns.
The model was listed as available through a free NVIDIA API endpoint and as a downloadable NIM deployment in the supplied research. The API reference lists a release date of August 18, 2026. Availability, licensing and deployment terms can change, so production users should verify the current terms on NVIDIA's model page and API documentation.
What can Kumo Relational predict?
NVIDIA documents several categories of predictive work:
- Binary classification: choosing between two outcomes, such as whether a customer is likely to churn.
- Multiclass classification: selecting one outcome from several categories.
- Regression: estimating a numerical value, such as a risk score or expected amount.
- Forecasting: predicting future values using historical and time-related data.
- Temporal link prediction: estimating whether a relationship between entities will occur or change over time.
Depending on the task, outputs can include predictions, probabilities, scores, rankings, quantiles, embeddings and diagnostic explanations. This makes the model relevant to more than a simple yes-or-no classifier. For example, a recommendation workflow may need ranked candidates, while a forecasting workflow may need a range of plausible values rather than one point estimate.
Examples of suitable applications include churn scoring, fraud detection, risk assessment, recommendations, customer or account classification, numerical prediction, demand or event forecasting and relationship prediction in temporal data. These examples describe the documented task scope; they should not be interpreted as a guarantee of accuracy for a particular dataset.
How the input and prediction workflow works
Kumo Relational accepts relational data in JSON array format together with declared schemas. A request can identify entity and related tables, specify primary-key and foreign-key relationships, provide labeled context rows and include rows for which predictions are required.
This is different from sending a prompt to a language model. There is no conventional token-based context window reported for Kumo Relational, and the supplied specifications do not identify a maximum output-token limit. Instead, the effective input size depends on the relational data, schema, context examples, prediction request and deployment configuration supported by the NIM.
A typical workflow is to define the tables and their relationships, express the prediction target in PQL, provide historical examples and submit one or more prediction rows. The returned result can then be used by an application for scoring, ranking, forecasting or downstream analysis. NVIDIA also documents batch prediction through the client, with ordinary batches supporting up to 1,000 entities and larger jobs configurable for appropriate deployments.
Because the model relies on relationships and historical context, data modeling is an important part of using it. A database with meaningful keys, reliable timestamps and sufficiently representative labels is a better fit than an isolated spreadsheet with no useful relationships. The supplied documentation does not provide a universal accuracy threshold or a promise that adding more tables will improve every task.
Main strengths and limitations
Strengths
- Designed for connected data: the model can use relationships among tables instead of requiring every feature to be flattened manually into one dataset.
- Multiple predictive task types: classification, regression, forecasting and temporal link prediction are covered by the documented workflow.
- In-context adaptation: labeled context examples can help describe the task at prediction time without requiring a separate task-specific model for every use case.
- Deployment flexibility: users can access a hosted NVIDIA endpoint or deploy a downloadable NIM, subject to the applicable environment and licensing terms.
- Operational outputs: probabilities, rankings, quantiles, embeddings and diagnostic explanations can be more useful in production systems than a single label.
- Batch scoring: the client supports batch prediction, including ordinary batches of up to 1,000 entities according to NVIDIA's documentation.
Limitations
- Not a language model: it is not intended for natural-language generation, chat, summarization, general-purpose coding or other text-first tasks.
- No conventional token specification: NVIDIA does not provide a token context length or maximum output-token figure in the supplied research. Capacity should instead be evaluated through the relational input and deployment configuration.
- Structured data preparation is required: users need schemas, relationships, context rows and prediction rows in the expected format. This is more involved than sending a simple text prompt.
- Limited tool scope: no tool-calling or function-calling capability is documented. The model does not independently browse the web or operate external applications.
- Not a multimodal generator: the supplied specifications identify no image, audio or video input or output. Its outputs are structured predictions and related analytical results.
- Task quality depends on the data: poor keys, missing relationships, weak labels, leakage or unrepresentative historical examples can undermine the usefulness of predictions.
Modalities, reasoning and coding capability
Kumo Relational uses structured relational input rather than text, images, audio or video. The supplied model record marks text, image, audio and video input as unsupported, and it does not identify direct image, audio or video output. Its output is structured predictive information, which may include scores, rankings, embeddings and explanations.
It is therefore misleading to evaluate this model using ordinary chat-model categories. The editorial reasoning score in the supplied database is 4 out of 10 and the coding score is 2 out of 10. These are internal editorial assessments, not NVIDIA benchmark results. The low coding assessment reflects the model's purpose: it can support a structured prediction service, but it is not a general programming assistant. Likewise, its reasoning value is expressed through relational inference and prediction rather than open-ended chain-of-thought conversation.
No tool-use or function-calling capability is documented. Applications can call the REST API or client SDK, but that is an integration method rather than a model feature that lets Kumo Relational choose and execute arbitrary tools.
Speed, cost and pricing
The supplied research does not identify public per-token input or output prices. That pricing model would also be a poor description of this product because Kumo Relational is not a conventional token-based language API. NVIDIA documents a free API endpoint and a downloadable NIM, but users should check the current endpoint limits, account requirements, infrastructure costs and licensing terms before treating deployment as cost-free.
Editorial database scores rate speed at 7 out of 10 and cost at 7 out of 10. These scores are approximate judgments for cataloging purposes, not published NVIDIA measurements. The practical cost trade-off depends on whether a workload uses the hosted endpoint or operates a downloadable NIM, how much relational data is sent, how often predictions run and what hardware is used for deployment.
Kumo Relational may offer a favorable capability-to-cost trade-off when many related tables support repeated predictive tasks and a team wants one relational foundation model rather than multiple independently engineered pipelines. A simpler single-table model may be more efficient for a small, stable dataset, while a language model may be more appropriate when the required output is natural language.
When to choose Kumo Relational
Choose Kumo Relational when the core problem is prediction over a connected database and the relationships among records contain useful signal. It is especially relevant when you need several task types—such as classification, regression, forecasting or link prediction—over related entities, and want to express tasks using context examples and PQL.
It is also a reasonable candidate when deployment flexibility matters. The hosted NVIDIA endpoint can provide a relatively direct evaluation path, while the downloadable NIM is relevant to teams that need to manage deployment in their own environment. Batch prediction makes it more suitable for recurring scoring jobs than for a conversational interface.
Another option may be more appropriate when the workload is primarily text generation, document understanding, software development, image analysis or audio processing. A conventional tabular machine-learning model may be preferable when the data is already clean, flat and narrowly focused on one task. A dedicated forecasting or graph-learning system may also be easier to operate when the use case requires specialized controls that are not documented for Kumo Relational.
Bottom line
NVIDIA Kumo Relational is a specialized structured-data model, not a general-purpose AI assistant. Its distinguishing feature is the ability to make several kinds of predictions from connected tables using relational structure, labeled context examples and PQL. The model is most compelling for database-centered applications such as churn, fraud, recommendations, risk scoring, forecasting and temporal relationships.
Its main trade-off is specialization. Users gain a workflow designed around relational prediction, but must supply well-defined schemas and relationships and should not expect chat, code generation, multimodal processing, tool calling or token-based context controls. For teams with connected data and repeatable predictive tasks, that specialization can be the reason to choose it; for text-first or unstructured workloads, another model type is likely a better fit.