深度强化学习驱动移动边缘计算任务卸载：从MDP到DQN的实战指南

简介：面向深度学习与边缘计算方向的毕业设计、课程设计需求，这份基于深度强化学习的移动边缘计算任务卸载与资源分配优化系统，提供了完整的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. 任务卸载与资源分配：把优化目标改写成 MDP

2.1 为什么是强化学习而不是凸优化或启发式

先看问题本身。一个典型场景：N 个移动设备，每个时隙产生一批计算任务，每个任务都有数据大小和计算量，可选本地执行，或卸载到 M 个边缘服务器之一。服务器 CPU 频率有限，信道又随时变化，目标是在时延和能耗之间取加权和最小。

这个问题的难点在于，任务到达随机、信道增益每个时隙变化、服务器负载互相牵连。把约束完整写开，它是一个混合整数非线性规划，目标里带 max、min 和指示函数，根本不是凸问题，设备一多就是 NP-hard。传统做法比如遗传算法和粒子群，在 10 设备、3 服务器、每时隙 20 个任务的场景里，一次决策要跑几百上千次适应度评估，在线系统根本等不起这一下。

深度强化学习的思路是反过来的：决策时不做搜索，策略网络直接把状态映射到动作，一次前向传播毫秒级完成。它天然适合这种“环境在变、但必须快速出决策”的场景，这也是 MEC 任务卸载里 DRL 论文扎堆的根本原因。别把凸优化当万能钥匙，这个问题从假设阶段就不满足凸性。

2.2 状态、动作、奖励三件套的设计

把问题改写成 MDP，核心是定三件事。我现在复盘时觉得，这三件事定了，后面所有代码就只是翻译：

状态向量维度不需要太大，我见过做得比较顺的项目是 12 维左右：3 个任务特征统计量、每个服务器的负载占用率、本地队列长度。动作侧的关键是资源分配必须离散化，常见做法是把每台服务器的算力切成 0.1、0.3、0.6、1.0 四档系数，训练难度比连续动作低一个量级，对课设来说性价比很高。

奖励公式里的权重，我一般默认 α=0.5、β=0.5、γ=2~5。这里有个经验：时延是毫秒级、能耗是焦耳级，不归一化的话 Q 网络会被大数带走，后面专门讲这个坑。

2.3 基线与对比逻辑

有了 MDP 还不够，评判 DRL 策略到底有没有用，基线得先架起来。我拆包时最先看的就是这部分，通常有三种基线：

1. 全部本地：纯本地计算，最保守，能耗可控但时延高；
2. 最小负载贪心：卸载到当前负载最低的服务器，不看信道质量；
3. 负载均衡启发式：用“服务器剩余能力 + 信道质量”打一个加权分，选分最高的。

对比指标用四个：平均 system cost、任务超时率、卸载率、单次决策耗时。跑 100 个时隙取平均，和 DRL 放同一张表里。遗传算法也可以加进来当近似最优上界，用它来衡量 DRL 离最优解还有多远。这套对比脚本跑一遍直接出 CSV，比你自己从头造轮子省半天时间。

3. 仿真环境搭建：信道、队列、能耗的工程实现

3.1 时隙驱动的主循环结构

MEC 仿真一般用离散时隙。每个时隙的事件顺序是：生成任务 → 采样信道状态 → 做卸载决策 → 执行计算 → 更新负载和能耗。信道用瑞利衰落加路径损耗，每个时隙重新采一次，这样状态才有真实的动态性。

import numpy as np class MECEnv: def __init__(self, n_devices=5, n_servers=3, slot=0.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(scale=1e-5) # 瑞利衰落信道增益 snr = self.tx_power * gain / self.noise_power return self.bandwidth * np.log2(1 + snr) # 香农公式算传输速率

逻辑说明：环境类核心就是两个函数，_rate算设备到服务器之间的上行速率，reset负责初始化每轮实验的负载与队列。带宽、发射功率、噪声系数三个参数直接决定传输时延的大小，改场景时优先调这三个。

参数说明：slot=0.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, dtype=np.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×(1+M) 的离散选择，标准做法是 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×(1+5×4)=210，128 的隐藏层会偏紧，可以提到 256。毕设场景大多数用不到那么大的动作空间。

双 DQN 的改进点在于：主网络选动作，目标网络给 Q 值，避免单网络过估计。实现上就是两个结构一样的网络，每隔若干步把主网络权重软更新给目标网络，τ 取 5e-3。

4.2 经验回放与训练主循环

def train_loop(env, q_net, target_net, optimizer, buffer, epsilon, batch_size=128): 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, dtype=torch.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, dtype=torch.float32) s2 = torch.tensor(s2, dtype=torch.float32) r = torch.tensor(r, dtype=torch.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, tau=0.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 训练爆炸与不收敛

现象 1：loss 曲线直接变成 NaN，或者前几个 epoch 冲到 1e5 以上后陡降。 原因：奖励函数没有归一化。TD target 是 r + gamma × maxQ，r 的量级如果是几十上百，目标值超出 Q 网络输出范围，梯度一步就把权重打飞。 解决：把时延和能耗分别除以场景典型值，压到 ±1 区间，再对最终奖励做 clip。同时确认学习率不超过 3e-4，ReLU 网络配大学习率非常容易崩。

现象 2：cost 曲线从头到尾是一条平线，只比随机策略好一点。 原因：探索率衰减配错。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 实验记录导成文档

训练日志存 CSV，cost 曲线存 PNG，环境配置导出 JSON，五组随机种子的对比结果汇总成表格。这些都是毕设“实验与分析”章节的原材料。资源包里一般带好了results/目录骨架，我拿到手先照跑一遍，再改一组 reward 权重 α=0.3/0.7 做对比，两个表格摆出来，结论就立住了。

下载包里把环境配置模板、训练脚本和三个基线函数分好了目录，拿到手可以从第 3 章的代码直接跑起，跑通后再改自己的场景。

我第一版实验时，为了省时间把 epsilon 直接设成 0.6 从中间往下降，结果整整两天在一个“看起来在训、其实根本没在探索”的模型上死磕，最后发现是探索率曲线配错了。从那以后，每次起新实验，我第一件事就是把随机种子、探索率衰减曲线和奖励归一化系数写进配置文件，先跑通再优化，不再碰这个坑。希望帮到你。

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