激励型需求响应负荷转移策略的Matlab+Cplex建模与工程实现

手里的负荷曲线越来越“尖锐”——白天尖峰顶到天花板，夜间低谷几乎贴地。调度那边催着要削峰填谷方案，你第一个想到的是什么？我最先想到的是：把一部分高峰时段的用电挪到低谷时段去。这件事放在需求响应的体系里，如果依靠给用户发激励补偿来引导，而不是靠实时电价波动自然吸引，那就属于典型的“激励型需求响应”。这篇文章就用Matlab做建模和数据处理，用Cplex做底层混合整数规划的求解器，完整拆解一套负荷转移策略从模型设计到落地的全过程。

要说清楚的是，这个主题不是单纯的数学题，也不是MATLAB的炫技。它解决的问题很具体：在用户愿意配合调整用电行为的前提下，电网或者负荷聚合商怎么设计激励价格、怎么决定每个时段转移多少负荷，才能既削了峰谷差，又让用户拿到合理的补偿，同时企业和用户两边都算得过账。整体适合电力系统专业的学生、做需求响应项目的算法工程师，以及想把手动Excel测算升级成自动优化模型的能源行业从业者参考。

1. 激励型需求响应与负荷转移策略的整体思路

先讲清楚一个核心概念，“激励型”到底激励在哪里。需求响应按触发机制分，常见的有两块：价格型需求响应和激励型需求响应。价格型靠分时电价、实时电价引导用户“感觉什么时候便宜就多用”，用户有自主权，但电网很难精确控制响应量。激励型则是用户事先签协议，约定在某个时间段削减或转移一定负荷，完成后拿补偿。效果更可控，适合电网可靠性压力大、必须保证削峰量的场景。

负荷转移又是激励型需求响应里最常用的一种执行方式。它不要求用户少用电，只要求把用电时间平移。这对制造业工厂尤其友好，比如水泥厂、电解铝、污水处理厂这类可中断、可错峰的生产工艺，提前把生产计划调一下，就能把高峰用电挪到凌晨。用户没有损失产能，电网削了峰，属于双赢。策略的核心就变成了：怎么设计转移规则、怎么定补偿价格、怎么在几十上百个用户和24个时段之间找出最优的调度安排。

1.1 为什么选Matlab和Cplex组合

这个组合在工程界几乎是“建模+求解”的黄金搭配。Matlab的优势在于生态完整，数据预处理、聚类分析、结果可视化、报表生成一条龙。尤其是用Yalmip这个工具箱写优化模型，几乎可以把数学公式直接翻译成代码，维护起来非常直观。Cplex的优势在求解器本身，它是老牌商业求解器，对线性规划、混合整数线性规划、二次约束规划的支持极其成熟，几十万变量、几十万约束的大规模问题也能在可接受时间内解出来。而且相比开源求解器，Cplex在数值稳定性和预设参数上更省心，遇到病态模型时不容易翻车。

有人可能会问，为什么不用Python+Gurobi？能做，但很多电力系统团队的老资产、历史数据、已有程序都沉淀在Matlab里，再用Matlab衔接Cplex，迁移成本最低。Matlab也自带linprog、intlinprog，但处理大规模混合整数问题时求解速度明显吃力，对负荷转移这种带大量0-1整数变量的优化问题，Cplex显然更专业。更何况，很多高校和科研机构本身就有Cplex的学术许可，不存在额外的授权门槛。这个组合选型的理由很朴素：建模快、求解稳、落地阻力小。

1.2 策略的整体技术闭环

整个负荷转移策略不是“建模、一跑、出结果”这么简单，它是一套完整的技术流程。前端是数据输入，包括24个时段的基线负荷、用户可转移负荷类型、协议约定的最大响应次数；中间是优化核心，把目标函数和约束写成混合整数线性规划，交给Cplex求解；后端是结果处理，把求得的转移量换算成补偿费用、修订后的负荷曲线，最后输出给执行系统或者人工复核。

这里面最容易被忽略的是“基线”确定。需求响应里经常有一句话：没有基线，就没有结算。如果用户原本就计划在晚高峰减产，你却把削减量算成他的响应量，出现所谓的“搭便车”问题，结算时就会扯皮。所以我们的策略里一定要预设一套基线校核机制，比如用转移日前5个正常日的平均负荷作为基线，再乘以天气修正系数。做模型的人可以假设这些都经过预处理，但心里始终要有这根弦。

