---
title: "DeepSeek-V2의 효율은 어디서 올까: 계산과 KV 캐시를 나눠 줄이기"
author: "Dne Cna"
published_at: "2026-10-03T10:00:04.850Z"
updated_at: "2026-09-30T08:10:52.834Z"
tags: ["ai","머신러닝","논문리딩","deepseek v2"]
canonical_url: "https://ariser.io/@writer_8706b598dfee/deepseek-v2%EC%9D%98-%ED%9A%A8%EC%9C%A8%EC%9D%80-%EC%96%B4%EB%94%94%EC%84%9C-%EC%98%AC%EA%B9%8C-%EA%B3%84%EC%82%B0%EA%B3%BC-kv-%EC%BA%90%EC%8B%9C%EB%A5%BC-%EB%82%98%EB%88%A0-%EC%A4%84%EC%9D%B4%EA%B8%B0"
ai_assisted: false
---

# DeepSeek-V2의 효율은 어디서 올까: 계산과 KV 캐시를 나눠 줄이기

[원문](https://ariser.io/@writer_8706b598dfee/deepseek-v2%EC%9D%98-%ED%9A%A8%EC%9C%A8%EC%9D%80-%EC%96%B4%EB%94%94%EC%84%9C-%EC%98%AC%EA%B9%8C-%EA%B3%84%EC%82%B0%EA%B3%BC-kv-%EC%BA%90%EC%8B%9C%EB%A5%BC-%EB%82%98%EB%88%A0-%EC%A4%84%EC%9D%B4%EA%B8%B0)

언어 모델 서비스의 비용은 가중치 파일 크기만 보고 계산하기 어렵다. 사용자가 긴 대화를 이어가면 KV 캐시가 커지고, 동시에 처리할 요청이 많아지면 메모리가 먼저 부족해진다. 모델을 한 번 호출하는 계산량을 줄여도 이 병목은 남는다.

DeepSeek-V2 논문이 흥미로운 이유는 두 종류의 비용을 함께 다룬다는 점이다. feed-forward 계산에는 sparse expert를 쓰고, attention에는 key와 value를 함께 압축하는 Multi-head Latent Attention, MLA를 사용한다. 모델을 더 작게 만들기보다, 어디에 큰 표현이 필요하고 어디에 압축된 표현만 남겨도 되는지를 다시 설계한다. [DeepSeek-V2 원문](https://arxiv.org/abs/2405.04434)

## 캐시에서 줄일 수 있는 것은 무엇일까

자기회귀 생성에서는 새 토큰을 만들 때 과거의 key와 value를 읽는다. 매번 이전 토큰을 다시 계산하면 비싸기 때문에 이 값을 캐시에 저장한다. 대화가 길어지면 캐시도 늘어난다. 모델 가중치는 여러 요청이 공유할 수 있어도 각 요청의 문맥은 서로 다르므로, 대화별 캐시는 계속 공간을 차지한다.

설명을 위한 숫자를 잡아 보자. 요청 하나의 캐시가 1GB이고 요청이 열 개라면 10GB가 필요하다. 같은 모델이라도 캐시를 요청당 0.2GB로 줄일 수 있다면, 다른 조건이 같을 때 동시에 처리할 여지가 커진다. 이는 논문의 측정값이 아니라 캐시 압축이 서비스 처리량에 영향을 주는 경로를 설명하기 위한 예다. 실제 공간에는 길이, 배치 관리, 저장 정밀도 같은 변수가 들어간다.

일반적인 multi-head attention에서는 head마다 key와 value를 가진다. 이 표현을 전부 보관하는 대신 MLA는 토큰의 hidden state를 작은 latent vector c로 내려 보낸다. 각 head가 사용할 내용 기반 key와 value는 이 공통 latent에서 선형 변환으로 얻는다. 압축된 표현을 공유하지만, 모든 head가 같은 key와 value를 그대로 쓰는 구조는 아니다.

여기서 중요한 것은 이미 학습한 모델의 캐시를 나중에 아무렇게나 압축한다는 설명과 구분하는 일이다. MLA는 이 구조를 전제로 모델을 학습한다. 제한된 latent 표현으로 attention에 필요한 정보를 전달하도록 projection과 다른 가중치가 함께 조정된다. 저장 공간을 줄이는 일이 학습 목표와 분리된 후처리만은 아니다. [MLA의 구조](https://arxiv.org/html/2405.04434v5#S2.S1)

## 압축을 풀지 않아도 되는 행렬 계산

압축한 key를 읽을 때마다 다시 크게 펼쳐야 한다면, 저장 공간을 줄인 이익 일부를 계산 비용으로 내게 된다. MLA에서 재미있는 부분은 선형 변환을 결합해 이런 복원을 피할 수 있다는 것이다.

내용 기반 key를 k = Uc로 쓰면 attention score의 qᵀk는 qᵀUc = (Uᵀq)ᵀc가 된다. 각 과거 토큰의 큰 k를 만드는 대신 query 쪽을 변환하고 작은 c와 내적할 수 있다. value 쪽의 선형 변환도 출력 projection과 결합할 수 있다. 행렬 곱의 결합 순서를 바꾸는 익숙한 대수가 실제 캐시 설계의 핵심이 된 셈이다.

하지만 위치 정보가 끼면 이야기가 복잡해진다. RoPE는 위치에 따라 query와 key를 회전시키므로, 위치 의존 행렬이 들어간 곱을 일반적인 고정 행렬처럼 흡수할 수 없다. 원문은 이 문제를 해결하려고 내용 경로와 RoPE를 담당하는 경로를 분리한다. 캐시에는 압축된 latent 외에 위치 정보를 담는 key도 남긴다. “latent 하나만 저장한다”는 짧은 설명은 이 부분을 빠뜨릴 수 있다. [분리된 RoPE와 캐시 구성](https://arxiv.org/html/2405.04434v5#S2.S1.S3)

나는 이 대목을 읽을 때 압축률보다 조건이 먼저 보였다. 계산을 합칠 수 있는 이유가 선형성이기 때문이다. 모델 안에서 어떤 변환이 선형이고 어떤 변환이 위치나 입력에 의존하는지 정확히 구분해야 최적화가 성립한다. 논문에 등장하는 캐시 절감은 좋은 저차원 표현과 계산 가능한 형태를 동시에 마련한 결과다.

## expert를 더 잘게 나누고 공통 작업을 따로 두기

다른 축에는 DeepSeekMoE가 있다. 큰 expert 몇 개 대신 더 세분한 expert를 두고 일부를 선택한다. 여러 조합으로 계산할 수 있으니 같은 총량 안에서도 분업의 경우의 수가 달라진다. 여기에 모든 토큰이 거치는 shared expert를 따로 둔다. 여러 routed expert가 반복해 배우기 쉬운 공통 지식을 shared 부분이 맡도록 유도하려는 설계다. [DeepSeekMoE 설명](https://arxiv.org/html/2405.04434v5#S2.S2)

비유하자면 팀마다 회계와 문서 정리 능력을 모두 갖추게 하는 대신, 공통 업무를 담당하는 지원 조직과 특정 업무를 맡는 작은 팀을 함께 두는 모습이다. 물론 신경망이 실제로 그 조직도대로 학습했다는 뜻은 아니다. 공통 계산과 선택 계산을 분리할 수 있는 구조적 통로를 마련했다는 정도로 읽어야 한다.

expert를 잘게 나누면 통신도 생각해야 한다. 선택된 expert가 여러 장치에 흩어져 있으면 토큰을 보내는 비용이 커진다. 원문은 device-limited routing과 부하 균형 장치를 함께 설명한다. sparse 계산으로 산술 연산을 줄이는 것과, 실제 분산 환경에서 빠르게 처리하는 것은 별도의 조건을 가진다.

이 점은 모델 이름에 붙은 활성 파라미터 수를 읽는 방식도 바꾼다. V2는 전체 236B 파라미터 중 토큰당 21B가 활성화된다고 보고한다. 활성 수가 작아도 전체 가중치를 저장하고 배치할 자원은 필요하다. dense 21B 모델과 동일한 메모리나 동일한 단일 장치 배포 조건을 기대할 수는 없다. [공식 모델 설명](https://github.com/deepseek-ai/DeepSeek-V2)

## 성능 향상의 원인을 하나로 고정하지 않기

논문은 영어와 중국어의 언어 이해, 수학, 코드 등 여러 평가와 효율 비교를 보고한다. MLA와 MoE의 구조적 실험은 각 설계의 가능성을 보여 주고, 완성된 V2는 이전 dense 모델 대비 성능과 비용의 개선을 보여 준다. 하지만 최종 모델에는 학습 데이터와 학습 절차의 변화도 포함되어 있다. 모든 개선을 MLA 하나의 효과로 돌리면 비교의 의미가 달라진다. [학습 설정과 평가](https://arxiv.org/html/2405.04434v5#S3)

특히 최대 throughput은 조건이 붙는 값이다. 짧은 요청 한 개의 지연 시간, 긴 문맥의 다중 요청 처리량, 첫 토큰까지의 대기 시간은 서로 다른 지표다. 캐시를 줄여 배치를 키울 수 있으면 처리량은 좋아질 수 있지만, 개별 요청의 모든 단계가 같은 비율로 빨라진다는 뜻은 아니다. 서비스에서 어느 지표가 중요한지 먼저 정해야 논문의 숫자가 유용해진다.

내가 이 논문에서 가져갈 실무 관점은 비용을 세 칸으로 나눠 보는 것이다. 가중치를 올려 두는 비용, 토큰을 계산하는 비용, 대화의 상태를 저장하고 읽는 비용. MoE는 두 번째 칸을 바꾸고 MLA는 세 번째 칸에 직접 손을 댄다. 이 구분은 논문 결과의 단순 요약보다, 구조가 어떤 병목에 답하는지를 읽기 위한 해석이다.

긴 문맥을 사용한다면 모델 선택 때 캐시 사용량과 실제 배치 한도를 함께 측정해 볼 만하다. 반대로 요청이 매우 짧고 동시성이 낮으면 다른 병목이 더 클 수 있다. 아키텍처의 장점은 사용 패턴과 만났을 때 실제 이익이 된다.

DeepSeek-V2는 큰 모델의 비용을 하나의 숫자로 말하기 어렵다는 사실을 잘 보여 준다. 기억할 공간을 압축하는 설계와 필요한 계산만 수행하는 설계가 서로 다른 자리에서 만난다. 논문을 읽고 나면 “모델이 얼마나 큰가”보다 “생성 과정에서 무엇을 저장하고 무엇을 실제로 계산하는가”를 먼저 묻게 된다.

논문: DeepSeek-AI, *DeepSeek-V2: A Strong, Economical, and Efficient Mixture-of-Experts Language Model*, 2024. [원문](https://arxiv.org/abs/2405.04434) · [공식 코드와 모델 안내](https://github.com/deepseek-ai/DeepSeek-V2)