🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

ZeroGPU의 짧게 생성되는 GPU 프로세스에서는 실행 시점 컴파일보다 모델을 한 번 미리 컴파일하고 즉시 다시 불러오는 PyTorch 사전 컴파일이 적합하며, 생성 모델의 추론 속도를 최대 1.8배까지 높일 수 있다.

📌 핵심 요약

• ZeroGPU는 요청이 없을 때 GPU를 점유하지 않고, GPU 작업이 호출될 때만 별도 프로세스를 생성해 H200의 MIG 슬라이스를 할당한 뒤 작업이 끝나면 해제한다.
• 일반적인 torch.compile은 최초 실행에서 모델을 컴파일하고 이후 결과를 재사용하지만, ZeroGPU에서는 작업마다 프로세스가 새로 생성되므로 캐시 복원에 수십 초에서 수분이 걸릴 수 있다.
• 사전 컴파일은 예제 입력 수집, torch.export.export를 통한 계산 그래프 내보내기, spaces.aoti_compile을 통한 컴파일, spaces.aoti_apply를 통한 파이프라인 적용 순서로 구성된다.
• FLUX.1-dev에서는 계산량이 큰 트랜스포머만 사전 컴파일해 약 1.7배의 속도 향상을 얻었으며, Flux·Wan·LTX 계열의 전체 사례에서는 1.3배에서 1.8배의 향상이 제시된다.
• H200이 지원하는 FP8 양자화를 사전 컴파일 전에 적용하면 추가로 약 1.2배의 향상을 얻을 수 있고, 다양한 이미지·영상 해상도를 처리하려면 동적 형상도 별도로 지정해야 한다.

🧩 주요 포인트

1. ZeroGPU는 요청이 없을 때 GPU를 점유하지 않고, GPU 작업이 호출될 때만 별도 프로세스를 생성해 H200의 MIG 슬라이스를 할당한 뒤 작업이 끝나면 해제한다.
2. 일반적인 torch.compile은 최초 실행에서 모델을 컴파일하고 이후 결과를 재사용하지만, ZeroGPU에서는 작업마다 프로세스가 새로 생성되므로 캐시 복원에 수십 초에서 수분이 걸릴 수 있다.
3. 사전 컴파일은 예제 입력 수집, torch.export.export를 통한 계산 그래프 내보내기, spaces.aoti_compile을 통한 컴파일, spaces.aoti_apply를 통한 파이프라인 적용 순서로 구성된다.
4. FLUX.1-dev에서는 계산량이 큰 트랜스포머만 사전 컴파일해 약 1.7배의 속도 향상을 얻었으며, Flux·Wan·LTX 계열의 전체 사례에서는 1.3배에서 1.8배의 향상이 제시된다.
5. H200이 지원하는 FP8 양자화를 사전 컴파일 전에 적용하면 추가로 약 1.2배의 향상을 얻을 수 있고, 다양한 이미지·영상 해상도를 처리하려면 동적 형상도 별도로 지정해야 한다.

🧠 상세 정리

1. ZeroGPU가 해결하려는 상시 GPU 점유 문제

Hugging Face Spaces의 일반적인 데모는 모델을 불러온 뒤 곧바로 CUDA 장치로 이동시키는 형태로 구성된다. 이 방식은 구현이 간단하지만, NVIDIA 드라이버가 초기화되는 순간 해당 프로세스가 계속 CUDA와 연결되므로 사용자의 요청이 없는 시간에도 GPU가 예약된다. 실제 데모 트래픽은 일정하기보다 드물고 갑작스럽게 몰리는 경우가 많아, 상시 GPU 점유는 자원 효율이 낮다. ZeroGPU는 이를 피하기 위해 GPU 작업이 필요할 때만 프로세스를 분기하고 CUDA를 설정하며, 작업을 실행한 뒤 GPU를 반환해야 할 시점에 해당 프로세스를 종료한다. 따라서 유휴 상태에서는 GPU를 사용하지 않고, 실제 요청이 있을 때 한 개 이상의 GPU를 동시 작업 수요에 맞추어 사용할 수 있다.

2. 데코레이터를 이용한 지연형 GPU 실행 구조

