陈易铭最近在折腾电动汽车充电调度的问题，第一版我直接上了集中式优化，把所有充电桩、所有车辆、所有时段丢进同一个混合整数规划模型里。刚开始还顺利，数据量一上来就完蛋：300辆车、96个时段、再加上各种“必须在几点前充满”的硬约束，求解器跑半个多小时还在那里分支定界，内存占用居高不下，最终给的解也没法直接用。这个问题我卡了快一周，后来换了个思路——用拉格朗日松弛法把“全网协同调度”拆成“每辆车自己决策”，效果直接翻天覆地。
这篇文章就聊聊我实际拆解这个问题的全过程：为什么集中式会算不动、拉格朗日松弛法的核心思路到底是什么、建模和求解时有哪些坑、以及最关键的——怎么从对偶解得到一个真正能落地的充电计划。内容偏工程实践，不堆数学公式，适合正在做充电调度、有序充电、虚拟电厂或需求响应相关项目的朋友参考。
1. 为什么集中式优化规模一大就“算不动”
1.1 模型规模的增长比你想的快得多
先说我最初建的那个模型。假设一个园区有200台充电桩，调度周期是24小时，时间粒度取15分钟，那就意味着决策变量是 x_{i,t}，i表示第i台车，t表示第t个时段。200辆车乘以96个时段，这一层就是19200个连续变量。
但真实场景远不止这么简单。如果你要处理“充电过程中不允许中断”“车辆必须在用户设定时间前达到目标SOC”“充电桩的总功率不能超过变压器容量”之类的约束，就必然要引入二进制变量。一台车一个时段一个充电状态变量，又是19200个0-1变量。再叠加充电功率分档、充电桩绑定关系、用户偏好时段等约束，变量数量和约束行数轻松突破十万数量级。说实话，到这个量级，开源求解器基本就很难在可接受时间内找到全局最优解了，商业求解器也不轻松，尤其是整数变量占比高的时候。
我实际碰到的情况是：200辆车，模型生成后传给求解器，跑了20多分钟，gap还停在15%以上。这在实时调度场景里是完全没法用的——调度指令晚半小时才出来，用户的充电需求早就变了。
1.2 集中式的“数据汇聚”和“单点求解”瓶颈
除了计算量本身，集中式优化还有一个容易被忽略的问题：数据汇聚。集中式方案要求把所有车辆信息、充电桩状态、用户行程数据、电价信息全部上传到同一个中心节点，然后统一建模求解。
这套流程在仿真里跑没问题，但落到真实的充电运营平台就有很多麻烦：车辆接桩时间参差不齐、某些车在V2G模式、某些桩上报数据断断续续、用户临时改变离开时间……一旦数据变了，整个模型就得重新生成、重新求解。哪怕求解器本身足够快，反复的数据同步和模型重建也足够把实时性拖垮。
我调试的时候最怕的就是“模型重建后解不出来”，因为根本说不清是数据问题、模型问题还是参数设置问题。集中式方案的调试成本非常高。
1.3 问题的结构特征：哪些约束在“耦合”所有车
不过在折腾的过程中我慢慢发现一件事：充电调度问题并不是所有约束都耦合在一起的。大部分约束其实是单车的，比如：
- 每辆车有自己需要的总充电量；
- 每辆车有自己的充电功率上下限；
- 每辆车有自己的接入时间和离开时间；
- 每辆车有自己的电池SOC限制。
真正把所有车“绑在一起”的，通常只有少数几个全局约束，最典型的就是总功率约束——所有充电桩在任意时段 t 的总功率不能超过变压器容量 P_max，或者不能超过配电网给这个站点分配的最大负荷。
这就是问题的结构性特点：大量局部约束 + 少数全局耦合约束。集中式优化把所有约束扔给求解器，相当于把本来可以拆开算的100道小算术题强行合并成一道大综合题，计算复杂度当然指数增长。
于是我就想到，如果能把那条“全局耦合约束”从模型里暂时拿掉，把问题从“所有车一起算”变成“每辆车单独算”，再通过某种机制协调各自的决策，计算量就能降好几个数量级。这正是拉格朗日松弛法的核心逻辑。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 拉格朗日松弛法的核心思想：把“硬约束”变成“价格”
2.1 用“罚款”替代“硬性禁止”
拉格朗日松弛法最直观的理解方式，就是把你原本必须满足的全局约束，改成一条“可以做，但会被罚款”的规则。
打个比方：原来你规定停车场里所有车必须在早上8点之前全部驶离，这是硬约束。拉格朗日松弛的做法是：允许车超时停，但超时一分钟罚50块钱。车辆做决策的时候，就不再是“必须在8点前离开”，而是“对比罚款金额和自己多停一会的收益”，如果收益大于罚款，那就交罚款继续停；如果罚款太高，那就乖乖按时走。
放到充电调度里，总功率约束就