1. Giữ lại thông báo và ngữ cảnh trước khi chạy lại
Đừng tiếp tục thêm tác vụ vào hàng đợi. Ghi lại nội dung chính xác của lỗi, tệp hoặc câu hỏi liên quan, số phần tử được xử lý cùng lúc và bước đã đạt được. Mô hình đang tải, phép tính đang chạy hay kết quả đang được ghi ra? Hãy lưu cài đặt vào một ghi chú và các kết quả đã hoàn thành vào thư mục của chúng.
Một màn hình đứng yên hoặc ứng dụng đóng lại không rõ lý do không đủ để xác định nguyên nhân. Hãy tìm nhật ký của nó nếu có. Mất kết nối, đầu vào không hợp lệ và bộ nhớ đầy đều có thể tạo ra các triệu chứng giống nhau trên giao diện. Nếu phần mềm không nêu rõ điều gì, hãy ghi « nguyên nhân chưa xác định » và chuẩn bị một thử nghiệm tối thiểu thay vì bịa ra chẩn đoán.
2. Phân biệt bộ nhớ GPU, bộ nhớ hệ thống và dung lượng đĩa
Bộ nhớ GPU dùng cho các phần tử tính toán trên card. RAM của máy chủ và dung lượng lưu trữ đáp ứng các nhu cầu khác. Dung lượng hiển thị trên các trang GPU BriefGPU không mô tả RAM hoặc đĩa thực sự khả dụng. Hãy kiểm tra tài nguyên được thông báo lỗi đề cập và thông tin trong môi trường của bạn.
Trong Python, MemoryError chỉ một lỗi cấp phát bộ nhớ; chỉ tên này không có nghĩa là thiếu VRAM. Mã ENOSPC tương ứng với việc thiếu dung lượng trên thiết bị đích. Những dấu hiệu này định hướng tìm kiếm, nhưng nhật ký của ứng dụng vẫn cần thiết để xác định thao tác.
| Quan sát | Kiểm tra đầu tiên | Điều mà một GPU lớn hơn không tự giải quyết được |
|---|---|---|
| Thông báo CUDA out of memory trong quá trình tính toán | Bộ nhớ card được sử dụng, các tác vụ khác và kích thước nhóm | Phần mềm không tương thích hoặc tệp bị hỏng |
| MemoryError khi đọc tệp | Bộ nhớ của tiến trình, lượng dữ liệu nạp vào RAM | Việc nạp toàn bộ thư mục vào bộ nhớ hệ thống |
| No space left on device trong quá trình xuất | Dung lượng và hạn mức có thể có của thư mục đầu ra hoặc thư mục tạm | Đĩa đầy hoặc giới hạn lưu trữ |
| Ứng dụng đóng lại không có thông báo hữu ích | Nhật ký, bước đã đạt được và thử nghiệm trên một đầu vào duy nhất | Một nguyên nhân còn chưa biết |
3. Quay lại một đầu vào và chỉ một tác vụ đang hoạt động
Trước tiên hãy kiểm tra các xử lý mà chính bạn đã khởi chạy. Một bản xem trước, một phiên cũ hoặc một công cụ thứ hai có thể vẫn đang làm việc. Hãy đóng đúng cách các tác vụ trở nên không cần thiết sau khi giữ lại trạng thái của chúng. Đừng kết thúc một tiến trình mà bạn không nhận ra và đừng khởi động lại toàn bộ môi trường chỉ để tiết kiệm vài phút chẩn đoán.
Hãy chạy lại đầu vào đã thất bại, một mình, không giảm chất lượng của nó. Nếu nó chạy được riêng lẻ nhưng thất bại theo nhóm, số phần tử đồng thời trở thành một manh mối. Ví dụ, giảm một nhóm từ bốn xuống hai, rồi xuống một nếu cần. Số tệp trong thư mục vẫn giữ nguyên; chỉ lượng được xử lý cùng lúc thay đổi.
Một số công cụ cung cấp xử lý tuần tự để hạn chế các đỉnh bộ nhớ. Diffusers tài liệu hóa cụ thể việc chia nhỏ quá trình giải mã một nhóm hình ảnh. Khả năng này phụ thuộc vào pipeline được sử dụng: hãy xem các tùy chọn của nó trước khi bật một cài đặt được tìm thấy cho một mô hình khác.
4. Giảm tải mà không mất kết quả yêu cầu
Nếu một đầu vào duy nhất thất bại, hãy xem xét kích thước hoặc độ dài của nó. Với một hình ảnh, chuyển từ 2 048 × 2 048 xuống 1 024 × 1 024 chia số điểm ảnh cho bốn. Điều này không đảm bảo tổng bộ nhớ giảm còn một phần tư: mô hình và các phần tử khác vẫn giữ nhu cầu riêng của chúng. Việc giảm chỉ chấp nhận được nếu kết quả vẫn giữ các chi tiết cần thiết.
Đối với một trợ lý, hãy phân biệt tài liệu được cung cấp, câu hỏi và câu trả lời được tạo ra. Bộ nhớ đệm sinh có thể tiêu tốn nhiều bộ nhớ hơn khi ngữ cảnh dài; cơ chế chính xác phụ thuộc vào mô hình. Hãy thử một yêu cầu ngắn hơn hoặc chỉ một truy vấn mỗi lần. Đừng xóa đoạn chứa câu trả lời rồi kết luận rằng vấn đề đã được giải quyết.
Luôn giữ lại đầu vào gốc. Hãy đặt tên cho biến thể thử nghiệm và ghi rõ nó thay đổi điều gì. Nếu công cụ cung cấp tính năng chia thành các ô hoặc chuyển một số phần tử sang RAM, hãy kiểm tra tài liệu của nó và kiểm soát các mối nối, chất lượng và thời gian quan sát được. Một tùy chọn tiết kiệm VRAM có thể chỉ chuyển điểm nghẽn sang chỗ khác.
5. Đừng nhầm lẫn giữa bộ nhớ được đặt trước và bộ nhớ hữu ích
Với PyTorch, bộ nhớ được bộ cấp phát đặt trước và bộ nhớ mà các tensor chiếm giữ là hai phép đo khác nhau. Xóa bộ nhớ đệm không dùng đến không giải phóng các tensor còn đang hoạt động. Do đó, một lệnh dọn dẹp không biến một tác vụ quá lớn thành tác vụ tương thích.
Nếu việc khởi động lại ứng dụng một cách sạch sẽ giúp ích, hãy chạy lại đúng trường hợp nhỏ đó và ghi lại kết quả. Thành công sau khi khởi động lại không tự nó chứng minh rằng một rò rỉ bộ nhớ đã được khắc phục. Nếu mức sử dụng tăng lên sau mỗi lần chạy giống hệt nhau, hãy giữ lại quan sát đó và tham khảo tài liệu hoặc bộ phận hỗ trợ của phần mềm trước khi tiếp tục khởi động lại nhiều lần.
Ví dụ: cô lập vấn đề trong một thư mục gồm mười hai ảnh
Đây là một tình huống minh họa, không có đo lường phần cứng. Một người làm nghề tự do chuẩn bị mười hai ảnh, trong đó hai ảnh có kích thước lớn và chứa chữ mảnh. Việc xử lý theo nhóm bốn ảnh thất bại. Cô ấy giữ lại thông báo, rồi thử một trong các ảnh lớn riêng lẻ, ở chất lượng ban đầu. Bảng dưới đây cho thấy cách diễn giải những quan sát có thể có.
Trong tình huống này, cô ấy chỉ giữ lại nhóm hai ảnh sau khi đã kiểm tra hai ảnh lớn cùng nhau và vài ảnh thông thường. Cô ấy kiểm tra chữ và đường viền trong các tệp đã xuất. Cô ấy không khái quát hóa kết quả này cho mọi kích thước ảnh, mọi mô hình hay một phần mềm khác.
| Thử tình huống | Quan sát giả định | Quyết định cục bộ |
|---|---|---|
| Bốn ảnh cùng lúc | Lỗi bộ nhớ | Giữ lại lỗi và giảm nhóm |
| Một ảnh lớn, giữ nguyên cài đặt | Đầu ra đầy đủ và chấp nhận được | Chất lượng mục tiêu có thể đáp ứng cho trường hợp riêng lẻ này |
| Hai ảnh lớn cùng nhau | Đầu ra đầy đủ và chấp nhận được | Thử nhóm này trên một đoạn ngắn |
| Ảnh được giảm mạnh | Tính toán xong, chữ không đọc được | Loại bỏ cách giảm này dù về mặt kỹ thuật thành công |
Khi một cấu hình khác trở thành hướng đi hợp lý
Hãy so sánh với một card khác khi tình trạng thiếu bộ nhớ GPU đã được xác định, khi trường hợp thiết yếu thất bại khi chạy riêng lẻ và khi các cách giảm phù hợp với chất lượng của bạn không đủ. Hãy giữ lại phần mềm, phiên bản, tham số và đầu vào liên quan: hồ sơ này giúp lần thử tiếp theo có thể so sánh được. Nó không cho phép suy ra chính xác cần thêm bao nhiêu GB là đủ.
Một lỗi khi tải mô hình cũng có thể làm giảm lợi ích của việc giảm nhóm: một phần đáng kể tải trọng đã tồn tại trước đầu vào đầu tiên. Các tùy chọn về độ chính xác hoặc lượng tử hóa thay đổi điều kiện thực thi và đôi khi cả kết quả; chúng cần một thử nghiệm riêng. Việc thêm lô không tự động hợp nhất bộ nhớ của nhiều card.
Kết thúc bằng một chẩn đoán có thể sử dụng được
Ghi chú kết quả của bạn gồm năm yếu tố: thông báo và bước, tài nguyên bị nghi ngờ, đầu vào được giữ lại, cài đặt chạy được hay thất bại, kiểm tra chất lượng đã thực hiện. Hãy bổ sung những gì còn chưa biết. Nếu không có trường hợp nhỏ nào hoạt động, hãy dừng việc lặp lại toàn bộ lô và yêu cầu trợ giúp với những thông tin này.
Đừng xóa những bản gốc duy nhất của bạn để giải phóng dung lượng đĩa, đừng giảm nhiều tham số cùng lúc và đừng coi một đầu ra một phần là thành công. Hãy dành thời gian để sao lưu các kết quả hợp lệ. Chẩn đoán phải làm giảm sự không chắc chắn; nó không cần biến thành một buổi chỉnh cài đặt kéo dài vô tận.