简介面向计算机、人工智能、通信工程等方向的在校学生与开发者这份源码包提供了一个基于深度强化学习的移动边缘计算卸载与资源分配完整实现可解决多用户多服务器场景下任务调度、能耗与时延协同优化问题。打包内容共19个文件包括Python核心算法、绘图与日志分析脚本、shell一键运行配置以及简明说明文档压缩包仅113KB结构精简方便快速下载和部署。目前已有153人学习浏览代码经测试运行成功并附有仿真结果图像和运行日志便于对照复现实验、评估算法收敛效果。除直接使用完整流程外读者还可围绕其中的网络结构、动作空间和奖励设计进行扩展改造作为课程设计、毕业设计或强化学习入门项目具有较高的参考与二次开发价值。1. MEC计算卸载与资源分配这套Python源码为什么值得你自己跑一遍做移动边缘计算MEC的人多半都遇到过同一个瓶颈任务本地算还是卸载到边缘节点、卸载多少、给各用户分多少个CPU核这些决策在信道和队列动态变化时没有闭式解。深度强化学习DRL恰好提供了一条把状态映射成动作的路不需要预先知道用户移动模型也不需要离线拆信道估计直接把网络当作一个黑匣子用奖励信号训练。这套基于Python的MEC计算卸载与资源分配源码就是围绕“状态-动作-奖励”构建的一套可复现代码适合正在跑仿真实验的研究生也适合想评估DRL方案是否可行的边缘计算工程师。它解决的核心问题很简单在高动态环境下怎么让卸载决策和资源分配的效果越来越好。2. 先立场景再碰代码MEC的观测空间、动作空间与奖励设计2.1 动态计算卸载层到底在卸载什么在MEC网络里计算卸载不是简单的“全传上去”或“全留在本地”。一个任务可以被拆成两部分一部分在本地CPU执行另一部分通过无线信道发送到边缘服务器。这个拆分比例就是卸载决策的核心工程里常把它叫做动态计算卸载层。资源分配解决的是边缘节点把多少计算能力、带宽分给这个任务。二者耦合卸载比例大信道传输造成时延和设备能耗卸载比例小本地CPU排队严重。传统凸优化方法需要知道精确的信道模型和任务到达分布但在真实场景中这些参数都会漂移于是深度强化学习就顺理成章地顶了上来。在源码实现里任务的时延模型通常拆成三块本地计算时延、传输时延、边缘计算时延。如果卸载比例是x任务数据量是D_i本地计算量是(1-x)C_i本地时延等于本地部分除以设备CPU频率传输时延等于D_i * x除以信道速率边缘时延等于x*C_i除以边缘节点分配到的频率。这个简化排队模型已经能反映核心权衡传得越多传输时延越高但边缘算力弥补了本地资源不足。很多开源代码没有把本地CPU频率和边缘节点频率区分开导致训练出来的策略总在极端值上徘徊这一点后文避坑部分会单独说。状态空间里我通常会放四类信息任务信息数据量、所需CPU周期、截止期、信道状态每个设备和边缘节点之间的信道增益、边缘节点负载队列长度或CPU占用率、以及移动设备的剩余电量。动作空间依问题设定而异二值卸载场景用离散动作部分卸载加带宽分配则用连续动作。大部分开源的MEC卸载源码用的是连续动作因为这更接近真实场景卸载比例在0到1之间带宽比例也在0到1之间。奖励函数通常是延迟、能耗和系统吞吐的加权组合负权重惩罚高延迟。这里有一个新手最容易忽略的点奖励不能只看任务能不能完成。如果只给“完成1失败0”强化学习面临的稀疏奖励会让训练极慢。所以落地代码里常见的是用“资源消耗的负值”做即时奖励让每一步都有反馈。后面在避坑章节我会展开讲。2.2 用Python搭一个可交互的MEC环境骨架开源源码里MEC环境大多遵循OpenAI Gym的接口reset返回初始状态step接收动作并返回状态、奖励、完成标志。这样设计的好处是后面换成DQN、PPO或SAC都不需要改环境。下面是一个极简但结构完整的MEC环境我通常拿它当作写源码的起跳点。import numpy as np class MECEnv: def __init__(self, n_edges1, n_tasks4, max_task_len1024): self.n_edges n_edges self.n_tasks n_tasks self.max_task_len max_task_len self.n_actions 2 * self.n_tasks # 卸载比例 带宽分配 self.edge_cpu 4e9 # 边缘节点等效CPU频率 self.reset() def reset(self): # 每个周期的任务数据量、计算密度 self.task_data np.random.randint(512, 1024, self.n_tasks) self.task_cycles self.task_data * np.random.uniform(500, 1000) # 信道增益任务与每个边缘节点之间 self.channel np.random.uniform(0.1, 1.0, (self.n_tasks, self.n_edges)) self.queue np.zeros(self.n_edges) return self._get_state() def _get_state(self): # 所有特征归一化后拼接成一维向量 state np.concatenate([ self.task_data / self.max_task_len, self.task_cycles / 1e6, self.channel.flatten(), self.queue / 1000 ]) return state.astype(np.float32) def step(self, action): # 先把动作裁剪到[0,1]保证卸载比例和带宽比例合法 action np.clip(action, 0, 1) offload action[:self.n_tasks] # 卸载到边缘节点的比例 bandwidth action[self.n_tasks:] # 各任务分配的带宽比例 trans_delay self.task_data * offload / (self.channel[:, 0] * bandwidth 1e-6) comp_delay self.task_cycles / self.edge_cpu # 边缘计算时延 total_delay trans_delay comp_delay 0.1 * offload # 0.1固定开销 energy 0.5 * offload 0.2 * (1 - offload) # 简化能耗模型 reward -np.mean(total_delay) - np.mean(energy) self.queue total_delay / self.n_tasks done False # 连续决策场景一般不做终止 return self._get_state(), float(reward), done, {}逻辑说明action的前一半是各任务的卸载比例后一半是带宽分配比例。step先把动作裁剪到合法范围保证不会出现负数或超过1的荒谬值。trans_delay表示数据通过无线信道传给边缘节点的时间带宽越大时延越低comp_delay表示边缘计算时间。奖励取时延和能耗的负均值模型优化方向是让它们变小。这比稀疏奖励容易训得多。参数说明n_edges默认为1代表单基站场景要扩展成多边缘节点需要把信道矩阵维度改大并把带宽分配动作维度也改大。state里queue / 1000是为了把数值压到同一量级。状态不归一化是DRL训练里的常见翻车原因。想从这套源码起步首先得按自己机器上的Python安装教程把Python环境配好然后把numpy、torch这类基础库装齐才能好好跑后面的训练脚本。在实际源码里观测方案通常有三种写法它们决定了模型能不能学到全局协作观测方案特征构成优点缺点全局拼接所有用户任务信道边缘负载单智能体训练稳定用户数增加时维度膨胀局部观测自身任务邻居资源列更贴近多智能体场景环境非平稳性更强图像化输入信道矩阵转灰度图可用CNN提取空间特征MEC场景收益有限调试成本高如果任务是超低时延场景全局拼接并不一定好因为收集所有用户状态本身就要花时间。更多时候源码会采用全局拼接但把状态量限制在信道和任务队列这些低成本指标上。这一点看懂代码后再改会少走很多弯路。2.3 为什么选择深度强化学习而不是凸优化或启发式算法选择DRL的核心理由在于状态空间的规模和耦合性。一个5用户的MEC系统状态就有任务数据量、信道矩阵、队列长度、能量水平拼接后往往几十到上百维。凸优化需要重新建模求解启发式算法比如贪心卸载最多的任务很容易在动态信道下失衡。深度强化学习可以用一个函数近似器把这套映射关系学出来并且靠经验回放复用历史样本。具体到算法选择如果动作空间是离散的DQN即可但如果卸载比例和带宽都是连续值DDPG、TD3、PPO是开源源码里更常见的选择。DDPG对参数敏感PPO稍稳但样本效率偏低。我一般建议先从PPO跑通再换DDPG调极限性能。这个顺序能省掉大量排错时间。还有一个现实理由Python生态里已经有Stable-Baselines3这类现成算法库环境封好后只需要配置policy代码量很小。同时也要明确边界DRL不保证全局最优它只保证在奖励函数定义下找到一个好的策略。如果某个系统本身可以用线性规划精确求解就不要硬上深度强化学习。MEC真正值得用DRL的场景是状态高维、任务动态到达、信道时变且没法快速重解凸问题的在线场景。把这一点想清楚后面调参才有方向。3. 读懂源码骨架从Actor-Critic网络到经验回放与多智能体边界3.1 用PyTorch构造适用于MEC连续动作的Actor-Critic网络在MEC卸载源码里最常见的网络骨架不是多层CNN而是全连接MLP因为状态是由任务数据量、信道矩阵、队列长度拼成的向量没有明显的二维局部结构。这里给一个可改的ActorCritic模块后面既能搭PPO也能搭DDPG的主干。import torch import torch.nn as nn import torch.nn.functional as F class ActorCritic(nn.Module): def __init__(self, state_dim, action_dim, hidden256): super().__init__() self.fc1 nn.Linear(state_dim, hidden) self.fc2 nn.Linear(hidden, hidden) self.actor_mean nn.Linear(hidden, action_dim) self.critic nn.Linear(hidden, 1) def forward(self, x): x F.relu(self.fc1(x)) x F.relu(self.fc2(x)) return self.actor_mean(x), self.critic(x) def get_action(self, state): mean, _ self.forward(state) return torch.sigmoid(mean) # 强制映射到(0,1)逻辑说明get_action用sigmoid把连续动作压到(0,1)正好对应用户卸载比例和带宽比例。如果某个卸载比例在需求中只能取0或1这种二进制值可以把sigmoid输出四舍五入作为训练时的探索动作但梯度更新不能用四舍五入后的值否则整个反向传播就断了。这是很多开源代码没写清楚的地方。参数说明Actor和Critic共享前两层隐藏层。MEC状态维度通常不高256个隐藏单元足够。如果场景包含多个边缘节点可以增加到384或512但更宽不一定带来收益反而增大训练方差。网络初始化本身也值得关注nn.Linear的默认初始化会让actor_mean输出值偏大直接进sigmoid会导致初始动作接近0或1冷启动就饱和。我一般会把该层权重乘0.01for name, param in net.named_parameters(): if actor_mean in name and bias not in name: param.data.mul_(0.01)这样初始动作会靠近0.5每个卸载比例都有合理的探索空间。3.2 经验回放为什么MEC任务必须用它而不是在线学习在线学习在MEC场景下几乎不可行。相邻两个时隙的信道状态高度相关环境是非平稳的。如果只用当前转移样本做梯度下降训练信号方差极大网络容易把上一时刻的偶然相关当成规律。经验回放缓冲先存下大量样本再均匀或按优先级采样让采样分布尽量覆盖不同的信道和负载状态。这个技巧在DQN里是基石在DDPG/PPO里同样是主流做法。一个常用的ReplayBuffer实现如下from collections import deque import numpy as np import random class ReplayBuffer: def __init__(self, capacity50000): self.buffer deque(maxlencapacity) def push(self, s, a, r, s_next, done): self.buffer.append((s, a, r, s_next, done)) def sample(self, batch_size64): batch random.sample(self.buffer, batch_size) s np.asarray([t[0] for t in batch], dtypenp.float32) a np.asarray([t[1] for t in batch], dtypenp.float32) r np.asarray([t[2] for t in batch], dtypenp.float32) s_next np.asarray([t[3] for t in batch], dtypenp.float32) done np.asarray([t[4] for t in batch], dtypenp.float32) return s, a, r, s_next, done逻辑说明deque(maxlen50000)会自动弹出最老样本。样本统一转成np.float32这样后面转torch tensor时不会出现double和float匹配报错。参数上容量不必过大5万条对一个中等规模MEC仿真已经足够太大会让新策略产生的优质样本占比太少训练偏向旧分布。如果信道变化很快可以把容量降到2万左右让回放样本更贴近当前环境分布。3.3 源码文件结构与多用户场景的集中化设计一套可用的MEC-DRL源码通常不会只有一个脚本而是按职责拆开。常见的布局是mec_env.py负责环境状态、奖励和动作约束network.py负责网络结构memory.py负责经验回放config.py放超参数和路径train.py放训练循环和评估函数。我自己会在train.py里保留一个eval函数每隔一定步数评估一次当前策略而不是等训练完才一次性测试否则很难判断是训练在涨还是环境在泄漏信息。很多源码会把MEC场景做成多用户共享一个边缘节点这其实接近多智能体环境但只用中心化控制器控制所有用户的卸载决策。此时状态维度是用户特征拼接动作维度是所有用户的卸载参数和资源分配参数网络输入输出规模随用户数线性增长。经验回放中的状态如果包含前一个时刻的动作就会带来自循环依赖改代码时要特别小心。常见做法是只把上一时刻的观测喂进去不把上一动作喂进去除非环境本身需要记忆。如果需要记忆就要把全连接层换成GRU或LSTM模块。算法选型也直接影响源码结构下面这张对比表可以帮你判断手里的场景该往哪个方向改算法动作类型MEC场景适用性参数敏感性DQN离散/二值卸载只做任务卸载选择时够用目标网络更新频率敏感DDPG连续卸载比例带宽分配适合高超参数需要细调PPO连续或离散鲁棒但样本效率偏低中适合先跑通如果只是把源码跑一遍验证可行性首选PPO如果要做对比实验且接受大量调参再上DDPG。DQN在这类连续资源分配任务里表现通常不如连续动作算法因为带宽分配被离散化后精度损失太大。4. 训练主循环从最小可跑脚本到三个关键超参数4.1 最小可跑脚本用Stable-Baselines3跑通MEC环境MEC环境写好之后不需要自己从零实现PPO。Stable-Baselines3是Python生态里最常用的PyTorch强化学习库环境只要满足reset/step接口就能直接训练。先装依赖再训练pip install numpy torch stable-baselines3from stable_baselines3 import PPO from mec_env import MECEnv env MECEnv(n_edges1, n_tasks4) model PPO(MlpPolicy, env, verbose1, learning_rate3e-4, gamma0.99, n_steps2048, batch_size64, ent_coef0.01, clip_range0.2, seed0) model.learn(total_timesteps100_000) model.save(mec_ppo)逻辑说明PPO处理连续动作不需要目标网络训练相对稳定。MlpPolicy会自动读取环境的observation_space和action_space维度。model.learn内部会完成经验收集、优势计算和梯度更新所以外部只需要关注参数配置。参数说明n_steps是每次更新前收集的步数2048是常用值ent_coef0.01鼓励探索避免过早收敛到局部策略clip_range0.2控制新旧策略差异太大容易发散seed0保证同一份源码在正常情况下可以复现。如果训练时奖励曲线波动很大可以先提高n_steps到4096再降学习率。训练结束后加载模型做一次确定性评估import numpy as np env MECEnv(n_edges1, n_tasks4) model PPO.load(mec_ppo) obs env.reset() rewards [] for step in range(200): action, _ model.predict(obs, deterministicTrue) obs, r, done, _ env.step(action) rewards.append(r) if done: obs env.reset() print(avg reward:, np.mean(rewards))这里用deterministicTrue关闭探索噪声测的是策略本身的水平。如果平均奖励明显低于训练日志里的最终值说明训练过程中有评估偏差而不是策略失效。4.2 训练主循环背后经验收集、优势估计与更新直接调库能跑通但改参数时最好知道主循环里发生了什么。PPO每过n_steps步会把这批轨迹按gamma计算回报再用策略网络和值网络估计优势。样本通过小批量更新若干轮clip_range控制每轮更新的最大幅度。这套机制天然适合MEC一条轨迹里信道是连续变化的梯度更新时不会因为某个异常时隙的奖励而大幅震荡。如果你的源码选择自己写DDPG那么必须额外维护目标Actor网络和目标Critic网络。经验回放缓存中采样后用目标网络计算TD目标再用软更新缓慢同步目标网络参数。这个软更新系数叫tau常见值为0.005。调参时记住一点tau太小会让目标值收敛很慢太大则训练不稳定。相比PPODDPG对参数敏感得多所以不建议从它开始。4.3 超参数表与选择理由以下参数是我在MEC卸载任务里常用的初始值复制到config.py里再调参数常用初始值调参方向learning_rate3e-4太高容易发散太低学不动gamma0.99任务延时要求苛刻时降到0.95n_steps2048增大到4096减少梯度方差batch_size64不敏感但不要超过n_stepsent_coef0.01前期可到0.02后期降到0clip_range0.2别超过0.3buffer_size50000信道快速时变时降到20000gamma这个参数很多后台开发容易忽略。如果系统要求任务在几十毫秒内完成那么未来回报的时间尺度很短gamma0.99意味着模型把几十步之后的奖励看得太重可能学不到“尽快卸载”的导向。我一般会按任务平均时延步数设任务平均5步完成就把gamma设为0.9左右。这是源码改动里成本最低但收益明显的一处。4.4 用TensorBoard观察训练趋势真实收敛的判定标准Stable-Baselines3自带TensorBoard日志训练时加上tb_log_name即可model.learn(total_timesteps100_000, tb_log_namemec_ppo)终端启用TensorBoardtensorboard --logdirlogs训练是否有效不要只看rollout/ep_rew_mean是否上涨。我一般会同时看两个东西一是平均值是否持续抬升二是方差是否在缩小。平均值涨但方差巨大说明策略在不同信道条件下忽好忽坏有时候是探索噪声太大有时候是奖励函数里有个别极端样本在主导梯度。另一个重要指标是rollout/ep_ent也就是策略熵。如果它过早降到接近0说明策略已经锁定某个动作而奖励还没起来这时需要提高ent_coef或者减少learning_rate让策略别太早自满。5. 避坑实录训练发散、结果无法复现和动作边界问题5.1 奖励曲线不涨反跌先查状态归一化和奖励尺度现象训练几千步后reward还在下降或者始终在一个水平抖动。日志里loss正常但平均奖励就是上不去。原因状态各维量级差异过大是头号嫌疑。比如task_data在512到1024channel在0.1到1.0queue可能累积到几千。网络默认认为所有输入地位相等数值大的维度会主导梯度。奖励绝对值如果上万梯度更新也会随着奖励尺度暴涨导致模型越训越乱。解决打印一次env._get_state().max()和env._get_state().min()如果max超过100就需要归一化。常见做法是训练前跑几百步记录每个维度的均值和标准差然后在环境里固定住def _normalize_state(self, state): return (state - self.state_mean) / (self.state_std 1e-8)不要用np.random.seed去控制所有状态分布归一化统计量本身也要固定否则同一个环境每次采样到的状态尺度不同复现实验还是会翻车。5.2 随机种子设了还是翻车PyTorch、NumPy和SB3各管各的随机数现象训练两次明明在代码开头写了np.random.seed(0)和torch.manual_seed(0)最终奖励曲线还是不一样。原因环境、网络、动作采样、经验回放采样都依赖随机源。Stable-Baselines3内部有独立的seed环境类里如果继续用全局np.random那么它的随机序列会受其它库调用顺序影响。比如某个库在环境前先消耗了随机数后续轨迹就完全变了。解决在环境类里实现seed方法并把环境创建和模型训练串起来class MECEnv: def seed(self, seed): self.rng np.random.default_rng(seed) def reset(self): self.task_data self.rng.integers(512, 1024, self.n_tasks) ...然后把seed传给环境后在训练时也传入seed0。这样环境随机源和算法随机源分开同版本依赖下基本能复现。5.3 卸载比例总在0和1附近饱和资源分配被当成废动作现象训练结束后所有任务的offload都在0.01或0.99附近带宽分配维度几乎没有差异。奖励曲线虽然收敛但系统吞吐并没有想象中好。原因sigmoid的输入一旦超过正负5就会饱和梯度反向传导变得很弱。另一个原因是奖励函数只惩罚总时延那么模型发现全卸载或全本地最省事就没有动力去学精细的资源分配。解决在奖励里加一个中间比例正则鼓励动作不要停在极端值offload action[:self.n_tasks] reward - 0.05 * np.abs(offload - 0.5).mean()更根本的改动是让信道质量差异化更明显使不同任务的最优卸载比例确实不同否则模型当然会收敛到单一策略。这个正则的系数不要超过0.1否则会掩盖原始时延目标。5.4 经验回放里动作维度不匹配能训练但结果一直差现象loss正常下降但评估结果远不如训练途中的最好成绩。有时还会随机出现一次nan然后又恢复了。原因多用户源码里经常把动作按用户拆分保存比如每个用户各自存一份push进去时没有拼回完整维度。训练时采样的动作和状态不对齐相当于给模型喂了错位数据。解决在push前做维度校验def _validate_step(self, state, action, next_state): assert state.ndim 1 and next_state.ndim 1 assert action.shape (self.n_actions,), faction dim {action.shape} ! {self.n_actions} if not np.isfinite(action).all(): raise ValueError(action contains nan/inf)这个函数成本很低但能把隐藏问题在训练前暴露出来避免数据错位消耗大量时间。5.5 多用户各自独立环境资源竞争永远学不会现象单独训练一个用户的MEC环境时收敛很好把多个用户各自的环境串行训练后总吞吐反而下降。原因每个用户只看自己的信道和任务看不到边缘服务器的总负载。资源分配本质上是共享边缘节点计算能力和带宽如果奖励里没有体现竞争关系模型学不到合作。解决把多用户放进同一个MECEnv状态拼接所有用户的任务与信道特征动作拼接所有用户的任务卸载比例和带宽分配奖励取所有用户总时延和总能耗的均值。如果坚持用多智能体结构至少也要采用集中训练、分散执行的框架不然每个智能体都会把边缘资源当作无限资源来用。第一次实现不要拆成多个独立环境优先做集中式控制等基线跑通再扩展。6. 把源码接到自己的业务场景一小时上手验证的可移植技巧6.1 用域随机化提升策略在真实信道下的鲁棒性MEC仿真的信道模型永远是简化的。从源码迁移到实际基站环境时最常见的失败是仿真里收敛的策略换个信道分布就报废。我会在环境里每个episode结束时重新采样信道参数比如把快速衰落增益和噪声方差在一个范围内随机改强迫策略见到多种分布。Stable-Baselines3里直接在step的生成逻辑里每个episode调用一次np.random.uniform即可。这个方法叫domain randomization不需要改算法却能明显提升策略泛化能力是源码改动里投入产出比很高的一种。6.2 训练是否有效先盯住这三个指标不要只盯着一行平均奖励。我通常会在TensorBoard里同时设三项rollout/ep_rew_mean看综合健康度rollout/ep_ent看动作熵是否过早降为0如果熵已经很低且奖励还很差说明策略陷入确定性局部最优第三个是卸载比例均值这个指标需要在环境里记录并写进info它直接告诉你是策略在调整资源分配还是在某个边界附近死磕。如果平均卸载比例长期贴着0或1回看5.3的奖励正则比调学习率有效得多。我第一次把这套源码接到自己的多节点场景时犯过的最低级错误是把边缘节点算力放到了类变量而不是实例变量里导致所有episode共享一个不断累加的CPU状态。训练曲线看着在收敛其实模型根本没区分不同时隙的边缘负载。后来我把环境里所有随机参数的生成顺序写死并且每个episode打一条日志问题立刻暴露了。希望这个排查顺序能帮到你先做状态归一化和动作维度校验再用现成算法库跑通小环境最后盯三个指标决定要不要改网络结构而不是一上来就追求改算法。本文还有配套的精品资源点击获取