DeepSeek 4-bit 모델의 Expert 캐시 교체 실험

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

작성자는 2개의 RTX3090과 1개의 RTX3060, 128GB RAM 환경에서 140GB가 넘는 DeepSeek-V4-Flash-0731 4-bit MoE 모델을 llama.cpp로 실행하며 Expert 캐시 교체 방식을 실험했습니다. VRAM으로 이동한 Expert의 RAM 캐시를 해제하고 필요할 때 SSD에서 다시 읽도록 두 패치를 적용한 뒤 dflash drafter와 캐시 예산을 조정해 생성 속도를 7토큰에서 낮은 20토큰대까지 높였지만, 프롬프트 처리는 60토큰/초 아래에 머물렀습니다. 긴 프롬프트에 AD-IQ2_M을 별도로 사용하자 프롬프트 처리 단계는 약 200토큰/초까지 빨라졌으나 모델 간 캐시를 재구축해야 해 30K토큰 이상의 입력에서만 전체 이득이 나타났습니다. 두 브랜치와 실행 명령은 GitHub에 공개됐습니다.

커뮤니티 반응

작성자는 두 개의 llama.cpp 브랜치와 실행 명령을 공개해 다른 사용자가 동일한 Expert 캐시 교체 구조를 시험하거나 더 나은 하드웨어에서 재현할 수 있게 했습니다. 게시글에서 확인되는 반응은 주로 실험 아이디어와 구현을 공유하는 데 초점이 있으며, 제안한 프롬프트 처리 전용 모델 방식은 캐시 재구축 비용 때문에 조건부 효과만 보였습니다.

주요 논점

01찬성소수

RAM과 VRAM에 같은 Expert 캐시를 중복 보관하지 않고 필요할 때만 SSD에서 읽는 방식은 4-bit MoE 모델을 제한된 메모리에서 실행하는 현실적인 최적화로 평가됩니다. 작성자의 패치와 캐시 예산 조정 뒤 생성 속도가 7토큰에서 낮은 20토큰대까지 오른 수치가 근거입니다.

02찬성소수

긴 프롬프트 처리에 더 작은 양자화 모델을 일시적으로 사용하는 방식은 프롬프트 처리 단계와 토큰 생성 단계의 병목이 다를 때 유효할 수 있습니다. AD-IQ2_M이 일부 설정에서 약 200토큰/초를 기록했으며, 30K토큰 이상에서는 전체 처리 시간이 개선됐습니다.

03반대소수

프롬프트 처리 모델과 원래 생성 모델 사이에서 Expert ID만 넘기는 방식은 실제 활성 캐시를 보존하지 못해 디코딩 초기에 큰 비용을 만듭니다. 그 결과 처음 약 1,000토큰의 생성 속도가 낮아지고, 짧은 프롬프트에서는 프롬프트 처리 모델을 교체하는 이득이 사라졌습니다.

합의점 vs 논쟁점

합의점

4-bit 양자화 모델은 작성자의 128GB RAM과 GPU 메모리를 합친 용량보다 컸기 때문에 SSD 접근이 병목으로 작용했습니다. Expert 배치만 조정하는 것으로는 SSD에서 발생하는 캐시 미스를 없애지 못했습니다. 모델 크기와 RAM·VRAM·SSD의 실제 구성을 함께 측정해야 속도 차이를 해석할 수 있습니다.
RAM과 VRAM에 Expert 캐시를 동시에 유지하면 사용 가능한 메모리가 줄어들고 교체 효율이 떨어집니다. VRAM으로 이동한 Expert의 RAM 캐시를 해제하고, 다시 필요할 때 SSD에서 읽어 RAM에 고정하는 방식이 작성자의 실험에서 더 높은 생성 속도로 이어졌습니다. 다만 결과는 캐시 예산과 하드웨어 구성에 따라 달라집니다.

논쟁점

프롬프트 처리에 낮은 양자화 모델을 사용한 뒤 높은 양자화 모델로 디코딩을 이어가는 방식은 긴 입력에서만 이점이 나타났습니다. AD-IQ2_M에서 만든 KV 캐시를 원래 모델이 그대로 활용하지 못하고 Expert 캐시를 다시 구성해야 했기 때문입니다. 따라서 낮은 품질의 초기 캐시가 긴 디코딩 과정에서 회복된다는 전제를 실제 품질 평가 없이 일반화하기는 어렵습니다.
프롬프트 처리를 원격 서비스에서 수행하고 KV 캐시를 로컬 디코딩으로 이어가는 구상은 비용과 네트워크 전송량을 줄일 가능성이 있지만, 게시글에서는 구현이나 측정 결과가 제시되지 않았습니다. 원격 처리 후 로컬에서 캐시를 호환하는 방법도 확인되지 않았습니다. 현재는 후속 실험 아이디어에 해당합니다.

