Molayo

© 2026 Molayo

r/LocalLLaMA분석2026. 05. 09. 16:53

Qwen 35B-A3B is very usable with 12GB of VRAM

요약

본 기술 기사는 12GB VRAM 환경에서 Qwen 35B MoE 모델을 구동하는 최적의 방법을 상세히 분석합니다. 특히, 메모리 효율성과 성능 사이의 균형점을 찾는 것이 핵심이며, `llama-cpp`와 같은 프레임워크를 사용하여 다양한 하이퍼파라미터(예: `-ncmoe`, 컨텍스트 크기)를 조정해야 합니다. 분석 결과, 일반 디코딩과 MTP(Speculation Decoding) 모두 12GB VRAM에서 매우 강력한 성능을 보여주지만, 코딩 작업의 경우 메모리 사용량과 안정성을 고려했을 때 최적화된 플레인 디코딩 설정이 가장 실용적입니다. 결론적으로, 이 모델은 제한적인 VRAM에서도 대규모 컨텍스트와 높은 추론 속도를 유지할 수 있어 매우 활용도가 높습니다.

핵심 포인트

  • 12GB VRAM 환경에서 Qwen 35B MoE 모델 구동이 매우 실용적이며 고성능을 보장함.
  • MoE 블록 할당(`-ncmoe`)은 성능과 메모리 사용량에 결정적인 영향을 미치므로, 일반 디코딩의 경우 -ncmoe 18~20 사이가 최적 범위임.
  • 최상의 코딩 프로필은 32k 컨텍스트와 적절한 `-ncmoe` 설정을 조합하여 높은 속도(Prompt: ~88.9 t/s, Generation: ~43.4 t/s)를 달성함.
  • KV 캐시의 경우 q8_0을 사용하는 것이 성능 면에서 가장 유리하며, MTP 디코딩은 플레인 디코딩 대비 생성 속도 향상이 미미하여 코딩에는 플레인 디코딩이 권장됨.

Hardware:

RTX 3060 12GB
32GB DDR4-3200
Windows
CUDA 13.x

Model:

Qwen3.6-35B-A3B-MTP-IQ4_XS.gguf

모델은 35B MoE 이므로 -ncmoe 가 매우 중요합니다. -ncmoe 를 낮추면 GPU 에 더 많은 MoE 블록이 남습니다.

주요 요약

12GB VRAM 은 이 모델에 대해 매우 실용적인 크기입니다. 이는 충분한 MoE 블록을 GPU 에 유지할 수 있게 하여, 일반 디코딩이 상당히 강력해지도록 하고, 동시에 16k/32k 와 같은 유용한 컨텍스트 크기를 위한 공간을 남깁니다.

프롬프트 처리 / prefill 에 대해서는 llama-bench 숫자를 llama-cli 의 인터랙티브 Prompt: 라인보다 더 신뢰합니다. llama-bench 는 더 깨끗한 pp512 측정을 제공하기 때문입니다.

최상의 일반 llama-bench 결과:

-ncmoe 18
-t 9
-ctk q8_0 -ctv q8_0

pp512: ~914 t/s
tg128: ~46.8 t/s

이 설정에서 원시 prefill 은 매우 빠릅니다.

최고의 실용적인 코딩 프로필

일일 코딩을 위해 다음과 같이 사용합니다:

llama-cli.exe ^
  -m "Qwen3.6-35B-A3B-MTP-IQ4_XS.gguf" ^
  -p "..." ^
  -n 512 ^
  -c 32768 ^
  --temp 0 --top-k 1 ^
  -ngl 999 -ncmoe 20 ^
  -fa on ^
  -ctk q8_0 -ctv q8_0 ^
  --no-mmap ^
  --no-jinja ^
  -t 9 ^
  --perf

결과:

Context:     32k
Prompt:      ~88.9 t/s in llama-cli
Generation:  ~43.4 t/s
VRAM free:   ~273 MiB

이것은 코딩에 충분한 컨텍스트를 가지고, 여전히 빠르며 완전히 VRAM 에 없는 상태가 아닙니다.

빠른 16k 프로필

-c 16384 -ncmoe 19 -ctk q8_0 -ctv q8_0 -t 9

결과:

Prompt:      ~91.5 t/s in llama-cli
Generation:  ~44.5 t/s
VRAM free:   ~37 MiB

이것은 약간 빠르지만, VRAM 에 매우 가깝습니다.

MoE 오프로드 스윕

일반 디코딩, q4 KV, -t 11:

-ncmoe 22: tg128 ~41.6 t/s
-ncmoe 20: tg128 ~41.7 t/s
-ncmoe 19: tg128 ~44.2 t/s
-ncmoe 18: tg128 ~45.9 t/s
-ncmoe 17: tg128 ~46.6 t/s
-ncmoe 16: tg128 ~25.8 t/s  <-- cliff / 너무 공격적

따라서 일반 디코딩을 위해:

safe:  -ncmoe 18
edge:  -ncmoe 17
avoid: -ncmoe 16

KV 캐시 스윕

-ncmoe 18, -t 11 에서:

q4_0 KV: pp512 ~913 t/s, tg128 ~45.8 t/s
q8_0 KV: pp512 ~915 t/s, tg128 ~45.9 t/s
q5_0 KV: 훨씬 느림
mixed q8 K + q4/q5 V: 훨씬 느림

따라서 이 GPU 에서 q8 KV 는 기본적으로 무료이며 선호됩니다:

-ctk q8_0 -ctv q8_0

MTP / speculation 디코딩

나는 llama.cpp MTP 브랜치와도 MTP 를 테스트했습니다.

최상의 MTP 명령:

llama-cli.exe ^
-m "Qwen3.6-35B-A3B-MTP-IQ4_XS.gguf" ^
--spec-type mtp ^
-p "..." ^
-n 512 ^
--spec-draft-n-max 2 ^
-c 4096 ^
--temp 0 --top-k 1 ^
-ngl 999 -ncmoe 19 ^
-fa on ^
-ctk q4_0 -ctv q4_0 ^
--no-mmap ^
--no-jinja ^
-t 11 ^
--perf

Result:

Generation: ~47.7 t/s

MTP sweep:

-ncmoe 24, depth 2: ~43.8 t/s
-ncmoe 20, depth 2: ~46.6 t/s
-ncmoe 19, depth 2: ~47.7 t/s
-ncmoe 18: failed / invalid vector subscript
-ncmoe 16: failed / invalid vector subscript

Depth 3 was worse:

depth 3, -ncmoe 20: ~39.8 t/s

So the MTP sweet spot was:

--spec-draft-n-max 2

Conclusion

With 12GB VRAM, plain decoding is already very strong:

Plain llama-bench: ~914 t/s pp512, ~46.8 t/s tg128
Best MTP observed: ~47.7 t/s generation

So MTP only gave about a 2% generation speedup over well-tuned plain decoding. For coding, I would personally use plain decoding with 32k context:

-c 32768 -ncmoe 20 -ctk q8_0 -ctv q8_0 -t 9

The big lesson: for this MoE model, 12GB VRAM is a very practical sweet spot. It keeps enough experts on GPU that plain decoding becomes fast, q8 KV is usable, and 32k context is realistic.

AI 자동 생성 콘텐츠

본 콘텐츠는 r/LocalLLaMA의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0