Những gì bạn sẽ chạy
Dự án nhỏ Kernodeck chứa một tập dữ liệu tổng hợp nhỏ, một mạng nơ-ron có dropout, một vòng lặp huấn luyện và một bộ kiểm tra. Quy trình bắt buộc dùng CPU để cô lập logic lưu và khôi phục. Nó không phải là chứng nhận CUDA, ROCm, đa card hay phép đo hiệu năng của một GPU thuê.
Bộ kiểm tra mở các tiến trình mới cho hành trình liên tục, lần ngắt, lần khôi phục đầy đủ và một trường hợp phủ định không khôi phục các bộ sinh số ngẫu nhiên. Mục đích của trường hợp này là kiểm tra xem phép kiểm tra có phát hiện được một lần khôi phục không đầy đủ hay không, ngay cả khi trọng số và số bước có vẻ đúng.
Cuộn bảng để xem tất cả các cột.| Hành trình | Cách chạy | Câu hỏi được kiểm tra |
|---|---|---|
| Liên tục | 10 bước cập nhật từ trạng thái ban đầu. | Ta đạt được trạng thái nào khi không bị ngắt? |
| Ngắt | 5 bước cập nhật, rồi lưu và dừng. | Điểm trung gian có chứa các trạng thái mong đợi không? |
| Khôi phục đầy đủ | Tiến trình mới, tải điểm 5, rồi 5 bước cập nhật. | Có thu được cùng chuỗi đầu vào, tốc độ học và tham số trong dung sai đã chọn không? |
| Khôi phục không có RNG | Tiến trình mới, cùng điểm khôi phục nhưng bỏ qua việc khôi phục trạng thái ngẫu nhiên. | Phép kiểm tra có phát hiện được độ lệch mà việc chỉ tải trọng số sẽ bỏ sót không? |
Điều kiện tiên quyết và khởi chạy quy trình
Tải tệp lưu trữ, giải nén vào một thư mục làm việc, rồi chuyển vào thư mục chứa train.py và verify_resume.py. Dùng một môi trường Python có PyTorch và NumPy. Tệp lưu trữ chứa mã và dữ liệu tổng hợp; nó không tải mô hình nào và không yêu cầu tài khoản Kernodeck để chạy bài tập.
Bằng chứng đi kèm được chạy với Python 3.14.6, PyTorch 2.11.0+cu128 và NumPy 2.4.4. Chương trình bắt buộc dùng CPU, độ chính xác float64 và một luồng PyTorch. Do đó, hậu tố của gói không có nghĩa là việc khôi phục đã dùng CUDA. Trên một môi trường khác, hãy tự chạy kiểm tra của bạn.
Chọn một thư mục đầu ra chưa tồn tại. Mỗi hành trình tạo ra checkpoint.pt, mã băm checkpoint.pt.sha256 của nó và summary.json. Bộ kiểm tra tập hợp so sánh trong verification.json. Tùy chọn --steps đếm các bước bổ sung: sau khi ngắt ở bước 5, lệnh khôi phục chạy 5 bước nữa để đạt 10. Tùy chọn Python -B tránh các bộ nhớ đệm bytecode trong thư mục bài tập.
python -B verify_resume.py --output runs/preuve-cpupython -B train.py --steps 10 --output runs/continu
python -B train.py --steps 5 --output runs/coupure
python -B train.py --steps 5 --resume runs/coupure/checkpoint.pt --output runs/repriseXuất trọng số và checkpoint khôi phục không có cùng vai trò
Trước tiên, hãy chọn điều bạn muốn tìm lại. Một bản xuất để suy luận dùng để tạo dự đoán với một mô hình đã huấn luyện. Một lần khôi phục huấn luyện cũng phải tìm lại trạng thái quyết định các bước cập nhật tiếp theo. Còn xử lý suy luận theo tệp lại cần một danh sách đáng tin cậy các mục đã hoàn thành. Ba nhu cầu này tạo ra các bản lưu khác nhau.
Đừng nhầm bản lưu bền vững này với activation checkpointing. Kỹ thuật này giảm một số activation được giữ trong bộ nhớ bằng cách tính lại chúng trong quá trình lan truyền ngược; tự nó không tạo ra một tệp cho phép khôi phục sau khi dừng. Vì vậy, hãy nêu rõ trong dự án của bạn liệu từ checkpoint chỉ một tối ưu hóa bộ nhớ hay một điểm khôi phục.
Những trạng thái cần giữ cùng nhau
state_dict của mô hình chứa các tham số và buffer đã đăng ký; optimizer có trạng thái riêng. Ở đây, Adam, StepLR, dropout và ba bộ sinh số ngẫu nhiên ảnh hưởng đến các cập nhật tiếp theo. Checkpoint phải đại diện cho cùng một thời điểm đối với tất cả các thành phần này.
Hãy ghi lại cả phiên bản mã, các tham số của thí nghiệm và danh tính của dữ liệu. Khi đang ở giữa một epoch, chỉ biết số epoch là chưa đủ: cần có thể khôi phục thứ tự các mẫu và nhóm tiếp theo sẽ được sử dụng. Một sai sót ở đây có thể khiến bỏ sót các mục hoặc xử lý chúng hai lần.
Tập dữ liệu gồm 24 dòng mô tả một quan hệ tổng hợp giữa hai biến và một nhãn mục tiêu. Mạng có 33 tham số, với một lớp tám neuron và dropout bằng 0,25. Batch chứa bốn dòng. Sau năm cập nhật, con trỏ có giá trị 20 trên 24: điểm cắt nằm giữa một epoch. Mười cập nhật tiêu thụ 40 quan sát, buộc bước kiểm tra phải đi qua một hoán vị mới của dữ liệu.
Cuộn bảng để xem tất cả các cột.| Trạng thái | Vai trò | Kiểm tra cần thực hiện |
|---|---|---|
| Mẫu | Giữ nguyên trọng số và buffer. | So sánh các tham số cuối cùng và một kết quả đánh giá. |
| Optimizer | Giữ các trạng thái được dùng cho cập nhật tiếp theo. | Kiểm tra việc nạp lại, không chỉ các siêu tham số. |
| Scheduler | Tiếp tục chuỗi tốc độ học. | So sánh tốc độ học tiếp theo được áp dụng rồi các tốc độ sau đó. |
| RNG của Python, NumPy và PyTorch | Tiếp tục các lần sinh số thực sự được dùng. | Kiểm tra rằng bài tập tiêu cực không khôi phục sẽ phân kỳ. |
| Dữ liệu | Khôi phục hoán vị và con trỏ. | So sánh các định danh mục đầu vào sau điểm cắt. |
| Tiến độ | Diễn giải các bước và epoch. | Đạt tổng cộng 10 cập nhật, không làm lại hoặc bỏ sót. |
| Cấu hình | Tái tạo cùng một thí nghiệm. | Giữ nguyên kích thước, độ chính xác, cấu hình và phiên bản. |
Khôi phục theo đúng thứ tự
Hãy dựng lại mô hình, optimizer và scheduler trước khi nạp trạng thái của chúng. Scheduler phải được tạo trước optimizer.load_state_dict(): nếu không, việc khởi tạo nó có thể ghi đè các tốc độ học đã khôi phục. Hãy nạp lại cả trạng thái riêng của nó, rồi kiểm tra tốc độ học thực sự được dùng ở bước tiếp theo.
Hãy khôi phục các bộ sinh số ngẫu nhiên sau khi dựng các đối tượng có tiêu thụ các lần sinh số, ngay trước khi tiếp tục công việc. Chỉ đặt lại seed ban đầu sẽ khiến chuỗi bắt đầu lại từ đầu; đó không phải là khôi phục trạng thái đạt được sau cập nhật thứ năm. Trong dự án của bạn, hãy xác định tất cả các bộ sinh số được dùng, kể cả những bộ trong các phép biến đổi và trong việc nạp dữ liệu.
Trong bài tập này, Python điều chỉnh một độ lợi nhẹ trên các đầu vào, một bộ sinh NumPy PCG64 tạo nhiễu và các hoán vị, còn PyTorch tạo dropout. Checkpoint giữ trạng thái của chúng tại điểm cắt. Bước kiểm tra cũng quan sát các lần sinh số tiếp theo của chúng, khôi phục ngay trạng thái để không làm xáo trộn phần tính toán tiếp theo.
optimizer = torch.optim.Adam(model.parameters(), lr=0.03)
scheduler = torch.optim.lr_scheduler.StepLR(optimizer, step_size=3, gamma=0.5)
# Trong lộ trình khôi phục, sau khi dựng các đối tượng:
state = load_checkpoint(resume)
model.load_state_dict(state["model"])
scheduler.load_state_dict(state["scheduler"])
optimizer.load_state_dict(state["optimizer"])
progress = state["progress"]
history = state["history"]
restore_rng(state["rng"], generator)
model.train()Chọn một ranh giới lưu nhất quán
Hãy đặt một ranh giới rõ ràng, ví dụ sau một cập nhật optimizer hoàn chỉnh. Nếu bạn tích lũy nhiều microbatch trước cập nhật đó, việc lưu ở giữa buộc phải xử lý cả trạng thái trung gian. Một triển khai đầu tiên sẽ dễ kiểm tra hơn khi nó lưu tại một ranh giới mà các gradient tích lũy đã được sử dụng.
Hãy giữ nhiều thế hệ bản sao lưu. Ghi tệp mới dưới một tên riêng, đợi ghi xong, kiểm tra xem tệp có đọc được không, rồi đánh dấu là dùng được. Đừng thay thế checkpoint hợp lệ duy nhất của bạn trước khi kiểm tra đó. Tần suất phụ thuộc vào công việc bạn chấp nhận làm lại và thời gian ghi quan sát được; không thể chỉ suy ra từ thời lượng thuê.
Dự án nhỏ sao lưu sau một vòng lặp đã hoàn tất, rồi xuất tệp và dấu vân tay của nó. Nó dùng một thư mục mới cho mỗi lần chạy và không thay thế bằng chứng trước đó. Nếu quá trình huấn luyện của bạn dùng độ chính xác hỗn hợp với GradScaler, trạng thái của nó cũng thuộc phần khôi phục. Biến thể này không được bao gồm trong bài tập CPU.
Đọc so sánh và dung sai của nó
Giao thức so sánh phần tiếp diễn sau mốc 5: dữ liệu đã tiêu thụ, tốc độ học, mất mát và các tham số đạt được. Chỉ khớp số bước là không đủ. Một optimizer được khởi tạo lại có thể tiếp tục vòng lặp mà vẫn tạo ra các cập nhật khác.
Dung sai được chọn cho bài tập này là tuyệt đối: 1e-12, với dung sai tương đối bằng 0. Ngưỡng này thuộc giao thức CPU được cung cấp; nó không phải là quy tắc phổ quát cho các mô hình của bạn. Phép so sánh phải báo hiệu các giá trị không hữu hạn và sự khác biệt về cấu trúc, thay vì âm thầm chấp nhận một kết quả không dùng được.
PyTorch không đảm bảo kết quả giống hệt nhau giữa các phiên bản, nền tảng, CPU và GPU. Nếu bạn chuyển bài tập sang nơi khác, hãy làm lại bằng chứng trên mục tiêu đó và giải thích dung sai đã chọn. Đừng nới ngưỡng chỉ để làm biến mất một thất bại mà bạn chưa hiểu rõ nguyên nhân.
Trong bằng chứng được cung cấp, mọi sai lệch của toàn bộ hành trình đều bằng không: tham số, trạng thái của trình tối ưu hóa, các mất mát, tốc độ và MSE. Thứ tự các dòng, tiến trình, trạng thái của scheduler và các lần lấy mẫu tiếp theo cũng trùng khớp. Tốc độ học tiếp theo sau bước 10 bằng 0,00375 trong cả hai hành trình. Do đó, kết quả không chỉ phụ thuộc vào một chỉ số cuối cùng có thể che giấu những khác biệt trung gian.
Cuộn bảng để xem tất cả các cột.| So sánh | Khôi phục đầy đủ | Khôi phục không phục hồi RNG |
|---|---|---|
| Sai lệch tối đa của trọng số | 0 | 0,011669328447718508 |
| MSE cuối cùng | 0,09538858591775097 | 0,0936034144665111 |
| Chênh lệch MSE so với lần chạy liên tục | 0 | 0,001785171451239867 |
| Phán quyết của bài kiểm tra phụ về sự trùng khớp | Trùng khớp trong dung sai 1e-12 | Phát hiện phân kỳ |
Vì sao giữ trường hợp tiêu cực không phục hồi trạng thái ngẫu nhiên
Một phép kiểm tra hữu ích hơn khi bạn biết nó phát hiện lỗi gì. Biến thể tiêu cực nạp lại cùng trọng số, trạng thái optimizer, scheduler và tiến trình, nhưng cố ý bỏ qua việc phục hồi RNG. Tiến trình có thể kết thúc mà không có ngoại lệ Python nào, trong khi tiếp tục một quỹ đạo khác.
Trong bằng chứng được cung cấp, việc bỏ qua này tạo ra sai lệch tối đa của trọng số lớn hơn 0,011 và chênh lệch MSE lớn hơn 0,0017. MSE của trường hợp tiêu cực ở đây thấp hơn so với lần chạy liên tục: điều đó không làm cho việc khôi phục trở nên đúng. Mục đích là tái tạo cùng một trải nghiệm, không phải xếp hạng hai mô hình theo sai số cuối cùng.
Trình kiểm tra chỉ thành công khi lần chạy đầy đủ trùng khớp và trường hợp tiêu cực phân kỳ. Khi đó nó hiển thị all_checks_passed: true, positive: true và negative_divergence_detected: true. Mã thoát của nó bằng 0 khi giao thức thành công, 1 nếu so sánh thất bại và 2 nếu không thể hoàn tất kiểm tra.
python -B train.py --steps 5 --resume runs/coupure/checkpoint.pt --omit-rng-restore --output runs/reprise-incompleteNạp tệp của bài tập mà không nới lỏng các biện pháp bảo vệ
Dự án chỉ nạp checkpoint mà bạn đã tạo bằng bài tập này và giữ dưới sự kiểm soát của mình. Nó dùng tường minh torch.load(..., map_location="cpu", weights_only=True). Trạng thái Python chứa các kiểu nguyên thủy, trạng thái của bộ sinh NumPy PCG64 chứa số nguyên và chuỗi, còn trạng thái PyTorch CPU chứa một tensor byte. Không có mảng NumPy tùy ý nào được đặt vào trạng thái RNG đã lưu.
Trình tải kiểm tra dấu vân tay đi kèm, kích thước, lược đồ, tiến trình, các phiên bản cũng như danh tính của mã và dữ liệu. Nó từ chối trạng thái không nhất quán thay vì âm thầm khởi tạo lại một phần tử bị thiếu. Dấu vân tay phát hiện thay đổi; nó không xác thực người gửi của một tệp.
Đừng thêm weights_only=False chỉ để dập tắt một lỗi tải. Định dạng đã lưu và việc tái dựng nó phải nhất quán. Tải hạn chế làm giảm khả năng giải tuần tự hóa, nhưng không làm cho một tệp không rõ nguồn gốc trở nên đáng tin.
Điều gì thay đổi đối với huấn luyện phân tán
Với nhiều tiến trình hoặc trạng thái phân tán giữa các GPU, hãy kiểm tra ai ghi cái gì. Một tệp do một tiến trình duy nhất tạo ra không nhất thiết là bản sao lưu đầy đủ của công việc phân tán. Hãy dùng quy trình sao lưu theo chiến lược của bạn và chờ nó hoàn tất trên các thành phần liên quan. Xác định rõ các mảnh thuộc cùng một điểm khôi phục.
Việc thay đổi số lượng GPU có thể đòi hỏi phân phối lại trạng thái và làm thay đổi cách chia dữ liệu. Các cơ chế checkpoint phân tán có thể xử lý một số thay đổi, nhưng khả năng này phải được kiểm chứng cho định dạng và cấu hình của bạn. Hãy thử tải trên mục tiêu dự kiến. Thêm lô vào đơn hàng không tự động biến một bản sao lưu một card thành chương trình phân tán.
Kết thúc bằng một bản xuất thực sự có thể khôi phục
Trước thời hạn, hãy xuất các checkpoint hữu ích kèm cấu hình, chỉ số, hướng dẫn tải và định danh dữ liệu. Kiểm tra kích thước và dấu vân tay của các tệp đã sao chép, rồi tải ít nhất một bản sao lưu từ đích của nó. Dấu vân tay trùng khớp kiểm soát việc sao chép; việc tải lại xác minh rằng nội dung thực sự đủ để tái dựng công việc.
Chỉ tải các tệp mà bạn biết rõ nguồn gốc và chọn định dạng cùng các tùy chọn giải tuần tự hóa phù hợp. Giữ điểm khôi phục đã kiểm chứng gần nhất cho đến khi điểm mới vượt qua các kiểm tra của bạn. Kết quả mong đợi là một thư mục có thể khôi phục và một bằng chứng ngắn về việc khôi phục: lệnh đã chạy, bước đã tìm lại, kiểm tra đã đạt và kết quả đã xuất. Hãy dự trù thời gian này trong 3, 7 hoặc 30 ngày của bạn.
Phạm vi bằng chứng và lựa chọn thuê
Bằng chứng ngày 24 tháng 9 năm 2026 so sánh bốn tiến trình mới trên CPU, với dung sai tuyệt đối 1e-12 và không có dung sai tương đối. Nó không bao gồm CUDA, ROCm, AMP, huấn luyện phân tán, hay các worker tải dữ liệu. Nó xác thực logic tái lập của phiên bản được cung cấp, trong môi trường được mô tả, và không đo lường khả năng của một GPU đi thuê.
Sau bài tập nhỏ này, hãy áp dụng cùng quy trình cho mô hình, dữ liệu và backend của bạn. Một card 80 GB hay một card 192 GB không khắc phục được một checkpoint không đầy đủ: trước tiên hãy chọn chuỗi tương thích, rồi định cỡ bộ nhớ cho một bước thực tế. Các ưu đãi được liên kết bên dưới không được giới thiệu là phần cứng đã kiểm nghiệm cho bằng chứng này.
Hãy dự trù trong khoảng 3, 7 hoặc 30 ngày của bạn một chu trình đầu tiên gồm sao lưu–dừng–khôi phục và thời gian xuất cuối cùng. Kết quả hữu ích là một thư mục mà bạn có thể giải thích các phiên bản, điểm khôi phục, kiểm tra đối chiếu và các giới hạn; chỉ riêng sự tồn tại của một tệp .pt không mang lại sự đảm bảo đó.