DeepSeek V4는 정말 메모리를 98% 덜 쓸까?

지금 가장 안전한 표현

정확하게 쓰려면 다음 정도가 무난하다.

DeepSeek V4는 Hybrid Attention, Compressed Sparse Attention(CSA), Heavily Compressed Attention(HCA) 등을 통해 장문 추론의 KV cache 부담을 크게 낮추는 방향으로 설계됐다. 그러나 현재 공개 자료만으로 전체 VRAM이 98% 줄었다고 말하기는 어렵다 .

이 차이는 사소하지 않다. KV cache는 긴 문서, 긴 대화, 에이전트형 작업에서 큰 병목이 될 수 있다. 하지만 모델을 실제로 배포하고 서비스할 때 쓰는 메모리는 KV cache만으로 구성되지 않는다.

공식 자료가 실제로 말하는 것

DeepSeek 공식 API 뉴스 페이지는 DeepSeek-V4 Preview가 2026년 4월 24일 공개됐다고 적고 있다 . DeepSeek V4 모델 카드는 V4 계열에 DeepSeek-V4-Pro와 DeepSeek-V4-Flash가 포함되며, V4가 Mixture-of-Experts(MoE, 전문가 혼합) 언어 모델 시리즈라고 설명한다. 또한 DeepSeekMoE framework와 Multi-Token Prediction(MTP) strategy를 유지하면서 Hybrid Attention Architecture 같은 구조 변화를 도입했다고 밝힌다 .

메모리 절감 논의에서 핵심은 장문 컨텍스트의 어텐션 처리다. NVIDIA의 기술 글에 따르면 **Compressed Sparse Attention(CSA)**는 동적 시퀀스 압축으로 KV 엔트리를 압축해 KV cache memory footprint를 줄이고, DeepSeek Sparse Attention(DSA)으로 어텐션 행렬을 더 희소하게 만들어 계산 비용을 낮춘다. **Heavily Compressed Attention(HCA)**는 여러 토큰 묶음의 KV 엔트리를 하나의 압축 엔트리로 합쳐 KV cache 크기를 더 줄이는 방식으로 설명된다 .

따라서 공개 자료가 직접 뒷받침하는 것은 KV cache 크기와 어텐션 계산 비용의 최적화다. 이것이 곧 모든 VRAM 항목이 같은 비율로 줄어든다는 뜻은 아니다.

98%, 90%, 9.5배: 같은 숫자가 아니다

현재 자료에서 **98%**가 가장 직접적으로 보이는 곳은 LinkedIn의 사용자 작성 글이다. 해당 글 제목은 DeepSeek Sparse Attention이 실제 서비스에서 KV 메모리를 98% 줄인다고 주장한다 . 이런 글은 소문의 출처를 추적하는 단서가 될 수는 있지만, DeepSeek의 공식 사양처럼 다루기는 어렵다.

상대적으로 확인하기 쉬운 제3자 숫자는 10% KV cache다. Wccftech는 DeepSeek V4가 DeepSeek V3.2와 비교해 단일 토큰 추론 FLOPs는 27%, key-value(KV) cache는 **10%**만 필요하다고 보도했다 . 이를 KV cache가 10%만 남는다는 뜻으로 읽으면 약 90% 감소다. 그러나 비교 기준은 DeepSeek V3.2이고, 모든 컨텍스트 길이·배치 크기·하드웨어 설정·전체 VRAM에 그대로 적용되는 숫자는 아니다 .

또 다른 뉴스 제목은 DeepSeek V4를 9.5x lower memory requirements라고 표현했다 . 단순 계산으로 1/9.5는 약 10.5%이므로 약 89.5% 감소에 가깝다. 이 역시 98%가 아니며, KV cache를 말하는지, 특정 장문 컨텍스트 조건인지, 전체 배포 메모리인지는 별도로 확인해야 한다 .

왜 KV cache는 전체 VRAM이 아닌가

