独立评测 Google TabFM：零样本击败调优 XGBoost，显存虚标与多 GPU Bug 一并曝光

核心结论

Google Research 发布表格数据零样本基础模型 TabFM，宣称单个预训练模型无需训练即可匹敌甚至超越精心调优的梯度提升树。开发者 devYRPauli 随后展开独立复现评测，在三台机器上给出可复现的验证结果与若干重要发现。

主要结论可概括为四点：

• 在中小规模表格上，TabFM 零样本在全部 10 个 fold-matched 数据集上击败经 Optuna 调优的 XGBoost；在锚定数据集上，调优后差距反而扩大，准确率 0.877 对 0.821。

• 经多随机种子复核，其中两项「胜出」因差距小于测量噪声被降级为平局。

• 宣传的「22.75 GB GPU 显存占用」实为 XLA 分配器伪影，实际约 16.95 GB；关闭预分配后可用上下文行数从约 1 万翻倍至约 2 万。

• 发现一个会导致两卡及以上 GPU 机器 predict 阶段崩溃的 Bug，作者定位根因、提交修复与回归测试，PR 已被 google-research/tabfm 的作者之一合并。

所有结果均固定 seed 与依赖，可通过仓库 github.com/devYRPauli/tabfm-evaluation 完整复现。

评测方法与原则

为规避论文与博客中常见的「对自己方法有利」偏差，评测者在动手前自定三条规则：

• 源代码为最终事实，博客与代码冲突时以代码为准。
• 所有结果固定 seed、可逐位复现，不做精选运行。
• 负面结果与正面对待，结果无论胜负都如实记录。

第三条在本次评测中发挥了最关键作用。

TabFM 的技术事实（基于代码核实）

正式 benchmark 前，评测者直接从源码核实了若干关键细节：

• 属于上下文学习（in-context learning），并非训练：调用 fit() 不会更新网络参数，训练行作为单次前向传播时的上下文。
• 默认前向传播采用 32 成员集成，对显存占用与运行成本影响巨大。
• 硬性上限 max_classes = 10，20 类以上分类问题直接不可用。
• 存在两份权重仓库：JAX Orbax 检查点为规范版本，PyTorch 仓库为转换后的 state_dict，校验差异在 1e-4 以内；本次评测采用 JAX 后端。
• 代码采用 Apache-2.0 协议，预训练权重则采用非商业协议，二者管理不同制品，容易被忽略。

固定技术栈：commit b6ea70b、JAX 0.10.2、Flax 0.12.7、Python 3.12。

三机测试环境

评测在三台机器上分工：

• MacBook Pro（M1 Pro，16 GB）：仅作编排。
• Mac Studio（M4 Max，64 GB）：CPU 参考。
• Threadripper PRO 5955WX 工作站（128 GB，双 RTX 4090）：GPU 参考。

MacBook 曾因运行 32 成员集成（需约 17 GB 工作集）触发 macOS 大量 swap（写入约 39 GB）后自动重启，由此催生了 safe_run.sh 看门狗脚本：在运行前预检空闲内存与磁盘，对超限作业主动终止。此后所有重负载任务均通过该脚本统一调度。

复现性前置验证

正式 benchmark 前进行三项检查：

• 一致性与确定性：scikit-learn 接口契约成立，固定 seed 下预测结果位精确可复现，CPU 与 GPU 在 Studio 与 4090 上数值一致。
• 已知答案健全性：XOR 任务准确率达 1.00；随上下文行数增加，准确率从 0.69 升至 0.98；单调函数重建 R² 达 0.997，说明模型确实在做上下文学习，而非模式匹配噪声。
• 自检 bug 捕获：合成数据生成器在 train 与 test 阶段绘制了不同的标签函数，导致健全性测试初看失败。先修正自己的测试框架再下结论，是本次评测反复出现的主题。

正式 Benchmark：TabArena

基准采用 OpenML Study 457 的 TabArena 精选表格套件，选用 13 个数据集子集，规模从 748 到 15 万行，涵盖 9 个分类任务与 4 个回归任务，使用官方 repeat-0 折、每数据集 3 折。对比基线包括 TabFM 的默认预设与 .ensemble() 预设、XGBoost、随机森林、逻辑回归/岭回归下限，以及另一表格基础模型 TabPFN。作者在零样本场景下使用 fold-matched 调优后的 XGBoost 作为强基线，10 个数据集上全胜，另有 3 个数据集因测量噪声降为平局。