TabFM, TabPFN und TabICL: Ersetzen Tabular Foundation Models klassische Machine-Learning-Modelle?

Wie TabPFN, TabICL und TabFM die Modellwahl verändern und warum klassische Verfahren relevant bleiben.

TabPFN, TabICL und Googles TabFM fordern klassische Modelle auf tabellarischen Daten heraus. Was bedeutet das für Modellwahl, Interpretierbarkeit, Betrieb und Lehre?

Warum diese Entwicklung für Data Science relevant ist

Die öffentliche KI-Debatte dreht sich vor allem um Sprache, Bilder, Videos und Chatbots. In meiner Arbeit und Lehre begegnen mir dagegen überwiegend tabellarische Daten: Kunden, Transaktionen, Lieferungen, Diagnosen, Kreditanträge, Maschinenzustände oder Rechnungen. Für viele Data Scientists bilden Tabellen weiterhin den Kern ihrer täglichen Arbeit.

Der unmittelbare Anlass für diesen Text ist Googles Vorstellung von TabFM am 30. Juni 2026. Google beschreibt TabFM als Zero-Shot-Foundation-Model für tabellarische Klassifikation und Regression, das Trainingsbeispiele als Kontext nutzt und Vorhersagen ohne datensatzspezifisches Fine-Tuning oder Hyperparametersuche erzeugt (Kong und Das 2026). Damit ist TabFM kein isolierter Ausreißer, sondern ein weiterer Hinweis darauf, dass Foundation Models auch für Tabellen zu einer relevanten Modellklasse werden.

Als Foundation Model bezeichne ich hier ein Modell, das vorab auf vielen unterschiedlichen Aufgaben trainiert wurde und dieses vortrainierte Wissen anschließend für neue Datensätze nutzt. TabPFN, TabICL und TabFM verändern damit den üblichen Ablauf der Modellierung: Statt für jeden Datensatz ein Modell von Grund auf zu trainieren und danach Vorhersagen zu erzeugen, wird ein vortrainiertes Modell mit gelabelten Beispielen als Kontext versorgt.

Aus meiner Sicht werden Tabular Foundation Models klassische Machine-Learning-Modelle deshalb nicht einfach ersetzen. Sie verändern aber, was als gute Baseline gilt, also als einfaches oder etabliertes Vergleichsmodell, wie schnell erste brauchbare Modelle verfügbar sind und welche Kompetenzen Data Scientists für eine begründete Modellwahl benötigen.

Warum Tabellen schwierig sind

Ein Pixel hat in unterschiedlichen Bildern weitgehend dieselbe technische Bedeutung. Ein Wort lässt sich in vielen Texten mit derselben Tokenisierung verarbeiten. Bei einer Tabellenspalte ist das anders. Die Zahl 42 kann Alter, Umsatz, Temperatur oder eine willkürlich codierte Kategorie bedeuten. Spalten besitzen keine universelle Semantik und ihre Reihenfolge trägt normalerweise keine natürliche Bedeutung.

Hinzu kommt die Heterogenität innerhalb eines Datensatzes: numerische, kategoriale und ordinale Merkmale, fehlende Werte, Ausreißer, unterschiedliche Skalen und stark unbalancierte Zielgrößen. Viele Tabellen sind klein bis mittelgroß. Sie entstehen nicht nach einem sauberen Forschungsdesign, sondern als Nebenprodukt historisch gewachsener Prozesse. Ein Merkmal kann nach einer Systemumstellung seine Bedeutung ändern; ein vermeintlich guter Prädiktor kann Informationen aus der Zukunft enthalten.

Diese Kombination erschwert den Einsatz von Deep Learning. Neuronale Netze profitieren besonders dort, wo viel Datenmaterial und über Datensätze hinweg wiederverwendbare Strukturen vorhanden sind. Bei Tabellen sind die Stichproben häufig kleiner, und die relevanten Zusammenhänge wechseln von Datensatz zu Datensatz. In einer großen Benchmark-Studie schnitten baumbasierte Modelle auf typischen mittelgroßen tabellarischen Datensätzen besser ab als die dort untersuchten Deep-Learning-Verfahren; als mögliche Gründe diskutieren die Autoren unter anderem uninformative Merkmale und unregelmäßige Zielfunktionen (Grinsztajn, Oyallon, und Varoquaux 2022). Der Befund gilt nicht für jede Aufgabe, erklärt aber, warum neue neuronale Architekturen klassische Verfahren auf Tabellen lange nicht generell übertrafen.

Warum klassische Modelle so lange dominieren

Klassische Verfahren decken unterschiedliche Anforderungen ab. Lineare und logistische Regression liefern transparente Baselines. Entscheidungsbäume und Random Forests können Nichtlinearitäten und Interaktionen abbilden (Breiman 2001). Gradient Boosting kombiniert viele einfache Lernende schrittweise zu einem Modell mit niedrigerem Vorhersagefehler (Friedman 2001). XGBoost, LightGBM und CatBoost haben diese Grundidee rechnerisch und algorithmisch weiterentwickelt (Chen und Guestrin 2016; Ke u. a. 2017; Prokhorenkova u. a. 2018). AutoML-Systeme automatisieren zusätzlich Teile der Modellauswahl, des Hyperparameter-Tunings und der Ensemblebildung.

