LSTM电价预测实战：PyTorch构建24小时预测模型

简介：一套基于PyTorch与LSTM的丹麦电力电价预测项目，面向电力市场研究人员、量化分析学习者和深度学习初学者，解决未来24小时电价预测问题。项目整合历史价格、多维特征与时间序列建模，利用LSTM门控机制捕获长期依赖，并覆盖特征工程、模型设计、训练与评估全流程，可作为时序预测入门和项目实战的参考。

资源包共23个文件，压缩后约395KB。6个Python脚本承担数据分析、LSTM模型定义与训练预测；4个CSV文件提供丹麦2023年真实电价数据；另有模型权重、预测对比图和说明文档，方便直接复现核验。目前已有1030人学习下载。

该资源的价值在于形成了一套可运行、可扩展的完整方案：内置真实数据与预训练权重，可按readme快速启动，结合代码理解LSTM处理电价序列的细节；也可替换特征、调整超参数进行扩展实验，从而掌握从数据预处理到预测评估的落地思路，为后续更复杂的电力市场建模打下基础。

1. 电价预测这个需求，我用 LSTM 和 PyTorch 填上了

做能源数据的同学应该都有同感：电价预测这个需求看着简单，真正落地全是细节。手上有北欧某电力市场过去两年的历史价格和负荷数据，要在每天下午四点前给出未来 24 小时的预测曲线，误差太大就得挨批评。这篇笔记拆解的就是这样一个端到端的 LSTM 电价预测项目——从 PyTorch 模型搭建、历史特征构建到多步预测的完整代码流程。

项目核心思路不复杂：把过去 168 小时的历史电价、负荷、时间特征喂进一个两层 LSTM，一步直接输出未来 24 个价格点。难的不是模型本身，而是数据怎么对齐、标准化怎么不做错、训练时怎么不翻车。适合两类人：想找个真实时间序列项目练手的 PyTorch 开发者，以及做电力交易或能源管理、想在现有预测逻辑上做二次开发的算法工程师。

2. 项目架构设计：从原始 CSV 到 24 小时预测曲线的链路

2.1 技术选型：为什么不用 Transformer，而用 LSTM

先说结论：这个项目选 LSTM 不是因为 LSTM 比 Transformer 先进，而是因为电价序列的特性更适合它。电价有两个明显特征：一是日内周期性，早上低谷、傍晚高峰，每天重复；二是跨天滞后性，昨天的价格走势会传导到今天，前一周的同时刻也有参考价值。

LSTM 的门控结构天生擅长捕捉这种中等长度的时序依赖。遗忘门决定要不要丢掉上周同时刻的信息，输入门决定当前小时的数据值不值得记住，这种机制放到电价场景里非常自然。

对比另外两个常见选项。用 XGBoost 做点预测很强，但问题在于我们要预测 24 个连续的价点，用 XGBoost 做多步预测只能滚动递推，预测第 2 个小时的时候要用第 1 个小时的预测值当作输入，误差一层层累计，越往后越离谱。Transformer 并行性好、能捕捉长距离依赖，但对数据量要求高，两万多个样本喂给 Transformer 很容易欠拟合，而且训练时间成本比 LSTM 高一个数量级。

选 PyTorch 的理由也很实在。LSTM 的输入需要三维张量，形状是（batch, seq_len, features），PyTorch 的 Dataset 和 DataLoader 做滑窗切分非常顺手；自动求导省去手推反向传播的麻烦；训练到一半想打印某层的梯度分布，直接挂钩子就能看，调试体验比静态图好太多。

2.2 目录结构与模块职责

项目代码组织成这样，每个文件只管一件事，改起来不用满目录找：

nordic_price_forecast/ ├── config.yaml # 超参数与路径配置 ├── requirements.txt # 依赖清单 ├── data/ │ ├── raw/ # 原始CSV，按天导出 │ └── processed/ # 预处理后的特征矩阵 ├── src/ │ ├── load_data.py # 读CSV、时间对齐、去重 │ ├── build_features.py # 滞后/滚动/日历特征 │ ├── dataset.py # Dataset与DataLoader封装 │ ├── model.py # LSTM模型定义 │ ├── train.py # 训练主流程 │ └── predict.py # 预测与逆标准化 └── outputs/ ├── checkpoints/ # 模型权重 └── figures/ # 预测曲线图

