RTX Pro 6000 Blackwell에서 MiniMax H3 가속 경로 비교

영상 생성 서버(Windows, RTX Pro 6000 Blackwell 96GB)에서 MiniMax H3를 빠르게 돌리는 방법 몇 가지를 쟀습니다. 8-step 터보 경로에 Triton Sol 패치를 넣으면 샘플링 시간이 22% 줄었고, FastH3 VSA 4-step으로 바꾸면 2.4배 빨라졌습니다. 다만 FastH3는 아직 텍스트→영상만 지원해서 다른 구성을 전부 대신하지는 못합니다.

측정 결과

T2VA 1344×768·121f, warm 상태의 샘플링 시간입니다.

구성	샘플링	비고
8-step 터보 + SolAttnPatch (Saganaki Triton)	50.4초	dense 대비 -22%
8-step 터보, 패치 없음 (전역 sage)	64.5초
8-step 터보 + 코어 "comfy kitchen attention"	64.9초	dense 백엔드, sage와 비슷
FastH3 VSA 4-step (DataFree-1300 int8)	22초	스텝당 -16%, 대부분 4-step 증류에서 온 이득

헷갈리기 쉬운 것이 하나 있습니다. 코어의 ModelAttentionBackend에 있는 "comfy kitchen attention"은 이 GPU에서 dense 백엔드로 동작해서 sage와 속도가 같습니다. 이름 때문에 sparse Sol attention으로 착각하기 쉬운데, 이걸로 바꾸면 Sol 패치로 얻던 22%를 잃습니다. 다른 곳에서 "더 빠르다"고 들은 설정은 우리 기계에서 다시 재 보고 반영하고 있습니다.

같은 VSA checkpoint를 dense로 강제로 돌리면 품질이 눈에 띄게 떨어졌습니다. sparse 방식으로 학습한 checkpoint는 sparse로 실행해야 합니다.

FastH3를 쓰려면 필요했던 것

처음에는 FastH3 VSA가 기본 구성으로 돌지 않아서 ComfyUI 코어에 PR #15958 패치를 넣고, comfy-kitchen 0.2.32와 전용 int8 checkpoint(22.9GB)를 따로 갖췄습니다.

2026-10-04 추가: 이후 ComfyUI 본류가 이 기능을 흡수했습니다. PR #15958은 다른 구현으로 대체됐고, 코어의 BlockSparseAttention 노드 하나가 Sol-Attn, top-k SLA, VSA 세 방식을 모두 다룹니다. ComfyUI v0.35.0부터 들어가 있어서 이 서버의 코어 패치는 제거했습니다. 이 기본 노드와 이전 패치 경로를 같은 조건으로 비교하는 일은 아직 남아 있습니다.

아직 텍스트→영상 전용

FastH3는 2026-09-04에 나온 프리뷰 v1 기준으로 T2VA만 지원합니다. 공식 문서에 "FL2VA and Ref2VA were not distilled"라고 적혀 있습니다. 첫·끝 프레임을 지정하는 FL2V나 참조 기반 R2V 구성은 계속 8-step 터보와 Sol 패치를 씁니다. 공식 v1은 diffusers 형식에 전용 런처를 쓰기 때문에 ComfyUI에서 쓰려면 커뮤니티 변환본이 나와야 합니다.

FastH3 V2와 NVFP4 (2026-10-04 추가)

이후 FastH3 8-Step V2를 기본 코어 노드만으로 돌리는 구성(BlockSparseAttention VSA, 고정 타임스텝, shift 10/3, CFG 1)을 만들었고, Blackwell의 FP4 연산을 쓰는 NVFP4 변환 가중치도 시험했습니다. 1344x768, 5초, warm 상태에서 인코딩까지 포함한 전체 작업 시간입니다.

구성	int8	NVFP4 (pruned)
정규 20-step	203.3초	180.4초 (-11%)
터보 LoRA 8-step	100.6초	90.2초 (-10%)
FastH3 V2 8-step	105.3초
832x448, 3초, 20-step	25.2초	25.1초 (차이 없음)

FastH3 V2는 터보 LoRA보다 빠르지 않았습니다(105.3초 대 100.6초). 4-step v1에서 본 2.4배 같은 차이는 없었고, 고른다면 속도가 아니라 품질이나 라이선스 때문입니다. V2도 여전히 T2VA 전용입니다.

NVFP4 변환본은 11.67GiB로 int8(31.7GiB)보다 작고, 추가 노드 없이 그대로 불러올 수 있었습니다. 큰 해상도에서는 10~11% 빨랐지만 작은 해상도에서는 차이가 없었습니다. 변환본 제작자가 같은 그래프로 낸 값에서는 최대 VRAM이 82.5GB에서 59.3GB로 28% 줄었습니다. 96GB 카드에서 int8이 82.5GB를 쓴다는 것은 긴 클립에서 시스템 RAM으로 넘치는 문턱에 가깝다는 뜻이라, 시간보다 이쪽 이득이 더 클 수 있습니다.

다만 이 변환본은 가지치기(pruned)도 함께 돼 있어서, 속도와 메모리 이득이 FP4 때문인지 가지치기 때문인지 나눌 수 없습니다. 같은 시드 두 건에서 피사체를 더 멀리 잡는 경향도 보였지만 두 건으로는 판단할 수 없습니다. 공개된 변환본이 FL2VA용 하나뿐이라 참조 영상 기반(R2V) 구성은 바꿀 수 없어서, 기본값은 int8로 두고 NVFP4는 선택지로만 남겼습니다.

측정하면서 생긴 일도 하나 적어 둡니다. VSA의 keep_percent를 20에서 10으로 낮추면 빠르다는 1회 측정을 믿고 "약 14% 빠름"이라고 안내했다가, 같은 조건 3회 중앙값을 내 보니 24.1초 대 24.1초로 차이가 없었습니다. 이 서버의 H3 측정은 회차 간 편차가 ±15% 정도라서, 지금은 3회 이상 반복한 중앙값만 쓰고, 첫 회차는 모델 로드가 섞이므로 따로 적고, 10% 미만 차이는 반복을 늘리기 전까지 차이 없음으로 적습니다.

다음에 재 볼 후보

아직 조사만 했고 측정은 하지 않은 것들입니다.

기술	내용	판단
VDN (Video Delta Net)	공식 하이브리드 attention(가까운 곳은 softmax, 먼 곳은 선형 delta) 포트. 단일 GPU 약 2.6x, 긴 영상에서 유리	가장 유력한 비교 후보
Spectrum	학습 없이 스텝을 건너뛰는 방식, 20-step 기준 약 1.8x. 근사라서 같은 seed여도 결과가 달라짐	풀스텝 경로에서 선택 적용
PDD LoRA	8-step 가속 (shift 12/3 레시피)	파일은 준비, 코어 릴리스 대기

운영하면서 알게 된 것

이 GPU는 WDDM 모드라 VRAM이 넘치면 시스템 RAM으로 넘어갑니다. VRAM이 부족해도 에러가 나지 않고 RAM을 조용히 잡아먹기 때문에 96GB라고 안심할 수 없습니다.

픽셀 단위 업스케일에 필요한 RAM은 frames×W×H×scale²×12B입니다. 4배로 10초짜리를 올리면 72GB가 필요하고, 실제로 RAM이 바닥나 서버가 멈춘 일이 있었습니다. 그 뒤 2배, 15초로 상한을 뒀습니다. 이 사고는 별도 글에 정리했습니다.

같은 모델을 AMD gfx1151(Ryzen AI Max+ 395)에서 잰 결과는 별도 글에, 두 기기 비교는 비교 글에 있습니다.