r/LocalLLaMA•5일 전•56•58논쟁

16GB VRAM 및 64GB RAM에서 Qwen 3.8 Flash Next q4_k_m 구동 (130k 컨텍스트, q8 캐시, 4080에서 15-20 t/s)

Qwen 3.8 Flash Next q4_k_m, 130k context, q8 cache on 16GB VRAM ann 64GB RAM, 15-20 t/s on 4080

핵심 요약

16GB VRAM 환경에서 Qwen 3.8 Flash Next 모델을 효율적으로 구동하기 위한 최적화 설정과 성능 공유.

최적화 설정 — 적절한 양자화, 모델, 브랜치 및 캐시 플래그 조합으로 성능 극대화함.
하드웨어 제약 — 16GB VRAM 환경에서 DDR 대역폭과 VRAM 공간이 성능의 병목 구간으로 작용함.
성능 비교 — MTP와 전문가 캐시 활용을 통해 4080 환경에서 15-20 t/s의 속도를 달성함.
모델 평가 — 양자화 방식에 따른 성능 저하 논란과 더 나은 대안에 대한 사용자 간 의견 교환이 이루어짐.

일주일 동안 테스트해보고 이제 공유할 때가 된 것 같네. 대부분이 놓치고 있는 핵심 요소 4가지가 있는데, 바로 적절한 양자화(quant), 모델, 브랜치, 그리고 캐시 플래그야.

https://github.com/dtm-beep/qwen38-flash-next-mtp-16gb

