고해상도 영상 생성은 왜 비싸고, Prism과 Kandinsky 6는 어떻게 줄일까?

H100 한 장에서 Prism과 Kandinsky 6의 기법을 하나씩 켜고 꺼 봤습니다. 720p 5초 조건에서 생성 시간을 실제로 줄인 건 sparsity와 증류였고, Prism 동적 블록은 속도를 거의 바꾸지 않았습니다.

은긔
은긔
Prism·Kandinsky 6 영상 생성 속도 기법 실험 썸네일

핵심 요약

1

Prism 동적 블록을 켜도 스텝당 시간은 38.8초에서 39.7초로 거의 같았습니다.

2

sparsity를 0.75에서 0.93으로 올리자 디노이즈가 1984초에서 1260초로 36% 줄었지만 어깨 쪽 옷 질감이 프레임마다 흔들렸습니다.

3

Kandinsky 6 Pro-distill은 768×432 10스텝 생성과 VSR ×2를 합쳐 클립당 141~193초였습니다.

같은 사진, 같은 프롬프트, 같은 시드로 Prism 영상 세 개를 만들었습니다. 설정은 하나씩만 달랐는데요. 그중 하나는 다른 두 영상보다 디노이즈가 11분 넘게 빨리 끝났습니다. 대신 어깨 쪽 옷 질감이 프레임마다 왔다 갔다 했습니다.
요즘 오픈 영상 모델은 720p 5초 한 편에도 수십 분이 걸립니다. Prism 논문과 Kandinsky 6 기술 보고서는 이 비용을 서로 다른 곳에서 줄인다고 설명하는데요. 이 글에서는 문서에 나온 기법 세 가지를 Runpod H100 80GB 한 장에서 한 번에 하나씩 켜고 끄며, 생성 시간이 얼마나 바뀌었고 화면에서 무엇이 달라졌는지 정리했습니다.
  1. Prism의 블록 희소 어텐션: 동적 블록 모양과 sparsity
  2. Kandinsky 6의 저해상도 생성 + 별도 SR 모델
  3. Kandinsky 6의 π-Flow 증류: forward 100회 → 10회
설정마다 시드 하나로 한 번씩만 실행했습니다. 화면 관찰은 제가 결과를 나란히 보고 적은 것이고, 품질 우열을 가리는 벤치마크는 아닙니다.

토큰 수의 제곱으로 느는 어텐션 비용

요즘 영상 생성 모델은 대부분 DiT(Diffusion Transformer)입니다. 3D VAE로 영상을 latent로 압축하고, 패치로 잘라 토큰 시퀀스로 만든 뒤 트랜스포머에 넣죠. 그래서 계산량은 결국 토큰이 몇 개인지로 정해집니다.
이번에 돌린 720p 5초(121프레임)를 Prism에 넣으면 토큰 격자가 시간 32 × 세로 48 × 가로 80, 패딩까지 약 12만 3천 개였습니다. 동적 블록 기록에서 직접 확인한 값입니다. 비디오 self-attention은 이 토큰 전부를 서로 비교하기 때문에 비용이 토큰 수의 제곱으로 늘어납니다. 가로세로 해상도를 두 배로 올리면 토큰은 4배, 어텐션 계산은 16배가 되죠.
여기에 CFG(classifier-free guidance)까지 쓰면 스텝마다 조건부·무조건부 forward를 두 번씩 돌립니다. Prism을 50스텝으로 돌리면 트랜스포머 forward가 100번입니다. H100 한 장에서 이 디노이즈 구간만 1940초, 약 32분이 걸렸습니다.
두 문서는 이 비용을 다른 곳에서 줄입니다. Prism은 어텐션을 희소하게 만들어 덜 보고, Kandinsky 6는 토큰 수 자체를 줄이고 증류로 forward 횟수를 줄입니다.

같은 계산량 안에서 볼 곳을 고르는 Prism

