실행할 내용
Kernodeck 미니 프로젝트에는 작은 합성 데이터셋, dropout이 있는 네트워크, 학습 루프, 검증기가 포함되어 있습니다. 이 프로토콜은 저장 및 재개 로직을 분리하기 위해 CPU를 강제합니다. 이는 CUDA, ROCm, 멀티 카드 자격이나 임대한 GPU의 성능 측정을 구성하지 않습니다.
검증기는 연속 경로, 중단, 완전 재개, 그리고 난수 생성기를 복원하지 않는 부정 케이스를 위해 새 프로세스를 엽니다. 부정 케이스의 요점은 가중치와 스텝 번호가 올바르게 보이더라도 검사가 불완전한 재개를 감지할 수 있는지 확인하는 것입니다.
표의 모든 열을 보려면 스크롤하세요.| 경로 | 실행 | 검증 질문 |
|---|---|---|
| 연속 | 초기 상태에서 10회 업데이트. | 중단 없이 어떤 상태에 도달하는가? |
| 중단 | 5회 업데이트 후 저장하고 종료. | 중간 지점에 예상 상태가 포함되어 있는가? |
| 완전 재개 | 새 프로세스에서 5번 지점을 로드한 후 5회 업데이트. | 선택한 허용 범위 내에서 동일한 입력, 학습률, 파라미터의 연속을 얻는가? |
| RNG 없는 재개 | 새 프로세스, 동일한 재개 지점이지만 난수 복원은 생략. | 가중치만 로드하는 것으로는 놓칠 수 있는 드리프트를 테스트가 감지하는가? |
사전 요구 사항 및 프로토콜 실행
아카이브를 다운로드하여 작업 폴더에 압축을 풀고, train.py와 verify_resume.py가 있는 폴더로 이동하세요. PyTorch와 NumPy가 있는 Python 환경을 사용하세요. 아카이브에는 코드와 합성 데이터가 포함되어 있으며, 어떤 모델도 다운로드하지 않고 연습을 실행하는 데 Kernodeck 계정이 필요하지 않습니다.
제공된 증명은 Python 3.14.6, PyTorch 2.11.0+cu128, NumPy 2.4.4로 실행되었습니다. 프로그램은 CPU, float64 정밀도, 단일 PyTorch 스레드를 강제합니다. 따라서 패키지 접미사가 재개에 CUDA가 사용되었음을 의미하지는 않습니다. 다른 환경에서는 직접 검증을 실행하세요.
아직 존재하지 않는 출력 디렉터리를 선택하세요. 각 경로는 checkpoint.pt, 그 해시 checkpoint.pt.sha256, summary.json을 생성합니다. 검증기는 비교 결과를 verification.json에 모읍니다. --steps 옵션은 추가 단계를 셉니다. 5에서 중단한 후 재개 명령은 5를 실행하여 10에 도달합니다. Python 옵션 -B는 연습 폴더에 바이트코드 캐시가 생기는 것을 방지합니다.
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/reprise가중치 내보내기와 재개 체크포인트는 역할이 다릅니다
먼저 무엇을 복원하려는지 선택하세요. 추론용 내보내기는 학습된 모델로 예측을 생성하는 데 사용됩니다. 학습 재개는 다음 업데이트를 결정하는 상태도 복원해야 합니다. 파일 단위 추론 처리에는 이미 완료된 항목의 신뢰할 수 있는 목록이 필요합니다. 이 세 가지 요구 사항은 서로 다른 저장을 만들어냅니다.
이 영구 저장을 activation checkpointing과 혼동하지 마세요. 이 기법은 메모리에 유지되는 일부 활성화를 역전파 중에 재계산하여 줄이는 것으로, 그 자체만으로 중단 후 재개할 수 있는 파일을 만들지는 않습니다. 따라서 프로젝트에서 checkpoint라는 단어가 메모리 최적화를 뜻하는지 재개 지점을 뜻하는지 명확히 하세요.
함께 유지해야 할 상태들
모델의 state_dict에는 등록된 파라미터와 버퍼가 들어 있고, 옵티마이저는 자체 상태를 가집니다. 여기서는 Adam, StepLR, 드롭아웃, 세 개의 난수 생성기가 다음 업데이트에 영향을 줍니다. 체크포인트는 이 모든 요소에 대해 동일한 시점을 나타내야 합니다.
코드 버전, 실험 파라미터, 데이터의 정체성도 문서화하세요. 에포크 중간에서는 번호만 아는 것으로 충분하지 않습니다. 예제 순서와 다음에 소비할 그룹을 되찾을 수 있어야 합니다. 이 지점에서의 실수는 입력을 건너뛰거나 두 번 처리할 수 있습니다.
24개 행으로 이루어진 데이터셋은 두 변수와 목표값 사이의 합성 관계를 설명합니다. 네트워크는 8개 뉴런의 층과 0.25의 dropout을 포함해 33개의 파라미터를 가집니다. 배치는 4개 행을 포함합니다. 5회 업데이트 후 커서는 24 중 20이며, 에포크 중간에서 끊깁니다. 10회 업데이트는 40개 관측치를 소비하므로, 검사는 데이터의 새로운 순열을 통과해야 합니다.
표의 모든 열을 보려면 스크롤하세요.| 상태 | 역할 | 수행할 점검 |
|---|---|---|
| 모델 | 가중치와 버퍼를 유지합니다. | 최종 파라미터와 평가 출력을 비교합니다. |
| 옵티마이저 | 다음 업데이트에 사용되는 상태를 유지합니다. | 하이퍼파라미터뿐 아니라 재로딩도 확인합니다. |
| 스케줄러 | 학습률 시퀀스를 계속합니다. | 다음에 적용되는 학습률과 그 이후 학습률을 비교합니다. |
| Python, NumPy, PyTorch RNG | 실제로 사용된 추출을 계속합니다. | 복원 없이 하는 부정 실험이 발산하는지 확인합니다. |
| 데이터 | 순열과 커서를 재개합니다. | 중단 이후의 입력 식별자를 비교합니다. |
| 진행 상황 | 스텝과 에포크를 해석합니다. | 다시 하거나 빠뜨리지 않고 총 10회 업데이트에 도달합니다. |
| 구성 | 동일한 실험을 재구성합니다. | 차원, 정밀도, 설정, 버전을 유지합니다. |
올바른 순서로 복원하기
상태를 로드하기 전에 모델, 옵티마이저, 스케줄러를 재구성하세요. 스케줄러는 optimizer.load_state_dict()보다 먼저 생성해야 합니다. 그렇지 않으면 생성 과정에서 복원된 학습률을 덮어쓸 수 있습니다. 스케줄러 자체의 상태도 다시 로드한 뒤, 다음 스텝에서 실제로 사용되는 학습률을 확인하세요.
난수 생성기는 추출을 소비하는 객체를 생성한 뒤, 작업을 계속하기 직전에 복원하세요. 초기 시드만 다시 설정하면 시퀀스가 처음부터 시작됩니다. 이는 다섯 번째 업데이트 이후 도달한 상태를 되찾는 것이 아닙니다. 프로젝트에서 변환과 데이터 로딩에 사용되는 생성기를 포함해 사용된 모든 생성기를 파악하세요.
이 실습에서는 Python이 입력에 약간의 이득을 설정하고, NumPy PCG64 생성기가 노이즈와 순열을 만들며, PyTorch가 드롭아웃을 생성합니다. 체크포인트는 중단 시점에 도달한 이들의 상태를 유지합니다. 검증기는 또한 이들의 다음 추출도 확인하며, 계산의 나머지 부분을 방해하지 않도록 즉시 상태를 복원합니다.
optimizer = torch.optim.Adam(model.parameters(), lr=0.03)
scheduler = torch.optim.lr_scheduler.StepLR(optimizer, step_size=3, gamma=0.5)
# 재개 과정에서, 객체 생성 후:
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()일관된 저장 경계 선택
명시적인 경계를 정하세요. 예를 들어 옵티마이저의 완전한 업데이트 이후를 경계로 삼을 수 있습니다. 이 업데이트 전에 여러 마이크로배치를 누적한다면, 중간에 저장할 경우 중간 상태도 함께 관리해야 합니다. 누적된 그래디언트가 이미 소비된 경계에서 저장하면 첫 구현을 더 쉽게 검증할 수 있습니다.
여러 세대의 백업을 보존하세요. 새 파일을 별도의 이름으로 작성하고, 쓰기가 끝날 때까지 기다린 뒤 읽을 수 있는지 확인하고, 그 다음에 사용 가능으로 표시하세요. 이 확인 전에 유일하게 유효한 체크포인트를 교체하지 마세요. 주기는 다시 작업할 의향이 있는 범위와 관측된 쓰기 시간에 따라 달라지며, 대여 시간만으로 결정되지 않습니다.
이 미니 프로젝트는 한 번의 반복이 끝난 뒤 저장하고, 파일과 그 지문을 내보냅니다. 각 실행마다 새 폴더를 사용하며 이전 증거를 교체하지 않습니다. 학습에서 GradScaler와 함께 혼합 정밀도를 사용한다면 그 상태도 재개 대상에 포함됩니다. 이 변형은 CPU 실습에서 다루지 않습니다.
비교와 허용 오차 읽기
프로토콜은 5단계 이후의 이어하기를 비교합니다. 소비된 데이터, 학습률, 손실, 도달한 파라미터입니다. 단계 번호만 일치한다고 충분하지 않습니다. 초기화된 옵티마이저는 루프를 계속 진행하면서도 다른 업데이트를 만들어낼 수 있습니다.
이 실습에 선택된 허용 오차는 절대값 1e-12이며 상대 허용 오차는 0입니다. 이 임계값은 제공된 CPU 프로토콜의 일부이며, 여러분의 모델에 대한 보편적인 규칙이 아닙니다. 비교는 사용할 수 없는 출력을 조용히 받아들이는 대신, 비유한 값과 구조 차이를 표시해야 합니다.
PyTorch는 버전, 플랫폼, CPU와 GPU 간의 결과 동일성을 보장하지 않습니다. 실습을 이식한다면 대상에서 증명을 다시 수행하고 채택한 허용 오차를 설명하세요. 원인을 이해하지 못한 실패를 없애기 위해 임계값을 단순히 넓히지 마세요.
제공된 증명에서 전체 경로의 모든 편차는 0입니다. 파라미터, 옵티마이저 상태, 손실, 학습률, MSE 모두 그렇습니다. 행 순서, 진행률, 스케줄러 상태, 다음 샘플링도 일치합니다. 10단계 이후 다음 학습률은 두 경로 모두에서 0.00375입니다. 따라서 결과는 중간 차이를 가릴 수 있는 최종 지표 하나에만 의존하지 않습니다.
표의 모든 열을 보려면 스크롤하세요.| 비교 | 완전 재개 | RNG 복원 없는 재개 |
|---|---|---|
| 가중치 최대 편차 | 0 | 0,011669328447718508 |
| 최종 MSE | 0,09538858591775097 | 0,0936034144665111 |
| 연속 실행 대비 MSE 편차 | 0 | 0,001785171451239867 |
| 일치성 하위 테스트 판정 | 1e-12 허용 오차 내 일치 | 불일치 감지됨 |
난수 복원 없는 부정 케이스를 유지하는 이유
검사는 어떤 오류를 감지하는지 알 때 더 유용합니다. 부정 변형은 동일한 가중치, 옵티마이저 상태, 스케줄러, 진행도를 다시 로드하지만 RNG 복원은 의도적으로 생략합니다. 프로세스는 Python 예외 없이 종료될 수 있으면서도 다른 궤적을 따라갑니다.
제공된 증명에서 이 생략은 0.011을 초과하는 가중치 최대 편차와 0.0017을 초과하는 MSE 차이를 만듭니다. 여기서 부정 케이스의 MSE가 연속 실행보다 낮지만, 그것이 재개를 올바르게 만들지는 않습니다. 목적은 같은 실험을 되찾는 것이지, 최종 오차로 두 모델의 순위를 매기는 것이 아닙니다.
검증기는 전체 실행이 일치하고 부정 케이스가 불일치할 때만 성공합니다. 그때 all_checks_passed: true, positive: true, negative_divergence_detected: true를 출력합니다. 종료 코드는 프로토콜 성공 시 0, 비교 실패 시 1, 검증을 완료할 수 없었을 때 2입니다.
python -B train.py --steps 5 --resume runs/coupure/checkpoint.pt --omit-rng-restore --output runs/reprise-incomplete보호 조치를 완화하지 않고 실습 파일 로드하기
이 프로젝트는 이 실습으로 생성하고 직접 관리하는 체크포인트만 로드합니다. 명시적으로 torch.load(..., map_location="cpu", weights_only=True)를 사용합니다. Python 상태는 기본형을 담고, NumPy PCG64 생성기 상태는 정수와 문자열을 담으며, PyTorch CPU 상태는 바이트 텐서를 담습니다. 저장된 RNG 상태에 임의의 NumPy 배열은 들어가지 않습니다.
로더는 연관된 핑거프린트, 크기, 스키마, 진행 상태, 버전, 그리고 코드와 데이터의 신원을 검사합니다. 불일치 상태를 만나면 누락된 요소를 조용히 초기화하는 대신 거부합니다. 핑거프린트는 변경을 감지할 뿐, 파일 발신자를 인증하지는 않습니다.
단순히 로딩 오류를 없애기 위해 weights_only=False를 추가하지 마세요. 저장된 형식과 그 재구성이 일관되어야 합니다. 제한된 로딩은 역직렬화 가능성을 줄여주지만, 알 수 없는 파일을 신뢰할 만한 것으로 만들어 주지는 않습니다.
분산 학습에서 달라지는 점
여러 프로세스나 GPU에 분산된 상태를 다룰 때는 누가 무엇을 쓰는지 확인하세요. 단일 프로세스가 생성한 파일이 분산 작업의 완전한 백업이라고 볼 수는 없습니다. 전략에서 정한 백업 절차를 사용하고, 관련 참여자에서 완료될 때까지 기다리세요. 동일한 재개 지점에 속하는 조각들을 명확히 식별하세요.
GPU 수가 바뀌면 상태를 재분배해야 하고 데이터 분할도 달라질 수 있습니다. 분산 체크포인트 메커니즘이 일부 변경을 처리할 수 있지만, 이 가능성은 사용하는 형식과 구성에 대해 검증해야 합니다. 대상 환경에서 로딩 테스트를 해보세요. 주문에 배치를 추가한다고 해서 단일 카드 백업이 자동으로 분산 프로그램으로 바뀌지는 않습니다.
실제로 복구 가능한 내보내기로 마무리하기
마감 전에 유용한 체크포인트를 구성, 지표, 로딩 지침, 데이터 식별자와 함께 내보내세요. 복사한 파일의 크기와 핑거프린트를 확인한 다음, 최소한 하나의 백업을 목적지에서 로드하세요. 동일한 핑거프린트는 복사를 검증하고, 재로딩은 내용이 실제로 작업을 재구성하기에 충분한지 검증합니다.
출처를 아는 파일만 로드하고, 형식과 역직렬화 옵션을 상황에 맞게 선택하세요. 새 지점이 검사를 통과할 때까지 마지막으로 검증된 재개 지점을 유지하세요. 기대하는 결과물은 복구 가능한 폴더와 짧은 재개 증거입니다. 즉 실행한 명령, 복원한 단계, 통과한 검사, 내보낸 결과입니다. 3일, 7일 또는 30일 기간에 이 시간을 미리 확보하세요.
증거의 범위와 대여 선택
2026년 9월 24일의 증명은 CPU에서 4개의 새 프로세스를 비교하며, 절대 허용 오차는 1e-12이고 상대 허용 오차는 없습니다. CUDA, ROCm, AMP, 분산 학습, 데이터 로딩 워커는 다루지 않습니다. 이는 설명된 환경에서 제공된 버전의 재개 로직을 검증할 뿐, 대여한 GPU의 성능을 측정하지 않습니다.
이 작은 실습을 마친 후에는 동일한 프로토콜을 자신의 모델, 데이터, 백엔드에 적용하세요. 80GB 카드나 192GB 카드가 불완전한 체크포인트를 고쳐주지는 않습니다. 먼저 호환되는 체인을 선택하고, 그다음 실제 단계의 메모리 크기를 산정하세요. 아래 링크된 상품은 이 증거를 위해 테스트된 하드웨어로 제시된 것이 아닙니다.
3일, 7일 또는 30일 기간에 첫 번째 저장–중지–재개 주기와 최종 내보내기 시간을 미리 확보하세요. 유용한 결과물은 버전, 재개 지점, 비교 검사, 한계를 설명할 수 있는 폴더입니다. .pt 파일이 존재한다는 사실만으로는 이런 보증이 되지 않습니다.