llama.cpp로 8GB GPU에서 262K 컨텍스트·3.5 BPW Qwen-Flash-Next Coder 70 T/s 구동한다
원문 제목 — 8 GB GPU, 262K context 3.5 BPW Qwen-Flash-Next Coder 70 T/s using llama.cpp
📄 전문 번역
Qwen-Flash-Next는 n-gram과 MOE 패킹 덕에 자기 몸집 이상의 성능을 내지만, 활성 파라미터는 여전히 6B이다. 이를 역이용해 대부분의 MOE는 RAM에 유지하고(가장 작은 MOE는 속도를 위해 VRAM에 배치), n-gram은 디스크에 두는 방식을 쓴다. 모델은 가장 빠른 SSD에 두는 것이 중요하다. 필요 비용은 VRAM 8GB와 RAM 24GB이며, 총 메모리가 약 32GB인 환경에서도 컨텍스트 크기를 줄이면 무난히 구동할 수 있다. 실행 파라미터는 자신의 하드웨어에 가장 잘 맞게 조정하라.
편집 노트: CUDA는 8GB VRAM에서 이 구성을 구동하기 어려워하는 듯하므로, 실행에 실패하면 Vulkan 백엔드를 사용하라. 같은 댓글 사슬 아래의 두 번째 실행 파라미터를 쓸 수도 있다. 여기에 더해 컨텍스트 크기를 줄이고 백그라운드 앱이 VRAM을 낭비하지 않도록 하라. 이를 위해 브라우저의 하드웨어 가속을 비활성화할 수 있다.
많은 사람이 이 모델을 1비트 양자화로 오인하는데, 먼저 이를 바로잡는다. 이 모델은 ISTA DASLab이 공개한 3.5 Bits Per Weight 'Coder' 변형으로 GSQ RCO 양자화가 적용됐다. 전문가의 절반이 제거되어 원본 파라미터 크기 대비로는 1.9비트 양자화 크기지만, 실제 가중치는 3.5 BPW를 사용한다.
모델 페이지 설명에 따르면, 트랜스포머 전체 평균으로 이는 원본 모델 대비 파라미터당 1.89비트에 해당한다. 이 수치는 유효 비율로서 제거된 전문가를 원본 파라미터 수에 걸쳐 분산 계산한 것이며, 프루닝과 양자화의 결합 효과를 나타낸다. 개별 가중치가 1.89비트로 저장되는 것은 아니며, 유지된 가중치는 프루닝의 영향 없이 3.5 bpw 그대로 저장되고 절반으로 줄어든 전문가 수가 나머지 감소분을 설명한다. 동반 릴리스의 관례에 따라 이 수치는 트랜스포머 전체 기준으로 보고된다.
코딩 외 어휘를 프루닝해 400MB 이상 작아졌으며, 공식 ISTA DASLab 양자화가 권장된다. 성능은 선택적 MOE 오프로딩(정규식) 기준으로 PP 70 T/s, TG 약 8 T/s를 기록했다(PCIe가 병목이며 작성자는 3.0 사용, 환경에 따라 결과는 달라질 수 있다). 같은 효과를 --n-cpu-moe로 내면 앞서 언급된 요인 때문에 더 느려진다. MMAP 특성상 첫 실행은 느리므로 정확한 T/s 측정은 두 번째 실행에서 하라. 실행 파라미터는 아래 댓글에 있으며, qwen sharp 채팅 템플릿을 사용하면 과잉 추론이 줄어든다.
💬 주요 댓글 번역 (5)
🔍 루키 분석
이 게시물은 ISTA DASLab의 GSQ RCO 방식 3.5 BPW Qwen-Flash-Next Coder 양자화 모델을 llama.cpp로 8GB VRAM 환경에서 구동한 사례를 다룬다. 전문가 절반 프루닝으로 원본 대비 유효 1.89비트 규모가 된 모델에 선택적 MOE 오프로딩을 적용해 262K 컨텍스트에서 PP 70 T/s, TG 약 8 T/s를 기록했으며, 필요 메모리는 VRAM 8GB와 RAM 24GB다. 8GB VRAM에서 CUDA 구동이 어려울 경우 Vulkan 백엔드 전환, 컨텍스트 축소, 백그라운드 앱 정리가 대안으로 제시된다.
— 루키 · glm-5.3-flash:cloud
./llama-server --model ./Qwen3.8-Flash-Next-GSQ-RCO-IQ1_M-merged_P1G_Pruned.gguf --ctx-size 262144 --n-gpu-layers 999 --threads 8 --cache-type-k q5_0 --cache-type-v q4_0 -fa on --fit off --cache-ram -1 --load-mode mmap --cache-prompt --cache-idle-slots --batch-size 2048 --ubatch-size 256 --webui --sleep-idle-seconds 900 --parallel 1 --kv-unified --reasoning-format deepseek -ot 'token_embd=CPU,blk\.(47|17|25|27|28|29|35|40|44|45|0|7|14|16|18|22|31|33|37|38|41|42|43|46|2|3|4|5|6|9|11|15|19|23|24|26|32|34|39|21|12|20|30|1|8)\.ffn_.*_exps\.weight=CPU' --
혹시 명령줄 인수 더 있나?
네, 일부 8GB VRAM 시스템은 OS나 백그라운드 앱이 VRAM을 두고 경쟁하는 탓에 이 구성을 수용하지 못하므로, 8GB에서 더 쉽게 구동할 수 있는 실행 파라미터가 있다. ./llama-server --model ./Qwen3.8-Flash-Next-GSQ-RCO-IQ1_M-merged_P1G_Pruned.gguf --ctx-size 262144 --n-gpu-layers 999 --threads 8 --cache-type-k q5_0 --cache-type-v q4_0 -fa on --fit off --cache-ram -1 --load-mode mmap --cache-prompt --cache-idle-slots --batch-size 2048 --ubatch-size 256 --webui --sleep-idle-seconds 900 --parallel 1 --kv-unified --reasoning-format deepseek -ot 'token_embd=CPU,blk\.(47|17|25|27|28|2...
--repeat-penalty 1.05, --presence-penalty 0.2. 일반적으로는 반복 페널티나 존재 페널티보다 --dry-multiplier를 쓰는 편이 낫다. LLM의 사고 과정을 인위적으로 제한하지 않기 때문이다. DRY는 LLM이 반복을 시작하는 시점에 개입하므로, 그 전까지는 LLM이 자유롭게 생각하도록 두는 것이 좋다. 물론 일부 모델은 양자화 후 반복 페널티가 필요할 수도 있다.
--dry-multiplier를 오랫동안 안 썼지만, 이 파라미터들이 소형 모델이나 양자화 모델에서 반복되는 사고 사슬을 막는 데 도움이 된다는 것을 발견했다. flash-next에서 그런 현상을 겪지는 않았지만 Qwen 3.8 27B와 3.6 35B A3B에서 성과를 본 만큼 예방 조치에 가깝다. 좋은 정보에 감사한다. 사용자들이 취향에 맞게 조정하는 데 도움이 될 것이다.