NVIDIA Kumo Relational: Foundation-Modell sagt direkt auf Datenbanken voraus

Worum es geht

NVIDIA hat Kumo Relational veröffentlicht, ein vortrainiertes „Relational Foundation Model“. Es macht Vorhersagen direkt auf relationalen Datenbanken, also Datenbanken mit mehreren verknüpften Tabellen, etwa Nutzer, Bestellungen und Produkte. Typische Aufgaben sind Kundenabwanderung (Churn), Nachfrage oder Betrugserkennung. Das Modell braucht laut NVIDIA kein aufgabenspezifisches Training, kein Feature Engineering (manuelles Ableiten von Kennzahlen) und kein Zusammenpressen der Tabellen in eine einzige. Es ist ab sofort verfügbar, Gewichte liegen auf Hugging Face, Code auf GitHub.

Warum Foundation-Modelle für strukturierte Daten

NVIDIA zieht eine Parallele zu Sprachmodellen: Früher brauchte jede Textaufgabe ein eigenes Modell samt Pipeline, heute ersetzen LLMs das weitgehend. Dasselbe soll für Tabellendaten gelten, und zwar aus drei Gründen (Herstellerangaben):

• Genauigkeit: Auf RelBench-V1-Klassifikationsaufgaben liegt Kumo Relational im Schnitt knapp 4 AUROC-Punkte vor Gradient-Boosted Trees (z. B. XGBoost) auf von Experten gebauten Features. Auf SAP SALT schlägt es XGBoost auf entwickelten Features um 7 MRR-Punkte ohne Anpassung und um 13 nach Fine-Tuning.
• Einfachheit: Ein Modell ersetzt viele Einzel-Pipelines. Eine neue Vorhersage wird zur Abfrage statt zum Projekt.
• Agenten: Agenten können über die Predictive Query Language (PQL) Vorhersagefragen stellen, etwa welcher Kunde abwandert.

So funktioniert das Modell

Die meisten Modelle für Tabellendaten arbeiten auf einer flachen Tabelle. Kumo Relational arbeitet dagegen direkt auf der Datenbank und beachtet Tabellen, Fremdschlüssel und Zeitstempel. Es lernt per In-Context-Learning: Zur Laufzeit bekommt es Beispiele, die jeweils einen Teilgraphen um eine Entität zu einem Zeitpunkt mit dem bekannten Ergebnis verbinden (z. B. „dieser Nutzer ist abgewandert“).

Drei Schritte:

1. Automatische Kontexterzeugung: Aufgaben werden in PQL formuliert, einer deklarativen Sprache (man sagt, was, nicht wie). Das System spielt historische Datenbankzustände ab und gibt dem Modell nur Daten vor dem Stichzeitpunkt; so wird Datenleck (Data Leakage) verhindert.
2. Denken innerhalb von Tabellen: Ein leichtes Netz nutzt Spalten- und Zeilen-Attention, um relevante Spalten und Zeilen zu erkennen und Rauschen zu filtern.
3. Denken über Tabellen hinweg: Ein größeres Netz verteilt Zeilen-Embeddings per Graph-Attention über Primär-/Fremdschlüssel-Beziehungen, danach folgt Cross-Sample-Attention über die Kontextbeispiele. Da dies auf Embeddings statt auf jeder Zelle läuft, vermeidet das Design quadratische Kosten.

Training mit synthetischen Daten

Vielfältige relationale Datenbanken sind selten öffentlich. Deshalb wurde das Modell komplett auf synthetischen Daten vortrainiert, schrittweise von Einzeltabellen zu komplexeren Strukturen. Der Generator baut auf PluRel (ICML 2026) auf: Er erzeugt ein Schema, Fremdschlüssel-Verknüpfungen wie in echten Daten und Spaltenwerte aus strukturellen Kausalmodellen mit zeitlichen Trends und Abhängigkeiten zwischen Tabellen. Da die Erzeugung leicht ist, sind die Trainingsdaten praktisch unbegrenzt. Der Trainingsverlust folgt einem Potenzgesetz, und die Gewinne übertragen sich laut NVIDIA auf echte Datenbanken.

Ergebnisse

Getestet wurde auf 41 Aufgaben in 15 Datenbanken aus RelBench V1 und V2, SAP SALT und 4DBInfer (E-Commerce, Medizin, Unternehmen, Soziales, Akademisches). Keiner dieser Datensätze kam im Vortraining vor. Laut NVIDIA schlägt das Modell die stärksten überwachten Modelle bei Klassifikation und Regression und ist das beste In-Context-Modell im RelBench-Leaderboard. Auf RelArena-α (Stand 21.09.2026) liegt es auf der Pareto-Front aus Genauigkeit und Effizienz und ist bei ähnlicher Genauigkeit etwa 430-mal schneller als rtl-plurel.

Auf SAP SALT übertrifft es große AutoGluon-Ensembles um 8 % MRR, mit Fine-Tuning um 16 %. Es funktioniert mit nur 0,2 % der Trainingsdaten als Kontext, bleibt stabil, wenn bis zu 75 % der Fremdschlüssel-Links entfernt werden, und verliert kaum durch zusätzliche verrauschte Spalten.

Nutzung und Lizenz

Das Modell läuft in-memory, über Datenbank- und Warehouse-Konnektoren oder über kumo-engine, das laut NVIDIA über 500 Mrd. Zeilen per Memory-Mapped-I/O mit bis zu 5 GB/s verarbeitet. Die GPU-native Bibliothek structured-data-models (pip install) lädt die Gewichte beim ersten Einsatz von Hugging Face. Alternativ läuft es als NVIDIA NIM, angesprochen über den Client structured-data-models-client mit PQL-Abfragen wie „PREDICT COUNT(orders.*, 0, 30, days) FOR EACH users.user_id“. Code: Apache 2.0, Gewichte: OpenMDW License 1.1.

Was du zum Ausprobieren brauchst

Die Quelle nennt keine genauen Zahlen. Das Modell ist für GPUs ausgelegt (device="cuda"), du brauchst also eine NVIDIA-Grafikkarte, am besten in einem GPU-Notebook wie Google Colab. Rechne mit einigen GB freiem Speicherplatz für Gewichte und Daten. Reiner CPU- oder Mac-Betrieb wird nicht beschrieben. Ein Quickstart-Notebook liegt im Client-Repository.

Einordnung

Dass ein vortrainiertes Modell ohne Training mit speziell gebauten Pipelines mithalten oder sie schlagen kann, wäre für Unternehmen mit Datenbanken ein großer Aufwandsgewinn. Alle Zahlen stammen von NVIDIA bzw. aus dem eigenen Paper; unabhängige Replikationen fehlen noch. Grenzen nennt NVIDIA selbst: Am besten funktioniert es bei Daten mit sinnvollen Beziehungen und zeitlicher Dynamik. Bei sehr großen Trainingsmengen können spezialisierte überwachte Modelle noch vorne liegen, und das Vorhersagesignal muss in wenigen Hops erreichbar sein.