MiniMax H3 GPU 최적화, Jev와 Adaptive VSA 분석

9월 15일, 샌프란시스코의 AI 스타트업 TypeSafe AI가 스텔스 모드를 벗고 첫 공개 모델 Jev를 내놨습니다. Jev는 텍스트를 새로 쓰는 대신 미리 정의한 질문에 답만 돌려주는 "결정 모델"입니다. 개발자가 상태 데이터와 함께 예/아니오, 선택지 중 하나, 정해둔 척도 위의 위치처럼 정형화된 질문을 던지면 70에서 500밀리초 사이에 확률값을 붙인 답이 나옵니다. 가격도 화제였습니다. 입력 토큰 100만 개당 0.042달러, 출력은 무료입니다.

그런데 최근 GPU 커뮤니티를 둘러보다 이름이 똑같은 Jev를 하나 더 만났습니다. TypeSafe의 그 Jev와는 전혀 관계가 없습니다. 오픈소스 프로젝트 ComfyUI-MiniMax-H3-W4A4-VSA의 실험 브랜치에 등장하는데, 여기서 Jev는 "Jittered Entropy-based Variable sparse attention"의 약자입니다. 프로젝트 문서에는 "TypeSafe의 Jev 라이브러리와는 무관하다"는 안내까지 따로 붙어 있습니다. 같은 시기에 같은 이름을 각자 다른 의미로 붙인 우연이 재미있어서, RTX 4070 12GB 한 장에 이 두 번째 Jev를 직접 설치하고 실측까지 해봤습니다.

무거운 영상 생성 모델을 가볍게 만드는 두 겹의 압축

이 프로젝트가 최적화 대상으로 삼은 모델은 MiniMax H3입니다. 이미지 한 장을 넣으면 그 속 피사체가 움직이는 영상을 만들어주는 Ref2VA 모델이고, 고해상도 영상을 다루는 만큼 어텐션 연산이 무겁기로 유명합니다.

이 무게를 덜어내려고 프로젝트는 압축 기법 두 가지를 겹쳐 씁니다. 하나는 W4A4, 모델의 가중치와 중간 연산값을 모두 4비트로 낮춰 메모리 사용량과 연산량을 한꺼번에 줄이는 양자화 방식입니다. 다른 하나는 VSA입니다. 어텐션 계산에서 모든 토큰 쌍을 훑는 대신 중요한 토큰만 골라 계산합니다. 5%만 남기면 연산량이 95% 줄어듭니다.

설치: 사전 변환이 왜 필요한가

W4A4는 런타임에 즉석으로 변환할 수도 있지만, 이 프로젝트는 FC1 레이어 50개를 미리 4비트로 변환해두는 방식을 기본값으로 삼습니다. 설치는 세 단계입니다.

# 1. GPU 호환성 확인 (SM8x, 즉 Ampere/Ada 세대만 검증됨)
python convert.py --comfy-root ComfyUI --check --gpu 0

# 2. FC1 레이어 50개를 4비트로 사전 변환
python convert.py \
  --comfy-root ComfyUI \
  --model "minimax_h3_fused_refdelta_r1024_turbo8_mystic07_int8_convrot.safetensors" \
  --gate "fasth3_vsa_gate.safetensors" \
  --output "ComfyUI\models\h3_preconverted\fc1_gate" \
  --gpu 0

# 3. Windows라면 위 과정을 한 번에 처리하는 스크립트도 있다
setup.bat -ComfyRoot "C:\ComfyUI_windows_portable\ComfyUI"

변환이 끝나면 manifest.json과 SHA-256 체크섬이 함께 생성됩니다. 사전 변환 단계가 왜 필요한지는 뒤의 실측에서 드러납니다. 같은 W4A4+VSA 조합이라도 미리 변환해두느냐, 매번 즉석에서 변환하느냐에 따라 처리 시간이 30%나 벌어지기 때문입니다.