실용적 조언

DeepSeek-V4-Flash-0731의 대형 양자화를 시험할 때는 GPU 수와 모델별 메모리뿐 아니라 PCIe 채널, RAM 구성, SSD 읽기 성능, 컨텍스트 길이를 함께 기록해야 합니다. 게시글의 환경은 2개의 RTX3090과 1개의 RTX3060, 128GB DDR5, 156K 컨텍스트였으며 이 조건에서 SSD 접근이 주요 병목으로 나타났습니다.
llama.cpp에서 Expert 캐시를 사용할 때는 GGML_CUDA_MOE_CACHE_BUDGET_MB, GGML_CUDA_MOE_CACHE_BUDGET_MB_DEVICES, GGML_CUDA_MOE_CACHE_MLOCK, GGML_CUDA_MOE_CACHE_ELITE_PCT 같은 설정을 하드웨어에 맞춰 조정해야 합니다. 작성자는 캐시 예산을 40000MB로 두고 특정 장치 예산을 11800MB로 설정했으며, mlock과 Expert 수요 감쇠 값도 함께 지정했습니다. 동일한 수치를 그대로 적용하기보다 캐시 통계와 생성 속도를 함께 비교해야 합니다.
긴 입력에서만 별도 프롬프트 처리 모델을 활성화하도록 최소 토큰 수를 설정하는 편이 적합합니다. 게시글의 두 번째 브랜치는 --prompt-processing-min-tokens 8192와 AD-IQ2_M을 사용했지만, 30K 미만 입력에서는 모델 교체와 초기 캐시 재구축 비용이 이득을 상쇄했습니다. 실제 적용 전에는 프롬프트 길이별 처리 속도와 디코딩 첫 1,000토큰의 속도를 분리해 측정해야 합니다.

섹션별 상세

작성자는 2개의 RTX3090과 1개의 RTX3060, 128GB DDR5, SSD 2개를 갖춘 환경에서 DeepSeek-V4-Flash-0731의 4-bit 양자화를 156K 컨텍스트로 실행하려 했습니다. 초기 4-bit 계열에서는 Expert를 GPU에 배치하고 SSD 병렬 읽기를 추가해도 초당 생성 7토큰과 프롬프트 처리 약 20토큰에 그쳤고, leloch의 llama.cpp를 기반으로 한 AtomicChat 3-bit 양자화에서는 낮은 10토큰대까지 올라갔습니다. 그러나 4-bit 양자화는 모델 크기가 140GB를 넘어 RAM보다 컸기 때문에 SSD 접근을 피하면서 원본 Expert를 최대한 보존하는 방법이 핵심 과제가 됐습니다.

bash

sudo 'ulimit -l unlimited && \

GGML_CUDA_MOE_CACHE_RESERVE_MB=512 \

GGML_CUDA_MOE_CACHE_ADMIT_AFTER=1 GGML_CUDA_MOE_CACHE_INSERTS=256 \

GGML_CUDA_MOE_CACHE_QUEUE_MB=2048 \

GGML_CUDA_MOE_CACHE_MODE=on \

GGML_CUDA_MOE_CACHE_BUDGET_MB=40000 \

GGML_CUDA_MOE_CACHE_BUDGET_MB_DEVICES=0:11800 \

GGML_CUDA_MOE_CACHE_STATS=1024 \

GGML_CUDA_MOE_CACHE_MLOCK=1 \

GGML_CUDA_MOE_CACHE_ELITE_PCT=60 \

GGML_CUDA_MOE_CACHE_DEMAND_DECAY=4096 \

./llama.cpp/build/bin/llama-server \

  --spec-type draft-dspark \

  -c 167936 --parallel 1 \

  --split-mode layer \

  -b 4096 -ub 4096 --flash-attn on \

  --moe-cache auto'

첫 번째 moe-cache-ousemma 브랜치에서 Expert 캐시 예산과 메모리 잠금 정책을 설정하고 llama.cpp 서버를 실행하는 명령입니다.

Expert가 VRAM으로 이동한 뒤에도 RAM에 같은 캐시를 남겨두던 중복 구조가 메모리 부족과 SSD 페이지 캐시 미스를 유발했습니다. 작성자의 두 패치는 VRAM으로 승격된 Expert의 RAM 캐시를 잠금 해제해 다른 데이터가 그 자리를 사용하게 하고, VRAM에서 내려온 Expert는 실제로 필요해진 순간 SSD에서 읽은 뒤 mlock으로 RAM에 고정합니다. 같은 Expert를 RAM과 VRAM에 동시에 보관하지 않는 방식으로 메모리 중복을 줄였고, dflash drafter를 host RAM에 고정하고 VRAM 캐시 예산을 조정한 결과 생성 속도가 낮은 20토큰대까지 상승했습니다.

