NVIDIA Releases Kumo Tabular Open-Weights Tabular Foundation Model: Training-Free Single Forward-Pass Prediction, Self-Reported First on Four Benchmarks
According to an official NVIDIA blog post dated September 29, 2026, NVIDIA released Kumo Tabular, a tabular foundation model in three sizes from 28 million to 215 million parameters, published under the OpenMDW-1.1 license and hosted on Hugging Face. It requires no training or feature engineering, performing classification and regression in a single forward pass; the blog claims it ranks first on four benchmarks including TabArena.
What changed
According to an official NVIDIA blog post dated September 29, 2026, NVIDIA released Kumo Tabular, a tabular foundation model in the Kumo Structured model family. Weights are available on Hugging Face, with accompanying code released through an open-source structured data library. The model is pretrained entirely on synthetic tables: each training table is sampled from a structural causal model, with numeric columns, categorical columns, and a target variable generated through random causal graphs and randomly drawn functions, while remaining nodes stay hidden; post-processing then applies column correlations, outlier clipping, and missing-value injection, and a tree ensemble check removes tables with no learnable signal. The architecture is a Transformer for tabular structure, using column attention, row attention, and context attention; numeric and categorical values are embedded via Fourier features, and missing values are not imputed. Context rows attend to each other, while query rows attend only to context rows, so context key-value pairs can be computed once and reused; a length-aware attention temperature scales each query logarithmically with the number of keys to keep attention sharp on large tables with tens of thousands of rows. The model comes in Small/Medium/Large tiers at roughly 28 million to 215 million parameters. Classification and regression are trained as two separate models, using cross-entropy loss and quantile loss respectively; the regression model outputs 999 quantiles to provide point predictions and uncertainty estimates. The blog claims it ranks first on TabArena with an ELO of 1950 and is 17 times faster than LimiX-2 under a unified evaluation environment on a single RTX 6000 Pro; it ranks first on BeyondArena with 1418 ELO and a 7.78% Improvability score; it ranks first in the combined TALENT ranking across classification accuracy, classification log loss, and regression RMSE; and on ScoringBench, Large and Medium take first and second place. The blog also notes the model supports only numeric and categorical columns, covers at most 10 classes in a single forward pass, and relies on the library's error-correcting output codes to extend to more classes.
What it means for developers
For developers, the immediate impact is a changed way of approaching tabular modeling: Kumo Tabular has no REST inference endpoint, but is called in a Python environment through a new GPU-native library. The first run downloads weights from the Hub; inputs are labeled context rows plus query rows to predict, with no weight updates, feature engineering, or hyperparameter search. If the blog's claims hold, the earliest affected scenarios are tabular tasks with scarce labels that need a fast baseline, such as churn prediction, demand forecasting, and risk scoring, because what is saved is the entire training pipeline rather than just training time. As described in the blog, predictions depend only on the context and the query row itself, not on other query rows in the same batch, meaning context key-value pairs can be cached and reused so that continuous scoring only computes the context once; but this also means context quality and coverage directly determine the output, and choosing the wrong context rows is harder to notice than choosing the wrong hyperparameters. Note: the model does not appear in KimiSeek's current live catalog and cannot be called through this site's API; it can only be deployed locally or on self-hosted GPU services. Figures such as the 17x speedup and 1950 ELO are vendor self-reports, and the evaluation protocol and data splits are not detailed in the post, so they cannot be directly extrapolated to specific business data. OpenMDW-1.1 is a license, not a conclusion that "open weights automatically means commercially usable"; the specific terms must be read and confirmed independently. Treat Kumo Tabular as a supplementary candidate rather than an unconditional replacement for existing gradient-boosted trees: it is safer to run comparative experiments first on small-to-medium tables with sufficient labeled rows and mostly numeric and categorical columns.
Integration and evaluation
The following are conditional suggestions, not conclusions confirmed by the vendor. First, whether to set up a local GPU inference path: the reported fact to recognize is that the model runs locally as weights through an open-source library and depends on a GPU environment. The choice to make is whether to add a local inference pipeline or continue using existing per-task trained tree models; the key precondition that changes the choice is whether the team already has usable GPUs and enough tabular tasks with high per-task training costs; a testable criterion is comparing accuracy or regression error on your own holdout set while recording inference latency and GPU memory usage. If local inference shows no accuracy advantage and unacceptable latency, it is not worth maintaining a new pipeline for it. Second, choosing the number of context rows: the reported fact is that the third training stage extended context to 60,000 rows and specifically designed a length-aware attention temperature. The choice to make is how many context rows to invest per prediction; the precondition is table size and latency budget, since larger context increases GPU memory and time costs; the evaluation criterion is fixing a query set and measuring accuracy and latency with hundreds, thousands, and tens of thousands of context rows to see whether accuracy improves with more context and whether the latency curve is acceptable. If accuracy saturates early, adding more context only wastes GPU memory. Third, adoption boundaries under distribution shift: the reported fact is that the blog notes accuracy may degrade when query rows and context rows come from different distributions or when tables far exceed the training range. The choice to make is whether to place the model in controlled, same-distribution tasks or in open-distribution tasks across time periods and channels; the precondition is whether you can construct and maintain a context sample pool close to production. The evaluation criterion is constructing a holdout set that clearly deviates from the training distribution and observing whether error and the model's output quantile intervals grow together and whether calibration still holds. If intervals become miscalibrated, fall back to a supervised trained model or narrow the scope of use. Fourth, tasks with more than 10 classes: the reported fact is that a single forward pass covers at most 10 classes, and beyond that the library extends to arbitrary class counts via error-correcting output codes, effectively splitting the task into multiple binary problems. The choice to make is whether to use the model directly or choose another approach; the precondition is whether the target cardinality and prediction latency can tolerate multiplied overhead; the evaluation criterion is separately measuring error and time for the multi-class subtask and comparing with existing approaches before deciding.
Limits and open questions
To be clear: Kumo Tabular does not currently appear in KimiSeek's live catalog and cannot be called through this site; the blog describes a local deployment path where the vendor releases weights and an open-source library on Hugging Face, and the two should not be conflated. The benchmark rankings, ELO, speed multiples, and parameter sizes in the article all come from NVIDIA's self-reported blog results and have not been independently reproduced; the evaluation environment was a single RTX 6000 Pro, and different hardware or data splits could yield different conclusions. OpenMDW-1.1 is a license agreement, and open weights alone confer no authorization; whether it meets your commercial conditions requires reading the license text yourself. The model supports only numeric and categorical columns; text, images, and timestamps rely on built-in preprocessing to convert them into features, and a single forward pass covers at most 10 classes, beyond which error-correcting output codes are needed. The blog itself also acknowledges that accuracy may degrade outside the training range or when query and context distributions differ, so before launch be sure to validate accuracy and calibration with your own holdout data. In addition, the training recipe and synthetic data generator are said to be released soon, but as of the post's publication they had not been made public, so fully reproducing the training process remains infeasible.
Illustrations from the original report
