Qwen3.8 Flash Next 실측 — ROCm 10, lazy tensor, MTP 를 전부 검증하고 끈 이유
104.5GiB Qwen3.8 Flash Next 를 128K 컨텍스트로 — ROCm 10 동조건 A/B, lazy tensor, MTP draft-2 를 실측하고 운영 기본값을 정한 기록.
EVO-X2 (128GB 통합 메모리, gfx1151)에서 Qwen3.8 Flash Next UD-Q4_K_XL 을 돌리는
가장 단순하고 안정적인 구성은 최신 llama.cpp 직접 구동이었습니다. ROCm 10 은 안정성
검증은 통과했지만 같은 소스의 ROCm 7.14 보다 뚜렷하게 빠르지 않았고, lazy tensor 와
MTP 는 각각 안정성·작업 편차·메모리 때문에 기본값에서 뺐습니다. 그 판단의 근거를
수치로 남깁니다.
기준 구성
| 항목 | 값 |
|---|---|
| 모델 | Unsloth Dynamic UD-Q4_K_XL, 4 shards |
| 모델 + F16 projector | 약 104.53GiB |
| runtime | upstream llama.cpp 90c26fc, ROCm 10, native gfx1151 |
| context / slot | 131,072 tokens / 1 |
| KV | K/V Q8_0, GPU backend |
| tensor load | full resident, --tensor-read-lazy off |
| 기타 | full layer offload, Flash Attention, speculative off |
Unsloth Studio 가 쓰던 실제 추론기도 llama.cpp 였고 별도 Qwen kernel 이 없어서,
UI 와 proxy 가 필요 없는 agent 운용은 direct llama-server 로 단순화했습니다.
ROCm 10, 같은 조건에서 다시 재 보니
llama.cpp 90c26fc 을 동일 플래그로 ROCm 7.14 와 10 에서 각각 빌드해 비교했습니다.
| 시험 | ROCm 7.14 | ROCm 10 | ROCm 10 변화 |
|---|---|---|---|
| pp512 | 321.36 tok/s | 320.45 tok/s | -0.28% |
| pp4096 | 309.00 tok/s | 301.16 tok/s | -2.54% |
| pp16384 | 256.16 tok/s | 257.60 tok/s | +0.57% |
| tg256 | 21.50 tok/s | 21.00 tok/s | -2.33% |
ROCm 10 의 큰 성능 상승은 이 모델·양자화에서 재현되지 않았습니다. 다만 실제 32,784-token prefill 을 249.70 tok/s 로 완료했고 truncation·OOM·GPU reset·HIP fault· 서비스 재시작이 없었으므로, ROCm 10 을 운영에 쓰되 7.14 를 롤백용으로 남겼습니다.
장문 agent 실사용
| 작업 | 결과 |
|---|---|
| 1만 자 소설 | 23 calls, context 16,565→42,929, 생성 21,316 tokens |
| 소설 처리량 / 시간 | 가중 decode 12.06 tok/s / 약 31분 24초 |
| 브라우저 게임 | 5 calls, context 16,254→36,449, 생성 20,121 tokens |
| 게임 처리량 / 시간 | 가중 decode 12.56 tok/s / 약 30분 05초 |
게임의 첫 completion 은 19,377 tokens 와 전체 HTML edit tool call 을 포함했습니다. 다음 agent step 에서 큰 tool result 가 다시 직렬화되어 19,401 tokens 를 재프리필한 비용도 관측됐습니다. 에이전트 체감 속도는 짧은 생성 벤치가 아니라 tool schema, 재직렬화, prefix cache hit 에 크게 좌우됩니다.
lazy tensor — 메모리 32GiB 를 포기하고 끈 이유
모델의 per_layer_token_embd.weight 는 약 26.8GiB 입니다. lazy mmap 은 이 상주량을
피해 가용 메모리를 약 32GiB 늘렸지만, gfx1151 ROCm 의 HIP copy/signal wait 에서
서버가 ready 에 도달하지 못했습니다.
최신 llama.cpp 의 lazy 기본값이 auto 이므로, full-resident 운영에는
--tensor-read-lazy off 를 명시해야 합니다.
메모리 여유가 더 중요하면 UD-IQ4_XS 가 projector 포함 약 88.08GiB 로 16.44GiB 작습니다. 다만 IQ4_XS 는 routed expert 정밀도가 대부분 더 낮아, 같은 prompt 로 A/B 하기 전에는 품질 차이를 단정하지 않습니다.
MTP draft-2 — 작업 종류를 가렸다
| 작업 | 기준선 | MTP2 | 변화 / 수락률 |
|---|---|---|---|
| 코드 | 20.91 tok/s | 32.21 tok/s | +54.0%, 93.7% |
| 한국어 소설 | 20.91 tok/s | 13.18 tok/s | -37.0%, 49.2% |
코드는 제안 token 이 거의 그대로 채택됐지만 창작 문장은 절반가량 거절돼 draft 실행과
rollback 비용이 더 컸습니다. draft-p-min=0.5 도 두 작업 단순 평균에서 기준선보다
0.8% 낮았습니다. 32K 구성의 시스템 가용 메모리도 MTP 적용 시 약 22GiB 에서 10GiB 로
줄어, 128K Q4_K_XL 의 작은 메모리 여유와 겹쳐 운영에서는 끕니다.
권장값
- direct llama-server, ROCm 10, Q4_K_XL full resident
- context 128K, Q8 K/V, Flash Attention, slot 1
- lazy off, MTP/speculative off
- upstream 의 ROCm/MTP 구현이 바뀌면 코드와 한국어 장문을 모두 같은 조건으로 A/B
이 글은 128GB 미니PC 로컬 AI 시리즈의 각론입니다.