Molayo

© 2026 Molayo

Reddit요약2026. 06. 15. 09:08

[후속 질문] Qwen3.6-35B-A3B 8GB RTX: Linux를 시도하고 Gemma 4를 테스트해 본 결과, 왜 Windows가 더

요약

로컬 LLM 구동 시 Windows와 Linux 환경의 성능 차이를 분석한 실험 결과입니다. NVIDIA 드라이버의 '시스템 메모리 폴백' 기능 유무가 VRAM 부족 상황에서 성능 급락을 방지하는 핵심 요인임을 밝혀냈습니다.

핵심 포인트

  • Windows 드라이버는 VRAM 초과 시 시스템 RAM을 활용하는 폴백 기능 제공
  • Linux는 VRAM 부족 시 폴백 없이 성능이 급격히 저하되거나 오류 발생 가능
  • 노트북 환경에서는 PCIe 대역폭이 DDR5보다 낮아 GPU 배치 최적화가 오히려 느려질 수 있음
  • 외부 초안(External draft) 모델 사용 시 VRAM 사용량 급증 주의 필요

원본 게시물: https://www.reddit.com/r/LocalLLaMA/comments/1txwff3/comment/oq1e0jt/?context=3

요약 (TL;DR): Linux를 테스트하기 위해 WSL2로 마이그레이션했습니다 (여러 사람이 제안함). UD 모델에 MTP를 내장했을 때: 25.8 tok/s. Linux에서 외부 초안(External draft) 사용 시: ~9 tok/s (VRAM 붕괴). 다시 Windows로 돌아왔을 때 38–40 tok/s. Gemma 4를 테스트했으나 거부됨. Windows가 승리하는 이유는 Linux에는 존재하지 않는 특정 NVIDIA 드라이버 동작 때문입니다.

하드웨어: i7-13620H (6P + 4E), 32 GB DDR5-5200, RTX 4060 Laptop 8 GB.

Linux / WSL2 실험
WSL2(Ubuntu 24.04, apt를 통한 CUDA 12)에서 b9549를 소스에서 빌드했습니다. UD-Q4_K_M 변형(MTP 헤드가 내장된 버전)에서 내장 MTP (--spec-type draft-mtp)를 테스트했습니다:

  • MTP 내장, WSL2: 25.8 tok/s — 실제 개선됨 (WSL2에서 spec 미사용 대비 +43%)
  • 외부 초안 (Qwen3.5-0.8B), WSL2: ~9 tok/s — 처참한 결과
  • 외부 초안, Windows b9484: 38.8 tok/s — 이전과 동일

Linux에서 외부 초안 성능이 붕괴된 이유는 아래에 설명되어 있습니다. Linux가 막다른 길이라는 결론을 내리기 전에 전체 최적화 스윕(Baseline = 25.8 tok/s)을 실행했습니다:

설정tok/s∆
Baseline (t=8 auto, 기본 캐시, 우선순위 없음)25.8—
--prio 217.8-31%
-t 164.2-84%
-t 1218.7-28%
--cache-type-v q8_011.7-55%
--spec-draft-n-min 218.7-28%
n-cpu-moe 38 (더 많은 전문가를 GPU에 배치)15.3-41%

어떤 것도 도움이 되지 않았습니다. n-cpu-moe 결과는 직관에 반합니다: 더 많은 전문가(experts)를 GPU에 배치하는 것이 더 느립니다. 왜냐하면 PCIe 대역폭(~16 GB/s 노트북)이 DDR5 대역폭(~68 GB/s)보다 낮기 때문입니다. batch=1에서의 GEMV는 메모리 대역폭 제한(memory-bound)을 받으며, 이 지점에서는 CPU가 승리합니다.

왜 외부 초안이 Windows에서는 작동하지만 Linux에서는 작동하지 않는가
NVIDIA Windows 드라이버에는 시스템 메모리 폴백 (System Memory Fallback) 기능이 있습니다. VRAM이 가득 차면, OOM(Out of Memory) 오류를 내는 대신 조용히 시스템 RAM으로 넘깁니다. Linux에는 이 기능이 없습니다.

Linux에서 외부 초안(external draft) 모델이 활성화되면, 모델 로드 시점과 몇 번의 요청 사이의 VRAM 사용량이 약 5.4 GB에서 약 7.9 GB로 급증했습니다 (두 번째 모델 + CUDA graph 캡처가 약 3회 요청마다 약 219 MiB씩 증가함). 이로 인해 여유 공간(headroom)은 86 MB만 남았습니다. 성능은 약 9 tok/s로 급락했습니다.
Windows에서는 드라이버가 오버플로(overflow)를 흡수합니다. 이것이 바로 n-cpu-moe 34(더 많은 전문가(experts)를 GPU에 남겨두어 더 많은 VRAM을 사용함) 설정이 Windows에서는 안전하지만, 순수 Linux에서는 위험할 수 있는 이유이기도 합니다.
두 번째 요인: 외부 초안(external draft)을 사용하면 토큰 검증(token verification)이 배치(batch) 단위로 실행됩니다. 이는 여러 후보 토큰에 걸쳐 전문가(experts)를 로드하는 비용을 분산(amortize)시키며, 이 때문에 더 많은 전문가를 GPU에 유지하는 것(n-cpu-moe 34)이 부담(단일 토큰 GEMV)에서 순이익(배치 검증)으로 전환됩니다. 이러한 배치 효과는 WSL2 환경의 내장형 MTP(embedded MTP)에서는 동일한 방식으로 존재하지 않습니다.
또한 외부 초안은 내장형 MTP의 52.6% 대비 62~70%의 수락률(acceptance rate)을 기록했습니다. 외부 모델임에도 불구하고 더 나은 토큰 예측 성능을 보여줍니다.

