저는 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 컨텍스트):

핵심 비결은 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 가이드 영상도 제작할 계획입니다. 영상이 올라오면 업데이트하겠습니다.

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