基于深度强化学习的MEC计算卸载毕设源码解析与实战

简介这份资源面向人工智能、深度学习方向的学习者与研究人员聚焦移动边缘计算MEC场景下的计算卸载与资源分配问题通过深度强化学习DRL构建智能代理动态决策任务本地执行或卸载至边缘服务器并合理分配通信带宽与计算资源以降低时延、节省能耗、提升系统效率。压缩包共18个文件约112KB包含5个Python脚本实现DQN等DRL算法与MEC环境建模、4个Shell运行脚本、6个txt训练日志以及3张png结果图覆盖从环境模拟、模型训练到性能评估的完整流程。资源已有277人学习下载读者可获取可运行的代码框架、模拟数据集、训练日志与评估指标并借助报告文档理解算法架构与实验设计适合作为毕业设计或课题实践的参考方案。1. 从一份毕设源码看 MEC 计算卸载这套 DRL 方案到底能不能跑起来移动边缘计算MEC这两年在自动驾驶、工业质检、AR 巡检这些场景里被反复提起核心矛盾就一个终端算力不够、电池不够把任务卸载到边缘服务器能省时省电但卸载决策本身是个 NP 难的组合优化问题。传统方法要么靠启发式规则要么靠凸优化近似一旦设备数量、信道状态、任务到达率动态变化策略就崩了。这份「基于深度强化学习的MEC计算卸载与资源分配」毕设源码包走的是 DQN 路线用mec_dqn.py搭智能体、mec.py搭环境配了run_f1_dqn.sh到run_f3_q.sh六组对比脚本把 DQN 和 Q-Learning 在三种实验配置下跑出日志和曲线。适合谁正在做 MEC 卸载方向毕设、课程设计或者想找一个能直接改状态空间和奖励函数的 DRL 入门工程的人。它不完美但骨架完整能让你把「理论公式」和「能跑的代码」之间的那道沟填上。2. 拆开压缩包文件结构与 DRL 卸载的建模逻辑2.1 目录里每个文件在干什么拿到GraduationProject-master这个目录先别急着python mec_dqn.py。把文件按职责分三类后面调参和排错才不会乱。文件/目录类型职责mec.py环境模拟器定义 MEC 系统状态、动作空间、奖励函数、状态转移mec_dqn.py算法实现DQN 网络结构、经验回放、目标网络更新、训练主循环run_f1_dqn.sh~run_f3_q.sh实验脚本六组对照f1/f2/f3 三配置 × dqn/q 两算法draw_f1.py~draw_f3.py绘图脚本读取 log 目录下的训练日志输出收敛曲线和性能对比图log/日志目录log_f1_dqn.txt等六个文件记录每轮 reward、loss、卸载决策figure/输出目录Figure_1.png~Figure_3.png绘图脚本生成的实验结果图这个结构的好处是环境、算法、实验、可视化四层解耦。你想换 DDPG 或 A3C只动mec_dqn.py想改任务模型或信道模型只动mec.py想加新对比实验复制一个run_f*.sh改参数即可。常见做法是先把mec.py读一遍搞清楚状态向量里每个维度代表什么否则后面调 reward 就是盲调。2.2 状态、动作、奖励三件套怎么定义的MEC 卸载的 DRL 建模本质是把「哪个任务卸载、分配多少资源」翻译成 MDP。这份代码里状态空间通常包含本地设备队列长度、边缘服务器队列长度、当前任务计算量、信道增益、剩余电量。动作空间是离散的——每个任务要么本地执行要么卸载到边缘资源分配按固定档位切分。奖励函数是负的加权时延加能耗目标是最大化累积奖励。# mec.py 中环境核心逻辑示意以实际代码为准 class MECEnv: def __init__(self, num_devices5, num_tasks10): self.num_devices num_devices self.num_tasks num_tasks self.state_dim num_devices * 4 # 队列、计算量、信道、电量 self.action_dim 2 ** num_devices # 每个设备本地/卸载二选一 def reset(self): # 初始化队列、信道、电量 self.local_queue np.zeros(self.num_devices) self.edge_queue 0.0 self.battery np.ones(self.num_devices) return self._get_state() def step(self, action): # 根据动作计算时延和能耗更新队列 delay, energy self._compute_cost(action) reward -(0.6 * delay 0.4 * energy) # 权重可调 self._update_queue(action) done self._check_done() return self._get_state(), reward, done, {}这段逻辑说明几件事state_dim决定了 DQN 输入层大小action_dim决定了输出层大小。奖励里的 0.6 和 0.4 是时延与能耗的权衡系数改这个比改网络结构对结果影响更大。_compute_cost里通常包含香农公式算传输速率、CPU 频率算本地计算时延、边缘服务器排队时延。如果你发现训练不收敛先检查_compute_cost里的单位是否统一——时延用秒、能耗用焦耳别混用毫秒和瓦特。2.3 DQN 网络与经验回放的实现要点mec_dqn.py里 DQN 的部分核心是三层全连接加一个目标网络。经验回放池存(state, action, reward, next_state, done)五元组训练时随机采样 batch。这里有个容易翻车的点action_dim如果按设备数指数增长5 个设备就是 32 维输出10 个设备就是 1024 维DQN 直接爆炸。所以实际代码里往往不是每个设备独立动作而是把动作空间压缩成「卸载比例」或「优先级排序」。# mec_dqn.py 中 DQN 核心片段示意 class DQN(nn.Module): def __init__(self, state_dim, action_dim, hidden128): super().__init__() self.net nn.Sequential( nn.Linear(state_dim, hidden), nn.ReLU(), nn.Linear(hidden, hidden), nn.ReLU(), nn.Linear(hidden, action_dim) ) def forward(self, x): return self.net(x) # 经验回放 class ReplayBuffer: def __init__(self, capacity10000): self.buffer deque(maxlencapacity) def push(self, *transition): self.buffer.append(transition) def sample(self, batch_size): batch random.sample(self.buffer, batch_size) return zip(*batch)hidden128是保守值状态维度在 20 以内够用如果状态超过 50 维加到 256 或 512。capacity10000在任务数 10、每轮 200 步的情况下大约存 5 轮经验太小会导致过拟合近期经验太大会拖慢采样。目标网络更新用soft update还是hard update代码里一般用tau0.001的软更新比每 C 步硬拷贝稳。这些参数在run_f*.sh里通常以命令行参数传入改的时候别只改 py 文件忘了 shell。3. 跑通第一组实验从环境依赖到 DQN 收敛曲线3.1 环境准备与依赖安装这份代码是纯 Python 工程依赖不会太重但版本要对。常见组合是 Python 3.7~3.9、PyTorch 1.8~1.11、numpy、matplotlib。别用 Python 3.12 硬跑老代码里np.float这类别名会被移除直接报 AttributeError。# 建议用 conda 建独立环境避免污染主环境 conda create -n mec_drl python3.9 -y conda activate mec_drl # 安装核心依赖torch 按自己 CUDA 版本选 pip install torch1.11.0 numpy matplotlib # 进入项目目录 cd GraduationProject-master # 先看下脚本内容确认参数传递方式 cat run_f1_dqn.shrun_f1_dqn.sh里一般会指定--episodes、--lr、--gamma、--epsilon这些超参。先cat一遍再执行比直接bash安全。如果脚本里写死了绝对路径比如/home/xxx/...改成相对路径或你本机的路径。这一步花两分钟能省后面半小时的 FileNotFoundError。3.2 启动训练与日志观察跑第一组实验建议先改小episodes试水比如从 200 改成 20确认流程通了再跑全量。# 试跑临时改小轮数观察是否报错 python mec_dqn.py --episodes 20 --log log/test_f1_dqn.txt # 正式跑 f1 配置的 DQN bash run_f1_dqn.sh # 另开终端实时看日志尾部 tail -f log/log_f1_dqn.txt日志里每行通常有episode、reward、loss、epsilon、avg_delay。前 20 轮 reward 是大幅震荡的因为 epsilon 接近 1智能体在随机探索。到 100 轮左右 epsilon 衰减到 0.1 以下reward 应该开始爬升并趋于平稳。如果 200 轮后 reward 还在原地抖先看 loss 是不是 NaN——学习率 1e-3 对这个小网络偏大改成 5e-4 或 1e-4 试试。另一个信号是avg_delay不降反升那多半是奖励函数里能耗权重过大智能体为了省电宁可本地排队。3.3 用绘图脚本验证收敛与对比训练完 f1 的 DQN 和 Q-Learning 两组draw_f1.py会读两个日志画在同一张图上。这一步是验证「DRL 到底比传统 Q-Learning 好多少」的关键。# 确保 log 目录下 log_f1_dqn.txt 和 log_f1_q.txt 都存在 ls log/log_f1_*.txt # 运行绘图脚本 python draw/draw_f1.py # 输出在 figure/Figure_1.pngdraw_f1.py里一般用np.loadtxt或正则解析日志取 reward 列做滑动平均。如果图是空的九成是日志格式和解析正则对不上——比如日志里 reward 前面有Reward:前缀正则没匹配到。打开日志文件头几行对着改re.compile里的模式。对比图看两点DQN 的收敛轮数是否明显少于 Q-Learning以及收敛后的平均 reward 是否更高。如果两者差不多说明你的状态空间设计没有提供比 Q 表更多的信息量DQN 的优势发挥不出来得回头加状态维度或改奖励。4. 避坑与排查六组实验跑下来最容易翻车的五个地方4.1 现象训练 reward 一直不涨loss 在 0.6 附近横盘原因经验回放池太小或 batch_size 太大采样相关性过高网络学不到东西。也可能是奖励函数量纲不对时延和能耗数值差两个数量级梯度被大项主导。解决把capacity从 10000 加到 50000batch_size从 64 降到 32。检查_compute_cost返回值时延和能耗都做归一化比如时延除以最大容忍时延、能耗除以电池总容量让两项都在 0~1 之间。4.2 现象Q-Learning 跑得比 DQN 还快还好原因状态空间是离散且维度很低Q 表几分钟就填满了DQN 反而因为网络拟合慢而落后。这不代表 DQN 没用而是你的实验配置没体现出 DRL 的优势场景。解决增加设备数量或任务到达率的随机性让状态空间变大。或者把run_f2、run_f3的配置改成更多设备、更动态的信道再看对比。如果毕设要求必须体现 DQN 优势就在论文里说明「在低维离散状态下 Q-Learning 足够DQN 的优势在高维连续状态」。4.3 现象绘图脚本报ValueError: could not convert string to float原因日志文件里混入了非数值行比如训练中途手动中断留下的KeyboardInterrupt堆栈或者日志开头有超参打印行。解决打开日志把非数据行删掉或注释掉。更稳的做法是在draw_f*.py里加try/except跳过无法解析的行。长期方案是训练脚本写日志时只写纯数值超参单独存一个config.json。4.4 现象换到 f2 配置后显存溢出或训练极慢原因f2 配置的设备数或任务数翻倍action_dim指数增长网络输出层和经验回放的内存占用跟着涨。解决先确认action_dim的实际值print(env.action_dim)看一眼。如果超过 1000必须改动作空间设计用「卸载比例」连续动作替代「每设备二值」离散动作或者用动作分支结构。临时方案是减小hidden和batch_size但治标不治本。4.5 现象run_f3_q.sh跑完没有生成对应日志原因shell 脚本里的输出路径写的是相对路径但脚本执行时工作目录不对日志写到了别处。或者 Q-Learning 脚本和 DQN 脚本共用日志文件名被覆盖了。解决在 shell 脚本开头加cd $(dirname $0)确保工作目录正确。日志文件名带算法后缀log_f3_q.txt和log_f3_dqn.txt分开。跑完find . -name *.txt -newer mec.py找一下日志实际落在哪。5. 进阶改法把 DQN 换成 Double DQN 并验证过估计是否缓解这份代码的 DQN 是标准版本Q 值过估计问题在 MEC 这种奖励噪声大的场景里会被放大。一个低成本改法是换成 Double DQN动作选择用在线网络动作评估用目标网络。改动量很小但收敛稳定性能提升一截。# 原 DQN 目标值计算 next_q target_net(next_state).max(dim1)[0] target_q reward gamma * next_q * (1 - done) # Double DQN 改法在线网络选动作目标网络算值 next_action online_net(next_state).argmax(dim1, keepdimTrue) next_q target_net(next_state).gather(1, next_action).squeeze(1) target_q reward gamma * next_q * (1 - done)改完后跑同一组 f1 配置对比log_f1_dqn.txt和新的log_f1_ddqn.txt。看两个指标训练后期 reward 的方差是否变小以及相同轮数下的平均时延是否更低。如果方差明显收窄说明过估计确实被缓解了。另一个验证方法是打印 Q 值的均值标准 DQN 的 Q 均值往往虚高Double DQN 会更接近真实回报。我自己的习惯是每次改完算法先跑 50 轮小实验确认 loss 曲线没有异常尖峰再跑全量。全量跑完先看日志最后 20 行的 reward 均值再跑绘图脚本最后把figure/下的图和上一版对比。这套流程走一遍基本不会出现「跑了一晚上发现参数传错」的血泪情况。希望帮到你。本文还有配套的精品资源点击获取