필요를 충족하는 기준부터 시작하기
일반 입력, 경계 사례 및 결정 경계로 구성된 짧은 데이터셋을 선택하세요. 모델, 가중치, 전처리 및 train 또는 eval 모드를 고정하세요. 두 모델이나 두 배치 간의 비교로는 그 차이를 정밀도에 귀속시킬 수 없습니다.
손실만이 아니라 애플리케이션에 유용한 출력을 기록하세요. 분류기의 경우 점수와 결정이 포함될 수 있고, 회귀의 경우 오류와 극단값이 포함될 수 있습니다. 기준에서 이미 NaN 또는 inf의 존재를 확인하세요. 잘못된 FP32 실행은 비트 수가 더 많다는 이유로 신뢰할 수 있는 기초가 되지 않습니다.
시험 전에 허용 오차, 최소 품질 및 비유한값 부재를 정하세요. PyTorch는 부동 소수점 계산이 장치나 실행 경로 간에 동일한 결과를 보장하지 않는다고 상기시킵니다.
autocast, 수치 형식 및 GradScaler 구분하기
autocast는 각 연산의 계산 정책에 따라 일부 연산의 타입을 선택합니다. 전체 프로그램을 단일 형식으로 변환하지는 않습니다. 이 방식을 쓸 때는 모델 전체를 half()로 수동 변환하지 마세요. 현재 문서는 torch.autocast 또는 torch.amp.autocast를 권장하며, 구형 인터페이스인 torch.cuda.amp는 지원이 중단되었습니다.
GradScaler는 학습 중 손실과 기울기의 스케일을 조정합니다. backward를 수행하지 않는 추론의 가속기로 쓰는 것이 아닙니다. FP16은 BF16보다 수치 범위가 좁으므로 BF16용으로 설계된 모델은 FP16에서 오버플로가 발생할 수 있습니다. 따라서 스케일이 반복적으로 감소한다고 해서 문제가 해결되었다고 단정할 수 없습니다.
모델의 제약과 실제로 사용하는 연산을 기준으로 형식을 선택한 뒤, 대상 환경의 지원 여부를 확인하세요. 그래픽카드의 상용 이름이나 PyTorch 준비 방식에 대한 선호만으로는 사용자 정의 연산자가 원하는 커널을 갖추고 있다는 것이 증명되지 않습니다.
표의 모든 열을 보려면 스크롤하세요.| 선택 | 역할 | 필요한 점검 |
|---|---|---|
| FP32 기준 | 프로젝트 비교 기준점 | 유한한 출력과 기대 품질 |
| FP16 autocast | 일부 연산은 축소 정밀도로 | 수치 범위와 기울기 |
| BF16 autocast | 범위/정밀도의 또 다른 절충 | 사용 가능한 연산자와 품질 |
| GradScaler | 기울기 스케일 관리 | 실제로 반영된 업데이트 |
학습 단계를 올바른 순서로 배치하기
제시된 코드 조각은 모델과 옵티마이저가 이미 생성되었고, 입력과 타깃이 같은 GPU에 있으며, 손실이 스칼라라고 가정합니다. 이 코드는 실행되지 않았으며 어떤 상품에 대한 검증도 아닙니다. autocast 컨텍스트는 forward와 손실을 감싸고, backward는 컨텍스트가 닫힌 뒤에 수행됩니다. scaler는 배치마다가 아니라 학습 세션당 한 번 생성합니다.
기울기를 검사하거나 클리핑하려면 먼저 unscale_로 스케일 인자를 제거하세요. 공식 AMP 예제에서는 이를 옵티마이저마다 한 번, 그리고 해당 옵티마이저의 업데이트에 사용할 기울기를 누적한 뒤에 수행하도록 명시합니다. 아래의 클리핑 임계값 1.0은 예시 값일 뿐이며 프로젝트에 맞게 선택해야 할 값이지, 보편적인 권장 사항이 아닙니다.
여기의 가드는 손실, 기울기 또는 전체 노름이 유한하지 않으면 진단을 중단합니다. 이러한 CPU 읽기는 부하가 크므로 이 코드 조각의 시간을 측정하지 마세요. 누적, 다중 옵티마이저, 스케줄러는 각각의 업데이트 정의가 필요합니다.
import torch
# 전제 조건: model, optimizer, loss_fn, inputs, targets가 존재합니다.
# 모델과 입력은 같은 CUDA/HIP 장치에 있습니다.
dtype = torch.float16 # 검증이 필요한 선택이며 BF16은 또 다른 시도입니다.
scaler = torch.amp.GradScaler("cuda", enabled=(dtype == torch.float16))
# 루프 안에 배치하되, scaler는 배치 간에 유지합니다.
optimizer.zero_grad(set_to_none=True)
with torch.autocast(device_type="cuda", dtype=dtype):
prediction = model(inputs)
loss = loss_fn(prediction, targets)
if not bool(torch.isfinite(loss).item()):
raise FloatingPointError("손실이 유한하지 않음: 진단 중단")
scaler.scale(loss).backward()
scaler.unscale_(optimizer)
if any(p.grad is not None and
not bool(torch.isfinite(p.grad).all().item())
for p in model.parameters()):
raise FloatingPointError("기울기가 유한하지 않음: 진단 중단")
torch.nn.utils.clip_grad_norm_(
model.parameters(), max_norm=1.0, error_if_nonfinite=True,
)
scaler.step(optimizer)
scaler.update()실습 예제: 서로 비슷한 두 결정은 서로 바꿀 수 없다
최대 점수의 클래스를 선택하는 서비스를 가정해 봅시다. 교육용 입력에서 기준 구현은 1.0000과 1.0003이라는 매우 가까운 두 점수를 산출합니다. 다른 수치 경로는 이 순서를 바꾸거나 동점을 만들 수 있습니다. 이 숫자들은 결정 경계를 예시할 뿐이며, FP16이나 BF16의 측정된 출력이 아닙니다.
올바른 검증은 두 단계로 이루어집니다. 먼저 명시적인 허용 오차로 점수를 비교하고, 그다음 결정과 동점 처리 규칙을 비교합니다. 절댓값 차이가 작아도 선택되는 동작이 달라질 수 있습니다. 반대로, 수치상 눈에 띄는 차이가 있어도 임계값이 관측된 점수에서 멀리 떨어진 작업에는 아무 영향이 없을 수 있습니다.
식별자, 기준 출력, AMP 시험, 그리고 의사결정에 미친 영향을 기록합니다. 결과를 읽기 전에 합격 기준을 정합니다. 불편한 사례를 없애기 위해 허용 오차를 넓히지 마세요; 서로 다른 규모의 출력에는 별도의 기준이 필요할 수 있습니다.
표의 모든 열을 보려면 스크롤하세요.| 기준 | 참조 | AMP 시험 | 결정 |
|---|---|---|---|
| 완결된 출력 | 확인할 항목 | 확인할 항목 | 설명되지 않은 비완결 출력은 거부 |
| 수치 격차 | 보존된 값 | 계산할 격차 | 시험 전에 정의한 허용 오차 |
| 애플리케이션 결정 | 클래스 또는 액션 | 클래스 또는 액션 | 변경 사항 검토 |
| 고정된 데이터셋에서의 품질 | 측정 대상 | 측정 대상 | 프로젝트 임계값 준수 |
NaN과 건너뛴 업데이트 해석하기
비완결 출력이 나타나면, 이를 생성하는 첫 단계를 찾으세요: 입력, 중간 출력, 손실 또는 그래디언트. 동일한 사례를 기준으로 재실행한 다음, 의심되는 연산 주변에서 autocast를 국소적으로 비활성화하고 그 입력의 타입도 확인하세요. 전체 학습을 FP32로 다시 돌리는 것은 비교 자료로는 쓸모가 있지만, 문제를 자동으로 국소화해 주지는 않습니다.
스케일러는 그래디언트에 inf나 NaN이 포함될 경우 업데이트를 건너뛸 수 있습니다. 따라서 계속 진행되는 루프가 반드시 반복 횟수만큼 업데이트를 수행했다는 뜻은 아닙니다. 진단 중에는 이 동작을 기록하세요. 실제 수행된 업데이트를 따른다고 가정한 학습 정책을 맹목적으로 진행시키지 마세요.
손실이 유한하다고 해서 그래디언트도 유한하다고 보장되지는 않습니다. 반대로, 일시적인 사고 하나만으로 학습이 사용 불가능하다고 단정할 수는 없습니다: 빈도, 진행 상황, 품질을 살펴보세요. AMP 레시피는 autocast와 스케일링 중 하나가 의심될 때 둘을 개별적으로 분리하는 방법을 제공합니다.
재현 가능한 롤백 준비
시험 전에 기준 구성, 가중치, 옵티마이저 상태, 그리고 일관된 체크포인트를 보존하세요. 학습에서 스케일러를 사용한다면 그 상태도 재개 시 포함됩니다. dtype과 FP32로 남겨 둔 영역이 있다면 문서화하세요. 다른 정책으로 재개하는 것은 암묵적으로 동등한 연속이 아니라 식별해야 할 실험적 변경입니다.
출력이 비유한 값이 되거나, 품질이 정한 기준을 벗어나거나, 업데이트가 더 이상 활용 가능한 수준으로 진행되지 않으면 이전 구성으로 돌아가세요. 이 롤백을 정당화한 사례를 보존하세요. 수정 후에는 기간을 늘리기 전에 동일한 데이터셋에서 비교를 다시 시작하세요.
Kernodeck의 체크포인트 실습은 AMP 없이 CPU 재개를 검증합니다. 실제 루프에서 소비하는 상태를 추가하여 그 비교 방법을 재사용하세요.
수치 검증 후에만 이득 측정하기
검증 후에는 상세 진단 없이 메모리와 시간을 측정하세요. 형태, 배치, 모델, 품질은 유지하세요. 스칼라 읽기, 동기화, 프로파일러는 소요 시간을 바꿀 수 있으므로 최종 측정에서는 간섭적인 점검을 제거하세요.
ROCm에서는 PyTorch의 디바이스 이름이 여전히 cuda이며 해당 인터페이스가 재사용됩니다. 이는 NVIDIA와 동일한 커널이나 동일한 결과를 보장하지 않습니다. 대상 환경에서 프로젝트의 백엔드와 연산자를 확인하세요. 이 가이드는 Kernodeck의 고정된 메모리 절감, 속도 배수, 준비 호환성을 보장하지 않습니다.