NVIDIA Kumo Tabular predicts tables with no training and dethrones gradient-boosted trees
NVIDIA ships an open foundation model for tabular data that classifies and regresses in a single forward pass, with no training and no feature engineering, and ranks first on four benchmarks. Evaluate it on your own held-out data before replacing XGBoost or LightGBM.
September 29, 2026. NVIDIA publishes Kumo Tabular, an open foundation model for tabular data prediction, available on Hugging Face. September 2026. The model, offered in three sizes from 28M to 215M parameters, predicts labels for new rows in a single forward pass — no training, no tuning, and no feature engineering. September 29, 2026. It ranks first on all four benchmarks TabArena, BeyondArena, TALENT, and ScoringBench. Why it matters: for the first time, an open foundation model goes head-to-head with the gradient-boosted trees — XGBoost, LightGBM — that have ruled tabular data for two decades.
Twenty years of trees, a quiet fatigue
Tabular data is the backbone of enterprise machine learning. Customer records, transactions, sensor logs, claims, and orders all live in tables; predicting churn, default, demand, or price from them is among the most common machine learning tasks in industry. For two decades, that work has been done with gradient-boosted trees, and it has worked well.
But the lifecycle around those models has barely changed. Every new question means collecting labels, engineering features, searching hyperparameters, validating, and deploying a model that knows nothing about tables in general and learns each task from scratch. NVIDIA borrows here the argument that flipped NLP and then vision: a model pretrained on millions of tables can read a labeled table as context and predict new rows without updating a single weight. That is in-context learning, applied to tables.
Why tabular foundation models took so long
Text and images had their foundation models as early as 2018 and 2020; tables had almost nothing before 2023. The reason is structural. Text tokenizes into regular tokens, images into patches; a table, by contrast, mixes heterogeneous columns — an identifier, a date, an amount, a category — whose semantics depend on each dataset’s schema. Pretraining on “millions of tables” therefore requires normalizing arbitrary schemas, an obstacle that TabPFN and then TabICL began to clear by encoding cells through Fourier features rather than vocabulary tokens.
Kumo Tabular sits exactly in that lineage, with a difference in scale: massive pretraining on artificial data, and model sizes — up to 215M parameters — an order of magnitude beyond the early attempts. That scale explains the leap in performance on TabArena.
A Transformer built around a table’s structure
Kumo Tabular is a Transformer organized around the shape of a table, with three kinds of attention — column, row, and in-context — in the lineage of TabICL and TabPFN. To predict a label it must do three things: understand what each value means within its column, understand how the columns of a row interact, and relate the labeled context rows to the unlabeled query rows.
The mechanism runs through two encoding steps. First, cell embedding: a group of cells becomes a token, and both numerical and categorical values pass through Fourier features — sines and cosines of learned frequencies — with separate weights for each type. Missing values are handled specially, with no imputation. Second, row embedding: each row becomes an embedding by alternating two kinds of attention, column attention to situate a value in its column’s distribution (is a “42” typical or extreme?) and row attention to learn the interactions between features. Column-attention cost grows linearly with the number of rows, which bounds the model’s scalability.
Performance that clears the state of the art
The numbers are the heart of the announcement. NVIDIA ran all three Kumo Tabular sizes with default settings against the full TabArena leaderboard, spanning tuned gradient-boosted trees, AutoGluon, and the latest tabular foundation models. The result: Kumo Tabular ranks first overall with an ELO of 1950, while running 17× faster than LimiX-2 under a uniform single-RTX 6000 Pro setup.
The other three benchmarks tell the same story. BeyondArena: an ELO of 1418 and a 7.78% “improvability” score, first on the leaderboard. TALENT: the top overall ranking across classification accuracy, log-loss, and regression RMSE. ScoringBench, which measures predictive distributions: the Large and Medium sizes rank first and second.
The model is released under the OpenMDW-1.1 license for commercial use, and runs through the open-source sdm (structured-data-models) library, which downloads the weights on first use:
import sdm # structured-data-models
table = sdm.TableTensor.from_pandas(pd.load_csv(...), device="cuda")
na_mask = table["target"].isnan()
model = sdm.models.KumoTabular(device="cuda")
pred = model(
x_context=table[~na_mask].drop_columns("target"),
y_context=table[~na_mask, "target"],
x_query=table[na_mask].drop_column("target"),
)A single forward pass also changes the shape of deployment. A tuned gradient-boosted tree requires you to persist model artifacts, serve them behind an endpoint, and retrain on a schedule; Kumo Tabular needs only the weights and the labeled context you supply at call time. For teams that run many small prediction tasks — scoring a new cohort, triaging a queue, flagging anomalies — removing the training-and-retraining loop is the part of the announcement that compounds before the accuracy gains even register.
The trade-off is predictability. A gradient-boosted tree is transparent, fast on CPU, and its failure modes are well understood. Kumo Tabular shifts that risk profile: the model is a black box whose accuracy can drift silently when query rows fall outside its training distribution. That is why the “validate on held-out data” instruction is not boilerplate — it is the price of admission.
The limits to know before you migrate
The announcement is honest about the model’s boundaries. Kumo Tabular handles only numerical and categorical columns; text, images, and timestamps must be turned into features via built-in pre-processing recipes. A single forward pass covers up to 10 classes, which the library extends to any number through error-correcting output codes. Most importantly, accuracy may degrade on tables far beyond the training ranges, or when query rows come from a different distribution than the context rows — so the guidance is to validate accuracy and calibration on your own held-out data before deployment.
That last point matters most for an engineer: Kumo Tabular is not an unconditional replacement. It is a zero-training tool that excels when the task resembles its training data, and that must be benchmarked against a tuned XGBoost on a real validation set before you decide.
What it changes for the ML lifecycle
For a product team, Kumo Tabular’s argument is not just accuracy but a shorter cycle. The classic pipeline — label, engineer features, search hyperparameters, validate, deploy — shrinks here to two steps: provide a labeled table and read the predictions. Provided, as NVIDIA repeats, that you validate calibration on your own held-out data.
The hidden cost is worth measuring. The model runs on GPU — the sdm library is “GPU-native” — whereas an XGBoost fits on a modest CPU. For massive batch prediction, the development time saved is paid back in inference infrastructure. The choice is therefore not “trees or foundation” but “how many different tasks justify a dedicated GPU for tabular inference.”
Verdict
If you run a stream of tabular classification or regression tasks on clean, numerical-and-categorical data, test Kumo Tabular alongside your XGBoost/LightGBM on a held-out validation set: the promise of a single-forward-pass prediction with no feature engineering is measurable in half a day. If your data contains a lot of text, images, or time series, keep your existing pipelines — the model does not cover them natively and demands pre-processing the trees already handle differently. And if you are industrializing prediction, hold on to the decisive criterion: out-of-distribution calibration. A foundation model that answers fast is worth only as much as its reliability on your production data, not its standing on public leaderboards.