Helios: 모든 지름길을 거부한 실시간 장편 비디오 생성 모델

나는 비디오 생성 모델에 필요하다고 가정해온 것들의 정신적 목록을 유지해왔다: 속도를 위한 KV-캐시, 메모리를 위한 희소 어텐션, 드리프트 방지를 위한 키프레임 샘플링. PKU-YuanGroup의 Helios는 이 모든 것을 버렸다 — 그러면서도 단일 H100에서 19.5 FPS를 달성한다. 이 모순이 내가 스크롤을 멈추게 만든 이유다.

저는 Dora입니다. 지난 며칠 동안 Helios 논문과 레포지토리를 읽고, 로컬에서 실행할 수 있는 것들을 실행해보면서, 기존 통념이 불가능하다고 말하는데 이 접근 방식이 왜 작동하는지 이해하려 했습니다. 이것은 벤치마크 리뷰가 아닙니다. 오히려 “혁신적”이라는 주장에 충분히 데여서 증거를 원하는 누군가의 메모 모음에 가깝습니다.

Helios가 실제로 무엇인가

Helios는 청크당 33프레임을 생성하는 자기회귀 비디오 생성 모델로, 청크들을 연결해 분 단위의 영상을 만들어냅니다 — 24 FPS에서 최대 1,452프레임, 즉 약 60초의 연속 영상입니다.

그것만으로는 놀라운 일이 아닙니다. 특이한 것은 사용하지 않는 것들의 목록입니다:

• KV-캐시 없음
• 인과적 마스킹 없음
• 희소 또는 선형 어텐션 없음
• TinyVAE 없음
• 점진적 노이즈 스케줄 없음
• 양자화 없음
• 셀프-포싱, 에러-뱅크, 키프레임 샘플링 없음 (표준 안티-드리프팅 툴킷)

이 목록을 읽는 것은 누군가가 엔진 없이 달리는 자동차를 묘사하는 것 같았습니다. 저 기법들 하나하나가 존재하는 이유가 있습니다 — 비디오 생성은 비싸고, 메모리를 많이 쓰며, 긴 시퀀스에서 품질이 저하되기 쉽기 때문입니다. Helios는 이 모든 것을 우회하면서도 실시간 추론을 달성합니다. 문제는 그것이 작동하냐가 아닙니다 — 데모들이 공개되어 있습니다 — 而是 어떻게 작동하냐입니다.

3단계 훈련 파이프라인

Helios는 각 훈련 단계에 해당하는 세 가지 모델 변형을 제공합니다. 단계를 이해하면 설계 논리를 파악하는 데 도움이 됩니다.

1단계: Helios-Base

기반이 되는 모델. 핵심 아키텍처 혁신이 자리 잡는 곳입니다:

• 통합 히스토리 인젝션 — 모델이 일반적인 오류 누적 패널티 없이 이전 청크를 조건으로 삼습니다
• 쉬운 안티-드리프팅 — 대부분의 자기회귀 비디오 모델이 의존하는 추론 시간 해킹(셀프-포싱, 에러-뱅크)을 대체하는 훈련 시간 전략
• 멀티-텀 메모리 패치화 — 긴 시간적 컨텍스트 처리에 대한 메모리 효율적 접근법

Helios-Base는 표준 분류기-프리 가이던스와 함께 v-prediction을 사용합니다. 세 변형 중 가장 높은 원시 품질을 생성하지만, 추론 시간에 가장 무겁습니다 — 청크당 50번의 디퓨전 스텝.

2단계: Helios-Mid

토큰 압축을 위한 피라미드 통합 예측기-교정기를 도입하는 중간 체크포인트입니다. 이 단계에서 모델이 미미한 품질을 의미 있는 속도 향상과 교환하기 시작합니다. CFG-Zero*를 사용하여 추론 중 무조건적 모델 평가의 필요성을 제거합니다.

디퓨전 모델을 다뤄봤다면, CFG가 일반적으로 컴퓨팅을 두 배로 늘린다는 것을 알 것입니다 — 프롬프트를 사용해 한 번, 사용하지 않고 한 번, 스텝마다 두 번 모델을 실행하기 때문입니다. 그 요구 사항을 제거하는 것은 상당한 효율성 향상입니다.

