MoE 모델 5종 시험, 선택적 expert 오프로딩이 항상 빠르진 않았다

본문

MoE 모델을 GPU 메모리에 전부 올리지 못할 때 CPU에 어떤 부분을 맡기느냐에 따라 생성 속도가 달라집니다. DEV Community의 Jessica Doering은 16GB VRAM과 32GB RAM을 갖춘 노트북에서 모델 5종을 시험해 Phi-3.5-MoE와 Apex-35B에서는 expert만 선택적으로 CPU에 둔 방식이 빨랐고, 나머지 세 모델에서는 layer 전체를 CPU로 옮기는 방식이 빨랐다고 밝혔습니다.

MoE 모델은 토큰을 처리할 때 일부 expert만 활성화하지만, 전체 expert 가중치는 메모리에 저장해야 합니다. llama.cpp의 --n-cpu-moe N 설정은 지정한 수의 초기 layer에서 expert 가중치와 계산을 CPU에 두고, attention 등 나머지 작업은 GPU에 남기는 방식입니다. 전통적인 layer 오프로딩은 모델의 layer 전체를 CPU로 옮깁니다. 따라서 두 방식은 CPU와 GPU에 분배하는 작업의 범위가 다릅니다.

작성자는 RTX 4090 Laptop GPU, Core i9-14900HX, DDR5 32GB 노트북에서 CUDA 지원 llama.cpp와 Flash Attention을 사용했습니다. 모델은 GGUF 형식이며 각 파일 크기가 24~27GB로 16GB VRAM보다 컸습니다. 4,096토큰 문맥 설정과 같은 짧은 벤치마크 프롬프트를 사용하고, 측정 전에 워밍업 요청을 보냈습니다.

생성 속도는 Phi-3.5-MoE에서 선택적 오프로딩 5.67 tok/s, 전통적 오프로딩 4.03 tok/s였고 Apex-35B에서는 각각 5.18과 3.69 tok/s였습니다. 반면 Qwen3.5-35B는 4.37 대 5.23 tok/s, Gemma 4 26B는 4.40 대 5.77 tok/s로 전통적 방식이 앞섰습니다. LFM2.5-24B에서는 선택적 방식이 2.11 tok/s, 전통적 방식이 9.03 tok/s였습니다.

이 결과는 해당 노트북과 설정에서 오프로딩 방식의 속도 순위가 모델마다 달랐다는 점을 보여줍니다. 다만 모델별 양자화와 구조가 서로 다르고, 설정마다 짧은 측정을 한 번씩 진행했습니다. 작성자는 각 설정에서 서버를 새로 시작하고 워밍업했지만 Linux 페이지 캐시를 비우지는 않았다고 댓글에서 설명했습니다. 따라서 측정된 차이의 원인을 양자화나 CPU 메모리 대역폭, CPU·GPU 동기화 중 하나로 확정할 수는 없습니다. LFM2.5도 Q8_0으로만 시험해 양자화의 영향을 따로 비교하지 않았습니다.

Phi-3.5-MoE에서 CPU에 둔 expert layer 수를 바꾼 시험에서는 13개일 때 15,945MiB VRAM과 5.29 tok/s, 16개일 때 13,833MiB와 4.66 tok/s, 20개일 때 11,015MiB와 5.67 tok/s를 기록했습니다. VRAM을 가장 적게 쓴 20개 설정의 속도가 가장 높았지만, 각 설정의 단일 측정만으로 메모리 사용량과 속도 사이의 원인을 밝히기는 어렵습니다. 작성자는 이 설정들을 여러 번 측정하겠다고 밝혔습니다.

자료: DEV Community / 정리·해설: Trawling