常見的 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 中常見的一個原因是您正在嘗試跨進程發送另一個張量的視圖（view）的張量。例如，當跨進程發送張量 b = tensor.expand(new_shape) 時，對原始內容的引用將會遺失（因為 expand 操作保留了對原始張量的引用）。要對此進行偵錯，請尋找此類操作（view、permute、expand 等），並在呼叫該函數後呼叫 clone() 或 contiguous()。