요약
- vLLM-Omni와 FastVideo의 FastH3가 결합해 미니맥스 H3로 만든 10.1초 영상(오디오 포함)을 8.7초 만에 완성했어요.
- 가속은 Turbo LoRA(요청별 전환 가능한 사이드카)와 FastH3 프리뷰(로드 시점 가중치 융합) 두 방식으로 구현됐어요.
- 두 방식 모두 노이즈 제거 반복을 5개 시그마 포인트 기준 4회 DiT 연산으로 줄이지만, 유연성과 속도의 트레이드오프가 갈려요.
- 생성 결과
- 10.1초 MP4(영상+동기화 오디오)를 8.7초 만에 생성
- 결합 기술
- vLLM-Omni 서빙 + FastVideo의 FastH3 가속
- 베이스 모델
- MiniMax H3 (미니맥스, 8월 3일 오픈웨이트 공개)
- 가속 방식 A
- Turbo LoRA — 요청별 전환 가능한 LoRA 사이드카, y=Wx+B(Ax)
- 가속 방식 B
- FastH3 프리뷰 — 로드 시점 가중치 융합, W*=W+BA+Δ
- 압축 스케줄
- 5개 시그마 포인트 → 4회 DiT 순전파로 축소
- 근거 문서
- vLLM-Omni PR #6476, #6550, #6714
- FastH3 프리뷰 제약
- 요청별 전환 불가, VSA 변형 미지원, 오프로드 미지원
8.7초 만에 완성된 10.1초 영상
vLLM 프로젝트가 9월 1일 공개한 벤치마크에 따르면, 미니맥스(MiniMax)의 영상 모델 H3로 만든 10.1초짜리 MP4 — 영상과 동기화된 오디오까지 포함 — 를 8.7초 만에 만들어냈어요. 영상을 만드는 데 걸린 시간이 그 영상의 재생 시간보다 짧아진 셈인데, vLLM-Omni 서빙 위에 FastVideo 팀이 오픈소스로 공개한 가속 기법 FastH3를 얹은 결과예요.
풀어서 설명하면, 미니맥스 H3는 텍스트나 이미지를 넣으면 영상과 소리를 함께 만들어내는 영상 생성 모델이고, vLLM-Omni는 이런 모델을 실제 서비스에서 빠르게 처리하도록 vLLM 프로젝트가 운영하는 서빙 인프라예요. FastVideo 팀이 만든 FastH3는 이 H3 모델의 반복 연산 횟수를 줄여 속도를 끌어올리는 오픈소스 가속 기법으로, 이 셋이 합쳐져 이번 결과가 나온 거예요.
미니맥스 H3, 이번엔 속도로 화제
미니맥스 H3는 지난 8월 3일 오픈웨이트로 공개된 영상 생성 모델이에요. METAL LAB이 직접 확인한 바로는 영상과 32kHz 스테레오 오디오를 한 번의 추론에서 함께 뽑아내는 게 특징이고, 당시 RTX 4070 노트북에서 15초 분량 영상을 만드는 데 45분이 걸렸어요. 같은 달 8일에는 루마(Luma)가 자사 플랫폼 Luma Agents에도 H3를 탑재했다고 밝혔고요. 로컬 PC 실행, 클라우드 서비스 탑재에 이어 이번엔 서빙 가속까지, 한 달 사이 H3를 둘러싼 소식이 이어지고 있어요.
어떻게 8.7초 만에 만드나
영상 생성 모델은 보통 노이즈로 가득한 화면에서 시작해 디퓨전 트랜스포머(DiT) — 노이즈를 단계적으로 걷어내며 화면을 그리는 신경망 — 를 여러 차례 반복해 완성된 영상을 만들어요. vLLM 프로젝트가 공개한 자료를 보면, 이번 가속은 이 반복 횟수를 5개의 노이즈 강도 지점(시그마 포인트)에서 단 4번의 DiT 연산으로 줄이는 few-step 스케줄을 두 가지 방식으로 구현했어요.
첫 번째는 'Turbo LoRA' 방식이에요. LoRA — 모델 전체 대신 작은 덧댐 조각만 훈련하는 저비용 파인튜닝 — 를 이용해 기본 가중치(W)는 그대로 두고, A/B라는 작은 사이드카 조각을 요청이 들어올 때마다 골라 붙여요. 수식으로는 y=Wx+B(Ax)로 표현되고, DLO 구성을 쓰면 기본 블록은 스트리밍하고 A/B 버퍼만 가속기에 남겨 두는 식으로 동작해요.
두 번째는 FastVideo 팀이 낸 'FastH3 프리뷰'예요. 이쪽은 모델을 불러오는 시점에 가중치를 아예 하나로 합쳐요 — W*=W+BA+Δ라는 융합된 가중치를 샤딩 전에 미리 만들어 두고, 모든 요청이 이 고정된 4단계 가중치를 그대로 써요. 그만큼 빠르지만 요청마다 다른 어댑터로 바꿔 끼우는 건 안 되고, VSA 변형이나 오프로드도 아직 지원하지 않는다고 vLLM 프로젝트는 밝혔어요.
두 방식, 무엇이 같고 다른가
| 항목 | Turbo LoRA | FastH3 프리뷰 |
|---|---|---|
| 가중치 결합 시점 | 요청마다 (동적) | 모델 로드 시 (고정) |
| 서버 형태 | 범용 서버 + 사이드카 | 전용 서버 |
| 지원 모드 | FL2VA / T2VA | T2VA(고밀도)만 |
| 요청별 전환 | 가능 | 불가 |
| 오프로드 | DLO로 기본 블록 스트리밍 지원 | 미지원 |
이 표는 vLLM-Omni PR #6476(Turbo), #6550(Turbo+DLO), #6714(FastH3 프리뷰)에 각각 명시된 내용을 정리한 거예요. 두 방식 모두 목표는 같아요 — 4회 DiT 연산으로 영상을 완성하는 것. 다만 그 목표에 도달하는 경로에서 유연성과 속도를 서로 다르게 맞바꿨어요.
에디터의 시선
이번 벤치마크는 숫자 하나(8.7초)보다 그 숫자가 만들어진 방식에 더 눈여겨볼 대목이 있어요. 영상 생성 모델은 그동안 느려도 그림이 되면 된다는 인식이 강했는데, 서빙 레이어(vLLM-Omni)와 모델 레이어(FastH3)가 각각 다른 방식으로 4단계 압축을 구현해 실시간에 가까운 속도를 만들어냈어요. Turbo LoRA는 유연성을, FastH3는 속도를 택한 트레이드오프인데, 이 구도는 LLM 서빙에서 이미 익숙한 패턴이에요. 어댑터를 얼마나 유연하게 갈아 끼울 수 있느냐와 얼마나 빨리 응답하느냐는 늘 맞바꾸는 관계였고, 영상 생성이 이제 그 트레이드오프를 그대로 물려받은 거죠.
지난달 RTX 4070 노트북에서 15초 영상을 만드는 데 45분 걸렸던 걸 직접 확인했던 입장에서 보면, 이번 결과는 완전히 다른 체급의 이야기예요. 로컬 PC에서 도는 모델과 few-step 증류를 거쳐 서버급 인프라에 올라간 모델은 이제 속도 차이가 크게 벌어지고 있어요. 국내에서 영상 생성 파이프라인을 실무에 붙이려는 팀이라면, 오픈웨이트 모델을 그대로 로컬에 올릴지 아니면 이런 서빙 최적화가 적용된 엔드포인트를 쓸지부터 정하는 게 먼저예요 — 같은 모델이라도 서빙 방식에 따라 체감 속도가 완전히 달라지니까요.
FastH3 프리뷰가 아직 요청별 어댑터 전환과 오프로드를 지원하지 않는다는 점은 흠이 아니라 지금 단계의 사양으로 보는 게 맞아요. 전용 서버 하나로 고정된 형태를 먼저 검증하고 유연성은 다음 단계에서 채워 넣는 순서는 오픈소스 서빙 프로젝트에서 흔한 전개고요. 앞으로 몇 주 안에는 FastH3의 VSA 지원과 오프로드 대응이 추가되거나, 같은 few-step 압축 기법이 다른 오픈소스 영상 모델에도 이식되는 흐름이 나올 가능성이 커요.
댓글