Kronos与FaceCat-Kronos：时间序列基础模型在金融量化预测中的应用实践

简介：FaceCat-Kronos是一套结合清华大学Kronos框架与深度学习技术的金融量化预测工具包，面向做市商与短线交易者，用于通过历史行情预训练捕捉价格形态规律，优化交易策略。包内共50个文件，压缩包约19.71MB，包含23个Python脚本（预测示例、训练器与数据预处理代码）、模型权重目录、dll动态库、K线图/回测界面等10张png截图、json配置、csv历史数据（如XSHG_5min_600977.csv）、README与license说明，目录按模型、示例、微调、工具等模块组织，便于对照学习和二次开发。已有519人学习下载。通过源码可了解Kronos模型在时序预测中的具体实现，掌握从数据预训练到预测推理的完整流程，并借助自带界面文件快速搭建可视化回测环境，是一份适合具备一定Python与机器学习基础者深入研究的实战参考。

1. 为什么金融量化预测需要Kronos这种人工智能基础模型

手工特征加LightGBM的量化策略，最近两年越来越像玄学：特征调了十几版，回测曲线漂亮，实盘一上就不对味。Kronos是清华大学开源的时间序列预测基础模型，FaceCat-Kronos则是把Kronos接进金融数据流的一套工具。它做的事情很直接：吃进历史行情和因子，用预训练模型预测未来价格，再转成可回测的交易信号。很多人说人工智能正从尝鲜工具变成日常帮手，在量化这个最吃数据的领域，这句话落地得最快。这套方案的重点不是预测百分百准，而是把“大模型做时序预测”这件事变成可复现、可回测、可上线的工程流程。适合那些已经不想从头训Transformer，又需要快速验证AI预测能不能用在策略里的投研开发者和量化研究人员。

2. 先看懂Kronos：这个框架凭什么敢做金融预测

2.1 Kronos的预训练思路：把K线当成时间序列patch

Kronos是清华大学开源的时间序列基础模型家族。它的核心思路和NLP里的预训练模型如出一辙：先在大量非金融的时间序列上做自监督预训练，再把学到的序列规律迁移到目标领域。这里有一个重要认知：金融K线本质上是“带噪声的时间序列”，它不特殊。趋势、周期、突变、水平回归这些结构，在电力负荷、交通流量、气象数据里也反复出现。Kronos之所以能用于金融预测，不是因为它见过多少张K线图，而是因为它见过足够多不同形态的序列，能对“下一步可能怎么走”给出一个合理的先验分布。

具体到结构，常见实现会把连续序列切成长度相同的patch。每一个patch相当于一个token，再叠加时间戳和频率编码，扔进Transformer编码器。这样有两个好处：一是patch结构让模型更关注局部形态而不是单点噪声；二是把长度不定的历史序列统一成固定token序列，方便预训练和迁移。默认配置里常见patch_size=32、输入长度512、预测长度96。这张默认表不是随便定的。patch太大，K线里的关键转折点会被抹平；patch太小，模型容易过拟合噪声。对小时级和日级数据，32步patch是比较平衡的选择。

这里有一个常见误解：以为Kronos输出的是未来价格曲线，所以直接用预测价格做信号就行。但实际输出通常是未来多个patch的分布参数，而不是一条确定的线。FaceCat-Kronos在包装模型时，会把预测转成未来收益的采样路径，再给出不同分位数。分位数比均值重要得多。量化策略不怕预测错，怕的是模型不知道自己会错。Kronos能输出预测区间，意味着你可以拿这个区间控制仓位，而不是下注在单一点上。

2.2 FaceCat-Kronos的模块划分：数据、模型、信号三层

FaceCat-Kronos不是为了跑模型而做的demo，它是一个准备落地的量化预测工具。从常见封装习惯来看，整个工具大概可以拆成三层。

第一层是数据层，负责把CSV里的OHLCV或者外部因子数据统一成固定频率的序列，处理缺失值、时区、停牌。第二层是模型层，加载Kronos权重，对输入序列做预测，并输出预测分布。第三层是信号层，把预测分布转成策略信号，比如阈值、买卖方向、仓位，再送进回测引擎。

