arXiv:2603.04379 기반
Helios 영상 생성 AI,
14B인데 6GB로 돌아갑니다
결론부터 말씀드리면, Helios는 KV-cache도, 양자화도, sparse attention도 전혀 쓰지 않고 단일 H100에서 19.5 FPS를 달성한 오픈소스 영상 생성 모델입니다. 그리고 그룹 오프로딩을 켜면 VRAM 6GB짜리 GPU에서도 돌아갑니다. 14B 파라미터 모델 기준으로 이 조합은 기존 상식과 정면으로 어긋납니다.
Helios가 뭔지 30초 요약
Helios는 2026년 3월 4일 베이징대 PKU-YuanGroup과 ByteDance 연구팀이 공개한 오픈소스 영상 생성 모델입니다. 14B(140억) 파라미터 규모인데, 단일 NVIDIA H100 GPU에서 실시간(19.5 FPS)으로 최장 60초 분량의 영상을 생성합니다. (출처: arXiv:2603.04379, 2026.03.04)
텍스트→영상(T2V), 이미지→영상(I2V), 영상→영상(V2V) 세 가지 모드를 단일 아키텍처로 지원하고, 코드·가중치·학습 코드 전체가 Apache 2.0 라이선스로 공개돼 있어 상업적 이용도 가능합니다. Diffusers, vLLM, SGLang 같은 주요 인퍼런스 프레임워크는 출시 당일 지원됐습니다.
솔직히 말하면 처음엔 반신반의했습니다. 14B 모델이 H100 한 장에서 실시간으로 돌아간다는 게 기존 상식과 너무 달랐으니까요. 근거를 직접 논문에서 확인했고, 그 결과를 아래에 정리했습니다.
14B인데 6GB? — VRAM 숫자를 직접 따져봤습니다
14B 파라미터 모델을 bfloat16으로 올리면 단순 계산으로 약 28GB VRAM이 필요합니다. 그런데 Helios의 GitHub 공식 README는 그룹 오프로딩(Group Offloading)을 켜면 약 6GB로 실행 가능하다고 명시합니다. (출처: github.com/PKU-YuanGroup/Helios, 2026.03.08 업데이트 기준)
💡 공식 발표 수치와 실제 구동 조건을 함께 놓고 보니 이런 차이가 보였습니다
그룹 오프로딩은 사용하지 않는 레이어를 CPU 메모리로 내보내고 필요할 때만 GPU에 올리는 방식입니다. VRAM이 6GB로 줄어드는 대신 CPU↔GPU 전송 오버헤드가 생겨 추론 속도가 대폭 느려집니다. 6GB 수치는 속도를 포기한 조건에서 나온 것입니다.
실제로 Helios-Distilled가 19.5 FPS를 찍는 건 H100(80GB) 풀 메모리 상태에서입니다. 그룹 오프로딩 상태에서는 실시간 속도가 나오지 않습니다. 두 수치는 모두 사실이지만 동시에 성립하지는 않습니다. 대부분 기사가 이 부분을 뭉뚱그려서 “6GB로 실시간 생성”처럼 읽히는 게 문제입니다.
훈련 중에는 이야기가 다릅니다. 논문은 80GB H100 4장 안에 14B 모델 4개를 동시에 올릴 수 있다고 밝힙니다. 훈련 시 메모리 효율이 이 수준이라는 뜻이고, 실제 훈련은 H100 64~128장 클러스터에서 진행됐습니다. (출처: arXiv:2603.04379, p.5)
속도의 비밀 — 가속 기술 없이 어떻게 19.5 FPS가 나오는가
영상 생성 모델에서 추론 속도를 높이려면 보통 KV-cache, sparse attention, 양자화, TinyVAE 같은 기법을 쌓습니다. Helios는 이것들을 하나도 쓰지 않습니다. 논문 Abstract에 “without KV-cache, sparse/linear attention, or quantization”이라고 명시돼 있습니다. (출처: arXiv:2603.04379)
그 대신 속도를 훈련 파이프라인 안으로 끌어들였습니다. 핵심은 두 가지입니다. 첫째, Multi-Term Memory Patchification은 과거 프레임을 단기·중기·장기로 나눠 오래된 것일수록 더 강하게 압축합니다. 히스토리 토큰 수를 약 8배 줄이면서도 품질을 유지합니다. 둘째, Pyramid Unified Predictor Corrector는 확산 샘플링을 저해상도부터 시작해 점진적으로 해상도를 높이는 방식으로, 생성 세그먼트의 토큰 수를 약 2.3배 감소시킵니다.
Distilled 변형은 여기서 한 발 더 나아가 50스텝이었던 샘플링을 3스텝으로 줄입니다(Adversarial Hierarchical Distillation). 이 덕분에 19.5 FPS가 가능한 것입니다. 동급 Wan 2.1 14B가 5초짜리 영상을 A100에서 약 50분 걸려 만드는 것과 비교하면, Helios-Distilled는 이 작업을 수 초 안에 마칩니다. (출처: neurohive.io, arXiv:2603.04379 기준, “128× faster than base Wan 2.1”)
💡 기존 모델들이 추론 스택에 가속 기술을 외부에서 덧붙이는 방식이라면, Helios는 처음부터 “가속이 필요 없는 구조”를 만들기 위해 학습 과정 자체를 설계했습니다. 움직이는 부품이 적어지니 버그 포인트도 줄어듭니다.
다만 Flash Normalization과 Flash RoPE라는 커스텀 Triton 커널은 사용합니다. 이 두 가지만으로 추론 속도가 14.4%, 학습 속도가 14.5% 빨라집니다. 완전히 “아무것도 없이”는 아니고, 표준 가속 기법 없이라는 표현이 더 정확합니다.
긴 영상에서 무너지는 문제, Helios는 어떻게 버텼나
오토레그레시브 방식으로 영상을 청크 단위로 이어 붙이면 오류가 누적됩니다. 얼굴이 서서히 다른 사람으로 바뀌거나, 배경 색이 점점 변하거나, 동작이 무한 루프에 빠지는 식입니다. 논문은 이 현상을 포지션 시프트, 컬러 시프트, 복원 시프트 세 가지 유형으로 분류하고 각각에 대응하는 학습 전략을 도입했습니다. (출처: arXiv:2603.04379, Section 3.2)
Relative RoPE는 위치 인코딩 방식을 바꿨습니다. 기존 절대 위치 인덱스 대신, 히스토리 청크는 항상 0에서 시작하고 새 생성 세그먼트는 그 바로 뒤에 붙는 구조입니다. 영상이 아무리 길어져도 모델이 보는 “창”의 크기가 일정하게 유지됩니다. 이 덕분에 짧은 클립으로만 학습했어도 1440프레임(약 74초) 영상을 안정적으로 생성할 수 있습니다. First-Frame Anchor는 첫 번째 프레임을 끝까지 히스토리에 남겨둡니다. 색 열화는 거의 항상 첫 프레임에서 시작하지 않는다는 관찰에서 나온 발상입니다.
실험 결과, 1440프레임 장편 영상에서 Helios-Distilled 점수는 6.94로 2위인 Reward Forcing(6.88)을 앞섰습니다. 200명이 참여한 사용자 평가에서는 장편 영상 기준으로 70~92.5%, 단편 기준으로 56~99.2% 승률을 기록했습니다. (출처: arXiv:2603.04379, Table 2 & Table 3) 단순 수치로만 보면 경쟁 모델들을 상당히 앞서는 결과입니다.
세 가지 변형 모델 — 어떤 걸 써야 할까
Helios는 세 개의 가중치를 공개했고, 목적에 따라 선택이 달라집니다.
| 모델 | 샘플링 스텝 | 속도(H100) | 적합한 용도 |
|---|---|---|---|
| Helios-Base | 50스텝 | 느림 | 최고 품질, 최종 결과물 렌더링 |
| Helios-Mid | 중간 | 중간 | 품질·속도 균형, 중간 검토용 |
| Helios-Distilled | 3스텝 | 19.5 FPS | 프로토타입·빠른 시안, 실시간 인터랙티브 |
이 부분이 좀 아쉬웠습니다. Distilled는 50스텝을 3스텝으로 줄인 대가로 다양성과 세부 디테일에서 Base보다 뒤처집니다. “19.5 FPS”는 Distilled 기준이고, Base로 최고 품질을 원하면 50스텝의 컴퓨팅 비용을 그대로 감수해야 합니다. 두 모드의 속도 차이는 논문에 별도 수치로 공개되지 않았지만, 단순히 스텝 수 비율로 추정하면 Distilled 대비 약 17배 이상 느린 셈입니다.
또 Helios-Mid는 “중간 체크포인트”로, 논문 저자가 직접 “기대 품질을 충족하지 못할 수 있다”고 README에 적어뒀습니다. 중간 단계 버전이라 일반 사용 권장 목적은 아닙니다. (출처: github.com/PKU-YuanGroup/Helios, Model Download 섹션)
공식 발표문과 실제 사용 흐름을 같이 놓고 보니 이런 차이가 보였습니다
보도자료나 GitHub의 하이라이트만 보면 “H100 있으면 끝”처럼 읽힙니다. 하지만 실제 사용 흐름을 같이 놓고 보면 이야기가 달라집니다. 먼저 Helios는 호스팅 API가 없습니다. HuggingFace Spaces에 데모가 있고, 코드와 가중치는 공개돼 있지만, Make나 Zapier에 바로 연결할 수 있는 공식 SaaS API는 현재 존재하지 않습니다. (출처: coey.com, 2026.03.15 기준)
💡 논문 수치와 실제 하드웨어 접근성 사이의 간격
19.5 FPS는 H100 기준입니다. 그런데 H100은 현재 클라우드 시간당 비용이 약 3~5달러 수준입니다. RTX 4090(24GB VRAM)에서의 성능은 논문에 별도 수치가 없고, 커뮤니티 실험에서는 24GB 미만 VRAM 환경에서 영상 길이 제한이 걸린다는 보고가 있습니다. (출처: Facebook DeepNetGroup 게시물, 2026.03.12)
해상도도 현재 384×640(약 0.24MP)으로 고정돼 있습니다. 논문은 “계산 자원 제약으로 인해 모든 실험을 이 해상도로 제한했다”고 솔직하게 적습니다. (출처: arXiv:2603.04379, Limitations 섹션) 1080p나 4K 영상을 기대한다면 지금 당장은 불가능합니다.
반면 진짜 실용 포인트가 있습니다. Apache 2.0 라이선스라 상업적 프로젝트에 바로 쓸 수 있고, Diffusers 파이프라인으로 10줄도 안 되는 코드로 T2V를 돌릴 수 있습니다. ComfyUI 통합 노드는 출시 시점에 아직 공식 지원이 없지만, 커뮤니티에서 제작 중입니다. 오픈소스 영상 생성 생태계 역사로 보면 이런 부분은 보통 수주 안에 메워집니다.
자주 묻는 질문 5가지
마치며 — 지금 바로 쓸 수 있는 사람과 기다려야 하는 사람
Helios는 오픈소스 영상 생성 모델 중 속도와 영상 길이 두 가지를 동시에 밀어붙인 처음 시도입니다. 기존 가속 기법을 걷어내고 훈련 파이프라인에 효율을 심은 설계는 흥미롭고, 실제 벤치마크 수치도 경쟁 모델 대비 유의미하게 앞섭니다.
지금 바로 쓸 수 있는 경우는 H100 또는 그에 준하는 클라우드 GPU 접근 권한이 있고, Python·CUDA 환경 구성에 익숙하며, Apache 2.0 기반 상업적 프로젝트를 준비 중인 팀입니다. HuggingFace Spaces 데모는 누구나 설치 없이 시험해볼 수 있으니 먼저 거기서 결과물 품질을 확인해보는 게 빠릅니다.
기다리는 게 나은 경우도 있습니다. 384×640 이상의 해상도가 필요하거나, ComfyUI 같은 GUI 환경을 원하거나, 서비스 SLA가 필요한 팀이라면 생태계가 좀 더 무르익을 때까지 지켜보는 편이 현실적입니다. Helios가 얼마나 빠르게 발전할지는 커뮤니티 기여 속도에 달려 있습니다.
📎 본 포스팅 참고 자료
- Helios 공식 arXiv 논문 — https://arxiv.org/abs/2603.04379 (2026.03.04)
- Helios 공식 GitHub — https://github.com/PKU-YuanGroup/Helios (2026.03.20 최신 업데이트 기준)
- Helios HuggingFace Spaces 데모 — https://huggingface.co/spaces/BestWishYsh/Helios-14B-RealTime
- neurohive.io 기술 분석 — neurohive.io Helios 분석 (2026.03.11)
- coey.com 워크플로우 분석 — coey.com Helios 워크플로우 (2026.03.15)
※ 본 포스팅은 2026년 3월 21일 기준으로 작성되었습니다. Helios 프로젝트는 오픈소스 방식으로 활발히 업데이트되고 있으며, 본 포스팅 작성 이후 서비스 정책·UI·기능·성능 수치가 변경될 수 있습니다. 최신 정보는 공식 GitHub 및 arXiv 논문을 직접 확인해주세요.
댓글 남기기