Diese Modelle sind weiterhin relevant. Aus praktischer Sicht spricht für sie, dass ihre Implementierungen in R und Python etabliert sind und sich trainierte Modelle in vielen Umgebungen vergleichsweise unkompliziert bereitstellen lassen. Bei linearen Modellen sind die Koeffizienten unter den jeweiligen Modellannahmen direkt interpretierbar; für Baummodelle existieren effiziente modellspezifische Erklärverfahren. Ein trainiertes Modell kann außerdem gespeichert und für neue Einzelbeobachtungen häufig mit geringer Latenz ausgeführt werden.

Klassische Baselines erfüllen außerdem eine wichtige Kontrollfunktion. Wenn ein komplexes Modell eine logistische Regression nur geringfügig übertrifft, ist das eine relevante Information über den zusätzlichen Nutzen der Komplexität. Wenn bereits ein einfaches Modell bei verschiedenen Stichproben stark schwankt, sollte zunächst die Datenbasis und das Evaluationsdesign geprüft werden.

Was Tabular Foundation Models anders machen

Tabular Foundation Models verlagern einen wesentlichen Teil des Lernens in das Pretraining. Sie werden vor der Anwendung auf sehr vielen Aufgaben trainiert, bei TabPFN, TabICL und TabFM vor allem auf synthetisch erzeugten Tabellen. Dabei sollen sie nicht nur ein einzelnes Vorhersageproblem, sondern eine übertragbare Strategie für neue tabellarische Aufgaben lernen.

Für einen neuen Datensatz erhält das Modell die gelabelten Trainingszeilen sowie die ungelabelten Testzeilen als Kontext. Dieses Verfahren wird als In-Context Learning bezeichnet: Das Modell nutzt die im Kontext enthaltenen Beispiele für die neue Aufgabe, ohne seine Gewichte dafür mit einem Optimierer anzupassen. Die Vorhersagen entstehen in einem Forward Pass durch das neuronale Netz. Die gewohnte fit()-Methode kann in einer Scikit-learn-Schnittstelle zwar weiterhin vorkommen, dient dann aber primär der Vorbereitung des Kontexts und dem Laden des Modells. Christoph Molnar beschreibt diese Verschiebung als Übergang von „train and predict“ zu „pre-train and learn in context“ (Molnar 2026a).

Dabei ist zu beachten, dass weiterhin ein aufwendiges Training stattgefunden hat. Es wurde lediglich in das vorgelagerte Pretraining verlagert. Der neue Datensatz wird anschließend zur Laufzeit Teil der Berechnung. Daraus folgen sowohl die schnelle Anpassung an neue Aufgaben als auch einige betriebliche Grenzen.

Abbildung 1: Vom datensatzspezifischen Training zum vortrainierten Modell mit In-Context Learning

TabPFN als Beispiel für Prior-Data Fitted Networks

TabPFN steht für Tabular Prior-Data Fitted Network. Die Grundidee ist, viele synthetische Datensätze aus vorgegebenen Datenentstehungsprozessen zu erzeugen und einen Transformer darauf zu trainieren, die jeweils fehlenden Zielwerte vorherzusagen. Das Modell lernt damit näherungsweise einen Algorithmus für tabellarische Inferenz statt nur die Parameter eines konkreten Datensatzes.

Die 2025 in Nature veröffentlichte Version, heute meist TabPFNv2 genannt, unterstützt Klassifikation und Regression sowie kategoriale und fehlende Werte. Die Studie evaluiert Datensätze mit bis zu 10.000 Zeilen, 500 Merkmalen und zehn Klassen und berichtet in diesem Untersuchungsbereich bessere Ergebnisse als die einbezogenen, getunten klassischen Baselines (Hollmann u. a. 2025). Für Regression gibt das Modell eine Verteilung über Zielwerte aus und nicht nur einen einzelnen Punktschätzer.

Die Entwicklung ist inzwischen weiter fortgeschritten: Die offizielle Dokumentation führt neuere Modellgenerationen mit höheren Größenlimits auf (Prior Labs 2026a). Diese Herstellerangaben sind für praktische Tests relevant, ersetzen aber keine unabhängige Evaluation. Zudem unterscheiden sich die Lizenzen nach Version. Die Gewichte von TabPFNv2 sind laut Projektdokumentation kommerziell mit zusätzlicher Attribution nutzbar; neuere Gewichte unterliegen teilweise nichtkommerziellen Bedingungen oder benötigen für den produktiven Einsatz eine kommerzielle Vereinbarung (Prior Labs 2026a). Daraus folgt, dass Lizenzfragen für jede Modellversion gesondert geprüft werden müssen.

Auch in R ist der Ansatz zugänglich. Das Paket tabpfn integriert das Python-Modell in vertraute Formel-, Recipes- und Tidymodels-Workflows (Kuhn 2026). Für Experimente senkt das die Einstiegshürde erheblich; die Python-Runtime, Modellgewichte und Hardwareanforderungen bleiben aber Teil der technischen Abhängigkeiten.

TabICL: In-Context Learning für größere Tabellen

TabICL verfolgt dieselbe Grundidee, setzt aber bei der Skalierung anders an. Die Architektur verarbeitet zunächst Spalten- und Zeileninformationen so, dass kompakte Zeilenrepräsentationen entstehen, und führt darauf anschließend das In-Context Learning aus. Dadurch soll die Berechnung bei größeren Tabellen beherrschbarer werden.

