분산 트레이닝 실험 로깅

W&B를 사용하여 여러 GPU로 분산 트레이닝 실험을 로깅합니다.

분산 트레이닝 실험에서는 여러 머신 또는 클라이언트를 병렬로 사용해 모델을 트레이닝합니다. W&B를 사용하면 분산 트레이닝 실험을 추적할 수 있습니다. 사용 사례에 따라 다음 접근 방식 중 하나로 분산 트레이닝 실험을 추적합니다:

• 단일 프로세스 추적: W&B로 rank 0 프로세스(“리더” 또는 “코디네이터”라고도 함)를 추적합니다. 이는 PyTorch Distributed Data Parallel (DDP) 클래스와 함께 분산 트레이닝 실험을 로깅할 때 일반적으로 사용하는 방법입니다.
• 다중 프로세스 추적: 여러 프로세스가 있는 경우 다음 중 하나를 사용할 수 있습니다:
  • 프로세스당 하나의 run을 사용해 각 프로세스를 개별적으로 추적합니다. 선택적으로 W&B App UI에서 이들을 함께 그룹화할 수 있습니다.
  • 모든 프로세스를 단일 run에 추적합니다.

동시 연결

각 동시 연결은 컴퓨트, 메모리, 네트워크 리소스를 사용합니다. 메트릭을 정기적으로 로깅하지 않는 클라이언트 연결도 시스템 메트릭 업데이트를 전송하므로, 차트를 불러올 때 성능이 저하될 수 있습니다.

W&B는 워크로드에 맞게 최대 동시 클라이언트 연결 수를 제한하고, 시간이 지나면서 리소스 사용량을 모니터링할 것을 권장합니다. W&B는 Dedicated Cloud 환경에서 동시 클라이언트 연결 300개라는 하드 제한으로 테스트를 완료했습니다.

Multi-tenant Cloud 조직에서는 분산 트레이닝을 위한 클라이언트 연결도 일반 트레이닝 runs와 동일한 rate limits이 적용됩니다. Teams 및 Enterprise 요금제를 사용하는 사용자는 Free 요금제 사용자보다 더 높은 rate limits를 받을 수 있습니다.

​

단일 프로세스 추적

이 섹션에서는 rank 0 프로세스에서 사용할 수 있는 값과 메트릭을 추적하는 방법을 설명합니다. 이 방법은 단일 프로세스에서만 확인할 수 있는 메트릭을 추적할 때 사용하세요. 일반적인 메트릭에는 GPU/CPU 사용량, 공유 검증 세트에서의 동작, 그래디언트와 파라미터, 대표적인 데이터 예시에 대한 손실 값 등이 포함됩니다.

rank 0 프로세스 내에서 wandb.init()으로 W&B run을 초기화하고, 해당 run에 실험을 (wandb.log) 로깅합니다.

다음 샘플 Python 스크립트 (log-ddp.py)는 단일 머신에서 두 개의 GPU에 대한 메트릭을 PyTorch DDP를 사용해 추적하는 한 가지 방법을 보여줍니다. PyTorch DDP (torch.nn의 DistributedDataParallel)는 분산 트레이닝을 위한 널리 사용되는 라이브러리입니다. 기본 원리는 어떤 분산 트레이닝 설정에도 적용되지만, 구현 방식은 다를 수 있습니다.

이 Python 스크립트는 다음을 수행합니다.

1. torch.distributed.launch로 여러 프로세스를 시작합니다.
2. --local_rank 커맨드라인 인수를 사용해 rank를 확인합니다.
3. rank가 0으로 설정된 경우, train() 함수에서 조건부로 wandb 로깅을 설정합니다.

if __name__ == "__main__":
    # 인수 가져오기
    args = parse_args()

    if args.local_rank == 0:  # 메인 프로세스에서만 실행
        # wandb run 초기화
        run = wandb.init(
            entity=args.entity,
            project=args.project,
        )
        # DDP로 모델 학습
        train(args, run)
    else:
        train(args)