기존 Spaces 애플리케이션을 ZeroGPU 방식으로 전환할 때 필요한 핵심 변경은 spaces 패키지를 가져오고 GPU 작업 함수에 @spaces.GPU 데코레이터를 추가하는 것이다. 이 패키지는 PyTorch API 호출을 가로채 CUDA 연산을 즉시 수행하지 않도록 미루고, 데코레이터가 붙은 함수가 실제로 호출될 때 별도의 프로세스에서 실행되도록 만든다. 내부적으로는 할당된 장치가 해당 프로세스에 보이도록 처리하지만, 본문은 그 내부 API를 상세 범위에서 제외한다. ZeroGPU는 당시 H200의 3g.71gb 프로필에 해당하는 MIG 슬라이스를 할당하며, 전체 슬라이스를 포함한 추가 크기는 2025년 후반 제공 예정으로 설명된다. ZeroGPU Space는 Pro 사용자와 Team 또는 Enterprise 조직 구성원이 만들 수 있지만, 생성된 Space 자체는 누구나 이용할 수 있다.

3. 실행 시점 컴파일과 ZeroGPU의 구조적 충돌

PyTorch와 JAX 같은 현대적인 기계학습 프레임워크의 컴파일은 연산자 융합과 상수 접기 등 하드웨어 의존적인 최적화를 적용해 모델 지연 시간과 추론 시간을 줄인다. PyTorch 2.0 이후에는 torch.compile을 이용한 실행 시점 컴파일과 torch.export 및 AOTInductor를 이용한 사전 컴파일이 주요 인터페이스로 제시된다. 일반 환경에서 torch.compile은 첫 실행 때 모델을 컴파일하고 이후 호출에서 최적화 결과를 재사용하므로 효과적이다. 그러나 ZeroGPU는 거의 모든 GPU 작업에 대해 새 프로세스를 생성하기 때문에 이전 프로세스의 컴파일 상태를 효율적으로 이어받지 못하고, 파일 시스템 캐시에서 결과를 복구해야 한다. 이 복구 과정은 모델에 따라 수십 초에서 수분까지 걸릴 수 있어 짧게 실행되는 Spaces 작업에는 실용적이지 않다.

4. 사전 컴파일을 위한 예제 입력 수집

사전 컴파일은 실제 추론 전에 모델을 최적화해야 하므로, 런타임에서 들어올 입력과 같은 종류의 예제 인수가 필요하다. 본문은 FLUX.1-dev 파이프라인 전체가 아니라 생성 연산에서 가장 계산량이 큰 트랜스포머, 즉 일반적으로 디노이저에 해당하는 구성 요소만 컴파일한다. spaces.aoti_capture를 문맥 관리자로 사용해 트랜스포머 호출을 감싸고 파이프라인에 임의의 예제 프롬프트를 전달하면, 트랜스포머 연산 자체는 실행되지 않는다. 대신 이 도구가 해당 호출을 가로채 전달될 위치 인수와 키워드 인수를 각각 call.args와 call.kwargs에 저장한다. 이렇게 수집된 값은 이후 내보내기 단계에서 실제 모델 입력 형식과 계산 경로를 표현하는 예제로 사용된다.

5. 모델 내보내기와 AOTInductor 컴파일

수집한 예제 인수는 torch.export.export에 트랜스포머와 함께 전달되어 PyTorch의 ExportedProgram으로 변환된다. 이 프로그램은 모델의 텐서 계산을 나타내는 계산 그래프뿐 아니라 원래 모델의 매개변수 값도 포함한다. 다음 단계에서는 spaces.aoti_compile을 호출해 내보낸 프로그램을 추론에 사용할 사전 컴파일 바이너리로 만든다. 이 함수는 torch._inductor.aot_compile을 감싼 작은 도우미로, 컴파일 결과의 저장과 필요한 시점의 지연 로딩을 관리한다. 전통적인 사전 컴파일에서 사용자가 직접 디스크 저장과 재로딩을 다루는 부분을 spaces 패키지가 보조하므로, 짧게 생성되는 ZeroGPU 프로세스에서도 미리 만든 결과를 즉시 불러오는 구조를 구성할 수 있다.

6. 컴파일 결과 적용과 기존 매개변수 정리

컴파일된 트랜스포머를 원래 파이프라인에 연결할 때 구성 요소 전체를 단순히 교체하는 방식은 적합하지 않다. pipe.transformer에 컴파일 바이너리를 직접 대입하면 dtype과 config 같은 중요한 속성이 사라질 수 있기 때문이다. 반대로 forward 메서드만 교체하면서 원래 모델 매개변수를 그대로 유지하면 불필요한 메모리 점유가 남아 실행 중 메모리 부족이 발생할 수 있다. spaces.aoti_apply는 컴파일된 모델을 기존 트랜스포머의 forward에 연결하면서 오래된 모델 매개변수를 메모리에서 정리해 두 문제를 함께 처리한다. 즉, 파이프라인이 요구하는 구성 정보는 유지하고 실제 계산 경로만 최적화된 바이너리로 바꾸는 것이 이 적용 단계의 핵심이다.

