구형 GTX 1080(8 GB VRAM, 128k context)에서 ~30B MoE 모델로 24+ tok/s 달성

저는 llama.cpp를 사용하여 200달러짜리 중고 컴퓨터(i7-6700 / GTX 1080 / 32 GB RAM)에서 Qwen 3.6 35B-A3B와 Gemma 4 26B-A4B를 구동했습니다 (TurboQuant/RotorQuant KV 캐시 양자화(quantisation)를 통해 8 GB VRAM 내에서 128k 컨텍스트(context)를 사용할 수 있습니다).

결과 (Q4_K_M 모델, 128k 컨텍스트):

모델	tok/s	주요 플래그
Qwen 3.6 35B-A3B	~24	--n-cpu-moe 30, K=turbo4 V=turbo3
...

핵심 비결은 MoE 오프로딩(offloading)입니다. llama.cpp는 사용 빈도가 낮은 전문가 가중치(cold expert weights)를 시스템 RAM에 배치하고 PCIe를 통해 GPU로 스트리밍하는 동시에, 자주 사용되는 레이어(hot layers)와 KV 캐시(KV cache)는 GPU에 유지할 수 있습니다. 이 시스템은 완전히 PCIe 대역폭 제한(PCIe 3.0 x16이 최대치에 도달하는 동안 GPU 사용률은 ~40-50%에 머묾)을 받습니다.

가장 큰 발견: Gemma 4의 MTP 투기적 디코딩(speculative decoding)은 기본 설정 상태에서는 거의 도움이 되지 않았습니다 (~5% 이득). 확인 결과 llama.cpp가 토큰 임베딩 테이블(token embedding table)을 조건 없이 CPU에 유지하고 있었습니다. 보통은 문제가 되지 않지만(단순한 get_rows 조회), Gemma 4의 MTP 어시스턴트는 LM 헤드(LM head)가 결합되어 있어, 모든 초안 토큰(draft token)이 PCIe를 통해 262k×1024 행렬 곱셈(matmul)을 수행하게 됩니다. --override-tensor-draft를 사용하여 이를 GPU로 강제하면 실제 ~22%의 속도 향상과 ~79%의 초안 수락률(draft acceptance rate)을 얻을 수 있습니다.

설정 시 어려웠던 점 (Fedora 42 + Pascal GPU):

• akmod-nvidia를 580xx 브랜치로 고정 (Pascal은 레거시로 분류됨)
• CUDA 12.9를 위해 gcc-14 강제 사용 (최신 gcc는 거부됨)
• glibc 2.41 호환성을 위해 CUDA의 math_functions.h 패치
• TurboQuant 캐시와 Gemma MTP 지원을 위해 AtomicBot-ai/atomic-llama-cpp-turboquant 포크(fork) 사용

모든 고된 빌드 세부 사항이 담긴 전체 블로그 포스트 (모든 명령어 및 MTP 임베딩 테이블 문제에 대한 디버깅 심층 분석 포함)

조만간 YouTube 가이드 영상도 제작할 계획입니다. 영상이 올라오면 업데이트하겠습니다.

설정에 관한 질문은 언제든 환영합니다.