bash

sudo 'ulimit -l unlimited && \

LLAMA_EXPERT_SWAP_NO_PRELOAD=0 \

LLAMA_EXPERT_SWAP_PREFETCH=1 \

LLAMA_EXPERT_SWAP_MLOCK=1 \

/home/ous/infra/llama.cpp/build/bin/llama-server \

  --prompt-processing-model /home/.cache/huggingface/hub/models--AtomicChat--DeepSeek-V4-Flash-0731-GGUF/snapshots/5f8e5b74544ad821d71aedf658c2b8acdecd4b2b/AD-IQ2_M/DeepSeek-V4-Flash-0731-AD-IQ2_M-00001-of-00004.gguf \

  --prompt-processing-min-tokens 8192 \

  --moe-cache auto \

  --prompt-processing-gpu-moe 0'

긴 프롬프트를 처리할 때만 AtomicChat의 AD-IQ2_M 양자화 모델을 사용하도록 설정한 두 번째 브랜치의 핵심 명령입니다.

프롬프트 처리 속도는 캐시 튜닝과 배치 크기 조정만으로 60토큰/초 아래에서 개선되지 않았습니다. 이에 작성자는 8,192토큰 이상인 긴 프롬프트에 한해 AD-IQ2_M을 프롬프트 처리 전용 모델로 로드하고, 처리가 끝나면 원래의 UD-Q4_K_XL 모델로 되돌리는 방식을 실험했습니다. AD-IQ2_M 단계 자체는 일부 설정에서 약 200토큰/초에 도달했지만, 두 모델 사이에서 Expert ID만 전달해도 실제 캐시는 처음부터 다시 만들어야 했고 디코딩 초기 약 1,000토큰의 속도가 낮아 30K토큰 이상에서만 전체 프롬프트 처리 시간이 의미 있게 나아졌습니다.

용어 해설

Mixture of Experts: — 하나의 거대한 모델을 여러 Expert로 나누고 토큰마다 일부 Expert만 선택해 계산하는 구조입니다. 선택된 Expert의 가중치를 VRAM에 올리고 나머지를 RAM이나 SSD에서 교체하면 제한된 메모리에서도 모델을 실행할 수 있지만, 교체 비용이 성능을 좌우합니다.
커널 페이지 캐시(Kernel Page Cache): — 운영체제가 파일에서 읽은 데이터를 메모리에 임시 보관해 이후 접근을 빠르게 만드는 계층입니다. 모델 Expert를 RAM에 고정한다고 해도 캐시 정책과 메모리 잠금 상태에 따라 SSD 재읽기가 발생할 수 있어 대형 양자화 모델의 토큰 생성 속도에 영향을 줍니다.
추측 디코딩(Speculative Decoding): — 작은 초안 모델이 다음 토큰 후보를 먼저 만들고 큰 모델이 이를 검증해 한 번에 여러 토큰을 처리하는 추론 방식입니다. 글에서는 dflash drafter를 사용해 Expert 교체로 낮아진 생성 속도를 보완했으며, 1,000토큰 이상 생성할 때 초당 토큰 수가 낮은 20대까지 올라갔습니다.
메모리 잠금(mlock): — 프로세스의 메모리 페이지가 운영체제에 의해 디스크로 교체되지 않도록 고정하는 기능입니다. 글의 패치는 VRAM으로 승격된 Expert의 RAM 캐시를 잠금 해제하고, VRAM에서 내려온 Expert를 필요할 때 SSD에서 읽은 뒤 다시 잠가 RAM과 VRAM에 같은 Expert가 중복 보관되지 않게 합니다.
양자화(Quantization): — 모델 가중치를 더 적은 비트로 표현해 저장 공간과 메모리 사용량을 줄이는 기법입니다. 글에서는 원본 Expert를 많이 보존하는 4-bit 계열과 더 작은 3-bit 및 IQ_2M 양자화를 서로 다른 추론 단계에 배치해 메모리와 속도를 조정했습니다.

언급된 도구

llama.cpp추천링크

DeepSeek-V4-Flash-0731 GGUF 모델을 실행하고 MoE Expert 캐시 교체, 프롬프트 처리 모델 전환, dflash 기반 추측 디코딩을 적용하는 추론 프레임워크입니다.

언급된 리소스

GitHuboussemah/llama.cpp moe-cache-ousemma