대형 언어 모델은 토큰을 하나씩 생성하면서 이전 토큰들의 key와 value 정보를 저장해 둔다. 이것이 KV cache다. 컨텍스트가 길어질수록 저장해야 할 과거 정보가 많아지고, 동시 요청이 늘어날수록 서비스 전체의 캐시 부담도 커질 수 있다.

Hugging Face의 DeepSeek V4 소개는 장시간 에이전트형 작업에서 도구 호출 결과가 계속 컨텍스트에 붙고, 이후 토큰은 더 긴 문맥을 상대로 계산해야 한다고 설명한다. 이때 중요한 두 숫자가 단일 토큰 추론 FLOPs와 KV cache 크기이며, 둘 다 시퀀스 길이에 따라 커진다 . Hugging Face의 GitHub 버전도 긴 작업에서 흔한 실패 양상으로 trace가 컨텍스트 예산을 넘거나, KV cache가 GPU를 채우거나, 도구 호출 왕복 때문에 작업이 느려지는 상황을 언급한다 .

하지만 모델 전체를 서비스할 때 VRAM은 KV cache만 쓰지 않는다. 98% 주장을 내건 LinkedIn 글조차 shared weights, expert weights, activations, KV cache, framework overhead를 별도 항목으로 나눠 제시한다 . 이 구분이 중요하다. 특정 장문 추론 조건에서 KV cache가 크게 줄어도, 모델 가중치·activation·프레임워크 오버헤드까지 같은 비율로 줄었다고 말할 수는 없다.

CSA와 HCA는 효율 설계이지 마법의 숫자가 아니다

DeepSeek V4의 기술 방향은 충분히 주목할 만하다. 특히 백만 토큰급 컨텍스트처럼 긴 시퀀스에서 비싸지는 어텐션과 KV cache 문제를 정면으로 다룬다. NVIDIA 설명에 따르면 V4는 KV 엔트리 압축, 어텐션 행렬 희소화, 여러 토큰 집합의 KV 엔트리 병합을 통해 KV cache 크기와 계산 오버헤드를 줄인다 .

DeepSeek V4 기술 보고서도 훈련과 추론 인프라 최적화를 언급한다. 예를 들어 MoE 모듈을 위한 single fused kernel을 설계해 computation, communication, memory access가 겹쳐 실행되도록 했다고 설명한다 . 이런 작업은 의미 있는 효율 엔지니어링이다. 다만 그것만으로 전체 VRAM 98% 절감을 입증하지는 않는다.

실제 평가에서는 무엇을 봐야 하나

DeepSeek V4를 긴 문서 분석, 장기 대화, 에이전트 워크플로에 쓰려는 팀이라면 98%라는 제목보다 먼저 병목이 어디에 있는지 확인해야 한다. 공개 자료만으로는 V4가 장문 컨텍스트의 KV cache를 줄이는 데 강점을 갖는다는 말까지가 안전하다. 반대로 이를 전체 배포 메모리의 98% 절감으로 구매 사양, 용량 산정, 외부 마케팅 문구에 쓰기에는 근거가 부족하다 .

실무적으로는 다음 항목을 같은 조건에서 벤치마크하는 편이 낫다.

• 실제 입력 컨텍스트 길이와 출력 길이
• 배치 크기와 동시 요청 수
• 서빙 엔진의 KV cache 구현과 정밀도 설정
• GPU 또는 가속기의 VRAM 배치 방식
• 모델 가중치, activation, 프레임워크 오버헤드 비중
• 평균값뿐 아니라 긴 요청에서의 지연 시간과 메모리 피크

당신의 워크로드가 주로 KV cache에 막힌다면 V4의 압축 설계는 큰 의미가 있을 수 있다. 그러나 병목이 모델 가중치, activation, 프레임워크 오버헤드, 동시성 전략에 있다면 KV cache 감소가 곧바로 같은 비율의 총 VRAM 절감으로 이어지지는 않는다 .