원본 게시물: 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)을 실행했습니다:

어떤 것도 도움이 되지 않았습니다. 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) 테스트 결과:

현재 설정 (변경 없음, 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]