2. 核心数学模型与参数设计

负荷转移策略的数学模型，核心可以概括为四个决定：决定哪些时段可以转、决定转出去多少、决定转到哪些时段、决定补偿多少钱。前两个是物理约束问题，后两个是经济优化问题。把它们捏在一起，就形成了一个典型的混合整数线性规划问题。

2.1 目标函数设计

先看目标函数。我建议不要一上来就追求最复杂的社会福利最大化，先从一个工程上最实用的目标入手：在满足激励约束的前提下，最小化系统峰值负荷，或者等价地最小化峰谷差。这样设计出来的模型贴近电网的实际考核指标，也容易向领导解释结果。

如果用峰谷差最小作为目标，函数形式可以写成：

min max( P_sim(t) ) - min( P_sim(t) )

其中P_sim(t)是负荷转移之后的等效总负荷，包含了原始固定负荷和可转移负荷的重新分配结果。但这个目标带max和min，直接交给求解器处理比较麻烦，需要用辅助变量线性化。定义一个辅助变量Z等于系统峰值，再加两个约束：Z ≥ P_sim(t) 对所有t成立，同时把谷值也写成类似约束，然后最小化两者之差。

另一种常见的做法，也是我更喜欢用的，是把目标函数定义成“系统总用电成本”或者“用户总电费支出+电网激励支出”的加权和。比如：

min sum_t( price(t) * P_fixed(t) + price(t) * P_shift_in(t) ) + sum_t( incentive(t) * P_shift_t(t) )

这里price(t)是分时电价，P_shift_in(t)是转移到t时段的负荷量，incentive(t)是根据策略支付的激励单价，P_shift_t(t)是t时段参与转移的负荷量。这个目标的好处是自然地体现了“激励成本”的权衡，求解结果直接反映补贴预算和削峰效果的平衡。

再说一条建模心得：如果目标函数里同时出现削峰收益和激励成本，两者的量纲和数量级差异往往巨大，容易导致优化结果偏向单边。我在实际项目中会做归一化处理，把激励成本乘以一个经济性权重，或者把目标函数拆成两级优化——先最小化峰谷差，再在峰谷差不超过阈值的约束下最小化激励成本。这种层次化处理比单目标加权更可控，也更好解释。

2.2 可转移负荷的类型与约束

可转移负荷不是所有负荷都能“打包”处理的。要把它们分类建到模型里，工程上可以分三类：

第一类是固有的可转移负荷，比如洗衣机、消毒设备、蓄冷空调，特点是用电时段可以任意平移，但一旦开始就必须连续运行完整个工作周期。第二类是产能型可转移负荷，工厂的生产流水线，特点是某个生产任务需要固定的总电量，可以拆分成几个阶段在不同时段完成，但单个阶段不能中断。第三类是可削减负荷，照明、空调、电梯这类舒适性负荷，可以降低功率但不能完全断电，转移能力有限。

对不同类型，约束写法不同。对连续型可转移负荷，最简单的约束是：转移后各时段功率等于原始功率矩阵乘以一个转移分配矩阵。也就是用一个 N×N 的矩阵，行表示负荷的原始时段，列表示转移后的目标时段，矩阵元素是转移比例，每一行的和必须为1，因为原来的这份电量不能凭空消失。对整段不可拆分的负荷，则要引入0-1变量，比如“t时段开始运行”，然后约束工作时间长度、最大转移次数。

2.3 激励补偿定价怎么定

激励价格不是拍脑袋定的。太低了，用户不参与；太高了，电网补贴吃不消。业内常用的一种思路是“基于缺口的补偿”，也就是用户因为响应而改变用电计划所产生的机会成本。落到模型里，可以用用户不响应时的最大用电效益和响应后效益之差来量化。

简化处理时，可以预先设定一个补偿价格档次，高峰时段每转移1kW给X元，尖峰时段给Y元，深夜低谷期转移进去给Z元。也可以把补偿做成阶梯式：同一时段内，转移量在0到容量上限的60%以内，执行基础单价；超过60%的部分，执行溢价单价。加阶梯是为了激励用户“转得更多”，但模型复杂度会随之上升，因为需要引入分段线性函数和额外的0-1变量。

实际操作中，我建议第一次建模时先用固定单价，跑通结果后再逐步引入阶梯价格。因为固定单价的模型只用线性约束，Cplex求解非常快，适合调试。而阶梯价格导致的分段线性函数在Matlab里用Yalmip写也不算难，但后面的灵敏度分析和结果解读都会多一层工作量。

