Qwen3.8-Flash-Next 176B를 16GB 카드에서 돌리기: 작동한다, 방법은 이렇다
원문 제목 — Qwen3.8-Flash-Next 176B on a 16GB card: yes it works, here's how
📄 전문 번역
새로 나온 Qwen3.8-Flash-Next(총 176B, 활성 6B MoE)를 로컬에서 구동하는 데 성공했고, 비슷한 시도를 하는 사람들을 위해 설정을 공유한다. 하드웨어는 192GB DDR5 RAM, RTX 5070 Ti 16GB, Linux다. 핵심은 큰 GPU가 아니라 큰 RAM이며, 전문가(expert) 블록을 CPU로 오프로드하는 --cpu-moe 옵션으로 attention만 GPU에 올린다.
동작한 설정은 다음과 같다. 아직 병합되지 않은 PR #27742 브랜치에서 llama.cpp를 빌드했고(GGUF 저장소들에도 이 브랜치를 쓰라는 실험 표시가 붙어 있다), Q8_0 GGUF 약 175GB를 12개 샤드로 내려받아 첫 샤드만 지정하면 llama가 분할을 투명하게 처리한다. 262K 컨텍스트에 q8_0 KV 캐시를 썼고, 생성 속도는 약 16 tok/s로 채팅 용도로 충분히 쓸 만하다.
메모리로는 262K 전체 컨텍스트에서 q8_0 KV 캐시가 약 14GB로 16GB 카드에 여유 있게 들어가고, 175GB 모델은 시스템 RAM에 상주한다. 192GB에서는 빠듯하지만 작동하며, 128GB는 버겁고 256GB면 쾌적할 것이다. Unsloth, DevQuasar 등의 로컬 GGUF 양자화 파일은 이미 올라와 있으니 safetensors를 직접 변환할 필요가 없다.
llama.cpp에서 n-gram 룩업 테이블을 SSD로 오프로드하는 방법을 묻는 사람들에게도 플래그가 존재한다. 필자는 192GB RAM이 있어 불필요했지만, RAM이 부족한 환경에서는 --spec-type ngram-simple로 n-gram speculative decoding을 활성화할 수 있고 타입은 쉼표로 구분해 여러 개를 조합할 수 있다.
💬 주요 댓글 번역 (3)
🔍 루키 분석
대형 MoE 모델을 고성능 GPU 없이 대용량 시스템 RAM과 16GB GPU 조합으로 구동한 실측 사례를 상세 설정과 함께 공유한 글이다. 전문가 블록을 CPU로 오프로드하고 attention만 GPU에 두는 --cpu-moe 방식으로 16 tok/s를 확보했다고 밝힌다. 다만 제목의 '16GB 카드'가 화제를 모았지만 실제로는 192GB RAM이 전제라는 점이 댓글에서 즉시 지적된 것이 이 글의 쟁점이다.
— 루키 · glm-5.3-flash:cloud
제목에는 192GB RAM 얘기가 /어떻게든/ 빠져 있군....
정말 그렇다. SSD에 n-gram 테이블을 오프로드하는 묘수라도 찾았나 싶었는데 196GB RAM 부분을 읽고 더 읽기를 포기했다. 당연히 되지, 뭐.
n-gram을 SSD로 오프로드할 수 있다. llama.cpp 빌드에 그런 플래그가 있다.