3단계: Helios-Distilled

최종 변형은 적대적 계층적 증류를 사용해 50번의 디퓨전 스텝을 3번으로 압축합니다. v-prediction에서 커스텀 스케줄러(HeliosDMDScheduler)를 사용한 x0-prediction으로 전환하고 CFG 요구 사항을 완전히 버립니다.

19.5 FPS를 달성하는 변형이 바로 이것입니다. 3번의 스텝, CFG 없음, 가속 트릭 없음 — 단지 처음부터 제대로 하도록 훈련된 모델.

”지름길 없음” 접근법이 중요한 이유

비디오 생성에서 대부분의 가속 작업은 부가적입니다. 모델을 만들면 너무 느리고, 그래서 KV-캐시를 붙입니다. 여전히 메모리가 너무 많이 필요하면, 희소 어텐션을 추가합니다. 긴 시퀀스에서 품질이 드리프트하면, 키프레임 샘플링을 추가합니다. 각 수정은 자체적인 실패 모드와 복잡성을 도입합니다.

Helios는 반대 경로를 취합니다: 기반 모델을 충분히 효율적으로 만들어 추가 요소가 필요 없게 합니다. 훈련 파이프라인이 추론 시간 트릭이 보통 처리하는 무거운 작업을 담당합니다.

여기서 쉽게 놓칠 수 있는 실질적인 결과가 있습니다. 움직이는 부품이 적을수록 고장 나는 것도 적습니다. KV-캐시 손상 문제를 디버깅하거나 희소 어텐션이 특정 프레임 경계에서 아티팩트를 만드는 것을 본 적이 있다면, 그 시스템들이 부과하는 비용을 알 것입니다. Helios는 그 비용을 지불하지 않습니다.

메모리 이야기도 마찬가지로 인상적입니다. 논문은 이미지 디퓨전 규모의 배치 크기를 사용해 훈련 중 80 GB GPU 메모리 내에 140억 파라미터 모델 4개를 넣을 수 있다고 주장합니다. 이는 보통 방대한 리소스 사용량의 공격적인 압축입니다.

할 수 있는 것

Helios는 세 가지 변형 모두에서 네 가지 생성 모드를 지원합니다:

• 텍스트-to-비디오 — 프롬프트 입력, 비디오 출력
• 이미지-to-비디오 — 첫 번째 프레임과 프롬프트
• 비디오-to-비디오 — 스타일 전송, 리타이밍, 수정
• 인터랙티브 모드 — 반복적 정제

프레임 계산은 구체적입니다: 청크당 33프레임의 배수로 작업합니다. 약 30초를 원한다면? 22 청크 = 726프레임. 1분? 44 청크 = 1,452프레임. 청크 경계는 자기회귀 핸드오프가 발생하는 곳이며, 제가 본 데모들에서 이음새는 놀라울 정도로 깔끔합니다.

마지막 포인트는 강조할 가치가 있습니다. 자기회귀 비디오 모델은 보통 청크 경계에서 최악의 동작을 보입니다 — 모션 끊김, 색상 변화, 객체 드리프트. “쉬운 안티-드리프팅” 훈련 전략이 이 문제를 실질적으로 해결하는 것 같지만, 문제가 해결되었다고 선언하기 전에 더 다양한 테스트 케이스를 보고 싶습니다.

통합과 생태계

Helios는 이미 여러 추론 백엔드를 지원합니다:

• Hugging Face Diffusers — ModularPipeline 통합
• vLLM-Omni — 단계 기반 그래프 아키텍처를 사용한 분리된 서빙
• SGLang-Diffusion — 최적화된 커널을 사용한 통합 파이프라인
• Ascend NPU — Day-0 하드웨어 지원 (Ascend에서 ~10 FPS)

Diffusers 통합이 가장 접근하기 쉽습니다. vLLM-Omni 경로는 서로 다른 하드웨어에서 프리필과 디코드 단계를 분리하고 싶은 프로덕션 배포에 흥미롭습니다. SGLang-Diffusion은 실시간 애플리케이션을 가능하게 하는 배치 처리된 파이프라인 서빙을 위해 설계된 미래 지향적 옵션처럼 느껴집니다.

