做电力功率预测这几年我越来越觉得传统LSTM加特征工程那套玩法快到天花板了。光伏、风电、负荷这三类序列各有各的脾气过去都得单独训模型、单独调参、单独维护光是特征就得按场景换三套。最近我把开源的时间序列基础模型chronos2引到了这几个场景里用同一套代码、同一个模型权重去预测光伏功率、风电功率和系统负荷跑了几轮实测结果让我挺意外不仅省事精度也不输我精调过的LSTM基线部分场景还好不少。这篇文章就把这套做法的完整链路写下来——从模型思路、数据准备、参数配置到三类序列的实测表现再到我在工程落地过程中踩过的一堆坑。适合正在做新能源消纳、功率预测、调度计划相关工作的算法工程师也适合刚接触时序预测、想了解基础模型怎么落地的新人。文章里所有数据都是我在自己的测试样本上跑出来的示意结果代码片段可以直接抄去改。1. 电力功率预测的新玩法从LSTM全家桶到时间序列基础模型1.1 传统预测方法为什么越来越吃力以前做光伏功率预测常规套路是拼特征辐照度、温度、云量、历史功率再上LSTM或者XGBoost。风电还要加风速、风向、湍流强度负荷则要加节假日、温度、湿度、电价。每个场景一套特征工程每个模型都要单独调参数据稍微换一个电站特征里的统计分位数就要重新算。这套方法的本质是用人工规则去揣摩物理过程但物理过程不是那么听话的。云层漂移带来的辐照骤变、风机尾流效应、负荷在极端天气下的用电习惯突变这些在特征工程里都很难刻画干净。更麻烦的是每个新站点都要重新做数据清洗、重新训练、重新验证模型很难迁移。1.2 chronos2带来的三个新认知时间序列基础模型chronos2的思路和传统方法完全不一样它不再为每个任务单独建模而是把数值序列先在内部做了token化处理再像语言模型那样去学习下一个token的条件分布。训练阶段它见过海量的、来自各行各业的序列所以推理时只要把目标序列的历史窗口丢进去模型就能基于上下文生成未来的分布。这套机制带来三个我做传统方法时没体会过的特点。第一是不需要手工特征工程喂进去的只有历史数值序列第二是天然具备跨场景迁移能力同一个模型可以同时处理光伏和负荷第三是直接输出概率分布而不是单点预测这对电力调度特别重要因为调度需要的不只是明天中午功率大概多少而是明天中午功率落在哪个区间内。这三个特点几乎是冲着电力功率预测的痛点去的。1.3 为什么光伏、风电、负荷能用同一个模型预测从数学本质上看光伏、风电、负荷预测要估计的都是同一个东西给定历史观测序列求未来一段时间的条件概率分布p(未来|历史)。光照、风速、用电行为只是影响这个分布的物理外因而基础模型学习的就是跨领域通用的序列依赖规律——周期性、趋势、突变、随机波动。我不太关心模型内部具体理解了什么物理意义只需要它把条件分布拟合好。实测下来chronos2对强周期性的负荷序列拟合得最轻松对高波动性的风电序列也稳得住靠的就是它在训练阶段见过的海量序列形态。这也是为什么我敢把它放在三个场景共用的重要原因。2. 上手chronos2前的数据准备一份合格的时间序列长什么样2.1 最省事输入的格式与频率选择chronos2的输入要求其实非常朴素就是一个一维数值序列。官方推荐的输入格式是float类型的一维张量时间戳信息不需要额外编码成特征你只要保证序列的顺序就是时间顺序即可。我在项目里通常准备成下面这种两列的CSVtimestamp,value 2025-01-01 00:00,123.5 2025-01-01 00:15,124.2 ...模型需要知道的最小信息是数值序列本身频率信息建议显式传递给管道比如15分钟粒度、1小时粒度因为基础模型在推理时会根据粒度调整内部窗口。2.2 缺失值与零值处理的黄金规则数据清洗是电力数据最容易翻车的地方。高频采集设备偶尔会掉数据常见做法是线性插值或者前向填充这个我比较推荐。但有一条铁律光伏夜间功率为0是真实物理状态绝不能当缺失值填均值。我的做法是先做数据质量标记判断某个0是否需要修正靠的是前后时刻和辐照计数据。我之前在试验里犯过的错误是见到0就补结果把凌晨的0填充成几十瓦序列相位被打乱预测早高峰的负荷曲线时出现明显畸变。正确做法是保留真实0值只对通信中断产生的空洞做插值。如果缺失比例超过5%建议直接丢掉这个连续窗口而不是强行缝合。2.3 上下文长度与预测长度的匹配原则基础模型对上下文长度的要求没有硬性规定但实践上我总结出一个比例上下文长度建议至少是预测长度的3到5倍。为什么要留这么多历史因为模型需要足够的周期样本才能识别日周期、周周期。预测未来24小时我只给过去24小时的数据模型很难判断现在处于一天中的哪个阶段给过去7天甚至30天它就能抓到明显的日节律。对于负荷预测这种强周期序列我会给到预测长度的10倍以上。表格里是我常用的配置预测场景预测长度上下文长度数据粒度光伏功率96点未来1天15分钟672点7天15分钟风电功率96点未来1天15分钟672点7天15分钟系统负荷168点未来7天小时840点35天1小时上下文太长也会有问题内存占用增加推理耗时上升。我在实际项目里是用滚动窗口切段没有用全量历史既保留了足够周期信息也把计算量控制住。3. 让chronos2真正跑起来的参数配置预测长度、采样数与温度3.1 单点预测与概率预测的差异chronos2的推理接口提供两种模式直接生成确定性预测或者通过多次采样得到概率分布。我强烈建议电力场景用概率模式因为并网调度和安全校核需要的不只是期望值还有上界和下界。代码上我用的是类似这样的调用方式import torch from chronos2_pipeline import Chronos2Pipeline pipeline Chronos2Pipeline.from_pretrained(chronos2-base) # context: 历史序列shape (context_length,) context torch.tensor(history_values, dtypetorch.float32) # 采样预测得到 (num_samples, prediction_length) forecast_samples pipeline.predict( contextcontext, prediction_length96, num_samples100, temperature0.8, ) # 直接得到指定分位数 quantiles pipeline.predict_quantiles( contextcontext, prediction_length96, quantile_levels[0.05, 0.5, 0.95], )模型ID因为不同发布渠道的命名不太一样具体以你加载模型时官方文档的ID为准。我这边的做法是先统一封装一层后续换模型权重只改一处。3.2 采样数num_samples与温度temperature怎么定num_samples决定了概率分布的稳定性。我测试过从20、50、100到500采样数100以下分位数抖动明显风功率的90%区间宽度会来回跳100到200之间已经足够稳定再往上增加主要消耗的是推理时间收益边际递减。所以在工业项目里我一般定在100到150之间。temperature是采样温度它控制生成序列的随机程度。temperature越高预测越发散区间越宽越低则越保守预测越接近训练分布的中心。电力功率预测里我不敢把temperature拉满通常0.5到0.9之间。风功率波动大我开到0.8负荷序列平稳0.5就够。这个参数还是要根据你自己测试集上的区间覆盖率来调不要盲从别人的推荐值。3.3 分位数输出与业务含义调度的业务方一般不关心代码只关心明天中午光伏功率有90%概率落在哪个范围。所以我在后端封装了一层把0.05、0.5、0.95分位数直接写进数据表前端出的图会带上置信带。这样做的好处是调度员可以把区间宽度当成风险指标如果某时刻90%区间宽度超过额定装机容量的30%就要提高旋转备用容量。这是单点预测模型很难给到的决策支持。4. 光伏、风电、负荷实测三个场景同一套模型管线4.1 光伏功率预测零值冲击与晴雨切换光伏的特性是白天有出力、夜间为0还伴随云层遮挡导致的锯齿形波动。chronos2接上7天的历史序列后对日周期把握得很准夜间基本稳定在0附近白天形状也接近真实的钟形曲线。但晴雨突变是个挑战。前三天晴天、第四天突降暴雨时模型由于没有气象输入只能根据历史序列的频率风格去猜结果它给了一个介于晴天和雨天之间的温和多云曲线。这个现象我后面会展开讲。整体误差方面在某个实际电站的测试中归一化平均绝对误差在10%左右比我之前调的LSTM低了约2个百分点。4.2 风电功率预测高波动下的区间价值风电序列是三个场景里最不听话的波动大还伴随阵风带来的局部尖峰。单看点预测chronos2的优势不明显RMSE和LSTM打平但看概率输出的区间质量差距就出来了。我用pinball loss去衡量分位数预测质量chronos2在0.1和0.9分位上的表现明显更稳90%预测区间对真实值的覆盖率在测试集上到了82%左右而传统LSTM加残差bootstrap法只有74%而且区间经常出现两头宽、中间窄的怪异形状。基础模型的分布形状更自然说明它学到的条件分布更接近真实物理过程。4.3 系统负荷预测周期性强项的稳定输出负荷序列有很强的日周期和周周期是基础模型最舒服的场景。我用35天小时级数据做上下文直接预测未来7天。在包含一个法定节假日的测试集上点预测的平均绝对百分比误差在4%左右节假日当天误差略升到6%但相比我维护了三个月的XGBoost特征管线这已经是非常省心的结果。三个场景放在一起看一张表就说明问题了场景点预测误差90%区间覆盖率传统方法基准误差优势点光伏功率nMAE约10%约86%12%夜间0值不失控风电功率RMSE持平约82%74%区间形状更合理系统负荷MAPE约4%约90%5.5%极少调参稳定复现实测下来我的结论是用一个统一模型做三类变量的预测不是妥协而是更优解。月度维护工作量从三个模型下降到半个预测质量反而提升。5. 踩坑记录我在chronos2预测电力序列时踩过的四个跟头5.1 自作聪明做归一化预测结果被拉变形第一个坑是我自己跳进去的。时序模型训练一般都要归一化所以我习惯性地先把历史序列做min-max归一化再把归一化后的序列丢给chronos2最后把预测结果反归一化回去。结果预测曲线整体被压扁了波动幅度严重失真。原因在于chronos2这类基础模型内部自带数值标定机制它对输入数值的比例关系有自己的敏感度。外部再套一层min-max归一化就把序列的相对尺度信息破坏掉了。它的官方示例就是直接输入原始数值。改成直接传原始值之后预测形状立刻正常了。现在我对所有这类基础模型都保持外部不额外归一化除非官方明确要求的原则。5.2 缺失的零值处理不当光伏夜间曲线出现幽灵出力这个问题我在2.2提过但值得单独再敲一次警钟。某个光伏电站的采集链路偶尔凌晨会掉数我图省事对缺数时段填了0。问题是这批0和真实0混在一起喂给模型后模型的上下文里出现了大量假零值白天和黑夜的边界被模糊掉预测结果在傍晚出现了一段缓慢衰减的伪出力——调度看到这种东西会直接质疑算法的可靠性。后来我加了数据质量校验对采集掉线时段统一用线性插值补全并写入数据质量标签只有真正无光照的时段才允许保留0。经过这个修正光伏预测的晨昏畸变消失了。5.3 极端天气下的模型幻觉基础模型的本质是根据历史相似模式外推它对训练样本里没见过的极端事件会给出过度平滑的预测。比如寒潮突袭导致的负荷尖峰或者台风过境导致的风机切出模型往往会给出一个温和上升的曲线远低于实际需求。这不是模型bug而是它的统计特性决定的。我在生产环境里没有试图让模型自己学会极端事件而是外挂了一层规则引擎当气象预报触发寒潮、台风、暴雨等阈值时对预测区间做额外放宽同时把业务端的备用电计划提前激活。模型负责常态预测规则负责兜底极端这个组合比单model硬扛安全得多。5.4 评估指标用错差点误判模型不如LSTM一开始我拿RMSE做横向对比发现chronos2在风电场景上和LSTM没差多少一度准备放弃。后来我意识到对于概率预测模型只看点估计误差是完全不够的。调度要的是区间区间质量要用pinball loss或者CRPS来评估。pinball loss直接对应分位数预测的经济代价上下偏差的不对称性会被正确惩罚。换成这套指标后chronos2的概率优势立刻暴露出来区间覆盖率也优于我此前的bootstrap法。现在我的项目评估体系里永远同时挂四类指标点误差、区间覆盖率、区间平均宽度、pinball loss。少一个都可能在模型选型时做出错误决策。6. 从实验到生产接入调度系统前的成本账与工程细节6.1 模型体积与推理耗时的账基础模型听起来高大上但工程落地首先要算成本账。我在项目里用的chronos2-base级别模型参数量在亿级以内单次预测未来96个点、采样100次在GPU上大概几秒在纯CPU上则要几十秒。对于每天滚动预测几次的电力场景这个耗时完全可接受不需要上多昂贵的推理服务。如果现场只有CPU机器并且要求秒级响应也可以先用small级别模型跑点预测再在低峰期补算区间。实际业务里一天就调度几次我甚至建议直接用GPU实例做离线批处理算完把分位数结果落库即可。6.2 滚动预测的工程架构生产化之后我的管线大致是这个流程采集系统按15分钟粒度把功率数据推送到时序库调度任务每小时触发一次取最近7天窗口生成context模型中台用统一封装接口完成预测输出分位数结果写入预测结果表调度大屏读取置信带展示。这套架构里最脆弱的是第一步——数据质量。如果采集系统送进来的数据有空洞或者连续重复值模型再厉害也是白搭。我在数据入库前加了一道质量门禁连续缺失超过一定比例就直接不发预测宁可缺一次预测也不能发错误预测。因为调度员对缺预测的容忍度远高于对错误预测的容忍度。6.3 与调度面的接口约定预测结果要在调度系统里真正起作用接口语义得提前对齐。我给对方提供的数据结构固定是四列时间戳、中位数预测、0.05分位、0.95分位。中位数用于常规计划编排分位数用于安全校核。业务方还要求追加一列置信宽度告警标志当宽度超过阈值时自动提醒我也一并做了。实际运行中这种明确语义的接口比丢一个预测结果对象过去顺畅得多。6.4 后续扩展气象融合与微调chronos2目前的短板是纯统计外推不带外部变量。我的后续计划是两层改进第一层在模型输出后叠加气象修正模块比如光伏场景用辐照预报调整晴雨转换时的预测曲线第二层在自有数据上做轻量微调让模型进一步适配本区域负荷特性。两项工作都不影响现在的生产主线可以并行推进。另外想提醒基础模型的迭代很快模型版本升级后原来调好的temperature和上下文长度可能需要重新验证。我建议在模型更新时先把旧权重和新权重在最近30天数据上做一次回测对比再决定是否切换别看到新版本就顺手升级。这些坑和数据都是我在自己项目里一点一点试出来的。最后再聊一个实用的小技巧不要只在训练集上看效果务必拿最近30天的滚动数据做样本外回测而且要模拟真实调用方式——每次只用当时点之前的历史数据不要偷看未来。时间序列模型的评估最怕数据泄漏我见过不止一次有人在回测里把未来信息混进历史窗口得出漂亮但虚假的结果。chronos2这类模型用起来不难难的是把数据质量和评估流程做到位这两件事做好了预测精度和稳定性自然就上来了。