단일 프로세스에서 추적된 메트릭을 보여주는 예시 대시보드를 살펴보세요.

이 대시보드는 두 GPU 모두에 대한 시스템 메트릭(온도, 사용률 등)을 표시합니다.

그러나 에포크와 배치 크기의 함수로서의 손실 값은 단일 GPU에서만 로깅되었습니다.

​

여러 프로세스 추적

W&B에서 다음 방법 중 하나를 사용하여 여러 프로세스를 추적할 수 있습니다:

• 각 프로세스에 대해 run을 생성해서 각 프로세스를 개별적으로 추적하기
• 모든 프로세스를 단일 run으로 추적하기

​

각 프로세스를 개별적으로 추적하기

이 섹션에서는 각 프로세스마다 별도의 run을 생성하여 개별적으로 추적하는 방법을 설명합니다. 각 run에서 해당 run에 대한 메트릭, 아티팩트 등을 기록합니다. 트레이닝이 끝날 때 wandb.Run.finish()를 호출해 run이 완료되었음을 표시하면, 모든 프로세스가 올바르게 종료됩니다.

여러 Experiments에 걸쳐 run들을 추적하기가 어려울 수 있습니다. 이 문제를 줄이려면, W&B를 초기화할 때 (wandb.init(group='group-name')) group 파라미터에 값을 지정하여 각 run이 어떤 실험에 속하는지 추적하세요. Experiments에서 트레이닝과 평가 W&B Runs를 추적하는 방법에 대한 자세한 내용은 Group Runs를 참고하세요.

각 개별 프로세스의 메트릭을 추적하려는 경우 이 접근 방식을 사용하세요. 일반적인 예로는 각 노드의 데이터와 예측(데이터 분산 디버깅용)과 메인 노드 외부의 개별 배치에 대한 메트릭이 있습니다. 이 접근 방식은 모든 노드의 시스템 메트릭을 수집하거나 메인 노드에서 확인할 수 있는 요약 통계를 얻기 위해서는 필요하지 않습니다.

다음 Python 코드 스니펫은 W&B를 초기화할 때 group 파라미터를 설정하는 방법을 보여줍니다:

if __name__ == "__main__":
    # 인수 가져오기
    args = parse_args()
    # run 초기화
    run = wandb.init(
        entity=args.entity,
        project=args.project,
        group="DDP",  # 실험의 모든 run을 하나의 그룹으로
    )
    # DDP로 모델 학습
    train(args, run)

    run.finish()  # run 완료 표시

여러 프로세스에서 기록된 메트릭을 확인하려면 W&B App UI에서 예시 대시보드를 살펴보세요. 왼쪽 사이드바에 두 개의 W&B Runs가 그룹으로 묶여 있는 것을 볼 수 있습니다. 그룹을 클릭하면 해당 실험에 대한 전용 그룹 페이지로 이동합니다. 전용 그룹 페이지에는 각 프로세스에서 생성된 메트릭이 개별적으로 표시됩니다.

위 이미지는 W&B App UI의 대시보드를 보여줍니다. 사이드바에는 두 개의 실험이 보입니다. 하나는 ‘null’이라는 레이블이 붙어 있고, 다른 하나는 (노란색 박스로 표시된) ‘DPP’입니다. 그룹을 펼치면(Group 드롭다운을 선택하면) 해당 실험과 연결된 W&B Runs를 확인할 수 있습니다.

​

분산 run 구성하기

노드를 역할별로 분류하려면 W&B를 초기화할 때 job_type 파라미터를 설정하세요 (wandb.init(job_type='type-name')). 예를 들어, 메인 조정 노드와 여러 개의 결과를 보고하는 워커 노드가 있을 수 있습니다. 메인 조정 노드에는 job_type을 main으로, 결과를 보고하는 워커 노드에는 worker로 설정할 수 있습니다:

   # 메인 조정 노드
   with wandb.init(project="<project>", job_type="main", group="experiment_1") as run:
        # 트레이닝 코드

   # 리포팅 워커 노드
   with wandb.init(project="<project>", job_type="worker", group="experiment_1") as run:
        # 트레이닝 코드

