Model or dataset
limix-ldm-ai/LimiX avatar
limix-ldm-ai/LimiX

LimiX: A Structured-Data Foundation Model That Replaces Task-Specific Pipelines

LimiX: Unleashing Structured-Data Modeling Capability for Generalist Intelligence https://arxiv.org/abs/2509.03505

4,163 stars305 forksPythonApache-2.0

At a glance

What is it?
LimiX is an Apache-2.0 transformer for tabular data that handles classification, regression, imputation and generation under one inference recipe. The trade-off is a heavy CUDA and flash-attn setup that will not fit every environment.
Who is it for?
Adopt LimiX if you have a CUDA 12.2 environment, the patience to build flash-attn from a prebuilt wheel, and a workload where one checkpoint covering classification, regression and imputation saves you from maintaining separate pipelines. Do not adopt it if you need CPU-only inference, if your tabular problems are small enough that XGBoost trains in seconds, or if you cannot accept that the 2M variant drops missing-value imputation.
Can I use it commercially?
Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 92 days ago.
What is it written in?
Mainly Python, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

The problem LimiX targets: one model instead of one pipeline per task

Most tabular work still starts by picking a model per task. Gradient-boosted trees for classification, a different configuration for regression, a separate imputer for missing values, and yet another script if you need synthetic rows. LimiX is built around the claim that a single transformer checkpoint can cover classification, regression, missing value imputation and tabular generation without task-specific network design. The README states the model is focused on joint distribution modeling of variables and missing values, which is the mechanism that lets one set of weights serve several heads.

The intended user is an engineer or researcher who is tired of rebuilding preprocessing and model selection for every new table. The repository lists classification, regression, missing value imputation, feature selection, sample selection and causal inference as tasks under one training and inference recipe. That breadth is the pitch. Whether it holds for your data is a separate question, and the answer depends on how much your columns resemble the prior knowledge base the model was trained on.

How the transformer handles samples and features at once

The README describes the architecture in a few sentences, and they matter more than the benchmark images. Features X and targets Y are embedded from a prior knowledge base into token representations. Attention is then applied across both the sample dimension and the feature dimension, so the model can weigh which rows and which columns are salient for the current task. The resulting representations feed regression and classification heads.

That dual attention is the reason one checkpoint can serve multiple tasks. A classical tabular model treats columns as fixed positions; LimiX treats them as tokens that can be attended over, which is how feature selection and sample selection fall out of the same forward pass rather than requiring separate code. The README also mentions a retrieval mechanism that was enhanced in the 2M release, described as improving performance while reducing inference time and memory consumption. The repository does not spell out the retrieval index format or how it is populated, so treat that as a detail to confirm in the technical report rather than something the README settles.

Installation is the first real filter: CUDA 12.2, torch 2.7.1, flash-attn 2.8.0

The recommended path is the Dockerfile, built against nvidia/cuda:12.2.0-base-ubuntu22.04:

docker build --network=host -t limix/infe:v1 --build-arg FROM_IMAGES=nvidia/cuda:12.2.0-base-ubuntu22.04 -f Dockerfile .

The manual path is more explicit about the constraints. The README pins Python 3.12.7, torch 2.7.1, torchvision 0.22.1 and torchaudio 2.7.1, and instructs you to download a prebuilt flash_attn wheel rather than compile it:

wget -O flash_attn-2.8.0.post2+cu12torch2.7cxx11abiTRUE-cp312-cp312-linux_x86_64.whl https://github.com/Dao-AILab/flash-attention/releases/download/v2.8.0.post2/flash_attn-2.8.0.post2+cu12torch2.7cxx11abiTRUE-cp312-cp312-linux_x86_64.whl

That filename encodes the ABI, CUDA and torch versions. If your environment differs on any of them, the wheel will not load and you are back to compiling flash-attn yourself. The remaining dependencies are installed in one line: scikit-learn, einops, huggingface-hub, matplotlib, networkx, numpy, pandas, scipy, tqdm, typing_extensions, xgboost, kditransform and hyperopt. Note that xgboost and hyperopt ship as dependencies, which suggests the repository includes baseline or tuning code alongside the model itself.

The LimiXPredictor interface and what each parameter commits you to

Inference goes through a single class. The constructor signature in the README is:

LimiXPredictor(device, model_path, mix_precision=True, inference_config, categorical_features_indices=None, outlier_remove_std=12, softmax_temperature=0.9, mask_prediction=False, inference_with_DDP=False, seed=0)

A few of these deserve attention. categorical_features_indices takes a list of integer positions, so you must know your column order at call time; get it wrong and the model will treat a categorical column as numeric. outlier_remove_std defaults to 12, which is a loose threshold and will leave most outliers in place unless you lower it. softmax_temperature=0.9 sharpens classification outputs slightly below the neutral value of 1.0. mask_prediction=False is the default, and the README does not explain in the excerpt what turning it on changes, so that is a parameter to read the technical report for before relying on it.