Die ICML-Arbeit von 2025 untersucht Klassifikation, beschreibt ein Pretraining auf synthetischen Datensätzen mit bis zu 60.000 Zeilen und eine Anwendung auf bis zu 500.000 Zeilen. Auf 200 Klassifikationsdatensätzen des TALENT-Benchmarks lag TabICL in den berichteten Experimenten auf dem Niveau von TabPFNv2 und war systematisch schneller; auf 53 größeren Datensätzen übertraf es dort TabPFNv2 und CatBoost (Qu u. a. 2025). Diese Ergebnisse gelten innerhalb des beschriebenen Benchmark-Protokolls. Ob sie sich auf einen konkreten Unternehmensdatensatz übertragen lassen, muss separat geprüft werden.

Seitdem dokumentiert das Projekt TabICLv2 mit Klassifikation und Regression sowie optionalem Fine-Tuning. Der zugehörige Bericht ist derzeit ein Preprint, und die Projektangaben sollten entsprechend eingeordnet werden (Qu u. a. 2026; SODA, Inria 2026). Interessant ist der Kontrast zu TabPFN auch organisatorisch: Das TabICL-Projekt stellt Code und Gewichte unter einer permissiven Lizenz bereit. Schon daran wird sichtbar, dass „Foundation Model“ keine einheitliche Betriebs- oder Lizenzklasse bezeichnet.

TabFM: Googles Zero-Shot-Modell für Tabellen

TabFM ist die jüngste prominente Ergänzung dieser Modellfamilie. Google Research stellt das Modell als Zero-Shot-Ansatz für tabellarische Klassifikation und Regression vor. Zero-Shot bedeutet hier nicht, dass das Modell ohne Beispiele im engeren Sinn arbeitet. Die gelabelten Trainingszeilen werden vielmehr als Kontext an das Modell übergeben; die Modellgewichte selbst werden für die konkrete Aufgabe nicht angepasst (Kong und Das 2026).

Architektonisch verbindet TabFM Elemente, die bereits aus TabPFN und TabICL bekannt sind. Laut Google verarbeitet das Modell Tabellen zunächst mit alternierender Zeilen- und Spaltenaufmerksamkeit, komprimiert anschließend jede Zeile in eine dichte Repräsentation und nutzt danach einen Transformer über diese komprimierten Zeilenrepräsentationen für In-Context Learning (Kong und Das 2026). Die Modellkarte auf Hugging Face nennt zusätzlich konkrete Grenzen der veröffentlichten Version: Klassifikation ist auf bis zu zehn Klassen ausgelegt, die Nutzung skaliert im Speicher mit der Zahl der Kontextzeilen, und das Verhalten bei sehr breiten Tabellen ist nicht vollständig charakterisiert (Google Research 2026a).

Auch bei den Trainingsdaten folgt TabFM einem Muster, das diese Modellklasse prägt. Google gibt an, TabFM vollständig auf hunderten Millionen synthetisch erzeugten Datensätzen trainiert zu haben, die dynamisch mit Structural Causal Models erzeugt wurden (Kong und Das 2026). Diese Entscheidung ist plausibel, weil reale Unternehmensdaten häufig proprietär, sensibel oder lizenzrechtlich schwer nutzbar sind. Zugleich bedeutet sie, dass die Qualität des synthetischen Priors ein zentraler Teil des Modells ist. Für die Praxis folgt daraus, dass eine gute Benchmark-Position nicht automatisch zeigt, ob die synthetisch gelernten Regelmäßigkeiten zu einem konkreten Datensatz passen.

Für die Einordnung sind die veröffentlichten Leistungsangaben relevant, aber noch kein unabhängiger Konsens. Google berichtet eine Evaluation auf TabArena mit 38 Klassifikations- und 13 Regressionsdatensätzen zwischen 700 und 150.000 Zeilen. Die Standardvariante von TabFM erzeugt Vorhersagen in einem einzelnen Forward Pass; eine Ensemble-Variante ergänzt unter anderem Kreuzmerkmale, SVD-Features, nichtnegative Least-Squares-Gewichtung und bei Klassifikation Platt-Skalierung (Kong und Das 2026). Damit sollte man die Varianten getrennt lesen: Die einfache TabFM-Version steht für die eigentliche Zero-Shot-Erfahrung, die Ensemble-Version verschiebt sich bereits wieder in Richtung zusätzlicher Modellierungslogik.

Für die produktive Nutzung kommen außerdem Veröffentlichungsbedingungen und Infrastruktur hinzu. Der Code liegt auf GitHub unter Apache-2.0-Lizenz, die Modellgewichte auf Hugging Face stehen jedoch unter einer nichtkommerziellen TabFM-Lizenz; das Repository weist außerdem darauf hin, dass TabFM kein offiziell unterstütztes Google-Produkt ist (Google Research 2026b, 2026a). Hinzu kommt, dass solche Modelle je nach Kontextgröße, Latenzanforderung und Backend auf GPU- oder andere Accelerator-Ressourcen angewiesen sein können oder erst damit ökonomisch sinnvoll werden. Google kündigt zugleich eine Integration in BigQuery über AI.PREDICT an (Kong und Das 2026). Aus meiner Sicht macht gerade diese Kombination TabFM als Anlass interessant: Die technische Entwicklung rückt näher an alltägliche Datenplattformen heran, während Lizenz, Supportstatus, Hardwarebedarf und unabhängige Evaluation weiterhin sorgfältig geprüft werden müssen.