核心文件的职责如下表：

这个结构照着写就行。config.yaml 里放学习率、序列长度、隐藏层维度这些超参数，换数据集时不用改代码，只改配置文件。

2.3 整体数据流：从原始数据到预测曲线要经过的四个阶段

数据流可以拆成四段，理解这条链路是后面调参的基础。

第一阶段是加载与清洗。原始 CSV 按天从电力市场公开接口导出，里面有时间戳、电价、总负荷、风电出力这些列。加载时要处理两个最基础的问题：时间戳统一转成 UTC 并按时间排序，重复的时间戳只保留最后一条，电价缺失的行用前一天同时刻填充。

第二阶段是特征与样本构建。原始价格列不能直接用，要构造滞后特征、滚动统计特征和日历特征，然后按滑窗切成训练样本。窗口长度选 168 小时，也就是整整一周，输出长度是 24 小时。这样每个样本的形状是（168, 特征数），标签形状是（24,）。

第三阶段是训练。数据先按时间顺序切成训练集、验证集、测试集三个部分，标准化器只拟合在训练集上，然后喂给 LSTM。

第四阶段是预测与回放。模型输出的是标准化后的价格，要做逆标准化还原成真实价格单位，再画一条预测曲线和真实曲线做对比，计算 MAE 和 RMSE 评估误差。

# 数据流伪代码，看这一行就能理解全流程 raw_df = load_raw_data("data/raw") # 原始价格+负荷 feat_df = build_features(raw_df, lag=[1, 24, 168]) # 滞后/滚动/日历特征 dataset = PriceDataset(feat_df, seq_len=168, horizon=24) # 滑窗样本 model = train(dataset, config.yaml) # LSTM训练 pred = predict(model, latest_window) # 未来24h曲线

这条链路里最容易出问题的就是第三阶段和第四阶段之间的标准化衔接，后面避坑章节会专门展开。

3. 数据预处理与特征工程：让模型看到价格之外的信号

3.1 数据源与加载清洗：时区、重复、缺失值一个都不能漏

原始数据长什么样？北欧电力市场的公开数据接口导出的 CSV 一般是每一行一个小时的记录点，包含时间戳、电价、总负荷、风电出力、太阳能出力几列。数据质量不算差，但也没有好到能直接投进模型。

加载时有三件事必须做对。第一是时间解析，CSV 里的时间字符串要明确指定 UTC，避免本地时区隐式转换带来的偏差。第二是排序和去重，数据接口偶尔会在同一天导出两条同样的记录，直接按时间排序后保留最后一条。第三是缺失值处理，电价偶尔会出现个别小时缺失，常见做法是用前一天同时刻的价格做前向填充。

import pandas as pd def load_raw_data(path): df = pd.read_csv(path, parse_dates=["timestamp"]) df["timestamp"] = pd.to_datetime(df["timestamp"], utc=True) df = df.sort_values("timestamp").reset_index(drop=True) # 删除重复时间戳，只保留最后一条 df = df[~df["timestamp"].duplicated(keep="last")] # 电价缺失行用前一天同时刻前向填充 df["price"] = df["price"].ffill() return df

这里前向填充用的是 ffill()，它会把缺失值替换为最近一个非缺失值。但要注意，如果连续缺失超过 3 个小时，ffill 带来的填充值会产生很长时间的平直线，反而干扰模型。稳妥的做法是先检查每个缺失块的持续时长，超过 3 小时直接删除这一段，只对短时缺失做填充。

3.2 特征构建：滞后、滚动与日历编码的组合拳

原始特征只有负荷、风电几个维度，模型要从里面自动学出周期性，效率很低。特征工程的目的就是把人类知道的领域知识显式编码进去。

