Summary

  • Google prevé cobrar los tokens de TabFM por separado desde el 30 de octubre de 2026, sin eliminar el cargo de slots o bytes de la consulta.
  • La fórmula oficial multiplica los tokens de entrada y salida por n_ensembles; duplicar ese parámetro duplica la parte del modelo si los datos no cambian.

El truco comercial está dentro del SQL

La promesa de TabFM es atractiva: AI.PREDICT permite clasificar o estimar resultados a partir de tablas sin desplegar un modelo aparte. Se escribe una consulta y se recibe una predicción. La documentación de Google señala ahora el precio de esa sencillez. Desde el 30 de octubre de 2026, los tokens usados por TabFM tendrán su propio cargo, mientras que las partes de la consulta ajenas a la inferencia seguirán consumiendo slots o bytes procesados. La fecha aún no ha llegado al redactar este artículo el 28 de octubre; hablamos de una regla publicada, no de una factura observada.

Durante la versión preliminar, Enterprise y Enterprise Plus se cobran por slots y la modalidad bajo demanda por bytes. El cambio anunciado conserva la medición del trabajo ordinario y suma la del modelo. Para quien programa, sigue habiendo una instrucción. Para quien paga, habrá dos unidades de consumo. Esa diferencia puede perderse precisamente porque la función se integra tan bien en la base de datos.

Un multiplicador de precisión también multiplica dólares

La página oficial de precios establece 0,05 dólares por millón de tokens de entrada y 0,20 por millón de salida. La cuenta de entrada es (filas de entrenamiento × columnas + filas de predicción × (columnas − 1)) × n_ensembles; la de salida, filas predichas × n_ensembles. Las columnas incluyen las variables y la etiqueta objetivo usadas en el cálculo. El parámetro de conjuntos cuenta versiones reordenadas de los datos cuyas predicciones se promedian. Aparece al final de ambas fórmulas: duplicarlo duplica el cargo del modelo para las mismas filas y columnas. La descripción técnica limita las columnas de características a 50.

Supongamos un millón de filas etiquetadas, veinte columnas, 100.000 filas por predecir y cuatro conjuntos. La fórmula produce 87,6 millones de tokens de entrada y 400.000 de salida. A precio de lista, el modelo costaría 4,46 dólares. Con ocho conjuntos, 8,92 dólares. Son cifras hipotéticas calculadas con la fórmula oficial. Quedan fuera el cargo por la consulta, el almacenamiento y los descuentos pactados. El ejercicio no predice la factura de nadie; enseña que un ajuste de calidad tiene una pendiente de coste exacta.

El presupuesto pasa por quien escribe la función

Un responsable de plataforma puede vigilar la capacidad contratada del almacén y no ver que un equipo de producto cambió n_ensembles. Un analista puede ampliar las columnas o la población a predecir. Una aplicación puede repetir el cálculo cada hora. Cada decisión empuja el cargo del modelo sin alterar necesariamente la compra de slots. El control financiero, por tanto, tiene que llegar al texto de la consulta y a su frecuencia.

La tarifa baja por millón facilita la primera prueba. También facilita normalizar una función costosa por repetición antes de que alguien mida cuánto mejora las decisiones. La disciplina útil es concreta: registrar filas, columnas, conjuntos y ejecuciones; después, comparar el coste adicional de otro conjunto con la mejora observada en precisión. Comprar más predicciones porque el botón existe es una política de gasto bastante pobre.

Google ya ha publicado fórmula, precios y fecha. Falta una factura posterior al 30 de octubre vinculada a una carga de trabajo conocida para medir el efecto en un cliente real. Entretanto, el dato de mercado es la separación de la cuenta: BigQuery vende la facilidad de una sola consulta y cobra el modelo con un medidor propio.

Fuentes