2.4 约束条件的完整清单

在正式向代码转换之前，把约束条件列一个清单非常必要。我自己吃过亏，光顾着写目标函数，忘了约束，模型跑出来一堆“负负荷”的荒诞结果。基础约束包括：

• 功率平衡约束：每个时段固定负荷加转移负荷等于系统总负荷，转移来的负荷总和等于转移走的负荷总和。
• 转移能力约束：单个用户的日最大可转移电量有限制，每小时可转移功率上限有限制。
• 连续运行约束：不可拆分负荷的运行时间窗必须连续，比如蓄冷设备至少要连续运行4小时。
• 用户舒适度约束：可转移负荷的转移次数有上限，避免同一个用户被反复调度。
• 线性化约束：min/max函数、绝对值函数都要通过辅助变量转化为线性不等式。
• 激励预算约束：总激励支出必须小于预设预算，否则模型会疯狂让用户转移，算出不切实际的方案。

把这些约束全部列完之后再写代码，基本上可以一次性通过调试。如果跳过这一步直接开写，后面排查问题的成本会翻倍。

3. 实操过程与核心环节实现

建模思路理顺之后，进入实操环节。这部分我按“环境准备→数据构造→模型代码→结果解读”的顺序走一遍，尽量给到可以直接复用的代码框架。需要说明的是，不同电脑的Matlab版本和Cplex版本会有差异，但整体流程是通用的。

3.1 环境准备：Matlab、Cplex和Yalmip的配合

Matlab这边至少安装R2019b以上的版本，太老的版本在调用Yalmip时容易出现兼容性问题。Cplex需要有可用的许可，如果用的是社区版，模型规模会受限，但对教学和中小算例完全够用。Yalmip是一个独立于求解器的建模工具箱，需要单独下载并配置到Matlab路径中。安装完成后验证方法很简单，在命令窗口运行：

yalmiptest

如果输出列表里CPLEX对应的一行显示available，说明Cplex已经被Yalmip正确识别。这一步没通过的情况下，最常见的原因是Cplex安装路径没有加入MatlabJava路径，或者Cplex的版本与Matlab版本位数不一致。注意，Cplex 12.10之后的版本对Matlab的Java版本有要求，Matlab R2020a及以下可能会踩坑。

环境配置好之后，在Matlab中只需要把优化问题定义为Yalmip的决策变量、约束和目标，最后调用optimize函数。Yalmip会在后台自动把模型转换成Cplex要求的输入格式，对用户来说几乎感知不到Cplex的存在。

3.2 数据构造：模拟一天的负荷与可转移资源

以一个小型配网为例，一天划分成24个时段。系统基础固定负荷我构造一个典型的“早峰+晚峰”曲线，早峰出现在上午10点，晚峰出现在晚上7点，峰值大概在2500kW左右。另有三类可转移负荷用户：

• 用户A：蓄冷空调，夜晚低谷时段集中运行，可转移窗口为下午5点至次日早上7点，最大转移功率150kW。
• 用户B：工业流水线，日总转移电量2000kWh，可分割成多个时段，单时段最大500kW。
• 用户C：商业建筑空调，可削减功率，削减幅度在0到100kW之间。

每个用户设置一个单位激励价格，用户A为0.4元/kWh，用户B为0.6元/kWh，用户C为0.8元/kWh。为什么设置不同的价格？因为不同用户的响应成本和意愿差异很大，统一价格会低效。接下来把以上数据组织成Matlab向量和矩阵，准备建模。

3.3 Yalmip建模与Cplex求解核心代码

下面是一个简化的核心建模片段，覆盖了固定负荷、可转移负荷、削减负荷三类资源的优化。代码用Yalmip语法书写，决策变量用sdpvar定义，0-1变量用binvar定义。这部分代码执行后可以直接在Matlab里跑通。