Interpretierbarkeit und Betrieb

Tabular Foundation Models können ohne umfangreiches Tuning eine hohe Vorhersageleistung erreichen. Für eine produktive Anwendung reicht Vorhersageleistung allein jedoch nicht aus. Relevant sind auch Inferenzzeit, Kalibrierung, Robustheit, Datenschutz, Monitoring, Reproduzierbarkeit, Lizenzbedingungen und die Frage, ob eine Entscheidung gegenüber Betroffenen oder Fachabteilungen erklärt werden kann.

Ein wichtiger Unterschied liegt in der Kostenstruktur. Ein klassisches Modell kann im Training und Tuning teuer sein, danach aber günstig einzelne Vorhersagen liefern. Bei einem Tabular Foundation Model ist das Pretraining ausgelagert; die Anpassung an den konkreten Datensatz besteht vor allem darin, die Trainingsbeispiele als Kontext bereitzustellen. Zur Vorhersage muss dieser Kontext jedoch verarbeitet werden. Molnar spricht von einer Umkehr der Inferenzökonomie (Molnar 2026b). Das betrifft nicht nur den Live-Betrieb, sondern auch Erklärverfahren, die das Modell sehr oft aufrufen.

Damit wird Hardware zu einem Teil der Modellentscheidung, der in Benchmarks leicht verdeckt wird. TabFM stellt Installationspfade für JAX auf CPU oder GPU sowie PyTorch auf CPU oder GPU bereit; die Modellkarte nennt zugleich, dass der Speicherbedarf mit der Zahl der Trainingszeilen wächst, weil diese als Kontext verarbeitet werden (Google Research 2026b, 2026a). Bei TabPFN ist die Empfehlung expliziter: Die aktuelle Dokumentation empfiehlt für gute Performance eine GPU, nennt auch ältere GPUs mit etwa 8 GB VRAM als praktikabel und weist darauf hin, dass CPU-Nutzung im Wesentlichen für kleine Datensätze bis ungefähr 1.000 Beobachtungen sinnvoll ist; für manche große Datensätze werden 16 GB VRAM genannt (Prior Labs 2026b). TabICL wählt das Inferenzgerät automatisch zwischen CUDA und CPU, unterstützt Apple Silicon über mps, empfiehlt für größere Datensätze aber ebenfalls eine GPU. Für TabICLv2 nennt das Projekt als Beispiel 50.000 Zeilen und 100 Merkmale in unter zehn Sekunden auf einer H100-GPU; noch größere Datensätze können über CPU- und Disk-Offloading verarbeitet werden, wobei Genauigkeit und Laufzeit gesondert geprüft werden müssen (SODA, Inria 2026).

Eine unabhängige, allerdings auf ältere Modellversionen bezogene Studie macht diesen Punkt konkret. Bansal und Gangwani vergleichen TabPFN-1.0 und TabICL-base mit XGBoost, LightGBM und Random Forest auf einer NVIDIA-T4-GPU und messen neben Accuracy auch Laufzeit, CPU-RAM und GPU-VRAM. In ihren Experimenten benötigen die Baumverfahren keine VRAM-Ressourcen, während TabICL auf einem Higgs-100k-Task etwa 9 GB VRAM und deutlich höhere Latenz benötigt; TabPFN erreicht auf anderen Aufgaben vergleichbare Accuracy, benötigt aber bis zu 4 GB VRAM und verarbeitet den vollständigen Higgs-100k-Task nicht (Bansal und Gangwani 2025). Diese Zahlen lassen sich nicht direkt auf TabFM, TabPFN-3 oder TabICLv2 übertragen. Sie zeigen aber, warum Hardwarekosten nicht als Nebenaspekt behandelt werden sollten.

Tabelle 1: Vergleich typischer Hardware- und Betriebserwägungen

Modellklasse / Modell	CPU-Nutzung	Rolle von GPU oder Accelerator	Einschränkung
Lineare Modelle, Random Forest, XGBoost/LightGBM/CatBoost	häufig ausreichend	optional bei sehr großen Trainingsläufen oder speziellen GPU-Implementierungen	Tuning und Feature Engineering bleiben datensatzspezifisch
TabPFN	laut Doku vor allem für kleine Datensätze sinnvoll	für gute Performance empfohlen; größere Datensätze können 8–16 GB VRAM oder gehostete Inferenz erfordern	Kontextgröße und Modellversion bestimmen Speicherbedarf und Limits
TabICL / TabICLv2	möglich, Gerät kann automatisch gewählt werden	bei größeren Datensätzen empfohlen; H100-Beispiel für 50.000 × 100 unter zehn Sekunden	Offloading kann größere Daten ermöglichen, verschiebt aber Laufzeit- und Genauigkeitsfragen
TabFM	CPU- und GPU-Backends dokumentiert	abhängig von Backend, Kontextgröße und Latenzanforderung	Speicherbedarf wächst mit den Kontextzeilen; Gewichte derzeit nichtkommerziell

