대규모 로깅과 성능

이 페이지에서는 로깅 패턴이 W&B 성능에 미치는 영향을 설명하고, 대규모 프로젝트에서 실험 추적을 확장하기 위한 지침을 제공합니다.

성능은 일반적으로 다음 요소가 복합적으로 작용해 영향을 받습니다.

• 프로젝트의 run 수
• 각 run의 step 수
• 로깅하는 고유 메트릭 수
• wandb.Run.log()를 호출하는 빈도
• 각 log 호출에서 전송하는 데이터 양
• 워크스페이스 구성 방식

대부분의 경우 성능 문제는 step을 너무 많이 로깅해서보다 고유 메트릭을 너무 많이 로깅해서 발생하는 경우가 더 많습니다.

​

주요 용어

다음 용어는 이 페이지 전반에서 사용됩니다.

​

Steps

step은 run에서 메트릭의 단일 논리적 행을 의미합니다. wandb.Run.log()가 commit=True로 호출되면 step이 확정되며, commit과 step을 둘 다 지정하지 않은 경우에도 암묵적으로 확정됩니다.

import wandb

with wandb.init() as run:
    run.log({"loss": 0.42}, commit=True)

​

메트릭 카디널리티

메트릭 카디널리티는 중첩된 딕셔너리의 키를 포함해, 프로젝트에 로깅된 서로 다른 메트릭 키의 개수입니다.

예를 들어, 다음과 같이 로깅하면 서로 다른 메트릭 키 a, b.c, b.d.e, b.d.f 4개가 생성됩니다.

import wandb

with wandb.init() as run:
    run.log(
        {
            "a": 1,
            "b": {
                "c": 2,
                "d": {
                    "e": 3,
                    "f": 4,
                },
            },
        }
    )

W&B는 중첩된 딕셔너리를 펼쳐 점(.)으로 구분된 메트릭 이름으로 변환합니다.

​

로깅된 포인트

로깅된 포인트는 기록된 메트릭 값의 총 개수입니다.

예를 들어, 다음 두 코드 예시는 모두 로깅된 포인트를 3개 생성합니다:

import wandb

with wandb.init() as run:
    run.log({"a": 1, "b": 2, "c": 3})

import wandb

with wandb.init() as run:
    run.log({"a": 1})
    run.log({"a": 2})
    run.log({"a": 3})

​

로그 빈도

로그 빈도는 분당 wandb.Run.log() Call 횟수입니다.

log frequency = wandb.Run.log() calls per minute

​

처리량

처리량은 분당 기록되는 포인트의 총개수입니다.

처리량은 다음과 같이 생각할 수 있습니다:

throughput = logged points per minute

또는 다음과 같이 쓸 수 있습니다:

throughput = logged points × log frequency

다음 섹션은 W&B SaaS Cloud에 적용됩니다. 다른 W&B 배포 유형을 사용하는 경우, 배포별 지침이나 제한 사항은 관리자에게 문의하세요.

​

대규모 환경에서의 권장 사항

다음 표는 대규모 로깅에 권장되는 운영 범위를 요약한 것입니다.

Dimension	Guidance at scale
프로젝트당 Runs	10,000
run당 step 수	500,000
프로젝트당 메트릭 카디널리티	100,000
로그 빈도	분당 1,000행
처리량	분당 100,000개 값
비디오 처리량	분당 40 MB

이 값은 대규모 환경에서 우수한 성능을 유지하기 위한 가이드라인입니다. W&B는 이러한 권장 범위를 초과하는 데이터도 계속 수용할 수 있지만, 페이지 로드 및 사용 속도가 느려질 수 있습니다.

​

처리량 예시

로깅 방식이 달라도 동일한 처리량이 나올 수 있습니다.

​

스칼라 로깅 예시

로그 호출당 메트릭 수	로그 빈도(분당 호출 수)	처리량(분당 값 수)
100	1,000	100,000
1,000	100	100,000
10,000	10	100,000
20,000	5	100,000

​

비디오 로깅 예시

비디오 크기 (MB)	로그 빈도 (분당)	비디오 처리량 (MB/분)
1	46	46
5	8	40
10	4	40
50	1	50
100	0.3	30
250	0.1	25
500	0.07	35

​

로깅 시 고려 사항

실험 메트릭을 추적하려면 wandb.Run.log()를 사용하세요.

​

메트릭 카디널리티