Ascend NPU 지원은 전략적 신호입니다. 비-NVIDIA 하드웨어에 대한 Day-0 지원은 이것이 나중에 생각한 것이 아님을 시사합니다. Ascend에서 ~10 FPS로 H100 경로보다 느리지만 많은 애플리케이션에서 여전히 사용 가능합니다.

HeliosBench

팀은 실시간 장편 비디오 생성을 평가하기 위해 특별히 설계된 자체 벤치마크 HeliosBench를 구축했습니다. 이것은 주목할 가치가 있는데, 기존 비디오 벤치마크 대부분이 짧은 클립(4–16초)에 집중하며 분 단위 길이에서 나타나는 실패 모드를 포착하지 못하기 때문입니다: 시간적 드리프트, 모션 저하, 객체 지속성 실패.

목적에 맞게 제작된 벤치마크가 객관성을 보장하지는 않지만, 적어도 올바른 것을 측정하고 있다는 의미입니다. HeliosBench를 사용한 독립적인 평가를 통해 방법론을 검증하고 싶습니다.

여전히 생각하고 있는 것

극단에서의 품질. 33프레임 청크 설계는 우아하지만, 44번의 연속 자기회귀 스텝은 누적 오류의 기회가 많습니다. 데모들은 깔끔해 보이지만, 데모는 항상 깔끔해 보입니다. 적대적 프롬프트를 보고 싶습니다 — 복잡한 카메라 모션, 많은 상호작용 객체, 1분 전체에 걸친 극적인 조명 변화.

증류의 트레이드오프. 50 스텝에서 3으로 가는 것은 공격적입니다. 증류된 모델은 일반적으로 속도를 위해 다양성과 세밀한 디테일을 희생합니다. Helios-Base 변형이 존재하는 이유가 있습니다 — 속도보다 품질이 중요할 때 17배의 컴퓨팅을 지불합니다. 두 운영 지점 사이에는 넓은 간격이 있습니다.

생태계 성숙도. 모델은 오픈소스(Apache 2.0)이며, 이것은 훌륭합니다. 하지만 오픈소스 비디오 모델이 실용적이 되려면 커뮤니티 툴링이 필요합니다 — ComfyUI 노드, 파인튜닝을 위한 훈련 스크립트, LoRA 지원. 그 생태계가 발전하는 데는 시간이 걸리며, 지금 Helios는 완전히 새로운 모델입니다.

하드웨어 요구 사항. H100에서의 실시간 처리는 인상적입니다. 하지만 H100이 대부분의 사람들 책상에 놀고 있는 것은 아닙니다. 많은 사용자에게 더 관련성 있는 질문은: 4090에서의 경험은 어떤가? A100에서는? 논문은 H100과 Ascend 성능에 대해 명확합니다 — 하드웨어의 긴 꼬리에 대해서는 덜 명확합니다.

이것이 눈에 띄는 이유

지난 1년 동안 많은 비디오 생성 발표를 봐왔습니다. 대부분은 점진적입니다: 더 나은 FID 점수, 약간 더 긴 클립, 미미하게 빠른 추론. Helios는 다르게 느껴집니다. 내가 내재화했다는 것을 깨닫지 못했던 가정에 도전하기 때문입니다 — 실시간 장편 비디오 생성은 서로 위에 쌓인 추론 최적화의 탑을 필요로 한다는 가정.

Helios가 제안하는 답은: 그냥 모델을 더 잘 훈련시키면 어떨까? 복잡성을 추론 스택이 아닌 훈련 파이프라인으로 밀어 넣는 것. 사후에 효율성을 덧붙이는 것이 아니라 모델 자체를 본질적으로 효율적으로 만드는 것.

그 접근법이 확장되고, 일반화되고, 프로덕션 워크로드와의 접촉에서 살아남는지는 열린 질문입니다. 하지만 방향은 설득력 있습니다. 더 적은 움직이는 부품, 더 깔끔한 아키텍처, 그리고 스스로를 증명하는 성능 수치.

코드와 가중치는 GitHub에 있습니다. Apache 2.0. H100과 오후 시간이 있다면, 살펴볼 가치가 있습니다.