Google Research lanza TimesFM-3, pero su mejor modelo incluye una restricción comercial

Google Research lanzó TimesFM-3 el 31 de agosto de 2026, incorporando previsión multivariante nativa a una familia de modelos que antes estaba limitada a predicciones de una sola serie. El modelo de 330 millones de parámetros procesa más información en una sola pasada, incluidas series relacionadas, señales históricas y eventos futuros conocidos.

Este cambio es importante porque las previsiones reales rara vez dependen solo de un historial. La demanda minorista responde a promociones y al clima. El consumo energético sigue la temperatura, los horarios y la actividad. Las métricas de infraestructura se mueven en conjunto cuando falla un servicio compartido.

Según Google, TimesFM-3 aborda esa carencia sin requerir ajuste fino específico para cada tarea. Sin embargo, el lanzamiento presenta un conflicto importante. El código sigue siendo abierto bajo Apache 2.0, mientras que los nuevos pesos preentrenados prohíben el uso comercial y en producción.

El resultado es más que otra actualización de modelo. Google Research ha creado una arquitectura de previsión general más sólida, al tiempo que separa la experimentación pública del despliegue sin restricciones. Esto ejerce presión sobre Chronos-2 de Amazon, la familia Toto de Datadog y los equipos que mantienen pipelines de previsión especializados.

Qué cambió Google Research en TimesFM-3

TimesFM-3 transforma la familia TimesFM de un sistema de previsión de una sola serie en un modelo capaz de razonar entre variables conectadas.

Google presentó el TimesFM original en febrero de 2024. Ese modelo utilizaba un transformer de solo decodificador, lo que significa que predecía fragmentos futuros de series temporales a partir de fragmentos anteriores. Sus 200 millones de parámetros se entrenaron con 100.000 millones de puntos temporales del mundo real.

El modelo original realizaba previsiones zero-shot, es decir, generaba predicciones sobre un conjunto de datos no visto sin entrenarse específicamente para ese conjunto. Google informó de resultados competitivos frente a métodos estadísticos y modelos supervisados de aprendizaje profundo en su artículo sobre el modelo de previsión.

TimesFM-2.0 aumentó posteriormente el tamaño del modelo a 500 millones de parámetros. TimesFM-2.5 volvió a 200 millones, al tiempo que amplió el contexto admitido de 2.048 a 16.384 puntos temporales. También añadió previsiones continuas por cuantiles para horizontes de hasta 1.000 pasos.

Sin embargo, esos lanzamientos seguían siendo fundamentalmente univariantes. Cada previsión trataba principalmente una serie objetivo como el objeto que se debía predecir, incluso cuando había regresores externos disponibles mediante un mecanismo separado.

TimesFM-3 cambia ese diseño. Sus 330 millones de parámetros se preentrenaron con más de un billón de puntos temporales reales y sintéticos. Ese corpus de entrenamiento es más de diez veces mayor que el divulgado para el primer modelo.

El modelo acepta varios tipos distintos de información. Múltiples objetivos representan series relacionadas que los usuarios desean prever conjuntamente. Las covariables pasadas aportan variables conocidas solo durante el período de observación. Las covariables pasado-futuro incluyen valores ya conocidos a lo largo del horizonte de previsión.

Por ejemplo, un minorista podría predecir conjuntamente la demanda de helado, conos y sirope. El tráfico histórico de clientes puede servir como covariable pasada. Las promociones planificadas y las previsiones meteorológicas pueden convertirse en covariables pasado-futuro.

Esta disposición permite al modelo aprovechar conexiones que la previsión univariante descarta. Un aumento de ventas resulta más fácil de interpretar cuando el modelo observa que coincidió con una promoción. Los cambios de demanda entre productos relacionados también pueden aportar evidencia sobre comportamientos compartidos.

El lanzamiento oficial de TimesFM-3 afirma que el modelo admite tanto previsiones puntuales como por cuantiles para cada objetivo. Una previsión puntual ofrece un único valor esperado. Los cuantiles describen un rango de posibles resultados y su incertidumbre.

