- 프로젝트에 포함된 run의 수
- 각 run의 step 수
- 로깅하는 고유 메트릭의 수
wandb.Run.log()를 호출하는 빈도- 로깅 Call 한 번에 전송하는 데이터의 양
- 워크스페이스 설정 방식
주요 용어
이 페이지에서는 다음 용어를 사용합니다.Step
step은 run에서 메트릭으로 구성된 하나의 논리적 행입니다. step은commit=True로 wandb.Run.log()를 호출하면 확정되며, commit과 step을 모두 지정하지 않은 경우에는 암묵적으로 확정됩니다.
메트릭 카디널리티
메트릭 카디널리티는 프로젝트에 로깅된 고유 메트릭 키의 수로, 중첩된 딕셔너리의 키도 포함합니다. 예를 들어, 다음 코드는a, b.c, b.d.e, b.d.f의 4개 고유 메트릭 키를 로깅합니다.
로깅된 포인트
로깅된 포인트는 기록된 메트릭 값의 총 개수입니다. 예를 들어, 다음 두 코드 샘플은 모두 로깅된 포인트를 3개 생성합니다.로그 빈도
로그 빈도는 분당wandb.Run.log() Call 횟수입니다.
처리량
**처리량(Throughput)**은 분당 기록되는 로깅된 포인트의 총개수입니다. 처리량은 다음과 같이 이해할 수 있습니다.대규모 사용 시 권장 사항
다음 표는 대규모 로깅 시 권장되는 운영 범위를 요약한 것입니다.이 값은 대규모 환경에서 원활한 성능을 유지하기 위한 가이드라인입니다. 권장 범위를 초과하는 데이터도 W&B에서 계속 수신될 수 있지만, 페이지 로딩과 사용 속도가 느려질 수 있습니다.
처리량 예시
로깅 패턴이 달라도 처리량은 같을 수 있습니다.스칼라 로깅 예시
비디오 로깅 예시
로깅 시 고려 사항
실험 메트릭을 추적하려면wandb.Run.log()를 사용하세요.
메트릭 카디널리티
프로젝트의 전체 메트릭 카디널리티(고유 메트릭 수)를 워크로드에 맞는 권장 범위 내로 유지하세요. 메트릭 카디널리티가 높으면 워크스페이스가 느려지는 경우가 많으며, 이는 가장 흔한 원인 중 하나입니다. W&B는 중첩된 키를 점으로 구분된 메트릭 이름으로 평탄화하므로 메트릭 카디널리티가 예상보다 크게 늘어날 수 있습니다. 예를 들어 다음 코드는a, b.c, b.d라는 3개의 고유 메트릭 키를 로깅합니다.
값 크기
로깅하는 값 하나의 크기는 1MB 미만으로,wandb.Run.log() 호출 한 번의 전체 크기는 25MB 미만으로 유지하세요.
wandb.Image, wandb.Audio 같은 wandb.Media 유형은 처리 방식이 다르므로 이 권장 사항이 적용되지 않습니다.
W&B는 이러한 권장 사항을 초과하여 로깅된 데이터도 저장하지만, 페이지 로딩 속도가 느려질 수 있습니다.
로그 빈도 및 처리량
수집하는 데이터의 가치에 맞게 로깅 빈도를 선택하세요. 너무 자주 로깅하면 SDK 오버헤드가 늘어나 앱이 느려질 수 있으며, 메트릭 카디널리티가 높거나 페이로드가 클 때는 특히 그렇습니다. 처음에는 다음 가이드라인 범위 내에서 로깅하는 것이 좋습니다.- 로그 빈도: 분당
wandb.Run.log()Call 1,000회 미만 - 처리량: 분당 로깅된 값 100,000개 미만
- 비디오 처리량: 분당 40MB 미만
설정 크기
run 설정의 전체 크기는 10 MB 미만으로 유지하세요. 설정이 크면 프로젝트 워크스페이스와 Runs table의 오퍼레이션이 느려질 수 있습니다.워크스페이스 성능
워크스페이스 성능은 기반이 되는 프로젝트 데이터와 워크스페이스 설정의 영향을 모두 받습니다.프로젝트당 run 수
대규모 프로젝트에서 최상의 성능을 얻으려면 프로젝트의 run 수를 10,000개 미만으로 유지하세요. 팀에서 일부 run만 주로 사용한다면 오래되었거나 자주 사용하지 않는 run을 별도의 보관용 프로젝트로 옮기는 것이 좋습니다. 자세한 내용은 run 관리를 참조하세요.패널 수
자동 모드의 워크스페이스는 기본적으로 로깅된 키마다 표준 패널을 생성합니다. 대규모 프로젝트에서는 이 때문에 패널이 지나치게 많아져 워크스페이스가 느려질 수 있습니다. 성능을 향상하려면 다음과 같이 하세요.- 워크스페이스를 수동 모드로 재설정하세요.
- Quick add를 사용하여 필요한 패널만 추가하세요.
사용하지 않는 패널을 하나씩 삭제해도 대개 효과가 거의 없습니다. 워크스페이스를 재설정한 후 원하는 패널만 다시 추가하세요.
섹션 수
워크스페이스에 섹션이 수백 개 있으면 성능이 저하될 수 있습니다. 메트릭마다 섹션을 하나씩 만들기보다는 상위 수준의 메트릭 그룹별로 섹션을 만드세요. 섹션이 너무 많다면 접미사가 아닌 접두사를 기준으로 섹션을 만들어 보세요. 그러면 관련 메트릭을 더 적은 수의 섹션으로 묶을 수 있습니다.
run당 메트릭이 많은 경우
run마다 수천 개의 메트릭을 로깅하는 경우에는 수동 워크스페이스를 사용하여 시각화할 메트릭을 직접 선택하세요. 필요한 패널만 표시하면 로드 속도가 빨라집니다. 플롯하지 않은 메트릭도 계속 수집되고 저장됩니다. 워크스페이스를 수동 모드로 재설정하려면 워크스페이스의 액션() 메뉴를 클릭한 다음 Reset workspace를 클릭하세요. 워크스페이스를 재설정해도 run에 저장된 메트릭에는 영향을 주지 않습니다. 자세한 내용은 워크스페이스 패널 관리를 참조하세요.파일 수
run 하나에 업로드하는 파일 수는 1,000개 미만으로 유지하세요. 파일을 대량으로 로깅해야 한다면 W&B Artifacts를 사용하세요. run 하나에 파일이 1,000개를 넘으면 run 페이지가 느려질 수 있습니다.Reports와 워크스페이스
리포트는 소통과 공유를 위한 기능입니다. 워크스페이스는 많은 run과 메트릭을 한곳에서 심층적으로 살펴보는 대화형 분석을 위한 기능입니다. 많은 run을 비교하거나 여러 플롯을 한 번에 확인해야 할 때는 워크스페이스를 사용하세요. 엄선한 결과를 발표하려면 리포트를 사용하세요.Python 스크립트 성능
로깅은 트레이닝 스크립트에 오버헤드를 발생시킬 수 있습니다. 주요 원인은 다음과 같습니다.- 큰 페이로드
- 네트워크 속도 및 백엔드 설정
- 지나치게 빈번한
wandb.Run.log()Call
wandb.Run.log()를 너무 자주 호출하면 호출할 때마다 트레이닝 루프에 약간의 지연 시간이 더해질 수 있습니다. 여러 메트릭을 한데 묶어 로깅 Call 횟수를 줄이면 일반적으로 성능이 향상됩니다.
잦은 로깅 때문에 트레이닝 run이 느려지나요? 로깅 패턴을 조정해 성능을 높이는 방법은 이 Colab을 참조하세요.
요청 속도 제한
W&B Multi-tenant Cloud API는 서비스 안정성과 가용성을 유지하기 위해 요청 속도 제한을 적용합니다.요청 속도 제한은 변경될 수 있습니다.
429 Rate limit exceeded를 반환하고 응답에 요청 속도 제한 헤더를 포함합니다.
속도 제한 HTTP 헤더
메트릭 로깅 API 요청 속도 제한
wandb.Run.log()는 트레이닝 데이터를 W&B로 전송합니다. 온라인으로 직접 전송하거나, 나중에 오프라인 동기화를 통해 전송할 수 있습니다.
메트릭 로깅의 요청 속도 제한은 프로젝트 단위로 적용되며, 롤링 시간 윈도우 내의 요청 속도와 총 요청 크기를 모두 기준으로 합니다. 유료 플랜은 무료 플랜보다 제한이 더 높습니다.
요청 속도 제한을 초과하면 W&B SDK가 백오프를 적용해 요청을 자동으로 재시도합니다. 이로 인해 요청 속도 제한 윈도우가 재설정될 때까지 run.finish()가 지연될 수도 있습니다.
요청 속도 제한에 걸릴 가능성을 줄이려면 다음을 참고하세요.
- 최신 버전의 W&B SDK를 사용하세요.
- 로깅 빈도를 줄이세요.
- 관련 메트릭을 배치로 묶어 로깅 Call 횟수를 줄이세요.
- 필요한 경우 오프라인 로깅을 사용하고 나중에 동기화하세요.
wandb sync <run-file-path>를 사용하세요. 자세한 내용은 wandb sync를 참조하세요.
GraphQL API 요청 속도 제한
W&B 앱과 public API는 GraphQL 요청을 사용하여 데이터를 쿼리하고 수정합니다. Multi-tenant Cloud의 경우 다음과 같이 적용됩니다.- 인증되지 않은 요청은 IP 주소별로 요청 속도가 제한됩니다.
- 인증된 요청은 사용자별로 요청 속도가 제한됩니다.
- 프로젝트 경로를 지정하는 일부 SDK 요청은 데이터베이스 쿼리 시간에 따라 프로젝트별로도 제한될 수 있습니다.
429 Rate limit exceeded 응답을 받거나 RateLimit-Remaining=0이 표시되면 RateLimit-Reset에 표시된 시간(초)만큼 기다린 후 다시 시도하세요.
느린 프로젝트 문제 해결
프로젝트나 워크스페이스가 느리다면 먼저 다음 사항을 확인하세요.- 최근 run에서 새로운 메트릭 이름이 대량으로 추가되지 않았나요?
- 너무 자주 로깅하고 있지 않나요?
- 개별
run.log()Call의 크기가 지나치게 크지 않나요? - 워크스페이스가 자동 모드로 설정되어 있고 패널이나 섹션이 너무 많지 않나요?
- 프로젝트에 팀이 실제로 사용하는 것보다 많은 run이 포함되어 있지 않나요?
브라우저 고려 사항
W&B 앱은 메모리를 많이 사용할 수 있으며 Chrome에서 가장 원활하게 작동합니다. 컴퓨터의 메모리 용량에 따라 W&B를 3개 이상의 탭에서 동시에 열어 두면 성능이 저하될 수 있습니다. 예상보다 속도가 느리다면 다른 탭이나 애플리케이션을 닫아 보세요.W&B에 성능 문제 보고하기
W&B는 성능을 매우 중요하게 생각하며, 접수된 지연 문제는 모두 조사합니다. 로딩 속도가 느린 문제를 보고할 때는 주요 메트릭과 성능 이벤트를 캡처하는 W&B 기본 제공 성능 로거를 사용하면 더 빠르게 조사할 수 있습니다. 느리게 로드되는 페이지의 URL에 매개변수&PERF_LOGGING을 추가한 다음, 콘솔 출력을 담당 계정 팀이나 지원팀에 공유하세요.
