Day 3 - 디버깅과 프로파일링: SageMaker Debugger와 Profiler

Debugger와 Profiler의 역할 분리

손실이 줄지 않거나, 비싸게 빌린 GPU의 활용률이 30%에 머문다면 학습 내부를 들여다봐야 한다. 먼저 두 도구의 관심사를 명확히 가른다.

• 핵심 직관: Debugger는 "모델이 잘못됐다"를, Profiler는 "자원이 낭비된다"를 본다.
• "그래디언트가 0이 됐다/폭발한다" 같은 학습 품질 증상 → Debugger.
• "GPU가 놀고 있다/데이터 로딩이 느리다" 같은 자원 증상 → Profiler.

증상을 먼저 계층으로 분류한다
 
  손실·정확도가 이상하다        → 모델 계층      → Debugger (텐서)
        │
  학습은 되는데 느리다/비싸다    → 자원 계층      → Profiler (GPU/CPU/IO)
        │
  작업 상태·전체 추세를 보고 싶다 → 운영 계층      → CloudWatch (메트릭·로그·알람)

이 분리는 관측가능성(observability)의 두 층위에 대응한다. Debugger는 모델이라는 "수학적 프로세스"의 내부 상태(텐서)를 본다 — 그래디언트가 소실되면 학습이 멈추고 폭발하면 발산한다. Profiler는 그 프로세스가 돌아가는 "물리적 자원"의 사용 패턴을 본다 — GPU가 데이터를 기다리며 노는지, 전처리가 CPU를 묶고 있는지. 두 층위를 같이 봐야 "왜 학습이 안 되는가"와 "왜 비싼가"를 동시에 푼다.

SageMaker Debugger: 모델 내부를 본다

Debugger는 학습 중 텐서(그래디언트, 가중치, 손실 등)를 정기적으로 S3에 저장하고, 미리 정의된 내장 규칙(built-in rule)으로 이상을 감지한다.

from sagemaker.debugger import Rule, rule_configs, DebuggerHookConfig
 
estimator = PyTorch(
    entry_point='train.py', role=role,
    instance_type='ml.g5.xlarge', instance_count=1,
    framework_version='2.0', py_version='py310',
    rules=[
        Rule.sagemaker(rule_configs.vanishing_gradient()),   # 그래디언트 소실
        Rule.sagemaker(rule_configs.exploding_tensor()),     # 텐서 폭발
        Rule.sagemaker(rule_configs.overfit()),              # 과적합
        Rule.sagemaker(rule_configs.loss_not_decreasing())   # 손실 정체
    ],
    debugger_hook_config=DebuggerHookConfig(
        s3_output_path='s3://my-bucket/debug-tensors/'
    )
)

내장 규칙을 "무엇을 보고 → 무엇을 의심하고 → 무엇을 하는가"로 묶어 외운다.

수집할 텐서를 직접 고르고 저장 주기를 조절할 수도 있다. 텐서를 촘촘히 저장하면 진단은 정밀해지지만 S3 쓰기와 학습 오버헤드가 늘어난다.

from sagemaker.debugger import DebuggerHookConfig, CollectionConfig
 
debugger_hook_config = DebuggerHookConfig(
    s3_output_path='s3://my-bucket/debug-tensors/',
    collection_configs=[
        CollectionConfig(name='losses',    parameters={'save_interval': '50'}),
        CollectionConfig(name='gradients', parameters={'save_interval': '100'}),
        CollectionConfig(name='weights',   parameters={'save_interval': '500'}),
    ]
)

개념: 규칙은 학습 밖에서 돈다. Debugger 내장 규칙은 학습 컨테이너 안이 아니라 별도의 평가 작업으로 실행된다. 학습은 텐서를 S3에 쓰기만 하고, 규칙은 그 텐서를 읽어 판정한다. 덕분에 규칙 평가가 학습 속도를 크게 갉아먹지 않지만, 그만큼 판정에 약간의 지연이 있고 별도 리소스 비용도 붙는다는 점을 같이 기억한다.

⚠️ 함정: 규칙은 기본적으로 "감지 후 보고"만 한다. 규칙이 위반됐을 때 학습을 자동으로 멈추려면 action을 따로 연결해야 한다. 예를 들어 그래디언트가 폭발하는데도 학습이 끝까지 돌면서 비용만 태우는 사고를 막으려면 StopTraining 액션을 건다. "감지=자동중단"이라고 착각하지 않는 게 핵심.

