DeepSeek-V4.1-Flash가 공개한 숫자 중 메모리 반도체 관점에서 가장 중요한 것은 벤치마크 점수가 아닙니다. global KV 캐시가 토큰당 890바이트라는 수치입니다. DeepSeek는 이전 V4 Flash의 25% 수준, 초기 V1의 0.23% 수준이라고 설명합니다.
이 숫자만 보면 “AI 모델이 발전할수록 HBM 수요가 줄어든다”는 결론이 나오기 쉽습니다. 하지만 더 정확한 해석은 다릅니다. 요청 하나가 점유하는 메모리는 크게 줄었지만, 같은 장비가 처리할 수 있는 긴 문맥과 동시 요청은 그만큼 늘어날 수 있습니다. 메모리 수요의 단위가 ‘토큰당 바이트’에서 ‘서버당 처리 토큰’으로 이동하는 변화입니다.
확인된 사실과 숫자
890바이트를 100만 토큰으로 환산하면
DeepSeek-V4.1-Flash는 최대 100만 토큰 문맥을 지원합니다. 회사가 제시한 global KV 캐시만 단순히 곱하면 다음과 같습니다.
890 bytes/token × 1,000,000 tokens = 890 MB
이진 단위로는 약 0.83GiB입니다. 같은 최대 문맥 요청 100개를 동시에 유지한다면 global KV 캐시만 약 89GB, 즉 82.9GiB가 됩니다. 이전 V4 Flash가 같은 조건에서 약 4배를 사용했다는 회사 비교를 적용하면 100개 요청에 약 356GB입니다.
이 계산은 실제 GPU 메모리 사용량이 아닙니다. 모델 가중치, 활성값, 로컬·슬라이딩 윈도 KV, 인덱서 상태, 메모리 정렬과 할당 오버헤드는 포함하지 않습니다. 890바이트는 DeepSeek가 정의한 global KV 캐시의 토큰당 크기입니다. 따라서 “100만 토큰 모델 전체가 0.83GiB에서 돈다”로 읽으면 틀립니다.
어떻게 줄였나: 저장할 캐시 자체를 바꿨습니다
V4.1 Flash는 20층 causal encoder와 20층 decoder로 구성된 Causal Encoder-Decoder 구조를 씁니다. 각 decoder 층이 자기 hidden state에서 별도의 global KV를 만드는 대신, 마지막 encoder hidden state에서 decoder global KV를 투영합니다.
여기에 세 가지 방식이 겹칩니다.
- SWA Bounded Replay는 sliding-window attention의 KV를 SSD에 계속 보존하지 않고, 필요할 때 최근 윈도만 제한적으로 다시 계산합니다. DeepSeek는 persistent KV cache footprint가 이전 V4 Flash의 12.5% 수준이라고 설명합니다.
- CSA2는 attention 층을 Full·Reindex·Reuse로 나누고 main KV, indexer K, Top-K 결과를 층 사이에서 공유합니다.
- FP4 main KV caching은 main KV를 4비트 형식으로 저장합니다.
즉 단순한 양자화 하나의 효과가 아닙니다. 무엇을 저장하고, 어느 층에서 공유하고, 무엇을 다시 계산할지까지 함께 바꾼 결과입니다.
관계와 해석
HBM에는 단기 악재와 장기 상쇄 요인이 같이 있습니다
첫 번째 효과는 분명합니다. 동일한 문맥 길이와 동시 요청 수를 전제로 하면 KV 캐시 때문에 필요한 HBM 용량은 줄어듭니다. 긴 문맥 서비스가 HBM 용량 부족 때문에 GPU를 더 붙이던 경우라면, 토큰당 4분의 1은 서버당 HBM 탑재량이나 GPU 수를 낮추는 압력입니다.
하지만 두 번째 효과는 반대 방향입니다. 같은 HBM으로 더 많은 요청을 동시에 처리하거나 문맥을 더 길게 유지할 수 있습니다. 에이전트가 코드 저장소·문서·도구 결과를 반복해서 읽는 서비스에서는 단위 비용 하락이 사용량 증가를 만들 수 있습니다. 토큰당 메모리는 줄어도 서버당 처리 토큰과 전체 추론 서버 수가 더 빨리 늘면 총 HBM 비트 수요는 계속 증가할 수 있습니다.
세 번째로 모델 자체는 작아지지 않았습니다. V4.1 Flash는 552B backbone과 196B Engram parameter를 공개했고, prefill에는 토큰당 8B, decode에는 16B parameter를 활성화합니다. 이전 V4 Flash의 284B backbone보다 총 보유 가중치는 커졌습니다. 활성 parameter 감소는 계산량에 중요하지만, 전체 가중치를 어느 메모리·스토리지 계층에 둘지는 별도 문제입니다.
따라서 이번 발표는 “HBM 수요 감소”보다 HBM 용량 효율이 빠르게 개선되고 있다는 신호로 읽는 편이 정확합니다. HBM 업체를 볼 때는 모델 하나의 KV 압축률보다 가속기 출하량, GPU당 HBM 용량, 동시 요청 증가율, 평균 문맥 길이를 함께 봐야 합니다.
서버 DRAM과 SSD는 역할이 더 선명해집니다
persistent KV를 이전의 8분의 1로 줄였다는 설명은 KV offload용 SSD와 호스트 DRAM의 요청당 수요에도 하방 압력입니다. 캐시를 멀리 내렸다가 다시 올리는 대신 최근 구간을 재계산하는 선택이 가능해졌기 때문입니다.
반면 552B backbone과 196B Engram은 큰 가중치·조건부 메모리 계층을 요구합니다. 모든 parameter가 매 토큰 활성화되지는 않더라도 어딘가에는 저장되어 있어야 합니다. 그래서 SSD와 서버 DRAM의 역할이 사라진다기보다 KV 보관소에서 대규모 가중치·Engram 공급 계층으로 이동할 가능성이 있습니다.
메모리 반도체별로 보면 다음 구분이 필요합니다.
| 메모리 계층 | 토큰당 KV 압축의 직접 효과 | 수요를 다시 키울 변수 |
|---|---|---|
| HBM | 요청당 KV 용량 감소 | 동시 요청·문맥·가속기 출하 증가, 더 큰 모델 가중치 |
| 서버 DRAM | KV offload working set 감소 | CPU orchestration, 큰 모델 staging, 총 서버 수 증가 |
| SSD | persistent KV write/read 감소 가능 | 552B backbone·196B Engram 저장, checkpoint·데이터 공급 |
아직 확정되지 않은 것과 반증 조건
890바이트와 4배·437배 비교는 DeepSeek의 모델 카드와 기술 보고서 수치입니다. 독립적인 vLLM·SGLang production 측정으로 allocator overhead, local KV, 실제 동시성까지 포함한 GPU 메모리 절감률이 확인된 것은 아닙니다. 구현체가 새 구조를 얼마나 효율적으로 지원하는지도 초기 단계입니다.
이 해석이 틀렸다고 판단할 조건은 세 가지입니다.
- 독립 serving 측정에서 전체 KV 관련 메모리가 이전 V4 Flash 대비 크게 줄지 않을 때
- 긴 문맥·에이전트 사용 증가가 용량 효율 개선보다 느려 총 처리 토큰이 늘지 않을 때
- 재계산 비용 때문에 처리량·전력 효율이 나빠져 캐시 절감이 서버 비용 감소로 이어지지 않을 때
다음에 확인할 숫자
확인 대상은 동일 GPU·동일 정밀도에서 1M context 요청당 전체 GPU 메모리, 동시 요청 수, tokens/s, 전력, host DRAM·SSD traffic입니다. 그 수치가 나와야 이번 구조가 HBM 비트 수요를 실제로 줄이는지, 아니면 더 많은 추론을 같은 HBM에 밀어 넣어 총수요를 키우는지 구분할 수 있습니다.
결론은 단순한 수요 감소가 아닙니다. DeepSeek-V4.1-Flash는 KV 캐시를 토큰당 890바이트까지 줄이면서 메모리 효율 개선 속도가 모델과 트래픽 성장률을 따라잡을 수 있는가라는 새로운 기준을 제시했습니다. 메모리 투자자는 토큰당 바이트 하나보다 토큰당 바이트 × 동시 요청 × 평균 문맥 × 서버 수를 봐야 합니다.
내부 링크와 공식 근거
기존 기준선은 128K 추론의 KV 캐시 40GiB 분석과 계층형 메모리에서 비교할 수 있습니다.
- frontmatter의 DeepSeek-V4.1-Flash 공식 Hugging Face 저장소 — 552B backbone, 1M context, 890 bytes/token, V4 Flash·V1 대비 KV 비교
- 같은 공식 저장소의
DeepSeek_V41_Tech_Report.pdf— CED, SWA Bounded Replay, CSA2, FP4 KV 구조와 평가 조건
이 리포트는 회사가 공개한 모델 카드와 기술 보고서를 바탕으로 작성한 교육용 분석이며 특정 종목의 매수·매도를 권하지 않습니다.
밑줄 친 말은 용어 위키로 이어집니다.