%% 参数定义 T = 24; % 时段数 price = [0.5*ones(1,7), ... % 0-6点谷段电价 0.9*ones(1,3), ... % 7-9点平时段 1.3*ones(1,2), ... % 10-11点峰段 1.0*ones(1,2), ... % 12-13点平段 1.3*ones(1,3), ... % 14-16点峰段 0.9*ones(1,2), ... % 17-18点平段 1.4*ones(1,4), ... % 19-22点尖峰 0.9*ones(1,2)]; % 23-24点平常 P_fixed = [100 95 90 85 80 85 90 105 120 135 140 130 ... 125 130 135 145 150 140 145 150 155 160 140 110]; % 固定负荷 % 用户A：蓄冷，可转移窗口（简化模型，只转移能量） P_A_orig = 0.5*ones(1,7); % 原本在0-6点运行的负荷 A_shift = sdpvar(1, T); % 转移到各时段的负荷量 constraints = [A_shift >= 0, sum(A_shift) == sum(P_A_orig)]; % 用户B：工业负荷，每个时段可转移量上限500kW P_B_orig = [0 0 0 0 0 0 100 150 180 200 220 180 ... 160 140 120 130 150 170 180 160 120 80 40 0]; B_shift = sdpvar(1, T); constraints = [constraints, ... B_shift >= 0, ... B_shift <= 500 * ones(1, T), ... sum(B_shift) == sum(P_B_orig)]; % 用户C：可削减负荷 C_cut = sdpvar(1, T); constraints = [constraints, 0 <= C_cut <= 100]; % 激励单价 incentive = [0.4*ones(1,24); ... % 用户A 0.6*ones(1,24); ... % 用户B 0.8*ones(1,24)]; % 用户C %% 目标函数：转移后负荷与激励成本 P_total = P_fixed + A_shift + B_shift - C_cut; P_peak = sdpvar(1); % 峰负荷辅助变量 constraints = [constraints, P_peak >= P_total]; % 综合目标：峰值最小化 + 激励成本最小化（权重 λ 可调） lambda = 0.05; objective = P_peak + lambda * ... (sum(incentive(1,:).*A_shift) + ... sum(incentive(2,:).*B_shift) + ... sum(incentive(3,:).*C_cut)); ops = sdpsettings('solver', 'cplex', 'verbose', 2); result = optimize(constraints, objective, ops); %% 结果展示 if result.problem == 0 figure; stairs(1:24, P_total, 'k-', 'LineWidth', 2); hold on; stairs(1:24, P_fixed, 'r--', 'LineWidth', 1.2); legend('优化后', '原始固定负荷'); xlabel('时段'); ylabel('kW'); grid on; else disp('求解失败，请检查约束和求解器设置'); end

这段代码的核心逻辑是：把用户A的负荷平移到任何时段，用户B的负荷在容量上限内重新分配，用户C可以削减。注意我特意设计了目标函数里带了两个量，峰值和激励成本的加权和，lambda是权重系数。实际运行的时候可以先用lambda=0只看峰谷优化效果，再慢慢增加lambda，观察补偿费用和峰值之间的帕累托前沿。

3.4 求解结果与转移策略解读

跑完求解后，典型的结果是：晚高峰很大一块负荷被转移到了凌晨1点到5点之间，系统峰值从1550kW下降到1300kW左右，峰谷差明显收窄。用户A的蓄冷运行时间基本被安排到凌晨电价最低的区间，用户B的工业负荷从晚高峰分散到了中午和深夜，用户C在晚高峰被削减了80kW左右。同时，每个用户对应的激励费用被精确计算出来，可以直接用于结算单。

这里要提醒一句：优化结果出来以后，不要直接下发执行。要做一项关键验证——回代校验。把求得的转移方案重新代入原始负荷曲线，检查每个时段是否满足功率平衡，是否触碰最大最小限制，补偿费用是否在预算内。我见过不止一次因为模型里少写了一条约束，导致某个时段出现了“凭空多出200kW”的诡异结果。求出的解在数学上是最优的，但物理上是荒谬的，回代校验能在第一时间暴露这种问题。

3.5 结果可视化的进阶技巧

除了基础的负荷曲线对比，建议再做两个可视化：一个是“转移热力图”，矩阵的行是原始时段，列是目标时段，颜色深浅代表转移电量的多少。这张图能非常直观地看到负荷从晚高峰流向低谷。第二个是“激励费用堆叠图”，把每个时段的激励成本按用户类型堆叠起来，用来向财务部门解释补贴预算的构成。Matlab里用heatmap或者imagesc都能做热力图，操作不复杂，但效果极好。

4. 常见问题与排查技巧实录

再完美的建模思路，落地过程中都会遇到各种奇怪的报错和结果异常。我把自己踩过的、以及帮别人排查过的坑集中整理一下，这部分价值一点不比模型本身低。