TimesFM-3 produce nueve cuantiles, desde el percentil 10 hasta el 90. Esto es importante para decisiones en las que una sola predicción no basta. Los equipos de inventario necesitan comprender los riesgos de escasez y sobrestock, no solo la demanda esperada.

Google también afirma que el modelo funciona en modo univariante. Por ello, los desarrolladores pueden probar el nuevo checkpoint frente a cargas de trabajo existentes de una sola serie antes de construir un pipeline completo de datos multivariantes.

El lanzamiento ya está disponible mediante el repositorio público de Google Research y un checkpoint de Hugging Face. Google afirma que la integración con BigQuery llegará en las próximas semanas, lo que convierte el 31 de agosto en la fecha de evento verificada detrás de la renovada visibilidad del repositorio.

Por tanto, la tendencia en GitHub está vinculada a un lanzamiento actual, no a un redescubrimiento del proyecto de 2024. TimesFM-3 es el modelo más reciente del repositorio, y la nueva arquitectura multivariante es el evento que impulsa la atención.

Por qué la previsión multivariante cambia las apuestas competitivas

El cambio importante no es simplemente una mayor precisión. TimesFM-3 apunta a las relaciones complejas que determinan si la previsión funciona en producción.

La mayoría de las previsiones operativas se sitúan dentro de sistemas conectados. Un almacén no experimenta la demanda de forma independiente de los precios, las promociones, el clima, los festivos y el inventario cercano. Un centro de datos no genera señales aisladas de CPU, memoria, tráfico y latencia.

Los modelos univariantes simplifican esas relaciones. Pueden detectar estacionalidad, tendencias y patrones recurrentes dentro del historial de un objetivo. Sin embargo, no pueden interpretar directamente una promoción programada a menos que esa información entre mediante otro mecanismo.

La previsión multivariante gestiona varias series de forma conjunta. Puede modelar cómo una variable se mueve con otra y cómo las señales externas modifican el objetivo. Este enfoque resulta especialmente útil cuando esas relaciones se repiten a lo largo del contexto histórico.

El ejemplo ilustrativo de Google para el comercio minorista muestra el motivo. Una previsión univariante prolonga el patrón histórico de ventas semanales. No puede anticipar los días de promoción porque el calendario no aparece en los valores pasados del objetivo.

TimesFM-3 recibe ese calendario como una covariable futura conocida. A continuación, el modelo asocia las promociones históricas con los cambios de ventas y aplica esa relación a las fechas planificadas. El ejemplo de Google muestra un incremento previsto de ventas de aproximadamente un 20 por ciento en cada día de promoción.

Esa cifra es ilustrativa, no evidencia de que el modelo genere la misma predicción de incremento en todos los minoristas. Los efectos de las promociones dependen de los precios, los productos, los clientes, el momento y la calidad de los datos. En cambio, el ejemplo demuestra cómo la información futura entra en la previsión.

Esta capacidad ejerce presión directa sobre otros modelos fundacionales de series temporales. La familia Chronos de Amazon ayudó a consolidar el preentrenamiento al estilo de los modelos de lenguaje como un enfoque viable para la previsión. Más tarde, Chronos-2 amplió la competencia hacia tareas multivariantes y conscientes de covariables.

La familia Toto de Datadog también se dirige a la previsión de propósito general, incluidas las cargas de trabajo multivariantes. La familia Moirai de Salesforce y Tiny Time Mixers de IBM representan otros intentos de sustituir modelos separados y específicos de cada tarea por sistemas preentrenados reutilizables.

La competencia gira cada vez más en torno al alcance del despliegue. Un modelo fundacional que solo funciona en benchmarks públicos y limpios ofrece un valor limitado a un equipo de operaciones. El sistema ganador debe manejar contextos empresariales irregulares, incertidumbre, relaciones cambiantes y costes de inferencia aceptables.

