단일 RTX 4090에서 64k 컨텍스트로 실행되는 DeepSeek V4 Flash (UD-Q3_K_M) — 설정 및 측정 수치
요약
RTX 4090과 128GB RAM 환경에서 DeepSeek V4 Flash 모델을 64k 컨텍스트로 실행한 설정과 성능 측정 결과를 공유합니다. MoE 구조를 활용해 어텐션과 KV 캐시는 GPU에, 전문가 FFN은 시스템 RAM에 배치하는 최적화 방식을 다룹니다.
핵심 포인트
- DeepSeek V4 Flash(UD-Q3_K_M) 실행을 위해 128GB RAM 필수
- RTX 4090의 VRAM을 어텐션 가중치 및 KV 캐시 저장에 활용
- MoE 구조 최적화를 통해 생성 속도 12.0–13.1 t/s 달성
- llama.cpp를 이용한 구체적인 실행 설정 및 파라미터 제공
토론 목적이라기보다는 기록(documentation)을 위해 이 글을 게시합니다. 이 조합에 대한 수치를 어디에서도 찾을 수 없었기에, 제가 정확히 무엇을 실행하고, 무엇이 들어맞으며, 어떻게 작동하는지 공유합니다. 유용하다면 설정을 복사해 사용하시고, 틀린 부분이 있다면 수정해 주세요.
하드웨어
GPU: RTX 4090, 24 GB
CPU: Intel Core i9-13900K (8 P-cores + 16 E-cores, 32 threads)
RAM: 128 GB DDR5 (4 x 32 GB Kingston Fury, 정격 5600, 5200으로 동작), 듀얼 채널
OS: Windows 11 Pro
llama.cpp 빌드: 10240 ( 0b14b87d7 ), Clang 20.1.8, Windows x86_64
128 GB의 RAM은 여유 공간이 아니라 필수 요구 사항입니다. UD-Q3_K_M은 4개의 샤드(shards)에 걸쳐 121 GB를 차지합니다. GPU는 어텐션 가중치(attention weights)와 KV 캐시(KV cache)를 보유하며, 그 외의 모든 것은 시스템 RAM에 위치합니다.
모델이 로드되어 서비스 중일 때 측정된 수치:
| 이름 | WorkingSetGB | PrivateGB |
|---|---|---|
| llama-server | 103.2 | 127.7 |
103 GB 상주(resident), 128 GB 커밋(committed) — 기계 전체를 사용합니다. 두 수치 사이의 약 24 GB 차이는 VRAM에 들어있는 양과 밀접하게 일치하는데, 이는 GPU 상주 텐서(tensors)가 업로드된 후 호스트 측 복사본이 제거되는 것으로 해석됩니다. 어느 쪽이든: 이 양자화(quant) 버전은 64 GB에서는 실행되지 않으며, 128 GB에서는 남는 공간이 전혀 없습니다.
실행 중인 모델: unsloth/DeepSeek-V4-Flash-GGUF:UD-Q3_K_M (65536 컨텍스트, KV 캐시는 q8_0로 양자화, 단일 슬롯).
24 GB VRAM 중 22483–22836 MiB가 안정적으로 사용 중입니다.
--no-mmap 사용 시 로드 시간은 약 60초입니다.
설정(config):
llama-server.exe ^
-hf unsloth/DeepSeek-V4-Flash-GGUF:UD-Q3_K_M ^
--host 127.0.0.1 ^
--port 8096 ^
-c 65536 ^
-np 1 ^
-ngl 999 ^
--n-cpu-moe 39 ^
--flash-attn auto ^
--cache-type-k q8_0 ^
--cache-type-v q8_0 ^
-ub 2048 ^
-b 4096 ^
-t 24 ^
-tb 24 ^
--jinja ^
--no-mmap ^
--metrics ^
--temp 1.0 ^
--top-k 20 ^
--top-p 0.95 ^
--min-p 0.0
아이디어는 MoE(Mixture of Experts)의 일반적인 방식과 같습니다: 어텐션(attention)과 KV 캐시는 GPU에, 전문가 FFN(expert FFNs)은 시스템 RAM에 배치합니다. -ngl 999는 모든 것을 GPU로 보내고, --n-cpu-moe 39는 예외적으로 처음 39개 블록의 전문가들을 할당합니다. 샘플링(Sampling) 값은 권장 사항이 아니라 DeepSeek 자체 모델 카드(model-card)의 기본값입니다.
측정된 처리량(Throughput) 아래의 모든 수치는 위 설정으로 1시간 동안 연속 실행한 결과입니다.
| 항목 | 수치 |
|---|---|
| 생성 (Generation) | 12.0–13.1 t/s |
| 프롬프트 처리 (Prompt processing), 8k–32k 토큰 | 212–224 t/s |
| 프롬프트 처리 (Prompt processing), 1k–5k 토큰 | 153–210 t/s |
| 프롬프트 처리 (Prompt processing), 1k 미만 | 15–115 t/s |
생성 속도는 한 시간 내내 일정했습니다 — 드리프트(drift)나 성능 저하(degradation)가 없었으며, VRAM은 실행 간의 증가 없이 22483–22836 MiB로 안정적이었습니다. 마지막 행은 처리량이 아니라 요청당 고정 오버헤드(fixed per-request overhead)입니다: 41토큰 프롬프트는 15 t/s로 "실행"되며 여전히 3초 이내에 완료됩니다. 작업 부하(workload)가 매우 작은 요청들로 구성된 경우가 아니라면 이 수치는 무시하십시오. 여기서 생성 속도는 GPU나 코어 수에 의한 것이 아니라, CPU가 시스템 RAM에서 활성 전문가(active experts)를 얼마나 빠르게 스트리밍할 수 있는지에 의해 제한될 가능성이 높습니다. 이것이 성능이 매우 안정적인 이유를 설명해 줍니다. 13900K는 하이브리드 부품이며 -t 24 설정은 P-코어(P-cores)와 E-코어(E-cores) 모두를 아우르기 때문에, 빠른 코어가 느린 코어를 기다리게 될 수도 있습니다. 제가 직접 측정하지는 않았지만, 하이브리드 Intel CPU를 사용 중이라면 더 많은 코어가 더 낫다고 가정하기 전에 -t 8과 -t 16을 먼저 시도해 보십시오.
실제로 시간이 어디에 소요되는가: 저는 에이전트 코딩 하네스(agentic coding harnesses, OpenCode, Pi, Qwen Code)를 통해 이를 구동하고 있습니다. 턴(Turn)은 매우 다른 두 가지 형태를 띱니다.
프롬프트 제한적 턴(Prompt-bound turns) — 에이전트가 긴 대화 내용을 다시 읽은 다음, 도구 호출과 같이 짧은 작업을 수행하는 경우입니다. 접두사 캐시(Prefix cache)는 이 경우에 도움이 되지 않았으므로 전체 컨텍스트가 다시 처리되었습니다:
| 컨텍스트 재처리 (Context reprocessed) | 프롬프트 평가 (Prompt eval) | 생성 (Generation) | 시간 (Time) | 프롬프트에 소비된 비중 (Share spent on prompt) |
|---|---|---|---|---|
| 32284 tok | 146 s | 303 tok | 25 s | 85 % |
| 28403 tok | 127 s | 263 tok | 21 s | 86 % |
| 18862 tok | 89 s | 256 tok | 21 s | 81 % |
이 함축적 의미를 주목하십시오: 첫 번째 토큰이 나오는 데 2분 30초가 걸릴 수 있습니다. 응답이 1분 이내에 시작될 것이라고 가정하는 클라이언트는 서버가 정상적으로 작동하는 동안 연결을 끊어버릴 것입니다.
생성 제한적 턴(Generation-bound turns)은 그 반대입니다: 한 턴에서 3358토큰 프롬프트를 18초 만에 처리한 후 4610토큰을 연속으로 생성했습니다 — 378초가 소요되었으며, 프롬프트 평가(prompt eval)는 턴의 5%만을 차지했습니다. 전체 파일을 작성할 때 12 t/s의 속도가 실제로 고통스럽게 다가옵니다.
실제 작업에 소요되는 시간
세 가지 서로 다른 에이전트 하네스(agent harnesses)를 사용하여 동일한 작업을 각각 한 번씩 실행했습니다. 각 에이전트는 코드를 작성하고, 실행하고, 보고서와 도표를 생성해야 했습니다. 이는 멀티 턴(multi-turn), 수십 번의 도구 호출(tool calls), 그리고 약 30k 토큰까지 늘어나는 컨텍스트(context)를 포함합니다.
| 하네스 | 실제 소요 시간(wall clock) |
|---|---|
| Opencode | 896초 완료 |
| Pi | 1088초 완료 |
| Qwen Code | 1570초 완료 |
12 t/s의 속도로 전체 에이전트 작업(agentic task)을 수행하는 데 15분에서 26분이 소요되었습니다. 이것이 "사용 가능한가요?"라는 질문에 대한 솔직한 답변입니다. — 네, 키보드 앞에서 잠시 자리를 비울 용의가 있다면 가능합니다. 하네스 간의 편차는 서버 튜닝을 통해 얻은 그 어떤 결과보다 컸으며, 이는 설정을 조정하며 저녁 시간을 허비하기 전에 반드시 알아두어야 할 사실입니다.
튜닝 순서
- 컨텍스트가 실제로 가득 찼을 때(로드 시점이 아닌 실제 사용 시점) OOM(Out of Memory)이 발생하지 않는 가장 낮은
--n-cpu-moe값을 찾으세요. - 로딩 시점이 피크(peak)가 아닙니다. 그 다음, 남은 VRAM만큼
-ub를 높이세요. -b >= -ub를 유지하세요.-c또한 메모리 조절 노브(knob)입니다. 컨텍스트를 절반으로 줄이면 많은 양의 KV 캐시(KV cache)를 확보할 수 있으며 생성 속도에는 영향을 주지 않으므로, 레이어(layers)를 CPU로 넘기기 전에 이 방법을 먼저 시도해 보세요.- 이 구성에서는
--no-mmap이 실질적인 역할을 합니다. 전문가 텐서(expert tensors)는 매 토큰마다 읽히는데, 이들이 페이지 캐시(page-cache)에 의해 관리되어 교체(evictable)되는 상황을 원치 않기 때문입니다. 60초의 로딩 시간은 그에 따른 대가입니다. - 도구 호출(tool calling)을 수행한다면
--jinja는 선택 사항이 아닙니다. 모델 자체의 채팅 템플릿(chat template)이 없으면 모델의 능력이 부족한 것처럼 보이는 이상한 오류가 발생합니다.
제가 주장하지 않는 것
단일 머신, 단일 양자화(single quant), 단일 워크로드입니다. 여기에는 품질 벤치마크(quality benchmarks)가 포함되어 있지 않으며, 오직 처리량(throughput) 및 적합성 보고서일 뿐입니다. 만약 동일한 그래픽 카드를 사용하지만 RAM 사양이 다르다면, 비교해야 할 흥미로운 지표는 생성 수치(generation number)가 될 것입니다.
/u/HomoAgens1 제출 [링크] [댓글]
AI 자동 생성 콘텐츠
본 콘텐츠는 r/LocalLLaMA의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기