128GB UMA에서 Qwen3.8 Flash Next를 실전 투입해 봤습니다
104.5GiB Qwen3.8 Flash Next를 128K context로 적재하고 장문 소설, 브라우저 게임, ROCm 10과 MTP를 실측한 보고서입니다.
QWEN3.8 FLASH NEXT × 128GB UMA
104.5GiB 모델을 올린 뒤,
30분짜리 실전 작업을 두 번 돌렸습니다.
Ryzen AI Max+ 395에서 Qwen3.8 Flash Next의 최고 품질 4비트 GGUF를 llama.cpp로 직접 구동했습니다. 합성 속도만 재지 않고 1만 자 소설과 단일 HTML 게임 제작을 끝까지 수행해 context 성장, 재프리필과 안정성을 기록했습니다.
Q8 K/V · GPU
decode 기준선
최종 context
truncation · OOM · reset
1. 128GB 안에 들어가지만 여유는 작습니다
Q4_K_XL · vision 포함104.5GiB
≈10GiB
128K context와 Q8 K/V까지 SSD offload 없이 동작했지만, 안정화 뒤 시스템 가용 메모리는 약 10GiB였습니다. 품질을 우선한 선택이며 다른 대형 모델을 동시에 적재하는 운영에는 맞지 않습니다.
2. 합성 벤치에서는 긴 prefill도 유지됐습니다
full ROCm offload · 2회 평균3. 실사용 agent 두 건의 결과
OpenCode · 각각 약 30분1만 자 한국어 소설 작성·교정
초안, 반복 edit, 분량 확인과 파일 재독을 23회 호출로 완료했습니다.
종스크롤 슈팅 게임 제작
대형 edit, JavaScript 문법 검사와 브라우저 실행까지 5회 호출로 마쳤습니다.
게임의 첫 응답은 19,377 tokens였고 완성된 HTML 전체가 edit 인자에 포함됐습니다. 다음 단계에서 거의 같은 19,401 tokens를 다시 prefill해 119.7초가 추가됐습니다. agent의 파일 편집 전략도 하드웨어만큼 전체 시간을 좌우했습니다.
4. context가 깊어지면 decode는 낮아집니다
소설 작업의 대표 구간5. ROCm 10은 빨라졌다기보다 ‘동급’이었습니다
같은 llama.cpp · 같은 설정 A/BROCm 7.14와 소스까지 맞춘 비교에서 모두 측정 노이즈에 가까운 차이였습니다. ROCm 10의 32K 안정성은 통과했지만, 이 모델의 llama.cpp 경로에서 큰 성능 상승을 주장할 근거는 없었습니다.
6. MTP draft-2는 작업 종류를 가렸습니다
32K · 512-token 생성코드는 제안 token이 거의 그대로 채택됐지만 창작 문장에서는 절반가량이 거절돼 draft 실행과 rollback 비용이 더 컸습니다. MTP가 시스템 가용 메모리도 약 22GiB에서 10GiB로 줄였기 때문에 128K 운영에는 적용하지 않았습니다.
최종 운영 판단
실측 결과 기반품질 우선. Q8 K/V와 full ROCm offload로 장문 작업을 안정적으로 통과했습니다.
약 32GiB를 아낄 가능성은 있었지만 gfx1151에서 모델 적재가 완료되지 않았습니다.
코드에는 빠르지만 창작 회귀와 약 12GiB의 추가 메모리 비용이 컸습니다.
ROCm 10 자체보다 model graph와 gfx1151 kernel 개선의 효과를 계속 관찰합니다.
측정 범위와 해석
- 합성 벤치는 2회 평균이며 실사용 결과는 각 작업 1회입니다. 절대 성능 서열보다 운영 규모와 병목을 확인하는 자료입니다.
- 게임은 JavaScript 문법과 브라우저 실행까지 확인했으며 실제 플레이 품질의 자동 검증은 포함하지 않았습니다.
- 실사용 두 건 모두 context 잘림, OOM, SVM fault, GPU reset과 서버 재시작 없이 완료했습니다.