TimesFM-3 ofrece a Google una respuesta creíble frente a rivales que ya habían superado la previsión univariante. También conecta la investigación con un canal de distribución existente. Las capacidades anteriores de TimesFM llegaron a entornos de BigQuery, AlloyDB, Google Sheets y Vertex AI.

Google informó de que TimesFM ya atendía cientos de millones de consultas mensuales a través de BigQuery y AlloyDB durante 2025. Esa cifra se refiere a versiones anteriores del modelo, no a TimesFM-3, pero muestra una ruta establecida desde la investigación hasta el uso habitual.

La distribución podría importar tanto como la posición en los benchmarks. Un modelo de previsión dentro de un almacén permite a los analistas trabajar cerca de datos empresariales gobernados. Evita que cada equipo tenga que montar un servicio de inferencia independiente antes de probar una previsión.

La presión también recae sobre los pipelines de previsión especializados. Muchas organizaciones todavía entrenan modelos distintos para productos, regiones o métricas separadas. Cada modelo requiere ingeniería de características, validación, monitorización y mantenimiento repetido.

Un generalista zero-shot cambia el punto de partida. Los equipos pueden evaluar un modelo en muchas series antes de decidir dónde sigue mereciendo la pena el entrenamiento especializado. Esto no elimina los modelos personalizados, pero eleva el estándar que deben superar.

Por eso también la expresión “sin ajuste fino” requiere una interpretación cuidadosa. Los usuarios todavía deben seleccionar objetivos, preparar covariables, evitar fugas de información, elegir horizontes de previsión y evaluar los costes empresariales. El modelo elimina un paso de entrenamiento, no la disciplina de previsión que lo rodea.

Un modelo de una sola pasada reescribe el mecanismo de previsión

TimesFM-3 combina atención entre series con decodificación de una sola pasada, abordando tanto el contexto ausente como la acumulación de errores.

Al igual que las versiones anteriores de TimesFM, el modelo agrupa observaciones adyacentes en fragmentos de 32 pasos temporales. Un fragmento funciona como un token en un modelo de lenguaje, al comprimir varios valores continuos en una representación interna.

La fragmentación reduce la longitud de la secuencia y facilita el procesamiento de historiales largos. También permite que el transformer opere sobre patrones locales recurrentes en vez de tratar cada medición como un elemento sin relación.

TimesFM-3 organiza esos tokens en dos dimensiones. Una dimensión representa el tiempo. La otra representa las distintas series objetivo y covariables incluidas en la solicitud.

El transformer alterna entre dos operaciones de atención. La atención temporal causal examina fragmentos anteriores dentro de una serie. “Causal” significa que el modelo no puede inspeccionar valores objetivo futuros desconocidos mientras forma una predicción.

La atención completa entre variables opera entre series en la misma posición temporal. Permite que un objetivo extraiga información de otros objetivos y covariables. Así es como un calendario de promociones puede influir en la previsión de ventas asociada.

Las covariables pasado-futuro reciben un tratamiento especial de anticipación. Cada token combina su fragmento actual con fragmentos futuros que contienen información ya conocida. Por tanto, el modelo puede ver eventos programados sin que se le muestren resultados futuros del objetivo.

Esta distinción es esencial. Un calendario futuro de festivos es una entrada válida porque las fechas ya se conocen. Las ventas reales de mañana no son una entrada válida porque revelarlas filtraría la respuesta.

Google Research también modificó el proceso de decodificación. Los modelos TimesFM anteriores generaban fragmentos de previsión de forma secuencial. Cada fragmento predicho se convertía en contexto para producir el siguiente.

La generación secuencial tiene dos debilidades. Aumenta la latencia porque cada paso espera al anterior. También permite que un error de predicción temprano influya en todos los fragmentos posteriores.

En su lugar, TimesFM-3 utiliza enmascaramiento de fragmentos contiguos. El sistema añade marcadores de posición enmascarados que cubren todo el horizonte de previsión y luego predice esas posiciones durante una sola pasada hacia adelante.