프로젝트의 전체 메트릭 카디널리티(고유한 메트릭 수)는 워크로드에 권장되는 범위 내로 유지하세요. 메트릭 카디널리티가 높으면 워크스페이스가 느려지는 가장 흔한 원인 중 하나가 됩니다.

성능 문제는 step을 너무 많이 로깅해서가 아니라, 서로 다른 메트릭을 너무 많이 로깅해서 발생하는 경우가 많습니다.

W&B는 중첩된 키를 점으로 구분된 메트릭 이름으로 평탄화하므로, 메트릭 카디널리티가 예상보다 더 많이 증가할 수 있습니다.

예를 들어, 다음은 a, b.c, b.d라는 3개의 고유한 메트릭 키를 로깅합니다.

import wandb

with wandb.init() as run:
    run.log(
        {
            "a": 1,
            "b": {
                "c": "hello",
                "d": [1, 2, 3],
            },
        }
    )

워크스페이스가 갑자기 느려졌다면, 최근 run에서 새로운 metric 키가 대량으로 생성되었는지 확인하세요. 이런 경우에는 run이 한두 개만 표시되는 plot이 많이 나타나는 경우가 많습니다. 의도치 않게 이런 일이 발생했다면, metric 이름 집합을 더 적고 안정적으로 구성해 해당 run을 삭제한 뒤 다시 생성하는 것을 고려해 보세요.

​

값 크기

단일 로깅 값의 크기는 1 MB 미만으로 유지하고, 단일 wandb.Run.log() 호출의 총 크기는 25 MB 미만으로 유지하세요.

이 권장 사항은 wandb.Image 및 wandb.Audio와 같은 wandb.Media 유형에는 적용되지 않습니다. 이러한 유형은 별도로 처리됩니다.

import json
import wandb

with wandb.init(project="wide-values") as run:
    # 권장하지 않음
    run.log({"wide_key": list(range(10000000))})

    # 권장하지 않음
    with open("large_file.json", "r") as f:
        large_data = json.load(f)
        run.log(large_data)

큰 값은 해당 값을 포함한 메트릭뿐 아니라 전체 run의 플롯 로딩 속도도 늦출 수 있습니다.

W&B는 이러한 권장 사항을 초과해 로깅된 데이터도 계속 저장하지만, 페이지가 더 느리게 로드될 수 있습니다.

​

로그 빈도와 처리량

수집하는 데이터의 가치에 맞는 로깅 빈도를 선택하세요. 너무 자주 로깅하면 SDK 오버헤드가 증가하고 앱이 느려질 수 있으며, 특히 메트릭 카디널리티가 높거나 페이로드가 큰 경우 그 영향이 더 커집니다.

시작할 때는 다음 가이드라인을 기준으로 로깅하세요.

• 로그 빈도: 분당 wandb.Run.log() Call 1,000회 미만
• 처리량: 분당 로깅된 값 100,000개 미만
• 비디오 처리량: 분당 40 MB 미만

가능하면 관련 메트릭을 같은 step에 묶어 로깅하세요. 예를 들어, 다음 코드 스니펫은 세 개의 메트릭을 동일한 step에 로깅하므로 각각 따로 로깅하는 것보다 더 효율적입니다.

import wandb

with wandb.init(project="metric-frequency") as run:
    # 권장: 관련 스칼라 메트릭을 함께 묶어서 기록
    run.log(
        {
            "loss": 0.12,
            "accuracy": 0.98,
            "lr": 1e-4,
        },
        commit=True,
    )

​

설정 크기

run 설정의 전체 크기를 10MB 미만으로 유지하세요.

큰 설정은 프로젝트 워크스페이스와 Runs table 오퍼레이션을 느리게 할 수 있습니다.

import json
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)

​

워크스페이스 성능

워크스페이스 성능은 기반이 되는 프로젝트 데이터와 워크스페이스 설정 모두에 따라 달라집니다.

​

프로젝트당 Runs

규모가 큰 프로젝트의 경우 최적의 성능을 위해 프로젝트 내 Runs 수를 10,000개 미만으로 유지하세요.

팀에서 정기적으로 Runs의 일부만 사용하는 경우, 오래되었거나 사용 빈도가 낮은 Runs를 별도의 아카이브 프로젝트로 옮기는 것을 고려하세요. Runs 관리를 참조하세요.

​

패널 수

