你手上有 500 條商品的銷量歷史要預測未來三個月。依照傳統機器學習的思路，你得訓練 500 個模型——每個商品一個。資料清理 500 次、調參 500 次、上線部署 500 次。

Google Research 的 TimesFM 把這個數字劃掉，改寫成一個。

不管你有幾條時間序列，一個預訓練模型打遍天下。2024 年在 ICML 發表，論文出來一年多 GitHub 破了 12,000 顆星，Apache 2.0 授權。名字叫 Time Series Foundation Model——時間序列界的 GPT。

為什麼「預訓練 + zero-shot」在時間序列能成立

聽起來有點不合理。商品銷量的波動跟伺服器流量的波動看起來完全不一樣，怎麼可能一個模型通吃？

這也是論文出來時最被質疑的地方。但答案其實在「層級」這件事上。你看的是表面資料的不同，模型學到的是更底層的東西——上升、下降、週期、震盪、突變這些模式原型，跨領域都長一樣。把時間序列看成一種語言，那商品、氣溫、流量只是不同的「方言」，通用文法是共通的。

GPT 就是這個邏輯的先例。GPT 不是為每個問題重新訓練，它是在海量語料上學會「語言長什麼樣子」，然後面對新問題時套通用規律推答案。TimesFM 把同一招搬到時間序列——在大量序列資料上預訓練完，看到新資料直接推未來，中間不用你動任何 fine-tuning 的手。

架構：GPT 同源，細節不同

TimesFM 是 Decoder-only Transformer，核心跟 GPT 一樣。但為了吃時間序列的資料，改了幾個地方。

Patch-based 輸入。它不像 LSTM 一個時間點一個時間點吃，而是把時間序列切成長度 32 的 patch，一段一段餵。這招是從 Vision Transformer 學來的——ViT 把圖片切成 16×16 的小方塊，TimesFM 把序列切成 32 格的小段落。理由一樣：壓縮輸入長度、加快訓練。

Rotary Position Embeddings（RoPE）。處理序列位置資訊用。原版 Transformer 用絕對位置編碼，RoPE 的好處是能處理比訓練時更長的序列——這件事很重要，後面會看到為什麼。

RMS Normalization + Swish 激活函數。這兩個是訓練穩定性的標配。不用太放心上，知道就好。

版本演進：參數更少，效能更好

TimesFM 已經出到 v2.5，三代下來有個很反直覺的現象。

版本 參數量 Context 長度 亮點
1.0 200M 512 初版，只有點預測
2.0 500M 2,048 效能提升 25%
2.5（最新） 200M 16,384 更輕、context 擴 8 倍、連續分位數

看出哪裡怪了嗎？v2.5 的參數量反而比 v2.0 少了一半多，但效能更好、context 還拉到 16K。

這在 LLM 圈會被叫做「模型效率的第二曲線」——當你發現規模不是萬能解，開始回頭搞架構優化和資料品質。GPT-3 到 GPT-4 是堆規模，再往後很多改進靠的是架構細節、資料選擇、訓練技巧。TimesFM 2.5 就走了這條路。Context 從 2K 拉到 16K 意味著：你可以餵進更長的歷史——兩年每日資料 730 個點，現在綽綽有餘。

用起來長這樣

裝起來一般流程：clone repo、建虛擬環境、選 PyTorch 或 JAX/Flax backend。

1
2
3
4
git clone https://github.com/google-research/timesfm.git
cd timesfm
uv venv && source .venv/bin/activate
uv pip install -e .[torch]     # 或 .[flax]

然後一段範例就跑起來：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
import torch
import numpy as np
import timesfm

torch.set_float32_matmul_precision("high")

# 從 HuggingFace 載入預訓練模型
model = timesfm.TimesFM_2p5_200M_torch.from_pretrained(
    "google/timesfm-2.5-200m-pytorch"
)

# 編譯預測配置
model.compile(
    timesfm.ForecastConfig(
        max_context=1024,                    # 最多吃多長歷史
        max_horizon=256,                     # 最多預測多遠
        normalize_inputs=True,               # 自動正規化
        use_continuous_quantile_head=True,   # 啟用分位數預測
        force_flip_invariance=True,
    )
)

# 丟兩條序列進去，各預測未來 12 步
point_forecast, quantile_forecast = model.forecast(
    horizon=12,
    inputs=[
        np.linspace(0, 1, 100),              # 第一條：線性上升
        np.sin(np.linspace(0, 20, 67)),      # 第二條：正弦波
    ],
)
# point_forecast.shape    → (2, 12)      兩條序列各 12 步預測
# quantile_forecast.shape → (2, 12, 10)  含 9 個分位數的不確定性

注意三件事。

