Summary

  • Google 计划从 2026 年 10 月 30 日起单独收取 TabFM 模型 token 费用，查询的非模型部分仍按 slot 或处理字节计费。
  • 官方公式把训练行、预测行、列数与 n_ensembles 连在一起；其余输入不变时，把 ensemble 数翻倍，模型费用也翻倍。

一句 SQL，两个收费口

TabFM 的卖点是省事。用户把已标注样本和待预测数据交给 BigQuery 的 AI.PREDICT，一条查询就能做表格分类或回归，不必另起一套模型部署流程。省下的工程步骤没有让计费变简单。Google Cloud 函数文档写明：从 2026 年 10 月 30 日起，TabFM 消耗的模型 token 单独收费，查询中非模型推理部分仍按 BigQuery slot 或处理字节计费。本文写于 10 月 28 日，所讨论的是两天后拟生效的公开规则，不是已经收到的客户账单。

预览阶段，Enterprise 和 Enterprise Plus 的使用量按 slot 计，按需模式按处理字节计。新规则保留非模型查询的计量，同时加上模型这一项。产品界面仍像一次数据库调用，财务账本却要拆成两行。这种拆分最容易被“已经在 BigQuery 里运行”一句话掩盖。

决定金额的开关藏在参数里

官方价格表列出的输入 token 单价为每百万个 0.05 美元，输出 token 为每百万个 0.20 美元。输入量按“（训练行数 × 列数＋预测行数 ×（列数－1））× n_ensembles”计算；输出量为“预测行数 × n_ensembles”。这里的列数包括参与计算的特征列和目标标签列。n_ensembles 对应不同打乱顺序的数据版本，模型对各版本预测并取平均。它同时乘在输入与输出公式末尾。同样的行数和列数，把该值翻倍，模型 token 账单也翻倍。TabFM 产品文档将特征列上限定为 50。

算一笔示例账：100 万行已标注数据、20 列、10 万行待预测数据、4 个 ensemble。公式得到 8760 万输入 token 和 40 万输出 token，按公开标价分别是 4.38 美元和 0.08 美元，合计 4.46 美元。改成 8 个 ensemble，模型部分变成 8.92 美元。这只是公式演算，不代表任何真实客户的发票；其中还没有 SQL 查询的 slot 或字节费用、存储费和合同折扣。它的价值在于指出成本由哪个变量拉动。

容易试用，也容易让预算失去主人

云平台团队可以管住仓库容量，却未必知道应用开发者把 n_ensembles 从 4 调到 8。分析师可以增加列或预测行数，自动化系统可以把每日任务改成每小时任务。每一个动作都可能扩大模型费用，而原来的容量采购决定没有变。真正的审批对象不能只是一句“使用 BigQuery”，还得包括行数、列数、ensemble 和调用频率。

单次示例成本只有几美元，正适合试验，也正容易被忽略。进入生产后，重复次数比一次试验的价格更要紧。若多跑几个 ensemble 真能改善预测，就该拿可测的准确率增益解释新增费用；若只是因为参数能调，就让工程偏好替财务做了决定。Google 把定价公式写得很明白，企业也有条件把这道题算明白。

目前缺少的是 10 月 30 日之后、能对应具体查询与参数的实际账单。它会告诉我们计划价格落在真实工作负载上有多重。眼下已经可以下判断：Google 没让预测语句变复杂，却把同一条语句接到了两只计价表上。

来源