NVIDIA Kumo Tabular prédit des tableaux sans entraînement et détrône les arbres boostés
NVIDIA publie un modèle de fondation ouvert pour données tabulaires qui classe et régresse en une seule passe, sans entraînement ni feature engineering, et se classe premier sur quatre benchmarks. Évaluez-le sur vos données historiques avant de remplacer XGBoost ou LightGBM.
29 septembre 2026. NVIDIA publie Kumo Tabular, un modèle de fondation ouvert pour la prédiction sur données tabulaires, disponible sur Hugging Face. Septembre 2026. Le modèle, décliné en trois tailles de 28 à 215 millions de paramètres, prédit les étiquettes de nouvelles lignes en une seule passe, sans entraînement, sans réglage et sans feature engineering. 29 septembre 2026. Il se classe premier sur les quatre benchmarks TabArena, BeyondArena, TALENT et ScoringBench. Pourquoi c’est important : pour la première fois, un modèle de fondation ouvert rivalise frontalement avec les arbres à gradient boosté — XGBoost, LightGBM — qui règnent sur les données tabulaires depuis deux décennies.
Vingt ans d’arbres, une lassitude silencieuse
Les données tabulaires sont l’épine dorsale du machine learning d’entreprise. Les dossiers clients, les transactions, les journaux de capteurs, les sinistres et les commandes vivent dans des tableaux ; prédire le churn, le défaut, la demande ou le prix à partir d’eux est l’une des tâches les plus répandues de l’industrie. Depuis deux décennies, ce travail se fait avec des arbres à gradient boosté, et il fonctionne bien.
Mais le cycle de vie de ces modèles n’a presque pas changé. Chaque nouvelle question exige de collecter des étiquettes, de concevoir des variables, de chercher des hyperparamètres, de valider puis de déployer un modèle qui ne sait rien des tableaux en général et réapprend chaque tâche depuis zéro. NVIDIA reprend ici l’argument qui a fait basculer le NLP puis la vision : un modèle pré-entraîné sur des millions de tableaux peut lire un tableau étiqueté comme contexte et prédire les nouvelles lignes sans mettre à jour un seul poids. C’est l’in-context learning, appliqué aux tables.
Pourquoi les modèles de fondation tabulaires ont mis si longtemps
Le texte et les images ont eu leurs modèles de fondation dès 2018 et 2020 ; les tableaux, presque rien avant 2023. La raison est structurelle. Un texte se découpe en jetons réguliers, une image en patchs ; une table, elle, mêle des colonnes hétérogènes — un identifiant, une date, un montant, une catégorie — dont la sémantique dépend du schéma de chaque jeu de données. Pré-entraîner sur « des millions de tables » suppose donc de normaliser des schémas arbitraires, un obstacle que TabPFN puis TabICL ont commencé à lever en encodant les cellules par des caractéristiques de Fourier plutôt que par des jetons de vocabulaire.
Kumo Tabular s’inscrit exactement dans cette lignée, avec une différence d’échelle : un pré-entraînement sur données artificielles massives, et des tailles de modèles — jusqu’à 215 millions de paramètres — sans commune mesure avec les premiers essais. C’est cette échelle qui explique le saut de performance sur TabArena.
Un Transformer construit autour de la structure d’un tableau
Kumo Tabular est un Transformer organisé autour de la forme d’un tableau, avec trois types d’attention — colonne, ligne et contexte — dans la lignée des travaux TabICL et TabPFN. Pour prédire une étiquette, il doit accomplir trois choses : comprendre ce que chaque valeur signifie dans sa colonne, comprendre comment les colonnes d’une ligne interagissent, et relier les lignes de contexte déjà étiquetées aux lignes de requête sans étiquette.
Le mécanisme passe par deux étapes d’encodage. D’abord, l’encodage de cellule : un groupe de cellules devient un jeton, et les valeurs numériques comme catégorielles traversent des caractéristiques de Fourier — sinus et cosinus de fréquences apprises — avec des poids séparés pour chaque type. Les valeurs manquantes sont traitées à part, sans imputation. Ensuite, l’encodage de ligne : chaque ligne devient un plongement en alternant deux attentions, la colonne pour situer une valeur dans la distribution de sa colonne (un « 42 » est-il typique ou extrême ?) et la ligne pour apprendre les interactions entre caractéristiques. Le coût de l’attention de colonne croît linéairement avec le nombre de lignes, ce qui borne la scalabilité du modèle.
Des performances qui dépassent l’état de l’art
Les chiffres sont le cœur de l’annonce. NVIDIA a évalué les trois tailles de Kumo Tabular avec les réglages par défaut contre l’intégralité du classement TabArena, qui couvre des arbres boostés réglés, AutoGluon et les derniers modèles de fondation tabulaires. Résultat : Kumo Tabular se classe premier avec un ELO de 1950, tout en tournant 17 fois plus vite que LimiX-2 dans une configuration uniforme sur une seule RTX 6000 Pro.
Sur les trois autres benchmarks, le constat est identique. BeyondArena : un ELO de 1418 et un score d’« améliorabilité » de 7,78 %, en tête du classement. TALENT : premier rang global en précision de classification, en log-loss et en RMSE de régression. ScoringBench, qui mesure la qualité des distributions prédictives : les tailles Large et Medium occupent les première et deuxième places.
Le modèle est libéré sous licence OpenMDW-1.1, autorisant l’usage commercial, et fonctionne via la bibliothèque open source sdm (structured-data-models), qui télécharge les poids au premier usage :
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"),
)Les limites à connaître avant de migrer
L’annonce est honnête sur les frontières du modèle. Kumo Tabular ne traite que les colonnes numériques et catégorielles ; texte, images et horodatages doivent être convertis en caractéristiques via des recettes de pré-traitement intégrées. Une passe avant couvre jusqu’à 10 classes, que la bibliothèque étend à un nombre quelconque par des codes de sortie correcteurs d’erreurs. Et surtout, la précision peut se dégrader sur des tableaux très éloignés des plages d’entraînement ou quand les lignes de requête proviennent d’une distribution différente de celle du contexte — la consigne est donc de valider la précision et la calibration sur ses propres données avant tout déploiement.
Ce dernier point est le plus important pour un ingénieur : Kumo Tabular n’est pas un remplacement inconditionnel. C’est un outil de zéro entraînement qui excelle quand la tâche ressemble à celles de ses données d’entraînement, et qu’il faut confronter à un XGBoost réglé sur un jeu de validation réel avant de décider.
Ce que ça change pour le cycle de vie ML
Pour une équipe produit, l’argument de Kumo Tabular n’est pas seulement la précision mais le raccourcissement du cycle. Le pipeline classique — étiqueter, concevoir des variables, chercher des hyperparamètres, valider, déployer — se réduit ici à deux étapes : fournir un tableau étiqueté et lire les prédictions. À condition, répétée par NVIDIA, de valider la calibration sur ses propres données retenues.
Il faut néanmoins mesurer le coût caché. Le modèle s’exécute sur GPU — la bibliothèque sdm est « GPU-native » — alors qu’un XGBoost tient sur un CPU modeste. Pour une prédiction par lots massive, le gain de temps de développement se paie en infrastructure d’inférence. Le choix n’est donc pas « arbres ou fondation », mais « combien de tâches différentes justifient un GPU dédié à l’inférence tabulaire ».
Verdict
Si vous enchaînez des tâches de classification ou de régression tabulaires sur des données propres, numériques et catégorielles, testez Kumo Tabular en parallèle de votre XGBoost/LightGBM sur un jeu de validation tenu à l’écart : la promesse d’une prédiction en une seule passe, sans feature engineering, est mesurable en une demi-journée. Si vos données contiennent beaucoup de texte, d’images ou de séries temporelles, gardez vos pipelines existants — le modèle ne les couvre pas nativement et exige un pré-traitement que les arbres traitent déjà autrement. Et si vous industrialisez la prédiction, retenez le critère décisif : la calibration hors distribution. Un modèle de fondation qui répond vite n’a de valeur que s’il reste fiable sur vos données de production, pas seulement sur les classements publics.