노드에 job_type을 설정한 후에는 워크스페이스에서 saved views를 만들어 run을 정리할 수 있습니다. 오른쪽 상단의 … 액션 메뉴를 클릭한 다음 Save as new view를 클릭합니다.

예를 들어, 다음과 같은 saved view를 만들 수 있습니다:

• Default view: 워커 노드를 필터링해 노이즈 줄이기

  • Filter를 클릭한 다음 Job Type을 worker로 설정합니다.
  • 리포팅 노드만 표시합니다

• Debug view: 트러블슈팅을 위해 워커 노드에 집중

  • Filter를 클릭한 다음 Job Type을 == worker로 설정하고 State를 IN crashed로 설정합니다.
  • 크래시됐거나 오류 상태인 워커 노드만 표시합니다

• All nodes view: 모든 것을 한눈에 보기

  • 필터 없음
  • 전체 모니터링에 유용합니다

saved view를 열려면 프로젝트 사이드바에서 Workspaces를 클릭한 다음 메뉴를 클릭합니다. Workspaces는 목록 상단에, saved view는 하단에 표시됩니다.

​

여러 프로세스를 하나의 run으로 추적하기

x_로 시작하는 파라미터(예: x_label)는 퍼블릭 프리뷰 단계입니다. 피드백을 제공하려면 W&B 저장소에 GitHub 이슈를 생성하세요.

요구 사항

여러 프로세스를 하나의 run으로 추적하려면 다음이 필요합니다.

• W&B Python SDK 버전 v0.19.9 이상

• W&B Server v0.68 이상

이 방법에서는 기본 노드(primary node)와 하나 이상의 워커 노드(worker node)를 사용합니다. 기본 노드에서 W&B run을 초기화합니다. 각 워커 노드에서는 기본 노드에서 사용한 run ID를 사용해 run을 초기화합니다. 트레이닝 중에는 각 워커 노드가 기본 노드와 동일한 run ID로 로그를 남깁니다. W&B는 모든 노드에서 수집된 메트릭을 집계하여 W&B App UI에 표시합니다.

기본 노드에서 wandb.init()를 사용해 W&B run을 초기화합니다. settings 파라미터에 wandb.Settings 객체를 전달합니다(wandb.init(settings=wandb.Settings()))와 함께 다음을 설정합니다.

1. 공유 모드를 활성화하기 위해 mode 파라미터를 "shared"로 설정합니다.
2. x_label에 고유한 레이블을 지정합니다. x_label에 지정한 값은 W&B App UI의 로그 및 시스템 메트릭에서 데이터가 어떤 노드에서 왔는지 식별하는 데 사용됩니다. 지정하지 않으면 W&B가 호스트 이름과 무작위 해시를 사용해 레이블을 생성합니다.
3. 이 노드가 기본 노드임을 나타내기 위해 x_primary 파라미터를 True로 설정합니다.
4. 선택적으로 x_stats_gpu_device_ids에 GPU 인덱스 목록([0,1,2])을 제공하여 W&B가 어떤 GPU에 대해 메트릭을 추적할지 지정합니다. 목록을 제공하지 않으면 W&B는 머신의 모든 GPU에 대해 메트릭을 추적합니다.

기본 노드의 run ID를 기록해 두세요. 각 워커 노드에는 기본 노드의 run ID가 필요합니다.

x_primary=True는 기본 노드와 워커 노드를 구분합니다. 기본 노드만이 설정 파일, 텔레메트리 등 노드 간에 공유되는 파일을 업로드합니다. 워커 노드는 이러한 파일을 업로드하지 않습니다.

