简介面向部分计算任务卸载场景的深度强化学习Python源码主要帮助计算机、人工智能、通信工程、自动化等专业学生完成毕业设计、课程设计及课题演示解决移动边缘计算中任务卸载决策与延迟优化问题。压缩包共5个文件以Python脚本为核心附带Markdown说明文档与两张实验结果示意图便于理解算法流程与效果包体仅4KB轻量易部署。已有583人学习下载代码经测试运行成功模块结构清晰、注释完整适合入门强化学习及边缘计算任务卸载的读者直接使用或二次开发。通过源码可学习深度强化学习建模、状态动作设计、奖励函数设置及延迟优化评估的完整思路也可基于现有框架扩展更多卸载策略灵活适配不同实验场景。1. 深度强化学习与计算卸载延迟优化为何要选这条路做移动边缘计算方向的同学应该都遇过这种场景终端算力有限任务又有低延迟要求全卸载到边缘服务器回传排队和带宽又会吃掉增益。传统二元卸载容易撞上性能天花板而部分计算任务卸载——把任务切分一部分本地算一部分卸载到MEC节点——才是延迟优化的关键。这份基于深度强化学习的部分计算任务卸载延迟优化Python源码包把卸载比例的决策权交给DRL智能体它感知信道、任务量、服务器负载动态输出卸载比例目标是最小化端到端延迟。代码包由一个核心文件 mec.py、两组结果图 fig1/fig2 和 README 组成适合课程设计、毕业设计等场景用来验证DRL在任务卸载决策上的有效性。2. 部分计算任务卸载的模型基础先把延迟公式和决策变量钉死2.1 部分卸载 vs 二元卸载分割比例、本地算力与回传带宽的三角关系在动手看代码之前先把这套仿真背后的延迟模型理清楚。计算卸载本质上是一个“在哪里算更划算”的决策问题。二元卸载把任务看作一个不可分割的整体要么全部在本地CPU跑要么整包丢给边缘服务器。这个决策的优点是动作空间小但缺点很明显当本地算力不足以满足延迟约束、同时边缘服务器的回传链路又不够宽时只做0/1选择会让系统在两个极端之间摇摆很难逼近延迟最优值。部分卸载在中间加了一个连续决策量卸载比例 x0 ≤ x ≤ 1。任务总数据量 L 被切成两份——xL 留在本地剩余 (1-x)L 通过无线链路发送到边缘节点。本地计算延迟可以写成[ T_{local} \frac{xL \cdot c}{f_{local}} ]其中 c 是任务计算密度每比特需要的CPU周期数f_local 是本地CPU频率。边缘侧除了计算延迟还要加上传输时间和排队时间[ T_{edge} \frac{(1-x)L}{R} Q_{mec} \frac{(1-x)L \cdot c}{f_{mec}} ]R 是当前信道速率Q_mec 是边缘服务器上已有的排队任务耗时。因为本地和边缘在并行工作端到端延迟通常取两者中的较大值也可能同时考虑本地等待队列。这种模型看起来不复杂但真正麻烦的地方在于信道速率 R 和边缘排队 Q_mec 是动态的——它们随用户移动、任务到达率、其他用户竞争资源而变化。如果每步都暴力遍历所有 x 的取值在连续空间里根本行不通用传统优化方法比如拉格朗日松弛做离线求解没问题但无法应对实时变化的信道环境。我一般在课程设计里跟学生强调的第一件事是别急着调神经网络先把延迟模型写清楚。你只有把时间参数的构成写明白了后面奖励函数怎么写、状态空间怎么设计才不会出现“训练半天、结果曲线乱跳”的问题。这也是一个目标驱动型的仿真项目里最值得检查的部分。如果延迟公式里漏了排队项那模型实际上是低估了边缘侧的成本得到的卸载策略往往会过度偏向卸载导致在实验对比图里出现不合理的倒挂。2.2 状态、动作、奖励把MEC仿真环境翻译成DRL接口DRL框架要解决的计算卸载问题本质上是一个马尔可夫决策过程MDP。环境在每一个时隙 t 给智能体返回一个观测状态 s_t智能体根据策略选择一个卸载比例 a_t动作环境根据延迟模型计算出这一轮的端到端延迟并把奖励 r_t 返回给智能体。之后环境进入下一个时隙状态 s_{t1} 随之更新。在 mec.py 这类单文件实现里最常见的状态向量设计是拼接四个维度状态维度符号说明本地队列长度q_local本地待处理的任务量反映本地算力的繁忙程度边缘队列长度q_mec边缘节点的排队负载信道增益/速率R当前无线链路的传输速率影响卸载传输时间当前任务大小L到达任务的数据量有些实现还会加上任务剩余截止时间或者能量消耗项那是在做能耗和延迟的联合优化时加上去的。这份资源既然叫“延迟优化”状态空间大概率落在上述四个维度附近动作空间就是卸载比例 x。动作输出有两种常见形式# 常见做法DDPG/TD3 这类连续动作算法的动作裁剪 action np.clip(actor.forward(state), 0.0, 1.0) # 限制卸载比例在[0,1] # 或者 DDQN 等离散动作的做法把[0,1]均匀切成N档 # action_idx np.argmax(q_values) # e.g. N10 时 0~0.9 的档位动作是连续值还是离散档位决定了算法选型离散版用 DQN 家族的算法就好连续版就要用 DDPG/TD3/SAC 这类连续控制算法。从文件名称和环境复杂度推测常见选择是 DDPG 或其变体因为部分卸载的决策天然是连续量离散化到 N 档虽然能跑但在精度上会把最优卸载比例卡在一个粗粒度格点上最终延迟对比图不如连续动作算法平滑。奖励函数的设计是这个项目里最影响训练质量的部分。有一个常用做法是直接取负延迟reward -total_delay # 延迟越小奖励越大但这里面有一个坑如果延迟数值的量纲很大比如毫秒级 50~300负延迟的绝对值动辄上百神经网络的 Q 值预测会因为量级过大而变得不稳定。更稳妥的写法是做一个带延迟阈值的惩罚项例如penalty max(0.0, total_delay - delay_threshold) / delay_threshold reward -total_delay / delay_normalizer - lambda_ * penalty这样奖励的量级可以被压到一个相对稳定的范围内。这里和后面要展开的又是另一组调参问题了。总之搞懂 MDP 四元组状态、动作、转移概率、奖励在这个环境里对应的是什么再去看 mec.py 的训练循环会顺很多。3. mec.py实战环境封装、训练循环与关键参数配置3.1 文件组成与数据流mec.py里到底发生了什么下载下来的压缩包解开之后核心内容一眼能看完mec.py 是全部核心代码fig1.png 和 fig2.png 是训练结束后生成的结果图resources 目录里放着渠道或辅助数据README 记录了运行方式和参数设定。这种单文件工程在课程设计和毕业设计里很常见——用一个文件把网络结构、环境仿真、训练循环、绘图全串起来方便直接跑也方便查错。从数据流角度看mec.py 大致承担了四个角色首先是任务生成器模拟泊松到达的任务事件生成每个时隙的任务数据量 L然后是 MEC 环境模块根据当前状态和智能体给出的卸载比例 x计算本地与边缘的并行处理延迟接着是 DRL agent 模块里面包含 Actor/Critic 网络结构、经验回放缓冲区、软更新参数最后是主训练循环跑完设定的 episode 后画出收敛曲线和对比曲线。代码里如果看到类似下面这种接口基本就是环境模块的标准用法# 典型的 gym-style 环境接口源码里可能是类内部方法结构等价 state env.reset() # 初始化本地队列、边缘队列、信道状态 for step in range(max_steps): action agent.select_action(state) # 按当前策略给出卸载比例 next_state, delay, done, _ env.step(action) # 环境计算延迟并转移 agent.store_transition(state, action, -delay, next_state, done) state next_state这种结构的最大好处是环境换接口的成本很低。比如你后面想改成多用户卸载或者加入能量约束只要 env.step() 的输入输出约定不变agent 的训练循环基本不用动。因此在课程设计答辩里评审老师最常追问的也是“你环境的状态转移怎么实现的”——能把 env.step() 中间延迟计算过程讲清楚代码环节就能拿到大部分分。3.2 关键函数逐个拆从任务生成到延迟汇总看 mec.py 时不要从头到尾逐行读我建议按“入口 → 环境 → 网络 → 训练 → 绘图”的顺序来读。入口部分一般就是 ifname main里面设定随机种子、加载超参数、创建 agent然后进入 episode 循环。环境部分是重点它决定了一个动作进来之后延迟结果到底怎么算出来。下面是一段简化的延迟计算逻辑我在实验室里给 A 同学讲解时经常用这个片段作为切入点def step(self, action): x np.clip(action, 0.0, 1.0) # 卸载比例 local_bits self.task_size * x edge_bits self.task_size * (1.0 - x) # 本地计算延迟任务比特 x 计算密度 / CPU频率 t_local (local_bits * self.cpu_cycles_per_bit) / self.f_local # 传输延迟卸载比特 / 信道速率信道速率随信道增益动态变化 rate self.bandwidth * math.log2(1.0 self.channel_gain * self.tx_power / self.noise) t_trans edge_bits / max(rate, 1e-9) # 边缘计算延迟注意这里要加上边缘服务器已有的排队任务量 t_edge_proc (edge_bits * self.cpu_cycles_per_bit) / self.f_mec t_edge t_trans self.edge_queue / self.f_mec t_edge_proc # 端到端延迟取本地与边缘的较大值并行处理假设 total_delay max(t_local, t_edge) self.local_queue / self.f_local # 更新队列状态 self.local_queue edge_bits # 剩下的任务回填本地队列 self.edge_queue edge_bits # 边缘收到新任务 self.edge_queue max(0.0, self.edge_queue - self.f_mec) # 本时隙消耗 self.channel_gain self.update_channel() # 信道状态进入下一个时隙 return self._get_state(), total_delay, False, {delay: total_delay}这段代码里有几个容易理解偏差的地方第一t_local 和 t_edge 用 max() 合并是默认本地和边缘并行执行如果你的场景要求串行那就要改成相加这会显著影响动作偏好。第二边缘延迟里我加了 edge_queue / f_mec 这一项这对应边缘服务器上已积压任务的排队时间如果漏掉这一项智能体会高估卸载的好处。第三local_queue 的回填逻辑可以根据场景改——有些模型假设本地只处理 xL 部分剩余部分全卸载本地队列不参与有些则假设未卸载部分也要排队这取决于你在 README 里约定的是哪种排队模型。信道更新函数 update_channel() 是这个环境动态性的核心。如果信道增益是一个固定值那马尔可夫转移退化成一个确定性问题DRL 学到的策略也会比较“脆”。我一般建议至少在信道模型里加入时变衰落——比如瑞利衰落或简单的马尔可夫信道状态——这样智能体才能学到“信道差时少卸载信道好时多卸载”的策略。源码里如果看到信道增益是随机采样的说明环境设计者意识到了这一点。3.3 超参数配置与调参学习率、折扣因子、目标网络更新频率DRL 训练的效果很大程度取决于超参。不像监督学习那样有明确的损失曲线可以判断过拟合DRL 的调参更像在找一个平衡点探索多了训练发散探索少了收敛到局部最优学习率大了 Q 值震荡小了收敛慢。以 DDPG 为例关键参数和常见取值范围如下参数典型值调参方向Actor 学习率1e-4 ~ 3e-4收敛慢就略增大震荡就减小Critic 学习率1e-3 ~ 3e-3一般比 Actor 大一档折扣因子 γ0.9 ~ 0.99看重长期收益就靠近 0.99经验回放缓冲区1e5 ~ 1e6任务到达率高时建议开大软更新参数 τ0.001 ~ 0.01目标网络更新太快会不稳定噪声策略N(0, 0.1) 或 OU 噪声前期加大噪声探索后期衰减训练循环内部的标准写法一般是这样的# 每步决策后存经验、采样、更新网络 replay_buffer.push(state, action, reward, next_state, done) if len(replay_buffer) batch_size: states, actions, rewards, next_states, dones replay_buffer.sample(batch_size) # Critic 目标值 reward γ * Q_target(next_state, actor_target(next_state)) with torch.no_grad(): target_q rewards gamma * critic_target(next_states, actor_target(next_states)) * (1 - dones) current_q critic(states, actions) critic_loss F.mse_loss(current_q, target_q) # Actor 策略梯度最大化 Critic 对当前动作的评分 actor_loss -critic(states, actor(states)).mean() optimizer_critic.zero_grad() critic_loss.backward() optimizer_critic.step() # 软更新目标网络 for param, target_param in zip(critic.parameters(), critic_target.parameters()): target_param.data.copy_(tau * param.data (1 - tau) * target_param.data)这段逻辑看起来不难但实践里最容易翻车的点在 target_q 的计算。如果你把 dones 当 1 用末端时隙被赋予了虚假的未来回报曲线会出现末端翘起如果你忘了 detach 梯度图Critic 的梯度会串到 Actor 上训练日志里的 loss 会出现明显毛刺。代码里带注释时一般会在这些关键行留下提示跑之前值得逐行确认一遍注释和实际计算是否一致。4. 常见问题与避坑DRL部分卸载场景下的五个典型翻车点4.1 奖励函数设计不当导致收敛到局部最优现象训练过程中累计奖励曲线上升了但画出来的延迟对比图里 DRL 策略比“全卸载”甚至“全本地”还要差或者训练前几轮延迟下降明显后面就卡住不动怎么调超参都没用。原因奖励函数只用了负延迟而且延迟本身的数值范围很大Q 网络的误差梯度会被放大。另一种常见情况是奖励里没给“卸载过多导致边缘排队爆炸”任何惩罚智能体发现边缘侧延迟估算偏低就会不断加大卸载比例最终把边缘节点塞满系统整体延迟反而上升。解决把奖励做归一化并加入关于排队长度或延迟上限的惩罚项。一个可行的写法是normalized_delay total_delay / delay_max reward -normalized_delay - 0.5 * queue_penalty如果条件允许也可以把延迟转为负的得分区间例如 reward max(-1.0, -normalized_delay)让学习信号更平缓。4.2 状态空间未归一化导致训练震荡现象训练刚开始时 Loss 是 NaN 或者每几步就出现一次巨大的跳变把学习率从 1e-3 调到 1e-5 之后不崩溃了但收敛速度变得极慢。原因状态向量里任务大小 L 可能跑到几十万比特信道速率 R 可能是 1e6 量级而队列长度是 0 到几千。这些数值量级差异过大的状态特征直接喂进神经网络的输入层权重的梯度会被大数值特征主导小数值特征几乎学不到。解决在环境返回状态之前做归一化。常见做法是把每个特征除以它的最大值或者做 z-score 标准化。我在实际代码里会在 env._get_state() 里强制加一层 np.clip 和归一化state np.array([q_local / q_max, q_mec / q_max, rate / rate_max, task_size / task_max]) state np.clip(state, 0.0, 1.0)注意归一化参数要在环境初始化时固定下来不能每步动态算 min/max否则训练时的分布会漂移导致 Critic 估值不稳定。4.3 时隙长度与任务到达率不匹配导致任务排队积压现象仿真跑完时隙平均延迟看着不高但最终累计延迟曲线持续上升任务队列无界增长系统一直处于“欠处理”状态。原因时隙长度定得太短每个时隙到达的任务量大于本地和边缘能处理的量或者任务到达率设置成了固定速率而实际执行时信道速率变化导致处理能力下降。DRL 智能体在这个情况下只能看到延迟上升却无法通过动作改变处理速度属于环境参数本身设计不当。解决检查每个时隙本地与边缘的总处理能力是否大于平均到达量保证系统在稳态下不积压。调试时可以先把动作固定为 x0.5观察队列长度是否收敛如果不收敛说明环境参数本身有问题与算法无关。4.4 卸载比例边界越界导致动作无效现象训练中动作值出现负数或大于 1 的值延迟计算出现负数或者卸载比例为 0.8 时反而比 0.2 延迟更高但趋势没有规律。原因连续动作算法输出本身不受限制输出层如果用的是线性激活动作必然可能越界。如果代码里只在 reward 计算时才做 np.clip而环境内部状态更新用的是未裁剪的原始值那本地和边缘的任务量分配就会乱掉。解决在 agent 输出动作后立刻进行裁剪并把这个裁剪后的动作返回给环境而不是在环境内部二次裁剪。一个固定写法是action np.clip(actor(state).detach().cpu().numpy(), 0.0, 1.0) next_state, delay, done, _ env.step(action)同时要确保环境不会因为动作越界而产生积分累积误差例如本地队列为负值时要钳到 0。4.5 结果图表与指标口径不一致现象fig1 显示 DRL 的延迟比其他对比方案低但换一台设备重跑结果完全对不上或者绘制出来的曲线横轴的 episode 数与训练代码中的总 episode 数不一致。原因不同人的环境参数不一样直接拿图对比没有意义代码里绘图部分指标口径与训练阶段累计的指标口径不同比如训练时统计的是“所有时隙平均延迟”绘制时统计的是“每个 episode 延迟之和”。另外随机种子没固定导致每次训练结果不同。解决跑实验前固定随机种子np.random.seed、random.seed、torch.manual_seed 三个都要设在绘图代码里复用训练阶段保存的日志数据避免二次计算口径不一致。对比实验要在同一组信道样本、任务到达序列下测试。5. 验证与进阶用两组对比曲线判断收敛质量从单MEC扩展到多节点在图包里通常放的是 fig1 和 fig2 两张图。拿到这两张图时可以重点看它们对应的指标分别是什么fig1 多数时候是训练阶段各 episode 的累计延迟下降曲线fig2 则是将训练好的策略与几个 baseline 策略做的对比柱状图或折线图。验证复现效果时我的检查顺序是先看 fig1 的收敛趋势是否平滑。如果曲线是单调下降后趋于稳定说明 Q 值估计和策略更新在协同收敛如果曲线是“下降后又反弹”大概率是某个回合里经验回放的样本分布突变或者是目标网络更新过快。此时先调低 tau再从 5e-3 试到 1e-3如果训练前期就发散则先调低 Critic 学习率。再看 fig2 中 DRL 策略与三种常规定位对手的差距全部本地处理All Local、全部卸载All Edge、固定比例卸载Fixed x0.5。一个合理的结论是 DRL 的端到端延迟应该低于或等于三者中最优的那个偶尔出现“略高于某一种策略”也正常因为 DRL 要应对信道变化和随机到达但如果 DRL 系统性不如固定比例那问题多半出在奖励函数而不是算法本身。验证做完了下一步可以考虑进阶方向。这个单文件项目的扩展路径有好几条多边缘节点把环境里的一个 MEC 服务器改成 N 个服务器状态空间增加每个服务器负载和信道质量动作变成多维卸载向量。算法上 DDPG 可以直接输出多维度连续动作。能量约束把通信传输功率也放进动作空间奖励变成延迟加能耗的加权负值从纯延迟优化变成延迟-能耗折中优化。换算法把 DDPG 换成 TD3 或 SAC对比同一环境下的收敛速度和最终延迟。TD3 对 Q 值过估计更稳健在高动态信道环境下通常表现更好。信道模型升级把固定的随机信道换成带有时间相关性的马尔可夫信道链让智能体真正学到“信道差时少卸载、信道好时多卸载”的时序决策。我在拆这个项目时踩过的最大一个坑是环境里没固定随机种子就急着跑对比实验结果白天跑出来的 DRL 比固定比例好 15%晚上重跑变成好 3%浪费了大半天才意识到两种实验的信道序列根本不一样。从那以后我每次重跑任何对比实验前都要强制走一遍“固定四个随机种子 统一任务到达序列 检查队列稳态”这三步确认口径一致后才让实验跑过夜。这份资源最大的价值不只是那两行神经网络代码而是给你搭了一个完整的、可替换部件的卸载仿真底座希望帮到你。本文还有配套的精品资源点击获取