AIREITERNVIDIA Kumo Tabular mérite un pilote : ce modèle pour tables uniques est disponible au téléchargement. En revanche, les éléments publics actuels ne permettent pas encore de remplacer CatBoost, LightGBM ou TabPFN en production.
Notre verdict : testez Kumo Tabular, mais gardez le trafic de production où il est
Kumo Tabular mérite d’être évalué si vos données tiennent déjà dans une seule table, que les labels sont disponibles et que vous cherchez à mesurer le gain potentiel d’une prédiction en contexte par rapport à un cycle classique de modélisation. En revanche, la latence stricte, le serving sur CPU uniquement, l’hébergement managé ou les données réparties entre plusieurs tables doivent être traités comme des critères bloquants à vérifier, pas comme des capacités acquises.
Les poids officiels et la documentation de l’API sont disponibles, mais les comparaisons publiques spécifiques à Kumo restent limitées. La seule façon de trancher consiste donc à le valider sur votre propre jeu de test.
Ce que NVIDIA a réellement publié
La fiche du modèle Kumo-Tabular de NVIDIA présente un modèle préentraîné pour la classification et la régression. La documentation officielle de l’API KumoTabular décrit un fonctionnement en contexte : des lignes annotées servent de contexte, puis les lignes à prédire reçoivent leurs résultats sans qu’il soit nécessaire d’ajuster de nouveaux poids pour chaque jeu de données.
Le package public propose des variantes small, medium et large. Le catalogue des modèles de données structurées de NVIDIA indique environ 27 millions à 216 millions de paramètres selon la variante. La fiche du modèle mentionne la licence OpenMDW-1.1 et fournit un parcours d’installation Python ainsi qu’un chemin d’inférence. Pour un usage commercial ou une redistribution, lisez les conditions de la licence au lieu d’assimiler « poids publics » à « utilisation sans restriction ».
Attention à ne pas confondre cette publication avec KumoRFM. Kumo Tabular vise une table unique. La présentation de Kumo Relational par NVIDIA décrit KumoRFM comme un modèle distinct, conçu pour les données relationnelles. La documentation de Kumo Tabular précise explicitement que la prise en charge des tables liées n’est pas disponible.
| Question | Réponse pour Kumo Tabular |
|---|---|
| Tâches principales | Classification et régression |
| Format des entrées | Une table comprenant des lignes de contexte et des lignes de requête |
| Entraînement propre à chaque jeu de données | Non requis pour le parcours de prédiction en contexte |
| Tables liées | Non prises en charge par l’API publique KumoTabular |
| Poids | Publics sur Hugging Face |
| Licence indiquée dans la fiche du modèle | OpenMDW-1.1 |
| Inférence hébergée | Aucun fournisseur d’inférence Hugging Face n’est répertorié |
La fiche officielle du modèle et la page de l’API consultées pour cet article ne publient pas de valeur simple indiquant le nombre maximal de lignes ou de variables. Elles exposent en revanche la configuration du modèle et les restrictions liées aux tâches. Lors du pilote, mesurez donc le nombre de lignes, le nombre de variables, la composition du contexte et des requêtes, la consommation mémoire et le nombre de classes accepté, plutôt que de déduire ces limites à partir d’un autre modèle tabulaire.
Les contraintes qui détermineront son intérêt
L’adéquation de Kumo Tabular dépend de trois contraintes opérationnelles :
- La structure des données : Kumo Tabular ne consomme pas nativement des tables liées. Si les variables prédictives proviennent de clients, de commandes, de produits et d’événements du support, définissez et validez la stratégie d’aplatissement ou d’agrégation avant de comparer les modèles.
- L’échelle de l’inférence : la documentation publique décrit les variantes du modèle et les tâches prises en charge, mais ne fournit pas de tableau validé indépendamment sur le débit en production, la mémoire GPU ou le coût par prédiction. Mesurez l’effet de la taille du contexte sur la latence et la mémoire.
- L’accès au déploiement : les poids et l’interface Python sont publics, mais cela ne correspond pas à une API managée avec un SLA. Les équipes qui ont besoin d’un routage régional, de quotas garantis ou d’une exploitation hébergée par le fournisseur doivent transformer ces exigences en critères explicites du pilote.
Kumo Tabular face à TabPFN et aux modèles entraînés
Dans les sources examinées, aucun résultat public fiable et comparable ne démontre que Kumo Tabular surpasse TabPFN, CatBoost, LightGBM ou XGBoost dans leur version actuelle. Les benchmarks tiers cités servent à concevoir le pilote, pas à tirer des conclusions sur les performances de Kumo.
| Charge de travail | Première comparaison à lancer | Objectif de l’évaluation |
|---|---|---|
| Table unique propre, avec un échantillon annoté petit ou moyen | Kumo Tabular contre TabPFN | Comparer la prédiction en contexte native pour les tables sur le même split |
| Table riche en variables catégorielles | Kumo Tabular contre CatBoost | Utiliser CatBoost comme référence entraînée pour les données catégorielles |
| Scoring batch stable et répété | Kumo Tabular contre LightGBM ou XGBoost | Comparer un modèle en contexte à des modèles entraînés servis en production |
| Signal réparti entre plusieurs tables liées | Référence sur table aplatie contre approche relationnelle | Mesurer la structure utile perdue avec l’agrégation retenue |
| Exploration rapide de schémas | Pilote Kumo Tabular | Vérifier si l’absence de boucle d’entraînement propre à la tâche fait réellement gagner du temps |
La comparaison d’AnoFox a mesuré plusieurs modèles de fondation tabulaires sur un CPU à 8 cœurs. Ils ont devancé les modèles scikit-learn testés d’environ 2 à 7 % sur cinq petits jeux de données, avec un temps d’exécution parfois nettement supérieur. Lors d’un test de churn, l’inférence à chaud de Mitra a ainsi pris 19,3 secondes, contre 0,035 seconde pour la régression logistique.
Un benchmark distinct d’AIMultiple a conclu que TabFM remportait 15 jeux de données sur 19, mais au prix d’environ 40 fois plus de calcul que TabPFN 3 ou TabICLv2. Selon les chiffres publiés, une exécution complète de TabFM coûtait environ 27 $ sur des GPU B200, contre environ 0,65 $ pour TabPFN 3. Là encore, ces résultats indiquent les mesures à recueillir : ils ne constituent pas des résultats pour Kumo.
Un premier test qui tient la route
Utilisez un jeu de test figé et obligez Kumo Tabular à faire ses preuves face à une référence entraînée.
- Figez un seul split d’entraînement et de test, temporel ou stratifié, avant d’essayer les modèles. Gardez les labels du jeu de test indisponibles pendant la prédiction.
- Validez le schéma de la table : colonne cible, valeurs manquantes, colonnes catégorielles, entités en double et variables créées après l’instant de prédiction.
- Lancez Kumo Tabular sur la table brute prise en charge et consignez la variante du modèle, les lignes de contexte et de requête, le nombre de variables, le nombre de classes accepté, la taille des batchs, le matériel, le temps de démarrage à froid, la latence à chaud et la mémoire maximale.
- Lancez CatBoost ou LightGBM sur les mêmes lignes et la même cible. Mesurez séparément le temps de prétraitement, d’entraînement et de prédiction.
- Comparez une métrique adaptée à la tâche : AUROC et calibration pour la classification binaire, macro-F1 pour la classification multiclasse déséquilibrée, MAE ou RMSE pour la régression.
- Répétez le test avec un échantillon de contexte plus petit, puis plus grand. Si la qualité reste stable tandis que la latence augmente fortement, le modèle sera peut-être plus intéressant pour l’exploration que pour le serving.
- Définissez à l’avance trois critères de réussite : gain minimal de métrique, latence p95 maximale et coût maximal de l’infrastructure par batch. Ne passez à l’étape suivante que si Kumo Tabular respecte les trois.
Un benchmark fournisseur ne dispense jamais de vérifier les fuites de données. « Sans feature engineering » ne signifie pas « sans validation des données ».