Modellagnostische Verfahren verschwinden deshalb nicht. Permutation Feature Importance, SHAP, Partial Dependence, Accumulated Local Effects und Surrogate Models benötigen grundsätzlich nur Zugriff auf Vorhersagen und bleiben anwendbar (Molnar 2022). Aber ihre Kosten und Fallstricke bleiben nicht gleich. Viele dieser Verfahren beruhen darauf, denselben Prädiktor unter systematisch veränderten Eingaben wiederholt aufzurufen. Bei klassischen Modellen ist das nach dem Training oft billig: Ein linearer Prädiktor, ein Random Forest oder ein Gradient-Boosting-Modell kann viele Vorhersagen meist mit geringer zusätzlicher Infrastruktur erzeugen. Bei Tabular Foundation Models muss dagegen häufig wieder der Kontext verarbeitet werden; je nach Modell, Kontextgröße und Hardware kann eine Erklärung damit spürbar teurer werden als die einzelne Vorhersage. Shapley-basierte Verfahren sind ein besonders deutliches Beispiel, weil exakte Werte kombinatorisch teuer sind und auch Approximationen viele Modellaufrufe benötigen (Lundberg und Lee 2017; Sena und Azevedo 2026).

Daraus folgt nicht, dass Transparenz bei Tabular Foundation Models grundsätzlich unmöglich ist. Es gibt erste Ansätze, die den zusätzlichen Rechenaufwand verringern sollen. ShapPFN integriert eine Shapley-ähnliche additive Zerlegung in ein PFN-artiges Modell und berichtet auf Standardbenchmarks deutlich schnellere Erklärungen als KernelSHAP bei ähnlicher Erklärungstreue (Sena und Azevedo 2026). ExplainerPFN verfolgt einen anderen Weg und schätzt Feature-Attributionen ohne direkten Zugriff auf ein Zielmodell, indem ein Foundation Model selbst für Shapley-Wert-Schätzungen vortrainiert wird (Fonseca und Stoyanovich 2026). KernelICL macht wiederum die Nähe von In-Context Learning zu Kernel-Regression explizit und erzeugt Vorhersagen als gewichtete Durchschnitte über Trainingslabels (Miftachov, Charron, und Valentin 2026). Diese Arbeiten zeigen, dass Erklärbarkeit ein aktives Forschungsthema ist. Für die praktische Modellwahl sollte man sie aber noch nicht mit der etablierten Transparenz einfacher Modelle oder mit den ausgereiften Werkzeugen für Baumensembles gleichsetzen.

Korrelationen erschweren zudem weiterhin die Interpretation. Ein Surrogat erklärt zunächst das Verhalten seiner Approximation, nicht automatisch den inneren Mechanismus des Foundation Models. Angepasste Batch-Implementierungen oder speziell trainierte Erklärungsköpfe können die Laufzeit reduzieren; sie machen aus einer Post-hoc-Erklärung aber keine kausale Aussage (Rundel u. a. 2024; Molnar 2026b).

Die folgende Matrix fasst diese Kriterien qualitativ und konzeptionell zusammen. Sie enthält keine Benchmark-Scores und beschreibt typische Tendenzen, keine garantierten Eigenschaften eines konkreten Produkts oder einer konkreten Modellversion.

Tabelle 2: Qualitative Einordnung typischer Auswahlkriterien für drei Modellklassen

Kriterium	Lineare/logistische Modelle	Random Forest und Boosting	Tabular Foundation Models
Erste Modellgüte	gut nachvollziehbare Baseline	oft gute Ergebnisse, teils mit Tuning	oft gute Ergebnisse mit wenig Tuning
Datensatzspezifisches Training	gering	mittel bis hoch	gering; Pretraining ausgelagert
Inferenzkosten	meist niedrig	meist niedrig bis moderat	kontext-, batch- und hardwareabhängig
Interpretierbarkeit	unter Annahmen direkt	meist post hoc oder baumspezifisch	überwiegend post hoc, oft inference-intensiv
Deployment	einfach	etabliert	Gewichte, Runtime, Accelerator-Bedarf und Lizenz prüfen
Kleine Daten	oft geeigneter Ausgangspunkt	häufig konkurrenzfähig	Zielbereich vieler aktueller Modelle
Große Daten	meist gut handhabbar	meist gut handhabbar	abhängig von Modellversion und Architektur
Stakeholder-Erklärung	vergleichsweise einfach	mittel	tendenziell anspruchsvoll

Ersetzen sie klassische Modelle?

Tabular Foundation Models können Teile der bisherigen Modellierungsroutine übernehmen. Wenn ohne umfangreiches Tuning schnell eine brauchbare Baseline entsteht, sinkt der Nutzen einer langen manuellen Hyperparametersuche. Auf kleinen und mittelgroßen Aufgaben können TabPFN, TabICL und TabFM deshalb zu regelmäßigen Standardvergleichen werden. Molnar weist außerdem darauf hin, dass die Vorhersagefehler solcher Modelle vergleichsweise gering mit denen anderer Verfahren korreliert sein können, wodurch sie auch für Ensembles interessant werden (Molnar 2026a).

