Giữ lại lần thất bại đầu tiên và ngữ cảnh của nó
Hướng dẫn này bắt đầu sau khi khởi chạy thành công: PyTorch nhận diện được thiết bị, rồi ứng dụng của bạn thất bại trên một lô dữ liệu hoặc một toán tử. Nếu không có phép tính nhỏ nào chạy được, hãy quay lại từ bước chẩn đoán ban đầu. Nếu không, hãy giữ lại lỗi đầu tiên, số vòng lặp và bước cuối cùng đã hoàn thành. Một chuỗi thông báo sau lần thất bại đầu tiên có thể mô tả hậu quả của nó hơn là nhiều nguyên nhân độc lập.
Ghi lại revision của mã, phiên bản Python và PyTorch, backend, kiểu số và hình dạng đầu vào. Với dữ liệu, hãy ưu tiên một định danh nội bộ và các chiều hơn là sao chép toàn bộ nội dung. Tìm xem điều gì phân biệt batch lỗi: độ dài, thiếu target, lô cuối không đầy đủ, augmentation hoặc nhánh ít khi dùng. Hồ sơ này cho phép dựng lại trường hợp mà không cần chạy lại cả một chiến dịch.
Định vị lần chạy lỗi bất chấp tính bất đồng bộ
Trên CUDA, các phép toán được xếp hàng đợi và có thể kết thúc sau khi hàm Python trả về. Do đó, một lỗi xuất hiện trong lúc sao chép sang CPU hoặc đọc một scalar có thể đến từ một phép tính trước đó. Tài liệu PyTorch giải thích cách thực thi bất đồng bộ này. Dòng mà trace chỉ ra là một điểm quan sát cần xem xét, không phải lúc nào cũng là nguyên nhân.
Để tái hiện ngắn gọn trên NVIDIA/CUDA, hãy thử một lần chạy riêng với CUDA_LAUNCH_BLOCKING=1. Tùy chọn này khiến các lời gọi trở nên đồng bộ và có thể đưa lỗi đến gần nguồn gốc hơn. Nó dùng để chẩn đoán, không dùng để đo thời gian. Bạn cũng có thể tạm đặt các điểm đồng bộ giữa những bước lớn để thu hẹp khoảng nghi ngờ. Sau đó hãy gỡ bỏ instrumentation này: nó làm thay đổi thứ tự lập lịch thông thường.
Câu lệnh sau mang tính minh họa và chưa được chạy. Nó giả định một terminal POSIX và một script train.py đã tồn tại. Phép gán chỉ áp dụng cho lần chạy này; hãy điều chỉnh cú pháp cho shell của bạn. Đừng áp dụng chung biến NVIDIA này cho một stack ROCm.
CUDA_LAUNCH_BLOCKING=1 python train.pyĐọc một nhóm lỗi mà không kết luận quá sớm
Thông báo thu hẹp phạm vi tìm kiếm; nó không thay thế một trường hợp tái hiện được. Một chỉ số ngoài miền, một tensor trên thiết bị sai và một cấp phát bất khả thi đòi hỏi những kiểm tra khác nhau. Hãy giữ sự phân biệt giữa dữ liệu không hợp lệ, hợp đồng của toán tử và môi trường nhị phân. Thay đổi đồng thời batch, độ chính xác và các thư viện sẽ xóa bỏ sự phân biệt này.
Sau một assertion được thực thi trên thiết bị, đừng cố tiếp tục cùng một quá trình huấn luyện trong cùng tiến trình. NVIDIA cho biết cudaErrorAssert làm vô hiệu các cấp phát hiện có và buộc phải kết thúc rồi khởi động lại tiến trình. Trong một notebook, điều này có nghĩa là phải khởi động lại kernel trước khi tái hiện đã sửa. Tuy nhiên, khởi động lại không sửa được một target sai hay một chỉ số không hợp lệ.
Cuộn bảng để xem tất cả các cột.| Chỉ số quan sát được | Kiểm tra đầu tiên | Kết luận cần tránh |
|---|---|---|
| device-side assert | Chỉ số, target và điều kiện của toán tử | GPU chắc chắn bị lỗi |
| Out of memory | Hình dạng, vòng đời của tensor, bộ nhớ của tiến trình | Mọi lỗi CUDA đều là thiếu VRAM |
| Toán tử hoặc kernel không khả dụng | Phiên bản, extension, backend và dtype | Cài đặt lại mọi thứ một cách ngẫu nhiên |
| Các thiết bị khác nhau | Vị trí đặt model và từng đầu vào | Thêm một bản sao mà không hiểu nguồn gốc của nó |
Ví dụ minh họa: một lớp 4 trong bài toán bốn lớp
Hãy xét một bộ phân loại minh họa có đầu ra bốn cột. Các lớp của nó được đánh chỉ số từ 0 đến 3. Một tệp chú thích chứa giá trị 4 có thể tiết lộ cách mã hóa từ 1 đến 4 hoặc một lớp thứ năm ngoài dự kiến. Chỉ tăng kích thước đầu ra sẽ làm một ràng buộc biến mất mà không giải quyết được ý nghĩa của các chú thích.
Phép kiểm tra đề xuất dưới đây áp dụng trước khi chuyển các target sang CPU. Nó chưa được chạy. Nó minh họa hợp đồng CrossEntropyLoss cho các chỉ số lớp kiểu long, với ignore_index=-100 được chọn một cách tường minh. Nó không bao quát các target là phân phối xác suất. Trong kịch bản này, [0, 2, 4] phải bị từ chối; kết quả mong đợi này được suy ra từ quy tắc, không được trình bày như một phép đo.
Sau đó hãy sửa mapping trong bước chuẩn bị dữ liệu và kiểm tra tính song ánh của nó với các tên lớp. Đừng trừ 1 ở mọi nơi khi bạn chưa biết liệu tất cả các nguồn có dùng cùng một quy ước hay không. Hãy thêm trường hợp lỗi vào một tập kiểm tra nhỏ được lưu cùng dự án.
import torch
classes = 4
ignore_index = -100
target = torch.tensor([0, 2, 4], dtype=torch.long)
if target.ndim != 1 or target.dtype != torch.long:
raise ValueError("Cibles : vecteur d’indices attendu")
valid = target[target != ignore_index]
if valid.numel() == 0:
raise ValueError("Aucune cible exploitable dans ce batch")
if bool(((valid < 0) | (valid >= classes)).any()):
raise ValueError("Indice de classe hors domaine")Thu gọn chương trình mà không xóa tác nhân kích hoạt
Trước tiên hãy chạy lại một mục nhập hoặc một batch duy nhất với cùng các phép biến đổi. Loại bỏ theo dõi từ xa, ghi kết quả và các nhánh không liên quan đến lỗi. Giữ nguyên dtype, hình dạng và toán tử bị nghi ngờ. Nếu lỗi phụ thuộc vào một độ dài hoặc cách bố trí bộ nhớ cụ thể, một tensor nhỏ tùy ý có thể không còn tái hiện được lỗi nữa.
Hãy so sánh từng thay đổi một: tắt phần mở rộng tùy chọn, toán tử tham chiếu, độ chính xác thông thường hoặc cùng phép toán trên CPU khi có sẵn. Thành công trên CPU là một gợi ý, không phải xác nhận cho CUDA. Với một hàm tùy chỉnh, hãy ghi lại cả các giả định về strides, tính liên tục và kích thước. Tìm một ví dụ thất bại trước khi sửa và thành công sau khi sửa, với kiểm tra đầu ra thay vì chỉ dựa vào việc không có ngoại lệ.
Kiểm tra tính đúng đắn trên phạm vi ban đầu
Một bản sửa đúng phải vượt qua trường hợp tối thiểu, các trường hợp lân cận và một phần đại diện của luồng gốc. Cụ thể hãy chạy lại batch cuối, một mục nhập ngắn, một mục nhập dài và các giá trị biên của ánh xạ. Kiểm tra rằng các mục bị từ chối có thể nhận diện được và số lượng mục nhập đã xử lý vẫn đúng như mong đợi. Bỏ qua ngoại lệ một cách âm thầm có thể biến một lỗi rõ ràng thành kết quả không đầy đủ.
Hãy tắt chế độ chẩn đoán, khởi động lại từ một tiến trình mới và xác nhận hành vi với cấu hình bình thường. Ghi lại nguyên nhân, thay đổi đã áp dụng và kiểm tra chống hồi quy. Nếu bạn đã dừng một quá trình huấn luyện, hãy bắt đầu lại từ một checkpoint nhất quán đã được xác nhận trước lỗi; sự tồn tại của một tệp được ghi trong lúc sự cố không đủ để đảm bảo có thể khôi phục.
Biết khi nào cần yêu cầu phân tích chuyên sâu hơn
Nếu cùng trường hợp tối thiểu vẫn thất bại với các mục nhập hợp lệ, hãy chuẩn bị một yêu cầu cụ thể: phép toán, hình dạng, kiểu, backend, phiên bản và thông báo lỗi liên quan đầu tiên. Loại bỏ thông tin nhận dạng cá nhân và các đường dẫn không cần thiết. Một phần mở rộng nhị phân có thể cần ma trận tương thích riêng; hỗ trợ chung của PyTorch không tự động xác nhận phần mở rộng đó.
Trên ROCm, PyTorch vẫn giữ giao diện torch.cuda và tên thiết bị cuda. Hãy kiểm tra torch.version.hip để nhận diện stack này trước khi áp dụng quy trình NVIDIA. Các thông báo, công cụ và tùy chọn chẩn đoán có thể khác nhau. Không có kiểm tra nào được mô tả ở đây chứng minh môi trường đã chuẩn bị tương thích với một dịch vụ Kernodeck; hãy dùng các tiêu chí này để làm rõ nhu cầu của bạn trước khi chọn GPU.