第一，沒有訓練這件事。整段 code 找不到 model.fit() 或 loss.backward()。載入、配置、預測——結束。

第二，max_context 跟 max_horizon 有對齊限制。分別要是 32 跟 128 的倍數。違反會直接炸。

第三，use_continuous_quantile_head=True 打開了這篇後面要講的重點功能。沒有這一行你只會拿到點預測。

分位數預測：不告訴你答案是多少，告訴你範圍

傳統模型跟你說「下週銷量會是 100」。TimesFM 跟你說「中位數是 100，但 80% 機率落在 60 到 140 之間」。

後者多了一個東西：不確定性的範圍。這不是花俏的裝飾，是真正值錢的資訊。

想像你在做庫存決策。模型說「預測銷量 100」，你備 100 貨。結果實際 140——缺貨了。你備 120 好了？結果實際 60——積壓。問題不在模型預測得準不準，問題在你沒有風險預算。

分位數預測把這件事變可操作。看到 80% 信心區間是 60-140，你就知道：如果要確保不缺貨（保守做法），備到 140（90th 分位數）；如果要壓庫存成本，備到中位數 100 然後接受可能缺貨。決策從猜答案變成選立場。

同樣的邏輯搬到異常偵測。實際值超出 10th-90th 分位數範圍，就觸發告警——不用手動設閾值，模型自己告訴你「這個範圍內算正常」。伺服器回應時間、交易流量、溫度感測器，都能這樣監控。

XReg：把外部因素塞進去

光看歷史不夠。雙十一銷量不只跟上週銷量有關，也跟「今天是不是雙十一」有關。TimesFM 2.5 支援兩種共變量。

靜態共變量：不隨時間變的。商品類別、門市地點、是否為連鎖品牌。

動態共變量：隨時間變的。溫度、降雨、是否假日、促銷力度。

用 forecast_with_covariates() 把這些資訊帶進去，預測準度會再上一階。實務上能打到多精準，取決於你的共變量有沒有真的跟目標相關——放進去一堆但沒訊號的特徵只會搞亂模型。

什麼時候該用 TimesFM、什麼時候不要

這裡是最多人踩坑的地方。基礎模型不是銀彈。

該用：

  • 你有大量（幾十到上萬條）時間序列，每條專屬歷史資料都不多
  • 需要快速上線，沒時間為每個序列單獨調參
  • 需要不確定性區間做風控或異常偵測
  • 想用共變量但不想從零設計 feature engineering pipeline

不該用：

  • 你只有一條時間序列，而且累積了很多年的專屬資料。這時候傳統 ARIMA 或專用 LSTM 往往還是贏——基礎模型的優勢在「通用 + zero-shot」，你不需要通用時就沒優勢
  • 你的序列極度不規則（密度變化大、缺值多、非平穩），TimesFM 的 patch-based 假設會失靈
  • 你的預測週期需求超過 v2.5 的 connective quantile head 限制（horizon > 1,024）
  • 你的 infra 連 32GB RAM 都生不出來

要注意的限制

這不是 Google 官方產品。開源版不走 Google Cloud 的 SLA，Google 官方整合在 BigQuery ML 裡——想吃原廠支援用那邊。

記憶體需求高。載入 200M 參數模型、做推論，建議至少 32GB RAM。GPU 不是必要但強烈建議，CPU 推論的速度只能算勉強可用。

核心是單變量模型。它一次預測一條時間序列，要多變量就靠 XReg 共變量那一套，不是 native 的多變量預測。

v2.5 API 跟 v1 不相容。如果你本來用 v1.3.0 的 pip 版本，升級要改 code。

這件事背後更大的變化

TimesFM 值得注意的不只是它本身，是它代表的方向。

預訓練基礎模型這條路，原本只在語言（LLM）跟圖像（ViT）成立。大家一直假設時間序列太「特殊」——每個領域規律不同、資料量不夠、訊號太雜——不能走這條。TimesFM 加上差不多時期的 Lag-Llama、Moirai、Chronos，證明了這個假設錯了。

實務上的意義是：預測這件事的起點改變了。以前的起點是「蒐集序列歷史 → 訓練專用模型」。現在的起點是「載入基礎模型 → 看它有沒有幫我解決 80% 的問題 → 剩下 20% 再做客製化」。對大部分場景，80% 就夠了。

這跟當年 ResNet 預訓練權重改變電腦視覺、ImageNet 預訓練改變下游任務，是同一個故事的下一集。如果你的工作跟時間序列預測有關——零售、能源、監控、金融——現在開始學 TimesFM 不是超前部署，是補課。

原文來源：google-research/timesfm · GitHub
論文：A decoder-only foundation model for time-series forecasting (arXiv:2310.10688)
HuggingFace：google/timesfm-2.5-200m-pytorch