ゼロショットで予測できる TimesFM 3.0 を BigQuery で動かしてみた
はじめに
BigQuery で TimesFM 3.0 が使えるという紹介ブログを見て、少し興味を持ちました。ゼロショットで予測できるモデルっぽいから、使えるなら使ってみたいかなあ、くらいの気持ちです。
そこで、BigQuery の公開データを使って TimesFM 3.0 を動かし、前のバージョンの 2.5 と比べたり、祝日や天気を渡したりしてみました。自分の備忘録も兼ねて、分かったことをまとめます。
TL;DR
TimesFM 3.0 とは
日付順の数字から、この先の値と予測区間を返す
自分のデータで学習させずに使える（ゼロショット）
どう書くか
AI.FORECAST 関数に表を渡す
予測の手がかりになる列（共変量）は future_covariate_cols などで指定する
2.5→3.0 で何が変わったのか
共変量と多変量を扱えるようになった
1 つの系列の予測は、今回の条件では 2.5 のほうが精度が少し高かった
天気を渡すと予測は動いたが、今回の条件では精度はほぼ変わらなかった
プロジェクトにどう組み込むか
3.0 を商用で使えるのは BigQuery だけだが、まだ Preview
本番に入れるなら GA 待ちで、1 つの系列の予測なら BigQuery で 2.5 を今から使える
TimesFM 3.0 とは
TimesFM は、Google Research が作った時系列予測のモデルです。売上やアクセス数のような、日付順に並んだ数字（系列）を渡すと、この先の値と、その幅（予測区間）を返します。
Google が大量の時系列データで事前に学習させてあるので、自分のデータで学習させずに（ゼロショットで）使えます。ただ、予測のたびに過去の系列を渡す必要があり、天気や祝日のような表にない情報は、渡さない限り考慮されません。
BigQuery にもともとある予測モデル ARIMA_PLUS と並べると、こうなります。
ARIMA_PLUS
TimesFM
使う前の準備
CREATE MODEL で自分のデータを学習させる
なし
予測のときに渡すもの
予測する期間
過去の系列（必要なら、天気などの共変量も）
自分のデータの扱い
学習でモデルに覚えさせる
予測のたびに読むだけで、覚えない
BigQuery では 2.5 と 3.0 を選べます。
どう書くか（AI.FORECAST）
AI.FORECAST の引数の一覧は、AI.FORECAST Syntax にあります。
書き方は 2 通りあり、共変量を渡せるのは Multivariate だけです。
1 つの系列を予測する
共変量を渡す
リファレンスの節
Univariate
Multivariate
予測する列
data_col（1 列）
target_cols（リスト。複数書くと、複数の列を同時に予測する多変量になる）
共変量
渡せない
future_covariate_cols、past_covariate_cols
model
2.5 も 3.0 も選べる（省くと 2.5）
'TimesFM 3.0' を必ず書く
また、今回使ったのは、次の BigQuery の公開データです。
bigquery-public-data.new_york.citibike_trips：Citi Bike（ニューヨークのシェアサイクル）の利用記録
1 回の利用が 1 行で、2013-07-01〜2016-09-30 のデータがある
bigquery-public-data.noaa_gsod：NOAA（米国海洋大気庁）の気象データ
観測所ごと・日ごとの天気
例はどちらも、実績が分かっている 2016 年 9 月を隠して予測しています。精度は「2.5→3.0 で何が変わったのか」で見ます。
1 つの系列を予測する
今回は、8 月末までの利用回数から、9 月の利用回数を予測しました。Citi Bike の利用記録を日ごとの利用回数（daily）にまとめ、AI.FORECAST に渡しました。
SELECT *
FROM AI.FORECAST(
TABLE daily, -- 予測に使う過去のデータ（1日1行）
data_col => 'num_trips', -- 予測する列
timestamp_col => 'dt', -- 日付の列
model => 'TimesFM 3.0', -- 省くと TimesFM 2.5
horizon => 30 -- 何点先まで予測するか（1日1行なので日数）
);
SQL 詳細WITH daily AS ( -- 日ごとの利用回数（8/31 まで）
SELECT DATE(starttime) AS dt, COUNT(*) AS num_trips
FROM bigquery-public-data.new_york.citibike_trips
WHERE starttime IS NOT NULL AND starttime < '2016-09-01' -- 9月は答え合わせに使うので隠す
GROUP BY dt
)
SELECT *
FROM AI.FORECAST(
TABLE daily,
data_col => 'num_trips',
timestamp_col => 'dt',
model => 'TimesFM 3.0',
horizon => 30
);
実行結果（抜粋）
forecast_timestamp
forecast_value
confidence_level
prediction_interval_lower_bound
prediction_interval_upper_bound
ai_forecast_status
2016-09-01 00:00:00
56191.88
0.95
49976.22
61698.79
''
2016-09-02 00:00:00
53535.74
0.95
44921.19
60750.70
''
2016-09-03 00:00:00
42717.00
0.95
32562.72
51680.64
''
2016-09-04 00:00:00
40867.40
0.95
28283.59
51935.86
''
forecast_value が予測の中央値、prediction_interval_lower_bound と prediction_interval_upper_bound が 95%（confidence_level）の予測区間です。ai_forecast_status は、成功なら空文字です（値は小数 2 桁に丸めています）。
共変量を渡す
共変量は、予測の手がかりとして一緒に渡す列です。今回は、天気（降水量・平均気温）を共変量にして、9 月の利用回数を予測しました。
日ごとの利用回数（num_trips）に、セントラルパークの降水量（prcp）と平均気温（temp）の列を足した表（daily_with_weather）を作り、AI.FORECAST に渡しました。daily_with_weather の 8 月末から 9 月初めの行は、次のとおりです。
dt
num_trips
prcp（インチ）
temp（華氏）
2016-08-30
57,405
0.0
77.0
2016-08-31
57,214
0.0
78.9
2016-09-01
NULL
0.04
73.9
2016-09-02
NULL
0.46
72.6
SELECT *
FROM AI.FORECAST(
TABLE daily_with_weather, -- 過去の行と、利用回数を NULL にした予測する日の行
target_cols => ['num_trips'], -- 予測する列
timestamp_col => 'dt', -- 日付の列
future_covariate_cols => ['prcp', 'temp'], -- 予測する期間の値も分かっている列
model => 'TimesFM 3.0', -- 共変量を渡すときは 3.0 が必須
horizon => 30, -- 何点先まで予測するか（9月の30日間）
context_window => 1024 -- 予測に使う過去の点数
);
ちなみに、今日までの値しか分からない情報には、future_covariate_cols ではなく past_covariate_cols を使います。
SQL 詳細WITH daily AS ( -- 日ごとの利用回数
SELECT DATE(starttime) AS dt, COUNT(*) AS num_trips
FROM bigquery-public-data.new_york.citibike_trips
WHERE starttime IS NOT NULL
GROUP BY dt
),
weather AS ( -- セントラルパークの観測所の日ごとの天気
SELECT
DATE(CAST(year AS INT64), CAST(mo AS INT64), CAST(da AS INT64)) AS dt,
IF(prcp = 99.99, 0.0, prcp) AS prcp, -- 降水量（インチ）。欠測は 0 とみなす
temp -- 平均気温（華氏）
FROM bigquery-public-data.noaa_gsod.gsod*
WHERE _TABLE_SUFFIX BETWEEN '2013' AND '2016'
AND stn = '725053' AND wban = '94728'
),
daily_with_weather AS ( -- 利用回数に天気を添えた入力（9/30 まで）
SELECT
d.dt,
IF(d.dt < DATE '2016-09-01', d.num_trips, NULL) AS num_trips, -- 予測する9月は NULL にする
w.prcp,
w.temp
FROM daily AS d
JOIN weather AS w ON w.dt = d.dt
)
SELECT *
FROM AI.FORECAST(
TABLE daily_with_weather,
target_cols => ['num_trips'],
timestamp_col => 'dt',
future_covariate_cols => ['prcp', 'temp'],
model => 'TimesFM 3.0',
horizon => 30,
context_window => 1024
);
実行結果（抜粋）
dt
num_trips.value
num_trips.prediction_interval_lower_bound
num_trips.prediction_interval_upper_bound
time_series_type
confidence_level
ai_forecast_status
2016-09-01 00:00:00
53410.43
45873.04
59963.85
forecast
0.95
''
2016-09-02 00:00:00
49312.29
39320.58
58367.76
forecast
0.95
''
2016-09-03 00:00:00
43553.52
31200.80
54973.15
forecast
0.95
''
2016-09-04 00:00:00
44209.27
30954.60
56406.93
forecast
0.95
''
num_trips は 1 つの列で、中に予測の中央値（value）と予測区間の上下限が入っています。表では、取り出すときの書き方に合わせて num_trips.value のように分けて示しました。日付の列は、1 つの系列では forecast_timestamp になりますが、こちらは timestamp_col に渡した dt のまま返ります（値は小数 2 桁に丸めています）。
注意点
future_covariate_cols を使うときは、リファレンスでは context_window（予測に使う過去の点数）を「表の行数 − horizon」以下にするとされています
今回は日ごとの表が 1,200 行弱、horizon が 30
3.0 の既定の 2,048 ではこの決まりを満たさないので 1,024 に設定
context_window は、3.0 では 32 の倍数（64〜2,048）です
horizon の上限は 2.5 が 10,000、3.0 が 1,024 です
target_cols を使うと、出力は予測する列ごとの STRUCT になり、予測値は num_trips.value で取り出します
費用は SQL 1 本あたり約 250MB〜1GB の読み込みです。2026-12-01 からは、3.0 にトークン課金が加わります（AI.FORECAST Pricing）。
2.5→3.0 で何が変わったのか
精度は上がるのか
「1 つの系列を予測する」の SQL で、2016 年 9 月を 2.5 と 3.0 に予測させ、実績と比べました。精度は、実績とのずれで見ます。ずれは「予測と実績の差の絶対値 ÷ 実績」で算出し、値が小さいほど精度が高いことになります。
2016 年 9 月の実績と予測（8 月までのデータで予測）
2 本の予測はほとんど重なりました。急に落ちた日（9/1、9/19、9/30）はいずれも平日で、どちらのモデルもずれが大きくなっています。ずれを平均すると、次のとおりです。
2.5
3.0
30 日間の平均
18.4%
19.9%
平日（22 日）の平均
20.3%
20.7%
土日（8 日）の平均
13.1%
17.7%
紹介ブログでは、3.0 は共変量なしでも 2.5 を含む他のモデルと同等以上とされていますが、これは多くのデータセットでの平均順位として書かれています。今回比べたのは 1 つのデータの 1 か月分で、言えるのは、このデータの 9 月では 2.5 のほうが精度が少し高かった、というところまでです。
2.5 と 3.0 の予測を実績と並べる SQLWITH daily AS ( -- 日ごとの利用回数
SELECT DATE(starttime) AS dt, COUNT(*) AS num_trips
FROM bigquery-public-data.new_york.citibike_trips
WHERE starttime IS NOT NULL
GROUP BY dt
),
train AS (
SELECT * FROM daily WHERE dt < '2016-09-01' -- 9月を隠す
),
fc_25 AS (
SELECT * FROM AI.FORECAST(TABLE train, data_col => 'num_trips', timestamp_col => 'dt', model => 'TimesFM 2.5', horizon => 30)
),
fc_30 AS (
SELECT * FROM AI.FORECAST(TABLE train, data_col => 'num_trips', timestamp_col => 'dt', model => 'TimesFM 3.0', horizon => 30)
)
SELECT
a.dt,
a.num_trips AS actual,
ROUND(f25.forecast_value) AS forecast_25, -- forecast_value は予測の中央値
ROUND(f30.forecast_value) AS forecast_30,
-- その日の予測が実績から何%ずれたか
ROUND(ABS(f25.forecast_value - a.num_trips) / a.num_trips * 100, 1) AS error_pct_25,
ROUND(ABS(f30.forecast_value - a.num_trips) / a.num_trips * 100, 1) AS error_pct_30,
-- 30日分の平均を全行に入れる（OVER () は行をまとめずに全体で集計する）
ROUND(AVG(ABS(f25.forecast_value - a.num_trips) / a.num_trips) OVER () * 100, 1) AS avg_error_pct_25,
ROUND(AVG(ABS(f30.forecast_value - a.num_trips) / a.num_trips) OVER () * 100, 1) AS avg_error_pct_30
FROM daily AS a
-- 予測の日付は時刻付きで返るので、日付に直して実績とつなぐ
JOIN fc_25 AS f25 ON DATE(f25.forecast_timestamp) = a.dt
JOIN fc_30 AS f30 ON DATE(f30.forecast_timestamp) = a.dt
ORDER BY a.dt;
共変量を渡せるようになった
BigQuery で共変量と多変量を扱えるのは、「どう書くか」の表のとおり 3.0 だけです。紹介ブログには、アイスクリームの販促予定を渡すと、販促日ごとに売上が約 2 割増える予測になる、という例があります。公開データでも同じような結果になるかを、祝日と天気を渡して試しました。ここからは、予測がどれだけ動いたかを回数で、精度をずれ（%）で見ます。
祝日を渡してみる
会員の利用回数で 2016 年 7 月の前半（7/1〜14）を隠し、その日が独立記念日か（1 か 0）を渡す場合と渡さない場合を比べました。2016 年の独立記念日は 7/4 です。
2016 年 7 月の会員の利用回数と、独立記念日を渡す・渡さない予測（TimesFM 3.0）
7/4 の実績は 22,349 回で、普段の平日の半分以下でした。予測は、独立記念日を渡さないと 46,555 回、渡しても 42,234 回で、どちらも実績の 2 倍前後のままでした。参照した過去 1,024 日に独立記念日は 2 回しかなく、例が少なかったのだと考えています。
!
SQL は会員と非会員を同時に予測しています（多変量）が、グラフと数字は会員のみの結果です。
独立記念日を渡す・渡さない予測を実績と並べる SQLWITH daily AS ( -- 日ごとの会員・非会員の利用回数（7/14 まで）
SELECT
DATE(starttime) AS dt,
COUNTIF(usertype = 'Subscriber') AS subscriber_trips, -- 会員の利用回数
COUNTIF(usertype = 'Customer') AS casual_trips -- 非会員の利用回数
FROM bigquery-public-data.new_york.citibike_trips
WHERE starttime IS NOT NULL AND starttime < '2016-07-15'
GROUP BY dt
),
holidays AS (
-- 独立記念日（土曜は前日の金曜に振り替えた日）
SELECT dt FROM UNNEST([ -- 並べた日付を1行ずつの表にする
DATE '2013-07-04', DATE '2014-07-04', DATE '2015-07-03', DATE '2016-07-04'
]) AS dt
),
with_flag AS ( -- 祝日を渡す側の入力（7/14 までの全行を持つ）
SELECT
d.dt,
-- 予測したい日（7/1 以降）は NULL にする
IF(d.dt < DATE '2016-07-01', d.subscriber_trips, NULL) AS subscriber_trips,
IF(d.dt < DATE '2016-07-01', d.casual_trips, NULL) AS casual_trips,
-- 祝日は先の日付でも分かるので全期間に値を入れる
IF(h.dt IS NULL, 0.0, 1.0) AS is_holiday
FROM daily AS d
LEFT JOIN holidays AS h ON d.dt = h.dt -- 祝日でない日は h.dt が NULL になる
),
without_flag AS ( -- 祝日を渡さない側の入力（6/30 まで、祝日の列はない）
SELECT dt, subscriber_trips, casual_trips
FROM daily
WHERE dt < DATE '2016-07-01'
),
fc_with AS (
SELECT *
FROM AI.FORECAST(
TABLE with_flag,
target_cols => ['subscriber_trips', 'casual_trips'], -- 同時に予測する列
timestamp_col => 'dt',
future_covariate_cols => ['is_holiday'], -- 予測する期間の値も分かっている列
model => 'TimesFM 3.0',
horizon => 14,
context_window => 1024 -- 予測に使う過去の点数
)
),
fc_without AS (
SELECT *
FROM AI.FORECAST(
TABLE without_flag,
target_cols => ['subscriber_trips', 'casual_trips'],
timestamp_col => 'dt',
model => 'TimesFM 3.0',
horizon => 14,
context_window => 1024
)
)
SELECT
a.dt,
f.is_holiday,
a.subscriber_trips AS actual_subscriber,
ROUND(fo.subscriber_trips.value) AS without_flag_subscriber, -- 予測値と区間の上下限をまとめた列から予測値を取り出す
ROUND(fw.subscriber_trips.value) AS with_flag_subscriber,
a.casual_trips AS actual_casual,
ROUND(fo.casual_trips.value) AS without_flag_casual,
ROUND(fw.casual_trips.value) AS with_flag_casual
FROM daily AS a
JOIN with_flag AS f ON f.dt = a.dt
JOIN fc_without AS fo ON DATE(fo.dt) = a.dt
JOIN fc_with AS fw ON DATE(fw.dt) = a.dt
WHERE fo.time_series_type = 'forecast' AND fw.time_series_type = 'forecast' -- 予測の行だけに絞る
ORDER BY a.dt;
天気を渡してみる
次は、9 月を隠し、天気（降水量・平均気温）を渡す場合と渡さない場合を比べました。天気を渡す予測は、「共変量を渡す」と同じ SQL で作り、それに天気を渡さない予測と、実績との比較を足しました。渡したのは実際の天気なので、天気予報が完全に当たった場合と同じ条件です。実際に使うなら、渡すのは予報です。
2016 年 9 月の実績と、天気を渡す・渡さない予測（TimesFM 3.0）
天気を渡すと、予測は 1 日平均約 2,400 回動きました。ただ、平均のずれは渡さない場合とほぼ同じで、精度は変わりませんでした。予測が動いても実績に近づかなかった要因は、主に次の 2 つです。
雨の日（降水量 0.2 インチ以上）は 8 日あり、そのうち 7 日で予測が下がりました。しかし、実績が渡さない予測より少なかったのは 2 日だけで、残りは雨でも思ったほど減っていませんでした
月末（9/24〜29）は、天気を渡した予測がさらに下がり、ずれが大きくなりました
天気を渡す・渡さない予測を実績と並べる SQLWITH daily AS ( -- 日ごとの利用回数
SELECT DATE(starttime) AS dt, COUNT(*) AS num_trips
FROM bigquery-public-data.new_york.citibike_trips
WHERE starttime IS NOT NULL
GROUP BY dt
),
weather AS ( -- セントラルパークの観測所の日ごとの天気
SELECT
DATE(CAST(year AS INT64), CAST(mo AS INT64), CAST(da AS INT64)) AS dt,
IF(prcp = 99.99, 0.0, prcp) AS prcp, -- 降水量（インチ）。欠測は 0 とみなす
temp -- 平均気温（華氏）
FROM bigquery-public-data.noaa_gsod.gsod*
WHERE _TABLE_SUFFIX BETWEEN '2013' AND '2016'
AND stn = '725053' AND wban = '94728'
),
daily_with_weather AS ( -- 天気を渡す側の入力（9/30 までの全行を持つ）
SELECT
d.dt,
IF(d.dt < DATE '2016-09-01', d.num_trips, NULL) AS num_trips, -- 9月は NULL にして隠す
w.prcp,
w.temp
FROM daily AS d
JOIN weather AS w ON w.dt = d.dt
),
daily_without_weather AS ( -- 天気を渡さない側の入力（8/31 まで）
SELECT dt, num_trips
FROM daily
WHERE dt < DATE '2016-09-01'
),
fc_with AS (
SELECT *
FROM AI.FORECAST(
TABLE daily_with_weather,
target_cols => ['num_trips'],
timestamp_col => 'dt',
future_covariate_cols => ['prcp', 'temp'], -- 予測する期間の値も分かっている列
model => 'TimesFM 3.0',
horizon => 30,
context_window => 1024
)
),
fc_without AS (
SELECT *
FROM AI.FORECAST(
TABLE daily_without_weather,
target_cols => ['num_trips'],
timestamp_col => 'dt',
model => 'TimesFM 3.0',
horizon => 30,
context_window => 1024
)
)
SELECT
a.dt,
f.prcp,
f.temp,
a.num_trips AS actual,
ROUND(fo.num_trips.value) AS forecast_without_weather,
ROUND(fw.num_trips.value) AS forecast_with_weather,
ROUND(ABS(fo.num_trips.value - a.num_trips) / a.num_trips * 100, 1) AS error_pct_without,
ROUND(ABS(fw.num_trips.value - a.num_trips) / a.num_trips * 100, 1) AS error_pct_with,
ROUND(AVG(ABS(fo.num_trips.value - a.num_trips) / a.num_trips) OVER () * 100, 1) AS avg_error_pct_without,
ROUND(AVG(ABS(fw.num_trips.value - a.num_trips) / a.num_trips) OVER () * 100, 1) AS avg_error_pct_with
FROM daily AS a
JOIN daily_with_weather AS f ON f.dt = a.dt
JOIN fc_without AS fo ON DATE(fo.dt) = a.dt
JOIN fc_with AS fw ON DATE(fw.dt) = a.dt
WHERE fo.time_series_type = 'forecast' AND fw.time_series_type = 'forecast'
ORDER BY a.dt;
結果として、例が数回しかない祝日は予測をあまり動かさず、毎日ある天気は大きく動かしました。ただ、予測が動くことと精度が上がることは別でした。
プロジェクトにどう組み込むか
TimesFM は BigQuery のほかでも動かせます（2026-10-19 時点）。
経路
選べるバージョン
3.0 の扱い
BigQuery（AI.FORECAST）
2.5、3.0
Google Cloud の利用規約に従い、商用で使える。ただし Preview
Model Garden
2.0、2.5（自分でエンドポイントにデプロイする）
3.0 はない
Hugging Face（重みを自前で動かす）
2.5（Apache-2.0）、3.0
3.0 の重みは非商用・非本番に限られる
ライセンス上、3.0 を商用で使えるのは BigQuery だけです（GitHub の README、BigQuery の TimesFM のページ）。ただし BigQuery の 3.0 も Preview で、原則テスト環境向けなので、本番に入れるなら GA 待ちです。1 つの系列の予測で足りるなら、Preview ではない 2.5 を今から使えます。
どちらのバージョンでも、アプリからは、SQL で予測した結果を表に書き込み、それを読む形になります。
おわりに
今回試していないことを残しておきます。
実際の天気ではなく天気予報を渡した場合
別の月でも答え合わせをすると、2.5 と 3.0 の差はどうなるか
多変量で同時に予測すると、別々に予測するより精度が上がるか
共変量と多変量は、今回の執筆で初めて知った言葉でした。実際に試しながら意味を確かめられたので、勉強になりました。共変量は、過去に何度も出てくる情報ほど、予測を動かしやすいのかもしれません。
参考
TimesFM-3: A zero-shot foundation model for multivariate forecasting
The AI.FORECAST function
The TimesFM model
google-research/timesfm
Google Cloud のプロダクトのリリース段階
採用
「あらゆる判断を、Data-Informedに。」
株式会社ギックスでは、一緒に挑戦してくれる仲間を募集しています！
株式会社ギックス HP
株式会社ギックス 採用サイト
エンジニア求人情報
If you are collecting data with timestamps in your project, Google's TimesFM model might be a good fit, e.g. you can predict future trends based on your past, historical and seasonal data.
google-research/timesfm
3 views
TimesFM用海量真实时序做了预训练。新序列直接丢进去就能出点预报，分位数也支持。论文是ICML 2024那篇decoder-only的。
2.5版本适合看单变量和长上下文。多变量和过去/未来协变量这些，到3.0才进主模型。
代码是Apache。2.5的权重也宽松。
google-research/timesfm t.co
1 like · 307 views
What Is TimesFM? Google's Time-Series Foundation Model Explained, and How to Run It in Your Browser
A plain-English guide to Google's TimesFM: what it is, how it's built, why it's called a "foundation model", and what you can do with it, from forecasting CO₂ and oil prices to World Series odds, running free in a web browser.
Try it now: vishalmysore.github.io
Code: vishalmysore/webTimesFM
Model files (ONNX): huggingface.co
---
!Image description
---
What is TimesFM?
TimesFM (short for Time Series Foundation Model) is an open AI model from Google Research that forecasts numbers over time. Give it any list of numbers in time order, such as daily sales, monthly rainfall, hourly electricity use or a stock price, and it predicts what comes next, together with a range of likely outcomes.
What makes it special is that you don't have to train it. TimesFM has already learned what trends, seasons and cycles look like from about 100 billion real-world data points. It can forecast a series it has never seen before, straight away. This is called zero-shot forecasting.
It was introduced in the research paper "A decoder-only foundation model for time-series forecasting" by Abhimanyu Das, Weihao Kong, Rajat Sen and Yichen Zhou (ICML 2024). The code and the model weights up to version 2.5 are open source under the Apache-2.0 licence.
In one sentence: TimesFM is like ChatGPT, but instead of reading and writing words, it reads and writes numbers.
---
What is a time-series foundation model?
A foundation model is a large AI model that is:
1. Pre-trained once on a huge and varied dataset,
2. General-purpose, not built for one task,
3. Usable straight away on new problems (zero-shot), and
4. Adaptable: it can be fine-tuned further if you want.
GPT, Gemini and Claude are foundation models for text. TimesFM is a foundation model for time series, along with others such as Amazon's Chronos, Salesforce's Moirai, Lag-Llama and Nixtla's TimeGPT.
TimesFM vs traditional forecasting (ARIMA, Prophet)
| | Traditional model (ARIMA, Prophet, ETS) | Foundation model (TimesFM) |
|---|---|---|
| Training | Fitted separately for each series | Trained once, used for everything |
| Setup | Needs a data scientist to choose and tune | Paste your numbers, get a forecast |
| Knowledge | Knows only that one series | Has "seen" millions of patterns |
| Uncertainty | Often a single line, or a fitted interval | Built-in quantiles (10%…90%) for every step |
| Best when | You have one important series and time to tune | You have many series, little time, or little history |
---
How TimesFM is built
The core idea: GPT's architecture, applied to numbers
TimesFM is a decoder-only transformer, the same family of neural network as GPT, Gemini and Llama, from Google's 2017 paper "Attention Is All You Need". Google's key change is what counts as a "token":
| | Language model (GPT-style) | TimesFM |
|---|---|---|
| Input token | a word or piece of a word | a patch of 32 consecutive numbers |
| Task | predict the next word | predict the next 128 numbers |
| Trained on | text from the internet | ~100 billion real time points |
| Output | probabilities over a vocabulary | actual values plus quantiles (a range) |
Feeding the model patches instead of single values (an idea also used by PatchTST) makes long histories cheap to read. Predicting a long output patch of 128 steps at once makes forecasts fast and stable.
Inside TimesFM 2.5
These values come from the model's published configuration:
Your numbers ──► split into patches of 32 ──► normalise each patch (mean and spread)
│
▼
Input block: a small residual neural network turns each patch into a 1,280-number token
│
▼
20 transformer layers × 16 attention heads
• each patch attends only to earlier patches (decoder-only, causal)
• rotary position embeddings (knows the order)
• RMS normalisation and QK-norm (stable training)
│
▼
Output block ──► next 128 steps × [mean, 10th, 20th … 90th percentile]
| Setting | TimesFM 2.5 |
|---|---|
| Parameters | about 200 million |
| Transformer layers | 20 |
| Model width | 1,280, with 16 attention heads |
| Input patch | 32 time steps |
| Output per pass | 128 time steps |
| Longest history (context) | 16,384 points |
| Uncertainty | 9 quantiles per step, plus an optional quantile head for horizons up to 1,024 |
For horizons longer than 128 steps, the model feeds its own forecast back in and goes again, the way a chatbot writes one word after another.
What TimesFM was trained on
According to the original paper, the pre-training mix includes:
- Google Trends: search interest over time, at hourly, daily, weekly and monthly scales.
- Wikipedia page views: daily traffic for millions of articles.
- Synthetic data: computer-generated series with known trends, seasons and patterns.
- Public datasets: electricity, traffic, weather, retail and economic series.
That variety is why one model can forecast carbon dioxide, sunspots, shop sales and oil prices.
The technology stack
- Software: Google trained TimesFM with JAX (the first version used Google's PaxML framework). For 2.5, Google publishes both a Flax (JAX) and a PyTorch implementation.
- Hardware: Google's TPUs (Tensor Processing Units), its custom AI chips.
- Weights: shared on Hugging Face as a safetensors file (925 MB for 2.5).
---
TimesFM versions: 1.0, 2.0, 2.5 and 3.0
| Version | Released | Size | Max history | What changed | Weights licence |
|---|---|---|---|---|---|
| TimesFM 1.0 | 2024 | 200M | 512 | The original, from the ICML paper | Apache-2.0 |
| TimesFM 2.0 | 2024–25 | 500M | 2,048 | Bigger model, more data | Apache-2.0 |
| TimesFM 2.5 | Sept 2025 | 200M | 16,384 | Smaller but longer memory; continuous quantile head; no frequency setting; covariates via XReg (Oct 2025) | Apache-2.0 |
| TimesFM 3.0 | Aug 2026 | larger | long | Native multivariate forecasting and covariates; tops fev-bench, the TIME benchmark and GIFT-Eval (per Google) | Non-commercial for downloaded weights; commercial use through Google Cloud BigQuery ML |
Why this project uses TimesFM 2.5: it's small enough to download into a browser, it can read up to 16k points of history, and its Apache-2.0 weights can be used freely, including commercially.
---
What we built: TimesFM in your web browser
webTimesFM runs Google's TimesFM 2.5 entirely inside a web page. There's no server, no Python and no sign-up, and your data never leaves your computer.
Google's PyTorch weights (safetensors, 925 MB)
└─► converted to ONNX (portable model format)
└─► quantised to 8-bit (261 MB) or 4-bit (146 MB)
└─► ONNX Runtime Web (runs AI models in the browser)
└─► WebGPU (your graphics card) or WASM (your CPU)
└─► timesfm.js + index.html on GitHub Pages
- Speed: a 128-step forecast takes about 50–300 milliseconds on a laptop GPU.
- Two model sizes: 8-bit gives practically the same answers as Google's original. 4-bit is a smaller download but can drift on short series.
!Image description
- Proof it's the real model: a Run self-test vs PyTorch button compares the browser's forecasts with forecasts made by Google's own Python code, on your machine.
!Image description
---
What TimesFM does well, and where it fails
Every example on the site has a Hold back option. It hides the most recent data, forecasts it, and scores the result against the simplest possible guess, "no change".
Where it shines: regular patterns
CO₂ at Mauna Loa: a steady rise plus a yearly cycle. TimesFM forecast five years ahead almost exactly, 95% better than "no change".
Sunspots: the ~11-year solar cycle. Reading 85 years of history, TimesFM predicted the next cycle's rise and peak a decade ahead.
!Image description
Where it struggles: shocks from outside the data
World extreme poverty: TimesFM saw the steady decline up to 2018 and expected it to continue. It couldn't know COVID-19 would stall progress in 2020.
The rule of thumb: TimesFM is excellent at patterns (trends, seasons, cycles), but it can't see events (pandemics, wars, policy changes) until they show up in the numbers. For prices, "no change" is very hard to beat; the uncertainty band is the most useful output.
---
Forecasting current affairs: World Series, oil and Bitcoin
The Current affairs tab points TimesFM at this week's news, with data refreshed automatically every day by a GitHub Action.
World Series odds combine three steps:
1. Elo strength ratings from every MLB game this season,
2. TimesFM forecasting each team's strength with an uncertainty band,
3. 100,000 simulated playoffs in the browser, starting from the real series score.
On 17 October 2026, after the Brewers swept the Dodgers, the model gives Milwaukee about a 71% chance of winning the World Series. TimesFM's band moves the odds only slightly. The series score and the season's results do most of the work, and the page says so.
Oil and Bitcoin get 30-day forecasts with uncertainty bands, and the page explains why prices are so hard to forecast.
---
Adding the news: sentiment as a warning light
TimesFM reads only numbers, so a second, much smaller model reads the headlines. Every day, up to 100 Google News headlines per topic (oil, Bitcoin, each playoff team) are scored with VADER, a lightweight sentiment model. They're averaged into a daily news tone from −10 to +10.
Tone isn't direction. "War escalates" sounds negative but pushes oil prices up. So the news never moves the forecast. It works as a warning light instead:
- ⚠ Alert: fires when the latest day's tone is more than twice its usual day-to-day swing.
- Stormy-news band: the forecast chart then adds a purple range, built from how far that price moved in its most turbulent past periods.
Replaying August to October 2026 with no hindsight, three of five oil-news alerts came just before big Brent moves (+7%, +10%, +18%), and one big jump was missed. Even the stormy band was too narrow for the war spike. News can tell you when to worry, not always how much.
---
How to use TimesFM in your own web page
Copy timesfm.js next to your page, then:
<script type="module">
import * as ort from "https://cdn.jsdelivr.net/npm/onnxruntime-web@1.29.0/dist/ort.webgpu.min.mjs";
import { TimesFM } from "./timesfm.js";
ort.env.wasm.wasmPaths = "https://cdn.jsdelivr.net/npm/onnxruntime-web@1.29.0/dist/";
const model = await TimesFM.load(ort,
"https://huggingface.co/VishalMysore/timesfm-2.5-200m-onnx-web/resolve/main/timesfm25_q8.onnx",
navigator.gpu ? "webgpu" : "wasm");
const history = [/* your numbers, oldest first */];
const { point, quantiles } = await model.forecast(history, 128);
// point: median forecast; quantiles[t] = [mean, q10, q20, ..., q90]
</script>
No code? Open the site's Tutorial tab. It shows how to paste a column from Excel or Google Sheets, upload a CSV, choose context and horizon, and check accuracy with Hold back.
For Python, use Google's official package and examples at google-research/timesfm.
---
Try it
vishalmysore.github.io: open it, click **Load model (a one-time 261 MB download), pick an example, and press Forecast. Everything runs on your own machine.
---
Disclaimer
Please read before using the forecasts on this site or in this article.
Not affiliated with Google
- TimesFM is created by Google Research: paper, code, TimesFM 2.5 weights. "Google" and "TimesFM" are names and trademarks of Google LLC.
- webTimesFM is an independent, unofficial community project. It is not made, sponsored, reviewed or endorsed by Google, and nothing here speaks for Google.
About the browser model
- The model running here is a conversion of Google's TimesFM 2.5 weights to ONNX, compressed to 8-bit and 4-bit. The weights' values come only from Google's release; they were not retrained or fine-tuned.
- Compression and the browser re-implementation of the pre- and post-processing mean its forecasts can differ slightly from Google's official code. The 4-bit model differs more, especially on short series. Use the Run self-test vs PyTorch button to check on your own machine.
- TimesFM 2.5 code and weights are licensed under Apache-2.0 and are provided "as is", without warranties or conditions of any kind. The changes made for this conversion are listed on the model card. TimesFM 3.0, which has a separate non-commercial licence, is not used or included.
Not financial, investment or betting advice
- The oil, Bitcoin and other price forecasts are educational demonstrations, not recommendations to buy, sell or hold anything. Prices behave much like a random walk, and in our own tests the model roughly ties a simple "no change" guess.
- The World Series odds are an illustration of a forecasting method, not betting tips. They ignore starting pitchers, injuries and much else that matters.
- Forecasts can be, and often are, wrong. Past accuracy doesn't guarantee future results. Don't make financial, betting, business, medical or policy decisions based on this site. Consult a qualified professional instead.
About the data and the news signal
- Data comes from third-party public sources: MLB Stats API, FRED (Federal Reserve Bank of St. Louis), IMF, World Bank, US Bureau of Labor Statistics, NOAA, SILSO / Royal Observatory of Belgium, Johns Hopkins CSSE and Google News. Each is subject to its own terms and is used here for non-commercial, educational purposes.
- Data can be delayed, revised or incomplete. For example, official oil prices lag the market by about a week. It's refreshed automatically once a day, with no manual checking, and accuracy isn't guaranteed.
- News headlines belong to their publishers and are linked, not copied in full. The news tone is scored automatically by a simple sentiment model (VADER). It can misread sarcasm, context or mixed stories, and it isn't an editorial judgement about any team, company or event.
- Team and league names are trademarks of their respective owners. This project isn't affiliated with or endorsed by Major League Baseball or any team.
Privacy
- Forecasts run entirely in your browser. Numbers you paste or upload aren't sent to any server by this site.
- Your browser does download files from third parties: the model from Hugging Face, and ONNX Runtime from the jsDelivr CDN. Those services may log the request, as any website does.
Use at your own risk
This is a free, open-source demonstration for learning and research. It's provided as is, with no warranty of any kind. The author isn't liable for any loss or damage arising from its use. Always verify important numbers with the original sources.
AI z GitHuba w płatnym bocie tradingowym? Sam otwarty kod nie wystarczy. TimesFM 3.0 ma kod Apache 2.0, ale komercyjne użycie pobranych wag wymaga osobnej licencji. Sprawdzaj licencję modelu, nie tylko kodu.
Źródło: google-research/timesfm
Telegram: t.me
32 views
Mistral's Timestral Runs on a CPU. Its 'Modified MIT' License Stops at $20M a Month
- Book: System Design Pocket Guide: Fundamentals
- Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go
- My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools
- Me: xgabriel.com | GitHub
---
Mistral's new model doesn't write a single word. Timestral, released on October 15, 2026, reads a column of numbers and tells you where it is likely to go next, with a range around the guess. Mistral says its largest version, at 209M parameters, "ranks first on all three of the field's main public benchmarks," and that it "does not need a GPU at inference" (Mistral).
If you run capacity planning, cost forecasts or anomaly alerts off a metrics table, that is a useful release. Then you open the license. The weights ship under what Mistral calls a Modified MIT license, and the modification is a revenue cap: if your company's global monthly revenue went past $20 million in the preceding month, you are not authorized to use it.
What Mistral shipped on October 15
Timestral is a family of four time-series foundation models that share one architecture and training recipe (Mistral). "Foundation model" here means zero-shot: you hand it history and it forecasts, with no training on your data first. The GitHub README lists the checkpoints:
| Model | Hub repo | fp32 weights |
|---|---|---|
| Timestral-5M | mistralai/Timestral-5M | 21 MB |
| Timestral-28M | mistralai/Timestral-28M | 111 MB |
| Timestral-123M | mistralai/Timestral-123M | 490 MB |
| Timestral-209M | mistralai/Timestral-209M | 837 MB |
The 209M model card gives the shape of the thing. It reads up to 32,768 past steps and forecasts up to 1,024 steps per forward pass. Every forecast is 21 quantiles, from 0.01 to 0.99, which gives each step a band of likely values. It takes one series or several at once, plus covariates that are either known only for the past or known into the future (holidays, planned promotions, a scheduled deploy). Missing values go in as NaN.
On a server CPU with 8 threads, forecasting one day ahead from three weeks of 15-minute history, Mistral reports 10 ms for the 5M model and 140 ms for the 209M, with the 28M five times faster than the 209M (Mistral). Mistral's docs list Timestral 1.0 as a "Public Preview" and name no API price, so for now you download it and run it yourself.
The benchmark claims, and who made them
Every number below comes from Mistral. The model card says a tech report is "coming soon," and until it lands you can't check the method.
On the card's comparison table, Timestral-209M scores a MASE of 0.658 on GIFT-Eval, against 0.661 for t0-gamma, 0.667 for TimesFM-3 and 0.698 for Chronos-2 (lower is better). On fev-bench's SQL skill score it posts 50.39, against 49.42 for t0-gamma and 47.28 for Chronos-2 (higher is better). It leads every row, but the margins over the runner-up are small (model card).
The smaller models are the more interesting part for most teams. The 28M scores 0.678 on GIFT-Eval MASE and 0.638 on TIME MASE, both ahead of Chronos-2's 0.698 and 0.662, though behind t0-gamma and TimesFM-3 on GIFT-Eval and a hair behind t0-gamma's 0.637 on TIME (model card). Mistral describes Chronos-2 as about four times larger (Mistral).
Mistral says the results come from a single checkpoint with no ensembling, submitted to the GIFT-Eval and TIME leaderboards, and that most training data is synthetic, so "nothing we backtest was seen during pre-training" (Mistral). That addresses leakage, the usual worry with forecasting benchmarks. The tech report still has to back it.
!A small black CPU chip on a cream background, with a fan of burnt-orange forecast bands widening to the right out of a single line of history
Timestral returns a band of 21 quantiles per step, and Mistral says it needs no GPU to do it.
The "MIT" in Modified MIT
The inference code is Apache 2.0. The weights are not. The README says they are "distributed separately on the Hugging Face Hub under a Modified MIT license," and that license is where the catch sits.
The grant reads like MIT: use, copy, modify, merge, publish, distribute, sublicense and sell. Then the license file adds that you are "not authorized to exercise any rights under this license if the global consolidated monthly revenue of your company" (or your employer's) "exceeds $20 million (or its equivalent in another currency) for the preceding month." The restriction covers the model "and any derivatives, modifications, or combined works." Companies above the line can ask Mistral for a commercial license, which it may grant at its sole discretion, or use Mistral's hosted services. The 5M model's license carries the same $20 million cap, so a smaller checkpoint isn't a way around it.
How that plays out, as I read it (I'm not a lawyer):
1. It is measured monthly. A company near the line can be inside the license one month and outside it the next.
2. It follows the weights into derivatives, modifications and combined works based on them, including a fine-tuned copy.
3. It counts your whole employer's revenue, however small your team's budget is.
Mistral's announcement pitches Timestral for on-prem, VPC and air-gapped deployment (Mistral). Read that next to the cap. The large enterprises most likely to want air-gapped forecasting are often the ones above $20 million a month, so they need the commercial license. That's my reading of the two documents, not something Mistral has said.
!An open gate in a black fence on a cream background, with a burnt-orange stack of coins rising like a turnstile bar across the opening
The weights are free to use until your company's monthly revenue crosses $20 million.
Try it on a week of traffic
If you're under the line, trying it is short. The package isn't on PyPI. The README installs it from GitHub and asks for Python 3.10+ and torch 2.4+:
pip install git+https://github.com/mistralai/timestral.git
Here's a capacity-planning version of the README's quickstart. It takes hourly request counts and forecasts the next 168 hours with the 28M model:
import numpy as np
from timestral import TimestralForecaster
# One value per line: requests per hour, oldest first.
history = np.loadtxt("requests_per_hour.txt")
model = TimestralForecaster.from_pretrained(
"mistralai/Timestral-28M"
)
week = model.forecast(history, prediction_length=168)
p50 = week.median
p90 = week.quantile(0.9)
print("peak p50:", p50.max())
print("peak p90:", p90.max())
Size servers for the p90, not the median. Actual load lands above the median half the time.
A few options from the README are worth knowing before you put this in a job. from_pretrained takes a revision argument, so pin a commit while the model is in public preview. local_files_only=True (or HF_HUB_OFFLINE=1) makes it read only from the local cache, which suits a locked-down box. Known future events go in known_covariates, shaped (B, C_known, T + prediction_length), and a row of only 0s and 1s is treated as an indicator, which is how you'd flag a launch day.
Where it stops
The README is direct about the limits. Context above 32,768 steps is cut, keeping the most recent. Horizons past 1,024 steps are forecast block by block, and "each block's median is fed back as context," so the far end of a long forecast is built on earlier guesses. Covariates condition the forecast and are never forecast themselves. The project doesn't accept pull requests; issues are handled "on a best-effort basis" (README).
I haven't run Timestral myself, so I can't tell you how it does on your metrics. The fair test is cheap, though: backtest it on a month of your own history against whatever you use now, then check whether your company sits under the $20 million line before anyone builds on it.
Would a revenue cap on "MIT" weights stop you from adopting a model at work, or does a free tier for smaller companies seem like a fair trade? Tell me in the comments.
---
If this was useful
Forecasting load is only half of capacity planning. The other half is knowing what to do with the number: where to cache, when to shard, how much headroom a p90 should buy you. The System Design Pocket Guide: Fundamentals covers those building blocks in a short, practical format.
I also build Hermes IDE, a free, source-available IDE that runs Claude Code, Codex and other coding agents side by side, where each task can get its own branch and worktree, on macOS, Windows and Linux. Star it on GitHub if that sounds useful.
Mentions
ゼロショットで予測できる TimesFM 3.0 を BigQuery で動かしてみた はじめに BigQuery で TimesFM 3.0 が使えるという紹介ブログを見て、少し興味を持ちました。ゼロショットで予測できるモデルっぽいから、使えるなら使ってみたいかなあ、くらいの気持ちです。 そこで、BigQuery の公開データを使って TimesFM 3.0 を動かし、前のバージョンの 2.5 と比べたり、祝日や天気を渡したりしてみました。自分の備忘録も兼ねて、分かったことをまとめます。 TL;DR TimesFM 3.0 とは 日付順の数字から、この先の値と予測区間を返す 自分のデータで学習させずに使える（ゼロショット） どう書くか AI.FORECAST 関数に表を渡す 予測の手がかりになる列（共変量）は future_covariate_cols などで指定する 2.5→3.0 で何が変わったのか 共変量と多変量を扱えるようになった 1 つの系列の予測は、今回の条件では 2.5 のほうが精度が少し高かった 天気を渡すと予測は動いたが、今回の条件では精度はほぼ変わらなかった プロジェクトにどう組み込むか 3.0 を商用で使えるのは BigQuery だけだが、まだ Preview 本番に入れるなら GA 待ちで、1 つの系列の予測なら BigQuery で 2.5 を今から使える TimesFM 3.0 とは TimesFM は、Google Research が作った時系列予測のモデルです。売上やアクセス数のような、日付順に並んだ数字（系列）を渡すと、この先の値と、その幅（予測区間）を返します。 Google が大量の時系列データで事前に学習させてあるので、自分のデータで学習させずに（ゼロショットで）使えます。ただ、予測のたびに過去の系列を渡す必要があり、天気や祝日のような表にない情報は、渡さない限り考慮されません。 BigQuery にもともとある予測モデル ARIMA_PLUS と並べると、こうなります。 ARIMA_PLUS TimesFM 使う前の準備 CREATE MODEL で自分のデータを学習させる なし 予測のときに渡すもの 予測する期間 過去の系列（必要なら、天気などの共変量も） 自分のデータの扱い 学習でモデルに覚えさせる 予測のたびに読むだけで、覚えない BigQuery では 2.5 と 3.0 を選べます。 どう書くか（AI.FORECAST） AI.FORECAST の引数の一覧は、AI.FORECAST Syntax にあります。 書き方は 2 通りあり、共変量を渡せるのは Multivariate だけです。 1 つの系列を予測する 共変量を渡す リファレンスの節 Univariate Multivariate 予測する列 data_col（1 列） target_cols（リスト。複数書くと、複数の列を同時に予測する多変量になる） 共変量 渡せない future_covariate_cols、past_covariate_cols model 2.5 も 3.0 も選べる（省くと 2.5） 'TimesFM 3.0' を必ず書く また、今回使ったのは、次の BigQuery の公開データです。 bigquery-public-data.new_york.citibike_trips：Citi Bike（ニューヨークのシェアサイクル）の利用記録 1 回の利用が 1 行で、2013-07-01〜2016-09-30 のデータがある bigquery-public-data.noaa_gsod：NOAA（米国海洋大気庁）の気象データ 観測所ごと・日ごとの天気 例はどちらも、実績が分かっている 2016 年 9 月を隠して予測しています。精度は「2.5→3.0 で何が変わったのか」で見ます。 1 つの系列を予測する 今回は、8 月末までの利用回数から、9 月の利用回数を予測しました。Citi Bike の利用記録を日ごとの利用回数（daily）にまとめ、AI.FORECAST に渡しました。 SELECT * FROM AI.FORECAST( TABLE daily, -- 予測に使う過去のデータ（1日1行） data_col => 'num_trips', -- 予測する列 timestamp_col => 'dt', -- 日付の列 model => 'TimesFM 3.0', -- 省くと TimesFM 2.5 horizon => 30 -- 何点先まで予測するか（1日1行なので日数） ); SQL 詳細WITH daily AS ( -- 日ごとの利用回数（8/31 まで） SELECT DATE(starttime) AS dt, COUNT(*) AS num_trips FROM bigquery-public-data.new_york.citibike_trips WHERE starttime IS NOT NULL AND starttime < '2016-09-01' -- 9月は答え合わせに使うので隠す GROUP BY dt ) SELECT * FROM AI.FORECAST( TABLE daily, data_col => 'num_trips', timestamp_col => 'dt', model => 'TimesFM 3.0', horizon => 30 ); 実行結果（抜粋） forecast_timestamp forecast_value confidence_level prediction_interval_lower_bound prediction_interval_upper_bound ai_forecast_status 2016-09-01 00:00:00 56191.88 0.95 49976.22 61698.79 '' 2016-09-02 00:00:00 53535.74 0.95 44921.19 60750.70 '' 2016-09-03 00:00:00 42717.00 0.95 32562.72 51680.64 '' 2016-09-04 00:00:00 40867.40 0.95 28283.59 51935.86 '' forecast_value が予測の中央値、prediction_interval_lower_bound と prediction_interval_upper_bound が 95%（confidence_level）の予測区間です。ai_forecast_status は、成功なら空文字です（値は小数 2 桁に丸めています）。 共変量を渡す 共変量は、予測の手がかりとして一緒に渡す列です。今回は、天気（降水量・平均気温）を共変量にして、9 月の利用回数を予測しました。 日ごとの利用回数（num_trips）に、セントラルパークの降水量（prcp）と平均気温（temp）の列を足した表（daily_with_weather）を作り、AI.FORECAST に渡しました。daily_with_weather の 8 月末から 9 月初めの行は、次のとおりです。 dt num_trips prcp（インチ） temp（華氏） 2016-08-30 57,405 0.0 77.0 2016-08-31 57,214 0.0 78.9 2016-09-01 NULL 0.04 73.9 2016-09-02 NULL 0.46 72.6 SELECT * FROM AI.FORECAST( TABLE daily_with_weather, -- 過去の行と、利用回数を NULL にした予測する日の行 target_cols => ['num_trips'], -- 予測する列 timestamp_col => 'dt', -- 日付の列 future_covariate_cols => ['prcp', 'temp'], -- 予測する期間の値も分かっている列 model => 'TimesFM 3.0', -- 共変量を渡すときは 3.0 が必須 horizon => 30, -- 何点先まで予測するか（9月の30日間） context_window => 1024 -- 予測に使う過去の点数 ); ちなみに、今日までの値しか分からない情報には、future_covariate_cols ではなく past_covariate_cols を使います。 SQL 詳細WITH daily AS ( -- 日ごとの利用回数 SELECT DATE(starttime) AS dt, COUNT(*) AS num_trips FROM bigquery-public-data.new_york.citibike_trips WHERE starttime IS NOT NULL GROUP BY dt ), weather AS ( -- セントラルパークの観測所の日ごとの天気 SELECT DATE(CAST(year AS INT64), CAST(mo AS INT64), CAST(da AS INT64)) AS dt, IF(prcp = 99.99, 0.0, prcp) AS prcp, -- 降水量（インチ）。欠測は 0 とみなす temp -- 平均気温（華氏） FROM bigquery-public-data.noaa_gsod.gsod* WHERE _TABLE_SUFFIX BETWEEN '2013' AND '2016' AND stn = '725053' AND wban = '94728' ), daily_with_weather AS ( -- 利用回数に天気を添えた入力（9/30 まで） SELECT d.dt, IF(d.dt < DATE '2016-09-01', d.num_trips, NULL) AS num_trips, -- 予測する9月は NULL にする w.prcp, w.temp FROM daily AS d JOIN weather AS w ON w.dt = d.dt ) SELECT * FROM AI.FORECAST( TABLE daily_with_weather, target_cols => ['num_trips'], timestamp_col => 'dt', future_covariate_cols => ['prcp', 'temp'], model => 'TimesFM 3.0', horizon => 30, context_window => 1024 ); 実行結果（抜粋） dt num_trips.value num_trips.prediction_interval_lower_bound num_trips.prediction_interval_upper_bound time_series_type confidence_level ai_forecast_status 2016-09-01 00:00:00 53410.43 45873.04 59963.85 forecast 0.95 '' 2016-09-02 00:00:00 49312.29 39320.58 58367.76 forecast 0.95 '' 2016-09-03 00:00:00 43553.52 31200.80 54973.15 forecast 0.95 '' 2016-09-04 00:00:00 44209.27 30954.60 56406.93 forecast 0.95 '' num_trips は 1 つの列で、中に予測の中央値（value）と予測区間の上下限が入っています。表では、取り出すときの書き方に合わせて num_trips.value のように分けて示しました。日付の列は、1 つの系列では forecast_timestamp になりますが、こちらは timestamp_col に渡した dt のまま返ります（値は小数 2 桁に丸めています）。 注意点 future_covariate_cols を使うときは、リファレンスでは context_window（予測に使う過去の点数）を「表の行数 − horizon」以下にするとされています 今回は日ごとの表が 1,200 行弱、horizon が 30 3.0 の既定の 2,048 ではこの決まりを満たさないので 1,024 に設定 context_window は、3.0 では 32 の倍数（64〜2,048）です horizon の上限は 2.5 が 10,000、3.0 が 1,024 です target_cols を使うと、出力は予測する列ごとの STRUCT になり、予測値は num_trips.value で取り出します 費用は SQL 1 本あたり約 250MB〜1GB の読み込みです。2026-12-01 からは、3.0 にトークン課金が加わります（AI.FORECAST Pricing）。 2.5→3.0 で何が変わったのか 精度は上がるのか 「1 つの系列を予測する」の SQL で、2016 年 9 月を 2.5 と 3.0 に予測させ、実績と比べました。精度は、実績とのずれで見ます。ずれは「予測と実績の差の絶対値 ÷ 実績」で算出し、値が小さいほど精度が高いことになります。 2016 年 9 月の実績と予測（8 月までのデータで予測） 2 本の予測はほとんど重なりました。急に落ちた日（9/1、9/19、9/30）はいずれも平日で、どちらのモデルもずれが大きくなっています。ずれを平均すると、次のとおりです。 2.5 3.0 30 日間の平均 18.4% 19.9% 平日（22 日）の平均 20.3% 20.7% 土日（8 日）の平均 13.1% 17.7% 紹介ブログでは、3.0 は共変量なしでも 2.5 を含む他のモデルと同等以上とされていますが、これは多くのデータセットでの平均順位として書かれています。今回比べたのは 1 つのデータの 1 か月分で、言えるのは、このデータの 9 月では 2.5 のほうが精度が少し高かった、というところまでです。 2.5 と 3.0 の予測を実績と並べる SQLWITH daily AS ( -- 日ごとの利用回数 SELECT DATE(starttime) AS dt, COUNT(*) AS num_trips FROM bigquery-public-data.new_york.citibike_trips WHERE starttime IS NOT NULL GROUP BY dt ), train AS ( SELECT * FROM daily WHERE dt < '2016-09-01' -- 9月を隠す ), fc_25 AS ( SELECT * FROM AI.FORECAST(TABLE train, data_col => 'num_trips', timestamp_col => 'dt', model => 'TimesFM 2.5', horizon => 30) ), fc_30 AS ( SELECT * FROM AI.FORECAST(TABLE train, data_col => 'num_trips', timestamp_col => 'dt', model => 'TimesFM 3.0', horizon => 30) ) SELECT a.dt, a.num_trips AS actual, ROUND(f25.forecast_value) AS forecast_25, -- forecast_value は予測の中央値 ROUND(f30.forecast_value) AS forecast_30, -- その日の予測が実績から何%ずれたか ROUND(ABS(f25.forecast_value - a.num_trips) / a.num_trips * 100, 1) AS error_pct_25, ROUND(ABS(f30.forecast_value - a.num_trips) / a.num_trips * 100, 1) AS error_pct_30, -- 30日分の平均を全行に入れる（OVER () は行をまとめずに全体で集計する） ROUND(AVG(ABS(f25.forecast_value - a.num_trips) / a.num_trips) OVER () * 100, 1) AS avg_error_pct_25, ROUND(AVG(ABS(f30.forecast_value - a.num_trips) / a.num_trips) OVER () * 100, 1) AS avg_error_pct_30 FROM daily AS a -- 予測の日付は時刻付きで返るので、日付に直して実績とつなぐ JOIN fc_25 AS f25 ON DATE(f25.forecast_timestamp) = a.dt JOIN fc_30 AS f30 ON DATE(f30.forecast_timestamp) = a.dt ORDER BY a.dt; 共変量を渡せるようになった BigQuery で共変量と多変量を扱えるのは、「どう書くか」の表のとおり 3.0 だけです。紹介ブログには、アイスクリームの販促予定を渡すと、販促日ごとに売上が約 2 割増える予測になる、という例があります。公開データでも同じような結果になるかを、祝日と天気を渡して試しました。ここからは、予測がどれだけ動いたかを回数で、精度をずれ（%）で見ます。 祝日を渡してみる 会員の利用回数で 2016 年 7 月の前半（7/1〜14）を隠し、その日が独立記念日か（1 か 0）を渡す場合と渡さない場合を比べました。2016 年の独立記念日は 7/4 です。 2016 年 7 月の会員の利用回数と、独立記念日を渡す・渡さない予測（TimesFM 3.0） 7/4 の実績は 22,349 回で、普段の平日の半分以下でした。予測は、独立記念日を渡さないと 46,555 回、渡しても 42,234 回で、どちらも実績の 2 倍前後のままでした。参照した過去 1,024 日に独立記念日は 2 回しかなく、例が少なかったのだと考えています。 ! SQL は会員と非会員を同時に予測しています（多変量）が、グラフと数字は会員のみの結果です。 独立記念日を渡す・渡さない予測を実績と並べる SQLWITH daily AS ( -- 日ごとの会員・非会員の利用回数（7/14 まで） SELECT DATE(starttime) AS dt, COUNTIF(usertype = 'Subscriber') AS subscriber_trips, -- 会員の利用回数 COUNTIF(usertype = 'Customer') AS casual_trips -- 非会員の利用回数 FROM bigquery-public-data.new_york.citibike_trips WHERE starttime IS NOT NULL AND starttime < '2016-07-15' GROUP BY dt ), holidays AS ( -- 独立記念日（土曜は前日の金曜に振り替えた日） SELECT dt FROM UNNEST([ -- 並べた日付を1行ずつの表にする DATE '2013-07-04', DATE '2014-07-04', DATE '2015-07-03', DATE '2016-07-04' ]) AS dt ), with_flag AS ( -- 祝日を渡す側の入力（7/14 までの全行を持つ） SELECT d.dt, -- 予測したい日（7/1 以降）は NULL にする IF(d.dt < DATE '2016-07-01', d.subscriber_trips, NULL) AS subscriber_trips, IF(d.dt < DATE '2016-07-01', d.casual_trips, NULL) AS casual_trips, -- 祝日は先の日付でも分かるので全期間に値を入れる IF(h.dt IS NULL, 0.0, 1.0) AS is_holiday FROM daily AS d LEFT JOIN holidays AS h ON d.dt = h.dt -- 祝日でない日は h.dt が NULL になる ), without_flag AS ( -- 祝日を渡さない側の入力（6/30 まで、祝日の列はない） SELECT dt, subscriber_trips, casual_trips FROM daily WHERE dt < DATE '2016-07-01' ), fc_with AS ( SELECT * FROM AI.FORECAST( TABLE with_flag, target_cols => ['subscriber_trips', 'casual_trips'], -- 同時に予測する列 timestamp_col => 'dt', future_covariate_cols => ['is_holiday'], -- 予測する期間の値も分かっている列 model => 'TimesFM 3.0', horizon => 14, context_window => 1024 -- 予測に使う過去の点数 ) ), fc_without AS ( SELECT * FROM AI.FORECAST( TABLE without_flag, target_cols => ['subscriber_trips', 'casual_trips'], timestamp_col => 'dt', model => 'TimesFM 3.0', horizon => 14, context_window => 1024 ) ) SELECT a.dt, f.is_holiday, a.subscriber_trips AS actual_subscriber, ROUND(fo.subscriber_trips.value) AS without_flag_subscriber, -- 予測値と区間の上下限をまとめた列から予測値を取り出す ROUND(fw.subscriber_trips.value) AS with_flag_subscriber, a.casual_trips AS actual_casual, ROUND(fo.casual_trips.value) AS without_flag_casual, ROUND(fw.casual_trips.value) AS with_flag_casual FROM daily AS a JOIN with_flag AS f ON f.dt = a.dt JOIN fc_without AS fo ON DATE(fo.dt) = a.dt JOIN fc_with AS fw ON DATE(fw.dt) = a.dt WHERE fo.time_series_type = 'forecast' AND fw.time_series_type = 'forecast' -- 予測の行だけに絞る ORDER BY a.dt; 天気を渡してみる 次は、9 月を隠し、天気（降水量・平均気温）を渡す場合と渡さない場合を比べました。天気を渡す予測は、「共変量を渡す」と同じ SQL で作り、それに天気を渡さない予測と、実績との比較を足しました。渡したのは実際の天気なので、天気予報が完全に当たった場合と同じ条件です。実際に使うなら、渡すのは予報です。 2016 年 9 月の実績と、天気を渡す・渡さない予測（TimesFM 3.0） 天気を渡すと、予測は 1 日平均約 2,400 回動きました。ただ、平均のずれは渡さない場合とほぼ同じで、精度は変わりませんでした。予測が動いても実績に近づかなかった要因は、主に次の 2 つです。 雨の日（降水量 0.2 インチ以上）は 8 日あり、そのうち 7 日で予測が下がりました。しかし、実績が渡さない予測より少なかったのは 2 日だけで、残りは雨でも思ったほど減っていませんでした 月末（9/24〜29）は、天気を渡した予測がさらに下がり、ずれが大きくなりました 天気を渡す・渡さない予測を実績と並べる SQLWITH daily AS ( -- 日ごとの利用回数 SELECT DATE(starttime) AS dt, COUNT(*) AS num_trips FROM bigquery-public-data.new_york.citibike_trips WHERE starttime IS NOT NULL GROUP BY dt ), weather AS ( -- セントラルパークの観測所の日ごとの天気 SELECT DATE(CAST(year AS INT64), CAST(mo AS INT64), CAST(da AS INT64)) AS dt, IF(prcp = 99.99, 0.0, prcp) AS prcp, -- 降水量（インチ）。欠測は 0 とみなす temp -- 平均気温（華氏） FROM bigquery-public-data.noaa_gsod.gsod* WHERE _TABLE_SUFFIX BETWEEN '2013' AND '2016' AND stn = '725053' AND wban = '94728' ), daily_with_weather AS ( -- 天気を渡す側の入力（9/30 までの全行を持つ） SELECT d.dt, IF(d.dt < DATE '2016-09-01', d.num_trips, NULL) AS num_trips, -- 9月は NULL にして隠す w.prcp, w.temp FROM daily AS d JOIN weather AS w ON w.dt = d.dt ), daily_without_weather AS ( -- 天気を渡さない側の入力（8/31 まで） SELECT dt, num_trips FROM daily WHERE dt < DATE '2016-09-01' ), fc_with AS ( SELECT * FROM AI.FORECAST( TABLE daily_with_weather, target_cols => ['num_trips'], timestamp_col => 'dt', future_covariate_cols => ['prcp', 'temp'], -- 予測する期間の値も分かっている列 model => 'TimesFM 3.0', horizon => 30, context_window => 1024 ) ), fc_without AS ( SELECT * FROM AI.FORECAST( TABLE daily_without_weather, target_cols => ['num_trips'], timestamp_col => 'dt', model => 'TimesFM 3.0', horizon => 30, context_window => 1024 ) ) SELECT a.dt, f.prcp, f.temp, a.num_trips AS actual, ROUND(fo.num_trips.value) AS forecast_without_weather, ROUND(fw.num_trips.value) AS forecast_with_weather, ROUND(ABS(fo.num_trips.value - a.num_trips) / a.num_trips * 100, 1) AS error_pct_without, ROUND(ABS(fw.num_trips.value - a.num_trips) / a.num_trips * 100, 1) AS error_pct_with, ROUND(AVG(ABS(fo.num_trips.value - a.num_trips) / a.num_trips) OVER () * 100, 1) AS avg_error_pct_without, ROUND(AVG(ABS(fw.num_trips.value - a.num_trips) / a.num_trips) OVER () * 100, 1) AS avg_error_pct_with FROM daily AS a JOIN daily_with_weather AS f ON f.dt = a.dt JOIN fc_without AS fo ON DATE(fo.dt) = a.dt JOIN fc_with AS fw ON DATE(fw.dt) = a.dt WHERE fo.time_series_type = 'forecast' AND fw.time_series_type = 'forecast' ORDER BY a.dt; 結果として、例が数回しかない祝日は予測をあまり動かさず、毎日ある天気は大きく動かしました。ただ、予測が動くことと精度が上がることは別でした。 プロジェクトにどう組み込むか TimesFM は BigQuery のほかでも動かせます（2026-10-19 時点）。 経路 選べるバージョン 3.0 の扱い BigQuery（AI.FORECAST） 2.5、3.0 Google Cloud の利用規約に従い、商用で使える。ただし Preview Model Garden 2.0、2.5（自分でエンドポイントにデプロイする） 3.0 はない Hugging Face（重みを自前で動かす） 2.5（Apache-2.0）、3.0 3.0 の重みは非商用・非本番に限られる ライセンス上、3.0 を商用で使えるのは BigQuery だけです（GitHub の README、BigQuery の TimesFM のページ）。ただし BigQuery の 3.0 も Preview で、原則テスト環境向けなので、本番に入れるなら GA 待ちです。1 つの系列の予測で足りるなら、Preview ではない 2.5 を今から使えます。 どちらのバージョンでも、アプリからは、SQL で予測した結果を表に書き込み、それを読む形になります。 おわりに 今回試していないことを残しておきます。 実際の天気ではなく天気予報を渡した場合 別の月でも答え合わせをすると、2.5 と 3.0 の差はどうなるか 多変量で同時に予測すると、別々に予測するより精度が上がるか 共変量と多変量は、今回の執筆で初めて知った言葉でした。実際に試しながら意味を確かめられたので、勉強になりました。共変量は、過去に何度も出てくる情報ほど、予測を動かしやすいのかもしれません。 参考 TimesFM-3: A zero-shot foundation model for multivariate forecasting The AI.FORECAST function The TimesFM model google-research/timesfm Google Cloud のプロダクトのリリース段階 採用 「あらゆる判断を、Data-Informedに。」 株式会社ギックスでは、一緒に挑戦してくれる仲間を募集しています！ 株式会社ギックス HP 株式会社ギックス 採用サイト エンジニア求人情報
If you are collecting data with timestamps in your project, Google's TimesFM model might be a good fit, e.g. you can predict future trends based on your past, historical and seasonal data. google-research/timesfm
TimesFM用海量真实时序做了预训练。新序列直接丢进去就能出点预报，分位数也支持。论文是ICML 2024那篇decoder-only的。 2.5版本适合看单变量和长上下文。多变量和过去/未来协变量这些，到3.0才进主模型。 代码是Apache。2.5的权重也宽松。 google-research/timesfm t.co
What Is TimesFM? Google's Time-Series Foundation Model Explained, and How to Run It in Your Browser A plain-English guide to Google's TimesFM: what it is, how it's built, why it's called a "foundation model", and what you can do with it, from forecasting CO₂ and oil prices to World Series odds, running free in a web browser. Try it now: vishalmysore.github.io Code: vishalmysore/webTimesFM Model files (ONNX): huggingface.co --- !Image description --- What is TimesFM? TimesFM (short for Time Series Foundation Model) is an open AI model from Google Research that forecasts numbers over time. Give it any list of numbers in time order, such as daily sales, monthly rainfall, hourly electricity use or a stock price, and it predicts what comes next, together with a range of likely outcomes. What makes it special is that you don't have to train it. TimesFM has already learned what trends, seasons and cycles look like from about 100 billion real-world data points. It can forecast a series it has never seen before, straight away. This is called zero-shot forecasting. It was introduced in the research paper "A decoder-only foundation model for time-series forecasting" by Abhimanyu Das, Weihao Kong, Rajat Sen and Yichen Zhou (ICML 2024). The code and the model weights up to version 2.5 are open source under the Apache-2.0 licence. In one sentence: TimesFM is like ChatGPT, but instead of reading and writing words, it reads and writes numbers. --- What is a time-series foundation model? A foundation model is a large AI model that is: 1. Pre-trained once on a huge and varied dataset, 2. General-purpose, not built for one task, 3. Usable straight away on new problems (zero-shot), and 4. Adaptable: it can be fine-tuned further if you want. GPT, Gemini and Claude are foundation models for text. TimesFM is a foundation model for time series, along with others such as Amazon's Chronos, Salesforce's Moirai, Lag-Llama and Nixtla's TimeGPT. TimesFM vs traditional forecasting (ARIMA, Prophet) | | Traditional model (ARIMA, Prophet, ETS) | Foundation model (TimesFM) | |---|---|---| | Training | Fitted separately for each series | Trained once, used for everything | | Setup | Needs a data scientist to choose and tune | Paste your numbers, get a forecast | | Knowledge | Knows only that one series | Has "seen" millions of patterns | | Uncertainty | Often a single line, or a fitted interval | Built-in quantiles (10%…90%) for every step | | Best when | You have one important series and time to tune | You have many series, little time, or little history | --- How TimesFM is built The core idea: GPT's architecture, applied to numbers TimesFM is a decoder-only transformer, the same family of neural network as GPT, Gemini and Llama, from Google's 2017 paper "Attention Is All You Need". Google's key change is what counts as a "token": | | Language model (GPT-style) | TimesFM | |---|---|---| | Input token | a word or piece of a word | a patch of 32 consecutive numbers | | Task | predict the next word | predict the next 128 numbers | | Trained on | text from the internet | ~100 billion real time points | | Output | probabilities over a vocabulary | actual values plus quantiles (a range) | Feeding the model patches instead of single values (an idea also used by PatchTST) makes long histories cheap to read. Predicting a long output patch of 128 steps at once makes forecasts fast and stable. Inside TimesFM 2.5 These values come from the model's published configuration: Your numbers ──► split into patches of 32 ──► normalise each patch (mean and spread) │ ▼ Input block: a small residual neural network turns each patch into a 1,280-number token │ ▼ 20 transformer layers × 16 attention heads • each patch attends only to earlier patches (decoder-only, causal) • rotary position embeddings (knows the order) • RMS normalisation and QK-norm (stable training) │ ▼ Output block ──► next 128 steps × [mean, 10th, 20th … 90th percentile] | Setting | TimesFM 2.5 | |---|---| | Parameters | about 200 million | | Transformer layers | 20 | | Model width | 1,280, with 16 attention heads | | Input patch | 32 time steps | | Output per pass | 128 time steps | | Longest history (context) | 16,384 points | | Uncertainty | 9 quantiles per step, plus an optional quantile head for horizons up to 1,024 | For horizons longer than 128 steps, the model feeds its own forecast back in and goes again, the way a chatbot writes one word after another. What TimesFM was trained on According to the original paper, the pre-training mix includes: - Google Trends: search interest over time, at hourly, daily, weekly and monthly scales. - Wikipedia page views: daily traffic for millions of articles. - Synthetic data: computer-generated series with known trends, seasons and patterns. - Public datasets: electricity, traffic, weather, retail and economic series. That variety is why one model can forecast carbon dioxide, sunspots, shop sales and oil prices. The technology stack - Software: Google trained TimesFM with JAX (the first version used Google's PaxML framework). For 2.5, Google publishes both a Flax (JAX) and a PyTorch implementation. - Hardware: Google's TPUs (Tensor Processing Units), its custom AI chips. - Weights: shared on Hugging Face as a safetensors file (925 MB for 2.5). --- TimesFM versions: 1.0, 2.0, 2.5 and 3.0 | Version | Released | Size | Max history | What changed | Weights licence | |---|---|---|---|---|---| | TimesFM 1.0 | 2024 | 200M | 512 | The original, from the ICML paper | Apache-2.0 | | TimesFM 2.0 | 2024–25 | 500M | 2,048 | Bigger model, more data | Apache-2.0 | | TimesFM 2.5 | Sept 2025 | 200M | 16,384 | Smaller but longer memory; continuous quantile head; no frequency setting; covariates via XReg (Oct 2025) | Apache-2.0 | | TimesFM 3.0 | Aug 2026 | larger | long | Native multivariate forecasting and covariates; tops fev-bench, the TIME benchmark and GIFT-Eval (per Google) | Non-commercial for downloaded weights; commercial use through Google Cloud BigQuery ML | Why this project uses TimesFM 2.5: it's small enough to download into a browser, it can read up to 16k points of history, and its Apache-2.0 weights can be used freely, including commercially. --- What we built: TimesFM in your web browser webTimesFM runs Google's TimesFM 2.5 entirely inside a web page. There's no server, no Python and no sign-up, and your data never leaves your computer. Google's PyTorch weights (safetensors, 925 MB) └─► converted to ONNX (portable model format) └─► quantised to 8-bit (261 MB) or 4-bit (146 MB) └─► ONNX Runtime Web (runs AI models in the browser) └─► WebGPU (your graphics card) or WASM (your CPU) └─► timesfm.js + index.html on GitHub Pages - Speed: a 128-step forecast takes about 50–300 milliseconds on a laptop GPU. - Two model sizes: 8-bit gives practically the same answers as Google's original. 4-bit is a smaller download but can drift on short series. !Image description - Proof it's the real model: a Run self-test vs PyTorch button compares the browser's forecasts with forecasts made by Google's own Python code, on your machine. !Image description --- What TimesFM does well, and where it fails Every example on the site has a Hold back option. It hides the most recent data, forecasts it, and scores the result against the simplest possible guess, "no change". Where it shines: regular patterns CO₂ at Mauna Loa: a steady rise plus a yearly cycle. TimesFM forecast five years ahead almost exactly, 95% better than "no change". Sunspots: the ~11-year solar cycle. Reading 85 years of history, TimesFM predicted the next cycle's rise and peak a decade ahead. !Image description Where it struggles: shocks from outside the data World extreme poverty: TimesFM saw the steady decline up to 2018 and expected it to continue. It couldn't know COVID-19 would stall progress in 2020. The rule of thumb: TimesFM is excellent at patterns (trends, seasons, cycles), but it can't see events (pandemics, wars, policy changes) until they show up in the numbers. For prices, "no change" is very hard to beat; the uncertainty band is the most useful output. --- Forecasting current affairs: World Series, oil and Bitcoin The Current affairs tab points TimesFM at this week's news, with data refreshed automatically every day by a GitHub Action. World Series odds combine three steps: 1. Elo strength ratings from every MLB game this season, 2. TimesFM forecasting each team's strength with an uncertainty band, 3. 100,000 simulated playoffs in the browser, starting from the real series score. On 17 October 2026, after the Brewers swept the Dodgers, the model gives Milwaukee about a 71% chance of winning the World Series. TimesFM's band moves the odds only slightly. The series score and the season's results do most of the work, and the page says so. Oil and Bitcoin get 30-day forecasts with uncertainty bands, and the page explains why prices are so hard to forecast. --- Adding the news: sentiment as a warning light TimesFM reads only numbers, so a second, much smaller model reads the headlines. Every day, up to 100 Google News headlines per topic (oil, Bitcoin, each playoff team) are scored with VADER, a lightweight sentiment model. They're averaged into a daily news tone from −10 to +10.  Tone isn't direction. "War escalates" sounds negative but pushes oil prices up. So the news never moves the forecast. It works as a warning light instead: - ⚠ Alert: fires when the latest day's tone is more than twice its usual day-to-day swing. - Stormy-news band: the forecast chart then adds a purple range, built from how far that price moved in its most turbulent past periods. Replaying August to October 2026 with no hindsight, three of five oil-news alerts came just before big Brent moves (+7%, +10%, +18%), and one big jump was missed. Even the stormy band was too narrow for the war spike. News can tell you when to worry, not always how much. --- How to use TimesFM in your own web page Copy timesfm.js next to your page, then: <script type="module"> import * as ort from "https://cdn.jsdelivr.net/npm/onnxruntime-web@1.29.0/dist/ort.webgpu.min.mjs"; import { TimesFM } from "./timesfm.js"; ort.env.wasm.wasmPaths = "https://cdn.jsdelivr.net/npm/onnxruntime-web@1.29.0/dist/"; const model = await TimesFM.load(ort, "https://huggingface.co/VishalMysore/timesfm-2.5-200m-onnx-web/resolve/main/timesfm25_q8.onnx", navigator.gpu ? "webgpu" : "wasm"); const history = [/* your numbers, oldest first */]; const { point, quantiles } = await model.forecast(history, 128); // point: median forecast; quantiles[t] = [mean, q10, q20, ..., q90] </script> No code? Open the site's Tutorial tab. It shows how to paste a column from Excel or Google Sheets, upload a CSV, choose context and horizon, and check accuracy with Hold back. For Python, use Google's official package and examples at google-research/timesfm. --- Try it vishalmysore.github.io: open it, click **Load model (a one-time 261 MB download), pick an example, and press Forecast. Everything runs on your own machine. --- Disclaimer Please read before using the forecasts on this site or in this article. Not affiliated with Google - TimesFM is created by Google Research: paper, code, TimesFM 2.5 weights. "Google" and "TimesFM" are names and trademarks of Google LLC. - webTimesFM is an independent, unofficial community project. It is not made, sponsored, reviewed or endorsed by Google, and nothing here speaks for Google. About the browser model - The model running here is a conversion of Google's TimesFM 2.5 weights to ONNX, compressed to 8-bit and 4-bit. The weights' values come only from Google's release; they were not retrained or fine-tuned. - Compression and the browser re-implementation of the pre- and post-processing mean its forecasts can differ slightly from Google's official code. The 4-bit model differs more, especially on short series. Use the Run self-test vs PyTorch button to check on your own machine. - TimesFM 2.5 code and weights are licensed under Apache-2.0 and are provided "as is", without warranties or conditions of any kind. The changes made for this conversion are listed on the model card. TimesFM 3.0, which has a separate non-commercial licence, is not used or included. Not financial, investment or betting advice - The oil, Bitcoin and other price forecasts are educational demonstrations, not recommendations to buy, sell or hold anything. Prices behave much like a random walk, and in our own tests the model roughly ties a simple "no change" guess. - The World Series odds are an illustration of a forecasting method, not betting tips. They ignore starting pitchers, injuries and much else that matters. - Forecasts can be, and often are, wrong. Past accuracy doesn't guarantee future results. Don't make financial, betting, business, medical or policy decisions based on this site. Consult a qualified professional instead. About the data and the news signal - Data comes from third-party public sources: MLB Stats API, FRED (Federal Reserve Bank of St. Louis), IMF, World Bank, US Bureau of Labor Statistics, NOAA, SILSO / Royal Observatory of Belgium, Johns Hopkins CSSE and Google News. Each is subject to its own terms and is used here for non-commercial, educational purposes. - Data can be delayed, revised or incomplete. For example, official oil prices lag the market by about a week. It's refreshed automatically once a day, with no manual checking, and accuracy isn't guaranteed. - News headlines belong to their publishers and are linked, not copied in full. The news tone is scored automatically by a simple sentiment model (VADER). It can misread sarcasm, context or mixed stories, and it isn't an editorial judgement about any team, company or event. - Team and league names are trademarks of their respective owners. This project isn't affiliated with or endorsed by Major League Baseball or any team. Privacy - Forecasts run entirely in your browser. Numbers you paste or upload aren't sent to any server by this site. - Your browser does download files from third parties: the model from Hugging Face, and ONNX Runtime from the jsDelivr CDN. Those services may log the request, as any website does. Use at your own risk This is a free, open-source demonstration for learning and research. It's provided as is, with no warranty of any kind. The author isn't liable for any loss or damage arising from its use. Always verify important numbers with the original sources.
AI z GitHuba w płatnym bocie tradingowym? Sam otwarty kod nie wystarczy. TimesFM 3.0 ma kod Apache 2.0, ale komercyjne użycie pobranych wag wymaga osobnej licencji. Sprawdzaj licencję modelu, nie tylko kodu. Źródło: google-research/timesfm Telegram: t.me
Mistral's Timestral Runs on a CPU. Its 'Modified MIT' License Stops at $20M a Month - Book: System Design Pocket Guide: Fundamentals - Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go - My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools - Me: xgabriel.com | GitHub --- Mistral's new model doesn't write a single word. Timestral, released on October 15, 2026, reads a column of numbers and tells you where it is likely to go next, with a range around the guess. Mistral says its largest version, at 209M parameters, "ranks first on all three of the field's main public benchmarks," and that it "does not need a GPU at inference" (Mistral). If you run capacity planning, cost forecasts or anomaly alerts off a metrics table, that is a useful release. Then you open the license. The weights ship under what Mistral calls a Modified MIT license, and the modification is a revenue cap: if your company's global monthly revenue went past $20 million in the preceding month, you are not authorized to use it. What Mistral shipped on October 15 Timestral is a family of four time-series foundation models that share one architecture and training recipe (Mistral). "Foundation model" here means zero-shot: you hand it history and it forecasts, with no training on your data first. The GitHub README lists the checkpoints: | Model | Hub repo | fp32 weights | |---|---|---| | Timestral-5M | mistralai/Timestral-5M | 21 MB | | Timestral-28M | mistralai/Timestral-28M | 111 MB | | Timestral-123M | mistralai/Timestral-123M | 490 MB | | Timestral-209M | mistralai/Timestral-209M | 837 MB | The 209M model card gives the shape of the thing. It reads up to 32,768 past steps and forecasts up to 1,024 steps per forward pass. Every forecast is 21 quantiles, from 0.01 to 0.99, which gives each step a band of likely values. It takes one series or several at once, plus covariates that are either known only for the past or known into the future (holidays, planned promotions, a scheduled deploy). Missing values go in as NaN. On a server CPU with 8 threads, forecasting one day ahead from three weeks of 15-minute history, Mistral reports 10 ms for the 5M model and 140 ms for the 209M, with the 28M five times faster than the 209M (Mistral). Mistral's docs list Timestral 1.0 as a "Public Preview" and name no API price, so for now you download it and run it yourself. The benchmark claims, and who made them Every number below comes from Mistral. The model card says a tech report is "coming soon," and until it lands you can't check the method. On the card's comparison table, Timestral-209M scores a MASE of 0.658 on GIFT-Eval, against 0.661 for t0-gamma, 0.667 for TimesFM-3 and 0.698 for Chronos-2 (lower is better). On fev-bench's SQL skill score it posts 50.39, against 49.42 for t0-gamma and 47.28 for Chronos-2 (higher is better). It leads every row, but the margins over the runner-up are small (model card). The smaller models are the more interesting part for most teams. The 28M scores 0.678 on GIFT-Eval MASE and 0.638 on TIME MASE, both ahead of Chronos-2's 0.698 and 0.662, though behind t0-gamma and TimesFM-3 on GIFT-Eval and a hair behind t0-gamma's 0.637 on TIME (model card). Mistral describes Chronos-2 as about four times larger (Mistral). Mistral says the results come from a single checkpoint with no ensembling, submitted to the GIFT-Eval and TIME leaderboards, and that most training data is synthetic, so "nothing we backtest was seen during pre-training" (Mistral). That addresses leakage, the usual worry with forecasting benchmarks. The tech report still has to back it. !A small black CPU chip on a cream background, with a fan of burnt-orange forecast bands widening to the right out of a single line of history Timestral returns a band of 21 quantiles per step, and Mistral says it needs no GPU to do it. The "MIT" in Modified MIT The inference code is Apache 2.0. The weights are not. The README says they are "distributed separately on the Hugging Face Hub under a Modified MIT license," and that license is where the catch sits. The grant reads like MIT: use, copy, modify, merge, publish, distribute, sublicense and sell. Then the license file adds that you are "not authorized to exercise any rights under this license if the global consolidated monthly revenue of your company" (or your employer's) "exceeds $20 million (or its equivalent in another currency) for the preceding month." The restriction covers the model "and any derivatives, modifications, or combined works." Companies above the line can ask Mistral for a commercial license, which it may grant at its sole discretion, or use Mistral's hosted services. The 5M model's license carries the same $20 million cap, so a smaller checkpoint isn't a way around it. How that plays out, as I read it (I'm not a lawyer): 1. It is measured monthly. A company near the line can be inside the license one month and outside it the next. 2. It follows the weights into derivatives, modifications and combined works based on them, including a fine-tuned copy. 3. It counts your whole employer's revenue, however small your team's budget is. Mistral's announcement pitches Timestral for on-prem, VPC and air-gapped deployment (Mistral). Read that next to the cap. The large enterprises most likely to want air-gapped forecasting are often the ones above $20 million a month, so they need the commercial license. That's my reading of the two documents, not something Mistral has said. !An open gate in a black fence on a cream background, with a burnt-orange stack of coins rising like a turnstile bar across the opening The weights are free to use until your company's monthly revenue crosses $20 million. Try it on a week of traffic If you're under the line, trying it is short. The package isn't on PyPI. The README installs it from GitHub and asks for Python 3.10+ and torch 2.4+: pip install git+https://github.com/mistralai/timestral.git Here's a capacity-planning version of the README's quickstart. It takes hourly request counts and forecasts the next 168 hours with the 28M model: import numpy as np from timestral import TimestralForecaster # One value per line: requests per hour, oldest first. history = np.loadtxt("requests_per_hour.txt") model = TimestralForecaster.from_pretrained( "mistralai/Timestral-28M" ) week = model.forecast(history, prediction_length=168) p50 = week.median p90 = week.quantile(0.9) print("peak p50:", p50.max()) print("peak p90:", p90.max()) Size servers for the p90, not the median. Actual load lands above the median half the time. A few options from the README are worth knowing before you put this in a job. from_pretrained takes a revision argument, so pin a commit while the model is in public preview. local_files_only=True (or HF_HUB_OFFLINE=1) makes it read only from the local cache, which suits a locked-down box. Known future events go in known_covariates, shaped (B, C_known, T + prediction_length), and a row of only 0s and 1s is treated as an indicator, which is how you'd flag a launch day. Where it stops The README is direct about the limits. Context above 32,768 steps is cut, keeping the most recent. Horizons past 1,024 steps are forecast block by block, and "each block's median is fed back as context," so the far end of a long forecast is built on earlier guesses. Covariates condition the forecast and are never forecast themselves. The project doesn't accept pull requests; issues are handled "on a best-effort basis" (README). I haven't run Timestral myself, so I can't tell you how it does on your metrics. The fair test is cheap, though: backtest it on a month of your own history against whatever you use now, then check whether your company sits under the $20 million line before anyone builds on it. Would a revenue cap on "MIT" weights stop you from adopting a model at work, or does a free tier for smaller companies seem like a fair trade? Tell me in the comments. --- If this was useful Forecasting load is only half of capacity planning. The other half is knowing what to do with the number: where to cache, when to shard, how much headroom a p90 should buy you. The System Design Pocket Guide: Fundamentals covers those building blocks in a short, practical format. I also build Hermes IDE, a free, source-available IDE that runs Claude Code, Codex and other coding agents side by side, where each task can get its own branch and worktree, on macOS, Windows and Linux. Star it on GitHub if that sounds useful. 