동료 Llama 여러분, 여러분의 시간은 소중하니 짧게 핵심만 말씀드리겠습니다 (모든 것을 설명하려고 노력하면서 말이죠 ㅎㅎ). 요약하자면(TL;DR): 16GB GPU에서 33-35B MoE를 실행합니다. Qwen3.6 35B-A3B: 13.3 GiB (기존 ~20.5 GiB). Laguna XS.2 33B-A3B: 14.6 GiB (기존 18.8 GiB). 둘 다 RTX 3090에서 측정되었으며, 모두 16 GiB 미만입니다. 활성화된 전문가(active experts)만 GPU에 머뭅니다. A3B 모델은 토큰당 약 256개의 전문가 중 8개로 라우팅됩니다. Spark는 트래픽이 어떤 전문가를 타격하는지 보정(calibrate)하여 해당 전문가들을 '핫(hot)'한 상태로 유지합니다. 나머지 롱테일(long tail)은 시스템 RAM에 머물며, 제한된 GPU 캐시(bounded GPU cache)를 통해 필요할 때마다 스왑(swap)되어 들어옵니다. 셀프 튜닝(Self-tuning) 방식입니다. 배치(placement)는 실시간 라우팅으로부터 학습되어 모델 옆에 기록됩니다. 재시작할 때마다 더 나은 프로필을 로드합니다. 코퍼스(corpus)나 오프라인 보정 단계가 필요 없습니다. 명령어 하나로 두 백엔드 모두 지원합니다. dflash_server <model.gguf> --spark 명령은 laguna와 qwen35moe 모두에서 작동합니다. 서버가 캐시 크기를 선택하고, 존재할 경우 학습된 프로필을 로드하며, 이를 계속 유지(persisting)합니다. 속도 저하(speed cliff) 없는 오프로드(offload)를 구현합니다. 오프로드 상태에서 laguna는 레이어당 40개의 그래프가 아닌, 전체 토큰을 하나의 융합된 그래프(fused graph)로 실행합니다. 전체 상주(full residency) 시 이 그래프는 모든 GPU를 사용할 때와 비트 단위로 동일(bit-identical)하며 속도도 똑같습니다 (119 tok/s). 60% 상주 시에는 약 100 tok/s를 유지합니다 (단순한 오프로드 방식의 66 tok/s보다 1.5배 빠름). 이것은 오픈 소스이며 여기서 찾을 수 있습니다: https://github.com/Luce-Org/lucebox-hub (Apache2.0). 기본 아이디어 중 마법 같은 것은 없습니다. 전문가 오프로딩(Expert offloading)은 오래된 기술입니다: llama.cpp가 이를 수행하며 (--n-cpu-moe / --cpu-moe), ktransformers와 ik_llama.cpp도 수행합니다. 핫한 전문가를 GPU에 유지하고 나머지를 RAM에 두는 것은 표준적인 트릭입니다. 작동 원리는 세 가지 요소로 구성됩니다: 1. 보정된 배치(Calibrated placement). Spark는 실제 요청으로부터 (레이어, 전문가)별 라우팅 빈도를 축적하여 가장 많이 사용되는 세트를 고정(pin)합니다. 홀드아웃 트래픽(held-out traffic)에서 이는 콜드 히트율(cold-hit rate)을 36%(균등 분할 시)에서 약 7%로 낮춥니다. 2. 제한된 비동기 캐시(Bounded async cache). 여분의 GPU 슬롯을 고정된 링(ring) 형태로 유지합니다. 콜드 전문가(cold-expert) 히트가 발생하면, 가중치는 고정된 호스트 메모리(pinned host memory)로부터 연산과 중첩(overlap)되어 비동기적으로 여분 슬롯으로 복사되며, 이때 LRU 항목을 축출(evicting)합니다. 미스(miss)가 발생해도 연산이 중단(stall)되는 것이 아니라 처리량(throughput)만 감소합니다.

이 링(ring)은 핫 엑스퍼트 스택(hot expert stack)을 소량으로 과다 할당(over-allocation)한 것이므로, 스왑(swap)은 단지 세 개의 가중치 텐서(weight tensors)를 복사하고 하나의 라우팅 엔트리(routing entry)를 업데이트하는 과정일 뿐이며, 별도의 특수 경로 없이 기존 GPU FFN에 의해 처리됩니다. 두 백엔드(backend) 모두 동일한 메커니즘을 사용하며, 하나의 퓨즈드 그래프(fused graph)로 동작합니다. 오프로드(offloaded) 경로는 토큰당 레이어별로 40개의 그래프를 생성해야 했습니다. 라우팅된 FFN을 어텐션 그래프(attention graph)에 통합(folding)하고 전체 토큰을 하나의 그래프로 실행함으로써 이러한 제출 오버헤드(submission overhead)를 제거했습니다. 전체 레지던시(full residency) 상태에서 퓨즈드 디코드(fused decode)는 모든 GPU를 사용하는 방식(all-GPU)과 비트 단위로 동일하며(128/128 토큰, spark/bench.py로 검증됨), 동일한 약 119 tok/s 속도로 실행됩니다.

메모리, 3090에서의 피크 VRAM, 컨텍스트(ctx) 4096:

모델	All-GPU	Spark	절감액(Saved)	16GB 적합 여부
Laguna XS.2 33B-A3B	18.8 GiB	14.6 GiB	4.2 GiB	yes
Qwen3.6 35B-A3B	~20.5 GiB	13.3 GiB	~7 GiB	yes

속도, 이득이 발생하는 지점:

설정	디코드(Decode)	All-GPU 대비 %
Naive offload (uniform)	66	55%
Spark, calibrated placement	81	68%
Spark, calibrated + cache + fused graph	~100	~85%
All-GPU (24 GB 필요)	119	100%

하나의 셀프 튜닝(self-tuning) 명령:

laguna 또는 qwen35moe, 동일한 플래그 사용

dflash_server models/Qwen3.6-35B-A3B-Q4_K_M.gguf --spark

선택 사항: 레이어당 캐시 슬롯 (기본값 32)

dflash_server models/laguna-xs2-Q4_K_M.gguf --spark --spark-slots 48

솔직한 한계점: 3090(24 GB)에서 측정되었습니다. 피크 VRAM은 16 GiB 미만으로 떨어지지만, 아직 실제 16 GB 그래픽 카드에서 실행해 보지는 않았습니다. 만약 누군가 4060 Ti 16GB / 5060 Ti 16GB를 가지고 있다면, 실제 수치를 알고 싶습니다. 오프로드는 여전히 All-GPU 방식에 비해 약간 뒤처집니다. 마지막 ~15%의 격차를 줄이려면 더 많은 VRAM이 필요하거나 다음 엑스퍼트(experts)를 예측해야 하는데, 토큰 수준의 예측은 재현율(recall)이 약 53%에서 제한되므로 이는 공짜 점심이 아닌 해결해야 할 과제로 남아 있습니다. 아직 동일한 설정에서 llama.cpp --n-cpu-moe와의 직접적인 비교는 수행하지 않았습니다. 그것이 저희가 가장 추가하고 싶은 비교 항목입니다. 저희는 로컬 AI 커뮤니티를 돕기 위해 이 작업에 매진했습니다. 물론 실수가 있을 수 있습니다. 피드백은 언제나 환영합니다!

수정: 게시물을 더 간결하게 만들었습니다. 죄송합니다 여러분 😂 /u/sandropuppo가 r/LocalLLaMA에 제출함 [링크] [댓글]