Prism은 푸단대·텐센트 훈위안 등이 낸 논문으로, 영상과 소리를 함께 만드는 MOVA를 바탕으로 2K 영상을 네이티브로 학습하는 것이 목표입니다.
바탕은 블록 희소 어텐션(block sparse attention)입니다. 토큰을 블록으로 묶고, 쿼리 블록마다 관련도가 높은 키 블록만 골라 계산하는 방식이죠. 얼마나 건너뛸지는 sparsity가 정합니다. 이번 기준 설정인 0.75는 키 블록의 25%만 본다는 뜻입니다. 실제로 기록해 보니 쿼리 블록당 1,920개 중 평균 480개를 골랐습니다.
나머지 75%는 아예 보지 않기 때문에 어느 블록을 고르느냐가 품질을 좌우합니다. 블록을 고를 때는 블록 안 토큰 64개의 평균으로 판단하는데요. 기본 블록 4×4×4는 4프레임을 한 블록에 묶습니다. 손처럼 빠르게 움직이는 곳은 서로 다른 순간이 한 블록 안에서 평균이 돼 버려, 이 블록이 중요한지 판단이 흐려질 수 있습니다.
Prism은 영상을 8×8×8 토큰 구역으로 나누고, 구역마다 시간·세로·가로 축의 변화량을 재서 많이 변하는 축은 짧게 묶습니다. 블록 크기는 64토큰 그대로라 보는 양은 같고, 묶는 모양만 바뀝니다. 논문은 이 블록 모양을 정할 때 소리와 강하게 결합된 영역도 반영한다고 설명합니다.
논문이 보고한 수치로는 2K 학습 한 스텝이 full attention 26.5분에서 10.6분으로 약 2.5배 빨라졌고, 10초 2K 추론은 H800 4장에서 MOVA full attention 1091초 대비 331초였습니다. 다만 2.5배는 학습 속도이고, 추론 비교 대상은 full attention으로 돌린 베이스 모델입니다. 같은 논문에서 720p의 화질·모션 점수(0.58 / 0.71)는 2K(0.61 / 0.89)보다 낮아, 해상도가 낮을수록 이득이 작다고 보고합니다. 이번 실험은 그 720p에서 했습니다.

문서와 다른 기본값

고정한 커밋(8f0c263)의 README 표에는 ENABLE_IVPQ_DYNAMIC_BLOCK 기본값이 true로 적혀 있고, 인자 설명에는 "Prism core"라는 표현까지 있습니다. 그런데 배포된 prism_infer.sh는 이 값을 "false"로 두고, CLI 인자 --enable_ivpq_dynamic_block의 기본값도 false입니다. 공식 스크립트나 CLI를 그대로 돌리면 동적 블록이 꺼진 채로 실행되는 셈이죠. 저도 이전 실험에서는 끈 채로 돌렸습니다.
sparsity도 다릅니다. CLI 기본값은 0.9375이고 prism_infer.sh는 0.75입니다. 스크립트 없이 CLI만 호출하면 훨씬 공격적으로 건너뛰는 설정이 됩니다. 동적 블록을 쓰려면 --enable_ivpq_dynamic_block true를, sparsity는 원하는 값을 직접 넘기는 편이 안전합니다.

동적 블록을 켜도 그대로였던 속도

