多智能体深度强化学习的车联网资源分配：建模、训练与验证

简介面向车联网通信资源分配优化这份资源包基于多智能体深度强化学习方法MADDPG旨在解决车辆自组织网络中频谱与功率分配的效率与安全问题适合人工智能及深度学习方向的学生、研究人员参考学习。压缩包共包含19个文件其中13个为可读写的源代码脚本6个为运行时生成的缓存文件整体体积仅70KB源码按功能拆分为环境模拟、算法实现、经验回放、模型网络等模块涵盖环境构建、多智能体训练、经验池管理与网络定义等脚本结构清晰易于按需定位。目前已有519人学习下载借助完整代码可直观理解环境状态定义、智能体交互决策到资源分配策略收敛的全过程同时内置多种算法对比实现既可作为教学示例也能充当课程设计、毕业设计或论文复现的改进基座。对想深入研究车联网资源管理或协作式决策的开发者这套代码免去了从零搭建环境的繁琐可直接调整参数与奖励函数运行实验快速验证不同方案的可行性。1. 多智能体深度强化学习的车联网资源分配工程绕开什么样的墙做过车联网调度的人都有体会在密集城区十字路口V2V安全消息和V2I业务挤在同一个频段每辆车每隔 100ms 就要重新抢资源块和功率基站侧算一次凸优化要等全局信道增益算完信道早变了。单智能体强化学习更悬动作空间随车辆数膨胀而且其他车都被当成环境噪声训练基本靠运气。这份基于多智能体深度强化学习的车联网通信资源分配优化工程包把每个车端当独立智能体用集中式训练、分布式执行的方式训练资源分配策略解的是 V2V 时延满足率和 V2I 吞吐量这个多目标。适合正在做这个方向的研究生、毕设生或者准备做专利验证和算法对比的工程师。下面从建模、跑通、踩坑到验证完整拆一遍。2. 把资源分配问题写成多智能体MDP状态、动作、奖励设计的四个关键点2.1 为什么凸优化和单智能体DRL都卡在移动性上车联网的资源分配传统上是一个组合优化问题在给定资源块RB集合、功率档位和信道状态的前提下找到使加权总速率最大或满足用户最多的分配方案。这个题目在静态小场景里很好解经典做法是二分图匹配、匈牙利算法、加权最小干扰或者用凸松弛做功率控制。可车联网不是静态的车辆以 80km/h 在十字路口之间移动信道相干时间在毫秒级一辆车从阴影里冲出来信道增益可能变化 8~10dB。基站在第二次测量时得到的信道信息到执行时已经过期集中式优化还要承担信息汇聚延迟算得再准也用不上。单智能体深度强化学习解决了一部分时效问题策略网络可以在端上推理不需要等中央调度。但它把整个网络的动作空间集中到一个动作头上每增加一辆车动作维度就增加几个连续或离散量。智能体要同时输出所有车的 RB 选择和功率本质上是让一个大网络拟合一个高维组合动作训练速度慢奖励稀疏时基本出不来。更内核的问题是单智能体把其他车的策略变化当作环境的一部分而其他车也在学习它们不是平稳的随机噪声是“有意图的对手”。这会让价值函数估计失去一致性出现你这边奖励在涨那边策略一变又崩回去的情况。多智能体深度强化学习MARL换了个建模方式每辆车是一个带独立 actor 网络和 critic 网络的智能体。actor 只看自己可观测到的东西比如 GPS 位置、速度、前车距离、最近一次测量的 SINR然后决定自己的 RB 和功率。critic 在训练时拿到全局所有车辆的观测和动作做出一个相对准确的价值评估。这种范式叫 CTDE是车联网资源分配里最常用的深度强化学习算法框架之一。多智能体强化学习的核心价值就是不再把“其他车的动作”当作环境噪声而是当作联合策略的一部分来学习。2.2 最小环境状态、动作、奖励的定义附 Python 代码从实际拆包经验出发这类资源里的环境通常被简化为V2XResourceEnv负责模拟每辆 V2V 车辆和 V2I 链路的信道快衰、RB 选择和功率控制。工程包最常见的做法是用路径损耗加瑞利快衰生成信道增益矩阵用一次循环结算 day 内所有车辆的 SINR 和速率。这个模型比 OMNeT/Veins 那套轻得多省掉编译仿真器的时间足够验证深度强化学习算法本身的收敛性。下面是核心接口我习惯先跑通这个最小闭环再改模型import numpy as np class V2XResourceEnv: def __init__(self, n_v2v4, n_v2i4, n_rb6, max_power_dbm23, seed0): self.n_v2v n_v2v self.n_v2i n_v2i self.n_rb n_rb self.max_power_dbm max_power_dbm self.rng np.random.default_rng(seed) self.current_step 0 # 车辆位置、速度和信道快照每次 reset 时重新生成 self.positions self.rng.uniform(0, 500, size(n_v2v, 2)) self.speeds self.rng.uniform(20, 80, sizen_v2v) def reset(self): self.current_step 0 # 简化的快衰信道增益服从指数分布等价于瑞利包络平方 self.channel_gain self.rng.exponential(1.0, size(self.n_v2v, self.n_rb)) obs np.hstack([self.positions / 500.0, self.speeds[:, None] / 80.0, self.channel_gain]) return obs.astype(np.float32) def step(self, actions): # actions: shape (n_v2v, action_dim)action_dim2 # 第一维是 RB 编号离散第二维是功率档位连续 rb_choices actions[:, 0].astype(int) power actions[:, 1] * (self.max_power_dbm - 5) 5 # 映射到 5~23dBm # 计算同 RB 干扰、SINR、吞吐量和时延 reward self._compute_reward(rb_choices, power) self.current_step 1 return np.zeros_like(obs), reward, False, {rb_choices: rb_choices} def _compute_reward(self, rb_choices, power): # 允许两辆车共享 RB但干扰会使容量下降 interference np.zeros(self.n_v2v) for i in range(self.n_v2v): for j in range(self.n_v2v): if i ! j and rb_choices[i] rb_choices[j]: interference[i] power[j] * 0.1 # 简化互干扰系数 sinr self.channel_gain / (interference 1e-6) rate np.log2(1 sinr) * (power / 23.0) delay_satisfied (rate 2.0).mean() reward 0.6 * delay_satisfied - 0.2 * np.abs(power - 15).mean() 0.01 * rate.mean() return reward这段环境代码的重点不是信道模型有多准而是把多智能体问题的输入输出边界确定下来。状态里我放进了位置、速度和信道增益快照实际工程包里还会加邻居车数量和最近一次传输的 ACK 时延。动作第一维是 RB 编号的整数选择第二维是功率档位的连续值这样让算法必须同时处理离散和连续混合动作比纯连续动作更贴近真实协议栈。功率映射参数网络输出 0 到 1乘上 18 再加 5对应 5 到 23dBm避免让网络直接裸输出 dBm 值造成权重震荡。奖励函数是资源分配优化里最敏感的部分。这里我把奖励拆成三个部分V2V 安全消息的时延满足率、功率消耗惩罚、以及吞吐量的小幅正向激励。0.6、0.2、0.01 这几个系数的含义是第一优先保证安全消息达标第二控制功率不要总打到满格第三让系统还有动力去提升总吞吐量。如果你把 0.01 改大智能体会倾向牺牲时延换速率改小深度学习信号太弱奖励训练曲线会非常稀疏。状态 / 动作 / 奖励维度含义车辆位置2归一化到 500m 范围车速1除以 80km/h 归一化信道增益快照n_rb每个 RB 上的快衰增益RB 选择1离散动作范围 0~n_rb-1功率档位1连续动作映射到 5~23dBm奖励分量 11V2V 时延满足率权重 0.6奖励分量 21功率偏离惩罚权重 0.2奖励分量 31吞吐量正向激励权重 0.01这个表是调参的起点不是标准答案。把它写出来是为了让你在看代码时能快速定位“某个网络输出到底在控制什么”。2.3 从 DDPG 到 MADDPG为什么 CTDE 范式管用单智能体 DDPG 里actor 吃局部观测critic 吃全局状态。MADDPG 把这个思路复制到 N 个智能体身上区别是每辆车的 critic 在训练时输入所有车的观测和动作但在执行时 actor 只用自己的局部观测。集中式训练解决了“对手在变”的问题分布式执行解决了实时通信开销的问题。MADDPG 的核心更新片段我通常长这样def update(actor, critic, target_actor, target_critic, replay_buffer, batch): obs_all, action_all, reward_all, obs_next_all, done_all replay_buffer.sample(batch) # 目标 Q 值用 target actor 生成下一步动作 with torch.no_grad(): next_actions torch.cat([target_actor(obs_next_all[:, i]) for i in range(n_agents)], dim-1) target_q target_critic(obs_next_all, next_actions) target_q reward_all gamma * target_q * (1 - done_all) # 预测 Q 值critic 吃全局观测和全局动作 q_pred critic(obs_all, action_all) critic_loss F.mse_loss(q_pred, target_q) critic.optimizer.zero_grad() critic_loss.backward() critic.optimizer.step()这段代码有三个关键参数gamma通常取 0.99因为资源分配是一个长期调度决策不能太短视tau取 0.01 做软更新target 网络的参数慢速跟随batch_size 取 128太小 Q 的方差大太大在车联网这种动态场景里学不到近期分布。我在试验里发现MADDPG 的 critic 输入不需要堆上一整帧原始信道矩阵把每辆车的观测拼接成定长向量就够了前提是观测里已经做了归一化。为什么从 DDPG 扩到 MADDPG 之后就能收敛因为每辆车只关心自己的平均奖励而 critic 统一评估全局联合动作让智能体学到配合——比如我抢 RB 时看到邻居也在抢会自动偏向另一个 RB。这比单智能体把众多车辆动作都压成一个动作头好收敛得多。3. 把训练跑起来工程包结构、依赖安装与最小场景复现现在进入落地。打开工程包常见的目录分层是这样的。3.1 打开压缩包之后模块划分multi_agent_v2x_rl/ ├── configs/ │ └── v2x_small.yaml ├── env/ │ ├── __init__.py │ ├── v2x_env.py │ └── channel.py ├── algo/ │ ├── maddpg.py │ ├── buffer.py │ └── model.py ├── train.py ├── evaluate.py └── scripts/ └── run_small.sh配置、环境、算法、入口分离得比较干净。channel.py负责生成信道快照maddpg.py是 actor-critic 和更新逻辑model.py放 Q 网络和策略网络的定义evaluate.py用于加载训练好的权重做推理。我拆过的几个版本基本都是这个结构。如果里面没有ble、omnetpp之类的仿真器那就是用简化信道模型替代了完整的车载网络仿真这能省掉 OMNeT 和 Veins 一整套编译环境的搭建时间代价是信道模型的粒度比较粗结论适合做算法对比而不是协议级精度验证。3.2 建立虚拟环境与安装依赖cd multi_agent_v2x_rl python -m venv .venv source .venv/bin/activate pip install numpy scipy matplotlib torch先建虚拟环境再装依赖。torch 默认安装的是 CPU 版如果你的机器有 CUDA按官方命令安装对应 cuda 版本。这个工程包没有复杂依赖numpy 用于信道和奖励计算scipy 用于随机数matplotlib 画训练曲线。不要用系统级 pip install车联网方向经常要反复改依赖版本虚拟环境是后悔药装坏了直接删掉重来。3.3 最小场景配置与训练入口我用一个最小场景验证链路4 辆 V2V4 辆 V2I6 个 RB。配置文件长这样env: n_v2v: 4 n_v2i: 4 n_rb: 6 max_power_dbm: 23 episode_length: 20 algo: gamma: 0.99 tau: 0.01 lr: 1e-4 batch_size: 128 buffer_size: 50000 total_steps: 200000配置里episode_length: 20非常关键。车联网资源分配在工程上常用 1 秒一个 episode每 100ms 一个 step20 步就是一个调度窗口的完整轨迹。如果 episode 太长车辆已经无意义地漂移出网络范围训练曲线会产生周期性的陡降干扰判断。lr: 1e-4是很多场景下都比较稳的学习率再大容易 Q 值爆炸再小收敛太慢。训练入口的循环在工程包里是这样from env.v2x_env import V2XResourceEnv from algo.maddpg import MADDPG env V2XResourceEnv(n_v2v4, n_v2i4, n_rb6) agents MADDPG(n_agents4, obs_dimenv.obs_dim, act_dim2, argsargs) replay_buffer ReplayBuffer(capacityargs.buffer_size) for step in range(args.total_steps): obs env.reset() done False while not done: actions agents.select_actions(obs) obs_next, reward, done, info env.step(actions) replay_buffer.push(obs, actions, reward, obs_next, done) if len(replay_buffer) args.batch_size: agents.update(replay_buffer, args.batch_size) obs obs_nextselect_actions在训练时会加噪声比如高斯噪声或 OU 噪声避免策略早熟地固定到同一组动作。注意actions是形状(n_agents, 2)每个智能体输出一个 RB 索引和一个连续功率env.step需要把它们合并起来才能计算奖励。这是多智能体和单智能体训练的显著区别你在 debug 时看到某个 agent 的 loss 正常、但整体奖励不涨往往就是三个智能体的动作拼接顺序和 env 里的 reward 计算对不上。3.4 观察训练曲线先确认链路通了训练不是跑完等结果。我一般会每 1000 步打印一次平均奖励同时把平滑曲线画出来。最小场景至少要在 2 万步内看到奖励从负值爬到正值否则不是硬件问题就是奖励尺度问题。import matplotlib.pyplot as plt import numpy as np rolling np.convolve(rew_history, np.ones(50) / 50, modevalid) plt.plot(rolling) plt.xlabel(step) plt.ylabel(mean reward) plt.title(v2x small scenario training curve) plt.savefig(train_curve.png, dpi150)这里不装 tensorboard 也行matplotlib 足够用。判断收敛的一个经验标准在最后 5 万步里平均奖励的均值与标准差之比超过 3并且不能有大起大落。如果有周期性的断崖回去看episode_length和随机车辆初始位置通常是车辆在 episode 结束时被 reset 造成的分布跳变。4. 多智能体强化学习训练避坑奖励尺度、RB冲突与Q值爆炸这一章是血泪经验我在这个方向翻过不少车。下面几条按“现象 → 原因 → 解决”的顺序写每一条都值得在调参前读一遍。4.1 现象critic loss 降得很低但奖励曲线一动不动我最初训练时看到 critic 的 mse 降到 0.01觉得模型学得很好了。再看平均奖励还是负数像在原地打转。原因出在奖励尺度我一开始把奖励单位用成了 Mbps 和毫秒数值在几十到几千之间Q 值也巨大。这个状态下actor 对 Q 值梯度的响应几乎被淹没而且奖励里“时延满足”是稀疏的二值信号大多数 transition 的 reward 都是 0critic 只需要学会输出 0 就能把 loss 压到很低。解决方法是把奖励压到 [-1,1] 区间并用“比较项”替代“绝对值项”V2V 时延满足率高于 90% 给 0.5低于 50% 给 -0.5中间线性过渡。这样 critic 无法偷懒actor 也能得到和 Q 值同尺度的梯度。4.2 现象所有智能体训练后都抢同一个 RB训练完后我把 RB 选择画成热力图发现 6 辆车全压在 RB 3 上。奖励函数里我给了 V2V 时延满足率 0.6 权重但没考虑 RB 冲突结果智能体发现只要自己的发射功率足够高单独看自己的 SINR 还能接受而“其他车也在同一个 RB”这个事实被 critic 低估了——尤其是早期训练时 Q 值还没收敛。解决办法有两招第一在奖励上直接加冲突惩罚统计每个 RB 上活跃智能体数量对超过 1 的车辆乘以惩罚系数第二把功率映射的上限调低比如从 23dBm 降到 13dBm让抢同一 RB 的代价在实际信道模型里自动变大。我实际调试时先用惩罚训练稳定后再把惩罚慢慢降到 0让 critic 学着处理这样曲线不会断层。4.3 现象V2V 时延满足率 95%V2I 吞吐量却只有随机分配的一半这是一个典型的多目标失衡。前面说的奖励权重 0.6 和 0.01 差距太大智能体发现只要把 V2V 保住就能拿到大部分奖励V2I 的吞吐量基本被放弃。我一开始没在意直到对比 V2I 业务时才看到吞吐量曲线掉得离谱。解决方法是把 V2I 相关的奖励项也拉到和 V2V 同等量级然后用动态权重每 2000 步统计这两个指标的指数移动平均让权重反比于当前表现低于目标线的目标增大权重高于目标线的减少权重。经过这样调整V2V 从 95% 降到 88%V2I 从 50% 升到 85%整体仍然划算。4.4 现象训练到中段突然崩溃Q 值指数爆炸这个现象非常有辨识度前面 5 万步训练曲线稳步上升到某个点突然掉头向下而后 critic 里的 Q 值出现持续增大的尖峰。原因是 replay buffer 里的旧 transition 和当前策略严重不匹配随着策略变得激进它开始频繁探索高干扰的 RB 组合buffer 里还有大量早期保守策略的样本critic 基于混合分布的 TD target 方差很大。常见的解决套路是把 buffer_size 从 5 万降到 1 万到 2 万让采样分布贴近当前策略同时把 target 网络的 tau 从 0.01 降到 0.005让价值估计更慢跟上。还有一招是给 Q 值做梯度截断torch.nn.utils.clip_grad_norm_(critic.parameters(), 1.0)我试下来这个 1.0 的范数截断能有效阻止爆炸特别适合 MADDPG 这种多 critic 联合更新的场景。4.5 现象训练 6 辆车测试时加一辆车性能直接崩多智能体强化学习里这叫“不对 N 泛化”。工程包里如果 actor 网络输入是固定维度obs_dim是6*state_dim那么模型天然只能处理定长状态。测试时如果车辆数超过训练数输入 shift 一下位置就全错了。解决思路是在观测设计上就考虑变长用最大车辆数做 pad 填充不足则补 0同时在奖励和动作里做一个 mask让无效车辆不参与计算。如果不想改网络结构就老老实实用固定车辆数训练测试时也固定数量只在速度、位置和信道条件上做泛化。这些坑几乎在每一次调参里都会碰到尤其是奖励设计和 buffer 大小。我建议把 4.1 和 4.4 作为每次换新场景前的必查项这两个问题隐藏得最深也最容易让训练跑一个晚上之后才发现全白跑了。5. 训练完怎么验证对比基线、三次种子与可变数量泛化训练完不是结束。资源里通常已经留了evaluate.py我自己验证时会做三件事。第一跑三个基线随机 RB 分配、固定功率均匀分配、以及训练出的 MADDPG 策略。每个方法跑 50 个随机生成的场景统计 V2V 时延满足率和 V2I 吞吐量的均值。关键是要用同一个随机种子列表保证三组策略遇到完全相同的交通和信道序列不然对比不公平。代码上我会把测试场景的种子固定成一个 list而不是每次np.random.seed(None)。第二换三个不同随机种子重训一遍取训练曲线的中位数画图。强化学习的一次 run 有很强随机性单次曲线漂亮不能说明策略稳定。我习惯画出三条半透明曲线和一条中位数粗线只有三条曲线趋势一致才会认为这个工程包的调参是可靠的。第三测试可变车辆数的泛化性。如果 actor 网络是定长输入就固定车辆数测试如果支持 mask从 4 辆一路加到 10 辆看 V2V 时延满足率是不是在可接受范围内缓慢下降。有一回我把奖励权重 V2V 设成 0.9、V2I 设成 0.1训练曲线漂亮得很但一上可变车辆数测试V2I 吞吐量只有随机分配的三成。问题不在网络结构就在奖励权重失衡。从那以后我每次训练完都强制走一遍这三步验证流程先跑最小场景、再做基线对比、最后测试泛化能力。车联网资源分配最忌讳只刷一个场景的奖励曲线测试场景一变就露馅。希望帮到你。本文还有配套的精品资源点击获取