각 워커 노드에서는 wandb.init()를 사용해 W&B run을 초기화하고 다음을 제공합니다.

1. settings 파라미터에 wandb.Settings 객체를 전달합니다(wandb.init(settings=wandb.Settings()))와 함께:
   • 공유 모드를 활성화하기 위해 mode 파라미터를 "shared"로 설정합니다.
   • x_label에 고유한 레이블을 지정합니다. x_label에 지정한 값은 W&B App UI의 로그 및 시스템 메트릭에서 데이터가 어떤 노드에서 왔는지 식별하는 데 사용됩니다. 지정하지 않으면 W&B가 호스트 이름과 무작위 해시를 사용해 레이블을 생성합니다.
   • 이 노드가 워커 노드임을 나타내기 위해 x_primary 파라미터를 False로 설정합니다.
2. id 파라미터에 기본 노드에서 사용한 run ID를 전달합니다.
3. 선택적으로 x_update_finish_state를 False로 설정합니다. 이렇게 하면 기본 노드가 아닌 노드가 run의 상태를 조기에 finished로 업데이트하는 것을 방지하여, run 상태가 기본 노드에 의해 일관되게 관리되도록 합니다.

• 모든 노드에서 동일한 entity와 프로젝트를 사용하세요. 이렇게 하면 올바른 run ID를 찾는 데 도움이 됩니다.
• 각 워커 노드에서 환경 변수를 정의해 기본 노드의 run ID를 설정하는 것을 고려하세요.

아래 예제 코드는 여러 프로세스를 하나의 run으로 추적하기 위한 고수준 요구 사항을 보여줍니다:

import wandb

entity = "<team_entity>"
project = "<project_name>"

# 기본 노드에서 run 초기화
run = wandb.init(
    entity=entity,
    project=project,
	settings=wandb.Settings(
        x_label="rank_0", 
        mode="shared", 
        x_primary=True,
        x_stats_gpu_device_ids=[0, 1],  # (선택 사항) GPU 0 및 1의 메트릭만 추적
        )
)

# 기본 노드의 run ID를 기록해 두세요.
# 각 워커 노드에는 이 run ID가 필요합니다.
run_id = run.id

# 기본 노드의 run ID를 사용하여 워커 노드에서 run 초기화
run = wandb.init(
    entity=entity, # 기본 노드와 동일한 entity 사용
    project=project, # 기본 노드와 동일한 프로젝트 사용
	settings=wandb.Settings(x_label="rank_1", mode="shared", x_primary=False),
	id=run_id,
)

# 기본 노드의 run ID를 사용하여 워커 노드에서 run 초기화
run = wandb.init(
    entity=entity, # 기본 노드와 동일한 entity 사용
    project=project, # 기본 노드와 동일한 프로젝트 사용
	settings=wandb.Settings(x_label="rank_2", mode="shared", x_primary=False),
	id=run_id,
)

실제 환경에서는 각 워커 노드가 별도의 머신에 있을 수 있습니다.

GKE의 다중 노드 및 다중 GPU Kubernetes 클러스터에서 모델을 트레이닝하는 방법에 대한 엔드 투 엔드 예시는 Distributed Training with Shared Mode 리포트를 참고하세요.

run이 로그를 기록하는 프로젝트에서 멀티 노드 프로세스의 콘솔 로그를 보려면 다음을 수행하세요:

1. run이 포함된 프로젝트로 이동합니다.
2. 프로젝트 사이드바에서 Runs 탭을 클릭합니다.
3. 확인하려는 run을 클릭합니다.
4. 프로젝트 사이드바에서 Logs 탭을 클릭합니다.

콘솔 로그 페이지 상단에 위치한 UI 검색창에서 x_label에 제공한 레이블을 기준으로 콘솔 로그를 필터링할 수 있습니다. 예를 들어, 아래 이미지는 x_label에 rank0, rank1, rank2, rank3, rank4, rank5, rank6 값을 제공했을 때 콘솔 로그를 필터링할 수 있는 옵션을 보여줍니다.