설정디노이즈스텝당
고정 블록 4×4×4, sparsity 0.751940초38.8초
동적 블록, sparsity 0.751984초39.7초
동적 블록, sparsity 0.931260초25.2초
H100 80GB, 1280×720, 121프레임, 50스텝, CFG 5, seed 42001, 설정별 1회. 디노이즈는 첫 forward 시작부터 마지막 forward 반환까지이며 모델 로딩은 뺐습니다. 동적 블록 행에는 블록 모양 기록 비용이 조금 들어 있습니다.
동적 블록을 켜자 스텝당 시간은 38.8초에서 39.7초로 거의 같았습니다. 블록 모양이 바뀌어도 키 블록 25%라는 계산량이 그대로이니 자연스러운 결과죠. 동적 블록은 속도 기능이라기보다, 같은 예산 안에서 어디를 볼지 바꾸는 기능에 가깝습니다.
블록 모양을 실제로 어떻게 고르는지 보려고, 업스트림 코드를 고치지 않는 래퍼로 동적 블록 어텐션 호출 4,000번(50스텝 × CFG 2 × 40층)을 모두 기록했습니다. 첫 스텝에서는 75.3%가 기본 4×4×4를 그대로 썼고, 마지막 스텝에서는 43.9%로 줄었습니다. 전체 호출로 보면 62%가 기본 모양이었습니다. 이번 설정에서는 초반 스텝의 동적 블록이 고정 블록과 크게 다르지 않았고, 다른 모양은 후반 스텝에서 많이 선택됐습니다.
화면은 장면마다 달랐습니다. 주방 장면은 고정 블록과 동적 블록 결과가 거의 같았고, 사진에 없던 손이 2초 무렵 화면 오른쪽 끝에서 들어오는 현상도 그대로였습니다. 산 전망대 장면에서는 고정 블록일 때 중간에 이미지 두 장이 겹친 것처럼 보이던 구간이 동적 블록에서는 덜했는데요. 중간중간 화면이 튀는 현상은 남아 있었습니다. 산 장면의 고정 블록 결과는 같은 설정으로 이전에 H200에서 만든 영상입니다. 같은 설정에서 GPU만 바뀌었을 때의 차이는 주방 장면 기준 프레임 평균 절대차 1.85/255로 작았습니다.

sparsity 0.93이 줄인 36%와 흔들린 옷 질감

실제로 시간을 줄인 건 sparsity였습니다. 동적 블록을 켠 상태에서 0.75를 0.93으로 올리면 키 블록을 약 7%만 보는데요. 디노이즈가 1984초에서 1260초로 36% 줄었습니다. 속도는 얼마나 보느냐가 정하고, 블록 모양은 어디를 보느냐를 정하는 셈이죠.
주방 장면, 동적 블록. 왼쪽이 sparsity 0.75, 오른쪽이 0.93입니다. 앞 5초는 전체 화면, 뒤 5초는 어깨 부분을 확대했습니다. 입력은 AI로 생성한 가상 인물 사진입니다.
대신 영상으로 보면 어깨 쪽 옷 질감이 프레임마다 갑자기 바뀌었습니다. 그대로 있어야 할 부분이 매번 새로 그려지는 느낌이었죠. 프레임별 평균 절대차도 0.75와 0.93 사이가 8.2/255로, 고정 블록과 동적 블록 사이(3.8/255)보다 컸습니다. 세 설정 모두에서 오른쪽 끝의 손은 나타났습니다. 적어도 이번 결과에서 이 손은 어떻게 건너뛰느냐와는 관계가 없었습니다.

처음부터 작게 만드는 Kandinsky 6

Kandinsky 6 기술 보고서에 따르면 Kandinsky 6 Pro는 비디오 19B, 오디오 5B, 두 스트림을 잇는 cross 5B로 이루어진 29B 듀얼 스트림 DiT입니다. 블록마다 두 스트림이 서로를 참조하며 영상과 소리를 함께 만듭니다.
이 모델은 기본 생성을 SD 해상도에서 합니다. 720p가 필요하면 768×432로 만들고, 따로 학습한 SR 모델로 두 배 키우죠. 같은 VAE 압축(시간 4배, 공간 8배)과 패치 크기(1×2×2)로 계산해 보면, 768×432 5초는 31×27×48 ≈ 4만 토큰, 1280×720을 바로 만들면 31×45×80 ≈ 11만 토큰입니다. 이 토큰 수는 체크포인트 설정값으로 제가 계산한 값입니다. 어텐션이 토큰 수의 제곱에 비례한다면 계산량은 7분의 1 수준이 됩니다. Prism이 어디를 덜 볼지 고민했다면, Kandinsky는 처음부터 작게 만드는 쪽을 택한 거죠.
주방 장면, Kandinsky 6 Pro-distill. 1280×720 기준으로 같은 영역을 잘랐습니다. 왼쪽은 432p 원본을 bicubic으로 확대, 오른쪽은 공식 VSR ×2입니다.
432p 원본과 SR 결과를 같은 배율로 잘라 보면, 셔츠와 앞치마의 결은 SR 단계에서 선명해집니다. 구도와 움직임은 432p에서 이미 정해져 있죠. SR 모델은 프롬프트를 보지 않기 때문에 432p 단계에서 구도가 틀어지면 SR로는 고칠 수 없습니다.

