## 摘要

这个系列上一篇的结尾有一句话：模型是标准件，管道是每家企业的手工活。当时说的是传统机器学习——模型要自己训，管道要自己搭。到了基础模型时代，前半句又掉了一截：金融时序模型连训都可以不训了。Kronos 是清华大学团队 2025 年发布、首个专门为金融 K 线预训练的开源基础模型，权重挂在 Hugging Face 上，下载即用，上线一年多在 GitHub 拿了三万八千颗星。模型成了真正的标准件，剩下的工程全部集中在管道上：K 线数据怎么存、怎么取、怎么以合适的批次和口径喂给模型。DolphinDB 官方教程给出了三种喂食方式——小数据一次进内存、中规模落盘 pkl 分批读、大规模用 DDBDataLoader 从库里直接转张量，把"给基础模型供数"这条管道做成了可照抄的工程模板。本文沿官方教程与论文的线索，从"K 线即语言"的模型架构讲起，把三种管道逐一走一遍。
## 一、引言：模型越来越公用，数据越来越私有

基础模型浪潮卷到金融时序，比其他领域晚了些，原因不复杂：通用时间序列基础模型（TSFM）在 K 线上的表现一直不理想。Kronos 论文的开篇说得很直白——预训练模型在金融 K 线（candlestick）数据上的应用仍然有限，常常还不如非预训练的架构。金融 K 线是出了名的难啃：低信噪比、非平稳、厚尾分布，信号本来就弱，通用的预训练范式未必照搬得动。
Kronos 的回答是专门化：不为所有时序建模，只为 K 线建模。它用全球 45 家以上交易所的 K 线数据做预训练，decoder-only 架构，论文 2025 年 8 月挂上 arXiv，随后被 AAAI 2026 录用，代码和权重以 MIT 协议开源。开源之后社区用脚投票，GitHub 星标数在金融开源模型里涨得很快——一个可以直接 `from_pretrained` 下载的金融基础模型，对大量没有预训练算力的团队来说，是第一次够得着的东西。
对使用者来说，这个变化把工程重心彻底推到了数据侧。权重是公开的，架构是论文里写明的，超参数是示例代码里给好的，唯一不公开的是你自己的数据：你的品种、你的周期、你的成交细节。模型越公用，数据越私有；数据从数据库到模型之间的那段管道，就成了全部的手工活。上一篇讲库内机器学习时说"瓶颈常常不在模型，在管道"，到了基础模型这里，这句话成立了两次：模型不用训了，管道还在。
这篇就讲这段管道。仓库是 DolphinDB，用户是 Kronos，官方教程提供了完整的三种喂数方式。先花一点篇幅讲清楚 Kronos 为什么把 K 线当"语言"来读——不理解这一点，后面的数据管道细节就只是操作手册。
![img](https://developer.qcloudimg.com/http-save/yehe-11825160/88ae681008235f5052ea9a9e5aa14ded.png)
## 二、K线是一门语言：分词器与先粗后细

语言模型读的不是声波，是离散的词元。Kronos 把同一套思路搬到了 K 线上：与其让模型直接回归连续的价格曲线，不如先把每个时间点的 6 维 K 线数据（开、高、低、收、量、额，OHLCVA）翻译成离散的"词汇"，再让模型学习这些词汇的序列规律。动机还是金融数据的低信噪比——连续值回归容易过拟合、对异常值敏感，而量化成离散 token 之后，模型是在"词汇层"理解市场，鲁棒性好得多。
整个模型分两个模块，对应两阶段训练。
**第一阶段是 K 线分词器。** 一个轻量 Transformer 编码器把每个时间点的 6 维 K 线压缩成连续潜变量，然后用 Binary Spherical Quantization（BSQ）做量化：把潜变量投影到单位球面，用 20 个可学习的超平面做二值化，得到一个 20 位的二进制码。20 位意味着理论词表大小 2 的 20 次方，约一百万个"词"——K 线的字典。这 20 位再对半分成两段：前 10 位是粗子码，词表 1024，编码主要的价格结构；后 10 位是细子码，词表 1024，编码局部波动细节。训练分词器用两级重建损失约束这个层级：只用粗码去重建原始 K 线，逼粗码学大形态；用完整 20 位重建，让细码负责补细节。粗与细的分工不是人为指定的，是损失函数逼出来的。
**第二阶段是分层自回归预测器。** 一个 decoder-only 的 Transformer（因果注意力保证只看历史，RoPE 位置编码，RMSNorm），输入是历史 token 序列，任务是预测下一个 token。它的生成是"先粗后细"的两步：先根据上下文预测下一时刻的粗子码——判断大方向；再把采样得到的粗子码作为条件，通过交叉注意力补出细子码——填进具体波动。推理时用温度采样和 top-p 控制随机性；需要稳定的点预测时，采样多条未来轨迹，各自解码回连续值后取平均，论文实验显示轨迹数越多精度越高。
成绩单按三种用途计：价格序列预测，在多个基准数据集上超过通用时序模型和金融专用基线；波动率预测，MAE 比基线低 9%；合成 K 线生成，保真度提升 22%。预测、风控、数据增强，一个模型通吃——这正是"基础模型"三个字的含义。
模型家族按算力分档：Kronos-mini 4.1M 参数、上下文长度 2048；Kronos-small 24.7M、上下文 512；Kronos-base 102.3M、上下文 512；499.2M 的 large 未开源。官方教程用的是 small，上下文 512 意味着输入的历史窗口（lookback）不能超过这个数——这是后面所有数据管道要对齐的第一个口径，数据取多长，从这里开始定。
![img](https://developer.qcloudimg.com/http-save/yehe-11825160/71ee5e307271710bf199b35235df4bd8.png)
## 三、语料从哪来：一条 SQL 喂数据

K 线数据是典型的面板数据：多品种 × 多周期，按时间轴组织。这种数据的存储形态决定了喂模型的效率。DolphinDB 官方教程在开篇点了几条契合：时序数据库天然为这类数据设计，高频写入低延时；跨品种跨周期能直接重采样，1 分钟 K 线聚合成 5 分钟、30 分钟不用出库；时序聚合和截面计算都能在库内完成。教程使用的数据是一套 tushare 分钟级 K 线，按日期分区存在分布式库里，表形如 `dfs://tushare_minute_db` 下的 `stock_5min_k`。
预测侧的快速上手，把两边各写三行就接通了。模型侧从 Hugging Face 加载权重：
```
from model import Kronos, KronosTokenizer, KronosPredictor
import dolphindb as ddb
import pandas as pd
​
tokenizer = KronosTokenizer.from_pretrained("NeoQuasar/Kronos-Tokenizer-base")
model = Kronos.from_pretrained("NeoQuasar/Kronos-small")
predictor = KronosPredictor(model, tokenizer, max_context=512)
```
数据侧用 Python API 连库，取数是一条再普通不过的 SQL：
```
s = ddb.session()
s.connect("localhost", 8848, "admin", "123456")
script = '''
 &nbsp;  select trade_time as timestamps, open, high, low, close, vol as volume, amount
 &nbsp;  from loadTable("dfs://tushare_minute_db", "stock_5min_k")
 &nbsp;  where trade_date >= 2025.01.01 and code = `000514.SZ
'''
df = s.run(script)
df['timestamps'] = pd.to_datetime(df['timestamps'])
```
注意 select 列表里的两处对齐：`trade_time as timestamps` 和 `vol as volume`，是直接把库里的列名对齐成 Kronos 期待的字段名——数据库和模型之间的接口，本质上就是一次列名映射。然后取 400 根历史 K 线做上下文（不超过 512 的口径），向后预测 100 根：
```
lookback, pred_len = 400, 100
x_df = df.loc[:lookback-1, ['open','high','low','close','volume','amount']]
x_timestamp = df.loc[:lookback-1, 'timestamps']
y_timestamp = df.loc[lookback:lookback+pred_len-1, 'timestamps']
​
pred_df = predictor.predict(df=x_df, x_timestamp=x_timestamp,
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;y_timestamp=y_timestamp, pred_len=pred_len,
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;T=1.0, top_p=0.9, sample_count=1)
```
`T` 是采样温度，`top_p` 是核采样的概率阈值，`sample_count` 是采样轨迹数——把上一节说的蒙特卡洛多轨迹平均暴露成了参数，要稳定就把 `sample_count` 调大，代价是推理时间等比变长。返回的 DataFrame 按 `y_timestamp` 索引，六列俱全：预测出来的不只是收盘价，是一整根合成 K 线。
这个脚本有一条明写的边界：只适用于数据量小、能一次取完的场景。教程原话提醒，数据量大时一次性获取会触发数据库内存超限，需要按分区分批取数、在内存中合并，并给出了按天取数的模板。这条边界正是下一节的引子——预测只要 400 根，训练要的是上百万根，管道的难度全部藏在训练侧。
## 四、三种喂食模式：管道的三级梯度

训练对数据的需求和预测不是一个量级。教程按"数据放在哪"给出三种训练喂数方式，边界划得很清楚。
**方式一：全量进内存。** 数据量不大、单卡训练时最省事：按股票代码分批把数据全部取回内存 concat 成一张大表，一个 `FactorDataset` 类负责滑窗切样本——每个窗口做列标准化（减均值、除标准差，clip 截断），时间列拆成分钟、小时、星期几、日、月五个时间特征喂给模型。代码总共几十行，是理解整个训练流程的最好入口，也是三种方式里唯一能"一口气读完"的。它的脆也明摆着，教程自己说：1 分钟 K 线数据量极大，许多情况下内存无法支持一次性读取。
**方式二：落盘 pkl，分批读取。** 教程给出的样本配置：100 支股票、2025 全年 1 分钟 K 线，切窗后窗口总量 634,200，按 8:2 划分出训练集 510,700、验证集 123,500。这个量内存放不下、磁盘放得下，于是取数和训练解耦成两步：先按股票代码分 chunk 取数——每次取 5 支、取 20 次，每 4 个 chunk 攒 20 支股票序列化成一个 pkl 文件；训练时 dataset 按 pkl 分片惰性加载，用到哪片读哪片。
这一段的工程细节最密集，也最值得数据库侧的人细读，因为每一条都在回答"数据库怎么配合训练"：
- 取数粒度跟着分区走。按股票代码分 chunk 的前提是表按股票代码分区，一次查询命中一个分区；如果表只有日期分区，就改成按日期分批——否则每次取 5 支股票都要扫全表，管道的第一环就慢了。
- 计算压力往客户端挪。`trade_date` 和 `trade_time` 拼接时间戳这一步，教程选择在 Python 端用 Pandas 向量化完成，而不是在数据库端用函数生成——把计算压力从数据库转移到客户端，数据库只做它擅长的筛选，这是分工意识的细节。
- 序列化和合并的方式有讲究。pkl 用最高协议版本减小体积；按股票代码组织成字典、用 `update` 增量写入，而不是拼 DataFrame 再 concat——后者的合并开销在大数据量下是实打实的浪费。
- 一条只有真跑过才知道的毛边：一般 K 线数值 float32 装得下，但如果列是计算出来的大数值因子，不先转成 float64 再处理，转 float32 时会直接溢出成 inf。dataset 里的对策是把 inf 转回 nan、再用前值填充。教程把这条坑写在了正文里。

**方式三：DDBDataLoader 一体化，免落盘。** 数据连磁盘都不想落，就是这一篇之前提过的 AI DataLoader 的用武之地。安装 `dolphindb_tools` 后，`DDBDataLoader` 把"按分区切片查询 → 转成 PyTorch 张量 → 放入预取队列 → 供训练迭代"整条链路收进一个对象，内部多线程并发取数转换，客户端内存占用可控，数据量大时靠分区设置规避取数 OOM。DDP 多卡训练时，先查出全部股票代码，按 rank 均分——丢弃余数保证每张卡的股票数一致——每张卡只取自己名下的股票。
选择这种方式要接受两个"自己补"：loader 没有 `len` 实现，训练里依赖样本数的 `steps_per_epoch` 要按数据量和 batch size 自行估算，教程特别提醒估算可以略高、不能低于实际 batch 数，否则训练报错；loader 不做预处理，清洗 nan、按过去窗口归一化、clip 截断这几步，全部挪进训练循环内对每个 batch 现做。上一篇介绍 AI DataLoader 时讲的是它的定位，这一节是它落到具体案例上的完整工程形态。
三种模式的选型逻辑一句话能说完：内存装得下就不折腾；装不下先问磁盘；磁盘也不合适、或者不想多一道落盘工序，直接一体化。梯度是按数据规模排的，也是按工程复杂度排的。
![img](https://developer.qcloudimg.com/http-save/yehe-11825160/2b1ae9ac735eee671df188e82f57294e.png)
## 五、微调：让别人的模型学会你的K线

预训练权重解决的是"通用市场的语感"，自己的数据有自己的方言：品种结构不同、周期不同，甚至 K 线的维度都可能不是六列——教程专门提醒，想训练非六维的 K 线，项目自带的分词器对不上，需要自己初始化一个重训。微调因此分两步走，顺序不能乱：
先训分词器。用自己的数据把"词汇表"重新对齐到本领域的数据分布，损失函数是粗码重建加细码重建加 BSQ 量化正则，优化器 AdamW，OneCycleLR 调度，梯度裁剪——配置在教程里是全量给出的，照抄即可。维度没变的话，也可以直接加载 Hugging Face 上现成的分词器跳过这一步。
再训预测器。冻结训好的分词器，加载预训练预测器权重继续训练，损失函数换成粗、细两个子码的交叉熵，多卡用 torchrun。这一步的意义在于：分词器保证你的 K 线能被"读对"，预测器在你自己的市场语境里修正"语感"。
微调之后接什么用，Kronos 项目自己给了一个清醒的示范：官方的微调示例在 Qlib 上跑 A 股数据，微调完做 top-K 回测，README 里明确写着这是演示流程、不是生产就绪的量化系统——原始预测信号要经过组合优化和风险因子中性化才谈得上策略，回测要计入交易成本和滑点。这个免责声明值得原样转述：把模型输出直接当买卖信号，和把分词器输出直接当市场理解，是同一种天真。
门槛也要如实记下。教程的验证环境是 DolphinDB server 3.00.5（实例代码建议 3.00.4 及以上）、Python 3.12、CUDA 13.2、torch 2.11，训练章节默认多卡 torchrun；权重从 Hugging Face 下载，国内环境通常要配镜像。预测的门槛低——small 模型几百根 K 线的推理 CPU 也能跑——训练的门槛则实打实在 GPU 上。对想先低成本上手的读者，路径是明确的：第三节的预测脚本先行，第四、五节视算力逐级推进。
## 六、结尾：AI 版图的第四层

这个系列一路写下来，DolphinDB 的 AI 版图已经拼了四层。交互层是 DolphinX，让大模型和 Agent 能查数、算指标、执行分析；检索层是向量引擎与 TextDB，让语义和词法检索长在时序数据旁边；计算层是库内机器学习，特征、训练、推理在库内闭环；这一篇补上第四层——模型层：当预训练基础模型成为行业标配，数据库的职责向前延伸一段，做模型的语料库和供数引擎。
![img](https://developer.qcloudimg.com/http-save/yehe-11825160/dd62aa09afb2d169e98fa7137b06f280.png)
四层的支点都是"数据不动"，但每层的含义在递进。在检索层和计算层，数据不动是为了低延迟和口径一致；到了模型层，"不动"的含义更彻底——模型本身都可以是公用的，数据是唯一私有的资产。Kronos 把金融时序建模的门槛从"会训模型"降到"会下权重"，竞争的焦点被整个推回数据侧：谁的 K 线存得全、取得快、喂得稳，谁的基础模型就用得好。
这就是数据库在大模型时代的角色位移：从存数据的仓库，变成模型的语料库。官方教程的三种管道——进内存、落盘 pkl、一体化直连——覆盖了从单机演示到多卡训练的完整光谱，每一种的取舍都写在明处。对被"有了模型却喂数困难"卡住的团队来说，值得照着教程把三种管道各走一遍：从一条 `select` 语句供出第一批预测 K 线开始，到 DDBDataLoader 在多卡训练里稳定吐 batch 结束。模型的标准件化程度越高，数据的工程价值越大——把手里的时序数据管好、喂好，就是机构在大模型时代最实在的护城河。

这个系列上一篇的结尾有一句话：模型是标准件，管道是每家企业的手工活。当时说的是传统机器学习——模型要自己训，管道要自己搭。到了基础模型时代，前半句又掉了一截：金融时序模型连训都可以不训了。Kronos 是清华大学团队 2025 年发布、首个专门为金融 K 线预训练的开源基础模型，权重挂在 Hugging Face 上，下载即用，上线一年多在 GitHub 拿了三万八千颗星。模型成了真正的标准件，剩下的工程全部集中在管道上：K 线数据怎么存、怎么取、怎么以合适的批次和口径喂给模型。DolphinDB 官方教程给出了三种喂食方式——小数据一次进内存、中规模落盘 pkl 分批读、大规模用 DDBDataLoader 从库里直接转张量，把"给基础模型供数"这条管道做成了可照抄的工程模板。本文沿官方教程与论文的线索，从"K 线即语言"的模型架构讲起，把三种管道逐一走一遍。

当大模型学会读K线：DolphinDB × Kronos 金融时序基础模型实践

人工智能

数据库

Kronos开源金融基础模型实现“下载即用”，数据管道成核心工程。DolphinDB官方教程提供三种喂数模式：小数据全量进内存、中规模落盘pkl分批读、大规模DDBDataLoader一体化直连，覆盖预测到多卡微调全流程。模型将K线视为语言，通过离散分词与分层自回归实现高精度预测，微调分步适配私有数据，构建数据驱动的AI护城河。

机器学习

数据管道

代码解释

大数据

Python

GitHub

Agent

4核4G3M云服务器 新用户低至38元/年！

2026上云采购 | AI焕新·智启新局

ctsdb

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Kronos开源金融基础模型实现“下载即用”，数据管道成核心工程。DolphinDB官方教程提供三种喂数模式：小数据全量进内存、中规模落盘pkl分批读、大规模DDBDataLoader一体化直连，覆盖预测到多卡微调全流程。模型将K线视为语言，通过离散分词与分层自回归实现高精度预测，微调分步适配私有数据，构建数据驱动的A...

当大模型学会读K线：DolphinDB × Kronos 金融时序基础模型实践-腾讯云开发者社区-腾讯云

当大模型学会读K线：DolphinDB × Kronos 金融时序基础模型实践

当大模型学会读K线：DolphinDB × Kronos 金融时序基础模型实践

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