Sparse VideoGen TPU 최적화: 비디오 생성 추론 지연을 줄이는 실무 기준

요약: Google Developers Blog의 Sparse VideoGen TPU 최적화 사례는 비디오 생성 모델의 병목이 어디에서 생기고, 이론적 sparsity를 실제 하드웨어 속도 향상으로 바꾸려면 무엇이 필요한지 보여준다. 핵심 수치는 81프레임 720p 비디오에서 sequence length가 50K~400K 범위까지 커질 수 있고, 720p에서 1440p로 올리면 self-attention 비중이 55.5%에서 88.2%까지 커질 수 있다는 점이다. 최종적으로 1440p 비디오 생성에서 최대 1.69배 end-to-end inference speedup을 얻었다.

왜 비디오 생성은 느린가

비디오 diffusion 모델이 느린 이유는 크게 두 가지다. denoising step 수가 많고, 각 step의 계산 비용이 크다. 해상도와 프레임 수가 올라가면 각 step 안에서 self-attention이 병목이 된다.

Google 글은 81프레임 비디오를 예로 든다. 인기 있는 오픈소스 비디오 생성 모델에서 720p의 sequence length가 50K~400K 범위까지 커질 수 있다고 설명한다. 여기서 1440p로 올리면 sequence length가 크게 늘고, full attention은 sequence length의 제곱에 가깝게 비용이 증가한다.

특히 720p에서 1440p로 올라갈 때 attention이 single-layer transformer block latency에서 차지하는 비중이 55.5%에서 88.2%까지 커질 수 있다는 대목이 중요하다. 이 정도면 최적화할 곳이 명확하다. decoder 주변의 사소한 튜닝보다 attention을 줄이는 것이 먼저다.

Sparse VideoGen의 핵심 아이디어

Sparse VideoGen, 즉 SVG의 출발점은 비디오 diffusion의 attention이 완전히 무작위가 아니라는 관찰이다. 많은 query-key interaction은 실제 attention mass가 작고, 일부 구조적인 패턴에 집중된다.

논문과 Google 설명에 따르면 attention head는 대체로 spatial head와 temporal head로 나눠 볼 수 있다. spatial head는 같은 프레임 또는 가까운 프레임 안의 patch에 주로 집중한다. temporal head는 같은 공간 위치 주변을 여러 프레임에 걸쳐 따라간다. 즉 모든 토큰이 모든 토큰을 균등하게 볼 필요가 없다.

SVG는 inference 중 일부 query를 샘플링해 dense attention, spatial sparse attention, temporal sparse attention의 출력 차이를 비교한다. 그리고 dense baseline과 가장 덜 다른 sparse mask를 head별로 선택한다. 이 접근은 단순히 고정된 sparse pattern을 쓰는 것보다 품질을 보존하기 쉽다.

하지만 여기서 끝나지 않는다. 모델 수식상 sparse하다고 해서 하드웨어가 자동으로 빨라지는 것은 아니다.

이론적 sparsity와 물리적 sparsity의 차이

Google 글에서 가장 실무적인 부분은 “logical sparsity is not physical sparsity”라는 대목이다. attention matrix에서 61% interaction을 버린다고 해서 GPU나 TPU 시간이 바로 61% 줄어들지는 않는다.

현대 attention kernel은 전체 QK 행렬을 통째로 만들지 않고 tile 단위로 계산한다. sparse mask가 있더라도 방문한 tile 안에서 제외된 pair를 negative infinity로 마스킹할 뿐, 그 tile을 계산해야 한다면 비용이 남는다.

따라서 tile은 세 종류로 나뉜다.

• full tile: 모두 필요한 pair라서 빠르게 계산할 수 있다.
• boundary tile: 필요한 pair와 버릴 pair가 섞여 있어 elementwise mask가 필요하다.
• empty tile: 필요한 pair가 없어서 완전히 건너뛸 수 있다.

진짜 속도 향상은 empty tile을 얼마나 잘 건너뛰고, boundary tile의 마스킹 비용을 얼마나 줄이느냐에서 나온다. Google의 초기 sparse prototype은 query-key pair 기준으로는 약 61% sparsity였지만, tile 기준으로는 44% outer tile을 방문해야 했고, 모든 방문 tile에서 exact mask를 평가했다. 그 결과 dense Splash Attention보다 오히려 느린 96.37ms가 나왔다고 설명한다. dense baseline은 78.70ms였다.

