表格预测搬进上下文：NVIDIA Kumo Tabular 不训练不调参

训练目标是在每张人造表上，用大部分带标签的行当上下文，去预测剩下的行——分类用交叉熵，回归用分位数损失，而且分类和回归是两个独立训练的模型。训练仿照 TabICLv2 分三段：第一段也是最长的一段用 1024 行、最多 100 列的表，教模型"表长什么样"；第二段把上下文在 400 到 10240 行之间变化；第三段扩到 60000 行，列数仍然不超过 100。三个尺寸的 Kumo Tabular（S/M/L）分别见过约 3500 万、7100 万和 1.37 亿张人造表。训练配方和数据生成器，NVIDIA 说随后开源。

成绩单要横着看，不是竖着看

三个尺寸都按默认设置，对上了完整的 TabArena 排行榜——里面有调过参的梯度提升树、AutoGluon，以及最新的一批表格基础模型。

横轴是每千行推理耗时（对数刻度），纵轴是 ELO。Kumo Tabular 的三个尺寸把帕累托前沿整体左移，LightGBM、AutoGluon、TabPFN-3.5、LimiX-2 都在图上。图片来源：NVIDIA / Hugging Face Blog

Kumo Tabular 总排名第一，ELO 1950；在统一的单卡 RTX 6000 Pro 评测环境下，比同样处在高分区的 LimiX-2 快 17 倍。三个尺寸合起来，在精度-效率的帕累托前沿上创造了新的最好成绩——这张图的意义正在于此：它不是宣称"我最准"，而是宣称"在任何一个你愿意付的推理时间预算上，我都是最准的那个"。

其余三个榜：BeyondArena 上 ELO 1418、Improvability 7.78%，排第一；TALENT 上分类准确率、分类对数损失、回归 RMSE 的平均排名分别是 6.67、3.98、4.22，总排名第一；ScoringBench 是专门评预测分布的，Kumo Tabular 的 Large 和 Medium 按平均排名分列第一第二。最后这一项对风控和定价场景比前面几项更值得看——那些场景要的本来就不是一个点，是一条分布。

四条边界决定你现在能不能用

原文的限制一节写得相当克制，但每一条都直接对应一次上线前的检查：

列的类型：只吃数值列和类别列。文本、图像、时间戳要靠库里内置的预处理配方先转成特征——也就是说，这部分特征工程并没有消失，只是被搬进了一个标准化的入口。

类别数：一次前向最多覆盖 10 个类别，更多类别由库用纠错输出码扩展。多分类场景要先确认你的标签基数。

分布外：表的规模远超训练范围，或者查询行和上下文行不同分布时，精度会下降。结合上一节的训练配置，这给出了一条很具体的自检线——100 列、60000 行是它训练时见过的上界。国内企业里宽表动辄几百列，这是第一个要量的数字，不是最后一个。

校准：NVIDIA 自己把话说在前面了——和任何预测模型一样，部署前要在你自己的留出数据上验准确率和校准。999 个分位数给了你验校准的材料，但验不验是你的事。

调用本身确实只有几行，库会在首次使用时从 Hub 拉权重，预处理、集成和多分类扩展都在里面：

import sdm  # structured-data-models

table = sdm.TableTensor.from_pandas(pd.load_csv(...), device="cuda")
na_mask = table["target"].isnan()
model = sdm.models.KumoTabular(device="cuda")
pred = model(
    x_context=table[~na_mask].drop_columns("target"),
    y_context=table[~na_mask, "target"],
    x_query=table[na_mask].drop_column("target"),
)

注意那个 device="cuda"。这是一次成本结构的置换，不是成本的消失：省掉的是标注之外的调参、验证和一套一套模型的运维，换来的是推理要上 GPU。对一个同时跑着几十个业务表模型、每个都要单独排期维护的团队，这笔账多半划算；对只有一张表、LightGBM 已经跑了三年且没人动的场景，就未必。

国内团队可以先做的一次实验

这类模型真正的价值不在榜单名次上，在你的那张表上。可以用一周做完的对照是这样的：

挑一张列数不超过 100、行数不超过 6 万、标签不超过 10 类的真实业务表——先落在它的训练范围里，把分布外这个变量排除掉。留出一份测试集，一边是你现在那个调过参的梯度提升树，一边是默认设置的 Kumo Tabular，两边都记两个数：预测精度，以及从拿到需求到出第一个可用预测所花的总时间。第二个数才是这篇东西真正在争的东西。

另外两件值得顺手验的事：一是把上下文的 key/value 复用起来跑批量打分，看看在你的数据量上到底省多少——按原文描述，上下文算一次之后可以给后续预测反复用，这对每天全量刷一遍客户表的场景是直接的成本项；二是看校准，把 999 个分位数拿出来，对着你的实际发生率画一张可靠性曲线，再决定它能不能进风控链路。

还有一个容易被忽略的点：全人造数据预训练意味着这个模型在拿到你的表之前，对你的行业一无所知。好处是它不可能"记得"任何真实数据，数据来源和授权这条线是干净的；代价是它也没有任何领域先验可以替你抄近路——你那张表里的信号，得它在上下文里当场看出来。