forward 100회를 10회로 줄인 증류

원본 Pro는 50스텝에 guidance 5를 쓰므로 forward가 100번입니다. 보통 flow 모델은 forward 한 번에 지금 위치에서 갈 방향 하나만 냅니다. 노이즈에서 영상까지 가는 경로는 휘어 있어서, 스텝을 크게 잡으면 이 곡선을 따라가지 못하고 결과가 뭉개지죠.
증류판이 쓰는 π-Flow는 student 모델이 forward 한 번에 방향 하나가 아니라, 이후 구간을 네트워크 없이 따라갈 수 있는 policy를 예측합니다. Kandinsky 6 보고서와 체크포인트 설정에 따르면 출력 헤드를 10개 출력으로 늘려 clean latent 예측 격자를 만들고, 그 사이를 보간합니다. 전체 경로는 128개 substep으로 잘게 나눠 따라가는데, 이 substep에는 추가 forward가 들지 않습니다. 그래서 forward 10번으로도 휜 경로를 따라갈 수 있습니다.
보고서는 학습 단계에서 teacher의 CFG 적용 궤적을 그대로 흡수하기 때문에 별도의 CFG 증류가 필요 없다고 설명합니다. 그래서 추론에서도 무조건부 패스를 돌리지 않고, 50스텝 × 2패스가 10번이 되죠. 다만 궤적 압축만으로는 고주파 디테일이 줄어서, 그다음 실제 영상으로 adversarial 학습(Sim-LADD)을 한 번 더 해 디테일을 되살렸다고 합니다. 보고서의 사람 평가에서 증류판과 원본의 선호는 51 대 49였습니다.
설정디노이즈스텝당클립당 합계 (VSR 포함)
Pro-distill, 768×432, 10스텝, VSR ×270~71초약 7초141~193초
H100 80GB, 장면·프롬프트 4가지, seed 42001, 각 1회. 클립당 합계는 생성 호출과 VSR 시간을 더한 값이며 모델 로딩, VSR 로드(194초), 커널 워밍업·VAE 컴파일(1,065초)은 뺐습니다. module offload 상태에서 최대 할당 78.1GB였습니다.
H100에서 증류판은 디노이즈 약 70초, 스텝당 약 7초였습니다. SR까지 합쳐도 클립 하나에 2~3분입니다. 이 단계에서는 디노이즈와 SR이 비슷하게 걸려서, 병목이 생성에서 SR 쪽으로 옮겨간 셈이죠.
같은 장면을 이전에 H200에서 원본 Pro 50스텝으로 만든 결과와 나란히 보면 두 클립 모두 컵을 식탁에 내려놓고, 구도와 배경 배치가 거의 같았습니다. 제가 보기에는 증류판도 충분히 쓸 만했습니다. 원본 Pro는 이번 H100 세션에서 다시 돌리지 않았습니다. 예산 안에 들어가지 않아 같은 설정의 이전 H200 출력을 기준으로 썼고, 그래서 Pro의 H100 생성 시간은 이 글에 없습니다.
증류판에 짧은 프롬프트를 넣고 프롬프트 보강기(qwen25)를 켜 보기도 했는데요. 보강기가 다시 쓴 문장에 '한 모금 마시려는 듯 컵을 입으로 가져간다'는 동작이 들어가, 요청에 없던 마시는 동작이 영상에 추가됐습니다. 보강기를 끈 쪽에서는 다른 사람의 팔이 화면 왼쪽에서 들어왔습니다. 짧은 프롬프트로는 둘 다 요청한 동작에서 벗어났습니다.

실험 조건과 비용