from sagemaker.debugger import Rule, rule_configs
from sagemaker.debugger import CollectionConfig
 
# 규칙 위반 시 학습 자동 중단 + 알림
rule = Rule.sagemaker(
    rule_configs.loss_not_decreasing(),
    actions=rule_configs.ActionList(
        rule_configs.StopTraining(),          # 학습 중단(비용 절약)
        rule_configs.Email("ml-team@example.com")
    )
)

SageMaker Profiler: 자원을 본다

Profiler는 학습 중 시스템 자원(CPU·GPU 활용률, GPU 메모리, 네트워크·I/O)과 프레임워크 동작을 수집해, 병목을 찾아 리포트한다. 비싼 GPU 인스턴스를 빌렸는데 활용률이 낮으면 그만큼 돈을 버리는 것이므로 비용 최적화와 직결된다.

from sagemaker.debugger import ProfilerConfig, FrameworkProfile
 
estimator = PyTorch(
    entry_point='train.py', role=role,
    instance_type='ml.p4d.24xlarge', instance_count=1,
    framework_version='2.0', py_version='py310',
    profiler_config=ProfilerConfig(
        system_monitor_interval_millis=500,
        framework_profile_params=FrameworkProfile()
    )
)

Profiler가 흔히 잡아내는 병목을 증상 → 원인 → 조치로 정리하면 이렇다.

전형적 처방: GPU 활용률이 낮고 데이터 로딩이 병목이면 → DataLoader worker 수 증가, 데이터를 FSx for Lustre로 캐시, 전처리를 학습과 비동기로(프리페치).

⚠️ 함정: "학습이 느리다 → 더 비싼 GPU 인스턴스로 바꾼다"는 보기는 대부분 오답이다. GPU가 이미 놀고 있다면 더 빠른 GPU를 붙여도 노는 시간만 늘 뿐이고 비용만 오른다. 인스턴스 업그레이드는 Profiler로 "GPU 연산 자체가 포화"임을 확인한 뒤의 선택이다.

GPU 저활용의 본질은 "GPU가 노는 시간"이다. 학습 한 스텝은 데이터 로딩 → 전처리 → forward → backward → 옵티마이저로 이어지는데, GPU는 forward/backward만 한다. 나머지 단계가 느리면 GPU는 기다린다. 그래서 데이터 파이프라인(로딩·전처리)을 GPU 연산과 겹치게(overlap) 만드는 프리페치·비동기 로딩이 활용률을 끌어올린다. Profiler는 이 "기다리는 시간"을 가시화해 어느 단계를 고칠지 알려준다.

학습 모니터링: CloudWatch와의 관계

Debugger/Profiler는 학습 작업 내부의 정밀 분석이고, 전체 운영 모니터링은 CloudWatch가 맡는다.

내가 찍는 로그를 CloudWatch 메트릭으로 올리려면 정규식으로 뽑아내는 규칙을 Estimator에 등록한다. 이래야 여러 학습 작업의 손실 곡선을 한 화면에서 비교하고 알람을 걸 수 있다.

estimator = PyTorch(
    entry_point='train.py', role=role,
    instance_type='ml.g5.xlarge', instance_count=1,
    framework_version='2.0', py_version='py310',
    enable_sagemaker_metrics=True,
    metric_definitions=[                       # 로그 한 줄에서 숫자를 뽑는 규칙
        {'Name': 'train:loss',      'Regex': r'train_loss: ([0-9\.]+)'},
        {'Name': 'validation:loss', 'Regex': r'val_loss: ([0-9\.]+)'},
        {'Name': 'validation:acc',  'Regex': r'val_acc: ([0-9\.]+)'},
    ],
)

• 스크립트는 그냥 print(f"val_loss: {loss:.4f}") 처럼 찍기만 하면 된다.
• 여기서 만든 지표는 뒤에 배울 하이퍼파라미터 튜닝의 목표 지표로도 그대로 쓰인다.

[학습 작업]
   ├─ Debugger  → 텐서를 S3에 저장, 규칙 평가, 액션(중단/알림)
   ├─ Profiler  → 시스템·프레임워크 메트릭, 병목 리포트
   └─ CloudWatch → 메트릭/로그(전반 모니터링·알람)

