1. 기준과 예상 결과 정의하기
무엇을 재현하려는지부터 시작하세요: 동일한 카테고리 생성, 유사한 값 얻기, 또는 학습 궤적 이어가기. 중요한 단계를 통과하는 작은 입력 집합과 유효한 출력 예시를 보관하세요. 오류 없이 끝나는 설치가 아직 이 질문에 답하는 것은 아닙니다.
교육적인 사례를 하나 들어 보겠습니다. 애플리케이션이 식별된 샘플에 대해 임베딩을 생성한다고 합시다. 기준 환경에서는 출력의 형태, 자료형, 비유한 값의 부재, 그리고 실질적으로 유용한 업무 기준을 기록해야 합니다. 값을 비교한다면 사용 목적에 따라 정당화되는 허용 오차를 선택하세요. 여기서는 보편적인 수치 임계값을 제공하지 않습니다.
코드, 데이터, 가중치에 리비전을 부여하세요. «최신-모델» 같은 이름은 프로그램에 드러나지 않은 채 바뀔 수 있습니다. 또한 파라미터와 전처리도 기준에 함께 연결하세요. 이 기록이 있어야 차이가 소프트웨어에서 비롯된 것인지, 입력에서 비롯된 것인지, 실행 조건에서 비롯된 것인지 알 수 있습니다.
표의 모든 열을 보려면 스크롤하세요.| 항목 | 유지할 항목 | 재구성 후 점검 |
|---|---|---|
| 코드 및 파라미터 | 리비전, 변경 사항, 구성 | 동일한 진입점과 동일한 옵션. |
| 데이터 및 가중치 | 버전 또는 해시, 출처 및 접근 권한 | 동일한 샘플과 동일한 예상 내용. |
| Python 및 패키지 | 버전, 절차 및 설치 출처 | 올바른 인터프리터와 일관된 의존성. |
| 시스템 및 백엔드 | OS, 아키텍처, 드라이버, CUDA 또는 ROCm | 장치가 인식되고 최소 연산이 성공했습니다. |
| 결과 | 형식 및 수용 기준 | 먼저 구조, 그다음 품질 또는 예정된 허용 오차. |
2. 시스템 체인과 Python 패키지 분리하기
그래픽 카드, 시스템, 드라이버, Python, 라이브러리를 함께 확인하세요. 가상 환경은 Python 패키지를 정리해 주지만 시스템 드라이버를 대체하지는 않습니다. 마찬가지로 이미지 참조만으로는 호스트에서 GPU에 실제로 접근하는 방식을 설명하기에 충분하지 않습니다. 컴파일된 확장의 경우 필요한 컴파일 도구와 라이브러리를 기록하세요.
프로젝트의 연산 플랫폼에 따라 PyTorch 배포판을 선택하세요. ROCm에서 PyTorch는 torch.cuda 호출과 cuda라는 이름의 장치를 그대로 사용합니다. 즉 인터페이스 이름만으로는 NVIDIA를 식별할 수 없습니다. torch.version.cuda와 torch.version.hip을 각각 따로 기록하세요. 특정 체인을 위해 작성된 확장은 별도로 점검할 가치가 있습니다.
실제로 설치를 가능하게 한 절차를 패키지 출처와 함께 보관하세요. 호환성을 검토하지 않은 채 온라인에서 찾은 최신 명령과 오래된 의존성 파일을 섞지 마세요. 참고한 문서는 바뀔 수 있으니 사용한 버전을 자신의 기록에 남기세요.
3. 설치된 폴더를 복사하지 않고 재구성하기
선택한 Python으로 새 환경을 만드세요. 그런 다음 명시적으로 그 인터프리터를 사용해 프로젝트를 설치하고 실행하세요. Linux에서는 예를 들어 .venv-rebuild/bin/python, Windows에서는 .venv-rebuild\Scripts\python.exe입니다. 이전에 활성화했는지에 의존할 필요는 없습니다. Python 문서에 따르면 가상 환경은 위치가 바뀌면 다시 만들어야 합니다.
pip freeze는 설치된 패키지의 목록을 제공할 뿐, 계산된 잠금 파일이 아닙니다. 이는 관찰 기록으로 보관하세요. 재구성 파일은 또한 사용자의 PyTorch 변형에 필요한 인덱스나 파일, 그리고 호환되는 버전을 명시해야 합니다. 공유하기 전에 목록에 포함될 수 있는 경로나 URL을 다시 확인하세요.
아래 명령은 상황에 맞게 조정해야 하는 Linux 재구성 예시이며, 여러분의 프로젝트에 대해 실제로 실행한 시험은 아닙니다. requirements-rebuild.txt 파일은 이미 PyTorch의 올바른 선택을 포함해 여러분의 환경을 설명하고 있어야 합니다. 이를 보편적으로 통용된다고 가정한 버전 목록으로 대체하지 마세요.
python -m venv .venv-rebuild
.venv-rebuild/bin/python -m pip --version
.venv-rebuild/bin/python -m pip install -r requirements-rebuild.txt
.venv-rebuild/bin/python -m pip check
.venv-rebuild/bin/python -m pip freeze --all > installed-after.txt4. 연산 전에 의존성 계약 확인하기
올바른 인터프리터로 실행한 python -m pip check는 메타데이터에 따라 설치된 의존성 중 누락되거나 호환되지 않는 것을 찾습니다. 충돌이 없다는 결과가 드라이버, 네이티브 확장, 애플리케이션 품질을 검증해 주는 것은 아닙니다. 따라서 이 단계는 짧게 유지하고 연산 점검으로 넘어가세요.
재현을 더 엄격하게 만들려면 버전을 고정하고 허용된 배포본의 지문을 보관할 수 있습니다. 이 결정은 사용자의 플랫폼에 해당하는 전체 목록을 유지하는 일을 수반합니다. 컴파일된 휠 아카이브는 OS와 아키텍처에 따라 달라질 수 있으며, 서로 다른 두 머신 간의 이식성을 보장하지 않습니다.
임베딩 예제에서는 모델이나 매개변수를 수정하기 전에 재구성된 인벤토리를 기준과 비교하세요. 차이가 의도된 것이라면 기록하고 새 실행을 변형으로 취급하세요. 그렇지 않다면 재구성을 수정하세요. 여러 계층을 한꺼번에 변경하면 진단이 덜 정확해집니다.
5. 최소 검증에서 애플리케이션으로 넘어가기
프로젝트 인터프리터에서 Python, PyTorch 및 백엔드를 확인한 다음, 디바이스와 간단한 연산을 검증하세요. 예상한 GPU에 접근할 수 없다면 이 단계를 중단하세요. 대체 CPU 실행은 비교를 흐리게 만듭니다. Kernodeck 진단은 해석 가능한 보고서를 제공하고 실제로 통과한 단계를 구분합니다.
이 검증이 성공하면 작은 애플리케이션 샘플을 사용하세요. 임베딩의 경우 출력 개수, 차원, 식별자와의 대응, 선택한 기준을 확인하세요. 출력 폴더에서 파일을 다시 로드하세요. 행렬 연산이 성공했다고 해서 전처리나 프로젝트 확장 기능이 작동한다는 것을 증명하지는 않습니다.
데이터 읽기, 전송 또는 특정 연산 중에 시도가 실패하면 단계와 첫 번째 오류를 보관하세요. 일반적인 재구성은 올바를 수 있으며, 문제는 데이터 로더나 특정 연산자에 속할 수 있습니다. 그렇다면 진단을 해당 계층으로 향하게 하세요.
6. 재구성과 수치적 동일성 구분
동일한 의존성을 복원한다고 해서 하드웨어, 플랫폼 또는 PyTorch 버전 간에 동일한 결과가 보장되지는 않습니다. 시드를 고정해도 모든 변동 원인을 포괄하지는 못합니다. 사용된 생성기, 데이터 변환, 관련 정밀도 또는 결정론 설정을 문서화하세요.
차이를 살펴보기 전에 비교 기준을 정의하세요. 정확한 구조, 수치 허용 오차 또는 지표의 안정성 등입니다. 일부 결정론 설정은 특정 연산을 거부하거나 계산 비용을 변경할 수 있습니다. 원하는 결과는 명시된 조건에서 이해할 수 있는 결론이지, 모든 머신에서의 동일성 약속이 아닙니다.
학습 재개에는 버전만으로 충분하지 않습니다. 계산 상태와 진행 상황도 복원해야 합니다. 재개 폴더는 이 문제를 별도로 검증합니다. 그 CPU 연습과 허용 오차가 자동으로 사용자의 모델 조건이 되지는 않습니다.
7. 다른 실행에서도 사용할 수 있는 폴더로 마무리
최종 폴더에는 절차, 관찰된 인벤토리, 구성, 데이터 참조 및 검증 결과가 포함됩니다. 정확한 순서를 추가하세요. 재구성, 진단, 샘플 실행, 출력 재확인 순입니다. 접근 정보는 별도로 보관하고 제공 방법만 명시하세요.
환경을 이전 가능하다고 간주하기 전에 깨끗한 폴더에서 이 순서를 다시 실행하세요. 오래된 노트북의 변수를 가져오거나 잊힌 파일을 찾지 않고도 검증이 성공해야 합니다. 변경이 필요하면 절차를 수정하고 참조에 새 식별자를 부여하세요. 다음 연산 기간에 사용할 수 있는 기반을 얻게 됩니다.