PriorLabs/TabPFN

Recommended row and feature limits vary by checkpoint — see the Models page for the per-release limits. As a quick reference, the current default (TabPFN-3.5, and TabPFN-3.5-Fast) accepts up to 1,000,000 rows and 20,000 features. If your dataset exceeds the recommended limits for your checkpoint, you can subsample, set ignore_pretraining_limits=True to push past the size guardrail, or upgrade to a release with a higher limit.

TabPFN requires Python 3.10+ due to newer language features. Compatible versions: 3.10, 3.11, 3.12, 3.13, 3.14.

On first use, TabPFN will automatically open a browser window where you can log in via PriorLabs and accept the license terms. Your authentication token is cached locally so you only need to do this once.

For headless / CI environments where a browser is not available, visit https://ux.priorlabs.ai, go to the License tab to accept the license, and then set the TABPFN_TOKEN environment variable with a token obtained from your account.

If access via the browser-based flow is not an option for you, please contact us at sales@priorlabs.ai.

TabPFN automatically downloads model weights when first used. For offline usage:

Using the Provided Download Script

If you have the TabPFN repository, you can use the included script to download all models (including ensemble variants):

# After installing TabPFN
python scripts/download_all_models.py

This script will download the main classifier and regressor models, as well as all ensemble variant models to your system's default cache directory.

Manual Download

1. Download the model files manually from HuggingFace:

   • TabPFN-3.5 (one file serves both classifier and regressor): tabpfn-v3.5-20260909.safetensors
   • TabPFN-3.5-Fast: tabpfn-v3.5-fast-20260909.safetensors

2. Place the file in one of these locations:

   • Specify directly: TabPFNClassifier(model_path="/path/to/model.ckpt")
   • Set environment variable: export TABPFN_MODEL_CACHE_DIR="/path/to/dir" (see environment variables FAQ below)
   • Default OS cache directory:
     • Windows: %APPDATA%\tabpfn\
     • macOS: ~/Library/Caches/tabpfn/
     • Linux: ~/.cache/tabpfn/

Try the following:

• Download the newest version of tabpfn pip install tabpfn --upgrade
• Ensure model files downloaded correctly (re-download if needed)

TabPFN uses Pydantic settings for configuration, supporting environment variables and .env files:

Authentication:

• TABPFN_TOKEN: Provide a PriorLabs authentication token directly (useful for headless/CI environments). Obtain one from https://ux.priorlabs.ai.
• TABPFN_NO_BROWSER: Set to disable automatic browser-based login (e.g. in environments where opening a browser is undesirable).

Model Configuration:

• TABPFN_MODEL_CACHE_DIR: Custom directory for caching downloaded TabPFN models (default: platform-specific user cache directory)
• TABPFN_ALLOW_CPU_LARGE_DATASET: Allow running TabPFN on CPU above the per-model sample limit (5000 for TabPFN-3, TabPFN-3.5 and TabPFN-3.5-Fast, 1000 for older versions). Set to true to override the CPU limitation. Note: large datasets can still be slow on CPU!
• TABPFN_MPS_MEMORY_FRACTION: Fraction of recommended max MPS memory to allow on Apple Silicon (default: 0.7). Used to prevent macOS system crashes; set before importing TabPFN. Values above 1.0 are not recommended.
• TABPFN_MAX_BATCHED_TEST_ROWS: Maximum number of test rows fed through the model in a single forward pass during cached (fit_mode="fit_with_cache") inference (default: 32768). Larger test sets are split into independent chunks of at most this size and concatenated, bounding peak memory. Test rows are conditionally independent given the KV cache, so chunking is mathematically equivalent — results may still differ slightly due to floating-point non-associativity (see #800). Performance should be close to optimal at the default of 32768: the hardware is already saturated at that chunk size and, since the computations are independent, larger chunks bring no speedup. Set to 0 to disable chunking.

PyTorch Settings:

• PYTORCH_CUDA_ALLOC_CONF: PyTorch CUDA memory allocation configuration to optimize GPU memory usage (default: max_split_size_mb:512). See PyTorch CUDA documentation for more information.
• If you experience crashes on Windows with the error message containing Windows fatal exception: code 0xc000001d, try to set ONEDNN_MAX_CPU_ISA=AVX512_CORE_FP16. This is likely an upstream pytorch/oneDNN bug.

Example:

export TABPFN_MODEL_CACHE_DIR="/path/to/models"
export TABPFN_ALLOW_CPU_LARGE_DATASET=true
export PYTORCH_CUDA_ALLOC_CONF="max_split_size_mb:512"

Or simply set them in your .env

Use save_fitted_tabpfn_model to persist a fitted estimator and reload it later with load_fitted_tabpfn_model (or the corresponding load_from_fit_state class methods).

from tabpfn import TabPFNRegressor
from tabpfn.model_loading import (
    load_fitted_tabpfn_model,
    save_fitted_tabpfn_model,
)

# Train the regressor on GPU
reg = TabPFNRegressor(device="cuda")
reg.fit(X_train, y_train)
save_fitted_tabpfn_model(reg, "my_reg.tabpfn_fit")

# Later, or in another process. Defaults to device="auto", as the
# constructors do; pass device= to pin it (e.g. device="cpu").
reg_loaded = load_fitted_tabpfn_model("my_reg.tabpfn_fit")

To store just the foundation model weights (without a fitted estimator) use save_tabpfn_model(reg, "my_tabpfn.ckpt") (imported from tabpfn.model_loading). This merely saves a checkpoint of the pre-trained weights so you can later create and fit a fresh estimator. Reload the checkpoint with load_model_criterion_config.

Yes!

Best practices:

• Feature engineering: Add domain-specific features to improve model performance
• See the Improving Performance guide for the full escalation path

Not effective:

• Adapt feature scaling
• Convert categorical features to numerical values (e.g., one-hot encoding)

Each TabPFN release publishes a default checkpoint: one classification and one regression checkpoint up to TabPFN-3, and from TabPFN-3.5 on a single multitask checkpoint that serves both. Some releases also publish a handful of experimental variants — these aren't guaranteed to exist for every release. We recommend starting with the defaults; the variants are experimental and worse on average. When present, they can be used as part of an ensembling or hyperparameter optimization system, or tried out manually. Their name suffixes refer to what we expect them to be good at.