Vollständig ersetzen werden sie klassische Modelle absehbar nicht. Eine logistische Regression kann angemessener sein, wenn wenige Effekte transparent kommuniziert werden müssen. CatBoost oder LightGBM können sinnvoller sein, wenn niedrige Einzelvorhersage-Latenz, einfache On-Premise-Bereitstellung oder millionenfache Inferenz im Vordergrund stehen. Ein Foundation Model kann trotz besserer durchschnittlicher Benchmark-Platzierung ungeeignet sein, wenn seine Lizenz die Nutzung ausschließt, Wahrscheinlichkeiten schlecht kalibriert sind oder die Datenstruktur vom Evaluationsprotokoll abweicht.

Dabei ist außerdem zu beachten, dass nicht jede Analyse ausschließlich auf Prognose zielt. Kausale Fragen, Parameterschätzung, Unsicherheitskommunikation und wissenschaftliche Erklärung verlangen eigene Designs und Annahmen. Eine hohe Vorhersagegüte beantwortet beispielsweise nicht automatisch, welche Intervention eine Veränderung bewirken würde.

Aus meiner Sicht ersetzen Tabular Foundation Models daher nicht die fachliche Auseinandersetzung mit den Daten. Sie können einen Teil der Modellierungsroutine übernehmen, nicht aber Problemdefinition, Datenprüfung und die Begründung einer Entscheidung.

Was Benchmarks leisten und was zusätzlich geprüft werden muss

TabArena ist ein wichtiger Fortschritt, weil der Benchmark aktiv gepflegt wird, standardisierte Protokolle und gespeicherte Vorhersagen bereitstellt und neue Modellversionen aufnehmen kann (Erickson u. a. 2025). Ein solcher „living benchmark“ ist aussagekräftiger als eine statische Tabelle, deren Implementierungen und Modellstände altern. Molnar hebt zugleich hervor, dass TabArena eine kuratierte Auswahl kleiner bis mittelgroßer IID-Aufgaben abbildet und ein Elo-Ranking Siege zählt, nicht automatisch deren praktische Relevanz (Molnar 2026c).

Ein aktuelles Beispiel für diese differenziertere Sicht ist TabBench V2. Neuralk beschreibt den Benchmark als offene Evaluationssuite für 189 OpenML-Klassifikationsaufgaben aus verschiedenen Domänen; verglichen werden unter anderem Tabular Foundation Models, Gradient-Boosted Decision Trees und getunte neuronale Netze (Neuralk 2026). In der Auswertung gewinnen moderne Tabular Foundation Models zwar einen großen Teil der Vergleiche gegen stark getunte Baumensembles. Molnar weist auf Basis derselben Ergebnisse aber auf erkennbare Bereiche hin, in denen andere Modellklassen vorn liegen: Bei kleineren bis mittleren Aufgaben mit wenigen kategorialen Merkmalen sprechen die Ergebnisse eher für Tabular Foundation Models; bei kleineren Aufgaben mit vielen kategorialen Merkmalen und bei größeren binären Aufgaben bleiben Boosting-Verfahren stark; bei großen, mehrklassigen oder unausgeglichenen Aufgaben können getunte neuronale Netze vorteilhaft sein (Molnar 2026d). Wichtig ist dabei die Einordnung: TabBench V2 betrachtet Klassifikation, IID-Datensätze aus OpenML und maximal etwa 150.000 Zeilen. Lineare oder logistische Regressionen sind in dieser Zusammenfassung nicht als einfache Baselines enthalten. Die Regeln sind daher nützliche Heuristiken, aber keine allgemeinen Modellgesetze.

Noch deutlicher wird diese Grenze in BeyondArena, einem 2026 veröffentlichten Preprint zu einem breiteren Benchmark für Tabular Foundation Models. Dort werden neben klassischen IID-Aufgaben auch zeitliche und gruppierte Splits, sehr kleine bis größere Datensätze, hohe Dimensionalität, Textmerkmale und hochkardinale kategoriale Merkmale betrachtet. Die Autoren berichten, dass aktuelle Tabular Foundation Models vor allem auf kleinen bis mittelgroßen IID-Aufgaben stark sind, während klassische Baumverfahren und Deep-Learning-Modelle bei nicht-IID, großen oder hochdimensionalen Aufgaben weiterhin dominieren (Purucker u. a. 2026). Daraus folgt nicht, dass Tabular Foundation Models überschätzt sind. Es bedeutet aber, dass die Art des Benchmarks wesentlich mitbestimmt, welche Modellklasse als führend erscheint.

Abbildung 2: Prüfpfad für Modellkandidaten auf Basis der diskutierten Benchmark-Befunde

Benchmarks wie diese helfen bei der Entwicklung und beim systematischen Vergleich von Modellen. Für eine konkrete Modellentscheidung bilden sie jedoch nur den Ausgangspunkt. Eine seriöse Evaluation sollte mindestens:

• eine einfache und eine leistungsfähige klassische Baseline enthalten,
• Vorverarbeitung und Hyperparameterwahl innerhalb der Resampling-Schleife durchführen,
• Gruppen, Zeit und Abhängigkeiten im Split respektieren,
• Leakage aus Datenaufbereitung und Datenerzeugungsprozess prüfen,
• mehrere passende Metriken einschließlich Kalibrierung betrachten,
• Laufzeit, Speicher, Latenz, Accelerator-Bedarf und Kosten unter realistischen Bedingungen messen,
• Robustheit bei Missingness, Drift und relevanten Subgruppen untersuchen,
• sowie Lizenz, Datenschutz und Deployment vor der Empfehlung klären.

