128GB 미니PC에서 로컬 AI 모델을 고르는 기준

GMKtec EVO-X2는 Ryzen AI Max+ 395와 Radeon 8060S(gfx1151), 128GB 통합 메모리를 쓰는 미니PC입니다. 2026년 8~9월에 이 기계에 모델 네 가지를 설치해 운영했고, 이 글은 그때 정한 선택 기준입니다. 모델별 측정 과정은 각론 글에 따로 있습니다.

아래 표는 설치한 조합끼리의 운영 비교입니다. 입력과 출력 길이, 런타임, 양자화가 행마다 달라서 tok/s를 모델 성능 순위로 읽으면 안 됩니다.

설치한 조합

경로	상주 규모	검증 context	관측 속도	맞는 용도
DwarfStar4 / DeepSeek V4 Flash 0731 Q2	model 80.76GiB, 계획 약 87.82GiB	320K	짧은 decode 16.02 tok/s, 실제 agent 가중 13.35 tok/s	긴 text 세션, SSD prefix 저장
Qwen3.8 Flash Next Q4_K_XL	projector 포함 약 104.53GiB	128K	짧은 21.0 tok/s, 실제 소설/게임 12.06/12.56 tok/s	coding, 도구를 많이 쓰는 agent, 긴 출력
DeepSeek V4 Vision IQ2_XXS	model+projector 약 79.71GiB	320K	짧은 text 14.14, vision 14.88 tok/s	단일 이미지+text 실험, 큰 context
MiniMax H3	최신 측정 GTT 약 39.1~43.1GiB (해상도·경로별)	영상 latent	4-step 기준 Dense 23.97초(608×352·39f), HIP Sol 117.41초(768×448·124f)	영상·오디오 생성

같은 짧은 프롬프트에서 Qwen Q4_K_XL이 DS4 Q2보다 약 23% 빨랐습니다. 이것도 지금 설치한 두 조합의 차이이고, 원본 모델의 우열로 볼 근거는 없습니다.

작업별로 띄우는 것

긴 text 세션: DwarfStar4

320K context를 받고, KV checkpoint를 SSD에 저장해 둘 수 있습니다. 활성 KV를 SSD에서 읽어 계산하는 방식은 아니고, 재시작하거나 세션을 바꿀 때 prefix를 다시 처리하는 시간을 줄여 주는 기능입니다. 실제 40~80K 구간 decode는 약 12.66 tok/s였습니다. 자세한 내용은 DeepSeek V4 Flash 320K 운영 기록에 있습니다.

Vision Exp도 320K를 메모리에 올리는 데는 문제가 없었습니다. 다만 256Ki 토큰을 한 번에 넣으면 prefill에만 약 1시간 58분이 걸렸고, 그 위치에서 decode는 5.31 tok/s였습니다. 큰 context를 담을 수 있는 것과 그만큼을 한 번에 처리할 수 있는 것은 다른 문제입니다. 한 세션에서 조금씩 쌓고 prefix를 재사용하는 쪽이 현실적입니다.

coding과 agent 작업: Qwen3.8 Flash Next

짧은 decode가 약 21 tok/s이고, OpenCode로 19K 토큰짜리 completion이 들어간 브라우저 게임을 끝까지 만들었습니다. 상주 메모리가 104.53GiB라 여유가 적고, 도구 결과가 다시 직렬화되면서 큰 prefill이 반복되는 일이 있습니다. 128K context, Q8 K/V, lazy off, speculative off로 운영합니다. Qwen3.8 Flash Next 실측에 근거를 정리했습니다.

이미지 이해: DeepSeek V4 Vision (실험)

단일 이미지 설명은 반복해서 맞혔지만, 실험 PR과 routing patch에 기대고 있고 image span 안의 bidirectional attention이 아직 구현되지 않았습니다. 다중 이미지나 고해상도 입력은 결과를 확인하면서 써야 합니다. 256Ki 토큰 투입 실측을 참고하세요.

영상 생성: MiniMax H3

9월 7일 최신 gfx1151 HIP 빌드부터는 LightX2V v1.1 4-step, 네이티브 HIP Sol, FP16 VAE 조합이 빠른 생성의 기본값입니다. 실제 1344×768·124f에서 생성 시간이 Dense 평균 617.138초에서 Sol 431.056초로 30.15% 줄었습니다(워밍업 뒤 각 3회). 768×448·124f에서는 135.97초가 117.41초가 되어 13.65% 줄었습니다. 프롬프트와 시드 하나로 잰 속도라 품질이 같다는 보장은 아닙니다. 자세한 측정은 네이티브 HIP Sol 글에 있습니다.

짧은 토큰 작업은 자동으로 Dense CK를 쓰고, 이미지·레퍼런스 입력이나 다른 step 프로필은 기존 경로를 그대로 씁니다. VSA는 124.43초로 Sol보다 느리고 GTT도 더 써서 기본값으로 고르지 않았습니다. 품질을 비교할 때는 PDD나 Larry 8-step을 쓰고, 정규 20-step 미리보기에만 FirstBlockCache Safe를 켭니다. LLM과 H3는 동시에 띄우지 않습니다. 이전 가속 경로 비교는 MiniMax H3 가속 경로 실측에 있습니다.

기본으로 꺼 두는 옵션

옵션	이유
DS4 DSpark	수락률은 높지만 gfx1151에서 verifier 비용이 커서 기준선보다 느림
Qwen MTP2	코드는 빨라지지만 한국어 소설은 느려지고 메모리 약 12GiB 추가
Qwen lazy tensor	메모리는 줄지만 gfx1151 HIP signal wait에서 서버가 ready에 도달하지 못함
H3 예전 커스텀 Triton ROCm Sol-Attn	긴 토큰에서 dense CK보다 10.74% 느렸음. 새 네이티브 HIP Sol은 별도 구현이고 운영에 채택
H3 cache/forecast 상시 적용	빨라지지만 생성 결과가 크게 달라져 미리보기 용도로만
GPU low / 고정 Performance	앞은 성능 저하가 크고, 뒤는 장시간 냉각이 걱정됨

운영 원칙

1. 대형 GPU 서비스는 한 번에 하나만 띄운다.
2. CPU는 power-saver, GPU는 auto를 기본으로 둔다.
3. 같은 소스, 같은 양자화, 같은 프롬프트로 A/B하지 않았으면 우열을 말하지 않는다.
4. speculative decoding은 수락률이 아니라 최종 tok/s와 verifier 비용, 메모리로 판단한다.
5. 긴 context는 cold prefill, prefix 재사용, 깊은 위치의 decode를 따로 잰다.
6. 시험용 런타임과 모델은 운영 경로와 분리하고 되돌릴 판을 남긴다.