Gemma 4
12B (Q3_K_M) 및 26B-A4B (unsloth QAT UD-Q4_K_XL) 테스트 결과:

설정WSL2 tok/sWindows b9553 tok/s
Gemma 4 12B, spec 없음24.022.8
Gemma 4 12B + ngram-mod27.1 (높은 변동성)24.8 (높은 변동성)
Gemma 4 26B-A4B + ngram-mod21.2 (19–23)16.5
Gemma 4 26B-A4B + ngram-map-k14.723.1
Qwen3.6 + 내장형 MTP25.825.7
Qwen3.6 + 외부 초안—38.8
Qwen3.6가 모든 면에서 승리했습니다. Gemma 4는 품질 측면에서도 원본 스레드의 다른 사용자들이 언급한 것과 같은 도구 호출(tool-calling) 문제가 있었습니다.
흥미로운 데이터 포인트 하나는, 동일한 모델에 대해 ngram-map-k가 Windows에서는 +40%(23.1)였으나 WSL2에서는 -31%(14.7)였다는 점입니다. 예상되는 원인은 WSL2의 RAM 압박(RAM pressure)으로 인해 해시 맵(hash map)이 축출(evicting)되었기 때문입니다. 그럼에도 불구하고 23.1은 38.8에 한참 못 미칩니다.
Gemma 4는 공식 MTP 초안 모델(~0.4B 별도 모델)을 가지고 있지만, 이 아키텍처는 순정 llama.cpp에서는 지원되지 않으며 커뮤니티 포크(community fork)에서만 지원됩니다. 저는 이를 더 조사하지 않았습니다. 대역폭 한계(bandwidth ceiling) 논거는 이와 상관없이 적용되기 때문입니다.

현재 설정 (변경 없음, Windows, 안정적)

-m Qwen3.6-35B-A3B-Q4_K_M.gguf
-ngl 999 --n-cpu-moe 34
-c 65536 --parallel 1 --no-mmap
...

원문 게시물에서 명시적인 --cache-type-k q4_0 --cache-type-v q4_0를 제거했습니다. 일부 K-cache 양자화 (quant) 유형은 외부 초안 모델 (external draft)과 함께 로드될 때 충돌이 발생하며, 기본 설정이 잘 작동합니다 (64K 컨텍스트에서 이 모델의 KV 캐시는 약 295 MiB에 불과합니다 — 어텐션 레이어 10개 기준). --reasoning off는 여전히 필요합니다. --chat-template-kwargs enable_thinking:false는 초안 모델이 로드될 때 오류를 발생시킵니다.

프리필 (Prefill): 13K 토큰 프롬프트 기준 약 180 tok/s. --ubatch-size (기본값 512)는 튜닝하지 않았습니다. 풀 어텐션 (full-attention) 트랜스포머 (transformers)의 경우 더 큰 ubatch가 큰 도움이 되지만, 전문가 (experts)가 어차피 CPU에서 실행되는 CPU 오프로드 (CPU-offloaded) MoE의 경우 효과가 불분명합니다.

아직 해결되지 않은 문제

ByteShape CPU-5 양자화 (quants) — CPU 오프로드된 전문가의 경우, K-quants가 i-quants보다 빠르다는 것을 발견했습니다 (IQ4_XS는 35% 더 느렸습니다). ByteShape가 다른 CPU 커널 (kernels)을 사용하는지 궁금합니다.
CPU 오프로드된 MoE의 프리필 (prefill)을 위한 ubatch — 전문가 연산이 어차피 CPU에서 이루어질 때 더 큰 ubatch가 도움이 될까요?
CUDA 그래프 (graph) 증가 — 제한 없이 고유 배치(per-unique-batch)마다 VRAM이 지속적으로 증가합니다. 임시 방편으로 Nightly 빌드에서 재시작하고 있습니다. 관련 플래그가 있나요?

더 많은 수치나 설정을 공유할 의향이 있습니다. 어떤 제안이라도 도움이 될 것입니다. 감사합니다!
submitted by /u/heitortp0 to r/LocalLLaMA
[link] [comments]

AI 자동 생성 콘텐츠

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

원문 바로가기
0

댓글

0