Ein guter durchschnittlicher Rang beantwortet damit noch nicht, ob ein Modell unter den Bedingungen eines konkreten Kreditantrags, einer bestimmten Maschine oder einer neuen Kohorte verlässlich arbeitet.

Folgen für Data-Science-Praxis und Lehre

Wenn Modelle ohne umfangreiches Tuning gute Ergebnisse liefern, verschiebt sich ein Teil der Arbeit. Data Scientists können weniger Zeit für routinemäßige Hyperparametersuchen benötigen. Dafür gewinnen Problemdefinition, Datenqualität, Leakage-Prüfung, Evaluation, Interpretierbarkeit, Deployment, Monitoring, Governance und Kommunikation an Bedeutung.

Für die Lehre bedeutet dies, dass klassische Verfahren weiterhin in das Curriculum gehören. Studierende müssen lineare und logistische Regression, Entscheidungsbäume, Random Forests und Gradient Boosting verstehen. Sie brauchen außerdem Kenntnisse über Cross-Validation, Metriken, Feature Engineering, Overfitting, Leakage und Baselines, um neue Modelle beurteilen zu können. Ohne dieses Fundament lässt sich zwar eine Programmierschnittstelle bedienen, aber keine belastbare Modellentscheidung treffen.

Hinzu kommt eine neue Vergleichskompetenz: Studierende sollten eine transparente Regression, ein gut abgestimmtes Boosting-Modell und ein Tabular Foundation Model unter demselben sauberen Protokoll evaluieren. Sie sollten begründen können, warum ein kleiner Metrikgewinn zusätzliche Latenz oder schlechtere Erklärbarkeit rechtfertigt – oder warum nicht. R und Python sind dabei keine konkurrierenden Lager: R bietet mit Tidymodels eine saubere Evaluationslogik, Python derzeit den direkteren Zugang zu vielen Foundation Models. Professionelle Praxis muss beides verbinden können.

Mein Fazit

Tabular Foundation Models sind inzwischen eine relevante Modellklasse. Die veröffentlichten Ergebnisse zu TabPFN und TabICL sowie Googles Veröffentlichung von TabFM rechtfertigen es, sie bei geeigneten tabellarischen Aufgaben als zusätzliche Baseline zu prüfen (Hollmann u. a. 2025; Qu u. a. 2025; Kong und Das 2026).

Aus meiner Sicht folgt daraus keine Ablösung klassischer Machine-Learning-Modelle, sondern eine anspruchsvollere Modellwahl. Transparente statistische Modelle, gut abgestimmte Baumverfahren, AutoML und vortrainierte Foundation Models sollten unter einem gemeinsamen, zur Aufgabe passenden Evaluationsprotokoll verglichen werden.

Entscheidend ist damit nicht die Suche nach einer allgemein besten Modellklasse. Entscheidend ist, welches Verfahren für die konkrete Aufgabe, die vorhandenen Daten und die betrieblichen sowie rechtlichen Randbedingungen angemessen ist. TabFM macht diese Frage aktueller, aber nicht einfacher.

Literatur

Bansal, Aayam, und Ishaan Gangwani. 2025. „Light-Weight Benchmarks Reveal the Hidden Hardware Cost of Zero-Shot Tabular Foundation Models“. https://doi.org/10.48550/arXiv.2512.00888.

Breiman, Leo. 2001. „Random Forests“. Machine Learning 45: 5–32. https://doi.org/10.1023/A:1010933404324.

Chen, Tianqi, und Carlos Guestrin. 2016. „XGBoost: A Scalable Tree Boosting System“. In Proceedings of the 22nd ACM SIGKDD International Conference on Knowledge Discovery and Data Mining, 785–94. https://doi.org/10.1145/2939672.2939785.

Erickson, Nick, Lennart Purucker, Andrej Tschalzev, David Holzmüller, Prateek Mutalik Desai, David Salinas, und Frank Hutter. 2025. „TabArena: A Living Benchmark for Machine Learning on Tabular Data“. In Advances in Neural Information Processing Systems: Datasets and Benchmarks Track. https://papers.neurips.cc/paper_files/paper/2025/hash/1697e3fb412da11dc9488249f9e7bbc9-Abstract-Datasets_and_Benchmarks_Track.html.

Fonseca, Joao, und Julia Stoyanovich. 2026. „ExplainerPFN: Towards Tabular Foundation Models for Model-Free Zero-Shot Feature Importance Estimations“. https://doi.org/10.48550/arXiv.2601.23068.

Friedman, Jerome H. 2001. „Greedy Function Approximation: A Gradient Boosting Machine“. The Annals of Statistics 29 (5): 1189–1232. https://doi.org/10.1214/aos/1013203451.

Google Research. 2026a. „TabFM 1.0.0 (PyTorch)“. https://huggingface.co/google/tabfm-1.0.0-pytorch.

———. 2026b. „TabFM: Tabular Foundation Models“. https://github.com/google-research/tabfm.

Grinsztajn, Léo, Edouard Oyallon, und Gaël Varoquaux. 2022. „Why Do Tree-Based Models Still Outperform Deep Learning on Typical Tabular Data?“ In Advances in Neural Information Processing Systems, 35:507–20. https://proceedings.neurips.cc/paper_files/paper/2022/hash/0378c7692da36807bdec87ab043cdadc-Abstract-Datasets_and_Benchmarks.html.