这三层分开的好处是：你可以只替换其中一层验证自己的假设。比如我怀疑Kronos对特定频率不敏感，就在数据层换一个重采样频率，模型层不动；或者我想验证预测分布是否有用，就保留模型层预测，在信号层改分位数阈值。很多人在迁移量化策略时喜欢把数据和模型耦合在一起，最后连特征是哪个时间点生成的都说不清楚。FaceCat-Kronos把数据流和模型流分开，其实就是逼用户把回测里最关键的时间对齐问题提前暴露出来。

还有个容易忽略的细节：数据层的对齐是否严格按“先有数据，后有预测”来切分。Kronos模型本身是不管这个的，它只看你给的序列。如果你不小心把当日全天数据都喂进去，模型就会用当日收盘信息去预测当日开盘，回测结果当然好，实盘根本复现不了。这也是为什么FaceCat-Kronos的数据层里会要求升序时间戳、固定频率、以及一个显式的“预测起点”参数。用的时候要认真看这个参数，而不是直接传整份DataFrame进去。

2.3 为什么不用自己训LSTM/Transformer：数据量是最大的墙

很多人一看到Kronos就想到“我也可以自己训一个Transformer来做预测”。还真不行。问题不在模型能力，在数据量。以日线数据为例，一支股票上市至今也就五六千根K线。LSTM或Transformer要学出趋势和周期的组合规律，至少需要几十万到上百万个样本。用几千根数据去训练一个深度模型，最常见的结果是训练集loss很低，验证集一塌糊涂。这不是超参数问题，是样本量撑不住模型复杂度。

自监督预训练缓解的正是这个问题。Kronos在源领域见过大量序列形态，学习到的是通用的时序变换规律。拿到金融数据时，它不需要从零学“什么是趋势”，只需要在已有的先验上稍微适配金融序列的噪声分布。这就把有效样本量需求降下来了一个数量级。当然，这不代表Kronos对每个品种都管用。更理性的做法是先零样本跑一轮，看预测和真实值的相关性和分位数的校准情况。如果零样本表现已经可用，再考虑微调；如果零样本一塌糊涂，微调大概率也救不回来，因为基础模型的先验方向可能和这个标的运动规律不对付。

还有一个工程原因：自训模型从头到尾都需要自己处理归一化、滑窗、验证集切分、未来函数。这些细节一旦出错，模型再强也是白搭。用FaceCat-Kronos这类封装好的工具，虽然不能保证赚钱，但至少把“预测是否用了未来数据”这个基本问题隔离掉了。我可以把精力放在策略信号和仓位管理上，而不是反复质疑回测结果的真实性。

3. 本地跑通FaceCat-Kronos：环境、数据和最小预测脚本

3.1 安装与权重准备

先解决环境。FaceCat-Kronos依赖PyTorch和配套的数据处理库，Python版本建议3.10以上。我一般习惯先建独立conda环境，避免把系统Python搞乱。安装路径以项目开源仓库的README为准，常见做法是clone后直接pip install -e。

git clone <FaceCat-Kronos仓库地址> cd FaceCat-Kronos conda create -n facecat python=3.10 -y conda activate facecat pip install -e .

安装完成后不要急着跑，先确认权重能不能自动下载。Kronos模型权重一般托管在模型仓库里，第一次加载时会自动下载到本地缓存目录。如果你所在的网络访问不了默认下载地址，可以手动把权重文件放到~/.cache/kronos下，具体目录结构看项目文档。检查是否装好的命令是：

python -c "from facecat_kronos import KronosPipeline; print(KronosPipeline)"

没有报错就说明核心库和依赖都齐了。这里要提醒一句：不要跳过pip install -e里的-e。它会把项目以开发模式安装，后续更新代码不用重新安装。这个工具更新比较勤，直接用pip install .的话，每次升级都要重装，很容易出现版本对不上的问题。

3.2 行情CSV转成Kronos数据集

金融预测项目里，数据清洗比模型训练更花时间。FaceCat-Kronos的数据层需要标准OHLCV格式，至少包含时间戳、open、high、low、close、volume六列。我一般先用pandas做排序和缺失检查，再交给数据加载器转换。

import pandas as pd from facecat_kronos import KronosDataset df = pd.read_csv("btc_1h.csv", parse_dates=["datetime"]) df = df.sort_values("datetime") # 必须升序，否则预测序列是反的 ds = KronosDataset.from_ohlcv( df=df, timestamp_col="datetime", price_cols=["open", "high", "low", "close"], volume_col="volume", freq="1h", ) print(ds.len)