Las covariables futuras conocidas permanecen visibles mientras que los valores objetivo siguen enmascarados. La atención temporal y entre variables alternadas procesa el contexto combinado. El modelo completa el horizonte de previsión sin un bucle de generación iterativo.

Este diseño no autorregresivo, es decir, que no produce el horizonte una parte cada vez, es central para la afirmación de rendimiento de Google. Los horizontes más largos ya no requieren proporcionalmente más rondas de decodificación.

El mecanismo también cambia lo que los usuarios deben medir. La latencia bruta del modelo pasa a ser importante, pero también lo son el uso de memoria y la escalabilidad entre muchas variables. La previsión conjunta puede incluir más series en cada solicitud, lo que aumenta la cantidad de cálculo de atención.

El repositorio público de TimesFM incluye ejemplos para entradas univariadas de longitud variable y matrices multivariadas. También muestra entradas independientes para covariables solo pasadas y covariables pasadas-futuras.

Esos ejemplos revelan un requisito práctico. Los usuarios deben alinear cada objetivo y covariable con una línea temporal coherente. Las observaciones faltantes, los informes retrasados y las frecuencias desajustadas pueden comprometer el resultado antes de que comience la inferencia.

Pensemos en una carga de trabajo de observabilidad. La utilización de CPU puede llegar cada minuto, los datos de facturación cada hora y los marcadores de despliegue solo cuando se producen lanzamientos. Combinarlos exige tomar decisiones sobre el remuestreo y los valores faltantes.

Los casos de uso en salud y finanzas añaden restricciones más estrictas. Los equipos deben determinar si una variable externa realmente habría estado disponible en el momento de la predicción. De lo contrario, un benchmark puede parecer preciso porque utilizó accidentalmente información futura.

Explicar TimesFM simplemente como un transformer más grande pasa por alto el punto clave. Su tamaño aumentó de forma moderada respecto a TimesFM-2.5, mientras que el corpus de preentrenamiento se amplió a más de un billón de puntos. El cambio más profundo reside en cómo la arquitectura representa las relaciones y genera el horizonte.

Ese diseño hace que el modelo Google TimesFM sea más relevante para la planificación operativa. También hace que la evaluación sea más difícil. El éxito depende ahora de que las relaciones proporcionadas sean reales, estables, estén correctamente sincronizadas y resulten útiles para la decisión.

Los benchmarks no resuelven la cuestión de producción

Google informa resultados de primer puesto en tres benchmarks públicos, pero las licencias y la validación independiente limitan lo que los adoptantes pueden concluir hoy.

Google evaluó TimesFM-3 en GIFT-Eval, FEV-Bench y TIME. Estas suites cubren distintos conjuntos de datos, tareas de previsión, horizontes y configuraciones de evaluación.

La empresa informa que TimesFM-3 ocupó el primer puesto entre los modelos fundacionales preentrenados tanto para previsiones puntuales como probabilísticas. También afirma que el modelo lideró FEV-Bench en 100 tareas reales y el benchmark TIME en 98 tareas procedentes de 50 dominios.

GIFT-Eval ofrece otra prueba amplia de previsión zero-shot. Google afirma que TimesFM-3 ocupó el primer puesto entre los modelos fundacionales incluidos en esa comparación.

Según se informa, el modelo siguió siendo competitivo en modo univariado, donde no podía aprovechar covariables ni información entre series. Habilitar el modo multivariado completo mejoró aún más su clasificación media.

Son señales significativas porque prueban si un único modelo preentrenado puede transferirse entre conjuntos de datos diversos. También comparan TimesFM-3 con sistemas recientes, incluidos Chronos-2, Toto 2.0 y TimesFM-2.5.

Sin embargo, la clasificación media comprime muchos resultados en una sola cifra. No revela si el modelo gana en las series, los horizontes y los costes de error que importan a una organización concreta.

Un planificador de supermercados podría preocuparse sobre todo por los errores antes de los picos navideños. Un ingeniero de capacidad podría preocuparse por no detectar eventos de tráfico extremo. Un equipo financiero puede valorar más una incertidumbre bien calibrada que una pequeña mejora media.