이 사례는 ML 최적화에서 흔히 보는 함정이다. 알고리즘 복잡도만 보고 빨라질 거라고 기대했지만, 실제 kernel, memory layout, tile traversal이 맞지 않으면 느려진다.

실무에서 배울 최적화 기준

비디오 생성 서비스를 운영하는 팀이라면 이 사례에서 네 가지 기준을 가져갈 수 있다.

첫째, 병목을 layer 단위가 아니라 kernel 단위로 측정해야 한다. “attention이 느리다”는 말로는 부족하다. 어떤 해상도, 몇 프레임, 어떤 head dimension, 어떤 tile size에서 얼마나 느린지 봐야 한다.

둘째, sparsity는 하드웨어 구조와 함께 설계해야 한다. pair를 얼마나 줄였는지가 아니라 tile을 얼마나 건너뛰는지, boundary tile이 얼마나 남는지, memory access가 연속적인지까지 봐야 한다.

셋째, token ordering이 중요하다. Google 글은 temporal mask가 frame-major ordering에서는 fine-grained diagonal stripe처럼 보이며, token permutation이 필요하다고 설명한다. 같은 sparse pattern도 메모리 배치가 맞지 않으면 kernel이 이득을 못 본다.

넷째, end-to-end 속도와 kernel microbenchmark를 구분해야 한다. isolated attention kernel이 빨라졌다고 전체 inference가 같은 비율로 빨라지지는 않는다. routing, token permutation, device communication, denoising loop 전체 비용을 같이 봐야 한다.

제품팀 관점의 적용 포인트

비디오 생성 제품을 만드는 팀이 당장 Sparse VideoGen을 직접 구현하지 않더라도, 다음 의사결정에 영향을 줄 수 있다.

먼저 해상도 옵션을 설계할 때 attention 비용을 고려해야 한다. 720p와 1440p는 단순히 픽셀이 4배가 아니라 attention 병목 비중이 크게 달라진다. 무료 플랜에 고해상도 긴 비디오를 열면 비용 구조가 쉽게 무너진다.

다음으로 프리뷰 생성과 최종 렌더링을 분리하는 것이 좋다. 사용자가 prompt를 여러 번 수정하는 단계에서는 낮은 해상도와 짧은 frame count로 빠른 피드백을 주고, 최종 확정 후 고해상도 렌더링을 돌리는 편이 비용과 UX 모두 안정적이다.

또한 모델 선택 시 단순 품질 점수만 보지 말고 latency profile을 봐야 한다. 같은 품질이라면 attention 최적화가 잘 된 모델이 운영 비용에서 유리하다. 특히 대량 생성 서비스에서는 평균 latency보다 p95, p99 latency가 더 중요하다.

마지막으로 custom kernel 최적화는 팀 역량을 많이 탄다. JAX, Pallas, Splash Attention, TPU layout까지 다룰 수 있는 팀이 아니라면 직접 구현보다 managed inference나 최적화된 오픈소스 구현을 쓰는 편이 안전할 수 있다.

실행 체크리스트

• 비디오 생성 모델의 latency를 denoising step, attention, VAE, I/O로 나눠 측정한다.
• 해상도와 frame count별 sequence length와 p95 latency를 기록한다.
• sparse attention 적용 시 pair sparsity가 아니라 skipped tile 비율을 본다.
• boundary tile 마스킹 비용과 token permutation 비용을 따로 측정한다.
• microbenchmark 결과와 end-to-end inference 결과를 분리해 보고한다.
• 프리뷰 생성과 최종 고해상도 렌더링을 제품 플로우에서 분리한다.
• 무료/유료 플랜별 frame count, 해상도, 동시 생성 수를 비용 기준으로 제한한다.
• 직접 kernel을 만질 역량이 없으면 최적화된 runtime이나 vendor inference를 우선 검토한다.

Sparse VideoGen TPU 사례의 교훈은 간단하다. 비디오 생성 최적화는 “sparse하게 만들었다”에서 끝나지 않는다. 실제 속도는 tile, kernel, memory layout, end-to-end pipeline이 함께 맞을 때 나온다. 개발팀이 이 기준으로 병목을 보면, 모델 품질을 유지하면서도 추론 비용과 대기 시간을 줄일 현실적인 길을 찾을 수 있다.