기본적으로 자동 모드의 워크스페이스는 로깅된 각 키에 대해 표준 패널을 생성합니다. 규모가 큰 Projects에서는 이로 인해 패널이 지나치게 많이 생성되어 워크스페이스가 느려질 수 있습니다.

성능을 개선하려면:

1. 워크스페이스를 수동 모드로 재설정하세요.
2. Quick add를 사용해 필요한 패널만 추가하세요.

사용하지 않는 패널을 하나씩 삭제해도 대개 효과가 거의 없습니다. 워크스페이스를 재설정한 후 원하는 패널만 다시 추가하세요.

자세한 내용은 Panels를 참조하세요.

​

섹션 수

워크스페이스에 섹션이 수백 개 있으면 성능이 저하될 수 있습니다.

메트릭마다 섹션을 하나씩 만드는 대신, 메트릭을 상위 수준으로 그룹화해 섹션을 만드세요. 섹션이 너무 많다면, 관련 메트릭이 더 적은 수의 섹션으로 그룹화되도록 접미사 대신 접두사를 기준으로 섹션을 만드는 것을 고려하세요.

​

run당 많은 메트릭

run당 수천 개의 메트릭을 로깅하는 경우, 시각화할 메트릭을 선택할 수 있도록 수동 워크스페이스를 사용하세요.

더 집중된 플롯 집합을 사용하면 워크스페이스가 더 빠르게 로드됩니다. 플롯되지 않은 메트릭도 평소와 같이 계속 수집되고 저장됩니다.

워크스페이스를 수동 모드로 재설정하려면, 워크스페이스의 작업 () 메뉴를 클릭한 다음 워크스페이스 재설정을 클릭합니다. 워크스페이스를 재설정해도 run에 저장된 메트릭에는 영향을 주지 않습니다. 워크스페이스 패널 관리를 참조하세요.

​

파일 수

단일 run에 업로드하는 파일 수는 1,000개 미만으로 유지하세요.

많은 파일을 log해야 하는 경우에는 대신 W&B Artifacts를 사용하세요. 단일 run에서 파일 수가 1,000개를 초과하면 run 페이지가 느려질 수 있습니다.

​

Reports 및 워크스페이스

Report는 커뮤니케이션과 프레젠테이션용으로 설계되었습니다. 워크스페이스는 많은 Runs와 메트릭 전반에 걸쳐 밀도 높은 대화형 분석을 수행하도록 설계되었습니다.

많은 수의 Runs를 비교하거나 여러 plot을 함께 봐야 할 때는 워크스페이스를 사용하세요. 선별한 결과를 제시하려는 경우에는 Report를 사용하세요.

​

Python 스크립트 성능

로깅은 트레이닝 스크립트에 오버헤드를 유발할 수 있습니다. 주요 원인은 다음과 같습니다.

1. 큰 페이로드
2. 네트워크 속도 및 백엔드 설정
3. wandb.Run.log()를 매우 자주 호출하는 경우

wandb.Run.log()를 너무 자주 호출하면 호출할 때마다 트레이닝 루프에 약간의 지연이 추가될 수 있습니다. 여러 메트릭을 더 적은 횟수의 log 호출로 묶으면 일반적으로 성능이 개선됩니다.

잦은 로깅 때문에 트레이닝 run이 느려지고 있나요? 로깅 패턴을 조정해 성능을 개선하는 전략은 이 Colab에서 확인하세요.

W&B는 API 요청 속도 제한 외에는 이러한 권장 사항에 대해 엄격한 제품 제한을 강제 적용하지 않습니다. 이 페이지의 가이드를 초과하더라도 W&B가 데이터를 계속 수집할 수는 있지만, 앱 또는 SDK가 느려질 수 있습니다.

​

요청 속도 제한

W&B SaaS Cloud API는 서비스 안정성과 가용성을 유지하기 위해 요청 속도 제한을 적용합니다.

요청 속도 제한은 변경될 수 있습니다.

요청 속도 제한에 걸리면 서버는 HTTP 429 Rate limit exceeded를 반환하며, 응답에는 요청 속도 제한 헤더가 포함됩니다.

​

요청 속도 제한 HTTP 헤더

Header name	설명
RateLimit-Limit	현재 시간 창에서 사용 가능한 할당량으로, 0~1000 범위로 조정됩니다
RateLimit-Remaining	현재 창에서 남아 있는 할당량으로, 0~1000 범위로 조정됩니다
RateLimit-Reset	현재 할당량이 재설정될 때까지 남은 초 수

