성능 최적화

성능 최적화 (Performance Optimization)

이 페이지는 지연 시간, 처리량, 메모리, 품질 트레이드오프에 따라 SGLang Diffusion의 성능 레버를 선택하는 방법을 설명해요. SGLang Diffusion 성능 작업의 시작점으로, 출력 보존(lossless 스타일) 레버와 품질 트레이드오프(손실/근사) 레버의 두 결정 클래스로 나눠요.

출처: 문서

본문

이 페이지는 SGLang Diffusion 성능 작업의 시작점으로 사용해요. 성능 레버를 두 가지 결정 클래스로 분리해요:

• 출력 보존 / lossless 스타일: 상주(residency), 병렬 처리, 커널 또는 스케줄링을 변경하는 동안 모델 동작을 보존해야 하는 시스템 설정.
• 품질 트레이드오프 / 손실 또는 근사: 디노이징 경로, 수치 표현 또는 생성 출력을 바꿀 수 있는 기법.

문서는 비트 정확한 "lossless"를 약속하는 대신 "출력 보존"을 사용해요. 서로 다른 커널, GPU 유형 또는 정밀도 경로가 여전히 작은 수치 차이를 만들어낼 수 있기 때문이에요. 결정 경계는 최적화가 속도를 위해 의도적으로 품질 또는 출력 동등성을 거래하는지 여부예요.

여기서 시작 (Start Here)

1. Deployment and Performance Modes에서 서빙 또는 생성 모드를 선택해요. --performance-mode auto가 기본이고, 모델이 GPU 메모리에 맞고 지연 시간이 가장 중요할 때 speed, GPU 메모리가 병목일 때 memory, 모든 성능 플래그가 명시적이어야 할 때 manual을 사용해요.
2. Attention Backends에서 올바른 어텐션 백엔드를 선택해요.
3. 모델과 비디오 형태가 시퀀스 분할을 활용할 때만 Sequence Parallelism을 사용해요.
4. 서빙 중 동시 호환 요청에는 Inference Batching을 사용해요.
5. 여러 레버를 한 번에 바꾸기 전에 Profiling을 사용해요.

요청 품질 등급 선택 (Choose a request quality tier)

--quality는 누적적이에요. 더 넓은 등급은 더 엄격한 등급의 최적화를 절대 버리지 않아요.

융합 이득을 근사 가속화로부터 격리하고 싶을 때 extra-high를 사용해요. 활성 모델에 적격 경로가 없으면 등급이 no-op일 수 있어요. 별도로 구성된 양자화, 어텐션 또는 캐싱 옵션은 여전히 적용돼요. 현재 요청 게이팅 패밀리와 수치 계약은 Fused Kernels를 참고해요.

출력 보존 / Lossless 스타일 레버 (Output-Preserving / Lossless-Style Levers)

이 설정들은 상주, 병렬 처리, 커널 또는 스케줄링을 변경하면서 모델 동작을 보존해야 해요. 프로덕션 튜닝의 첫 선택이에요.

품질 트레이드오프 / 손실 또는 근사 레버 (Quality-Tradeoff / Lossy Or Approximate Levers)

이 기법들은 디노이징 경로, 수치 표현 또는 생성 출력을 바꿀 수 있어요. 기준선과 품질 수용 기준이 생긴 후에 유용해요.

실용적인 순서 (Practical Order)

1. 대상 모델, 해상도, 프레임 수, 스텝 수, GPU 유형으로 기준선 수립.
2. --performance-mode와 명시적 상주 또는 병렬 처리 플래그 선택.
3. quality=lossless와 quality=extra-high를 비교해 요청 게이팅 융합 집합을 격리.
4. 지원되는 고정 형태 파이프라인에서 breakable CUDA graph를 eager 실행과 비교. 모든 서빙 해상도를 --warmup-resolutions에 전달하고 서버 로그에서 캡처를 확인. 요청 게이팅 DiT 융합이 있는 모델은 그 융합을 lossless 브랜치에서 캡처된 그래프와 결합할 수 없음.
5. 배포 패턴에 맞춰 어텐션 백엔드와 배칭 튜닝.
6. 병목이 불명확하면 프로파일링.
7. 품질 트레이드오프 레버는 출력 품질을 수용 대상과 비교한 후에만 추가.

모델별 튜닝 시작점 (Per-model tuning starting points)

워밍업과 breakable CUDA graph(BCG)는 서로 다른 문제를 해결해요. --warmup-mode request는 첫 요청에서 파생된 워밍업 복사본을 실행해 일회성 컴파일과 캐시를 준비하며, 각 디노이징 스텝의 반복 Python 실행을 제거하지 않아요. BCG는 지원되는 DiT 세그먼트를 캡처하고 캡처된 형태의 반복 실행 오버헤드를 줄일 수 있어요. 아래 표를 첫 실험으로 사용하고, 프로파일링이 레버가 활성 병목을 다룬다고 확인할 때만 유지해요.

예시 할당은 단일 GPU NVIDIA B300/GB300 프로파일에서 나온 방향성이며 완전한 호환성 목록이 아니에요. 해상도, 프레임 수, 스텝 수, 병렬 처리 또는 GPU 유형이 바뀌면 모델이 여러 행과 일치할 수 있어요. 모델 이름보다 측정된 병목이 우선해요.

BCG는 런타임 지원 검사가 수용하는 모델 및 파이프라인 구성에 대해서만 활성화돼요. 기본 워밍업 형태를 자동으로 캡처해요. 추가 서빙 해상도에는 --warmup-resolutions을, 비디오와 가변 프롬프트 길이에는 --warmup-num-frames와 --bcg-text-buckets를 설정해 의도된 워크로드를 덮어요. 캡처된 시그니처와 일치하지 않는 요청은 eager 실행으로 폴백해요.

워밍업과 BCG는 속도를 위해 의도적으로 출력 품질을 거래하지 않지만, 이는 바이트 동일 출력의 보장이 아니에요. 서로 다른 실행 경로가 수치 차이를 만들 수 있고 일부 파이프라인은 합성 워밍업 요청이 사용하는 스케줄러 또는 스케줄을 커스터마이즈해요. 프로덕션 배포 전에 비트 단위 안정성이 필요하면 출력 해시를 비교하고, 그렇지 않으면 프로젝트의 품질 수용 검사를 실행해요.

성능 결과는 구성에 따라 달라져요. 정확한 체크포인트 리비전, GPU, 정밀도, 해상도, 프레임 수, 스텝 수, 병렬 처리, 명령줄, 측정에 워밍업 포함 여부를 기록해요. 다른 모델이나 형태에서 백분율을 옮기지 말고 대상 워크로드에서 Profiling으로 다시 프로파일해요.

진단 (Diagnostics)

Profiling은 그 자체로 최적화 기법이 아니에요. 여러 레버를 바꾸기 전에 어떤 단계, 커널 또는 디노이징 스텝을 최적화할 가치가 있는지 알려주므로 성능 워크플로우에 속해요.

참고 자료 (References)

• Deployment and Performance Modes
• Attention Backends
• Fused Kernels
• Sequence Parallelism
• Caching Strategies
• Profiling

더 알아보기

• SGLang Diffusion 개요