128GB 미니PC 에서 어떤 로컬 AI 모델을 띄울 것인가

GMKtec EVO-X2 (Ryzen AI Max+ 395, Radeon 8060S gfx1151, 128GB 통합 메모리)에서 어떤 로컬 모델을 띄울지는 공개 벤치마크 점수 하나로 정할 수 없었습니다. 작업 종류, 양자화, context 깊이, 메모리 여유와 검증된 runtime 을 함께 보고 결정해야 했습니다. 아래는 2026년 8~9월에 실제 설치해 운영한 조합의 선택표입니다. 각 조합의 상세 실측은 시리즈 각론에 있습니다.

이 표는 설치 조합의 운영 비교이지 원본 모델의 절대 순위가 아닙니다. 입력·출력 길이, runtime, 양자화가 행마다 다르므로 행 간 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 persistence
Qwen3.8 Flash Next Q4_K_XL	projector 포함 약 104.53GiB	128K	짧은 21.0 tok/s, 실제 소설/게임 12.06/12.56 tok/s	coding, tool-heavy agent, 대형 출력
DeepSeek V4 Vision IQ2_XXS	model+projector 약 79.71GiB	320K	짧은 text 14.14, vision 14.88 tok/s	단일 이미지+text 실험, 큰 context
MiniMax H3	profile별 GTT 약 28GiB	영상 latent	LightX2V 4-step 25.57초(608x352·39f)	영상·오디오 생성

Qwen Q4_K_XL 이 DS4 Q2 보다 같은 짧은 프롬프트에서 약 23% 빨랐던 것도 현재 설치 조합의 체감 비교일 뿐, 원본 모델의 우열이 아닙니다.

작업별 선택

긴 text 세션 → DwarfStar4

320K context 와 SSD KV checkpoint persistence 가 장점입니다. 활성 KV 를 SSD 에서 직접 계산하는 것은 아니지만, 재시작·세션 교체 때 prefix 재프리필을 줄여 줍니다. 실제 40~80K 구간 decode 는 약 12.66 tok/s 였습니다. → DeepSeek V4 Flash 를 320K 컨텍스트로

Vision Exp 도 320K 를 메모리상 수용했지만 256Ki cold prefill 이 약 1시간 58분, 그 위치의 decode 가 5.31 tok/s 였습니다. 큰 context 를 담을 수 있다는 것과 cold 로 처리할 수 있다는 것은 별개입니다. 가능하면 한 세션에서 점진적으로 누적하고 prefix 를 재사용해야 합니다.

coding 과 tool-heavy agent → Qwen3.8 Flash Next

짧은 decode 약 21 tok/s, OpenCode 로 19K completion 을 포함한 브라우저 게임을 완성했습니다. 다만 104.53GiB 상주 때문에 메모리 여유가 작고, tool result 재직렬화로 큰 prefill 이 반복될 수 있습니다. 128K context, Q8 K/V, lazy off, speculative off 가 검증된 기본값입니다. → Qwen3.8 Flash Next 실측과 운영 결론

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

단일 이미지 description 을 반복 성공했지만 실험 PR 과 routing patch 에 의존하고, image-span bidirectional attention 제한이 남아 있습니다. 중요한 다중 이미지·고해상도 작업은 결과를 검증하며 써야 합니다. → 256Ki 토큰 cold 투입 실측

영상 생성 → MiniMax H3

CK attention + LightX2V v1.1 4-step + FP16 VAE 가 일반 빠른 기본값입니다. 품질 비교는 PDD/Larry 8-step, 정규 20-step preview 만 FirstBlockCache Safe 를 씁니다. LLM 과 H3 는 동시에 띄우지 않습니다. → MiniMax H3 가속 경로 전수 실측

기본적으로 끄는 옵션

옵션	이유
DS4 DSpark	높은 수락률에도 gfx1151 verifier 비용으로 기준선보다 느림
Qwen MTP2	코드는 빠르지만 한국어 소설은 느리고 메모리 약 12GiB 추가
Qwen lazy tensor	메모리는 절약하지만 gfx1151 HIP signal wait 로 ready 실패
H3 ROCm Sol-Attn	실제 long-token sparse path 가 dense CK 보다 10.74% 느림
H3 cache/forecast 기본 적용	빠르지만 생성 궤적 변화가 커 preview opt-in 만 적합
GPU `low` / 고정 Performance	각각 지나친 성능 저하 / 장시간 냉각 위험

공통 운영 원칙

대형 GPU 서비스는 한 번에 하나만 실행한다.
CPU power-saver, GPU auto 를 기본으로 한다.
같은 소스·양자화·prompt 의 A/B 가 아니면 runtime 또는 모델의 우열로 단정하지 않는다.
speculative 은 수락률이 아니라 최종 tok/s, verifier 비용과 메모리로 판단한다.
긴 context 는 cold prefill, prefix 재사용, 깊은 위치 decode 를 따로 측정한다.
시험용 runtime·모델은 운영 경로와 분리하고 롤백본을 남긴다.