滞后特征是重头戏。电价有明显的自相关性，今天下午 5 点的价格和昨天下午 5 点的价格高度相关。所以构造 lag_1、lag_2、lag_24、lag_168 四个滞后列，分别代表前一小时、前两小时、前一天同时刻、前一周同时刻的价格。模型看到这些列之后，相当于直接拿到了"昨天这个时候卖多少钱"的基准线。

滚动统计特征用来描述近期趋势。过去 24 小时的平均价格和标准差，一个代表水平，一个代表波动幅度。电价突变往往发生在一段持续上涨之后，滚动均值能抓住这种趋势信号。

日历特征解决的是周期性区分问题。工作日和周末的用电模式完全不同，工作日早晚两个高峰，周末整体偏低。如果不告诉模型现在是星期几，它就只能靠数据自己猜，容易在周五周六交界处出错。

def build_features(df, lag_list=[1, 2, 24, 168]): df = df.copy() # 滞后特征：昨天同一时刻、上周同一时刻 for lag in lag_list: df[f"lag_{lag}"] = df["price"].shift(lag) # 滚动统计：24小时窗口均值与标准差 df["roll_mean_24"] = df["price"].rolling(24).mean() df["roll_std_24"] = df["price"].rolling(24).std() # 日历特征：小时、星期、周末标记 df["hour"] = df["timestamp"].dt.hour df["weekday"] = df["timestamp"].dt.weekday df["is_weekend"] = df["weekday"].isin([5, 6]).astype(int) # 丢弃NaN开头的行 df = df.dropna().reset_index(drop=True) return df

hour 和 weekday 是数值编码。hour 的范围是 0 到 23，weekday 是 0 到 6。这里有一个细节：hour 是周期性变量，23 点和 0 点本质上是相邻的，但数值编码会让模型觉得它们差得很远。更讲究的做法是把 hour 拆成 sin 和 cos 两个分量，比如np.sin(2 * np.pi * hour / 24)和np.cos(2 * np.pi * hour / 24)，这样 23 点和 0 点在 sin-cos 空间里距离就很近。这个项目里为了控制特征维度先用数值编码，如果你追求更高精度，值得改成循环编码。

3.3 滑窗切分与标准化：训练集和测试集之间不能有信息泄漏

特征构建完之后，原始 DataFrame 要切成三份：训练集、验证集、测试集。切分只有一个原则：严格按时间顺序，不能随机打乱。时间序列和图像分类不一样，随机打乱会让模型看到"未来"的数据，训练出来的模型到真实场景基本失效。

from sklearn.preprocessing import MinMaxScaler def create_samples(feature_df, seq_len=168, horizon=24, feature_cols=None): X, y = [], [] # 窗口滑动：用过去168个点预测未来24个点 for i in range(len(feature_df) - seq_len - horizon + 1): X.append(feature_df.iloc[i:i+seq_len][feature_cols].values) y.append(feature_df.iloc[i+seq_len:i+seq_len+horizon]["price"].values) return np.array(X), np.array(y)

滑窗的起点 i 从 0 遍历到总长度减去窗口和预测长度。每个 X 样本的物理含义是"过去 168 个小时的特征矩阵"，对应的 y 是"接下来 24 个小时的电价序列"。窗口每次滑动 1 个小时，所以样本之间存在大量重叠，这是正常的，时间序列预测本来就允许重叠。

标准化是另一个容易踩坑的地方。价格列和特征列的数值范围差异很大，负荷可能是几千兆瓦，价格只有几十欧分，不归一化的话 LSTM 很难收敛。做法是用 MinMaxScaler 把特征压缩到 0 到 1 之间。关键守则是：Scaler 只能在训练集上 fit，验证集和测试集只 transform，不能重新 fit。

feature_cols = ["lag_1", "lag_2", "lag_24", "lag_168", "roll_mean_24", "roll_std_24", "hour", "weekday", "is_weekend"] scaler_feat = MinMaxScaler().fit(train_df[feature_cols]) train_feat = scaler_feat.transform(train_df[feature_cols]) val_feat = scaler_feat.transform(val_df[feature_cols])

