企业官网建设流程全解析

简介：这份资源面向人工智能、深度学习方向的学习者与研究人员，聚焦移动边缘计算（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。把文件按职责分三类，后面调参和排错才不会乱。

这个结构的好处是环境、算法、实验、可视化四层解耦。你想换 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_devices=5, num_tasks=10): 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, hidden=128): 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, capacity=10000): self.buffer = deque(maxlen=capacity) def push(self, *transition): self.buffer.append(transition) def sample(self, batch_size): batch = random.sample(self.buffer, batch_size) return zip(*batch)

hidden=128是保守值，状态维度在 20 以内够用；如果状态超过 50 维，加到 256 或 512。capacity=10000在任务数 10、每轮 200 步的情况下大约存 5 轮经验，太小会导致过拟合近期经验，太大会拖慢采样。目标网络更新用soft update还是hard update，代码里一般用tau=0.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 python=3.9 -y conda activate mec_drl # 安装核心依赖，torch 按自己 CUDA 版本选 pip install torch==1.11.0 numpy matplotlib # 进入项目目录 cd GraduationProject-master # 先看下脚本内容，确认参数传递方式 cat run_f1_dqn.sh

run_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.png

draw_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 加到 50000，batch_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(dim=1)[0] target_q = reward + gamma * next_q * (1 - done) # Double DQN 改法：在线网络选动作，目标网络算值 next_action = online_net(next_state).argmax(dim=1, keepdim=True) 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/下的图和上一版对比。这套流程走一遍，基本不会出现「跑了一晚上发现参数传错」的血泪情况。希望帮到你。

本文还有配套的精品资源，点击获取