ComfyUI를 재시작한 뒤 워크플로우(H3_Streaming_v2.json)를 드래그 앤 드롭하고, 참조 이미지 3장(전신/상반신/얼굴)을 넣고 Queue Prompt를 누르면 생성이 시작됩니다. 실행 옵션에는 --disable-comfy-compiler를 추가로 붙이는 걸 권장합니다.

고정 비율을 버리고 단계마다 자동 조절하는 Jev

문제는 이 5%라는 비율(keep_percent)입니다. 고정값으로 두면 영상 생성 과정의 모든 단계에 똑같은 비율이 걸립니다. 생성 초반 단계와 후반 단계가 요구하는 정밀도는 서로 다릅니다. Jev는 여기서 엔트로피(정보량)를 기준으로 어느 토큰이 중요한지 그때그때 판단해 보존 비율을 동적으로 조절합니다. 구현을 공개된 문서 수준에서 개념만 옮기면 이런 느낌입니다.

def jev_adaptive_keep_percent(token_logits, step, total_steps, base_percent=5):
    entropy = compute_entropy(token_logits)  # 정보량이 높을수록 "중요한" 토큰
    # 생성 초반(디테일이 아직 안 잡힌 단계)은 적게,
    # 후반(디테일을 다듬는 단계)은 더 많이 보존한다
    stage_weight = step / total_steps
    keep_percent = base_percent * (0.6 + 0.8 * stage_weight)
    return select_top_entropy_tokens(token_logits, entropy, keep_percent)

이 브랜치가 추가로 실험하는 Adaptive VSA는 한 발 더 나아갑니다. 고정된 keep_percent 대신 각 생성 단계마다 최적의 보존 비율을 자동으로 골라, 초반에는 더 적게 후반에는 더 많이 처리합니다. 조절은 ComfyUI 노드 그래프에서 H3V2StreamingVSAPatch(고정 비율)와 H3V2JevAdaptiveVSAPatch(Jev 기반 자동 조절) 중 어떤 패치 노드를 물리느냐로 갈립니다. keep_percent 값 자체는 재변환 없이 바로 바꿀 수 있습니다.

값	의미	연산 감소
5 (기본값)	5% 유지	95% 감소
10	10% 유지	90% 감소
20	20% 유지	80% 감소

RTX 4070 12GB 한 장으로 돌린 실측 결과

2026년 9월 20일 기준 RTX 4070 12GB 한 장에서 832×1408 해상도, 124프레임, 4스텝, keep_percent 5% 설정으로 측정한 값입니다.

방식	처리 시간
기존 INT8	168.44초
W4A4 + VSA (사전 변환)	149.70초
W4A4 런타임 변환	213.28초

사전에 변환해둔 W4A4+VSA 조합이 기존 INT8보다 약 11% 빨랐습니다. 앞서 짚었던 "왜 사전 변환이 필요한가"의 답도 이 표에 있습니다. 변환을 매번 실행 시점에 처리하면 오히려 30% 느려집니다. 모델 로드까지 포함한 전체 생성 시간은 209.23초, GPU 메모리 최대 사용량은 11,479MiB로 12GB 카드의 한계 안에 들어왔습니다.

12GB 카드가 감당하는 범위

MiniMax H3 같은 무거운 Ref2VA 모델을 풀 정밀도로 돌리려면 보통 데이터센터급 GPU와 훨씬 큰 VRAM이 필요합니다. W4A4 양자화와 VSA 희소 어텐션에 Jev의 동적 조절까지 더하면 12GB급 소비자용 GPU 한 장으로도 같은 작업이 돌아갑니다. 추가로 필요한 디스크 공간도 사전 변환된 가중치 기준 5.8GB 남짓입니다. 클라우드 GPU 인스턴스를 매번 새로 띄우기 전에 이미 가진 카드에 먼저 설치해 검증해볼 수 있습니다.

같은 이름을 쓰는 두 프로젝트가 전혀 다른 문제를 풀고 있는 건 사소한 우연입니다. 그래도 그 우연 덕분에 직접 설치해 돌려본 두 번째 Jev는 GPU 비용을 아끼려는 쪽이라면 한 번 시도해볼 만했습니다.