同样的，价格列也单独要一个 scaler_price，预测结束后用 inverse_transform 还原成真实价格。如果 scaler 是在全量数据上 fit 的，验证集和测试集的标准值就已经被未来信息污染了，即使模型训练正确，评估指标也会虚高。这个坑在第一版代码里踩过一次，后面避坑章节详细说。

4. 核心代码拆解：模型定义与训练全流程

4.1 LSTM 模型：两层 LSTM 加全连接输出

模型结构不复杂，核心是双层 LSTM 加一个全连接输出头。

import torch import torch.nn as nn class LSTMPriceForecaster(nn.Module): def __init__(self, input_size=9, hidden_size=64, num_layers=2, output_size=24, dropout=0.2): super().__init__() self.lstm = nn.LSTM( input_size=input_size, hidden_size=hidden_size, num_layers=num_layers, batch_first=True, dropout=dropout ) self.fc = nn.Sequential( nn.Linear(hidden_size, 64), nn.ReLU(), nn.Dropout(dropout), nn.Linear(64, output_size) ) def forward(self, x): # x: (batch, seq_len, input_size) lstm_out, _ = self.lstm(x) # 取最后一个时间步的隐状态作为序列表示 last_hidden = lstm_out[:, -1, :] return self.fc(last_hidden)

input_size 是特征维度。前面特征工程一共构造了 lag 4 个、滚动 2 个、日历 3 个，所以是 9。如果你自己加了新特征，这个参数要同步改，config.yaml 里配置好就不会漏。

hidden_size 代表 LSTM 隐状态向量的维度，取 64 是平衡了表达能力和训练速度。num_layers 是 2 层，层数越多能捕捉的抽象层级越深，但训练难度和过拟合风险也越大，两到三层是电价预测场景里的常见选择。

forward 里最关键的一步是取最后一个时间步的输出。输入的 168 个时间步经过两层 LSTM 之后，每个时间步都有一个隐状态输出，但预测未来 24 小时只需要一个向量来代表整个序列的信息。lstm_out[:, -1, :] 就是最后一个时间步的隐状态，可以理解成模型把 168 个小时的信息"压缩"成了一个 64 维向量，再由全连接层扩展成 24 个价格点。

这个设计在一定程度上避免了多步预测的误差累积问题。如果用单步递推，预测第 2 个小时得把第 1 个小时的预测值重新喂回模型，误差会像滚雪球一样越来越大。直接输出 24 个值，每个价点之间是并行关系，模型自己学习它们之间的协同性。

4.2 训练循环：MSE 损失、Adam 优化器与梯度裁剪

训练循环是标准的 PyTorch 流程，但有三处针对 LSTM 的特殊处理。

def train_model(model, train_loader, val_loader, epochs=30, lr=1e-3): device = torch.device("cuda" if torch.cuda.is_available() else "cpu") model.to(device) criterion = nn.MSELoss() optimizer = torch.optim.Adam(model.parameters(), lr=lr) scheduler = torch.optim.lr_scheduler.ReduceLROnPlateau(optimizer, mode="min", factor=0.5, patience=3) for epoch in range(epochs): model.train() train_loss = 0.0 for x_batch, y_batch in train_loader: x_batch, y_batch = x_batch.to(device), y_batch.to(device) optimizer.zero_grad() pred = model(x_batch) loss = criterion(pred, y_batch) loss.backward() # 梯度裁剪：防止LSTM长序列训练中梯度爆炸 torch.nn.utils.clip_grad_norm_(model.parameters(), max_norm=1.0) optimizer.step() train_loss += loss.item() val_loss = evaluate(model, val_loader, criterion, device) scheduler.step(val_loss) print(f"epoch {epoch+1:02d} | train_loss {train_loss/len(train_loader):.4f} | val_loss {val_loss:.4f}") return model

损失函数用 MSE，电价的偏差会被平方放大，所以模型会更用力去拟合那些偏离较大的尖峰时段，这正是交易最关心的部分。

梯度裁剪专门针对 LSTM 的隐患。序列长度 168 意味着反向传播要穿过 168 个时间步，梯度在长路径上连乘之后很容易指数级增长，轻则训练不稳定，重则 loss 直接变成 NaN。clip_grad_norm_把所有参数的梯度向量的 L2 范数裁剪到不超过 1.0，相当于给梯度加了一个安全上限。这个技巧在普通 CNN 分类任务里可有可无，但在 LSTM 时间序列里是救命稻草。

