1. 프로그램, 파라미터 및 상업적 추적 분리하기
코드는 프로그램의 동작을 설명합니다. 구성은 워크로드를 명시합니다: 모델, 데이터, 배치, 정밀도 및 목적지. 비밀 정보는 필요한 리소스에 대한 접근을 제공합니다. 코드를 다시 작성하거나 공유 파일에 토큰을 복사하지 않고도 실험을 변경할 수 있도록 이러한 요소를 구분해 두세요.
Kernodeck 주문 참조를 통해 계정에서 대여 컨텍스트를 찾을 수 있습니다. 실행 식별자는 해당 기간 동안 프로그램의 실행을 구분합니다. 필요하다면 노트에서 둘을 연결해 두되, 스크립트가 결제 상태로부터 계산 상태를 추론하도록 요구하지 마세요.
동일한 샘플에서 여러 번 실행해야 하는 문서 분류 프로젝트를 예로 들어 보겠습니다. 프로그램 계약은 입력 파일, 허용된 파라미터, 출력 폴더 및 오류를 반환하는 방식을 설명합니다. 데이터 가이드는 콘텐츠 검증을 다루며, 여기서는 이러한 단계를 연결하는 인터페이스를 구성합니다.
2. 명시적이고 버전이 지정된 입력 계약 작성하기
필수 필드와 허용되는 값을 문서화하세요. 모델이나 장치처럼 결과를 바꾸는 결정에 대해서는 암묵적인 기본값을 피하세요. 스키마 번호는 구성의 형태를 코드 버전과 구분하며, 코드 버전을 대체하지는 않습니다.
이 교육용 예시에서 JSON 파일은 스키마, 입력 경로, 배치 및 요청된 장치를 포함합니다. 상대 경로는 구성 폴더를 기준으로 읽습니다. 예시를 위해 선택한 이 규칙은 동료가 명령을 실행하는 디렉터리에 의존하지 않도록 합니다.
유효한 JSON을 읽는 것은 구문만 검사합니다. 그다음 프로그램이 타입, 필드 및 프로젝트 제약 조건을 확인해야 합니다. 오류가 있으면 값비싼 리소스를 로드하기 전에 중단하고, 수정해야 할 파라미터를 명시한 메시지를 표시해야 합니다.
{
"schema_version": 1,
"input": "../data/pilote.jsonl",
"batch_size": 4,
"device": "cuda"
}3. 단순한 오류를 거부하는 진입점 준비하기
argparse를 사용하면 옵션을 선언하고 명령에 대한 도움말을 생성할 수 있습니다. 다음 예시는 사전 점검에 불과합니다: 구성을 읽고, 필드를 확인하며, 이미 사용 중인 출력 폴더를 식별합니다. 모델이나 데이터를 메모리에 로드하지 않으며 GPU 가용성도 테스트하지 않습니다.
이 교육용 코드를 조정하려면 prepare_run.py에 저장하세요. 검증된 실행 없이 제공됩니다. 그다음 최종 메시지를 계산 결과로 간주하지 말고, 애플리케이션에 비즈니스 검사를 추가하세요. cuda 장치는 요청일 뿐이며, PyTorch는 ROCm에서도 이 이름을 사용합니다.
기존 출력 디렉터리를 거부하는 것은 여기서 실험의 혼합을 방지하기 위한 관례입니다. 실제 재개 명령은 별도의 옵션과 검사를 받아야 합니다. 파일이 존재한다는 이유로 새로운 실행을 암묵적 재개로 만들지 마세요.
import argparse
import json
from pathlib import Path
parser = argparse.ArgumentParser(description="프로젝트 실행 검증")
parser.add_argument("--config", type=Path, required=True)
parser.add_argument("--run-dir", type=Path, required=True)
args = parser.parse_args()
try:
config_path = args.config.resolve()
config = json.loads(config_path.read_text(encoding="utf-8"))
except (OSError, UnicodeError, json.JSONDecodeError) as exc:
parser.error(f"설정 파일을 읽을 수 없습니다: {exc}")
expected = {"schema_version", "input", "batch_size", "device"}
if not isinstance(config, dict) or set(config) != expected:
parser.error("필수 필드: schema_version, input, batch_size, device")
if type(config["schema_version"]) is not int or config["schema_version"] != 1:
parser.error("schema_version은 1이어야 합니다")
if type(config["batch_size"]) is not int or config["batch_size"] < 1:
parser.error("batch_size는 양의 정수여야 합니다")
if config["device"] not in ("cpu", "cuda"):
parser.error("device는 cpu 또는 cuda여야 합니다")
if not isinstance(config["input"], str) or not config["input"]:
parser.error("input은 비어 있지 않은 경로여야 합니다")
input_path = (config_path.parent / config["input"]).resolve()
run_dir = args.run_dir.resolve()
if not input_path.is_file():
parser.error("입력 파일이 없습니다")
if run_dir.exists():
parser.error("새 출력 폴더를 선택하세요")
print(json.dumps({
"status": "configuration_validated",
"input": str(input_path),
"run_dir": str(run_dir),
"device_requested": config["device"],
"batch_size": config["batch_size"]
}, ensure_ascii=False))python prepare_run.py --config config/pilote.json --run-dir runs/pilote-0014. 실행과 그 결과에 식별자 부여하기
각 실행을 캠페인 내에서 고유한 짧은 식별자와 연결하세요. 코드 리비전, 실제 사용된 스키마와 파라미터, 그리고 데이터와 모델의 참조를 기록하세요. 이 값들을 출력과 함께 보관하여 나중에 수정된 설정 파일에 결과가 의존하지 않도록 하세요.
두 가지 배치 크기를 비교하려면 두 개의 실험과 두 개의 디렉터리를 만드세요. 동일한 샘플을 유지하고 의도적인 차이를 식별하세요. pilote-001과 pilote-002라는 이름만으로는 무엇이 변경되었는지 설명되지 않습니다. 매니페스트가 이름과 파라미터를 연결합니다.
도구가 읽을 수 있는 요약 형식을 마련하세요. 수신, 성공, 거부, 처리 대기 항목을 구분할 수 있습니다. 완전한 성공 규칙을 정하고 첫 번째 결과가 기록되었다고 해서 실험을 완료로 표시하지 마세요. 프로그램의 반환 코드는 이 결론과 일관성을 유지해야 합니다.
표의 모든 열을 보려면 스크롤하세요.| 파일 또는 상태 | 역할 | 필요한 점검 |
|---|---|---|
| manifest.json | 코드, 데이터 및 파라미터의 식별 정보 | 비밀 정보 없이 실제 사용된 값. |
| results.jsonl | 허용된 항목당 하나의 출력 | 알려진 식별자와 준수된 형식. |
| errors.jsonl | 거부된 항목과 유용한 사유 | 조용한 누락이나 불필요한 민감 콘텐츠 없음. |
| summary.json | 실험 결론 및 카운터 | 합계 일치, 최종 상태 전 파일 재확인. |
5. 도구에 유용한 이벤트 노출하기
몇 가지 전환을 가시화하세요. 설정 허용, 데이터 접근 가능, 모델 로드, 첫 출력 기록, 처리 종료 등입니다. 추적 기록은 문서나 프롬프트를 복사하지 않고도 "이 실행은 어디까지 진행되었는가?"에 답할 수 있어야 합니다. 단계와 실험 식별자를 메시지와 연결하세요.
Python의 logging 모듈을 사용하면 메시지를 레벨과 대상별로 구성할 수 있습니다. 그런 다음 자체 이벤트 규칙을 정하고 문서화하세요. 오류를 기록한 후 성공으로 종료하는 애플리케이션은 자동화를 오도합니다. 반대로 모든 경고가 결과를 사용할 수 없다는 의미는 아닙니다.
발생한 이벤트와 지속적인 결과를 혼동하지 마세요. "백업 시작됨" 메시지는 파일이 재확인되었음을 증명하지 않습니다. 장시간 실행의 경우 전용 가이드에서 프로세스와 세션의 관계를 설명합니다. 인터페이스는 무엇보다 대화형 연결이 끝난 후에도 결론에 접근할 수 있어야 합니다.
6. 실패, 재개 및 최종 검증 정의하기
유용한 실패를 분류하세요: 잘못된 구성, 없는 리소스, 계산 오류, 규격에 맞지 않는 결과. 각각에 대해 다음 조치를 제시하세요. 어떤 효과가 반복될 수 있는지 결정하지 않은 채 자동 재시도를 설치하지 마세요. 이미 승인된 출력을 다시 작성하는 것과 체크포인트를 재개하는 것은 서로 다른 규칙이 필요합니다.
최종 절차는 실행, 관찰, 중지, 재개, 내보내기 방법을 설명해야 합니다. 문서 처리라면 완료된 식별자 목록과 재처리할 식별자 목록을 유지하세요. 학습이라면 새 프로세스에서 저장된 상태를 검증하는 프로토콜을 사용하세요. 비어 있지 않은 폴더가 올바른 재개의 증거는 아닙니다.
마지막으로 알려진 구성과 별도의 목적지를 사용해 새로운 호출에서 프로젝트를 점검하세요. 예상된 거부를 확인한 다음, 작은 전체 경로를 검증하세요. 이 페이지의 사전 점검은 동시 접근, 서비스의 공개 노출, 스토리지 권한을 다루지 않습니다. 이러한 주제는 별도의 설계가 필요합니다.