AIREITERNVIDIA Kumo Tabular ist ein öffentlich herunterladbares Modell für einzelne Tabellen und damit einen Pilotversuch wert. Die bisherigen Erkenntnisse reichen jedoch nicht aus, um CatBoost, LightGBM oder TabPFN im Produktiveinsatz zu ersetzen.
Das praktische Fazit: Kumo Tabular testen, aber noch keinen Produktionsverkehr umstellen
Kumo Tabular eignet sich für einen Test, wenn die Daten bereits in einer Tabelle vorliegen, Labels vorhanden sind und geprüft werden soll, ob Vorhersagen im Kontext den Modellierungsaufwand reduzieren. Strenge Latenzvorgaben, ein reiner CPU-Betrieb, Managed Hosting oder Daten aus mehreren Tabellen sollten dabei als harte Testkriterien gelten. Es wäre voreilig, anzunehmen, dass Kumo Tabular diese Anforderungen automatisch erfüllt.
Die offiziellen Gewichte und die API-Dokumentation sind verfügbar, belastbare öffentliche Vergleiche speziell für Kumo bleiben jedoch rar. Entscheidend ist deshalb ein Test auf dem eigenen Holdout-Datensatz.
Was NVIDIA tatsächlich veröffentlicht hat
NVIDIAs Kumo-Tabular-Modellkarte beschreibt ein vortrainiertes Modell für Klassifikation und Regression. Die offizielle KumoTabular-API-Dokumentation zeigt einen In-Context-Workflow: Beschriftete Zeilen dienen als Kontext, während Abfragezeilen Vorhersagen erhalten, ohne für jeden Datensatz neue Modellgewichte trainieren zu müssen.
Das öffentliche Paket stellt Varianten in den Größen Small, Medium und Large bereit. NVIDIAs Katalog für strukturierte Datenmodelle nennt für diese Varianten ungefähr 27 bis 216 Millionen Parameter. Die Modellkarte führt die OpenMDW-1.1-Lizenz auf und beschreibt Installation und Inferenz mit Python. Wer das Modell kommerziell einsetzen oder weiterverbreiten möchte, sollte die Lizenzbedingungen im Detail prüfen. „Öffentliche Gewichte“ bedeuten nicht automatisch eine uneingeschränkte Nutzung.
Wichtig: Diese Veröffentlichung ist nicht mit KumoRFM gleichzusetzen. Kumo Tabular ist für eine einzelne Tabelle ausgelegt. Die Übersicht zu Kumo Relational beschreibt KumoRFM als separates Modell für relationale Daten. In der Kumo-Tabular-Dokumentation wird die Unterstützung verbundener Tabellen ausdrücklich als nicht verfügbar gekennzeichnet.
| Frage | Antwort von Kumo Tabular |
|---|---|
| Hauptaufgaben | Klassifikation und Regression |
| Eingabeformat | Eine Tabelle mit Kontext- und Abfragezeilen |
| Training pro Datensatz | Für den In-Context-Vorhersagepfad nicht erforderlich |
| Verbundene Tabellen | In der öffentlichen KumoTabular-API nicht unterstützt |
| Gewichte | Öffentlich auf Hugging Face verfügbar |
| In der Modellkarte genannte Lizenz | OpenMDW-1.1 |
| Gehostete Inferenz | Kein Hugging-Face-Inference-Provider aufgeführt |
Die für diesen Artikel geprüfte offizielle Modellkarte und API-Seite nennen keine einfache Obergrenze für Zeilen oder Features. Sie stellen jedoch die Modellkonfiguration und Einschränkungen der unterstützten Aufgaben bereit. Deshalb sollten Zeilenzahl, Feature-Anzahl, Zusammensetzung von Kontext und Abfragen, Speicherverbrauch sowie die akzeptierte Zahl von Klassen im Pilotversuch erfasst werden, statt Werte von einem anderen Tabular-Modell zu übernehmen.
Diese Einschränkungen entscheiden über den praktischen Einsatz
Ob Kumo Tabular in eine bestehende Umgebung passt, hängt vor allem von drei betrieblichen Faktoren ab:
- Datenstruktur: Kumo Tabular verarbeitet verbundene Tabellen nicht nativ. Wenn Vorhersagemerkmale aus Kunden-, Bestell-, Produkt- und Supportdaten stammen, muss die Strategie zum Flattening oder zur Aggregation vor dem Modellvergleich festgelegt und validiert werden.
- Inferenz im großen Maßstab: Die öffentliche Dokumentation beschreibt Modellvarianten und unterstützte Aufgaben, liefert aber keine unabhängig validierte Übersicht zu Produktionsdurchsatz, GPU-Speicher oder Kosten pro Vorhersage. Messen Sie, wie sich die Kontextgröße auf Latenz und Speicherverbrauch auswirkt.
- Zugang und Bereitstellung: Gewichte und Python-Schnittstelle sind öffentlich verfügbar. Das ist jedoch etwas anderes als eine verwaltete API mit SLA. Teams, die regionales Routing, garantierte Kontingente oder einen vom Anbieter betriebenen Dienst benötigen, sollten diese Anforderungen als verbindliche Kriterien für den Pilotversuch definieren.
Kumo Tabular im Vergleich zu TabPFN und trainierten Baselines
Die geprüften Quellen liefern keinen verlässlichen direkten Vergleich, der belegt, dass Kumo Tabular aktuelle Versionen von TabPFN, CatBoost, LightGBM oder XGBoost schlägt. Die genannten Benchmarks Dritter helfen bei der Planung des Pilotversuchs, sind aber kein Leistungsnachweis für Kumo.
| Arbeitslast | Erster Vergleich | Zweck der Evaluation |
|---|---|---|
| Saubere Einzeltabelle mit kleiner oder mittlerer Zahl gelabelter Beispiele | Kumo Tabular gegen TabPFN | In-Context-Vorhersagen für Tabellen auf demselben Split vergleichen |
| Tabelle mit vielen kategorialen Merkmalen | Kumo Tabular gegen CatBoost | CatBoost als trainierte Baseline für kategoriale Daten verwenden |
| Stabile, wiederholte Batch-Bewertung | Kumo Tabular gegen LightGBM oder XGBoost | Ein In-Context-Modell mit Baselines für das Serving trainierter Modelle vergleichen |
| Signal verteilt über verbundene Tabellen | Baseline für flache Tabelle gegen relationalen Ansatz | Messen, ob die gewählte Aggregation nützliche Strukturen verliert |
| Schnelle Erkundung verschiedener Schemata | Pilotversuch mit Kumo Tabular | Prüfen, ob der Verzicht auf einen aufgabenspezifischen Trainingszyklus tatsächlich Zeit spart |
Der AnoFox-Vergleich untersuchte mehrere Tabular-Foundation-Modelle auf einer CPU mit 8 Kernen. Auf fünf kleinen Datensätzen lagen sie etwa 2–7 % vor den getesteten scikit-learn-Modellen, benötigten dafür aber teilweise deutlich mehr Laufzeit. In einem Churn-Test dauerte die Warm-Inferenz von Mitra 19,3 Sekunden, während die logistische Regression 0,035 Sekunden benötigte.
Ein separater AIMultiple-Benchmark kam zu dem Ergebnis, dass TabFM bei 15 von 19 Datensätzen gewann, dafür aber ungefähr 40-mal so viel Rechenleistung wie TabPFN 3 oder TabICLv2 benötigte. Für einen vollständigen TabFM-Lauf wurden rund 27 US-Dollar auf B200-GPUs angegeben, gegenüber etwa 0,65 US-Dollar für TabPFN 3. Auch diese Zahlen zeigen lediglich, welche Messwerte erhoben werden sollten. Sie sind keine Ergebnisse für Kumo.
So sieht ein belastbarer erster Test aus
Verwenden Sie einen festen Holdout-Datensatz und lassen Sie Kumo Tabular seinen Platz neben einer trainierten Baseline verdienen.
- Legen Sie vor dem ersten Modellvergleich genau einen zeitbasierten oder stratifizierten Train-/Test-Split fest. Die Testlabels dürfen während der Vorhersage nicht verfügbar sein.
- Prüfen Sie das Tabellenschema: Zielspalte, fehlende Werte, kategoriale Spalten, doppelte Entitäten sowie alle Felder, die erst nach dem Vorhersagezeitpunkt entstehen.
- Führen Sie Kumo Tabular mit der unveränderten unterstützten Tabelle aus. Erfassen Sie Modellvariante, Kontext- und Abfragezeilen, Feature-Anzahl, akzeptierte Klassenzahl, Batchgröße, Hardware, Kaltstartzeit, Warm-Latenz und maximalen Speicherverbrauch.
- Führen Sie CatBoost oder LightGBM mit denselben Zeilen und demselben Ziel aus. Erfassen Sie die Vorverarbeitungszeit getrennt von Trainings- und Vorhersagezeit.
- Vergleichen Sie eine zur Aufgabe passende Metrik: AUROC und Kalibrierung für binäre Klassifikation, Macro-F1 bei unausgeglichenen Multiclass-Aufgaben sowie MAE oder RMSE für Regression.
- Wiederholen Sie den Test mit einer kleineren und einer größeren Kontextstichprobe. Bleibt die Qualität stabil, während die Latenz stark steigt, eignet sich das Modell möglicherweise eher für Exploration als für Serving.
- Definieren Sie vorab drei Bestehenskriterien: den minimalen Metrikgewinn, die maximal zulässige p95-Latenz und die maximalen Infrastrukturkosten pro Batch. Setzen Sie Kumo Tabular nur dann weiter ein, wenn alle drei Kriterien erfüllt sind.
Ein Hersteller-Benchmark ersetzt keine Prüfung auf Data Leakage. „Kein Feature Engineering“ bedeutet nicht „keine Datenvalidierung“.