Model selection is a two-way choice. LimiX-16M supports classification, regression and missing value imputation. LimiX-2M supports classification and regression only. If imputation is part of your pipeline, the smaller and faster checkpoint is not an option. Both are downloaded from Hugging Face under the stableai-org organization.

Where LimiX is the wrong tool

The environment requirements are the clearest limitation. This is a CUDA-first project. The Dockerfile targets CUDA 12.2, the dependency list pins torch 2.7.1, and flash-attn is a hard requirement with a prebuilt wheel tied to a specific Python and ABI combination. There is no documented CPU path in the material. If your deployment target is a CPU-only container or a managed environment where you cannot control the CUDA version, LimiX is not a practical choice regardless of its benchmark results.

The second limitation is task coverage by checkpoint. The 2M variant, which the release notes describe as using significantly less GPU memory and running faster, does not support missing value imputation. That is a real constraint if imputation is why you came. You either accept the larger 16M model or you keep a separate imputer.

The third is the inference_config parameter, typed as list or str, with no example in the supplied README excerpt. Until you read the technical report or the repository's config files, you cannot know what belongs in it. A project whose central entry point takes an undocumented configuration argument is asking you to read source before you can run it.

How LimiX differs from XGBoost and TabPFN-style approaches

XGBoost is the baseline the README names directly. The difference in approach is fundamental. XGBoost builds an ensemble of decision trees on your training split and produces a model specific to that dataset. LimiX is a pretrained foundation model: you load a checkpoint and run inference, with the README describing embedding from a prior knowledge base rather than fitting from scratch. That means no per-dataset training loop, but also no ability to inspect which splits drove a prediction. If your workflow depends on feature importance plots from a fitted booster, you are trading that for attention weights you would have to extract yourself.

TabPFN is the closer comparison in spirit, since it is also a pretrained transformer for tabular data. The difference visible in this material is task scope. LimiX claims classification, regression, imputation, feature selection, sample selection and causal inference under one recipe, and the README positions it against existing tabular foundation models on ten mainstream structured datasets. Whether the dual sample-and-feature attention gives it an edge on your specific table is not something the README can answer for you.

Maintenance, versioning and the Apache-2.0 terms

The release history is short and dense. V1.0 arrived on 2025-08-29, V1.0.1 on 2025-09-19, V1.1.0 on 2025-11-10 alongside the LimiX-2M announcement, and the repository shows a last push in June 2026. The 2M variant was accepted to ICML 2026 according to the news section. A project moving this fast means the interface can shift between minor versions; pin your dependency on a specific release tag rather than tracking main if you are deploying.

Everything is open-sourced under Apache-2.0, including model resources according to the README. That license permits commercial use and modification, and it includes a patent grant. It does not give you any warranty, and it does not cover the pretrained weights' provenance beyond what the repository states. If your organization has a policy on model licensing distinct from code licensing, check whether the checkpoints on Hugging Face carry the same terms as the repository. This is not legal advice; read the LICENSE file and the model card yourself.

Who should adopt LimiX and what to verify first

The fit is narrow but real. You should consider LimiX if you have a CUDA 12.2 capable machine, you are comfortable building from a Dockerfile or pinning torch 2.7.1 with a matching flash-attn wheel, and your workload genuinely spans classification, regression and imputation such that one checkpoint saves you from maintaining three pipelines. Research teams evaluating tabular foundation models against XGBoost baselines are the natural audience, especially since xgboost and hyperopt are already in the dependency list.

You should not adopt it if you need CPU inference, if your tables are small enough that a boosted tree trains in seconds, or if the 2M variant's speed and memory profile is what attracted you but you also need imputation. Those two requirements conflict.

What to verify before you build anything: confirm the flash-attn wheel filename matches your Python version, CUDA version and torch ABI exactly, because that string encodes all three. Read the technical report to learn what inference_config expects and what mask_prediction changes, since the README does not say. And test categorical_features_indices against a table where you already know the column types, because a wrong index list will silently degrade results rather than raise an error.

Editorial conclusion

Adopt LimiX if you have a CUDA 12.2 environment, the patience to build flash-attn from a prebuilt wheel, and a workload where one checkpoint covering classification, regression and imputation saves you from maintaining separate pipelines. Do not adopt it if you need CPU-only inference, if your tabular problems are small enough that XGBoost trains in seconds, or if you cannot accept that the 2M variant drops missing-value imputation. Before committing, verify the flash-attn wheel matches your Python and torch build, check the categorical_features_indices parameter against your own column layout, and confirm which checkpoint actually serves the task you need.

Official sources

  1. License: Apache-2.0
  2. limix-ldm-ai/LimiX on GitHub
  3. Project website
  4. README
  5. Releases
Community notes

Community notes