TL;DR
작성자는 144GiB DeepSeek-V4-Flash-0731 UD-Q4_K_XL GGUF를 4개의 12GB RTX 3060과 128GB quad-channel RAM에서 llama.cpp로 실행해 368,640-token context, prompt processing 99.4 tok/s, generation 10.1 tok/s를 측정했습니다. -ncmoe 34로 일부 Expert를 system RAM에 남기고 나머지 Expert를 GPU 1–3에 명시적으로 배치한 뒤, -ts 100,1,1,1로 attention과 KV 관련 non-Expert tensor를 GPU0에 집중했습니다. -ub 2048은 -ub 1024보다 prompt processing을 약 63.4 tok/s에서 99.4 tok/s로 높였지만 VRAM 여유를 줄였고, Q8_0 KV와 -np 1이 메모리 관리에 유리했습니다. 368k context는 설정 가능한 용량이며 전체를 끝까지 채운 생성 시험 결과는 아닙니다.
실용적 조언
- 긴 context와 처리 속도를 함께 확보하려면 먼저 -ub 2048을 사용해 prompt processing을 높이고, 실제 부하에서 가장 적은 VRAM 여유를 확인해야 합니다. 393,216-token 설정에서 GPU0 여유가 493 MiB까지 줄었으므로 368,640으로 낮추면 속도를 거의 유지하면서 671 MiB를 남길 수 있습니다. 메모리 여유를 더 우선하면 -ub 1024와 더 큰 context를 교환할 수 있지만 prompt processing은 약 63.4 tok/s로 감소합니다.
- Expert가 GPU에 고르게 배치되지 않는 MoE에서는 -ncmoe와 명시적인 -ot override를 함께 조정해야 합니다. 이 사례에서는 blocks 0–33의 Expert를 system RAM에 남기고 blocks 34–42의 Expert를 GPU 1–3에 나눴으며, -ts 100,1,1,1로 GPU0에 non-Expert tensor를 집중시켰습니다. 배치를 수식으로만 추정하기보다 후보 설정을 실제 prompt load에서 측정해야 CUDA allocation failure와 예기치 않은 VRAM 부족을 피할 수 있습니다.
- KV 메모리는 Q8_0으로 설정하고 -np 1을 유지하는 편이 이 구성에 적합합니다. F16 KV는 c=393216에서 VRAM 여유를 587 MiB까지 줄였고, 여러 slot은 slot 수에 따라 KV-cache 요구량을 늘립니다. 모델 대부분을 system RAM에서 읽는 구조이므로 GPU 용량뿐 아니라 128GB quad-channel 메모리와 메모리 대역폭도 함께 고려해야 합니다.
섹션별 상세
llama-server \
-m DeepSeek-V4-Flash-0731-UD-Q4_K_XL-00001-of-00005.gguf \
-c 368640 \
-ncmoe 34 \
-ts 100,1,1,1 \
-ot 'blk.(3[4-6]).ffn_.*_exps=CUDA1,blk.(3[7-9]).ffn_.*_exps=CUDA2,blk.(4[0-2]).ffn_.*_exps=CUDA3' \
-ctk q8_0 \
-ctv q8_0 \
-b 2048 \
-ub 2048 \
-np 1 \
-lm none \
--threads 20 \
--flash-attn on4개의 RTX 3060에서 DeepSeek-V4-Flash-0731을 실행하며 Expert와 비Expert 텐서의 배치를 조정한 llama.cpp 실행 명령입니다.
-ub 1024: approximately 63.4 tok/s prompt processing
-ub 2048: approximately 99.4 tok/s prompt processing
Decode remained almost unchanged at approximately 10.1–10.5 tok/s.microbatch 크기를 바꿨을 때 prompt processing과 decode 속도가 어떻게 달라지는지 기록한 측정값입니다.
Context Prefill Decode Minimum free VRAM
376832 99.5 t/s 10.4 t/s 611 MiB
368640 99.4 t/s 10.1 t/s 671 MiB
360448 99.4 t/s 10.1 t/s 735 MiB설정한 context 용량별 prompt 처리 속도, 생성 속도, 부하 상태의 최소 VRAM 여유를 비교한 표입니다.
용어 해설
- 혼합 전문가 모델(MoE)
- — MoE는 하나의 거대한 신경망 전체를 매번 계산하지 않고, 입력에 맞는 일부 Expert만 선택해 처리하는 구조입니다. 이 방식은 모델 규모를 키우면서도 실제 연산량을 줄이지만, Expert 가중치 배치와 메모리 이동이 성능에 큰 영향을 줍니다.
- KV 캐시(KV cache)
- — KV cache는 대화의 이전 토큰에서 계산한 Key와 Value를 저장해 다음 토큰 생성 때 재사용하는 메모리 영역입니다. 긴 context를 유지하려면 크기가 크게 늘어나므로, 이 글에서는 Q8_0 양자화로 저장 공간을 줄이고 GPU 메모리 여유를 확보했습니다.
- GGUF 모델 파일 형식(GGUF)
- — GGUF는 llama.cpp 계열 실행 환경에서 양자화 모델과 메타데이터를 함께 저장하는 파일 형식입니다. 이 글의 DeepSeek-V4-Flash-0731 파일은 약 144GiB 크기의 UD-Q4_K_XL 양자화 버전으로, 대부분을 system RAM에 두고 일부 Expert와 실행용 텐서를 GPU에 배치했습니다.
- 마이크로배치 크기(microbatch size)
- — microbatch size는 한 번에 GPU가 처리하는 토큰 묶음의 크기입니다. 값을 1024에서 2048로 높이자 prompt processing 속도가 약 63.4 tok/s에서 99.4 tok/s로 상승했지만, KV 메모리 사용량도 늘어 context 용량과 GPU 여유 공간 사이의 균형이 필요했습니다.
언급된 도구
DeepSeek-V4-Flash-0731 GGUF 모델을 llama-server로 실행하고 Expert 및 KV 관련 텐서 배치를 조정하는 데 사용했습니다.
AI 요약 · 북마크 · 개인 피드 설정 — 무료
출처 · 인용 안내
인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.