4.1 Cplex求解报错的排查

常见的一种场景是，Yalmip能完成建模，但调用Cplex时报“Out of memory”或者“No solution exists”。先说内存问题，如果模型引入了太多不必要的整数变量，Cplex的求解空间会指数膨胀。比如24时段乘以50个用户，再乘以0-1状态变量，规模会突然冲到几千个整数变量。遇到内存溢出，第一选择不是加内存，而是削减整数变量：检查同一个逻辑状态是不是被重复定义了，能不能用连续变量近似替代。

“No solution exists”的原因多数不是模型本身无解，而是约束相互矛盾。典型例子是把“转移来的总能量等于转移走的总能量”写成误把所有用户都限制为“每时段转入等于转出”，这明显不可能满足。排查技巧也简单，先把整数变量全部松弛成连续变量，看线性松弛是否有解；如果松弛有解，说明是整数约束引起的组合问题，需要检查0-1变量的取值范围；如果松弛也无解，那就是硬约束冲突，需要逐步放开关闭约束来定位问题行。

4.2 结果不合理的排查

跑出结果但结果不合理，比报错更头疼。常见情况是负荷曲线出现毛刺——某个时段转移量剧烈波动，相邻时段差异巨大。这通常是因为目标函数里没有加入“平滑性”惩罚项，优化器为了极小化峰值，会把负荷集中堆到最便宜的时段，形成尖刺。解决办法是额外增加一个约束，限制相邻时段转移量变化速率，比如：

abs(A_shift(t) - A_shift(t-1)) <= 50

用Yalmip里的abs函数即可，它内部会做线性化处理。

另一种不合理是“激励价格过高的甩负荷”——目标函数为了减少峰值，宁可高额补贴用户，也要让某个用户转出全部负荷。这时对应的激励预算约束没有生效。我建议每个用户单独加一个总激励费用上限，比如不得超过该用户原始电费的一定比例，这样能有效防止补偿费用爆表。

4.3 效率优化和经验技巧

当问题规模增大到几千个变量时，Cplex求解时间会从秒级跳到分钟级。工程上常用的加速手段有三种：提供初始解、设置MIP间隙、调整求解精度。Yalmip可以给sdpsettings里的cplex.mip.tolgap设置一个合适的容忍间隙，比如0.01表示允许1%的误差，求解速度可能快好几倍；也可以先用松弛模型求一个解作为整数模型的启动起点，Cplex会从这个起点开始搜索，收敛速度明显更快。

还有一个很隐蔽的经验：变量顺序对Cplex有影响。把决策变量按照“用户、时段”的二维矩阵形式而不是一维长向量形式定义，能帮助求解器更有效地做分支定界。原理不深究，但实测有效。

4.4 模型验证思路

最后说一下验证。没有验证的优化模型，谁都不敢直接信。我常用的验证方法是“基准案例对比法”：先设置一个完全不平移负荷的基准方案，计算其峰谷差、总电费和激励成本；再用模型跑一个允许自由转移的方案，两者对比。如果优化后峰谷差反而变大，基本可以断定模型写错了，要么目标函数方向反了，要么约束限制得太死。

更系统的验证是用历史数据做“后测”。取过去一个月的负荷数据，把方案重新算一遍，看哪些天的优化效果特别差，再分析差的原因。通常会发现是某个用户的响应率预测不准，或者激励价格对某个用户群没有吸引力，这为下一轮参数更新提供了依据。需求响应项目永远是“先跑起来、再迭代”，一上来就想把模型做到完美，反而容易陷入调参循环。

我个人在做这类项目的过程中，体会最深的一点是：优化模型再漂亮，最后落地看的还是现场反馈。负荷转移策略的求解结果只是建议方案，真正执行时要考虑用户的生产安排、设备切换成本、通讯延迟这些非建模因素。所以现在的习惯是留出至少一个“可执行性校验”环节——结果出来后，让现场人员过一遍，标记出哪些转移建议不合理，再把这些不合理的情形以约束形式加回到模型里。迭代几轮之后，模型的准确度会越来越高。上面这套Matlab+Cplex的实现流程，我已经在多个小型园区和工厂的响应项目中跑过，整体思路是经得起检验的。如果后续能把激励价格从固定值升级成动态定价，再引入用户的实时响应状态，这套框架可以直接扩展成一个轻量的日内调度工具。