아래 권장 범위 내에서 로깅을 수행해 W&B 페이지의 속도와 응답성을 높게 유지하세요.
실험 지표를 추적하려면 wandb.Run.log()을 사용하세요.
성능을 더 빠르게 유지하려면 프로젝트에서 사용하는 고유 메트릭의 총 개수를 10,000개 이하로 유지하세요.
import wandb
with wandb.init() as run:
run.log(
{
"a": 1, # "a"는 고유한 메트릭입니다
"b": {
"c": "hello", # "b.c"는 고유한 메트릭입니다
"d": [1, 2, 3], # "b.d"는 고유한 메트릭입니다
},
}
)
W&B는 중첩된 값을 자동으로 평탄화합니다. 즉, 딕셔너리를 전달하면 W&B가 이를 점(.)으로 구분된 이름으로 변환합니다. config 값의 경우 이름에 최대 3개의 점을 지원하고, summary 값의 경우 이름에 최대 4개의 점을 지원합니다.
wandb.Run.log() 호출에서 로깅되는 전체 값의 크기는 25 MB 미만으로 제한하세요. 이 제한은 wandb.Image, wandb.Audio 등과 같은 wandb.Media 타입에는 적용되지 않습니다.
import wandb
with wandb.init(project="wide-values") as run:
# 권장하지 않음
run.log({"wide_key": range(10000000)})
# 권장하지 않음
with open("large_file.json", "r") as f:
large_data = json.load(f)
run.log(large_data)
권장 범위보다 더 넓은 값을 기록하더라도 데이터는 저장되고 추적됩니다. 다만 플롯이 로드되는 속도가 느려질 수 있습니다.
- 스칼라: 메트릭당 <100,000개 로그 포인트
- 미디어: 메트릭당 <50,000개 로그 포인트
- 히스토그램: 메트릭당 <10,000개 로그 포인트
import wandb
with wandb.init(project="metric-frequency") as run:
# 권장하지 않음
run.log(
{
"scalar": 1, # 스칼라 100,000개
"media": wandb.Image(...), # 이미지 100,000개
"histogram": wandb.Histogram(...), # 히스토그램 100,000개
}
)
# 권장
run.log(
{
"scalar": 1, # 스칼라 100,000개
},
commit=True,
) # 배치된 단계별 메트릭을 함께 커밋
run.log(
{
"media": wandb.Image(...), # 이미지 50,000개
},
commit=False,
)
run.log(
{
"histogram": wandb.Histogram(...), # 히스토그램 10,000개
},
commit=False,
)
W&B는 사용자가 로깅한 데이터를 계속 수집하지만, 권장 한도를 초과하면 페이지가 느리게 로드될 수 있습니다.
import wandb
# 권장
with wandb.init(
project="config-size",
config={
"lr": 0.1,
"batch_size": 32,
"epochs": 4,
}
) as run:
# 여기에 학습 코드를 작성하세요
pass
# 권장하지 않음
with wandb.init(
project="config-size",
config={
"large_list": list(range(10000000)), # 대용량 리스트
"large_string": "a" * 10000000, # 대용량 문자열
}
) as run:
# 여기에 학습 코드를 작성하세요
pass
# 권장하지 않음
with open("large_config.json", "r") as f:
large_config = json.load(f)
wandb.init(config=large_config)
- SaaS Cloud: 100,000개
- Dedicated Cloud 또는 Self-Managed: 10,000개
실행 개수가 이 임계값을 초과하면, 특히 실행을 그룹화하거나 실행 중에 매우 많은 수의 서로 다른 메트릭을 수집할 때 Project 워크스페이스나 실행 테이블과 관련된 작업이 느려질 수 있습니다. 메트릭 개수 섹션도 참고하세요.
팀에서 동일한 실행 집합(예: 최근 실행 집합)에 자주 액세스한다면, 자주 사용하지 않는 실행을 대량으로 새 “archive” 프로젝트로 이동하여 작업 중인 프로젝트에는 더 적은 수의 실행만 남겨 두는 것을 고려하세요.
이 섹션은 워크스페이스 성능을 최적화하는 데 도움이 되는 팁을 제공합니다.
기본적으로 워크스페이스는 자동 모드이며, 로그된 각 키에 대해 표준 패널을 생성합니다. 대규모 프로젝트의 워크스페이스에 로그된 키가 많아 그만큼 많은 패널이 생성되면 워크스페이스 로딩 및 사용이 느려질 수 있습니다. 성능을 개선하려면 다음을 수행하십시오:
- 워크스페이스를 수동 모드로 재설정합니다. 이 모드에서는 기본적으로 패널이 포함되지 않습니다.
- Quick add를 사용해, 시각화가 필요한 로그된 키에 대한 패널만 선택적으로 추가합니다.
사용하지 않는 패널을 하나씩 삭제해도 성능에는 거의 영향을 주지 않습니다. 대신 워크스페이스를 재설정한 다음, 필요한 패널만 선택적으로 다시 추가하십시오.
... 메뉴를 클릭한 다음 Reset workspace를 클릭합니다. 워크스페이스를 초기화해도 실행에 대해 저장된 메트릭에는 영향이 없습니다. 워크스페이스 패널 관리를 참조하십시오.
단일 실행에서 업로드하는 파일 총 개수를 1,000개 이하로 유지하십시오. 많은 수의 파일을 기록해야 할 때는 W&B 아티팩트를 사용하십시오. 단일 실행에서 파일 수가 1,000개를 초과하면 실행 페이지가 느려질 수 있습니다.
리포트는 패널, 텍스트, 미디어를 자유롭게 배치해 구성하는 문서로, 동료들과 인사이트를 쉽게 공유할 수 있습니다.
반면 워크스페이스는 수십 개에서 수천 개에 이르는 지표를, 수백 개에서 수십만 개에 이르는 실행 전반에 걸쳐 고밀도로 빠르게 분석할 수 있도록 해줍니다. 워크스페이스는 리포트와 비교했을 때 캐싱, 쿼리, 로딩 기능이 최적화되어 있습니다. 워크스페이스는 발표보다는 분석이 주 목적이거나, 한 번에 20개 이상의 플롯을 함께 보여줘야 하는 프로젝트에 사용하는 것을 권장합니다.
Python 스크립트의 성능이 저하되는 경우는 다음과 같습니다:
- 데이터 크기가 너무 큰 경우. 데이터 크기가 크면 학습 루프에 1 ms 이상의 오버헤드가 추가될 수 있습니다.
- 네트워크 속도와 W&B 백엔드 구성 방식.
wandb.Run.log()를 초당 여러 번 이상 호출하는 경우. wandb.Run.log()가 호출될 때마다 학습 루프에 작은 지연 시간이 추가되기 때문입니다.
잦은 로깅 때문에 학습 실행 속도가 느려지고 있나요? 로깅 전략을 변경해 성능을 개선하는 방법은 이 Colab을 확인하세요. 429 Rate limit exceeded 오류가 발생하며, 응답에는 요청 속도 제한 HTTP 헤더가 포함됩니다.
앞의 표는 요청 제한 HTTP 헤더를 설명합니다:
| 헤더 이름 | 설명 |
|---|
| RateLimit-Limit | 각 시간 윈도우에서 사용 가능한 쿼터를 0~1000 범위로 스케일링한 값 |
| RateLimit-Remaining | 현재 요청 제한 윈도우에서 남아 있는 쿼터를 0~1000 범위로 스케일링한 값 |
| RateLimit-Reset | 현재 쿼터가 초기화될 때까지 남은 시간(초 단위) |
wandb.Run.log()은 학습 데이터를 W&B에 로깅합니다. 이 API는 온라인 모드 또는 오프라인 동기화를 통해 호출됩니다. 두 경우 모두 일정 시간 구간(rolling time window) 내에서 rate limit(쿼터)이 적용됩니다. 여기에는 전체 요청 크기와 요청 빈도에 대한 제한이 포함되며, 여기서 요청 빈도는 일정 시간 동안 전송되는 요청 수를 의미합니다.
W&B는 W&B Project마다 rate limit을 적용합니다. 따라서 하나의 팀에 3개의 프로젝트가 있다면, 각 Project에는 고유한 rate limit 쿼터가 있습니다. 유료 플랜 사용자는 무료 플랜 사용자보다 더 높은 rate limit이 적용됩니다.
rate limit에 도달하면 HTTP 429 Rate limit exceeded 오류가 발생하고, 응답에는 rate limit HTTP 헤더가 포함됩니다.
메트릭 로깅 API rate limit 이하로 유지하기 위한 권장 사항
run.finish() 호출이 지연될 수 있습니다. 이를 방지하려면 다음 전략을 고려하십시오:
- W&B Python SDK 버전 업데이트: 최신 버전의 W&B Python SDK를 사용하고 있는지 확인하십시오. W&B Python SDK는 정기적으로 업데이트되며, 요청을 안정적으로 재시도하고 할당량 사용을 최적화하는 향상된 기능을 포함합니다.
- 메트릭 로깅 주기 감소:
할당량을 절약하기 위해 메트릭을 기록하는 빈도를 최소화하십시오. 예를 들어, 매 에폭마다 메트릭을 기록하는 대신 다섯 에폭마다 메트릭을 기록하도록 코드를 수정할 수 있습니다:
import wandb
import random
with wandb.init(project="basic-intro") as run:
for epoch in range(10):
# 훈련 및 평가 시뮬레이션
accuracy = 1 - 2 ** -epoch - random.random() / epoch
loss = 2 ** -epoch + random.random() / epoch
# 5 에포크마다 메트릭 기록
if epoch % 5 == 0:
run.log({"acc": accuracy, "loss": loss})
- 수동 데이터 동기화: W&B는 요청 속도 제한에 걸리면 실행 데이터를 로컬에 저장합니다.
wandb sync <run-file-path> 명령으로 데이터를 수동으로 동기화할 수 있습니다. 자세한 내용은 wandb sync 참조 문서를 확인하세요.
W&B Models UI와 SDK의 public API는 데이터를 조회하고 수정하기 위해 서버로 GraphQL 요청을 전송합니다. SaaS Cloud 환경에서 발생하는 모든 GraphQL 요청에 대해, W&B는 인증되지 않은 요청에는 IP 주소별로, 인증된 요청에는 사용자별로 요청 제한을 적용합니다. 이 제한은 고정된 시간 창 내에서의 요청 속도(초당 요청 수)에 기반하며, 기본 한도는 사용 중인 요금제에 따라 결정됩니다. 프로젝트 경로(예: 보고서, 실행, 아티팩트)를 지정하는 관련 SDK 요청의 경우, W&B는 데이터베이스 쿼리 시간으로 측정되는 프로젝트별 요청 제한을 적용합니다.
Teams 및 Enterprise 요금제를 사용하는 사용자는 Free 요금제 사용자보다 더 높은 요청 제한을 부여받습니다.
W&B Models SDK의 public API를 사용하는 동안 요청 제한에 도달하면, 표준 출력에 해당 오류를 나타내는 메시지가 표시됩니다.
요청 제한에 도달하면 HTTP 429 Rate limit exceeded 오류를 수신하며, 응답에는 요청 제한 관련 HTTP 헤더가 포함됩니다.
GraphQL API 요청 제한을 초과하지 않기 위한 권장 사항
429 Rate limit exceeded 오류를 받았거나 응답 헤더에서 RateLimit-Remaining=0 값을 확인했다면, 재시도하기 전에 RateLimit-Reset에 지정된 초 수만큼 기다리십시오.
W&B 앱은 메모리 사용량이 많은 편이며 Chrome에서 가장 원활하게 동작합니다. 컴퓨터의 메모리 용량에 따라, W&B를 한 번에 3개 이상의 탭에서 사용하면 성능이 저하될 수 있습니다. 예상보다 성능이 느려진다면 다른 탭이나 애플리케이션을 닫는 것을 고려하세요.
W&B는 성능을 중요하게 여기며, 지연 현상에 대한 모든 보고를 조사합니다. 조사를 신속하게 진행하려면 로딩이 느릴 때 W&B에 내장된 성능 로거를 사용해 핵심 메트릭과 성능 이벤트를 캡처한 후 문제를 보고하는 방법을 고려하세요. 느리게 로드되는 페이지의 URL 끝에 &PERF_LOGGING 매개변수를 추가한 다음, 브라우저 콘솔 출력 내용을 계정 담당자나 지원 팀과 공유하세요.
플랫폼
W&B Models
W&B Weave
W&B Inference
W&B 교육
릴리스 노트
