Qwen3.8 Flash Next를 128K 컨텍스트로 운영하며 확인한 것들
104.5GiB Qwen3.8 Flash Next를 EVO-X2에서 128K 컨텍스트로 돌리며 ROCm 10 동조건 비교, lazy tensor, MTP draft-2를 측정하고 운영 기본값을 정했습니다.
2026-09-26 추가: 이 글의 처리량은 8월 말 llama.cpp 빌드 기준입니다. 이후 upstream 최적화로 prefill이 최대 61% 빨라졌습니다. 3주 뒤 다시 잰 결과를 함께 보세요.
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용으로는 llama-server를 직접 띄우는 쪽으로 정리했습니다.
ROCm 7.14와 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토큰 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토큰이었고, HTML 전체를 담은 edit 도구 호출이 들어 있었습니다. 다음 단계에서 그 큰 도구 결과가 다시 직렬화되면서 19,401토큰을 또 prefill했습니다. agent를 쓸 때 체감 속도는 짧은 생성 벤치마크보다 도구 스키마 크기, 결과 재직렬화, prefix cache 적중 여부에 더 크게 좌우됐습니다.
lazy tensor를 끈 이유
이 모델의 per_layer_token_embd.weight는 약 26.8GiB입니다. lazy mmap을 켜면 이 텐서를 상주시키지 않아도 돼서 가용 메모리가 약 32GiB 늘어납니다. 그런데 gfx1151 ROCm에서는 HIP copy/signal wait에 걸려 서버가 ready 상태까지 가지 못했습니다.
최신 llama.cpp는 lazy 기본값이 auto입니다. 전부 상주시켜 운영하려면 --tensor-read-lazy off를 명시해야 합니다.
메모리 여유가 더 필요하면 UD-IQ4_XS가 있습니다. projector 포함 약 88.08GiB로 16.44GiB 작지만, routed expert 대부분의 정밀도가 더 낮습니다. 같은 프롬프트로 비교하기 전까지는 품질 차이를 판단하지 않았습니다.
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% |
코드는 제안한 토큰이 거의 그대로 채택됐고, 소설은 절반 가까이 거절되면서 draft와 rollback 비용이 이득보다 컸습니다. draft-p-min=0.5로 조정해도 두 작업 평균이 기준선보다 0.8% 낮았습니다. 32K 구성에서 MTP를 켜면 시스템 가용 메모리가 약 22GiB에서 10GiB로 줄어서, 128K로 운영할 때는 끕니다.
운영 설정
llama-server직접 실행, ROCm 10, Q4_K_XL 전부 상주- context 128K, Q8 K/V, Flash Attention, slot 1
- lazy off, MTP와 speculative off
- ROCm이나 MTP 구현이 바뀌면 코드와 한국어 장문을 같은 조건으로 다시 비교
이 글은 128GB 미니PC 로컬 AI 시리즈의 한 편입니다.