ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

FaceCat-Kronos实战:基于大语言模型的做市商K线规律预测

FaceCat-Kronos实战:基于大语言模型的做市商K线规律预测 简介FaceCat-Kronos是花卷猫量化研究团队自主研发的金融量化预测工具依托清华大学开源的Kronos框架与人工智能技术对股票历史数据进行深度预训练辅助做市商及中短线交易者捕捉K线规律发掘传统方法难以发现的复杂模式。资源共43个文件压缩包仅1.41MB以Python代码为核心23个py涵盖模型模块、训练/推理示例、Qlib数据接入、Token器训练、无交易量预测等脚本并带有可视化图片、配置JSON、说明文档及附赠Word资料目录结构清晰便于快速定位与二次开发。已有482人学习浏览适合量化研究者、金融算法工程师以及具备一定编程基础、希望入门AI选股或复现K线预测流程的进阶学习者。通过源码可同时理解Kronos时序建模思路与FaceCat封装工程实现从数据预处理、模型训练到预测推理均有对应可运行实例是一份紧凑且可实际运行的参考包。1. Kronos 凭什么做做市商 K 线规律预测在行情快照高度内卷的做市场景里传统技术指标给出的信号往往滞后一到两根 K 线而纯统计模型又很难同时吃下不同周期、不同标的的波动规律。FaceCat-Kronos 的思路是把整个股票历史 K 线当成“金融文本”先用类似语言模型的方式做深度预训练让模型理解价格序列里的重复结构再做做市商 K 线规律预测。底层依赖的是清华大学开源的 Kronos 框架它没有沿用 LSTM 或 Transformer encoder 的老路而是把时间序列 token 化之后交给类 Llama 的 decoder-only 结构去预测下一个 patch。目录里既有 CPU 推理脚本也有依赖 facecatcpp.dll 的本地可视化端适合想快速用上预训练模型又不打算从头搭训练管线的量化研究人员、做市策略工程师和 AI 相关专业的学生。2. 拆解 FaceCat-Kronos 的目录设计与技术底座2.1 examples、model、finetune 三层源码结构解压后的facecat-kronos-main目录分层很清晰三个文件夹分别对应推理、模型定义和训练管线直接按功能切分而不是按文件混排。根目录下的README.md和README.en.md是双语文档说明文件.txt与附赠资源.docx一般是作者补的部署笔记安装依赖前建议先扫一眼这两个文件里面往往包含权重文件的放置路径和已知问题记录。路径作用examples/cpu_prediction_example.py纯 CPU 环境下跑上一次 K 线预测适合无 GPU 的调试机examples/prediction_example.py默认推理示例自动选择 GPU/CPU带成交量输入examples/prediction_wo_vol_example.py不依赖成交量数据的简化版预测适合只有 OHLC 的市场model/module.pyKronos 网络结构定义包含 patch embedding、transformer layermodel/kronos.py对外暴露 KronosPredictor、KronosTokenizer 等高层接口finetune/train_predictor.py基于 PyTorch Lightning 的预测头训练入口finetune/train_tokenizer.py分位数 tokenizer 训练脚本用历史数据重新生成码本finetune/dataset.py序列滑窗采样与批量读取负责把 K 线切片成训练样本utils/qlib_data_preprocess.py把 qlib 标准格式的 CSV 数据转成训练/推理可用的 npy 序列facecat/main_pyside.py基于 PySide 的桌面端加载模型后直接在本地 K 线图上显示预测结果实际跑起来时建议先用prediction_wo_vol_example.py通流程再切到带成交量输入的prediction_example.py。后者多了量能相关的 token输入构造上要额外对齐成交量序列和价格序列的时间索引。facecat目录下的facecat.py是封装 C 动态库的 Python 桥接层它不参与模型计算只在渲染和读取行情图片时做加速。2.2 requirements.txt 与 CPU/GPU 推理分支requirements.txt的内容大致围绕 PyTorch、numpy、pandas 展开GPU 机器上一般还要额外安装对应 CUDA 版本的 torch。先看文件内容再决定用哪套环境不要无条件pip install -r requirements.txt。# 建议先创建独立虚拟环境 conda create -n facecat python3.10 -y conda activate facecat # 安装基础依赖requirements.txt 里通常不含 torch需要按硬件选装 pip install -r requirements.txt # CPU 版 pip install torch --index-url https://download.pytorch.org/whl/cpu # GPU 版以 CUDA 12.1 为例 pip install torch --index-url https://download.pytorch.org/whl/cu121如果只做推理复现建议 CPU 版 torch 就够了Kronos 模型在单条序列上不需要大矩阵并行seq_len在 512 以下时 CPU 推理速度尚可。requirements.txt中还有pandas、numpy、tqdm、pyyaml这类常规依赖其中pyyaml用于读取config.py里的参数配置训练环境还需要pytorch-lightning和tensorboard这两项在很多精简版 requirements 里不会写全。提示如果启动main_pyside.py闪退优先确认PySide6是否安装它是桌面端的唯一图形依赖。2.3 为什么是 Llama 式 decoder-onlypatch 与 tokenizer 的含义Kronos 的核心不只是“用 Transformer 预测 K 线”而是把连续价格序列映射成离散 token这一步决定了整个模型的表达能力。常见做法是把长度为patch_size的连续 K 线窗口比如 16 根 K 线的 OHLC 归一化值压缩成单个 token然后在码本里找到最近的分位数向量作为该窗口的离散表示。训练好 tokenizer 之后原始的浮点价格序列变成一段 token 序列后续预测任务就是标准的自回归式 next-token prediction。这种设计的直接好处是解决了金融数据非平稳的问题。传统回归模型直接预测未来价格数值遇到风格切换时误差会迅速放大而 tokenizer 把预测目标限制在码本空间里模型只需要决定“下一段窗口落在哪个分位区间”鲁棒性更强。decoder-only 结构则让预测头可以复用预训练阶段学到的市场结构信息微调做市商场景时只更新最后几层收敛速度远快于从零训练的 LSTM。FaceCat-Kronos 在model/kronos.py中暴露的KronosPredictor类内部就是把 tokenizer 输出接上若干层自注意力再输出未来预测区间的分位数序列整体思路和自然语言处理里的 causal LM 高度一致。3. 推理实战从 examples 跑通单标的 K 线预测3.1 最小复现cpu_prediction_example.py 的调用方式examples/cpu_prediction_example.py的设计目的是在没有任何独显的机器上验证模型能否正常加载和推理。脚本核心逻辑很直接读取历史 K 线文件转成模型输入张量调用KronosPredictor输出未来 K 线预测。它的参数大多从命令行传入也可以直接改脚本里的常量。python examples/cpu_prediction_example.py \ --data-path data/example.csv \ --seq-len 512 \ --pred-len 32 \ --device cpuseq_len是回看窗口的 K 线数量也就是用最近多少根 K 线来预测未来512 表示约两天的分钟级数据日线数据建议减到 128 或 64否则输入窗口跨度过长容易覆盖多个不同行情阶段。pred_len是预测未来 K 线根数做市商场景下 16 到 32 比较合理太长时预测的分位数区间会明显变宽。device参数在 CPU 脚本里固定为 cpu但代码内部仍保留cuda分支方便直接改设备名切换。输出的并不是一根确定性的 K 线而是一组分位数预测结果通常是未来pred_len根 K 线的 open、high、low、close 的 0.1、0.5、0.9 分位值。拿 0.5 分位作为基准预测0.1 和 0.9 分位作为风险区间这样在做市报价时可以直接把买卖价差设在中位数附近避险时参考分位宽度。3.2 无成交量输入的简化模式prediction_wo_vol_example.py 的使用场景prediction_wo_vol_example.py这个文件名里的wo_vol是 without volume 的缩写。很多国外数据源的分钟线成交量字段缺失或对齐异常而 Kronos 预训练时如果同时混入了含成交量和不含成交量的序列推理时就必须保持一致的输入格式。作者单独抽出这个脚本就是为了解决只拿到 OHLC 数据时的推理兼容问题。import torch from model.kronos import KronosPredictor, KronosTokenizer tokenizer KronosTokenizer.from_pretrained(model/tokenizer.json) predictor KronosPredictor.from_pretrained(model/checkpoints/kronos_facecat.pt) # 输入: (seq_len, 4) - open, high, low, close kline_input torch.tensor(data, dtypetorch.float32).unsqueeze(0) with torch.no_grad(): pred_tokens predictor.predict(kline_input, pred_len24) pred tokenizer.decode(pred_tokens) # (1, 24, 4)这个分支内部会把输入形状从(batch, seq_len, 5)截断成(batch, seq_len, 4)也就是自动丢弃最后一列成交量。代码中的关键点在于KronosPredictor的predict方法不是一次生成全部预测 token而是循环调用forward每一步把上一步预测的 patch 拼回输入序列。如果你看到推理速度偏慢问题往往出在这个循环次数等于pred_len上而不是模型本身参数量大。3.3 预测结果的还原与做市商信号加工模型输出的分位数序列是在标准化空间里的直接拿去做市没有意义。脚本末尾通常带着inverse_transform的逆归一化但在做市商实盘建议里更重要的一步是把“预测的 close 中位数”转换成具体策略信号。base close_series[-1] future_med pred_closes[:, 0.5] # (pred_len,) future_up pred_closes[:, 0.9] # 如果未来 16 根 K 线的 90% 分位价格高于现价 0.3% 以上则维持正库存 signal long_bias if (future_up[-1] - base) / base 0.003 else neutral注意这里用future_up而不是用未来中位数是因为做市商面临的不对称收益方向判断错误时中位数信号没有提供任何风险管理信息而 0.9 分位可以当作“最坏情况下的上涨空间”。如果你想更保守可以同时要求 0.1 分位不低于现价下方某个阈值否则即使中位数看涨也选择缩小报价宽度而不是加仓。这是做市商 K 线规律预测和设备端模型推理之间最容易忽略的衔接环节。4. 微调一条真正的量价时间序列模型4.1 数据工程qlib_data_preprocess.py 的工作流utils/qlib_data_preprocess.py表明作者采用 qlib 作为数据中间层。qlib 是量化投研领域常见的开源平台它会把原始行情整理成“交易日历 股票列表 逐字段二进制”的格式。FaceCat-Kronos 里这个脚本做的是反向操作把 qlib 的 CSV dump 导出成模型训练需要的时间序列样本。# 先用 qlib 导出 CSV这里以 qlib 已初始化数据目录为前提 python -m qlib.run.get_data --qlib_dir ~/.qlib/qlib_data/cn_data \ --region cn --start 2020-01-01 --end 2024-12-31 --freq 1d # 再执行项目自带的预处理脚本 python utils/qlib_data_preprocess.py \ --input-dir ~/.qlib/qlib_data/cn_data \ --output-dir data/processed \ --seq-len 512 \ --pred-len 32 \ --mode train脚本内部会做三件事第一把所有股票的日线序列按绝对时间对齐只保留交易日历上的日期第二对每只股票单独计算 z-score 归一化避免高价股和低价股在 tokenizer 训练时互相干扰第三用滑窗切出(seq_len pred_len)长度的子序列前段做输入、后段做预测标签输出为npy文件。mode参数切到test时不生成标签只保留输入段用于后面推理验证。常见坑qlib dump 出来的文件路径是按市场代码分目录的--input-dir要指向包含calendars、instruments、features的根目录而不是 features 内部。判断标准是脚本里是否有open(days_path)之类的读取日历文件行为如果有你传的路径就必须同时能看到calendars/day.txt。4.2 训练 tokenizer 与 predictor 的参数对照在finetune目录下训练过程被拆成 tokenizer 训练和 predictor 训练两个阶段。train_tokenizer.py负责拟合价格序列的分布产出码本文件train_predictor.py则在固定 tokenizer 的情况下训练预测头。两个脚本共享config.py中的参数但同一参数在两个阶段表达的含义不同。# config.py 中的示例配置实际以项目内文件为准 config { patch_size: 16, # tokenizer: 每个 patch 覆盖 K 线根数 vocab_size: 4096, # tokenizer: 码本容量 d_model: 768, # predictor: 注意力隐层维度 n_layers: 12, # predictor: transformer 层数 seq_len: 512, # predictor: 输入 K 线数 pred_len: 32, # predictor: 预测 K 线数 batch_size: 64, lr: 1e-4, weight_decay: 0.01, }参数tokenizer 阶段含义predictor 阶段含义patch_size一个 token 覆盖的 K 线窗口长度输入序列被 reshaped 的基础块大小vocab_size分位数码本条目数分类头输出维度seq_len训练 tokenizer 时截取的单段序列长度模型输入窗口影响显存占用lr码本更新步长一般用 1e-3transformer 全参数微调用 1e-4冻结编码器时用 5e-5训练顺序不能颠倒。tokenizer 不收敛时predictor 无论训练多久都不可能学到有效规律因为离散 token 一直漂移。先跑train_tokenizer.py确认训练损失降到稳定水平后再检查model/tokenizer.json是否生成最后执行train_predictor.py。4.3 在本地复现时最容易出错的三个配置问题第一个问题是batch_size显存爆炸。seq_len512、d_model768时单条样本已经是几十万浮点数如果显存只有 8GBbatch_size调到 8 就是极限建议先用 4 验证前向和反向传播正常再逐步加大。第二个问题是数据集里含大量停牌垃圾样本。qlib 预处理脚本默认会把 NaN 填充为 0但如果你在训练集生成前没有过滤amount0的交易日模型会学到“连续零成交量”这种虚假规律。第三个问题是 tokenizer 训练和 predictor 训练用了不同的归一化参数。qlib_data_preprocess.py输出的scaler.json一定要同时保留并用它来预处理后续推理数据否则预测结果会出现整体偏移。5. 附带资源中的 facecatcpp 加速与 PySide 看盘界面5.1 facecatcpp.dll 加速与图形输出facecat/facecatcpp.dll是 FaceCat 团队封装的 C 扩展库核心解决两个问题一是大规模 K 线数据的快速渲染二是把 PySide 界面里的高频刷新从 Python 层解放出来。facecat.py通过 ctypes 加载这个动态库import ctypes dll ctypes.CDLL(facecat/facecatcpp.dll) dll.CreateKLineView.restype ctypes.c_void_p view dll.CreateKLineView()加载成功后会返回一个窗口句柄main_pyside.py拿这个句柄往 PySide 的QWidget上贴图。日常使用时你不需要直接调这些接口直接运行python facecat/main_pyside.py即可看到封装好的界面模型预测结果会以虚线绘制在当前 K 线的右侧。5.2 用 main_pyside.py 把预测接进本地 K 线界面桌面端配置好模型路径后启动命令很简单python facecat/main_pyside.py \ --model-path model/checkpoints/kronos_facecat.pt \ --tokenizer-path model/tokenizer.json \ --data-dir data/csv界面里会同时显示历史 K 线和未来预测区间预测区域默认用半透明色带表示 0.1 到 0.9 分位。色带宽度大说明模型不确定性高此时做市商应主动收窄挂单量色带窄且中位数线朝一个方向延伸才是相对高置信度的行情信号。如果你把鼠标悬停在预测色带上状态栏会显示当前预测位置对应的未来时间和分位价格。5.3 值得补做的验证把预测落成可回测的 PnL代码包里没有现成的回测引擎但你可以把pred_len的预测结果平移到历史数据上做 rolling 验证。常见做法是对每个交易日 t用t-1时刻之前seq_len根 K 线做预测把预测的 0.5 分位 close 和真实 close 做差统计绝对百分比误差如果误差中位数大于 1%优先检查scaler.json是否匹配误差分布右偏说明预测系统性高估需要在inverse_transform后减去偏差项。最后用不超过 20 行的 pandas 脚本就能把预测序列和真实序列画在一起这比任何日志指标都更能暴露边界问题。验证时要注意避免以未来数据回填输入窗口即预测第 t 根 K 线时只能用 t-1 及之前的信息这是做市策略回测数据泄漏最常见也最隐蔽的错误。本文还有配套的精品资源点击获取
返回列表