Timestral 上架开放权重货架：209M 跑在 CPU 上的时序预测模型，聚合层要开新类目

这次上架的不只是又一个模型，是一个新类目

过去两年，模型货架的基本盘是语言与多模态：按百万 tokens 计价、比价、跑路由。Mistral 这次把首个时序基础模型家族 Timestral 以开放权重放出，货架上出现了一个没有 tokens 可计量的新类目——时间序列预测。家族四档 5M、28M、123M、209M 参数，权重 fp32 分别只有 21MB、111MB、490MB、837MB（GitHub 仓库与 HuggingFace 模型卡交叉一致），上下文支持 32768 个时间步，单次前向最多预测 1024 步，每步输出 21 个分位数（0.01 到 0.99），支持多变量目标与 past-only、known-future、类别协变量。

CPU 上 140ms，把推理成本拉到 CPU 行项

Mistral 在 8 线程服务器 CPU 上测出：从 3 周 15 分钟间隔的历史数据预测 1 天，5M 档 10ms、209M 档 140ms（厂商自报，媒体交叉转述）。对 API 聚合层，这意味着时序预测通道的成本结构跟语言模型完全不同：不用占 GPU 配额，推理成本接近一条 CPU 行项，货架上的计价单位也得换——按预测任务次数或按占用算力时长收，套「每百万 tokens」反而失真。123M 档更值得采购方盯：GIFT-Eval MASE 0.659，只比 209M 的 0.658 差 0.001，模型体积与推理耗时都小一圈。

许可差异是准入门槛，别只看跑分

对照同赛道：谷歌 TimesFM-3（330M）走非商用许可，商用转售要逐例评估；Timestral 权重是 Modified MIT（代码 Apache 2.0），商用货架直接可放。榜单侧，209M 在 GIFT-Eval（MASE 0.658，领先 t0-gamma 的 0.661 仅 0.003）、TIME（MASE 0.626）、fev-bench（SQL 50.39，高于 TimesFM-3 的 48.99）三项中，零样本、单检查点、无集成前提下排预训练模型第一——这些数字是 Mistral 自测并提交榜单，属厂商自报，落地前建议用自己的业务序列复测。

选型账：先 28M 试水，123M 做主力

Mistral 团队称 28M 档在 GIFT-Eval 与 TIME 上超过约四倍体积的 Chronos-2（厂商自报，单源，复测后再信），这给低成本场景留了口子：把 28M 挂在边缘或低配实例上跑全量序列的例行预测，异常序列再升级到 123M/209M。按单任务 140ms 估算（推算值，非官方数据），单核 CPU 每小时可消化约 2.5 万次预测任务，跟「语言模型加工具链」路线动辄每任务数万 tokens 的开销不是一个量级——高频、低时延、强周期性的时序场景，专用模型就是该走专用通道。

API 通道的现状：Preview 加 Forge 微调

Mistral 文档把 Timestral 1.0 209M 列为 Public Preview，私有数据微调走 Mistral Forge 流水线，支持本地、VPC 与气隙部署（厂商自报）。聚合层能做的有三步：先把开放权重托管成标准端点；对高频时序客户（需求预测、异常检测、容量规划）开 Forge 微调档；等 Preview 转正后把价格锚定写进路由表。

上架前三行清单

第一行计价：给时序类目定义计价单位——按预测任务数、还是按千次任务包，分位数输出按步计费还是整单计费，写进价目表备注。第二行验收：把语言模型那套跑分换成 MASE/CRPS，内部建一个至少 20 条业务序列的回归集（含缺失值、突变、季节项），基线拿 ARIMA 与自训练模型对照，验收线才立得住。第三行许可：模型卡加「商用转售」栏，Timestral 走 Modified MIT 可进商业通道，同货架上的非商用权重单独隔离，别混进对客路由。数据侧也省心：输入原生标 NaN 表示缺失，每个预测块用前序中位数统计量去标准化，真实运营里带缺失的脏数据不阻塞接入。

观察：语言模型货架卷到按 tokens 比价已经卷了两年，时序这条线才刚开柜——类目、计价单位、验收基准（MASE/CRPS 而非跑分榜）三样都还是空的，先占位的人定义规则。

来源：Mistral 官方博客与 GitHub（mistralai/timestral）、HuggingFace 模型卡、MarkTechPost（10/18）。「三项基准零样本第一」「CPU 10-140ms」「Public Preview」为厂商自报/自测；规格与许可证经 GitHub、HuggingFace、第三方媒体交叉核对。