简介面向深度学习与边缘计算方向的毕业设计、课程设计需求这份基于深度强化学习的移动边缘计算任务卸载与资源分配优化系统提供了完整的DQN和Q-learning实现。压缩包共19个文件涵盖5个Python源码模型定义、训练与绘图、4个Shell运行脚本分场景启动不同算法、6个txt运行日志、3张结果对比图及1份Markdown说明文档整体仅112KB结构精简、易于部署。已有71人学习。通过调用脚本可快速复现任务卸载与资源分配的强化学习过程结合日志和图表分析延迟、能耗等核心指标对比深度Q网络与传统Q-learning的决策差异。适合作为课程设计、毕业设计的参考范例也可作为MEC场景下DRL应用的基线实现。1. 深度强化学习做移动边缘计算任务卸载为什么值得花精力复现移动边缘计算里最头疼的事是任务卸载到底怎么决策手机上刚抓了一帧要跑 YOLO 的画面本地算力不够传给边缘服务器还是本地硬扛传统做法是枚举或启发式搜索用户一多决策空间就组合爆炸。深度强化学习在这里的价值是把“每次决策都现场算”变成“训练一次、推理 O(1)”所以这类系统设计才会在毕设和课程设计里年年热门。这份“移动边缘计算任务卸载与资源分配优化系统设计”包包含从问题建模、MDP 设计、仿真环境到 DQN 训练调参的完整闭环。适合两类人一类是拿它当期末大作业骨架、想快速跑通再改自己场景的同学另一类是已经写过启发式算法、想摸清深度强化学习实际边界的人。下面按我拆这个包的顺序从建模到仿真到训练再到踩坑一条线过一遍。2. 任务卸载与资源分配把优化目标改写成 MDP2.1 为什么是强化学习而不是凸优化或启发式先看问题本身。一个典型场景N 个移动设备每个时隙产生一批计算任务每个任务都有数据大小和计算量可选本地执行或卸载到 M 个边缘服务器之一。服务器 CPU 频率有限信道又随时变化目标是在时延和能耗之间取加权和最小。这个问题的难点在于任务到达随机、信道增益每个时隙变化、服务器负载互相牵连。把约束完整写开它是一个混合整数非线性规划目标里带 max、min 和指示函数根本不是凸问题设备一多就是 NP-hard。传统做法比如遗传算法和粒子群在 10 设备、3 服务器、每时隙 20 个任务的场景里一次决策要跑几百上千次适应度评估在线系统根本等不起这一下。深度强化学习的思路是反过来的决策时不做搜索策略网络直接把状态映射到动作一次前向传播毫秒级完成。它天然适合这种“环境在变、但必须快速出决策”的场景这也是 MEC 任务卸载里 DRL 论文扎堆的根本原因。别把凸优化当万能钥匙这个问题从假设阶段就不满足凸性。2.2 状态、动作、奖励三件套的设计把问题改写成 MDP核心是定三件事。我现在复盘时觉得这三件事定了后面所有代码就只是翻译组成内容设计说明状态 s任务数据量、任务计算量、剩余截止时间、当前信道增益、各服务器已用负载、本地队列长度要覆盖“当前能不能卸载、卸载到哪最划算”的全部信息动作 a卸载目标本地 / 服务器 0 / 服务器 1 / ...资源分配各服务器算力按比例划分毕设场景通常把资源分配量化为 4 档离散化后统一用 DQN奖励 r负的加权时延与能耗之和外加超时惩罚r -(α·归一化时延 β·归一化能耗 γ·超时惩罚)状态向量维度不需要太大我见过做得比较顺的项目是 12 维左右3 个任务特征统计量、每个服务器的负载占用率、本地队列长度。动作侧的关键是资源分配必须离散化常见做法是把每台服务器的算力切成 0.1、0.3、0.6、1.0 四档系数训练难度比连续动作低一个量级对课设来说性价比很高。奖励公式里的权重我一般默认 α0.5、β0.5、γ2~5。这里有个经验时延是毫秒级、能耗是焦耳级不归一化的话 Q 网络会被大数带走后面专门讲这个坑。2.3 基线与对比逻辑有了 MDP 还不够评判 DRL 策略到底有没有用基线得先架起来。我拆包时最先看的就是这部分通常有三种基线全部本地纯本地计算最保守能耗可控但时延高最小负载贪心卸载到当前负载最低的服务器不看信道质量负载均衡启发式用“服务器剩余能力 信道质量”打一个加权分选分最高的。对比指标用四个平均 system cost、任务超时率、卸载率、单次决策耗时。跑 100 个时隙取平均和 DRL 放同一张表里。遗传算法也可以加进来当近似最优上界用它来衡量 DRL 离最优解还有多远。这套对比脚本跑一遍直接出 CSV比你自己从头造轮子省半天时间。3. 仿真环境搭建信道、队列、能耗的工程实现3.1 时隙驱动的主循环结构MEC 仿真一般用离散时隙。每个时隙的事件顺序是生成任务 → 采样信道状态 → 做卸载决策 → 执行计算 → 更新负载和能耗。信道用瑞利衰落加路径损耗每个时隙重新采一次这样状态才有真实的动态性。import numpy as np class MECEnv: def __init__(self, n_devices5, n_servers3, slot0.1): self.n n_devices self.m n_servers self.slot slot # 单个时隙时长单位秒 self.bandwidth 10e6 # 信道带宽 10 MHz self.noise_power 1e-13 # 噪声功率谱密度 self.server_freq 20e9 # 边缘服务器 CPU 频率 20 GHz self.local_freq 1e9 # 本地 CPU 频率 1 GHz self.energy_coef 1e-26 # 每 CPU 周期的能耗系数 self.tx_power 0.5 # 设备发射功率 0.5 W self.reset() def reset(self): self.server_load np.zeros(self.m) # 边缘服务器已用算力 self.queue_len np.zeros(self.n) # 本地待处理队列长度 self.tasks [] return self._get_state() def _rate(self, dev, server): gain np.random.rayleigh(scale1e-5) # 瑞利衰落信道增益 snr self.tx_power * gain / self.noise_power return self.bandwidth * np.log2(1 snr) # 香农公式算传输速率逻辑说明环境类核心就是两个函数_rate算设备到服务器之间的上行速率reset负责初始化每轮实验的负载与队列。带宽、发射功率、噪声系数三个参数直接决定传输时延的大小改场景时优先调这三个。参数说明slot0.1代表每个时隙 100ms任务要在这个窗口内决策server_freq取 20 GHz 是边缘服务器的常见量级energy_coef是芯片级的每周期能耗实际值会随制程浮动做设计时只需要保持量级正确。3.2 调度与成本结算代码环境里最关键的逻辑是step里的调度拿到动作后逐任务判断本地还是卸载卸载时还要检查服务器剩余资源。这里的记账方式直接决定状态是否失真。def _schedule(self, action, tasks): total_cost 0.0 for task in tasks: dev task[device] if action[dev] 0: # 本地执行 delay task[cpu_cycles] / self.local_freq energy task[cpu_cycles] * self.energy_coef else: server action[dev] - 1 if self.server_load[server] task[cpu_cycles] self.server_freq * self.slot: # 服务器超载按排队处理cost 按最坏情况估算 delay task[cpu_cycles] / (self.server_freq * 0.2) energy self.tx_power * task[data_mb] * 8e6 / self._rate(dev, server) else: self.server_load[server] task[cpu_cycles] rate self._rate(dev, server) tx_delay task[data_mb] * 8e6 / rate comp_delay task[cpu_cycles] / self.server_freq delay tx_delay comp_delay energy self.tx_power * tx_delay total_cost 0.5 * delay / 1.0 0.5 * energy / 0.1 return total_cost逻辑说明action是每个设备一个离散值0 表示本地1 到 M 表示卸载到第几个服务器。超载分支很关键它把过载任务按 20% 服务能力估算时延既给了惩罚又不会把server_load污染成负数。delay / 1.0和energy / 0.1是量级归一化让两个目标在 cost 里大致同权。参数说明0.5 * delay 0.5 * energy对应奖励公式里的 α 和 β想偏向时延就把前面的系数调大超载分支的0.2是排队降速因子代表服务器满负荷后只能分出 20% 算力这个值可以根据场景改。3.3 状态归一化不做这步基本训不动状态里混着 MB 级别的数据量、GHz 级别的计算量、0 到 1 的负载占用率、还剩几个时隙的截止时间量级差 10 的 8 次方。直接喂给 DQN第一层全连接层的梯度会被大数维度统治小维度的信息全被淹没。def _get_state(self): return np.concatenate([ self.server_load / self.server_freq, # 服务器负载压到 0~1 self.queue_len / 50.0, # 队列长度除以上限 50 ]) def normalize_state(self, state): state np.asarray(state, dtypenp.float32) state[0] state[0] / 5.0 # 设备数归一化 state[1] state[1] / 500e6 # 任务计算量归一化 state[2] state[2] / 10.0 # 截止时间归一化 state[3] state[3] / 1e-6 # 信道增益归一化 return state说明归一化系数要跟仿真参数范围对齐。比如信道增益先跑几个时隙统计峰值再定分母留 20% 余量别拍脑袋。目标是把每个维度的动态范围压到 0 到 1 左右网络才学得动。这个步骤省掉的话后面所有调参都是白费功夫。4. DQN 训练实现与调参让 loss 曲线往下走4.1 网络结构三层 MLP 加双 DQN动作空间是 N×(1M) 的离散选择标准做法是 DQN 直接输出所有动作的 Q 值。网络结构不需要复杂三层 MLP 足够输入层接状态两个隐藏层 256 和 128输出层接动作数。import torch import torch.nn as nn class DQN(nn.Module): def __init__(self, state_dim, action_dim): super().__init__() self.fc1 nn.Linear(state_dim, 256) self.fc2 nn.Linear(256, 128) self.fc3 nn.Linear(128, action_dim) def forward(self, x): x torch.relu(self.fc1(x)) x torch.relu(self.fc2(x)) return self.fc3(x)逻辑说明输出层不加激活直接给 Q 值原始估计。256/128 这个规模在 MEC 任务里非常够用继续加宽收益很小反而容易过拟合当前任务分布。参数说明如果动作空间特别大比如 10 个设备、5 个服务器、4 档资源系数输出维度是 10×(15×4)210128 的隐藏层会偏紧可以提到 256。毕设场景大多数用不到那么大的动作空间。双 DQN 的改进点在于主网络选动作目标网络给 Q 值避免单网络过估计。实现上就是两个结构一样的网络每隔若干步把主网络权重软更新给目标网络τ 取 5e-3。4.2 经验回放与训练主循环def train_loop(env, q_net, target_net, optimizer, buffer, epsilon, batch_size128): state env.reset() total_loss 0.0 for step in range(2000): # 探索率控制小于 epsilon 随机动作否则走策略 if np.random.rand() epsilon: action np.random.randint(0, env.action_dim) else: with torch.no_grad(): action q_net(torch.tensor(state, dtypetorch.float32)).argmax().item() next_state, reward, done env.step(action) buffer.append((state, action, reward, next_state)) # 每 500 步回放一次batch 从 buffer 随机抽取 if len(buffer) batch_size: batch random.sample(buffer, batch_size) s, a, r, s2 zip(*batch) s torch.tensor(s, dtypetorch.float32) s2 torch.tensor(s2, dtypetorch.float32) r torch.tensor(r, dtypetorch.float32) q q_net(s).gather(1, torch.tensor(a).unsqueeze(1)).squeeze(1) q_next target_net(s2).max(1)[0].detach() target r 0.95 * q_next loss nn.functional.mse_loss(q, target) optimizer.zero_grad() loss.backward() optimizer.step() total_loss loss.item() if step % 1000 0: soft_update(target_net, q_net, tau0.005) return total_loss / step逻辑说明训练循环的核心是“采样、存 buffer、回放”。target r gamma * maxQ(s2)是 DQN 的时间差分目标detach()是为了让梯度只流过主网络这是标准写法不能省。参数说明gamma 取 0.95 是因为 MEC 是短时决策未来收益衰减要快epsilon 从 1.0 线性衰减到 0.05衰减步数设在 5 万步左右buffer 上限 5 万条超出随机覆盖学习率 2e-4 配 Adam适合这种规模的 MLP。4.3 收敛判据loss 之外还看什么loss 不是唯一指标甚至不是主要指标。TD 误差收敛不代表策略变好——可能出现 loss 平稳但 cost 一直下不去的情况。我一般在训练脚本里每个 epoch 末尾做一次评估固定随机种子、关掉探索、用当前网络跑 50 个时隙记录平均 system cost 和超时率。注意判断模型能不能用看评估 cost 比看 loss 可靠。经验阈值是至少比“全部本地”基线低 20%并且连续 10 个 epoch 不再下降才算真正收敛。如果 cost 一直下不去优先查动作编码和奖励权重而不是盲目加训练轮数。我见过有人在错误奖励上多跑了两万步结果只是把错误策略练得更熟了。5. 任务卸载仿真里的常见翻车点五个高发故障与排查方法5.1 训练爆炸与不收敛现象 1loss 曲线直接变成 NaN或者前几个 epoch 冲到 1e5 以上后陡降。 原因奖励函数没有归一化。TD target 是 r gamma × maxQr 的量级如果是几十上百目标值超出 Q 网络输出范围梯度一步就把权重打飞。 解决把时延和能耗分别除以场景典型值压到 ±1 区间再对最终奖励做 clip。同时确认学习率不超过 3e-4ReLU 网络配大学习率非常容易崩。现象 2cost 曲线从头到尾是一条平线只比随机策略好一点。 原因探索率衰减配错。epsilon 从 1.0 开始、五万步内线性降到 0.05 是常见配置如果只设了三千步就降完网络基本没做过随机探索从头就在一条错误的道上一路狂奔。 解决把衰减步数写进配置文件先跑一个小型实验打印每个步段的 epsilon 值确认前一万步里还有 0.5 以上的探索率。5.2 仿真状态被隐性污染现象 3训练曲线在下降但任务超时率周期性跳高。 原因服务器资源分配没做记账。两个任务被分到同一个服务器各自判断“剩余资源充足”但server_load没有累加实际负载早已超出上限。这是最容易踩的坑而且很难从 loss 上发现。 解决调度时按设备编号排序逐任务分配每分一次就从剩余资源里扣减 CPU 周期数扣成负数就按排队处理并把状态里的负载占用率设为 1.0。我后来干脆改成每次决策前重新统计所有已分配任务的总和彻底避免脏状态。现象 4队列长度无上限状态里这一维从 0 慢慢漂到几百。 原因任务到达率高于处理能力队尾任务永远出不去队列越长状态越失真奖励里又没有对应惩罚策略根本学不到“应该拒绝新任务”。 解决给队列设上限 50满了直接按超时记账不让它进状态。状态里的排队长度用min(queue / 50, 1)表示保证输入范围固定。5.3 评估环节的隐性 bug现象 5训练时平均 cost 好看切到评估模式后数值崩坏。 原因评估代码把训练的 exploration 逻辑原样搬了过去epsilon 没关策略一边推理一边随机乱跳另一个常见问题是目标网络没冻结Q 值还在漂。 解决评估分支固定随机种子、epsilon 置 0、用 target_net 做前向跑 50 个时隙取平均。同一组实验至少跑 5 个不同种子把标准差也写进文档。这个习惯能救你答辩时的命因为老师一定会问“你的结果是稳定的吗”。6. 从训练到交付三种验证方法和成果导出6.1 泛化性测试用 5 个设备训出来的模型直接去跑 8 个设备的环境评估 cost 上涨幅度。如果涨幅在 30% 以内说明策略学到的是调度规律而不是记住了设备数量。我拿到一个模型先做这组实验比看任何指标都直观。视频帧处理类的负载也可以在这步做替换比如把任务特征换成 YOLO 单帧推理的计算量验证同一套代码在不同负载分布下是否仍然稳定。6.2 实验记录导成文档训练日志存 CSVcost 曲线存 PNG环境配置导出 JSON五组随机种子的对比结果汇总成表格。这些都是毕设“实验与分析”章节的原材料。资源包里一般带好了results/目录骨架我拿到手先照跑一遍再改一组 reward 权重 α0.3/0.7 做对比两个表格摆出来结论就立住了。下载包里把环境配置模板、训练脚本和三个基线函数分好了目录拿到手可以从第 3 章的代码直接跑起跑通后再改自己的场景。我第一版实验时为了省时间把 epsilon 直接设成 0.6 从中间往下降结果整整两天在一个“看起来在训、其实根本没在探索”的模型上死磕最后发现是探索率曲线配错了。从那以后每次起新实验我第一件事就是把随机种子、探索率衰减曲线和奖励归一化系数写进配置文件先跑通再优化不再碰这个坑。希望帮到你。本文还有配套的精品资源点击获取