​

메트릭 로깅 API 요청 속도 제한

wandb.Run.log()는 트레이닝 데이터를 W&B로 전송합니다. 온라인에서 직접 전송하거나 나중에 오프라인 동기화를 통해 전송할 수 있습니다.

메트릭 로깅에 대한 요청 속도 제한은 프로젝트 수준에서 적용되며, 일정 시간 동안의 요청 속도와 총 요청 크기를 모두 기준으로 합니다. 유료 플랜은 무료 플랜보다 한도가 더 높습니다.

요청 속도 제한을 초과하면 W&B SDK가 자동으로 백오프를 적용해 요청을 재시도합니다. 경우에 따라 요청 속도 제한 기간이 재설정될 때까지 run.finish()가 지연될 수 있습니다.

요청 속도 제한에 걸릴 가능성을 줄이려면 다음을 수행하세요.

• 최신 W&B SDK 버전을 사용하세요.
• 로깅 빈도를 줄이세요.
• 관련 메트릭을 묶어 log 호출 횟수를 줄이세요.
• 적절한 경우 오프라인 로깅을 사용하고 나중에 동기화하세요.

import random
import wandb

with wandb.init(project="basic-intro") as run:
    for epoch in range(10):
        accuracy = 1 - 2 ** -epoch - random.random() / (epoch + 1)
        loss = 2 ** -epoch + random.random() / (epoch + 1)

        if epoch % 5 == 0:
            run.log({"acc": accuracy, "loss": loss})

수동으로 동기화하려면 wandb sync <run-file-path> 명령을 사용하세요. wandb sync를 참조하세요.

​

GraphQL API 요청 속도 제한

W&B App과 public API는 GraphQL 요청을 사용해 데이터를 쿼리하고 수정합니다.

SaaS Cloud의 경우:

• 인증되지 않은 요청에는 IP 주소별로 요청 속도 제한이 적용됩니다
• 인증된 요청에는 사용자별로 요청 속도 제한이 적용됩니다
• 프로젝트 경로를 지정하는 일부 SDK 요청에는 데이터베이스 쿼리 시간을 기준으로 프로젝트별 제한이 추가로 적용될 수도 있습니다

Teams 및 Enterprise 플랜은 Free 플랜보다 한도가 더 높습니다.

public API 요청을 대량으로 보내는 경우, 가능하면 요청 사이에 최소 1초 이상 기다리세요. HTTP 429 Rate limit exceeded를 받거나 RateLimit-Remaining=0이 표시되면, 다시 시도하기 전에 RateLimit-Reset에 지정된 초 수만큼 기다리세요.

​

느린 프로젝트 문제 해결

프로젝트 또는 워크스페이스가 느리다고 느껴진다면, 먼저 다음 사항을 확인하세요.

1. 최근 run에서 새로운 메트릭 이름이 대량으로 추가되었나요?
2. 로그를 너무 자주 남기고 있나요?
3. 개별 run.log() Call의 크기가 매우 큰가요?
4. 워크스페이스가 자동 모드이고 패널이나 섹션이 너무 많나요?
5. 프로젝트에 팀이 실제로 활발히 사용하는 것보다 더 많은 run이 포함되어 있나요?

대부분의 경우 메트릭 카디널리티를 줄이고, log Call을 배치로 처리하고, 큰 워크스페이스를 수동 모드로 전환하면 성능이 향상됩니다.

​

브라우저 관련 참고 사항

W&B 앱은 메모리를 많이 사용할 수 있으며 Chrome에서 가장 원활하게 작동합니다. 컴퓨터의 메모리 용량에 따라 W&B를 탭 3개 이상에서 동시에 열어 두면 성능이 저하될 수 있습니다. 예상보다 느리게 작동한다면 다른 탭이나 애플리케이션을 닫아 보세요.

​

W&B에 성능 문제 보고하기

W&B는 성능 문제를 गंभीर하게 다루며, 지연 관련 보고는 모두 조사합니다. 조사를 더 빠르게 진행할 수 있도록, 로딩 속도가 느릴 때는 주요 메트릭과 성능 이벤트를 캡처하는 W&B의 내장 성능 로거를 실행해 주세요. 로딩이 느린 페이지의 URL에 &PERF_LOGGING 매개변수를 추가한 다음, 콘솔 출력을 account team 또는 지원팀과 공유하세요.