gfx1151에서 MiniMax H3를 빠르게 돌리는 방법을 하나씩 재 봤습니다

2026-09-07 추가: 이 글에서 dense보다 느려서 뺐던 Sol-Attn은 당시의 custom Triton 구현입니다. 이후 comfy-kitchen에 들어온 네이티브 HIP Sol은 1344×768에서 생성 시간을 30% 줄였고 운영 기본값이 됐습니다. 후속 측정을 보세요. 아래 본문은 당시 기록입니다.

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 런타임도 시험했지만, 동작하는지와 품질과 속도를 따로 확인해 보니 이 조합을 넘지 못했습니다.

18.75%ROCm 7.2.1→10 동조건 단축 (768x448·124f)

3.59xLightX2V v1.1 4-step vs 정규 20-step

0.49%실크기 반복의 변동계수 (CV)

0.635cache 결과 SSIM (재현 기준 0.9985)

구성

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, AMDGPU auto

ROCm 7.2.1에서 10으로 올리자 768x448·124f·Turbo v1.0 4-step 조건에서 179.010초가 145.446초로 18.75% 줄었습니다. 짧은 시험에서는 오히려 느려졌기 때문에, ROCm 자체의 효과라기보다 긴 생성에서 스택 전체가 나아진 결과로 봅니다.

step distillation

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

608x352·39f warm 생성 시간낮을수록 좋음

정규 20-step

91.7초

LightX2V v1.1 4-step

25.6초

FastH3 dense 4-step

25.5초

Larry v4 EMA 6-step

33.6초

PDD 8-step

41.6초

Larry v4 EMA 8-step

41.9초

FastH3 dense와 LightX2V는 DiT를 평가하는 횟수가 같아서 속도가 거의 같습니다. FastH3 VSA는 fused sparse kernel과 함께 써야 이점이 나오는데, 당시 공개된 경로는 CUDA 위주였고 HIP에서는 O(T²) eager 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 비교에서 PyTorch cross attention보다 14.71% 빨랐고, 지금 스택에서도 HIP backend로 돌고 있습니다.

당시의 custom Triton Sol-Attn은 microprobe와 실제 17,353토큰 sparse 경로까지는 동작했지만, 1344x768·56f·4-step에서 dense CK보다 10.74% 느렸습니다. 참고로 RDNA4(gfx120x)용 커뮤니티 kernel은 Strix Halo(gfx1151)용이 아닙니다.

cache를 쓰면 결과물이 달라진다

경로	정규 20-step 시간	속도 향상	판정
FirstBlockCache Safe	63.271초	1.45x	미리보기에만 선택
FirstBlockCache Fast	59.793초	1.53x	근사 오차 증가
CacheDiT	57.254초	1.60x	근사, 선택 적용
Spectrum	60.947초	1.51x	근사, 선택 적용

같은 seed로 baseline을 두 번 돌리면 SSIM이 0.9985인데, cache나 forecast를 쓴 결과와 baseline 사이는 0.635~0.639였습니다. SSIM이 곧 눈으로 보는 품질은 아니지만, 원래 생기는 흔들림보다 생성 결과가 훨씬 많이 바뀐다는 뜻입니다. 최종본에는 cache를 쓰지 않습니다. 4-step LightX2V에서는 FirstBlockCache 적중이 0/4라 두 가지를 같이 켤 이유도 없었습니다.

메모리와 전용 런타임

INT8 video VAE는 warm GTT를 약 2.22GiB 줄였지만 FP16보다 빠르지는 않았습니다. 메모리가 빠듯한 큰 작업에서만 씁니다.

순수 HIP 런타임인 h3-hip.c의 공식 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배 오래 걸렸습니다. checkpoint 134.125GiB를 따로 둬야 하고 실행할 때마다 가중치를 다시 읽어야 해서 기본 서비스로 쓰지 않았습니다.

용도별 설정

용도	조합
일반 빠른 생성	CK + LightX2V v1.1 4-step + FP16 VAE
품질 비교	CK + PDD 8-step 또는 Larry v4 EMA 8-step
정규 20-step 미리보기	CK + FirstBlockCache Safe
정규 20-step 최종본	CK, cache/forecast 없음
큰 작업 메모리 절감	위 조합 + INT8 video VAE

H3의 AV latent는 일반 Tensor가 아니라 NestedTensor라서 코어 SaveLatent로 저장할 수 없습니다. 짧은 노트에 따로 적었습니다.

이 글은 128GB 미니PC 로컬 AI 시리즈의 한 편입니다.