항목값
GPUNVIDIA H100 80GB HBM3 (SXM) × 1, Runpod Secure Cloud
컨테이너runpod/pytorch:1.0.2-cu1281-torch280-ubuntu2404
디스크Volume 450GB, Container 30GB
입력AI로 생성한 가상 인물 사진 2장(주방, 산 전망대), I2V
공통5초, 24fps, 121프레임 생성 → 1280×720·120프레임으로 정규화, seed 42001
PrismAlpha, 1280×720 직접 생성, 50스텝, CFG 5, CPU offload
Kandinsky 6Pro-distill, 768×432, 10스텝, guidance 1.0, 공식 VSR ×2, 프롬프트 보강기 끔(보강기 비교 제외)
Pod 사용 시간4.27시간
비용GPU $3.99/h × 4.27h ≈ $17.0 + 디스크 약 $0.3 = 약 $17.3
Prism의 MoE 영상 전문가 두 개는 각각 28.6GB라 H100 80GB에 함께 올리기 어려웠습니다. 그래서 지금 쓰는 전문가만 GPU에 두고 다른 하나는 CPU로 옮기는 래퍼를 썼습니다. 계산 결과는 바꾸지 않지만 교체가 클립당 두 번, 한 번에 15~25초 걸렸습니다. 같은 설정을 교체 없이 돌린 이전 H200 실행은 스텝당 약 34.9초였습니다.
이 Pod의 /workspace는 네트워크 파일시스템이었습니다. 그래서 패키지 설치에 약 40분, Prism 프로세스 하나를 띄우는 데 16~20분이 걸렸고, 비용의 상당 부분이 생성이 아닌 준비 시간에 들어갔습니다. 비용은 Pod 생성부터 삭제까지의 시간으로 계산한 추정치이며 최종 청구서로 확인한 값은 아닙니다.
이 결과를 넓게 일반화하기 어려운 이유도 함께 적어 둡니다.
  • 설정·장면마다 시드 하나, 실행 한 번입니다. 화면 차이는 이번 결과에서 본 것이지 재현율이 아닙니다.
  • 720p에서만 쟀습니다. Prism 논문이 목표로 하는 2K에서는 결과가 다를 수 있습니다.
  • 산 장면의 고정 블록과 증류 비교의 원본 Pro는 이전 H200 출력입니다.

시간을 줄인 건 건너뛰는 양과 forward 횟수

하나씩 꺼 보니, 이번 720p 5초 조건에서 생성 시간을 실제로 줄인 건 얼마나 건너뛰느냐(sparsity)와 몇 번 forward하느냐(증류)였습니다. Prism의 동적 블록은 속도를 거의 바꾸지 않았고, 장면에 따라 화면 일부가 달라졌습니다. sparsity 0.93은 디노이즈를 36% 줄였지만 옷 질감이 흔들렸고, 그래도 5초 한 편의 디노이즈에만 21분이 걸렸습니다. Kandinsky 6 증류판은 432p 생성과 SR을 합쳐 2~3분이었습니다.
같은 H100에서 여러 번 다시 뽑으며 구도를 잡는 작업이라면, 저는 Kandinsky 6 Pro-distill을 768×432 + VSR로 먼저 써 보겠습니다. Prism을 쓴다면 동적 블록과 sparsity를 기본값에 맡기지 말고 직접 지정한 뒤, 0.75와 0.93 사이에서 디노이즈 시간과 정지한 부분의 질감 변화를 함께 비교하는 편을 권합니다.

같은 조건으로 따라 해보기

Pod 사양, 고정 커밋과 가중치 revision, 설치 명령(Prism의 flash-attn wheel·audiotools 우회 포함), 설정별 실행 명령, 동적 블록 모양 기록 훅, 측정 결과를 OMG Runpod Media의 05 레시피에 정리했습니다. 레시피 스크립트는 실험에 쓴 스크립트를 옮겨 정리한 것으로, 새 Pod에서 처음부터 그대로 다시 실행해 보지는 않았습니다.
레시피를 Runpod에서 실행하면 GPU와 저장 공간 비용이 발생합니다. 실험이 끝나면 Pod와 Volume을 직접 삭제했는지 확인하세요.
이 글은 김진의가 Oh My GPU에서 진행한 실험입니다. Runpod 공식 벤치마크가 아닙니다. 논문 수치는 각 논문과 기술 보고서가 보고한 값이며, 직접 검증한 것은 이 글의 H100 측정값과 고정 커밋의 기본값입니다.

🔗 References

현재 워크로드를 함께 살펴봅니다.

Runpod 도입·GPU 운영 상담하기