Hollmann, Noah, Samuel Müller, Lennart Purucker, Arjun Krishnakumar, Max Körfer, Shi Bin Hoo, Robin Tibor Schirrmeister, und Frank Hutter. 2025. „Accurate Predictions on Small Data with a Tabular Foundation Model“. Nature 637: 319–26. https://doi.org/10.1038/s41586-024-08328-6.

Ke, Guolin, Qi Meng, Thomas Finley, Taifeng Wang, Wei Chen, Weidong Ma, Qiwei Ye, und Tie-Yan Liu. 2017. „LightGBM: A Highly Efficient Gradient Boosting Decision Tree“. In Advances in Neural Information Processing Systems. Bd. 30. https://proceedings.neurips.cc/paper_files/paper/2017/hash/6449f44a102fde848669bdd9eb6b76fa-Abstract.html.

Kong, Weihao, und Abhimanyu Das. 2026. „Introducing TabFM: A Zero-Shot Foundation Model for Tabular Data“. Google Research. 30. Juni 2026. https://research.google/blog/introducing-tabfm-a-zero-shot-foundation-model-for-tabular-data/.

Kuhn, Max. 2026. „tabpfn: Prior-Data Fitted Network Foundational Model for Tabular Data“. https://tabpfn.tidymodels.org/.

Lundberg, Scott M., und Su-In Lee. 2017. „A Unified Approach to Interpreting Model Predictions“. In Advances in Neural Information Processing Systems. Bd. 30. https://proceedings.neurips.cc/paper_files/paper/2017/hash/8a20a8621978632d76c43dfd28b67767-Abstract.html.

Miftachov, Ratmir, Bruno Charron, und Simon Valentin. 2026. „Interpretable Tabular Foundation Models via In-Context Kernel Regression“. https://doi.org/10.48550/arXiv.2602.02162.

Molnar, Christoph. 2022. Interpretable Machine Learning: A Guide for Making Black Box Models Explainable. 2. Aufl. https://christophm.github.io/interpretable-ml-book/.

———. 2026a. „The Rise of Tabular Foundation Models“. Mindful Modeler. 13. Januar 2026. https://mindfulmodeler.substack.com/p/tabular-ml-is-about-to-get-weird.

———. 2026b. „The Interpretability Tax on Tabular Foundation Models“. Mindful Modeler. 24. März 2026. https://mindfulmodeler.substack.com/p/tabular-foundation-models-break-the.

———. 2026c. „TabArena Explained“. Mindful Modeler. 31. März 2026. https://mindfulmodeler.substack.com/p/tabarena-explained.

———. 2026d. „When Trees Still Beat Tabular Foundation Models“. Mindful Modeler. 23. Juni 2026. https://mindfulmodeler.substack.com/p/when-trees-still-beat-tabular-foundation.

Neuralk. 2026. „TabBench V2: The New Version of the Open Evaluation Suite for Tabular Classification“. 3. Juni 2026. https://www.neuralk.ai/post/tabbench-v2-the-new-version-of-the-open-evaluation-suite-for-tabular-classification.

Prior Labs. 2026a. „TabPFN Models: Capabilities, Limits, and Availability“. 2026. https://docs.priorlabs.ai/models.

———. 2026b. „TabPFN: Foundation Model for Tabular Data“. https://github.com/PriorLabs/TabPFN.

Prokhorenkova, Liudmila, Gleb Gusev, Aleksandr Vorobev, Anna Veronika Dorogush, und Andrey Gulin. 2018. „CatBoost: Unbiased Boosting with Categorical Features“. In Advances in Neural Information Processing Systems. Bd. 31. https://proceedings.neurips.cc/paper/2018/hash/14491b756b3a51daac41c24863285549-Abstract.html.

Purucker, Lennart, Andrej Tschalzev, Nick Erickson, Gioia Blayer, David Holzmüller, Alan Arazi, Alexander Pfefferle, Mustafa Tajjar, Gaël Varoquaux, und Frank Hutter. 2026. „Beyond IID: How General Are Tabular Foundation Models, Really?“ https://doi.org/10.48550/arXiv.2606.30410.

Qu, Jingang, David Holzmüller, Gaël Varoquaux, und Marine Le Morvan. 2025. „TabICL: A Tabular Foundation Model for In-Context Learning on Large Data“. In Proceedings of the 42nd International Conference on Machine Learning, 267:50817–47. Proceedings of Machine Learning Research. https://proceedings.mlr.press/v267/qu25d.html.

———. 2026. „TabICLv2: A Better, Faster, Scalable, and Open Tabular Foundation Model“. https://doi.org/10.48550/arXiv.2602.11139.

Rundel, David, Julius Kobialka, Constantin von Crailsheim, Matthias Feurer, Thomas Nagler, und David Rügamer. 2024. „Interpretable Machine Learning for TabPFN“. In Explainable Artificial Intelligence, 465–76. Springer Nature Switzerland. https://doi.org/10.1007/978-3-031-63797-1_23.

Sena, Luan Borges Teodoro Reis, und Francisco Galuppo Azevedo. 2026. „Real-Time Explanations for Tabular Foundation Models“. https://doi.org/10.48550/arXiv.2603.29946.

SODA, Inria. 2026. „TabICL: Official Implementation“. https://github.com/soda-inria/tabicl.