TOPIC COLLECTION
Mistral Timestral是什么？2亿参数的时间序列预测模型，CPU就能跑，谁用得上
Mistral于2026-10-15发布首个时间序列基础模型家族Timestral，含5M、28M、123M、209M四个尺寸，支持多变量、概率预测（21个分位数）以及过去与已知未来协变量，上下文32768个时间步，许可证为修改版MIT。官方称209M版在GIFT-Eval、TIME、fev-bench三个榜单排第一，8线程CPU上单次预测10–140毫秒。
资料更新：2026-10-19
依据Mistral官网《Introducing Timestral》（2026-10-15）及其GitHub仓库、Hugging Face模型页。榜单排名与延迟数字为Mistral自述，技术报告尚未发布；本站未在自有数据上复现。核查2026-10-19（新加坡时间）。
主题标签：Mistral Timestral、时间序列预测、开源模型、需求预测、设备监控
Mistral不是做聊天大模型的吗，怎么出了个预测模型？2026-10-15，Mistral AI发布了Timestral，它第一个时间序列基础模型家族。它不聊天，也不写代码，只干一件事：给一串按时间排好的数字，预测接下来会怎样。
听起来冷门，其实离很多人的工作很近。电商备货、门店客流、服务器CPU、工厂传感器、电费负荷，底下都是时间序列。
基本规格
| 项目 | Timestral |
|---|---|
| 尺寸 | 5M、28M、123M、209M参数 |
| 上下文长度 | 32,768个时间步 |
| 输出 | 概率预测，21个分位数 |
| 输入 | 多变量目标序列，过去协变量，已知未来协变量，类别型协变量 |
| 部署 | 本地、VPC、物理隔离环境 |
| 许可证 | 修改版MIT（商用前请读仓库里的具体条款） |
| 获取方式 | GitHub仓库mistralai/timestral，权重在Hugging Face |
| 微调 | 通过Mistral Forge |
「基础模型」对预测意味着什么
做过预测的人都用过ARIMA、线性回归、Prophet这类方法。它们的共同点是：一条序列训练一个模型，只从这条序列自己的历史里学。新开一家门店、上一个新SKU，历史太短，模型基本没法用。
后来的深度学习方法（比如PatchTST）能跨多条序列学非线性规律，但通常还是每个数据集从头训练，换个行业又得重来。
时间序列基础模型借的是大语言模型那套思路：先在海量、多样的序列上预训练，学到能迁移的规律，再对没见过的数据直接做零样本预测。Timestral就是这一类。同类产品还有亚马逊的Chronos、谷歌的TimesFM，Mistral这次点名比的就是Chronos-2和TimesFM-3。
官方给的成绩，怎么看
Mistral的说法是：209M版在GIFT-Eval、TIME、fev-bench三个主流公开榜单的五项指标上，在预训练零样本模型里都排第一，而且是单个checkpoint、没有做集成；28M版在GIFT-Eval和TIME上就胜过了大约四倍体积的Chronos-2。
这些是厂商自述，技术报告还没发，结果已提交到GIFT-Eval和TIME榜单等待收录。我的看法是：榜单可以当入场券，但你的业务数据很可能和榜单数据分布差很远，节假日、促销、断货这些因素，公开数据集里覆盖得并不好。
为什么「CPU能跑」是重点
官方给了一组很具体的数字：在8线程的普通服务器CPU上，用三周的15分钟粒度历史数据预测未来一天，5M模型约10毫秒，209M模型约140毫秒。28M比209M快约5倍；123M的分数和209M只差0.2%，延迟是它的四分之三。
这对落地很关键。很多公司的监控和报表系统跑在没有GPU的机器上，几千条传感器序列每15分钟要刷新一次。如果每次预测都得调GPU，成本和运维复杂度都上去了。CPU上百毫秒级，意味着可以直接塞进现有的Prometheus、Grafana这类监控链路旁边跑。
尺寸怎么挑，可以这样粗分：
| 场景 | 建议先试 |
|---|---|
| 边缘设备、成千上万条序列高频刷新 | 5M或28M |
| 日常业务预测，要平衡精度和速度 | 123M |
| 预测频率低、精度优先（月度需求、容量规划） | 209M |
协变量这块，比旧方法省事
Timestral把每条输入序列分成三种角色：要预测的目标、只有过去值的协变量、未来值已知的协变量。
举个电商例子。要预测的是某SKU每日销量；过去协变量可以是历史广告花费；已知未来协变量是促销日历、节假日、天气预报。模型能看到未来的促销安排，但不会偷看销量本身的未来值，官方说他们在注意力机制上专门做了这层隔离。
类别型输入也直接支持，比如星期几、设备状态（运行/空闲/检修）。以前要手动做独热编码，现在原样喂进去就行。
输出是21个分位数，不只是一个点预测。实际意义是你能拿到区间：备货按P90、报警阈值按P95，比单一数字更好做决策。
普通数据分析师怎么上手
1. 到GitHub仓库mistralai/timestral，按README装环境、下载权重。需要GPU吗？推理不需要。
2. 准备一份你熟悉的数据，最好是已经有人工或旧模型预测结果的，这样有对照。在Jupyter或Google Colab里跑都行。
3. 留出最近一段时间做回测，比较Timestral零样本结果、你现有方法、以及「去年同期」这种朴素基线。朴素基线很重要，很多花哨模型其实打不过它。
4. 把协变量加进去再跑一次，看提升多少。没有提升，说明协变量没选对，或者数据本身噪声太大。
5. 想要更贴合行业，再考虑Mistral Forge微调。官方说支持在私有数据上微调、调整训练数据配比、生成贴近目标领域的合成数据，全流程可以部署在客户自己的硬件上。
手里没有现成数据练手的，Kaggle上有不少零售、能源的公开时间序列竞赛数据。
它不能替你做的事
它是数值模型，不懂业务语境。突发事件（疫情、断供、政策）它预测不了，只能事后从数据里看到。官方自己的设想是把Timestral当监控里的异常检测器，发现异常后再交给语言模型智能体去查维修记录、班次日志，给出诊断草稿。这个链路需要你自己搭，不是开箱即有。
另外，许可证是「修改版MIT」，不是标准MIT。商用、尤其是要嵌进对外售卖的产品里，先让法务读一遍仓库里的LICENSE。
想在本地跑其他开源模型，可以对照看Ollama和站内模型社区分类；Mistral的语言模型API在Mistral Console。
和Chronos、TimesFM放一起怎么看
三家的路线很像：都是预训练好的通用预测模型，都主打零样本。差别主要在体积和部署友好度。Mistral这次的卖点是「同等精度下更小」，以及从一开始就支持本地、VPC和物理隔离部署，这对制造业、金融这类数据不能出内网的客户比较有吸引力。
如果你已经在用某一家，没必要马上换。拿同一份回测数据把三家都跑一遍，看在你自己的业务上谁赢，比看榜单可靠。
来源与核查日期
- Mistral：Introducing Timestral（2026-10-15）
- GitHub：mistralai/timestral
- Hugging Face：mistralai/Timestral-209M
核查日期：2026-10-19（新加坡时间）。榜单与延迟数据为官方自述，技术报告待发布。