세 줄 요약: AtomicChat AD-4.27bpw Q4_K_M 타겟에 공유된 Unsloth MTP 헤드 조합해. 내 pr-mtp-fix 브랜치에서 빌드해야 함(순정 마스터는 아직 이 MTP 헤드 못 불러옴, PR #28243에 수정 커밋 하나 추가된 버전임). 그리고 --spec-draft-cpu-moe 이게 16GB에서 돌아가게 만드는 킥이야. 드래프트 전문가들이 RAM에 상주하니까 타겟의 핵심 전문가들이 GPU를 온전히 쓸 수 있거든. IQ4_XS 기준 10 t/s 나오던 게 131k 컨텍스트, q8 KV에서 16.5 tg / 350 pp까지 뽑힌다.

누군가에게 도움이 됐으면 좋겠네.

원문

커뮤니티 목록

r/LocalLLaMA•5일 전•56•58논쟁

16GB VRAM 및 64GB RAM에서 Qwen 3.8 Flash Next q4_k_m 구동 (130k 컨텍스트, q8 캐시, 4080에서 15-20 t/s)

Qwen 3.8 Flash Next q4_k_m, 130k context, q8 cache on 16GB VRAM ann 64GB RAM, 15-20 t/s on 4080

핵심 요약

16GB VRAM 환경에서 Qwen 3.8 Flash Next 모델을 효율적으로 구동하기 위한 최적화 설정과 성능 공유.

최적화 설정 — 적절한 양자화, 모델, 브랜치 및 캐시 플래그 조합으로 성능 극대화함.
하드웨어 제약 — 16GB VRAM 환경에서 DDR 대역폭과 VRAM 공간이 성능의 병목 구간으로 작용함.
성능 비교 — MTP와 전문가 캐시 활용을 통해 4080 환경에서 15-20 t/s의 속도를 달성함.
모델 평가 — 양자화 방식에 따른 성능 저하 논란과 더 나은 대안에 대한 사용자 간 의견 교환이 이루어짐.

https://github.com/dtm-beep/qwen38-flash-next-mtp-16gb

누군가에게 도움이 됐으면 좋겠네.

주요 댓글

r/localllama

사용자들은 작성자가 공유한 Qwen 3.8 Flash Next 설정의 성능을 검증하며, 각자의 하드웨어 환경에 맞는 최적의 플래그와 드래프트 수락률에 대해 심도 있게 토론하고 있습니다.

이 속도를 내기 위해 실제로 입력되는 컨텍스트 크기가 어느 정도인가요?

1,000 토큰 정도의 시스템 프롬프트가 포함된 첫 응답인가요, 아니면 100k 컨텍스트가 포함된 답변인가요?

어떤 크기든 상관없음. 일정함.

증명해 봐

개선할 여지가 좀 있어 보이네.

네 성능이 내 MI50 전문가 캐시나 3060 12GB에 https://github.com/GenerelSchwerz/llama.cpp/wiki 전문가 캐시를 쓴 Codacus랑 비교해서 별로 나은 것 같지 않아.

MTP도 전문가 레이어나 캐시를 더 넣을 수 있는 공간을 차지하는 셈이지.

전문가를 더 넣으려 해도 안 들어가. 시도해 봤거든. 남는 VRAM이 부족해. 개선할 여지는 딱히 없어. 여기서 제한 요소는 DDR 대역폭이야. 물론 VRAM 공간도 그렇고. MTP 없으면 추론 성능이 떨어져. 실질적인 이득은 없지. 물론 더 좋은 방법 있으면 언제든 환영이야.

좋은 글이네, 나도 시도해 봐야겠어! 난 지금 순정 llama.cpp에서 ngram이랑 Atomic Chat을 쓰고 있어. RTX 4070(24 t/s) 시스템 하나랑 RTX 5070 TI(34 t/s) 시스템 하나에서 결과가 잘 나오고 있어. 둘 다 64GB DDR5랑 Core Ultra 7 265K를 쓰고 있지. 프리필(Pre-fill)은 별로지만.

llama-server -m Qwen3.8-Flash-Next-AD-4.27bpw-Q4_K_M-M64-00001-of-00033.gguf -c 32000 -b 2048 -ub 1024 -np 1 -fa on --jinja -ctk q8_0 -ctv q8_0 -t 20 --threads-batch 16 --spec-type ngram-mod --spec-ngram-mod-n-match 60 --spec-ngram-mod-n-min 12 --spec-ngram-mod-n-max 24 --temp 1.0 --top-p 0.95 --top-k 20 --min-p 0.0 --reasoning-effort medium -fit on -fitt 32

수정 - llama-server 값 몇 개 업데이트함.

난 4080이랑 64GB DDR5로 22 tgs, 450 pps 나오는데, 같은 GGUF 쓰고 있어. 플래그 공유 좀 해줄 수 있어? 수정: MTP 없이.

어느 컨텍스트 사이즈에서?

난 지금 이렇게 돌리고 있어:

LLAMA_ATTN_ROT_DISABLE=1 GGML_CUDA_NO_PINNED=1 taskset -c 0-11 ~/llamaDTM/build-mtp/bin/llama-server
-m /home/dan/.lmstudio/models/AtomicChat/Qwen3.8-Flash-Next-GGUF/Qwen3.8-Flash-Next-AD-4.27bpw-Q4_K_M-M64-00001-of-00033.gguf
--alias qwen38
-md /mnt/games/lmstudio_models/unsloth/Qwen3.8-Flash-Next-GGUF/MTP/mtp-Qwen3.8-Flash-Next-shared-Q4_K_M.gguf
--spec-type draft-mtp --spec-draft-n-max 2 --spec-draft-cpu-moe --load-mode none --lazy-mode on --fit on --fit-target 100 #--parallel 1 -ctk q8_0 -ctv q8_0 -c 131072 -b 2048 -ub 2048 -t 6 -tb 12 --cache-ram 2048 --ctx-checkpoints 0 --host 127.0.0.1 --port 8080 --tools all --jinja --reasoning-format deepseek-legacy --chat-template-kwargs '{"reasoning_effort":"medium","preserve_thinking":true}' --temp 1.0 --top-p 0.95 --top-k 20 --min-p 0.0 --repeat-penalty 1.0s --log-file /tmp/load.log

진짜 대박이네! 네 설정으로 돌리니까 내 4060 Ti 16GB에서 프리필 200-230 t/s, 생성 22-28 t/s 정도 나와.

예전에는 100k 컨텍스트에 IQ3_XXS, Q4/Q4 KV 캐시 썼을 때 프리필 400 t/s, 생성 10-20 t/s 정도였거든.

그래서 프리필 속도는 좀 줄었지만, 솔직히 Pi 쓸 때는 별로 상관없어. 대신 Q8/Q8 KV 캐시를 얻었고, 컨텍스트도 훨씬 늘었고, 모델도 훨씬 똑똑해졌으니까.

아무튼 이 설정 공유해줘서 정말 고마워!

좋은 결과 공유해줘서 고마워.

t/s랑 같이 서버 로그에서 드래프트 수락률(draft acceptance rate)도 올리는 게 좋을 듯. 드래프트 전문가들이 RAM에 고정되어 있으면 MTP 헤드는 수락률이 60%는 넘어야 본전치기를 하거든. 근데 이게 산문이나 temp 0.8 이상에서는 코드 완성보다 수락률이 확 떨어지니까. 그리고 참고로 양자화된 V 캐시는 -fa를 켜야 해, 안 그러면 llama.cpp가 거부하거든. 그러니까 이거 없이 q8/q8 플래그 복사하는 사람들은 빌드가 깨졌다고 생각할 거야.

좋은 조언이야. 로그 기록은 레포에 다 있어. 가이드에 있는 모든 tg 수치는 드래프트 수락률 옆에 적혀 있고, 관계는 대략 tg ≈ 수락률 x 30 정도라 독자들이 직접 확인해 볼 수 있어.

측정해본 수치 하나 말하자면, 이 시스템에서 본전치기(break-even)는 0.60이 아니라 0.50 정도야. 같은 바이너리와 같은 에이전트 트래픽으로 측정했을 때, MTP 끄면 15.2 t/s, MTP 켜고 수락률 0.55일 땐 16.5 t/s였어. 0.48일 땐 14.4 t/s였으니까 교차점은 0.48에서 0.55 사이, 딱 0.5 근처야. 보통의 경험칙보다 비용이 싼 이유는 --spec-draft-cpu-moe가 드래프트 전문가들을 RAM에 올려두기 때문에 MTP 단계에서 VRAM이나 GPU 시간을 거의 안 쓰기 때문이야. GPU에서 드래프트를 완전히 돌리는 설정에서 본전치기를 60%까지 끌어올리는 일반적인 드래프트 비용은 여기선 거의 안 드는 셈이지.

원문r/LocalLLaMA