자세한 내용은 Console logs를 참고하세요.

W&B는 모든 노드의 시스템 메트릭을 집계하여 W&B App UI에 표시합니다. 예를 들어, 아래 이미지는 여러 노드의 시스템 메트릭을 포함하는 예시 대시보드를 보여줍니다. 각 노드는 x_label 파라미터에 지정한 고유한 레이블(rank_0, rank_1, rank_2)을 가집니다.

선형 플롯 패널을 사용자 지정하는 방법은 Line plots를 참고하세요.

​

예제 사용 사례

다음 코드 스니펫은 고급 분산 환경에서의 일반적인 사용 시나리오를 보여줍니다.

​

스폰된 프로세스

스폰된 프로세스에서 run을 시작하는 경우 메인 함수에서 wandb.setup() 메서드를 사용하세요:

import multiprocessing as mp

def do_work(n):
    with wandb.init(config=dict(n=n)) as run:
        run.log(dict(this=n * n))

def main():
    wandb.setup()
    pool = mp.Pool(processes=4)
    pool.map(do_work, range(4))


if __name__ == "__main__":
    main()

​

run 공유하기

프로세스 간에 run을 공유하려면 run 객체를 인자로 전달합니다.

def do_work(run):
    with wandb.init() as run:
        run.log(dict(this=1))

def main():
    run = wandb.init()
    p = mp.Process(target=do_work, kwargs=dict(run=run))
    p.start()
    p.join()
    run.finish()  # run 완료 표시


if __name__ == "__main__":
    main()

W&B는 로깅 순서를 보장하지 않습니다. 동기화는 스크립트 작성자가 직접 처리해야 합니다.

​

문제 해결

W&B와 분산 트레이닝을 함께 사용할 때 다음 두 가지 문제가 자주 발생할 수 있습니다.

1. 트레이닝 시작 시 멈춤 현상 - wandb 멀티프로세싱이 분산 트레이닝에서 사용하는 멀티프로세싱과 충돌하면 wandb 프로세스가 멈출 수 있습니다.
2. 트레이닝 종료 시 멈춤 현상 - wandb 프로세스가 언제 종료해야 하는지 알지 못하면 트레이닝 작업이 멈춘 상태가 될 수 있습니다. Python 스크립트의 마지막에서 wandb.Run.finish() API를 호출하여 W&B에 해당 run이 완료되었음을 알려야 합니다. wandb.Run.finish() API는 데이터 업로드를 완료하고 W&B 프로세스가 종료되도록 합니다.

W&B는 분산 작업의 안정성을 높이기 위해 wandb service 명령 사용을 권장합니다. 앞서 언급한 두 가지 트레이닝 문제는 wandb service를 사용할 수 없는 버전의 W&B SDK에서 흔하게 발생합니다.

​

W&B Service 활성화

사용 중인 W&B SDK 버전에 따라 W&B Service가 이미 기본적으로 활성화되어 있을 수 있습니다.

​

W&B SDK 0.13.0 이상

W&B SDK 0.13.0 이상 버전에서는 기본적으로 W&B Service가 활성화되어 있습니다.

​

W&B SDK 0.12.5 이상

Python 스크립트를 수정하여 W&B SDK 버전 0.12.5 이상에서 W&B Service를 활성화하세요. 메인 함수 내에서 wandb.require 메서드를 사용하고 문자열 "service"를 전달하세요:

if __name__ == "__main__":
    main()


def main():
    wandb.require("service")
    # 나머지-스크립트를-여기에-작성하세요

최적의 사용 환경을 위해 최신 버전으로 업그레이드할 것을 권장합니다.

W&B SDK 0.12.4 및 그 이전 버전

W&B SDK 0.12.4 및 그 이전 버전을 사용하는 경우 멀티스레딩을 사용하려면 WANDB_START_METHOD 환경 변수를 "thread"로 설정하세요.