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 성장, 재프리필과 안정성을 기록했습니다.

128K운영 context
Q8 K/V · GPU
19.49 tok/s짧은 합성
decode 기준선
42.9K소설 agent의
최종 context
0건두 실사용 시험의
truncation · OOM · reset

1. 128GB 안에 들어가지만 여유는 작습니다

Q4_K_XL · vision 포함
125B language weights · token당 6B 활성262K native context128K 실운영 한도

128K context와 Q8 K/V까지 SSD offload 없이 동작했지만, 안정화 뒤 시스템 가용 메모리는 약 10GiB였습니다. 품질을 우선한 선택이며 다른 대형 모델을 동시에 적재하는 운영에는 맞지 않습니다.

2. 합성 벤치에서는 긴 prefill도 유지됐습니다

full ROCm offload · 2회 평균
32,786-token 실제 입력도 235.3 tok/s로 처리하고 정답을 반환했습니다. 다만 짧은 generation 속도를 긴 agent 작업의 기대값으로 쓰면 안 됩니다.

3. 실사용 agent 두 건의 결과

OpenCode · 각각 약 30분
LONG-FORM FICTION

1만 자 한국어 소설 작성·교정

초안, 반복 edit, 분량 확인과 파일 재독을 23회 호출로 완료했습니다.

9,945자최종 파일
21,316생성 tokens
12.06가중 decode
BROWSER GAME

종스크롤 슈팅 게임 제작

대형 edit, JavaScript 문법 검사와 브라우저 실행까지 5회 호출로 마쳤습니다.

23.7KB단일 HTML
20,121생성 tokens
12.56가중 decode

게임의 첫 응답은 19,377 tokens였고 완성된 HTML 전체가 edit 인자에 포함됐습니다. 다음 단계에서 거의 같은 19,401 tokens를 다시 prefill해 119.7초가 추가됐습니다. agent의 파일 편집 전략도 하드웨어만큼 전체 시간을 좌우했습니다.

4. context가 깊어지면 decode는 낮아집니다

소설 작업의 대표 구간
GPU 사용률이 100%가 아니어도 고장이나 CPU fallback을 뜻하지 않았습니다. context가 커질수록 token마다 KV와 attention 비용이 늘어나는 흐름이 두 실사용 작업에서 반복됐습니다.

5. ROCm 10은 빨라졌다기보다 ‘동급’이었습니다

같은 llama.cpp · 같은 설정 A/B
pp512320.45 tok/s−0.28%
pp4096301.16 tok/s−2.54%
pp16384257.60 tok/s+0.57%
tg25621.00 tok/s−2.33%

ROCm 7.14와 소스까지 맞춘 비교에서 모두 측정 노이즈에 가까운 차이였습니다. ROCm 10의 32K 안정성은 통과했지만, 이 모델의 llama.cpp 경로에서 큰 성능 상승을 주장할 근거는 없었습니다.

6. MTP draft-2는 작업 종류를 가렸습니다

32K · 512-token 생성
코드 생성 · 수락률 93.7%
20.91 → 32.21+54.0%
한국어 소설 · 수락률 49.2%
20.91 → 13.18−37.0%

코드는 제안 token이 거의 그대로 채택됐지만 창작 문장에서는 절반가량이 거절돼 draft 실행과 rollback 비용이 더 컸습니다. MTP가 시스템 가용 메모리도 약 22GiB에서 10GiB로 줄였기 때문에 128K 운영에는 적용하지 않았습니다.

최종 운영 판단

실측 결과 기반
KEEPQ4_K_XL · 128K

품질 우선. Q8 K/V와 full ROCm offload로 장문 작업을 안정적으로 통과했습니다.

KEEPLazy read 끄기

약 32GiB를 아낄 가능성은 있었지만 gfx1151에서 모델 적재가 완료되지 않았습니다.

OFFMTP 기본 비활성

코드에는 빠르지만 창작 회귀와 약 12GiB의 추가 메모리 비용이 컸습니다.

WATCHROCm·llama.cpp 후속판

ROCm 10 자체보다 model graph와 gfx1151 kernel 개선의 효과를 계속 관찰합니다.

측정 범위와 해석

  • 합성 벤치는 2회 평균이며 실사용 결과는 각 작업 1회입니다. 절대 성능 서열보다 운영 규모와 병목을 확인하는 자료입니다.
  • 게임은 JavaScript 문법과 브라우저 실행까지 확인했으며 실제 플레이 품질의 자동 검증은 포함하지 않았습니다.
  • 실사용 두 건 모두 context 잘림, OOM, SVM fault, GPU reset과 서버 재시작 없이 완료했습니다.