学习率调度用的 ReduceLROnPlateau，验证集 loss 连续 3 个 epoch 不下降就减半学习率。初始学习率 1e-3 是 Adam 的推荐值，对几十兆参数量的模型是够用的。

4.3 预测与逆标准化：把模型的输出还原成真实电价

训练完成后，预测模块要做两件事：用最新 168 个小时的窗口做前向推理，再把标准化后的预测值还原成真实电价。

def predict_future(model, latest_window, scaler_price, seq_len=168): model.eval() with torch.no_grad(): # latest_window: (seq_len, n_features)，补一个batch维度 x = torch.tensor(latest_window, dtype=torch.float32).unsqueeze(0) pred_norm = model(x).cpu().numpy().reshape(-1, 1) # 逆标准化得到真实电价 pred = scaler_price.inverse_transform(pred_norm).flatten() return pred

predict 时强制 model.eval() 和 torch.no_grad()，目的分别是关闭 Dropout 随机丢弃和关闭梯度追踪，保证预测结果的确定性。unsqueeze(0)把形状从（168, 9）变成（1, 168, 9），补上一个 batch 维度，因为模型的输入要求是三维张量。

逆标准化要用训练时那个 scaler_price，不是重新 fit 一个。这里的常见错误是有人看到预测值都在 0 到 1 之间，觉得不对劲，顺手再 fit 一次 scaler 去还原，这样出来的数值单位是对的但偏差很大。正确做法是把训练时保存好的 scaler_price 通过 pickle 序列化到磁盘，预测阶段加载同一个对象。

4.4 评估指标：MAE、RMSE 和真实误差的解读

评估指标在时间序列预测里是必须做的。不能只看 loss 曲线，要额外计算 MAE 和 RMSE 两个指标，单位是原始价格单位。

def evaluate_metrics(y_true, y_pred): mae = np.mean(np.abs(y_true - y_pred)) rmse = np.sqrt(np.mean((y_true - y_pred) ** 2)) return mae, rmse

RMSE 对个别离群点更敏感，如果某一天电价出现极大的尖峰没预测准，RMSE 会被拉得很难看，这时候可以从 MAE 确认大部分时段的平均偏差。这组指标每跑完一次实验记下来，无论是调参还是换特征，都拿它来对比。我一般把一个基准模型跑完所有记录再开始迭代。

5. 避坑指南：LSTM 电价预测里的五个翻车现场

5.1 数据泄漏：验证集表现虚高，上线就废

现象：验证集预测曲线和真实曲线贴合得完美，部署上线跑第一天的预测，偏差肉眼可见地大。

原因：对全部数据做了标准化之后再切分，scaler 在 fit 的时候翻看了未来的价格区间，模型在训练时就间接接触了"答案"。这也包括 MinMaxScaler 的 min 和 max 本身携带了全量数据的信息。

解决：切分训练集和测试集之后，scaler 只在训练集上 fit，验证集和测试集只调用 transform。检查代码里是否存在对全量数据先 fit 后切分的顺序问题。

5.2 滑窗错位：预测曲线整体滞后一天

现象：训练 loss 很低，但把预测曲线和真实曲线叠在一起看，发现预测的峰值位置比真实峰值晚了整整一个周期。

原因：滑动窗口的数据对齐写错了。比如用 168 小时窗口时，把窗口末尾的最后一个数据点当作当前时刻，但那个点本身还没收盘，属于当前预测周期的内部数据，相当于把未来信息当作输入的一部分。

解决：严格保证窗口内的最后一行是预测起始时刻之前的数据。标注样本时用df.index[i + seq_len]作为未来第一个时间点，窗口区间为左闭右开，不含未来值。建议写一个断言函数，检查每个样本的窗口最大时间戳小于标签的最小时间戳。

5.3 梯度爆炸：loss 训练到一半变成 NaN

