Timestral 是 Mistral 新公開的時間序列模型，從按時間排列的歷史數值推估未來。 10 月 15 日發布的家族有四種大小。我們在 Windows 的 CPU 環境實際跑了最小 5M 版，拿到未來一週的中位數與不同分位數，確認沒有 GPU 也能完成這個小型範例。
對台灣沒有獨立顯卡的分析師或營運團隊，這多了一條把數值預測留在本機執行的路。不過，我不建議拿到預測值就直接接上補貨：這次測的是合成資料能否跑通，真實需求還要和既有方法回測，企業使用也要看權重授權。
最小版已在 CPU 跑通，輸出的是一組預測分布
Timestral 家族的標稱參數量為 5M、28M、123M、209M。官方程式庫可在 CPU 或 GPU 推論，輸入多條相關序列，也能加入只知道過去、或事先已知未來的變數；程式與權重都已可取得，輸出的數值能接回既有資料流程。
我們下載官方 5M 權重，固定版本，在隔離的 Python 環境以 CPU 執行。測試資料有 84 個歷史點，將每點視為一天，由緩慢上升趨勢加上每週起伏生成；它不是任何真實店家的銷量，也沒有用來先訓練或微調模型。
使用下載後的本機模型目錄，這次的合成資料與核心呼叫如下：
import numpy as np
from timestral import TimestralForecaster
t = np.arange(84, dtype=np.float32)
history = (80 + 0.2*t + 12*np.sin(2*np.pi*t/7)).astype(np.float32)
model = TimestralForecaster.from_pretrained("model", device="cpu")
forecast = model.forecast(history, prediction_length=7)
median = forecast.median程式成功產出七步預測，每步有二十一個分位數，所有輸出都是有限數值，分位數順序也沒有交錯。下面節錄前三天，四捨五入到小數第二位；數值沒有實際商品單位：
| 預測日 | 10% 分位 | 中位數 | 90% 分位 |
|---|---|---|---|
| 第一天 | 95.10 | 95.79 | 96.42 |
| 第二天 | 105.19 | 105.98 | 106.83 |
| 第三天 | 107.96 | 108.83 | 109.90 |
中位數位在模型估計分布的中央，另外兩欄是偏低、偏高位置的估計。表格確認了最小權重能在這個 CPU 環境回傳預期格式；是否預測準、偏高偏低的範圍是否可靠，要留給真實需求資料回測，這次沒有測量。
台灣補貨場景，要把已知未來與事後資料分開
假設團隊想預測門市每日需求，已排定的促銷可以作為事先知道的資訊；活動結束後才結算的人流或最終銷量，就不能倒填回預測當下。Timestral 支援未來變數，不代表模型能替你判斷哪個欄位當時真的存在。
我會先把資料整理成固定時間粒度，再用多個過去切點，各自預測後面一段需求，和「沿用上週同日」及現行系統比較。這符合時間序列交叉驗證的原則：每次只能使用當時以前已知的資料，而不是打亂順序分訓練、測試集。補貨還要分別看缺貨與過量的代價，不能只挑一張好看的預測圖。
授權也有一道不能略過的門檻。這次下載的 5M 權重原文要求保留歸屬及許可聲明；若公司或雇主前一月的全球合併月營收超過 2,000 萬美元，就不能依這份授權行使使用等權利，需另洽商業授權。原始碼的 Apache-2.0，不能拿來取代權重的修改版 MIT 條件。
我的判斷是，Timestral 值得讓已有歷史數據、但沒有 GPU 的小團隊多做一次本機比較。先確認授權與資料可用，再看它是否真的降低你在意的需求誤差；模型小、跑得動，只解決了開始嘗試的一部分成本。
資料整理可接著看時間欄位與缺值清理，門市端的任務則有 AI 零售與 POS 應用可承接。若你已在研究其他時間序列模型，可對照站內的 TimesFM 3 指南；它是另一個模型家族，安裝與權重條款應各自核對。
常見問題
Timestral 一定要 GPU 才能跑嗎？
不一定。官方支援 CPU，本站也在 Windows 的 CPU 環境跑通最小 5M 版。這不代表各種模型大小、序列長度或批次都具有相同速度與記憶體需求。
這次的預測表能證明實際銷量會預測準嗎？
不能。表格是合成週期數列的實際模型輸出，只確認推論可執行、格式正常。真實門市準確率與分位數覆蓋率仍需用歷史切點回測，並與既有方法比較。
修改版 MIT 代表任何公司都能直接商用嗎？
不能這樣理解。這次下載的 5M 權重要求保留聲明，且公司或雇主前一月全球合併月營收超過 2,000 萬美元時，不能依此授權使用，應另洽商業授權；原始碼的 Apache-2.0 不涵蓋權重。