Los benchmarks públicos también pueden diferir de los datos de producción. Las series empresariales contienen roturas de stock, cambios de políticas, brechas de reporte, lanzamientos de productos y perturbaciones puntuales. Las relaciones aprendidas del historial pueden fallar cuando cambian esas condiciones.

El ángulo escéptico más sólido se refiere al acceso. El código fuente del repositorio tiene una licencia Apache 2.0, y los pesos del modelo hasta TimesFM-2.5 conservan esa licencia. Los pesos de TimesFM-3 usan una licencia no comercial independiente.

Esa licencia restringe los pesos preentrenados predeterminados de TimesFM-3 al uso no comercial y no productivo. Una empresa puede estudiar la arquitectura y realizar experimentos permitidos, pero no puede asumir que el checkpoint descargado sea desplegable en un flujo de trabajo que genere ingresos.

Esto crea una marcada brecha entre la disponibilidad técnica y la disponibilidad operativa. El modelo es público, pero su vía de producción más inmediata sigue bajo el control de Google.

El repositorio también advierte que su versión abierta no es un producto de Google con soporte oficial. Por tanto, los desarrolladores deben distinguir entre código accesible para la comunidad y un servicio que conlleva compromisos de soporte empresarial.

La integración con BigQuery puede resolver parte de la cuestión del despliegue. Google afirma que esa integración llegará en las semanas posteriores al lanzamiento. Sus condiciones, disponibilidad geográfica, cuotas, entradas compatibles y comportamiento en producción serán importantes.

El soporte anterior de TimesFM ya existe mediante la función AI.FORECAST de BigQuery. Esa interfaz reduce la barrera para los usuarios de SQL, pero el soporte de TimesFM-3 debe verificarse después de su implementación.

El lanzamiento también carece del tipo de evidencia independiente en producción que se acumula con el tiempo. Los usuarios públicos solo han tenido unos días para probar el comportamiento multivariado, los requisitos de memoria, los modos de fallo y la sensibilidad a las elecciones de covariables.

Incluso la cifra de Google de un billón de puntos de entrenamiento deja preguntas sin responder. El lanzamiento describe una mezcla de series temporales reales y sintéticas, pero no proporciona un inventario completo del corpus. Los usuarios no pueden juzgar plenamente la cobertura de dominios solo a partir de la escala.

El modelo inicial utilizó datos de Google Trends y de visualizaciones de páginas de Wikipedia entre sus fuentes públicas. Esos conjuntos de datos contienen patrones temporales útiles, pero no se puede dar por sentada la similitud entre esos patrones y las operaciones internas de una empresa.

Las predicciones por cuantiles también requieren validación. Producir nueve estimaciones de incertidumbre no garantiza que sus intervalos estén calibrados en un dominio nuevo. Los equipos deben comprobar con qué frecuencia los resultados reales caen dentro de cada rango previsto.

Por tanto, la prueba práctica es comparativa. Las organizaciones deberían evaluar TimesFM-3 frente a TimesFM-2.5, Chronos-2, Toto, líneas base estadísticas y sus modelos actuales de producción utilizando las mismas divisiones temporales.

También deberían puntuar las decisiones generadas por cada previsión. Una pequeña ganancia estadística puede tener poco valor si la inferencia es más difícil, las covariables no son fiables o las licencias bloquean el despliegue.

Los benchmarks de Google respaldan una evaluación seria. No justifican sustituir un sistema de producción sin pruebas locales, salvaguardas operativas y derechos de uso claros.

Qué observar después del lanzamiento de Google Research

Tres señales determinarán si TimesFM-3 se convierte en una capa de previsión ampliamente utilizada o sigue siendo un influyente checkpoint de investigación.

La primera señal es la prometida integración con BigQuery. La disponibilidad mediante SQL ofrecería a los analistas una vía directa hacia previsiones multivariadas cerca de los datos existentes en el almacén.