现象：前几个 epoch 的 loss 正常下降，到第五六个 epoch 突然变成 NaN，一行警告接着训练终止。

原因：LSTM 的 BPTT 反向传播路径长度等于序列长度，梯度过 long 路径连乘之后数值溢出，权重更新一步跨出可控范围。

解决：在 loss.backward() 和 optimizer.step() 之间加梯度裁剪，torch.nn.utils.clip_grad_norm_(model.parameters(), max_norm=1.0)。如果崩溃发生在某个特定的 epoch，可以考虑降低初始学习率到 3e-4 配合裁剪使用。

5.4 预测曲线是一条水平线：模型没学到周期性

现象：预测结果几乎是一条平直的线，所有输出值都在均值附近，曲线的峰谷完全消失。

原因：日历特征缺失。模型无法区分工作日和周末，也没有小时信息，面对一个周期性很强的序列，最优策略就是预测平均值，因为平均值的平方误差最小。特征维度不够的典型表现。

解决：把 hour、weekday、is_weekend 加进特征矩阵，并确认 build_features 生成的日历特征列和时间戳能正确对齐。如果还是平直线，检查是不是每个 batch 里的样本顺序乱掉了，导致模型学不到时间一致性。

5.5 多步预测后半段误差放大

现象：单步预测误差在一个合理范围，但 24 步预测里，第 18 到第 24 个小时的误差明显比前 6 个小时大。

原因：如果采用递推预测策略，也就是把预测出来的第 1 个小时作为输入去预测第 2 个小时，误差会随时间步逐渐累积。

解决：改用 direct multi-output 策略，就是 4.1 节设计的模型结构，一次输出 24 个点，不递推。训练时标签形状是（batch, 24），预测时直接得到整条曲线，步与步之间没有信息传递，误差自然不会被放大。

6. 二次开发思路：让模型跑在别的市场

6.1 换数据源：调整特征列和标准化器

不同电力市场的公开数据差异主要在字段命名和价格单位上。换到其他市场，第一步是检查原始 CSV 的字段名，把 load_data.py 里的列名映射改成目标市场的实际字段。价格单位如果从欧元改成当地货币，scaler_price 会自动处理范围，不用手动改。重点检查时间戳时区，北欧市场用欧洲中部时间，有些数据源会混进本地时区，加载后统一转 UTC，排序时才不会出现时间倒流。

6.2 增加天气和节假日特征

电价和气温强相关，尤其是制冷和供暖需求集中的地区。常见做法是引入目标区域的平均气温、风速、云量三个特征。气温影响基础负荷，风速影响风电出力，云量影响太阳能。这些数据可以从气象公开接口按小时拉取，然后按时间戳 merge 进主表。节假日特征建议用一个日历文件手工标注，把法定节假日标为 1、普通工作日标为 0，因为节假日模式通常和周末类似但又有差别，模型自己很难学到。

新增特征之后要留意 input_size 参数。特征矩阵多了三列，LSTM 第一层的 input_size 从 9 变成 12，单独改 model.py 里的默认值是治标不治本，把 config.yaml 里的特征列表和维护的维度对应起来才是正路。

6.3 试试注意力机制

如果预测精度卡在一个瓶颈上不去，可以考虑给 LSTM 的输出接一层简单的注意力。常见做法是把所有时间步的隐状态加权求和，而不是只取最后一个，权重由模型学出来。这能帮你直观看到模型到底关注哪些历史时刻，解释性也更好。加在项目里不算难，PyTorch 的 GRU 输出拿outputs所有时间步，用一个小全连接层算权重，再和隐状态做加权平均，改动量大约三四十行代码。

这个项目我从数据清洗到模型上线前后改了五六轮，最重要的教训是：先守住数据边界再调模型结构。某次我在测试集上反复调参把 RMSE 降了百分之十几，后来发现是对测试集做了滑动窗口去重，信息泄漏让结果虚高。从那以后，我每次做时间序列实验，都会强制走一遍数据泄漏自查清单——标准化是否只 fit 训练集、滑窗是否有未来数据混入、验证集是否严格在时间轴上位于训练集之后。这个清单希望也能帮到你。

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