常见 PyTorch 错误和解决方案

与梯度相关的错误 [新手]

新手在从头开始编写 RL 算法时经常会遇到与梯度相关的问题。典型的训练循环通常可以概括如下

obs = env.reset()

for _ in range(n_training_steps):
    # STEP 1: data collection
    # Get a new datapoint "online"
    observations = []
    actions = []
    others = []
    for _ in range(n_data_per_training):
        with torch.no_grad():
            action = policy(obs)
        obs, *other = env.step(action)
        observations.append(obs)
        actions.append(action)
        others.append(other)
    replay_buffer.extend(observations, actions, others)

    # STEP 2: loss and optimization
    # => compute loss "offline"
    loss = loss_fn(replay_buffer.sample(batch_size))

    loss.backward()
    optim.step()
    optim.zero_grad()

一系列错误源于想要通过由 no_grad() 上下文管理器修饰的策略操作进行反向传播。实际上，此操作（在大多数情况下）不应成为任何计算图的一部分。相反，所有可微分的操作都应在 loss_fn(...) 抽象中执行。一般来说，RL 是一个领域，人们应该注意充分理解哪些应该被认为是不可微分的“数据”（例如，环境交互、优势和回报计算、PPO 中的“分母”对数概率），哪些应该被认为是可微分的损失产物（例如，价值误差、PPO 中的“分子”对数概率）。

要查找的可能与此误解相关的错误如下

• RuntimeError: Trying to backward through the graph a second time (or directly access saved tensors after they have already been freed). 此错误通常在损失函数中两次使用属于计算图的数据点后出现。一些用户尝试通过调用 loss.backward(retain_graph=True) 来修复此问题，但这将导致此列表中的下一个错误。 相关讨论的 PyTorch 错误

  • 此处

  • 此处

• RuntimeError: one of the variables needed for gradient computation has been modified by an inplace operation 这通常在用 retain_graph=True 标志修复第一个错误后发生。相反，要通过其微分的操作应该在 loss_fn 中重新计算。另一个常见原因是两个模块使用共享的计算图（例如策略和评论家）进行更新。在这种情况下，应该使用 retain_graph=True 标志，但应该小心，因为这可能会将一个损失的梯度累积到另一个损失上。一般来说，更好的做法是为每个损失单独重新计算每个中间值，同时排除特定图中不需要的参数，即使某些子模块的前向调用匹配也是如此。 相关讨论的 PyTorch 错误

  • 此处

  • 此处

• 算法不学习 / param.grad 为 0 或 None。算法不学习可能有多种原因。首先要查看的是参数梯度的值，其范数应严格非负。 相关 PyTorch 讨论的错误

  • 此处

我的训练太慢 [新手 / 中级]

• 众所周知，RL 在某些情况下是 CPU 密集型的。即使并行运行少量环境，您也可以通过在集群上请求比您正在使用的环境数量更多的核心（例如两倍）来看到巨大的加速。对于渲染的环境（即使它们在 GPU 上渲染）来说，情况也是如此，尤其如此。

• 训练速度取决于多种因素，没有适用于所有问题的通用解决方案。常见的瓶颈是

  • 数据收集：模拟器速度可能会影响性能，随后的数据转换也会影响性能。加速环境交互通常通过向量化（如果模拟器支持，例如 Brax 和其他基于 Jax 的模拟器）或并行化（在 gym 和其他库中被不恰当地称为向量化环境）来完成。在 TorchRL 中，转换通常可以在设备上执行。

  • 回放缓冲区存储和采样：如果底层操作需要一些繁重的内存操作或繁琐的索引（例如，使用优先级回放缓冲区），则将项目存储在回放缓冲区中可能需要时间。如果数据不是连续存储和/或执行了代价高昂的堆叠或连接操作，则采样也可能花费大量时间。TorchRL 在这些情况下提供了高效的连续存储解决方案以及高效的写入和采样解决方案。

  • 优势计算：计算优势函数也可能构成计算瓶颈，因为这些函数通常使用普通的 for 循环进行编码。如果性能分析表明此操作花费了大量时间，请考虑改用我们完全向量化的解决方案。

  • 损失计算：损失计算和优化步骤通常占用了相当大的计算时间。一些技术可以加快速度。例如，如果正在使用多个目标网络，则使用向量化映射和函数式编程（通过 functorch）而不是循环遍历模型配置可以提供显着的加速。

常见错误

• 对于与 mujoco 相关的错误（包括 DeepMind Control 套件和其他库），请参阅 MUJOCO_INSTALLATION 文件。

• ValueError: bad value(s) in fds_to_keep：这可能有多种原因。torchrl 中常见的一种原因是您正在尝试跨进程发送张量，该张量是另一个张量的视图。例如，当跨进程发送张量 b = tensor.expand(new_shape) 时，对原始内容的引用将丢失（因为 expand 操作保留了对原始张量的引用）。要调试此问题，请查找此类操作（view、permute、expand 等）并在调用函数后调用 clone() 或 contiguous()。