TimesFM 3 值得拿來當多變量時間序列的零樣本 baseline，但現在不適合直接接進商業正式環境。 Google 已公開程式碼與 3.0 權重，可共同預測多條相關序列，也能納入促銷、假日或天氣預報等變數；不過 3.0 權重明確限制為非商業、非 production 使用，BigQuery 也尚未提供這一版。
這代表資料團隊可以先用歷史庫存、需求、流量或設備感測資料做 PoC，確認它是否贏過 seasonal naive、ARIMA 與現行模型。若結果將直接用於採購、排班、定價、交易或客戶交付，先不要把 Hugging Face 權重上線，應等待可用的商業授權或受管服務條款。
TimesFM 3 和 2.5 差在哪？
| 比較項目 | TimesFM 2.5 | TimesFM 3 |
|---|---|---|
| 主要輸入 | 單條序列為主，另有 XReg covariate 流程 | 原生多目標與多變量輸入 |
| 參數量 | 2 億 | 3.3 億 |
| 預測方式 | 逐 patch 生成 | 一次 forward pass 產出完整 horizon |
| 開放權重 | Apache-2.0 | 非商業、非正式環境授權 |
| BigQuery | AI.FORECAST 已支援 | 官方稱之後整合，目前尚未支援 |
Google Research 公告指出，TimesFM 3 用超過一兆個真實與合成 time points 預訓練，能同時輸出多個目標的 point forecast 與 quantile forecast。它把連續資料切成長度 32 的 patches，交替處理時間方向與不同變數之間的關係，再一次預測完整 horizon，避免前代逐段生成造成的延遲與誤差累積。
這裡的「零樣本」只表示不必先用你的資料微調，不代表模型知道公司促銷規則、台灣連假、停機或缺貨。資料語意、粒度、異常值與未來事件仍要由團隊整理；想先補資料前處理，可看 AI 資料清理流程。
三類資料要怎麼放？
TimesFM 3 把輸入分成三類。第一類是 targets，例如各門市每日銷量；第二類是 past-only covariates，例如已發生的人流或設備溫度；第三類是 past-and-future covariates，例如已排定促銷、已知假日與在預測當下已發布的天氣預報。多條序列必須使用相同時間粒度並對齊，缺值與重複時間戳要先處理。
最危險的是把「事後才知道」的資料偽裝成 future covariate。實際天氣、最終成交價、活動後曝光或月底修正庫存，在預測當下都不存在；若回測時直接餵給模型，就會形成 future leakage。正確做法是保存當時真正可取得的預報或計畫版本，沒有版本資料時，就只把該欄位當歷史變數。
官方 Hugging Face model card列出的架構是 20 層、model dimension 1280、16 個 heads，模型約 3.3 億參數。它會輸出中位數與多個 quantiles，但區間寬度仍需在自己的資料上做 coverage 檢查；「提供機率預測」不等於 90% 區間在你的場景真的覆蓋 90% 實際值。
最小 PoC 怎麼跑？
Google Research GitHub目前建議從 repository 安裝新版程式碼，因為 PyPI 的穩定套件仍以舊版流程為主。研究環境可建立隔離虛擬環境，再載入 gated Hugging Face checkpoint：
git clone https://github.com/google-research/timesfm.git
cd timesfm
uv venv
uv pip install -e ".[torch]"import numpy as np
from timesfm3 import ModelConfig, TimesFM3Evaluator
history, horizon = 56, 7
days = np.arange(history + horizon)
weekly = np.sin(2 * np.pi * days / 7).astype(np.float32)
rng = np.random.default_rng(7)
# Synthetic research data, not real store records.
all_targets = np.stack([
80 + 12 * weekly + rng.normal(0, 2, len(days)),
50 + 8 * weekly + rng.normal(0, 2, len(days)),
]).astype(np.float32)
context = all_targets[:, :history]
actual = all_targets[:, history:]
known_calendar = weekly[None, :]
config = ModelConfig(
checkpoint_path="google/timesfm-3.0-pytorch",
per_core_batch_size=1,
device="cuda",
)
forecaster = TimesFM3Evaluator(config)
result = list(forecaster.predict_batch(
contexts=[context],
horizon=horizon,
past_future_covariates=[known_calendar],
return_quantiles=True,
use_symmetric_averaging=False,
))[0]
prediction = np.asarray(result.forecast)
quantiles = np.asarray(result.quantiles)
assert prediction.shape == (2, 7)
assert quantiles.shape == (2, 7, 9)
assert np.isfinite(prediction).all()
naive = context[:, -horizon:]
print("Forecast by store:", prediction)
print("TimesFM MAE:", np.mean(np.abs(prediction - actual), axis=1))
print("Seasonal naive MAE:", np.mean(np.abs(naive - actual), axis=1))這個示例依官方多變量呼叫介面整理，使用自行生成的研究資料，沒有真實門市紀錄，也沒有在本文假報模型跑分。執行前須有相容的 PyTorch／CUDA 環境、完成權重所需的存取與授權程序；本文沒有下載權重完成推論，因此不提供假造的預測輸出或執行速度。沒有 CUDA 的環境不能原封不動使用這段設定，應依官方支援的後端另行配置。
陣列對應要先看懂：兩間假設門市各有 56 天歷史，所以 context 是 (2, 56)；往後預測 7 天，答案應是 (2, 7)。已知的每週週期是我們事先定義的日曆變數，包含過去與未來共 63 天，因此 known_calendar 是 (1, 63)。actual 雖為回測預先保留的真值，卻沒有送進模型；若誤把完整 all_targets 當成歷史輸入，評估就失去意義。
每個步驟先確認形狀與有限數值，再看誤差。載入權重失敗時應處理環境、存取與版本；形狀錯誤時先查批次、門市與日期維度，不要先改模型大小。上述呼叫把兩個門市放在同一個多變量案例，並非分別做兩次單變量預測。
跑出一排數字後，如何判斷有沒有幫助？
這個例子的季節性基準直接拿上一週同一天的數值當預測，因此 context[:, -7:] 與未來 7 天一一對應。平均絕對誤差（MAE）是每一天預測和實際值差多少，再取平均；程式按門市分開計算，避免大店的結果掩蓋小店退步。
假設某次示意結果是 A 店的基準 MAE 為 5、TimesFM 為 3，B 店卻由 2 變成 4，結論不能寫成「新模型全面更準」。你要回頭查 B 店的缺貨、資料粒度與週期是否不同；這組 5、3、2、4 只用來解釋判讀，並非上面程式的實際輸出。
量化區間同樣要核對。若用第 10 與第 90 百分位作上下界，兩端合起來是名義上 80% 的區間，不是 90%。應在多個歷史切分點檢查真值落入區間的比例，還要看區間是否寬到無法幫忙決策。只預測一次、剛好落在區間內，不能證明校準良好。
門市真實資料還有一個陷阱：賣出數量不一定等於需求。當天缺貨，低銷量可能來自供給受限；把它當成需求下降，可能得到越補越少的建議。先把零銷量、停業、缺貨與漏登分開標記，再決定模型要預測的是銷量、需求還是庫存。這比直接把一列數字丟給新模型更重要。
這個小例子用來走通資料到結果的流程；它沒有證明正式準確率，也沒有解除權重的非商業限制。進一步驗證應改用經授權的資料與多個歷史切分點，相關步驟見後面的回測段落。
如果只想在 SQL 裡測單變量預測，BigQuery AI.FORECAST 文件目前支援 TimesFM 2.0 與 2.5，預設為 2.5。這條路不需要自行管理權重，但不是 TimesFM 3 多變量能力；Google 公告只說 3.0 整合會在後續推出，尚未給確切日期。
Benchmark 第一名該怎麼驗證？
Google 宣稱 TimesFM 3 在 GIFT-Eval、FEV-Bench 與 TIME 的 point、probabilistic 指標排名領先。這些結果有公開 benchmark 脈絡，FEV evaluation library也提供資料與模型提交流程，但目前圖表仍由模型開發團隊發布，還不能當成你的銷量、財務或設備資料也會第一名。
驗收時不要隨機切 train／test。應建立多個依時間前進的 cutoff：每個 cutoff 只能看到當時以前的 target、covariates 與資料修訂版本，再預測相同 horizon。至少比較 seasonal naive、現行 production 模型和 TimesFM 3，分開計算各門市、各品類或各設備的 MAE／WAPE、區間 coverage、推論時間與失敗率。
我的判斷很直接：研究、教學與內部非商業 benchmark 可以現在試；商業團隊先用它判斷「多變量 foundation model 是否值得投資」，不要直接讓輸出決定庫存或資金。若連 seasonal naive 都沒有穩定贏過，就不值得只因模型較新而增加 GPU、授權與維運成本。時間序列也不一定要交給文字模型；可搭配時間序列圖像與 VLM 研究理解「預測」和「異常判讀」其實是兩種任務。
常見問題
TimesFM 3 可以免費商用嗎？
目前不行。程式碼採 Apache-2.0，但 3.0 預訓練權重採 TimesFM Non-Commercial License v1.0，限制非商業與非正式環境使用；完整授權文字還明確排除商業決策、客戶交付與營收活動。
TimesFM 3 能預測股票漲跌嗎？
它可以對數值序列產生預測，不代表能創造可交易優勢。股價受制度變化、新聞與市場反應影響，零樣本誤差指標也不能替代含交易成本的 walk-forward 測試；不建議把模型輸出直接當買賣訊號。
BigQuery AI.FORECAST 已經是 TimesFM 3 嗎？
截至 2026 年 9 月 2 日不是。文件列出的支援版本是 TimesFM 2.0 與 2.5，預設為 2.5；Google 只表示 TimesFM 3 整合將在後續推出。
多變量預測一定比單變量準嗎？
不一定。相關序列或未來事件若穩定且在預測當下可取得，可能改善結果；噪音、錯位或資料洩漏則可能讓表面分數更好、正式表現更差。兩種模式要用相同 rolling-origin cutoff 公平比較。
參考來源
- Google Research：TimesFM-3: A zero-shot foundation model for multivariate forecasting（2026-08-31）
- Google Research GitHub：TimesFM（2026-09-02 查閱）
- Hugging Face Google：TimesFM 3.0 (PyTorch)（2026-09-02 查閱）
- Hugging Face Google：TimesFM Non-Commercial License v1.0（2026-09-02 查閱）
- Google Cloud Documentation：The AI.FORECAST function（2026-07-31）
- AutoGluon GitHub：fev - Forecast evaluation library（2026-09-02 查閱）