PyTorch复现Basisformer：锂电池SOC预测与部署实践-北京尧图网络

做电池系统的人应该都有这种体验同一块电池静置两小时测出来的开路电压能查表查到SOC可一旦进入动态工况电压曲线和SOC之间就没有那么强的对应关系了。和做BMS的同事聊起来大家普遍觉得最烦的部分就是SOCState of Charge荷电状态估计——安时积分越跑越偏等效电路模型参数随温度、老化飘得厉害。这两年数据驱动方法被反复讨论其中时间序列预测模型是最主流的路线之一。我最近基于PyTorch复现了Basisformer用它做锂离子电池SOC预测把一段工况的电压、电流、温度喂进去直接输出未来一段窗口的SOC。实测下来这套方案比同规模的LSTM和Transformer稳而且模型参数少得多。本文把整个复现过程和数据踩坑经验整理出来包括模型原理、核心代码、训练细节和部署思路给同样在纠结用什么模型做SOC估计的朋友一个参考。1. 先搞清楚SOC估计为什么是电池管理系统里最麻烦的事1.1 SOC的定义与工程上的真实痛点SOC的数学定义很简单剩余可用容量占额定容量的百分比SOC Q剩 / Q额定 × 100%。但工程上的麻烦在于这个量没法直接测只能靠其他可测量量电压、电流、温度去推断。而电池本身是一个强非线性、强时变的电化学系统同样一组电压电流数据在不同温度、不同老化阶段、不同充放电倍率下对应的SOC可能差出好几个百分点。更烦的是电池还有滞回特性。磷酸铁锂的电压平台很平SOC从20%到80%之间电压可能只变了零点几伏你用查表法根本分不清当前到底在哪个点。三元锂稍微好一点但动态工况下内阻极化一叠加电压和SOC的映射关系也跟着变。这些因素叠加起来导致SOC误差会直接影响续航显示、充电策略、均衡策略和安全保护。我做项目时见过一种典型场景电池包用了一年满充容量下降了10%如果BMS还按出厂容量做安时积分显示的SOC就会逐渐偏离真实值最后用户觉得续航虚标甚至可能触发误保护。所以SOC估计不仅要准还得有一定的自适应性。1.2 传统方法为什么越来越不够用工程上用得最多的还是三类传统方法安时积分法对电流积分累加简单直接但电流采样噪声、库仑效率、初始SOC误差都会累积时间越长越漂移。而且它本质上是个开环方法没有任何校正机制。开路电压查表法需要电池静置足够长的时间让电压回稳在线场景基本用不了只能作为校准手段。等效电路模型卡尔曼滤波这是目前BMS的主流方案。通过RC网络拟合电池动态特性再用扩展卡尔曼滤波EKF递推估计SOC。问题是RC参数会随温度、SOC、老化状态漂移你需要做大量的参数辨识实验而且模型一复杂计算量上来嵌入式跑起来并不轻松。这些方法不是不能用而是标定成本高、适应性弱。尤其面对动态工况比如电动车频繁加减速、快充快放传统模型的预测误差会明显放大。1.3 数据驱动方法为什么这两年被反复讨论数据驱动路线的思路很简单既然电压、电流、温度的历史序列里实际上包含了SOC演化的信息那就让模型直接学这个映射关系。过去大家用LSTM、GRU这一类循环网络效果比传统方法好不少但存在两个问题一是循环网络的长程记忆能力有限输入窗口一旦拉长早期信息容易衰减二是训练序列必须逐个时间步走并行性差。后来Transformer进入时间序列领域自注意力机制能全局建模长程依赖但注意力机制的复杂度是序列长度的平方电池SOC这种动辄几千上万步的工况数据训练和推理成本都不低。而且电池数据本身噪声不小直接套Transformer容易学到局部扰动泛化能力反而一般。这也是我转去尝试Basisformer的直接原因——它走的完全是另一条路不在两两时间步之间算注意力而是把时间序列分解成少数几个基函数的加权组合。这个思路对于电池这种有明显周期性和平滑趋势的信号来说非常对路。2. Basisformer的核心思路从注意长序列到分解长序列2.1 为什么Transformer在超长电池时序上不划算Transformer的时间复杂度是O(L²)L是输入序列长度。如果你想用足够长的历史窗口去推断SOC这种慢变量L很容易到几百甚至上千训练一步的成本会变得很高。更实际的问题是注意力矩阵里大部分权重其实集中在少数几个关键位置剩下大量计算都浪费了。电池工况序列又存在明显的自我相似特性——充放电循环反复出现如果用注意力去建模很多头的关注点高度重叠。我在复现LSTM和Transformer做SOC估计时一个直观感受是模型确实能拟合训练集但验证集上的误差主要由少数突发工况段贡献。原因很简单基于注意力的模型本质上是在学哪一段历史和当前最相关但电池SOC演化是一个连续的物理过程它更依赖的是长期趋势和低频周期而不是某一个时刻的局部关系。2.2 傅里叶视角下的电池工况信号如果你把一段完整的电池充放电工况画出来看会非常明显地看到几个特征电压、电流、温度曲线整体是平滑的不存在大量高频振荡充放电循环对应着固定的周期成分电池老化会让电压平台的振幅缓慢变化属于典型的非平稳信号SOC本身是一条单调性较强的趋势线加了一些小幅波动。这组特征和Basisformer的设计假设几乎完全重合它假设未来序列可以由过去序列的一组基函数加权组合得到。你可以把它理解成一个带外推能力的傅里叶分解——不是简单地把历史信号分解成三角级数而是把历史信号里的主导周期成分提取出来生成一组基函数再用这组基函数去组合出未来的走向。2.3 Basisformer的四步预测管线Basisformer的预测管线可以拆成四步序列分解。用滑动平均把输入序列分成趋势项和季节项。趋势项代表信号整体走向季节项代表围绕趋势的周期波动。这一步和很多时间序列模型的做法一致核心作用是把宏观趋势和周期成分分开建模避免相互干扰。傅里叶分析频率选择。对季节项做离散傅里叶变换得到振幅谱然后选出k个振幅最大的主导频率。这一步是为了过滤掉噪声频率和无关高频成分只保留最能刻画电池工况周期性的一部分频率。原论文用的是分层Top-K策略大意是把频率分成若干组每组内再选代表避免所有被选中的频率都堆在低频区。我复现时先用了简化版全局Top-K效果已经不错后面再细说分层策略。基函数构建与指数衰减。对选出的每个频率生成一对正弦和余弦基函数并且用一个可学习的指数衰减项去调制基函数振幅。这一步非常关键——电池信号是非平稳的相同频率的振幅会随时间变化比如老化后内阻变大充放电电压平台的振幅跟着变指数衰减恰好能把这种振幅演化趋势编码进基函数里。系数投影与合成。把历史季节项投影到基函数上得到每个基函数的权重系数再用这些系数把基函数线性加权合成未来的季节项。趋势项则用简单的线性层单独预测最后两者相加得到完整预测。整个模型没有用自注意力机制复杂度降到了线性。更实际的好处是基函数一旦构建好预测步骤本质上就是矩阵乘法和线性层非常容易被量化部署。2.4 它凭什么适合SOC估计我对比了同一份电池工况数据上三种模型的实验效果大致可以归纳成下表对比维度LSTMTransformerBasisformer长窗口依赖弱信息衰减快强但计算贵强靠基函数覆盖全局计算复杂度O(L)串行O(L²)并行O(kL kT)并行对周期性信号的拟合一般一般强对非平稳振幅的建模靠隐状态硬学靠注意力硬学指数衰减显式建模在小样本工况上过拟合程度中等高低部署友好度中等差好这个对比不是要说明Basisformer在所有场景都能秒杀其他模型。我遇到过一些数据本身噪声大、周期性弱的工况Basisformer的优势会被削弱。但至少对于标准充放电工况、循环老化测试这类电池数据它的假设是切中要害的。3. 数据预处理SOC估计这活儿七分在数据三分在模型3.1 特征选择与归一化输入特征我用的是电压、电流、温度三个可测量量目标值是SOC。公开的电池老化测试数据一般都能提供这几种物理量不需要额外制造特征。有个容易被忽略的细节要不要把上一时刻的SOC也作为输入特征。我的建议是如果做的是多步预测不要在当前输入窗口里混入未来的SOC标签否则会造成严重的数据泄漏训练时指标漂亮部署时完全失效。如果只做当前时刻的SOC估计可以用上一时刻SOC作为自回归输入但要明确把它当成一个会被估计误差污染的特征来对待不要过度依赖。归一化我统一用z-score每个特征单独做统计量只从训练集计算。使用z-score而不是min-max的原因是电池数据里偶尔会出现电压尖峰或电流脉冲min-max会把大部分正常数据压缩到一个小范围内影响模型对中间区域的区分度。3.2 滑窗长度和预测长度的确定SOC是一个慢变量窗口长度太短模型看不到完整的充放电周期无法推断出当前处于哪个SOC区间。窗口太长又会引入太多无关历史训练成本上升。我在复现实验里验证过的经验值输入窗口256步左右预测窗口16步左右采样间隔按0.1秒到1秒算这相当于用最近几分钟到十几分钟的历史去预测未来一小段SOC变化。这个参数组合兼顾了信息量和计算成本。预测长度不宜设太长。SOC演化速率受充放电倍率影响很大预测窗口拉长到几十步之后误差会显著放大。如果你要的是当前SOC是多少完全可以设pred_len1把模型当成一个时间序列回归器来用如果要做短时趋势外推pred_len8-16是比较稳妥的范围。3.3 最容易翻车的划分方式一定要按电芯切数据这是我复现过程中踩过最大的坑必须单独拿出来说。SOC估计数据集天然是多元时间序列同一个电池的连续工况数据内部高度相关。很多初学者会把所有电池的数据拼在一起然后随机抽取窗口划分训练集和验证集这个做法几乎必然导致数据泄漏。原因很直接随机划分之后训练集和验证集里会存在大量来自同一个电池、时间上相邻甚至重叠的窗口。模型等于提前见过了验证集所在工况段验证集指标自然虚高。等你真把模型部署到一块从未出现过的电池上误差立刻反弹。正确做法是按电池单元划分比如有10块电池的完整工况数据用其中7块的完整数据做训练2块做验证留1块做最终测试。这样测试集里的电池是整个训练过程中完全没见过的评估结果才接近真实部署场景。我在标准老化测试集上按这个方式划分后验证集MAE比随机划分高了不少但那个数据才真正反映了模型的泛化能力。3.4 工况筛选与数据增强经验纯实验室数据往往只有标准恒流恒压充放电和固定倍率工况真实场景更复杂。如果手头数据允许建议把不同倍率、不同温度下的工况都放进去让模型见过足够多样的电流-温度-SOC组合。数据量不足时可以做一些基础增强比如对电流序列做小幅缩放、对温度序列加少量高斯噪声模拟不同环境下采样误差。我试过在原始数据上叠加±1%的电流噪声训练模型对传感器噪声的鲁棒性确有提升。但不建议做太强的扰动否则会破坏电压电流之间的物理一致性。4. 用PyTorch搭建一个可跑通的Basisformer4.1 环境与依赖代码基于PyTorch 2.x依赖numpy、pandas、scikit-learn。我的实验在单张显卡上跑其实这个模型规模不大CPU也能完成训练只是慢一些。复现前先固定随机种子保证实验结果可重复。4.2 序列分解模块Basisformer的第一步是序列分解用滑动平均分离趋势项和季节项。我给一个可直接使用的实现import torch import torch.nn as nn import torch.nn.functional as F import torch.fft as fft class SeriesDecomp(nn.Module): def __init__(self, kernel_size: int 25): super().__init__() self.kernel_size kernel_size self.pool nn.AvgPool1d(kernel_sizekernel_size, stride1, padding0) def forward(self, x: torch.Tensor) - tuple: # x: [batch, seq_len, feat_dim] x_t x.transpose(1, 2) # [batch, feat_dim, seq_len] x_pad F.pad(x_t, (self.kernel_size - 1, 0), modereplicate) trend self.pool(x_pad).transpose(1, 2) # [batch, seq_len, feat_dim] season x - trend return trend, season滑动平均的kernel_size直接影响趋势项的平滑程度。kernel太小趋势项里还残留周期成分分解不彻底kernel太大趋势项对近期变化反应迟钝预测末尾段时误差变大。我的经验是kernel设为输入长度的十分之一左右比如seq_len256时取25。4.3 基函数预测模块这一部分是模型核心。简化实现里我用全局Top-K选频率用可学习线性层把历史季节项投影成基函数系数再和带指数衰减的基函数矩阵相乘得到预测class BasisLayer(nn.Module): def __init__(self, seq_len: int 256, pred_len: int 16, k: int 8, use_decay: bool True): super().__init__() self.seq_len seq_len self.pred_len pred_len self.k k self.use_decay use_decay # 历史季节项 - 基函数系数 self.proj nn.Linear(seq_len, 2 * k) if use_decay: self.alpha nn.Parameter(torch.rand(k) 0.5) def forward(self, season: torch.Tensor) - torch.Tensor: # season: [batch, seq_len, feat_dim] B, L, D season.shape # 1) 逐特征做DFT取振幅谱按批次平均选Top-K频率 amp fft.rfft(season, dim1).abs().mean(dim0).mean(dim-1) top_idx torch.topk(amp, self.k).indices # [k] freqs top_idx.float() / L # 2) 构造正弦余弦基函数矩阵 [2k, pred_len] t torch.arange(self.pred_len, deviceseason.device).float() basis_cos torch.cos(2 * torch.pi * freqs[:, None] * t[None, :]) # [k, T] basis_sin torch.sin(2 * torch.pi * freqs[:, None] * t[None, :]) # [k, T] basis torch.stack([basis_cos, basis_sin], dim-1) basis basis.reshape(self.k, self.pred_len * 2).transpose(1, 0) # [2k, T] # 3) 指数衰减调制 if self.use_decay: alpha torch.clamp(self.alpha, min1e-3) decay torch.exp(-alpha[:, None] * t[None, :]) # [k, T] decay decay.repeat_interleave(2, dim-1).transpose(1, 0) # [2k, T] basis basis * decay # 4) 归一化并投影 basis basis / (torch.norm(basis, dim1, keepdimTrue) 1e-6) coef self.proj(season.transpose(1, 2)) # [B, D, 2k] pred torch.matmul(coef, basis) # [B, D, T] return pred.transpose(1, 2)这里有两个和原论文不一致的简化点先说明清楚第一原论文用的是分层Top-K选频策略我这里先用了全局振幅Top-K代码更短适合做基线第二原论文的系数投影更复杂包含额外的投影分解模块我这里直接用线性层替代。如果你要做完整复现建议在选频和投影两部分再往原论文靠拢。4.4 模型组装与训练循环把趋势预测和季节预测拼起来就是完整模型。趋势项对每个特征单独做线性外推相当于把当前趋势方向平推出去这比直接用最后几个值去复制要稳定class Basisformer(nn.Module): def __init__(self, seq_len: int 256, pred_len: int 16, in_features: int 3, k: int 8, kernel_size: int 25): super().__init__() self.seq_len seq_len self.pred_len pred_len self.decomp SeriesDecomp(kernel_size) self.basis_layer BasisLayer(seq_len, pred_len, k) self.trend_proj nn.Linear(seq_len, pred_len) self.fuse nn.Sequential( nn.Linear(2 * in_features, 64), nn.GELU(), nn.Linear(64, in_features) ) def forward(self, x: torch.Tensor) - torch.Tensor: trend, season self.decomp(x) trend_pred self.trend_proj(trend.transpose(1, 2)).transpose(1, 2) season_pred self.basis_layer(season) out torch.cat([trend_pred, season_pred], dim-1) return self.fuse(out)训练循环我用最标准的写法Adam优化器初始学习率1e-3配合余弦退火调度损失函数用MSE。batch_size取32跑80到120个epoch加了早停验证集loss连续10个epoch不下降就停。数据加载直接用PyTorch的Dataset和DataLoader实现滑窗生成样本时注意按电池单元切好训练集和验证集再做窗口化顺序不能反。4.5 训练中容易被忽视的超参数k值基函数数量一般取4-16。k太小模型表达能力不足预测曲线过于平滑k太大容易把噪声频率也选进来出现过拟合。我在电池数据上取8比较稳。指数衰减的初始值alpha初始在0.5-1.5之间比较合理。如果初始太大基函数在预测窗口后半段会被压得几乎为零模型退化成一阶外推如果太小又体现不出振幅衰减的调节能力。kernel_size前面提过取输入长度的十分之一左右是个安全的起点再根据验证集loss微调。5. 训练、评估与一次真实的翻车排查5.1 训练配置与评价指标SOC估计的评估指标我习惯看三个MAE平均绝对误差、RMSE均方根误差和MAPE平均绝对百分比误差。其中MAPE要注意一个问题SOC接近0和接近100时很小的绝对误差也会造成很大的百分比误差所以看MAPE时要结合SOC区间分析不能只盯一个数。训练过程的日志至少记录每个epoch的训练loss和验证loss确认没有明显的过拟合趋势。我一般会顺手把验证集上每隔10个epoch的预测结果存下来方便后续可视化对比。5.2 可视化从三条曲线看出模型是否真的学会了训练完先别急着看指标画三张图排查模型行为完整时间线上的SOC真值与预测对比看整体跟随情况确认没有明显的相位滞后。一段典型充放电循环内的细节对比看波形细节确认模型不是只学了趋势的平均形状。误差随SOC区间的分布判断模型在哪个SOC区间系统性偏差大。我第一次跑通时整体MAE只有1.8%左右看起来很漂亮但画出误差随SOC区间分布后发现模型在中段SOC区间误差很小在低SOC和高SOC区间误差明显偏大。后来分析原因是训练数据里低SOC和高SOC区间样本占比少模型见得少自然拟合差。解决方法是增加这些区间的采样权重而不是盲目调模型结构。5.3 一次预测值像直线的排查过程我手头有一次复现实验翻车的过程特别典型。训练过程loss正常下降验证集MAE也不差但把预测曲线拉出来一看SOC几乎是一条水平直线完全没有跟随真实曲线变化。当时排查链路是这样的第一件事确认输入数据本身有没有问题。打印一个batch的电压、电流、温度窗口发现数值都在正常范围内窗口内也有明显的波动数据没毛病。第二件事怀疑归一化出问题。检查训练集和验证集的归一化统计量发现验证集用的是训练集的均值和方差没混进验证集信息也没问题。第三件事打印模型中间输出。把趋势预测项和季节预测项拆开看发现趋势预测项几乎占据了最终输出的全部季节预测项贡献接近于零而且趋势预测项被外推成了未来一段基本不变。问题定位到这里就清楚了——模型发现用最简单的趋势平推就能在训练集上拿到不错的loss于是走捷径了。核心原因是我的预测窗口相对于SOC变化率来说太长而输入特征里又没有显式表达当前是充电还是放电或目前SOC大致在哪的信息模型在多个方向互相抵消的情况下学会了输出均值。后来做两个改动预测窗口从16缩到8输入特征里加上一阶差分项让模型能直接看到电压电流的变化方向。改完之后预测曲线立刻恢复了正常的跟随性。5.4 常见问题速查表现象可能原因处理方式训练loss不降学习率过大或过小先在1e-4到1e-2区间扫一遍初始lr验证集好、测试集差按时间滑窗随机划分导致数据泄漏改成按电池单元划分预测曲线是直线趋势项占主导季节项贡献为0缩小预测窗口加入差分特征高SOC/低SOC区间误差大极端区间样本少分区采样或加权预测值整体滞后滑动平均kernel过大调小kernel_size开启指数衰减后预测更差alpha初值过大把alpha初始值降到0.5附近6. 从实验到落地轻量化部署与几点个人体会6.1 参数量和推理速度实测Basisformer不含自注意力参数量非常可控。以我复现的配置seq_len256pred_len16k8特征数3统计总参数量在3万到5万之间PyTorch默认FP32权重文件大约一两百KB。同尺寸的Transformer光是一个注意力头加位置编码就会逼近这个量级堆三四层的话参数数量至少是它的5到10倍。推理速度方面在普通CPU上单条窗口的推理时间在几毫秒量级如果用BMS主控芯片的定点运算跑INT8版本还能再快一个数量级。这个性能对实时性要求较高的SOC估计场景是够用的。6.2 ONNX导出与量化思路如果要把模型部署到边缘设备第一步是导出ONNX摆脱PyTorch运行时依赖。导出时注意把动态维度固定下来嵌入式推理框架对动态shape支持参差不齐固定成静态shape12563更稳妥。量化是必须做的一步。模型结构里主要是线性层和矩阵乘法对量化非常友好。我试过两种方案# 动态量化示例 model.eval() model_int8 torch.quantization.quantize_dynamic(model, {torch.nn.Linear}, dtypetorch.qint8)动态量化实现起来最省事无需校准数据精度损失在SOC估计任务上通常可以控制在0.5%以内。如果要进一步压内存可以考虑静态量化但需要收集一批代表性工况数据做校准校准集的覆盖度会直接影响量化后的精度。6.3 边缘端部署的注意点部署阶段最容易忽视的是输入窗口的管理。PC端实验时我们直接把整个时间序列切成窗口送进模型但嵌入式设备上是流式数据需要自己维护一个滚动窗口缓冲区每来一个新采样点把最旧的点丢掉再把新点拼进去。这个缓冲区的更新逻辑虽然简单但容易在时序边界上出问题尤其需要注意窗口首尾的数据拼接顺序。另一个注意点是数值范围。模型训练时输入是z-score归一化后的值部署时必须把同样的均值和方差以常数形式烧进设备端代码不能依赖训练时保存的Python对象。6.4 几句题外话最后聊一点个人体会。Basisformer这类分解基函数的思路天然适合电池这种有物理规律、周期性明显、趋势平滑的信号。相比之下它在随机性极强的数据上优势就不明显。所以选型之前建议先把自己手上的工况数据画出来看看如果能看到清晰的周期和趋势Basisformer值得一试如果信号完全杂乱那可能还是Transformer或集成方法更合适。另外模型结构再先进也挡不住数据划分和特征工程上的疏忽。我见过太多项目在SOC估计上翻车最后排查下来不是模型的问题而是泄漏、归一化错误或者工况覆盖不足。先把数据基础打好再谈模型精度这句话放在SOC估计这个领域什么时候都不过时。

PyTorch复现Basisformer：锂电池SOC预测与部署实践

相关推荐

AIGC内容工业化实操指南：AI漫剧与短视频生产变现全流程

pixhawk_v4驱动安装与刷写环境搭建：从串口权限到pymavlink验证

AI原生时代一人公司如何通过复利工程实现指数增长

更多资讯

Superpowers插件实战指南：批量处理与自动化工作流效率提升

VS2015配置OpenCV3.4.16实战：ABI兼容性与运行时库匹配详解

开源代码审查工作流：CLI+Git+本地LLM的可追溯审查实践

C# Excel 操作实战：读取、保存与格式处理完整实例

CLI驱动的代码评审新范式：Git Diff+LLM Agent工作流

OpenVINO车牌识别实战：CPU环境下深度学习推理与模型部署全解析

今日更新

悟空开源无代码平台实战：从实体建模到应用设计避坑指南

基于.NET9的多租户权限系统：数据权限与动态API落地实践

场地预约小程序毕设实战：SSM+微信小程序+MySQL数据库设计到避坑

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？