TabFM: a scikit-learn tabular model that predicts from context instead of training on your data

A tabular model with no fit step in the usual sense

TabFM inverts how a tabular model normally works. The README states it is a scikit-learn compatible tabular foundation model that performs zero-shot classification and regression on datasets with mixed column types out of the box. At inference it does not train parameters on your dataset. Instead it uses in-context learning, reading your training data as context to predict on new test samples immediately.

That is aimed at a specific practitioner: someone with a small-to-moderate tabular dataset who wants a strong baseline without a training loop, hyperparameter search or a GPU-hours budget. The scikit-learn interface means it drops into an existing workflow next to a `RandomForestClassifier` with the same `fit` and `predict` calls.

The README is careful to say this is not an officially supported Google product, which sets expectations: it is research code released by Google Research, not a maintained cloud service. The value in reading it is seeing a production-shaped implementation of the in-context tabular idea, with both a JAX and a PyTorch backend, rather than a paper's reference script.

In-context learning is the whole mechanism

The mechanism is the design. Because TabFM reads training rows as context rather than fitting weights to them, `fit` does not do gradient descent on your data. The README says the classifier's `fit` prepares ordinal encoders and numerical scalers, so what looks like training is really feature preparation, and prediction happens by feeding the prepared context and the test rows through the pretrained model in one pass.

That has a direct consequence the README's FAQ raises: there is a limit to how much context fits, because in-context learning holds the training data in the model's input. A dataset small enough to serve as context is the sweet spot; a very large training set does not scale the same way a tree ensemble would, since it cannot all be read as context at once.

The two backends share one model interface. You import either `tabfm_v1_0_0_jax` or `tabfm_v1_0_0_pytorch`, call `.load()` for classification or `.load(model_type="regression")` for regression, and wrap the result in `TabFMClassifier` or `TabFMRegressor`. The README states the scikit-learn wrapper works with either backend model, so the choice between JAX and PyTorch is about your environment, not your code.

Installing a backend and running the first prediction

Installation is a local editable install with a backend extra. The README gives three variants; the JAX CPU path is:

git clone https://github.com/google-research/tabfm.git
cd tabfm
pip install -e .[jax]

For GPU you use `.[jax,cuda]`, and for the PyTorch backend `.[pytorch]`, with the README noting you should install the CUDA-appropriate PyTorch yourself first. It requires Python 3.11 or newer, and pins specific versions per backend: `jax==0.10.1` with `flax==0.12.7` using the modern `flax.nnx` API, or `torch==2.12.1+cpu` or a GPU build. Hugging Face Hub is needed because `load()` downloads the weights.

A first classification follows the scikit-learn shape exactly:

from tabfm import TabFMClassifier, tabfm_v1_0_0_jax as tabfm_v1_0_0
model = tabfm_v1_0_0.load()
clf = TabFMClassifier(model=model)
clf.fit(X_train, y_train)
predictions = clf.predict(X_test)
probabilities = clf.predict_proba(X_test)

`X_train` is a pandas DataFrame with mixed numeric and categorical columns, and `clf.fit` prepares the encoders and scalers rather than training the network. You should see class predictions from `predict` and a probability matrix from `predict_proba`. The repository ships runnable scripts too, and `python examples/classification_example.py` runs one end to end; comments inside let you switch backends.

The license split is the real gate on adoption

The most consequential fact about TabFM is not technical. The README carries a prominent license notice: the source code is Apache-2.0, but the default Quick Start calls `tabfm_v1_0_0.load()`, which downloads pretrained weights from Hugging Face distributed under a separate `tabfm-non-commercial-v1.0` license restricted to non-commercial, non-production use. Commercial or production use of the default pretrained weights is not permitted.

This matters more than any accuracy number, because it decides who can actually deploy TabFM. A team evaluating it for a production classifier cannot ship the default weights, full stop. Research, coursework, benchmarking and internal experiments are fine. Anything customer-facing or revenue-generating with the default weights is outside the license.

The README does leave a path: it documents converting your own weights and reusing or changing the recipe, so the framework itself, being Apache-2.0, can in principle run weights you are entitled to use. But out of the box, the thing most people will `load()` is non-commercial. Anyone considering TabFM should settle this question before writing a line of code, because it is the difference between a usable tool and a demo.

Where in-context tabular prediction is the wrong tool

Beyond licensing, the approach has honest limits. The context-window ceiling the README's FAQ acknowledges means very large training sets do not feed in the way they would train a model. If you have millions of labelled rows, the in-context premise works against you, and a method that actually trains on all of them will use the data more fully.

There is also the resource profile. Reading training data as context and running it through a foundation model at every prediction is heavier per inference than evaluating a fitted tree ensemble, which does its expensive work once at training time. For high-throughput, low-latency scoring on a fixed model, that trade can be unfavourable.

So TabFM fits best where a strong result matters more than throughput and the dataset is modest: quick baselines, problems where building a training pipeline is not worth it, and cases with limited labelled data where its zero-shot behaviour shines. It is the wrong tool for very large datasets, for latency-critical serving, and, by license, for production without your own weights.

Against gradient-boosted trees like XGBoost

The default incumbent for tabular problems is a gradient-boosted tree library such as XGBoost, and it is the sharpest contrast. XGBoost trains a model on your dataset: it builds trees that fit your data, which takes a training step and tuning but produces a compact model that scores new rows cheaply forever after.

TabFM's difference in approach is that it skips per-dataset training entirely and predicts from context using pretrained weights. On a small dataset that removes the training and tuning loop and can give a strong answer immediately, which is TabFM's advantage. The cost is the mirror image of XGBoost's strengths: TabFM does not scale to very large training sets the way tree boosting does, its per-prediction cost is higher, and its default weights carry a non-commercial license where XGBoost is Apache-2.0 with no such restriction. The practical read is that TabFM is a fast, capable baseline and a research tool for modest data, while XGBoost remains the choice when you have a lot of data, need cheap repeated inference, or must deploy commercially without weight-license constraints.

Backends, pins and what to check first

The framework's maintenance surface is visible in its build files. It ships a `pyproject.toml`, a `requirements.txt` with pinned dependencies, a `CHANGELOG.md`, and both Bazel (`BUILD`, `MODULE.bazel`, `WORKSPACE`) and pip configurations, which signals it is built to Google's internal conventions and then released. The tight version pins, `jax==0.10.1`, `flax==0.12.7`, `torch==2.12.1+cpu`, make the environment reproducible but also fragile: those exact versions are what it is tested against, and drifting from them is the likely cause of a broken install.

The Apache-2.0 code license means you can fork, modify and integrate the framework freely; the constraint travels with the default weights, not the code. That separation is the thing to internalize.

The concrete first step is to decide the weights question and the backend together. Confirm whether your use is within `tabfm-non-commercial-v1.0` or whether you need to bring your own weights via the documented conversion path, then pick JAX or PyTorch to match your existing stack, and run `python examples/classification_example.py` to verify the download and load work before pointing it at your own data.

Editorial conclusion

Reach for TabFM when you want a strong zero-shot baseline on a modest tabular dataset without building a training pipeline, and your use is research, evaluation or another non-commercial context: the scikit-learn interface and dual JAX/PyTorch backends make it easy to slot in. Do not use it for very large training sets, latency-critical serving, or any production or commercial deployment with the default weights, which the tabfm-non-commercial-v1.0 license forbids. Before writing code, resolve two things: whether your use falls inside that weight license or requires your own converted weights, and which backend matches your stack, then run examples/classification_example.py to confirm the Hugging Face download and load succeed.

Frequently asked questions

Official sources

1. google-research/tabfm on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases