Auto-fit vs 튜닝된 MoE 오프로드: 564 → 1330 pp tok/s, 디코딩 속도는 동일 (Qwen3.6-35B-A3B Q6 /
요약
RTX 3090 환경에서 MoE 모델의 일부 레이어를 CPU로 오프로드하여 VRAM을 확보하고, 이를 통해 배치 사이즈를 키워 프롬프트 처리 속도를 2.36배 향상시킨 최적화 사례를 소개합니다.
핵심 포인트
- MoE 전문가 레이어 CPU 오프로드로 VRAM 여유 공간 확보
- 확보된 메모리를 활용해 배치(-b) 및 마이크로 배치(-ub) 크기 증대
- 프롬프트 처리(PP) 속도 564에서 1330 tok/s로 대폭 향상
- 토큰 생성(TG) 속도는 기존과 동일하게 유지됨
요약(TL;DR): 24GB RTX 3090에서 64K 컨텍스트 크기에 맞춰 설정된 Qwen3.6-35B-A3B Q6 환경에서, 8개의 MoE 전문가(expert) 레이어를 CPU로 오프로드(offload)함으로써 충분한 VRAM을 확보했습니다. 이를 통해 -b 값을 512에서 1024로, -ub 값을 128에서 512로 증가시킬 수 있었습니다. 프롬프트 처리(Prompt processing) 속도는 2.36배 향상된 반면, 생성(generation) 속도는 측정 오차 범위 내에서 변동 없이 유지되었습니다.
| 벤치마크 | Auto-fit 기준선 | 튜닝된 결과 |
|---|---|---|
| PP4K | 564.5 tok/s | 1330.0 tok/s (2.36×) |
| TG4K | 97.4 tok/s | 97.7 tok/s (측정 오차 범위 내) |
| TG32K | 81.6 tok/s | 84.0 tok/s (측정 오차 범위 내) |
이 수치들은 4K 프롬프트를 사용한 PP(Prompt Processing) 측정값이며, 4K 및 32K 컨텍스트 깊이에서의 TG(Token Generation) 측정값입니다. 설정값들은 64K 컨텍스트 요구 사항에 맞춰 조정되었습니다. 이는 64K 깊이의 처리량(throughput) 벤치마크가 아닙니다.
저는 먼저 실행 가능한 구성을 확립하기 위해 auto-fit을 사용했습니다. 그 결과 도출된 배치(batch) 설정은 -b 512, -ub 128이었습니다. 비교의 재현성을 위해 아래 기준선(baseline) 명령에 이를 하드코딩했습니다. 튜닝된 구성은 의도적으로 8개 레이어의 MoE 전문가 가중치(expert weights)를 CPU로 이동시킵니다: -ot 'blk.(1[2-9]).ffn_.*_exps.weight=CPU' \ -b 1024 -ub 512 -ngl 41
이것은 결합된 구성(joint-configuration)의 결과입니다: CPU 오프로드가 VRAM을 확보하고, 더 커진 배치/마이크로 배치(batch/micro-batch)가 해당 메모리를 사용하여 프리필(prefill)을 가속화합니다. CPU 오프로드 단독으로 성능을 향상시킨다는 개별적인 주장이 아닙니다.
Full reproduction Baseline은 auto-fit 구성을 재현합니다: llama-bench
-m Qwen3.6-35B-A3B-UD-Q6_K.gguf
-fitt 1024 -fitc 65536
-t 7 -b 512 -ub 128
-fa on -ctk q8_0 -ctv q8_0 -mmp 1
-p 4096 -n 64 -r 2
-d 4096,32768
Tuned는 다음과 같습니다: llama-bench
-m Qwen3.6-35B-A3B-UD-Q6_K.gguf
-t 7 -b 1024 -ub 512 -ngl 41
-fa on -ctk q8_0 -ctv q8_0 -mmp 1
-ot 'blk
p.(1[2-9]).ffn_.*_exps.weight=CPU'
-p 4096 -n 64 -r 2
-d 4096,32768
환경 모델: unsloth/Qwen3.6-35B-A3B-GGUF
양자화(Quant): Qwen3.6-35B-A3B-UD-Q6_K.gguf , 27.3 GiB
SHA-256: 4fe53b148b46f9b88830e2a3055c5b15c3a4d1e3ddc9a1384a108d8b9d59f043
GPU: RTX 3090, 24 GiB
CPU: Threadripper PRO 3955WX, 임대 RAM에 사용 가능한 코어 7개: 약 100 GB DDR4
llama.cpp: commit 571d0d5 Build: -DGGML_CUDA=ON -DGGML_CUDA_FA_ALL_QUANTS=ON , Release Peak tuned VRAM: 23,468 / 24,576 MiB, 약 1.1 GiB 여유
주의사항(Caveat): 이 수치들은 두 번의 반복 측정값이며, 관찰된 실행 간 드리프트가 약 1.6%입니다. TG 차이는 노이즈로 간주하고; 의미 있는 결과는 관찰된 디코드 성능 저하 없이 2.36× PP 개선입니다.
제가 사용한 방법은 진화 탐색(evolutionary search)을 통해 위 설정에 도달했습니다 (LEVI). 저는 이를 대략 100회 평가 / 40분 동안 실행했습니다 (https://github.com/ttanv/levi ). 현재는 기본적인 플래그와 설정만 진화시키고 있지만, llama cpp의 일부를 편집하는 등 더 비전통적인 수정에 정말 기대가 됩니다. 목표는 스택의 어떤 부분이 일반적이라서 맞춤형 최적화를 적용할 여지를 남겨두는지 재작성하여, 서빙 엔진이 모델+하드웨어 조합에 완전히 특화되도록 하는 것입니다. 하지만 신뢰성 있고 빠른 평가는 어렵습니다 :( . 혹시 이와 관련하여 제안이나 경험을 가진 분이 있다면 듣고 싶습니다. 또한 이것이 일반화되어 다른 환경에서도 유용할 수 있는지 테스트하고 싶습니다.
만약 MoE를 부분적으로 오프로드(offloaded)하고 있거나, VRAM 한계에 근접한 다른 설정을 사용 중이라면 다음과 같은 정보를 포함하여 답글을 남겨주세요:
- GPU, CPU 및 RAM 구성
- 정확한 GGUF 버전
- 목표 컨텍스트 길이 (Target context length)
- 현재 사용 중인 명령어 (Current command)
- PP(Prompt Processing), TG(Token Generation) 중 무엇을 더 중요하게 생각하는지, 혹은 더 큰 모델을 올리는 것이 우선인지
저는 진정으로 다른 설정들을 시도해보고 이것이 얼마나 일반화될 수 있는지 확인하고 싶습니다. 특히 더 니치(niche)하고 커스텀(custom)한 유형의 설정들을 찾고 있습니다. 다만, 제가 Vast.ai에 의존하고 있기 때문에 너무 거대한 설정은 아니길 바랍니다 (ㅎㅎ).
/u/Longjumping-Music638님이 r/LocalLLaMA에 게시함 [link] [comments]
AI 자동 생성 콘텐츠
본 콘텐츠는 r/OpenAI Codex (search)의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기