Los detalles de implementación revelarán qué parte de TimesFM-3 llega a los usuarios gestionados. Los compradores deberían estar atentos al soporte para múltiples objetivos, covariables históricas, covariables futuras conocidas, salida por cuantiles y horizontes de previsión realistas.

Las condiciones de precios también importan, aunque la evaluación inicial debería centrarse en la adecuación a la carga de trabajo en lugar del coste destacado. La latencia, las cuotas, la disponibilidad regional y los controles de gobierno de datos determinarán si los equipos pueden utilizar el servicio de forma repetida.

Un soporte amplio de BigQuery reforzaría la posición de Google porque convertiría un lanzamiento de investigación en infraestructura accesible. Una integración retrasada o limitada mantendría una oportunidad para rivales y proveedores independientes de previsión.

La segunda señal es la reproducción independiente de los benchmarks. Investigadores y profesionales deben confirmar la clasificación comunicada con conjuntos de datos fijos, reglas de evaluación idénticas y condiciones computacionales comparables.

Debe prestarse especial atención a las tareas multivariadas en las que haya covariables futuras útiles disponibles. Esos casos ponen a prueba la afirmación central de TimesFM-3, en lugar de su rendimiento univariado retrocompatible.

Los evaluadores también deberían publicar resultados por tarea, no solo clasificaciones medias. Ese detalle mostrará dónde tiene dificultades TimesFM-3 y si sus ganancias se concentran en dominios u horizontes específicos.

Las pruebas con valores faltantes, cambios de régimen, covariables ruidosas y grandes cantidades de series relacionadas ofrecerían una relevancia mayor para producción. Podrían debilitar el caso de Google si el rendimiento depende de entradas excepcionalmente limpias.

La tercera señal es el estatus comercial de los pesos preentrenados. Una licencia más amplia permitiría a más organizaciones desplegar el checkpoint mediante su propia infraestructura. Las restricciones continuadas orientarían la adopción comercial hacia los servicios gestionados de Google.

Esa elección afecta al mapa competitivo. Chronos-2, Toto, Moirai y modelos de previsión más pequeños pueden ganar terreno cuando sus condiciones de acceso se ajustan mejor a los requisitos de despliegue privado.

Los desarrolladores deberían examinar la licencia del modelo antes de crear un producto en torno al checkpoint. La disponibilidad pública no invalida sus restricciones declaradas.

Los equipos aún pueden usar el lanzamiento para plantear mejores preguntas técnicas. ¿Mejora la información entre series la precisión tras aplicar controles estrictos contra la fuga de datos? ¿Los eventos futuros conocidos producen cambios razonables? ¿Las previsiones por cuantiles están calibradas durante períodos inusuales?

Una evaluación útil debe preservar un conjunto de reserva basado en el tiempo, comparar líneas base sencillas y calcular costes específicos de cada decisión. Los equipos deben documentar qué covariables se conocían realmente en cada punto histórico de predicción.

También deberían conservar el modelo creíble más simple. Si una línea base estacional tiene un rendimiento similar, el modelo fundacional añade complejidad sin suficiente beneficio. Si TimesFM-3 gana de forma consistente, aporta evidencia a favor de un flujo de trabajo de previsión diferente.

Google Research ha defendido que los modelos de previsión generales deben comprender variables conectadas y generar horizontes completos de forma eficiente. Aún no ha resuelto cuán abiertamente llegarán sus pesos más potentes a producción.

Los próximos meses mostrarán si convergen la disponibilidad gestionada, los resultados independientes y las licencias. Hasta entonces, es mejor tratar TimesFM-3 como un lanzamiento arquitectónico significativo y un candidato de despliegue cuidadosamente acotado.

Para desarrolladores y equipos de datos, la acción inmediata es sencilla: elegir un problema de previsión importante, construir una evaluación segura frente a fugas de datos y probar el modelo frente al sistema que ya está tomando decisiones. ¿TimesFM-3 mejora el resultado que su organización realmente valora?