7. 실제 GPU에서의 시작 단계 컴파일과 성능 향상

예제 입력 가로채기, 모델 내보내기, Inductor 컴파일의 첫 세 단계는 실제 GPU에서 수행해야 한다. CUDA가 없는 영역에서 제공되는 에뮬레이션만으로는 충분하지 않은데, 생성 코드 조정을 위한 마이크로 벤치마크처럼 컴파일 과정 자체가 하드웨어 특성에 의존하기 때문이다. 본문은 이 단계를 최대 시작 허용 시간인 1500초를 지정한 @spaces.GPU 함수 안에 넣고, 반환된 컴파일 모델을 애플리케이션 루트에서 원래 트랜스포머에 적용한다. 이후 일반 생성 함수도 @spaces.GPU로 실행하되, 매번 다시 컴파일하지 않고 미리 준비된 결과를 사용한다. 약 열두 줄의 코드를 추가한 FLUX.1-dev 예제는 약 1.7배 빨라졌으며, 글의 서두에서는 Flux·Wan·LTX 모델 사례의 향상 범위를 1.3배에서 1.8배로 제시한다.

8. FP8 양자화와 동적 형상 처리

사전 컴파일은 양자화와 결합해 추가적인 성능 향상을 얻을 수 있으며, 이미지와 영상 생성에서는 FP8 사후 학습 동적 양자화가 속도와 품질 사이에서 유리한 절충을 제공한다고 설명된다. FP8은 최소 9.0의 CUDA 계산 능력을 요구하지만, ZeroGPU가 H200 기반이므로 이 양자화 방식을 사용할 수 있다. 적용 순서는 예제 입력을 수집한 뒤 모델을 내보내기 직전에 torchao의 Float8DynamicActivationFloat8WeightConfig로 트랜스포머를 양자화하는 방식이며, 본문은 이 조합에서 추가로 약 1.2배의 속도 향상을 제시한다. 또한 이미지와 영상은 해상도와 크기가 달라질 수 있으므로, 고정된 예제 입력만 기준으로 컴파일하지 말고 torch.export.export의 기능을 이용해 동적으로 취급할 입력 차원을 지정해야 한다. FLUX.1-dev에서는 서로 다른 이미지 해상도가 트랜스포머의 두 forward 인수에 영향을 주며, 본문에 제시된 hidden_states는 트랜스포머가 노이즈를 제거해야 하는 입력 잠재 표현으로 설명된다.

🧾 핵심 주장 / 시사점

• ZeroGPU에서 사전 컴파일의 핵심 가치는 단순한 연산 최적화뿐 아니라, 매 작업마다 프로세스가 바뀌는 환경에서 실행 시점 컴파일의 긴 복구 비용을 제거하는 데 있다.
• 생성 파이프라인 전체가 아니라 계산량이 가장 큰 트랜스포머만 컴파일하고 기존 매개변수를 정리하면, 변경 범위를 줄이면서 속도 향상과 메모리 절약을 함께 달성할 수 있다.
• 실제 배포에서는 사전 컴파일만 적용하는 것으로 끝나지 않으며, 대상 H200 하드웨어에 맞춘 FP8 양자화와 입력 해상도 변화에 대응하는 동적 형상 설정을 함께 검토해야 한다.

✅ 액션 아이템

• ZeroGPU의 요청 기반 GPU 프로세스 특성을 반영해 실행 전 1회 컴파일 후 즉시 재적용하는 AOTI 흐름을 채택한다.
• 사전컴파일은 예시 입력 수집- torch.export.export- spaces.aoti_compile- spaces.aoti_apply 순서를 고정해 재현성 있는 배치 절차를 정한다.
• H200에서 FLUX.1-dev의 1.7배 향상과 FP8의 추가 1.2배 이득을 반영해 대상 모델의 컴파일 우선순위와 적용 범위를 정의한다.

❓ 열린 질문

• 작업마다 새 프로세스가 생성되는 환경에서 torch.compile 캐시복구 지연(수십초~수분)이 실제로 어느 구간에서 임계 병목이 될 것인가?
• Flux·Wan·LTX 사례의 1.3~1.8배 범위를 대상 모델에 적용할 때 기대 속도 향상을 어떻게 정량적으로 검증할 수 있는가?
• 이미지·영상 다중 해상도를 처리할 때 동적 형상을 어떤 기준으로 분기하면 성능 향상과 호환성을 동시에 확보할 수 있는가?