한 팀이 ml.p4d 인스턴스로 학습하는데 GPU 활용률이 25%에 머물러 학습이 예상보다 4배 느렸다. Profiler 리포트를 보니 GPU가 대부분 데이터 로딩을 기다리고 있었다. 원인은 매 배치를 S3에서 직접 읽고 CPU 전처리가 무거웠던 것. DataLoader worker를 늘리고 데이터를 FSx for Lustre에 캐시한 뒤 전처리를 프리페치로 겹치자 GPU 활용률이 85%로 올라 학습 시간이 1/3로 줄었다. 교훈: 느린 학습이 항상 GPU 성능 문제는 아니다 — Profiler로 진짜 병목을 먼저 본다.

비용을 자동으로 막는 고리

관측의 실질적 효용은 "사람이 보고 있지 않아도 낭비가 끊긴다"에 있다. 감지와 조치를 하나의 고리로 묶는다.

학습 작업
   │  텐서 저장(S3)                     시스템 메트릭
   ├──────────────► Debugger 규칙        ├──────► Profiler 리포트
   │                     │                        │
   │              위반 감지                   병목 진단
   │                     │                        │
   │              ┌──────┴───────┐                └─► 파이프라인 개선(사람)
   │              │              │
   │        StopTraining      Email/SNS 알림
   │              │
   └──────────────┘  ← 남은 학습 시간만큼 비용 절감

• 규칙만 걸고 액션을 안 붙이면 이 고리가 끊긴 채 돌아간다 — 리포트는 쌓이는데 돈은 계속 나간다.
• 반대로 액션을 너무 공격적으로 걸면 정상적인 손실 정체 구간(플래토)에서도 학습이 끊긴다. 규칙 임계값과 최소 학습 스텝을 함께 본다.

어떻게 고르는가

증상이 무엇인가?
 ├─ 손실 정체 / 그래디언트 소실·폭발 / 과적합
 │     → Debugger 내장 규칙  (+ StopTraining action으로 비용 차단)
 ├─ 느리다 / GPU가 논다 / 비용 대비 비효율
 │     → Profiler로 병목 진단 → 데이터 파이프라인·배치·정밀도 조정
 │        (GPU 연산 포화가 확인된 뒤에야 인스턴스 업그레이드)
 └─ 전체 추세·실패 알림·여러 작업 비교
       → CloudWatch 메트릭/로그/알람 (+ EventBridge로 후속 자동화)

다음 글에서는 학습이 끝난 모델이 정말 좋은지 판단하는 모델 평가 — 지표 선택과 과적합·교차검증 —를 본다.

📖 용어

• 텐서(tensor) : 모델이 계산에 쓰는 숫자 덩어리. 가중치·그래디언트·손실 값이 모두 여기에 해당한다.
• 그래디언트 : 손실을 줄이려면 가중치를 어느 방향으로 얼마나 바꿔야 하는지 알려주는 값.
• 그래디언트 소실 : 그래디언트가 0에 가까워져 가중치가 사실상 갱신되지 않는 상태. 학습이 멈춘 것처럼 보인다.
• 그래디언트 폭발 : 반대로 값이 너무 커져 학습이 발산하는 상태. 손실이 NaN이 되기도 한다.
• 내장 규칙(built-in rule) : SageMaker가 미리 만들어 둔 이상 감지 조건. 이름만 지정하면 바로 쓸 수 있다.
• 액션(action) : 규칙이 위반됐을 때 실행할 조치. StopTraining(학습 중단), 이메일 알림 등.
• 프로파일링 : 프로그램이 시간을 어디에 쓰는지 측정하는 일. 여기서는 GPU·CPU·I/O가 각각 얼마나 바쁜지를 본다.
• GPU 활용률 : GPU가 실제로 계산하고 있던 시간의 비율. 낮으면 대개 데이터를 기다리고 있다는 뜻이다.
• 프리페치(prefetch) : 다음에 쓸 데이터를 미리 준비해 두어, GPU가 계산하는 동안 로딩이 함께 진행되게 하는 기법.
• metric_definitions : 학습 로그에서 정규식으로 숫자를 뽑아 CloudWatch 지표로 올리는 설정.