本文匯總使用DLC模組遇到的常見問題、定位思路以及解決辦法。
Q：模型訓練時報錯：SupportsDistributedTraining false, please set InstanceCount=1
報錯原因：當前訓練任務啟用了多個執行個體（節點數大於1），但該模型不支援分布式訓練。
解決方案：將節點數量設定為1。
Q：模型訓練時報錯：failed to compose dlc job specs, resource limiting triggered, you are trying to use more GPU resources than the threshold
訓練任務當前限制最多同時運行2*GPU，超過會觸發資源限制。請等待正在運行中的訓練任務完成再啟動，或提交工單申請增加配額。
Q：“exited with code 137”，遇到錯誤碼137怎麼辦？
當您遇到錯誤碼137時，如“xxx exited with code 137”，您可以嘗試更換記憶體規格更大的執行個體，或增加worker數量，或修改您的代碼中記憶體申請的數量。
在Linux系統中，錯誤碼137表示進程被SIGKILL訊號強制中止了，最常見的原因是記憶體使用量量過高，即OOM（Out Of Memory）錯誤。您可以結合任務詳情中worker的記憶體水位來進一步判斷記憶體不足的原因，或更換記憶體規格更大的執行個體，或增加worker數量，或修改您的代碼中記憶體申請的數量。
Q：當DLC任務執行狀態為已失敗或已出隊時該如何處理？
DLC的任務執行狀態順序為：
任務類型 | 任務執行狀態順序 | |
使用隨用隨付資源提交DLC任務 | 使用靈駿智算競價資源 |
|
使用靈駿智算或通用計算公用資源 |
| |
使用訂用帳戶資源提交DLC任務 |
| |
，或者查看執行個體動作記錄，來初步定位任務執行失敗的原因，詳情請參見Q：使用公用資源的DLC任務後期能調整為專屬資源嗎？
您需要重新建立任務來調整所使用的資源。您可以在原始任務操作列下單擊複製，以建立一個新的任務，該任務將複用原始任務的配置，避免重新輸入和配置相同的參數。關於計費詳情介紹，請參見分布式訓練（DLC）計費說明。
Q：在DLC中使用多機多卡如何設定？
您可以在建立DLC任務時，配置以下啟動命令，更多配置詳情，請參見建立訓練任務。
python -m torch.distributed.launch \ --nproc_per_node=2 \ --master_addr=${MASTER_ADDR} \ --master_port=${MASTER_PORT} \ --nnodes=${WORLD_SIZE} \ --node_rank=${RANK} \ train.py --epochs=100Q：如何將在PAI-DLC平台訓練得到的模型下載到本地？
在提交分布式訓練（DLC）任務時，您可以關聯所需的資料集，並在啟動命令中通過配置相應命令將訓練結果輸出至已掛載的資料集目錄中。
這樣，在訓練完成後，產生的模型檔案會自動儲存到已掛載的資料集目錄中。後續您可以直接存取已掛載資料集對應的檔案系統，並從中下載模型檔案到本地。
如何在提交DLC任務時綁定資料集，請參見通過控制台建立任務。
如何將Object Storage Service檔案系統中的檔案下載到本地，請參見控制台快速入門。
如何將NAS檔案系統中的檔案下載到本地，請參見Function Compute掛載檔案系統。
Q：在DLC中如何使用Docker鏡像？
使用Docker鏡像建立DLC任務：您可以將Docker鏡像推送至阿里雲Container RegistryACR中，然後再將其添加至PAI工作空間自訂鏡像中，即可在建立DLC任務時選擇對應鏡像啟動執行個體。
將Docker鏡像推送至Container RegistryACR中，請參見使用個人版執行個體推送拉取鏡像。
添加PAI自訂鏡像，請參見自訂鏡像。
在DLC容器中安裝和使用Docker：DLC任務本身運行在容器中，因此無法在DLC中再安裝和使用Docker。
Q：DLC 任務有部分節點已經完成要怎麼配置才能釋放給其他dlc使用？
問題描述：
在DLC任務啟動多worker分布式訓練任務時，由於每個worker資料不完全一致（比如資料扭曲），會有部分worker先完成，並正常退出的現象。但是預設配置下，部分worker仍會佔用調度的節點。
解決方案：可以參考PAI-DLC進階參數ReleaseResourcePolicy，該參數預設不配置時，計算資源只有在任務整體完成時才釋放，如果配置為pod-exit則worker退出，相應的計算資源就會釋放。
Q：DLC任務報錯OSError: [Errno 116] Stale file handle？
問題描述：
多個Worker在執行PyTorch的torch.compile（AOT編譯）時，因讀取快取檔案失敗而報錯OSError: [Errno 116] Stale file handle。
排查思路&過程：
同步複現發現：該錯誤通常發生在NFS（Network File System）環境下，當某個進程持有檔案控制代碼但檔案在伺服器端已被刪除或移動時，用戶端嘗試訪問會導致控制代碼失效。
問題原因：
根因在於PyTorch的AOT編譯機制會將最佳化後的計算圖緩衝到檔案系統（預設在/tmp，通常是本地tmpfs），但在叢集計算等環境下，緩衝可能被儲存到NFS掛載的CPFS（Distributed File System），而NFS對檔案刪除操作敏感。 觸發Stale file handle的條件包括：PyTorch自動清理舊緩衝或其他進程刪除緩衝目錄導致檔案被刪除；NFS伺服器端檔案被移動、刪除或許可權更改，但用戶端仍持有舊控制代碼；NFS用戶端預設快取檔案屬性，可能導致用戶端感知不到伺服器端的變更。此外，環境因素加劇了問題：CPFS基於NFS，而NFS在高並發訪問時容易出現Stale file handle，尤其是臨時緩衝等短生命週期檔案；多Worker並發訪問可能同時讀寫或清理緩衝，進一步導致競爭條件。
解決方案：
優先驗證：強制緩衝使用本地tmpfs（通過環境變數TORCHINDUCTOR_CACHE_DIR=/dev/shm/torch_cache）。
備選方案：
參考Torch官方文檔改用Redis作為共用快取（需搭建Redis服務）。
檢查CPFS的NFS配置（noac掛載選項可能緩解但影響效能）。
禁用緩衝（TORCHINDUCTOR_CACHE_DIR=""，但犧牲編譯效能）。