表格数据是深度学习输得最惨的战场。NLP 被 Transformer 统一了，CV 被 ViT 统治了，强化学习在棋盘上碾压人类了。但回到企业最常用的结构化表格，XGBoost 和 LightGBM 这些诞生于 2016 年的梯度提升树模型，到现在依然是绝大多数数据科学家的默认选择。
过去八年，无数深度学习模型试图攻下这个堡垒。TabNet 来过，输了。NODE 来过，也输了。Transformer 套上表格数据，大多数时候只是在跟一棵调过参的决策树打平手。这不是算法不够聪明，是表格数据的结构太特殊，异构列、缺失值、非线性交互，每一项都在跟深度学习的假设对着干。
2026 年 6 月 30 日，Google Research 发布了 TabFM，声称用一个预训练模型，零训练、零调参、零特征工程，在 TabArena 基准上把调参调满的梯度提升树模型拉下了马。这个说法太大了，大到任何一个在 GitHub 上泡够五年的人都会下意识地启动 BS 检测器。
我在它的代码、基准、Issue 区和社区讨论里泡了一圈。结论比”牛逼”或”炒作”都复杂。这篇文章想讲清楚一件事：TabFM 到底改变了什么，以及它暂时还改不了什么。
TabFM 的核心思路其实不复杂：它不训练。你把历史数据（特征加标签）和待预测数据（只有特征）一起塞给它，它在一个前向传播里读完上下文，直接吐出预测结果。这跟大语言模型做 few-shot 推理是一个逻辑，只不过”上下文”不是自然语言，是表格行。
架构上它混合了两种已有路线的优点。先用交替行列注意力在原始表格值上捕捉特征交互，这部分像 TabPFN，不需要手工做特征交叉。然后把每行压缩成单个稠密向量，把二维网格降维成一维序列，再用 Transformer 做上下文学习，这部分像 TabICL，控制计算量。这个两段式设计的好处是，它既保留了细粒度的特征交互能力，又避免了在全尺寸表格上跑二次复杂度的行列注意力。
训练规模也值得一提。Google 用结构因果模型生成了数亿个合成数据集来预训练这个模型，覆盖了金融、医疗、零售、技术等多种领域的分布模式，但没有用到任何真实数据。这意味着不存在泄露 TabArena 测试集的风险，同时也绕过了收集企业敏感表格数据的合规问题。
还有一件事容易被人忽略：它是 scikit-learn 兼容的。TabFMClassifier 和 TabFMRegressor 两个类，标准的 fit() 和 predict() 接口。如果你已经在用 sklearn pipeline，把 RandomForestClassifier 换成 TabFMClassifier，剩下代码不用改。fit() 实际上不做训练，只是把数据加载进上下文窗口。支持 JAX 和 PyTorch 双后端，GPU 加速开箱即用。
不过等等，max_classes 硬限制在 10 个类别。超过 10 类的多分类问题直接报错。默认上下文窗口最多 500 个特征和 100 行训练数据，虽然可以调，但 GPU 显存是硬天花板。
跑起来看看
安装不复杂，但需要 Python 3.11 以上。两个后端二选一，别两个都装，会冲突。新手建议从 PyTorch 后端开始，编译快、显存省，也不用跟 JAX 的 XLA 编译较劲：
# JAX 后端
git clone https://github.com/google-research/tabfm
cd tabfm
pip install -e .[jax]
# PyTorch 后端
pip install -e .[pytorch]
首次运行时模型权重会自动从 Hugging Face 下载，大约几个 GB。注意选后端的时候想清楚：JAX 版本的预训练权重是 Google 官方训练的原始 checkpoint，PyTorch 版本是从 JAX 转换过来的 state_dict，经过社区验证误差在 1e-4 以内。
写几行代码就能跑起来的体验，是 TabFM 最直观的卖点。分类任务的最小可运行示例：
from tabfm import TabFMClassifier
from sklearn.datasets import load_breast_cancer
from sklearn.model_selection import train_test_split
X, y = load_breast_cancer(return_X_y=True)
X_train, X_test, y_train, y_test = train_test_split(X, y, random_state=42)
model = TabFMClassifier()
model.fit(X_train, y_train) # 不训练，只加载上下文
y_pred = model.predict(X_test) # 单次前向传播完成预测
print(f"Accuracy: {(y_pred == y_test).mean():.3f}")
回归任务换成 TabFMRegressor，接口完全一致。如果你想要最佳效果，用 model.ensemble() 替代默认的单次预测，它会跑 32 次不同上下文采样的集成预测，配合 Platt 缩放做概率校准，精度明显更高、显存占用也更大。
跑通基础流程不难，但有几个坑值得提前知道。我把它们按严重程度排一下，省得你踩完才发现：
-
JAX 后端首次编译需要 20 分钟以上。这是 JAX 的 XLA 编译特性，不是卡住了，等就行。PyTorch 后端没有这个问题。 -
显存是硬约束。PyTorch 后端支持 bf16 精度加激活分块，在 RTX 4090 上显存占用只有 3 到 7 GB，能跑到约 4 万行的上下文。JAX 默认在约 2 万行就会 OOM，因为 allocator 会预占大量显存。 -
多 GPU 机器上有一个已知的 crash bug，已经在 PR #59 中修复（截至 2026 年 7 月 27 日已合并）。如果你用的是较早的版本，更新到最新 main 分支即可。
还有个不那么明显但很重要的事：权重协议。代码是 Apache 2.0，但预训练权重用的是 tabfm-non-commercial-v1.0 协议。商业用途或生产环境直接使用默认权重是被禁止的。如果你的公司想做 SaaS 产品，这个限制需要法务先评估。
什么时候用，什么时候别用
| 场景 | 典型用户 | 优势 | 局限 |
|---|---|---|---|
| 快速基线 | 数据科学家 | 零调参出结果，几分钟搞定 | GPU 依赖 |
| 小样本预测 | 研究/冷启动团队 | 预训练先验知识弥补数据不足 | 特征数 ≤ 100 时最佳 |
| 探索性分析 | 分析师（即将支持 BigQuery SQL） | 不需要写训练管道 | 非商业权重限制 |
| 多表格快速评估 | ML 工程师 | 一个模型覆盖所有表格 | 大表性能退化 |
不适用的情况同样重要，说清楚比画饼有用。直接列出来，你自己对号入座：
-
你的特征超过 100 个。TabFM 的表现开始退化，GBDT 的差距缩小甚至反超。Bioresponse 数据集（1776 特征）上 GBDT 明显更好。 -
你跑纯 CPU 推理。XGBoost 毫秒级，TabFM 需要 GPU，成本差两个数量级。 -
你的任务超过 10 个类别。硬限制，别试。 -
你对可解释性有硬性要求。上下文学习的注意力图不如 SHAP 值直观，审计场景会比较难受。
一个容易被忽视的细节：TabFM 的”零训练”不包括数据清洗。脏数据、缺失值、类别不平衡这些问题不会因为你换了模型就消失。Google 的训练数据是合成生成的干净数据，真实世界表格的 messiness 可能会让它的表现低于预期。LinkedIn 上有数据科学家反映在实际生产数据上的结果不如 TabICLv2，差距不大但方向相反。
社区在聊什么
| 指标 | 数据 | 说明 |
|---|---|---|
| Stars | 约 540（截至 2026 年 7 月） | 发布 1 个月，增速健康 |
| 核心维护者 | 约 10 人（Google Research 团队） | Bus Factor 低风险，但全靠 Google 一家 |
| 最新提交 | 2026 年 7 月 27 日 | 活跃迭代，PR 响应快 |
| 协议 | 代码 Apache 2.0，权重 non-commercial | 代码商业友好，权重受限 |
社区反应比我想象的理性。没有出现”RIP XGBoost”刷屏，反而质疑声很集中。HackerNews 上有人直接指出 Elo 评分不足以说明模型在表格任务中的改进幅度，GitHub 的结果文件也需要更清晰的元数据说明。一位评论者写道：”如果 benchmark 细节不透明，企业用户很难判断它能不能替代熟悉的 XGBoost。”LinkedIn 上的讨论更务实，多位数据科学家分享了他们自己的测试结果，TabICLv2 在部分场景下仍然领先，虽然差距不大，但它更轻量且协议是 BSD 3-Clause。
最值得一读的社区贡献来自独立评测者 Yashraj Pandey。他用 Optuna 做了 100 轮 TPE 搜索调参 XGBoost，然后跟 TabFM 在 10 个 fold 匹配数据集上对比。结果 TabFM 全胜，在一个 anchor 数据集上差距反而比轻调参时更大了。但他也做了多 seed 验证，发现两个”胜出”的数据集在统计噪声范围内，主动降级为平局。更关键的是，他找到了一个多 GPU 机器上的 crash bug 并写了修复和回归测试，PR 已经被 TabFM 作者合并。
你可能会问：这到底是社区在严格检验一个好项目，还是在给一个过度营销的产品挑刺？我的判断是前者。TabFM 的作者对社区反馈的响应速度比大多数 Google Research 项目都快，PR 合并、CHANGELOG 更新、bf16 支持这些事都在一个月内完成了。
但社区买不买账是一回事，项目本身能不能站稳是另一回事。聊完了外部声音，该聊点真的了。
值不值得跟
我一开始对这个项目预期不高。Google Research 出过很多发布即巅峰然后慢慢沉寂的项目，再加上”零训练替代 XGBoost”这种说法太像营销话术。泡完代码和社区讨论后，我的判断收窄了：它不是营销空壳，但也不是 XGBoost 杀手。
真正有价值的地方是它证明了表格基础模型这条路走得通。过去大家觉得 Transformer 在表格数据上打不过树模型，是因为结构不匹配。TabFM 用混合架构加数亿合成数据预训练，把这个差距抹平了甚至反超了，这在 2026 年之前是不可想象的。
但它的天花板也很明显。非商业权重协议意味着短期内你只能把它当评估工具用，除非 Google 改变许可或者你自己从头训练一个。GPU 硬依赖让它在边缘部署和高吞吐场景下毫无竞争力。超过 100 个特征的表现退化是结构性的，不是修几个 bug 能解决的。
趋势判断：这个赛道正在快速升温。TabPFN 背后的 Prior Labs 今年 5 月被 SAP 收购了，TabICLv2 保持了轻量和协议友好的优势，Amazon 的 Mitra 在 AutoGluon 里也有一席之地。TabFM 目前的 TabArena Elo 领先只是暂时的，关键是看 Google 后续的 BigQuery AI.PREDICT 集成能不能把它变成企业数据栈里的默认选择。如果这个集成做得好，非商业协议的矛盾会变得更尖锐。
资源地址
分析归分析，技术选型最终要落回到行动上。说到这，该给你一个实在的建议了。
先跑起来再说
如果你在做表格数据的分类或回归，先把 TabFM 装上去跑一个 baseline。零调参拿到一个可用的结果，本身就是对传统 ML 工作流的降维打击。但别急着用它替换生产管道里的 XGBoost。
如果你在观望，关注两个信号：Google 会不会调整权重协议，以及 BigQuery AI.PREDICT 集成上线后的实际延迟和成本。这两点决定了 TabFM 能不能从一个好用的研究工具变成真正的企业级依赖。
有趣的是，这个赛道在过去半年里的变化速度远超我的预期。TabPFN 被 SAP 收购、TabICLv2 开源、TabFM 发布，三件事挤在同一个季度里发生，这不是巧合。表格基础模型这件事，2026 年才算真正开局。