MiniMax H3 를 gfx1151 에서 빠르게 — 가속 경로 전수 실측
step distillation, attention, cache, 전용 HIP runtime 까지 전수 실측해 ROCm 10 + CK + LightX2V 4-step 을 기본 경로로 정한 과정. cache 의 품질 비용도 SSIM 으로 쟀다.
Ryzen AI Max+ 395 / Radeon 8060S (gfx1151) 에서 MiniMax H3 의 가장 실용적인 경로는
ROCm 10 + comfy-kitchen CK attention + LightX2V v1.1 4-step 이었습니다. 전용
sparse attention, cache/forecast, 순수 HIP runtime 은 모두 동작 여부와 품질·속도를
따로 확인해야 했고, 결과적으로 기본 경로를 이기지 못했습니다.
기준 스택
- ROCm 10, Python 3.12.3, PyTorch 2.13
- ComfyUI 0.34.0, comfy-kitchen CK attention
- pruned INT8 ConvRot FL2VA, Qwen3-VL NVFP4 AWQ
- FP16 video VAE, FP32 audio VAE
- CPU
power-saver, AMDGPUauto
ROCm 7.2.1→10 의 768x448·124f·Turbo v1.0 4-step 동조건은 179.010→145.446초로 18.75% 짧아졌습니다. 짧은 smoke 는 반대로 느려졌으므로, 긴 실제 생성에서의 스택 전체 이득으로만 해석합니다.
step distillation — 4-step 이 3.6배
608x352·39f 공통 작업의 warm 결과입니다.
| 경로 | 설정 | 시간 | 정규 20-step 대비 |
|---|---|---|---|
| 정규 | 20-step | 91.722초 | 1.00x |
| LightX2V v1.1 | 4-step | 25.574초 | 3.59x |
| FastH3 dense | 4-step | 25.492초 | 3.60x |
| PDD | 8-step | 41.611초 | 2.20x |
| Larry v4 EMA | 6-step | 33.552초 | 2.73x |
| Larry v4 EMA | 8-step | 41.918초 | 2.19x |
FastH3 dense 와 LightX2V 는 DiT 평가 횟수가 같아 사실상 동률입니다. FastH3 VSA 의 핵심 이점은 fused sparse kernel 과 결합할 때 나오는데, 당시 공개 경로는 CUDA 중심이고 HIP 에서는 eager O(T²) fallback 이었습니다. 그래서 검증된 LightX2V 를 기본값으로 유지했습니다. 실제 크기 반복에서는 LightX2V v1.1 4-step 이 768x448·124f 평균 144.545초 (CV 0.49%), 1344x768·39f 평균 135.696초 (CV 0.32%) 였습니다.
attention
- CK attention 은 과거 768x448·124f A/B 에서 PyTorch cross attention 보다 14.71% 짧았고, 현재 스택에서도 HIP backend 사용을 확인했습니다.
- ROCm Sol-Attn 은 microprobe 와 실제 17,353-token sparse path 까지 동작했지만, 1344x768·56f·4-step 에서 dense CK 보다 10.74% 느렸습니다.
gfx120xRDNA4 용 community kernel 을gfx1151Strix Halo 용으로 간주하면 안 됩니다.
cache 는 빠르지만 결과물이 달라진다
| 경로 | 정규 20-step 시간 | 속도 향상 | 판정 |
|---|---|---|---|
| FirstBlockCache Safe | 63.271초 | 1.45x | preview opt-in |
| FirstBlockCache Fast | 59.793초 | 1.53x | 근사 오차 증가 |
| CacheDiT | 57.254초 | 1.60x | 근사 opt-in |
| Spectrum | 60.947초 | 1.51x | 근사 opt-in |
동일 seed 의 baseline 반복 SSIM 이 0.9985 인데, cache/forecast 결과와 baseline 의 SSIM 은 약 0.635~0.639 였습니다. 생성 영상에서 SSIM 이 곧 지각 품질은 아니지만, 자연 변동보다 생성 궤적 자체가 크게 달라진다는 근거입니다. 최종본 기본값에는 cache 를 쓰지 않습니다. 4-step LightX2V 에서는 FBC cache hit 가 0/4 이라 두 가속을 겹칠 실익도 없었습니다.
메모리와 전용 runtime
INT8 video VAE 는 warm GTT 를 약 2.22GiB 줄였지만 FP16 보다 빠르지는 않아, 큰 작업의 메모리 옵션으로만 씁니다.
순수 HIP runtime(h3-hip.c)의 official BF16 경로는 exact E2E 평균 171.270초,
45-layer/reuse-2 fast 평균 111.845초였습니다. fast 는 자체 exact 보다 1.53배 빨랐지만
ComfyUI 정규 20-step (91.722초) 보다 21.94% 느리고 LightX2V 4-step 의 4.37배입니다.
134.125GiB 추가 checkpoint 와 매 실행 weight I/O 도 필요해 기본 서비스로 채택하지
않았습니다.
운영 권장
| 용도 | 조합 |
|---|---|
| 일반 빠른 생성 | CK + LightX2V v1.1 4-step + FP16 VAE |
| 품질 비교 | CK + PDD 8-step 또는 Larry v4 EMA 8-step |
| 정규 20-step preview | CK + FirstBlockCache Safe |
| 정규 20-step 최종본 | CK, cache/forecast 없음 |
| 큰 작업 메모리 절감 | 위 조합 + INT8 video VAE |
덧붙여 H3 의 AV latent 는 일반 Tensor 가 아닌 NestedTensor 라 코어 SaveLatent 로
바로 저장할 수 없는 별도의 제약이 있습니다 —
짧은 노트로 정리했습니다.
이 글은 128GB 미니PC 로컬 AI 시리즈의 각론입니다.