
MiniMax H3 (Hailuo 3.0)를 Colab A100에서 실행했을 때, 문제가 된 것은 VRAM이 아니라 디스크와 RAM이었다
요약
멀티모달 영상 생성 모델인 MiniMax H3(Hailuo 3.0)를 Google Colab A100 환경에서 실행할 때 발생하는 리소스 병목 현상을 다룹니다. VRAM 부족보다 디스크와 RAM 용량이 더 큰 문제임을 지적하며, 모델 로드를 위한 양자화 및 오프로딩 전략을 설명합니다.
핵심 포인트
- MiniMax H3는 텍스트, 이미지, 영상, 음성을 처리하는 대규모 멀티모달 모델임
- 모델 크기가 매우 커서 A100 40GB에서도 양자화와 그룹 오프로딩이 필수적임
- 실행 시 VRAM보다 디스크 및 RAM 용량 부족이 주요 병목 지점으로 작용함
- diffusers 최신 기능을 사용하기 위해 git을 통한 직접 설치가 필요함
X에서 본 바이럴 게시물이 계기였습니다. "MiniMax H3, Colab의 L4에서 15초당 €0.23". 그럼 한번 해볼까 하는 가벼운 마음으로 시도했으나, 실제로 부딪힌 벽은 VRAM이 아니라 디스크와 RAM이었다는 기록입니다.
평소에는 IVYXON이라는 사이트에서 SEC 공시 데이터 등의 1차 정보를 사용한 미국 주식 실측 기사나 자체 제작 도구를 공개하고 있습니다. 이번에는 성격을 바꾸어, 실기(実機)에서 겪은 함정만을 기록한 기술 메모입니다.
MiniMax H3 (Hailuo 3.0) 란
- 정체는 Hailuo 3.0입니다. 텍스트, 이미지, 영상, 음성을 동일한 문맥에서 다루는 멀티모달 (Multimodal) 영상 생성 모델입니다. 2026-07-31에 API가 공개되었고, 2026-08-03에 오픈 웨이트 (Open-weight)화되었습니다.
- 공식 리포지토리: MiniMaxAI/MiniMax-H3
- 출력은 5~15초 @24fps입니다.
num_frames는17*n+5로 스냅(snap)되는 사양으로, 예를 들어 124 (n=7)라면 약 5.17초가 됩니다. 해상도는 768px 이상이며 32의 배수여야 합니다. 네이티브로 스테레오 음성을 동시에 생성합니다.guidance_scale이나 negative prompt는 없으며 (guidance가 내장됨), 이 점은 기존의 영상 생성 파이프라인을 다뤄본 적이 있다면 오히려 당혹스러울 수 있는 포인트였습니다. - 라이선스는 MiniMax H3 Community License입니다. 제외 지역은 EU, UK, 한국, 미국뿐이며, 일본은 대상이 아니므로 일반 라이선스로 이용할 수 있습니다. 상업적 이용도 연 매출 $20M 미만이라면 사전 승인이 필요하지 않았습니다 (LICENSE 원문에서 확인). - diffusers 대응은 PR #14355가 2026-08-05에 main으로 merge 되었으나, pip 안정판에는 아직 배포되지 않았습니다. git에서 직접 install 해야 합니다. 공식 문서(Official documentation)는 여기 있습니다.
pip install -q "git+https://github.com/huggingface/diffusers.git"
pip install -q -U transformers accelerate torchao huggingface_hub
pip install -q imageio imageio-ffmpeg soundfile av
av는 encode_video가 내부에서 import av를 하기 때문입니다. 여기서 막히면 에러 메시지가 저장 단계까지 나오지 않으므로, 처음부터 설치해 두는 것이 좋습니다.
애초에 모델이 너무 크다
MiniMax H3는 transformer 본체만으로 bf16 환산 61.7GB, 텍스트 인코더 (Text encoder, Qwen3-VL)도 62.1GB에 달합니다. A100 40GB로도 순수 로드(Load)만으로는 올릴 수 없습니다. 따라서 공식 문서에서 "24~32GB급 소비자용 카드용"으로 안내하고 있는 int8 양자화 (Quantization) + 그룹 오프로딩 (Group offloading) 레시피가 A100에서도 실질적으로 필수적입니다.
from diffusers import MiniMaxH3Transformer3DModel, ModularPipeline, TorchAoConfig
from diffusers.hooks import apply_group_offloading
from transformers import TorchAoConfig as TransformersTorchAoConfig, Qwen3VLForConditionalGeneration
...
로드에서 오프로딩까지의 순서도 지정된 대로 지켜야 합니다. from_pretrained (빈 파이프라인) → update_components (양자화된 모듈로 교체) → load_components (나머지 공유 컴포넌트 로드) → requires_grad_(False) → 그룹 오프로딩 순서입니다. 공식 문서에는 "양자화된 텐서는 autograd의 일부 경로를 처리할 수 없으므로, 스트리밍 오프로딩 전에 freeze가 필요하다"는 취지의 코멘트가 있으며, 이를 어기면 작동하지 않습니다.
여기까지는 "문서대로 하면 작동하는" 파트입니다. 실기에서 정말로 막혔던 것은 지금부터였습니다.
벽 1: 디스크가 먼저 죽는다
종량제 방식의 순수 A100 인스턴스는 디스크가 112.64GB밖에 없습니다. OS와 패키지 베이스만으로 약 47GB가 사용되고 있어, 실질적인 여유 공간은 약 66GB입니다.
transformer와 text_encoder를 동시에 디스크에 둘 필요는 없지만, 각각을 다운로드할 때 일시적으로 66GB급의 여유 공간이 필요하다는 점이 함정이었습니다. 첫 번째(transformer, 57.2GB) 다운로드는 통과하더라도, 두 번째(text_encoder) 다운로드 시 확실하게 디스크 부족 현상이 발생합니다. 5회 연속으로 같은 결과가 나왔으며, xet 경유든 HTTP 폴백(fallback)이든 차이가 없었습니다. Google Drive의 FUSE 마운트를 통해 다운로드 경로를 변경하는 회피 방법도 시도해 보았으나, 결국 로컬 디스크를 버퍼로 사용하기 때문에 무의미했습니다.
해결책은 아주 단순하게도, Colab Pro로 업그레이드하여 디스크를 235.7GB로 만드는 것이었습니다(커뮤니티의 실측치인 236GB와 거의 일치합니다).
벽 2: 이번에는 VRAM이 아니라 RAM이 죽는다
디스크 문제를 해결하고 진행했음에도 다음 셀에서 중단되었습니다.
pipe = ModularPipeline.from_pretrained(MODEL_ID)
pipe.update_components(transformer=transformer, text_encoder=text_encoder)
pipe.load_components(workflow="t2va", dtype=torch.bfloat16) # ← 여기서 크래시 발생
load_components 호출 시 시스템 RAM 83.5GB를 모두 사용하여 세션이 크래시되었습니다. VRAM이 아니라 시스템 메모리입니다. update_components에서 이미 등록했을 transformer를 load_components가 내부적으로 다시 로드하는 듯한 동작을 보여, RAM을 이중으로 소비하고 있을 가능성이 높다고 보고 있습니다(확인되지 않은 추측입니다). HuggingFace 포럼에도 "96GB RAM에서도 OOM(Out of Memory)이 발생했다"는 보고가 있었으며, 증상 면에서 일치했습니다.
해결책은 Colab의 런타임 설정에서 "하이 메모리(High-RAM)" 토글을 ON으로 설정하는 것이었습니다(Colab Pro에서만 선택 가능). 이를 통해 RAM 167.1GB, VRAM 80GB 사양의 인스턴스가 할당되어 문제가 해결되었습니다.
구동을 위한 최소 구성
결과적으로, 실제 환경에서 유일하게 끝까지 통과한 구성은 다음과 같습니다.
| 벽 | 증상 | 해결책 |
|---|---|---|
| 모델 크기 | transformer 61.7GB + text_encoder 62.1GB가 A100 40GB에도 다 올라가지 않음 | int8 양자화 (Quantization) + 그룹 오프로드 (Group Offload) |
| ... | load_components에서 83.5GB를 모두 사용하여 크래시 (VRAM 아님) | 런타임 "하이 메모리" ON (167.1GB) |
사전 준비 사항은 다음 4가지입니다.
- MiniMaxAI/MiniMax-H3에서 라이선스 동의 (Agree and access repository)
- HF의 Tokens 설정에서 read 권한 토큰을 발행하고, Colab의 Secrets에
HF_TOKEN으로 등록 - Colab Pro 이상 구독 (종량제만으로는 위의 이유로 완주할 수 없음)
- 런타임 유형에서 GPU: A100, "하이 메모리" 토글: ON 선택
구현 시 유효했던 기타 세세한 함정들
low_cpu_mem_usage=True: 공식 샘플은False를 사용하고 있지만, 이 환경에서는False로 설정할 경우 양자화와의 조합에서ValueError가 발생했습니다.True로 고정하여 해결했습니다.workflow="t2va": 텍스트 전용 생성 워크플로우를 지정하면transformer_ref/파티션을 다운로드하지 않으므로, 단순한 텍스트→비디오 용도로는 용량 면에서 유리합니다. 이미지로 시작/끝 프레임을 지정하는fl2va역시 동일한transformer/를 공유하므로 추가 로드 없이 사용할 수 있습니다.- 생성 결과의 키(key)는
videos,audio,sampling_rate세 가지입니다.encode_video
는 diffusers.utils.export_utils에서 import합니다.
생성해 보기
스모크 테스트 (Smoke Test)로서, 화질보다는 "에러 없이 끝까지 돌아가는가"를 우선한 설정으로 1개를 생성했습니다.
result = pipe(
prompt="A red fox trotting through a snowy forest, cinematic lighting",
num_frames=124, # 17*7+5 ≒ 5.17초 @24fps
...
0.88MB, 약 5초의 smoke_test_001.mp4가 생성되었습니다. 여기까지 확인되면 num_inference_steps=30,
height=768, width=1344 (공식 "trained" 해상도)로 올려서 화질을 확인하고 있습니다.
배치화하여 무인 운용하기
transformer + text_encoder 로드에만 15분 이상 걸리기 때문에, 컷마다 다시 읽어오는 설계는 할 수 없습니다. 그래서 로드는 세션 내에서 한 번만 수행하고, shot list (JSON)를 읽어 루프를 도는 무인 운용용 노트북을 별도로 만들었습니다.
shot list는 배열이며, 1컷당 최소한 id / prompt / seed를 지정합니다.
| 필드 | 필수 | 설명 |
|---|---|---|
id | ○ | 출력 파일명이 됨 (예: cut001 → cut001.mp4) |
prompt | ○ | 텍스트 프롬프트 (Text Prompt) |
seed | ○ | 재현성을 위한 고정 시드 (Fixed Seed) |
image / last_image | - | 시작/끝 프레임 지정 (fl2va). 생략 시 텍스트만 사용 |
duration_seconds / num_frames | - | 생략 시 약 5.17초 |
height / width | - | 생략 시 768/1344 |
배치 루프 (Batch Loop)는 출력 파일이 이미 존재하는 컷을 스킵합니다. Colab 세션은 끊길 수 있기 때문에, 이것이 없으면 재실행할 때마다 처음부터 다시 시작해야 합니다. 1컷이 실패하더라도 batch_errors.log에 기록하고 다음 컷으로 넘어가도록 하여, 무인 운용 중에 단 한 건의 실패로 전체가 멈추지 않도록 했습니다.
for i, shot in enumerate(shots):
output_path = os.path.join(OUTPUT_DIR, f"{shot['id']}.mp4")
if os.path.exists(output_path):
...
새로운 세션에서 파일 단독 실행도 확인을 마쳤습니다. GPU 할당 → pip install (44초) → HF 로그인 → Drive 마운트 (자동) → 모델 로드 (11분, transformer 57.2GB 다운로드 포함) → 배치 루프로 이어지는 과정이 에러 없이 완주되었습니다.
여기서 한 가지 부수적인 발견이 있었습니다. Colab Pro는 동시 활성 런타임 세션 수에 상한이 있어, 다른 노트북 (이번의 경우 PoC용 노트북)의 런타임이 살아있는 상태라면, 새로운 노트북의 런타임 할당이 "세션이 너무 많습니다"라며 거부됩니다. 여러 노트북을 오가야 할 경우에는 전환하기 전에 런타임을 끊어두어야 합니다.
음성 레퍼런스 (ref2va / omni-reference)는 아직 대응하지 않습니다. transformer_ref/ 파티션의 추가 로드가 필요하기 때문에, 필요해지는 시점에 확장할 예정입니다.
검토했으나 채택하지 않은 길: ComfyUI
MiniMax H3를 구동하는 방법으로는 ComfyUI를 경유하는 방법도 검토했습니다. 커뮤니티에서의 동작 보고는 이쪽이 더 많은 인상입니다. 이번에는 스크립트/배치를 통한 무인 운용을 우선시했기에 채택하지 않았지만, 막혔을 때의 대체 루트로서 기록해 둡니다.
요약
「Colab의 L4에서 15초당 €0.23」라는 숫자만 보면 가볍게 시도해 볼 수 있을 것 같지만, 실제로 구동하기까지의 장벽은 VRAM 측면의 양자화(Quantization)나 오프로드(Offload)보다, 디스크 용량과 시스템 RAM이라는 사소한 부분에 있었습니다. 두 가지 모두 "직접 실행해 보고 실제로 중단될 때까지는 깨닫지 못하는" 종류의 제약이라, 공식 문서의 레시피대로 구현하더라도 순수 종량제(Pay-as-you-go) 플랜으로는 완주할 수 없습니다. 같은 실수를 반복하는 분들의 시간을 단축하는 데 도움이 되기를 바랍니다.
평소에는 IVYXON이라는 사이트를 운영하고 있습니다. SEC EDGAR나 EDINET 등의 1차 정보에 기반하여 미국 주식 및 일본 주식을 실측하는 기사나, 직접 제작한 분석 툴을 공개하는 사이트입니다. 이번과 같은 "직접 해보며 알게 된 사실"을 다루는 태도는 공통적이므로, 관심이 있다면 한 번 둘러봐 주시기 바랍니다.
Discussion

AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기