这里几个参数值得展开。timestamp_col必须是datetime类型，不要用字符串，否则时间排序会按字母排。price_cols一般把OHLC都传进去，因为Kronos在预训练时见过多变量序列，只传close会丢掉高低开信息。freq很关键，它告诉模型数据是小时级还是日级，频率错了，模型内部的时间编码就错位，预测结果会非常奇怪。

如果原始CSV里有缺失时间戳，比如某些小时没有交易，不要直接drop。金融数据里的缺失往往代表流动性差，直接删掉会让模型以为时间连续，从而低估波动。FaceCat-Kronos的处理方式是把缺失时间戳补成NaN，由模型内部决定是否忽略。你只需要保证排序正确，重复时间戳不能出现。

3.3 最小预测脚本与输出解读

数据集准备好之后，最小预测脚本很短。下面这段是我在本地验证模型是否正常时用的模板，也是后续接策略的基础。

from facecat_kronos import KronosPipeline pipe = KronosPipeline( model_name="kronos-base", device="cuda", # CPU环境改成 "cpu" ) forecast = pipe.predict( ds=ds, input_length=512, horizon=96, num_samples=20, ) print(forecast.mean_close) print(forecast.quantile(0.05)) print(forecast.quantile(0.95))

这里的input_length是喂给模型的K线根数，horizon是预测未来多少根K线。默认512和96的意思是：用过去512根小时K线预测未来96小时。num_samples=20表示从预测分布里采样20条路径，用这些路径算均值和中位数。

第一次运行会下载权重，几GB不等，耐心等。跑完后输出的mean_close是一条未来96小时的预测价格曲线，quantile(0.05)和quantile(0.95)是90%预测区间的下界和上界。我拿到输出后的第一件事，不是看涨还是跌，而是看区间宽度：如果预测区间宽到覆盖了涨跌两个方向，那这个预测对单边策略没有意义，只能做波动率或做市策略。

如果你想把预测结果可视化，直接对forecast.mean_close调用pandas内置的plot即可。注意预测索引是从最后一个真实K线之后开始的，不是从第一个真实K线开始，很多人第一次画图会把两条线错位看图，误以为模型滞后，其实是索引没对齐。

4. 把预测变成策略：窗口参数、微调与回测设置

4.1 输入长度和预测步数怎么配对

Kronos的预测表现很吃输入长度和预测步数的匹配。我见过不少踩坑案例：直接把horizon设成几十甚至几百，然后发现预测均值几乎是一条水平线。这不是模型坏了，而是预测步数拉长后，不确定性累积，模型回归到历史均值是完全合理的。

经验法则是：预测步数不要超过输入长度的三分之一。比如输入512根K线，预测96步，即未来不到输入长度的20%，效果相对稳定。如果你做日线级别，目标是预测未来5天，那就用过去30到60天作为输入。输入太短，模型看不到趋势；输入太长，会把早已失效的旧行情当成当前状态。

频率和高度的组合也要调。对于小时级数据，我一般用输入512到1024，预测24到96。对于分钟级数据，输入长度可以放宽到2048，但要小心高频噪声。Kronos在分钟级上的零样本表现通常不如小时级和日级，因为高频数据的微观结构和预训练数据差异更大。如果策略本身就是日内高频，建议先用日线数据验证模型有没有预测能力，再决定值不值得上分钟级。

这里还涉及一个信号周期问题。预测步数应该对应持仓周期：你做3天持仓，就预测3天；做1小时持仓，就预测1小时。不要把预测周期和交易周期错开。预测周期比持仓周期长，信号更新太慢；预测周期比持仓周期短，噪音又会掩盖真正的中期趋势。我在配置时会把持仓周期先定下来，然后反推horizon，而不是先跑模型再想怎么用。

4.2 冻结backbone微调和全量微调怎么选

Kronos零样本输出适合做初筛，但如果你想对一个特定品种持续预测，微调一般会带来稳定提升。FaceCat-Kronos的微调接口预留了两种模式：冻结backbone只训练输出头，或者全参数微调。两者适用场景完全不同。

冻结backbone微调的数据需求量小，训练快，也不容易忘记预训练学到的通用规律。我认为大多数个人和中小团队应该先用这种模式。尤其当你只有几千根K线时，全参数微调很容易直接把预训练权重冲坏。全参数微调不是不能用，但前提是数据量足够大，并且验证集切分严格按时间顺序。

下面是一段典型微调代码：

from facecat_kronos import KronosForecaster model = KronosForecaster.from_pretrained("kronos-base") trainer = model.finetune( train_loader=train_loader, val_loader=val_loader, freeze_backbone=True, lr=1e-4, epochs=5, gradient_clip=1.0, )

freeze_backbone=True是关键参数。它把Kronos主体网络的权重冻结，只更新最后输出层。lr一般从1e-4起步，epochs在3到5之间。金融时序信噪比低，训练太久必然过拟合。gradient_clip=1.0是防止个别异常样本把梯度拉爆，这个参数在金融数据上基本必须开。

微调后不要看训练集loss，要看验证集的预测方向准确率或IC。验证集必须严格在时间上晚于训练集。比如2019到2022年训练，2023到2024年验证。不能随机打乱切分，否则模型会“记住”每个时点的噪声，验证结果虚高。另外，微调前后最好保留同一个验证集，用零样本预测作为baseline，微调后如果IC没有提升超过20%，说明这个标的和预训练规律差异不大，微调的收益有限。

4.3 回测参数：阈值、止损、滑点

预测做完只是第一步，能不能变成策略，要看信号生成和回测参数。我常用的是预测收益率阈值触发：只有当预测未来N期收益的置信区间下界大于0时才做多，上界小于0时才做空。

拿90%置信区间举例：预测收益的5%分位数大于0，意味着模型有95%把握未来N期收益为正。阈值越严格，交易次数越少，胜率越高，但可能错过机会。回测时需要把阈值和换手成本放在一起看。

我习惯用这张参数表做初始配置，再根据标的波动调整：

止损用预测区间宽度而不是固定百分比，是我自己的习惯。Kronos预测区间宽说明当前不确定性高，止损放太近会被噪声扫掉；预测区间窄说明行情清晰，止损放太远又没意义。用区间宽度的1.5倍，相当于给策略设了一个自适应止损。

回测里最容易让人产生幻觉的是滑点参数。做分钟级回测，我用万五起步；做日线，用千一也不夸张。如果回测模型里没有显式滑点参数，至少要按成交价的0.1%做成本扣减。很多策略在没有任何交易成本时年化50%，扣完滑点手续费直接变负，这不是模型失效，是成本没算够。

5. FaceCat-Kronos避坑指南：数据泄露、过拟合与失效场景

5.1 回测很漂亮，实盘却亏损

现象：回测年化50%，胜率65%，实盘连续三周亏损，回撤曲线和回测完全对不上。

原因通常出在两个地方。一是数据泄露，比如用全样本均值做归一化，或者把未来一段时间的统计量混进了历史输入；二是成交时点过于理想，回测假设信号出现后立刻按当前价成交，实盘却要等下一根K线，价差和延迟全被吃掉。

解决方法是做两步检查。第一步，把归一化切到窗口滚动模式，只用t时刻之前的数据算均值方差；第二步，把回测成交价改到信号生成后的下一根K线开盘价，滑点设到万五以上。这样改完再看回测，一般会砍掉一半以上收益，剩下的是相对可信的部分。FaceCat-Kronos的数据层本身就支持预测起点参数，回测时务必让预测起点晚于最后一个输入K线。

5.2 预测曲线比真实行情滞后半拍

现象：把Kronos预测均值和真实收盘价叠在一起，发现预测曲线看起来总是慢半拍，涨跌方向都对，但转折点晚一两个周期。

原因很常见：模型预测的是未来多个patch的平均路径，本身就带有平滑效应；如果是多步预测，均值会向历史水平收缩，看起来就像滞后。另一个原因是你拿预测的“最后一个点”去和“当前真实值”比较，但预测点是在历史序列基础上外推的，比较基准根本不对。

解决方式：不看价格，看预测收益率。用未来N期收益率预测，比用价格预测更不容易产生“滞后感”。如果仍然滞后，检查输入序列是否用了未复权价格，分红除权会造成假跳变，模型会把这些跳变当成真实行情，预测自然对不上。换用前复权价格基本能解决。

5.3 微调后验证集反而变差

现象：训练集loss不断下降，验证集IC却比零样本还低，而且每多训练一个epoch就再降一点。

原因几乎总是过拟合。金融数据是强噪声低信噪比，模型训练到一定程度就开始记忆噪声。另外，验证集在时间上在后，市场状态可能已经切换，模型在训练集上习得的规律不适用于新的环境。

解决方式：优先用冻结backbone的轻量微调，限制输出头的学习率；把epochs从5降到2到3，观察验证集IC随epoch变化，选验证集最优的checkpoint，而不是训练集收敛的checkpoint。如果验证集还是比零样本差，就接受零样本结果，不要强行微调。

5.4 CPU推理太慢，GPU显存不够

现象：用CPU跑512输入、96预测、20次采样，单次推理要几十秒，分钟级策略根本跑不动；侥幸上了GPU，batch一加大直接Out of Memory。

原因：Kronos的Transformer结构在长序列和多采样次数下计算量线性放大，采样20次等于一次推理20倍成本。

解决方式：先做信号粗筛，把num_samples降到1，只保留预测方向；对通过粗筛的时间点再用20次采样做精细仓位。推理时用半精度，很多深度学习框架里只需在模型层加半精度转换，显存占用几乎减半。如果显存还是不够，把input_length从512降到256，代价是预测精度轻微下降，但能换来稳定运行。上了GPU还慢，要先检查batch size是否过小，GPU利用率太低，增大batch往往比调模型更有效。

5.5 加了因子却没有提升IC

现象：原本只用OHLCV，IC在0.04到0.06之间；加了换手率、资金流、情绪因子后，IC反而降到0.03，或者完全没有变化。

原因：FaceCat-Kronos默认的数据接口以OHLCV为骨架，额外因子如果不在模型预训练格式里，可能被当作独立序列拼接，但模型没有针对这些因子的时间编码做适配，结果等于给输入增加噪声。还有一个原因是因子本身已经包含在OHLCV的衍生信息里，比如某些流动性因子和成交量高度相关，模型已经有了这个信息，再加是冗余。

解决方式：把新增因子当成条件特征，在数据层和价格序列分别编码，再拼接进输入特征。每个因子单独做IC检验，只保留零样本下IC绝对值大于0.02且与价格因子相关性低于0.7的因子。不要迷信因子越多越好，时序基础模型不是机器学习竞赛里的堆特征游戏，它的先验来自序列形态，因子必须转换为模型能理解的“序列信息”才有用。

6. 先做预测能力体检，再谈盈利：IC验证与滚动更新技巧

最后这条建议值一次血泪经验：不要先写策略，先给模型做体检。把Kronos的预测当成一个黑匣子，你需要先确认它有没有预测能力，再决定值不值得为它投入。所谓预测能力，我现在只看两个指标：IC和ICIR。IC是预测收益率和未来真实收益率的Spearman相关系数，ICIR是IC的均值除以标准差。一个稳健的时序模型，ICIR至少在0.3以上才值得继续做，低于0.1基本就是噪声。

我自己的常规流程是：取一只流动性好的标的，三年日线数据，用滚动窗口做预测，每120天滚动一次，预测未来3到5天收益，算整个区间IC均值。下面这段代码是一个可行的验证脚本：

from facecat_kronos import evaluate_ic result = evaluate_ic( pipe=pipe, df=df, window_days=120, horizon=3, metric="spearman", ) print(result.ic_mean) print(result.icir)

window_days=120表示每隔120天重新训练或重新做窗口对齐，horizon=3表示预测未来3天收益。如果IC均值大于0.05，ICIR大于0.3，模型在这个标的上具备基础预测能力。这时再做策略不迟。如果IC均值在0附近，直接放弃这个标的或换预测频率，比调一万个参数都有效。

体检通过之后，还有一个滚动更新习惯要养成。Kronos虽然预训练强大，但金融数据的状态会漂移。我一般每周五收盘后用最新数据重跑一遍预测，每个月做一次轻度微调，每次微调保留验证集最优的权重，而不是最新epoch的权重。实盘信号生成时间和策略执行时间之间必须留出足够间隔，不要让预测K线没收盘就下单。

这套做完，你会发现自己对Kronos的预期越来越正常。我不再指望它预测每个转折点，而是把它当成一个能给未来收益“排出概率分布”的助手。预测区间宽的时候我减仓，预测区间窄且有方向的时候我加仓，模型也会犯错，所以我永远保留止损。希望这些参数和踩坑记录能帮你少走一段弯路，祝顺利跑通第一张K线预测。

本文还有配套的精品资源，点击获取