NVIDIA publie Kumo Tabular, un modèle de base tabulaire à poids ouverts : prédiction en une passe sans entraînement
Selon un blog officiel de NVIDIA publié le 29 septembre 2026, le modèle de base tabulaire Kumo Tabular est disponible en trois tailles de 28 à 215 millions de paramètres, publié sous licence OpenMDW-1.1 sur Hugging Face ; sans entraînement ni ingénierie des caractéristiques, une seule propagation avant suffit pour la classification et la régression, et le blog le classe premier sur quatre benchmarks dont TabArena.
Ce qui change
Selon un blog officiel de NVIDIA publié le 29 septembre 2026, NVIDIA lance le modèle de base tabulaire Kumo Tabular, issu de la série Kumo Structured, dont les poids sont disponibles sur Hugging Face et le code associé publié via une bibliothèque open source pour données structurées. Le modèle est entièrement préentraîné sur des tables synthétiques : chaque table d'entraînement est échantillonnée à partir d'un modèle causal structurel, avec des graphes causaux aléatoires et des fonctions tirées aléatoirement pour générer des colonnes numériques, catégorielles et la variable cible, les autres nœuds restant masqués, puis un post-traitement applique corrélations entre colonnes, troncature des valeurs aberrantes et injection de valeurs manquantes, et un contrôle par ensemble d'arbres écarte les tables sans signal apprenable. L'architecture est un Transformer adapté aux structures tabulaires, avec attention par colonnes, par lignes et contextuelle ; les valeurs numériques et catégorielles sont encodées via des caractéristiques de Fourier, sans imputation des valeurs manquantes ; les lignes de contexte s'observent entre elles, les lignes de requête n'observent que les lignes de contexte, ce qui permet de calculer les clés-valeurs du contexte une fois et de les réutiliser ; une température d'attention sensible à la longueur, augmentant logarithmiquement avec le nombre de clés, maintient l'attention précise sur de grandes tables de plusieurs dizaines de milliers de lignes. Le modèle existe en trois tailles Small/Medium/Large, d'environ 28 à 215 millions de paramètres ; classification et régression sont deux modèles distincts, entraînés respectivement avec une perte d'entropie croisée et une perte quantile, la régression produisant 999 quantiles pour donner une prédiction ponctuelle et une estimation d'incertitude. Le blog annonce la première place sur TabArena avec un ELO de 1950 et une vitesse 17 fois supérieure à LimiX-2 dans un environnement d'évaluation unifié sur une seule RTX 6000 Pro ; la première place sur BeyondArena avec 1418 ELO et un score d'améliorabilité de 7,78 % ; la première place sur TALENT pour le classement combiné de la précision de classification, de la perte logarithmique de classification et du RMSE de régression ; et les première et deuxième places sur ScoringBench pour les tailles Large et Medium. Le blog précise aussi que le modèle ne prend en charge que les colonnes numériques et catégorielles, qu'une propagation avant couvre au plus 10 classes, et que les cas multi-classes sont étendus par codage de sortie à correction d'erreur de la bibliothèque.
Conséquences pour les développeurs
Pour les développeurs, l'effet direct est un changement de mode d'accès à la modélisation tabulaire : Kumo Tabular n'a pas d'interface d'inférence REST, mais s'appelle dans un environnement Python via une nouvelle bibliothèque native GPU, les poids étant téléchargés depuis le Hub au premier lancement ; l'entrée est constituée de lignes de contexte étiquetées plus les lignes de requête à prédire, sans mise à jour de poids, sans ingénierie des caractéristiques et sans recherche d'hyperparamètres. Si le blog dit vrai, les scénarios les plus touchés sont les tâches tabulaires à étiquettes rares nécessitant une ligne de base rapide, comme la prédiction d'attrition, la prévision de demande ou le scoring de risque, car c'est toute la chaîne d'entraînement qui est supprimée, pas seulement le temps d'entraînement. D'après la description du blog, la prédiction ne dépend que du contexte et de la ligne de requête elle-même, pas des autres lignes de requête du même lot : les clés-valeurs du contexte peuvent donc être mises en cache et réutilisées, un seul calcul de contexte suffisant pour un scoring continu ; mais cela signifie aussi que la qualité et la couverture du contexte déterminent directement la sortie, et choisir de mauvaises lignes de contexte est plus difficile à détecter que choisir de mauvais hyperparamètres. À noter : le modèle n'apparaît pas dans le catalogue en ligne actuel de KimiSeek et ne peut pas être appelé via l'API de ce site, seulement déployé en local ou sur un service GPU auto-hébergé ; les chiffres du blog, comme la vitesse 17 fois supérieure et l'ELO de 1950, sont des déclarations du fournisseur, le protocole d'évaluation et le découpage des données n'étant pas détaillés dans l'article, et ils ne peuvent pas être extrapolés directement à des données métier spécifiques ; OpenMDW-1.1 est une licence, et des poids ouverts n'impliquent pas automatiquement un usage commercial, les clauses précises devant être lues et confirmées soi-même. Considérez Kumo Tabular comme un candidat complémentaire plutôt qu'un remplacement inconditionnel des arbres à gradient boosting existants : une expérience comparative sur des tables petites ou moyennes, avec suffisamment de lignes étiquetées et principalement des colonnes numériques et catégorielles, sera plus prudente.
Intégration et évaluation
Les suggestions suivantes sont conditionnelles et non des conclusions confirmées par le fournisseur. Premièrement, faut-il mettre en place une voie d'inférence GPU locale : le fait rapporté est que le modèle s'exécute localement sous forme de poids via une bibliothèque open source et dépend d'un environnement GPU. Le choix à faire est d'ajouter une chaîne d'inférence locale ou de continuer avec les modèles d'arbres entraînés tâche par tâche ; la condition qui change ce choix est de savoir si l'équipe dispose déjà de GPU disponibles, si les tâches tabulaires sont assez nombreuses et si le coût d'entraînement par tâche est assez élevé ; le critère mesurable est de comparer sur un ensemble de validation propre la précision ou l'erreur de régression des deux approches, en enregistrant la latence d'inférence et l'occupation mémoire ; si l'inférence locale n'apporte pas de gain de précision et que la latence est inacceptable, cela ne vaut pas la peine de maintenir une nouvelle chaîne pour elle. Deuxièmement, le compromis sur le nombre de lignes de contexte : le fait rapporté est que la troisième phase d'entraînement étend le contexte à 60 000 lignes et conçoit spécialement une température d'attention sensible à la longueur. Le choix à faire est le nombre de lignes de contexte investies par prédiction ; la condition est la taille de la table et le budget de latence, un contexte plus grand augmentant les coûts mémoire et temporels ; le critère d'évaluation est, sur un ensemble de requêtes fixe, de mesurer la précision et la latence avec quelques centaines, quelques milliers puis des dizaines de milliers de lignes de contexte, pour voir si la précision s'améliore avec le contexte et si la courbe de latence reste acceptable ; si la précision sature prématurément, ajouter du contexte ne fait que gaspiller de la mémoire. Troisièmement, les limites d'adoption en cas de dérive de distribution : le fait rapporté est que le blog signale une possible baisse de précision lorsque les lignes de requête et de contexte suivent des distributions différentes ou que la table dépasse largement la plage d'entraînement. Le choix à faire est de placer le modèle sur des tâches contrôlées de même distribution ou sur des tâches ouvertes inter-périodes et inter-canaux ; la condition est la capacité à construire et maintenir un pool d'échantillons de contexte proche de la production ; le critère d'évaluation est de construire un ensemble de validation nettement hors distribution, d'observer si l'erreur et l'intervalle quantile de sortie augmentent ensemble et si la calibration tient toujours ; si les intervalles se dégradent, il faut revenir à un modèle entraîné supervisé ou réduire le périmètre d'usage. Quatrièmement, les tâches de classification à plus de 10 classes : le fait rapporté est qu'une propagation avant couvre au plus 10 classes, au-delà la bibliothèque étend à un nombre arbitraire de classes par codage de sortie à correction d'erreur, ce qui revient à découper la tâche en plusieurs problèmes binaires. Le choix à faire est d'utiliser directement ce modèle ou une autre solution ; la condition est la cardinalité de la colonne cible et l'acceptabilité d'un surcoût multiplié en latence ; le critère d'évaluation est de mesurer séparément l'erreur et le temps des sous-tâches multi-classes, puis de comparer avec les solutions existantes avant de décider.
Limites et points à confirmer
À préciser : Kumo Tabular n'apparaît pas actuellement dans le catalogue en ligne de KimiSeek et ne peut pas être appelé via ce site ; le blog décrit une voie de déploiement local avec publication des poids sur Hugging Face et une bibliothèque open source par le fournisseur, les deux ne doivent pas être confondus. Les classements aux benchmarks, les ELO, les facteurs de vitesse et les tailles de paramètres proviennent de résultats auto-déclarés dans le blog NVIDIA, sans reproduction indépendante, l'environnement d'évaluation étant une seule RTX 6000 Pro ; un changement de matériel ou de découpage des données peut donner des conclusions différentes. OpenMDW-1.1 est un contrat de licence, et des poids ouverts ne constituent en soi aucune autorisation ; il faut lire le texte de la licence pour savoir si vos conditions d'usage commercial sont remplies. Le modèle ne prend en charge que les colonnes numériques et catégorielles ; les textes, images et horodatages dépendent d'un prétraitement intégré pour être convertis en caractéristiques, et une propagation avant couvre au plus 10 classes, au-delà il faut un codage de sortie à correction d'erreur. Le blog reconnaît lui-même une possible baisse de précision hors de la plage d'entraînement ou lorsque les distributions des requêtes et du contexte diffèrent ; il est donc indispensable de valider précision et calibration sur vos propres données de validation avant mise en production. En outre, la recette d'entraînement et le générateur de données synthétiques sont annoncés comme prochainement publiés, mais n'étaient pas publics au moment de la parution de l'article ; reproduire complètement l'entraînement reste donc impossible.
Illustrations de l’article original
