100만 토큰을 0.9GB에, 딥시크 V4.1 논문이 KV 캐시를 줄인 방법

딥시크는 9월 10일 공식 계정에서 V4.1-Flash를 새 구조 계열의 가장 작은 모델로 소개했습니다. 이미지를 직접 이해하고, 더 빨리 추론하고, 처리량이 높고, 더 큰 모델로 키울 수 있게 설계했다는 설명입니다. 같은 날 API 문서에는 KV 캐시가 이전 세대보다 GPU 메모리(HBM)는 4분의 1, SSD 저장 용량은 8분의 1만 쓴다고 적었고, 에이전트 비용에서 캐시 적중 요금이 큰 비중을 차지해 캐시 압축이 그 비용을 크게 줄인다고 덧붙였습니다. 그 숫자를 만든 설계는 보고서에 자세히 적혀 있고, arXiv에 올라온 저자 목록에는 량원펑 창업자를 포함해 591명의 이름이 있습니다.

KV 캐시는 모델이 앞 문맥을 적어 두는 메모입니다

언어 모델은 답을 한 토큰씩 만듭니다. 새 토큰을 만들 때마다 어텐션(앞에 나온 토큰 가운데 무엇을 참고할지 고르는 계산)이 지금까지의 문맥을 다시 훑는데, 앞 토큰들을 매번 처음부터 계산하지 않으려고 토큰마다 계산해 둔 키(K)와 값(V)을 GPU 메모리에 쌓아 둡니다. 이렇게 쌓아 둔 값을 KV 캐시라고 부릅니다.

캐시는 문맥이 길수록 커집니다. 토큰 하나에 드는 크기가 정해져 있어서, 100만 토큰짜리 문맥이면 그 100만 배를 GPU 옆 고대역폭 메모리(HBM)에 올려 두어야 합니다. 에이전트는 도구를 부를 때마다 실행 결과가 새 입력으로 돌아오고 몇 시간씩 일하며 문맥을 계속 늘립니다. 보고서의 다중 에이전트 실험은 과제 하나에 최대 20시간을 주었고, 에이전트 여럿이 함께 푼 FrontierSWE v2 점수는 1시간 13.50%에서 20시간 32.90%까지 올랐습니다.

보고서는 이런 장기 에이전트가 퍼지면서 모델이 하는 일이 갈수록 입력을 읽는 쪽에 쏠린다고 진단합니다. 남은 병목으로는 처음 들어온 긴 입력을 읽는 계산(프리필), HBM과 SSD의 용량, 캐시를 옮기는 대역폭을 꼽았습니다. 딥시크가 한 번 만든 캐시를 SSD에 보관하는 이유도 여기서 나옵니다. 같은 앞부분으로 시작하는 요청이 다시 오면 저장해 둔 캐시를 불러와 계산을 건너뛰고, API 요금표의 「캐시 적중」 입력이 이 경우입니다. 보고서에 따르면 V4 서비스는 캐시가 보통 72시간 넘게 남아 있도록 SSD를 넉넉히 잡았습니다.

같은 100만 토큰, 389GB와 0.89GB

보고서 첫 그림은 딥시크 모델 세대별로 토큰 하나에 드는 전역 KV 캐시 크기를 나란히 놓았습니다. 2023년 11월 첫 모델은 38만 9,120바이트, 2025년 12월 V3.2는 4만 8,068바이트, 2026년 4월 V4-Flash는 3,514바이트였고, 이번 V4.1-Flash는 890바이트로 첫 모델의 437분의 1까지 내려왔습니다.

토큰당 값에 100만을 곱하면 크기가 손에 잡힙니다. 아래 표의 오른쪽 열은 제가 보고서의 토큰당 값에 100만을 곱한 환산값입니다. 첫 모델은 실제로 이렇게 긴 문맥을 지원하지 않았으니, 같은 방식으로 저장했다면 얼마가 드는지 보여 주는 숫자입니다.

GPU의 HBM에는 모델 가중치와 다른 계산도 함께 올라갑니다. 긴 작업 하나가 캐시로 3.5GB를 차지하느냐 0.89GB를 차지하느냐는, GPU 한 장에 긴 작업을 몇 개까지 동시에 올릴 수 있느냐로 이어집니다.

전역 어텐션과 지역 어텐션

890바이트의 출발점은 V4에서 정한 구조입니다. V4는 어텐션을 두 갈래로 나눠 씁니다. 전역 갈래는 문맥 전체를 압축해서 보고, 지역 갈래인 슬라이딩 윈도 어텐션(SWA)은 바로 앞의 정해진 개수만큼만 그대로 봅니다(V4.1은 128토큰). 전역 갈래가 쌓는 캐시(본 KV와 인덱서 키)는 문맥 길이에 비례해 커지지만, SWA 캐시는 레이어마다 윈도 크기만큼으로 고정됩니다.

그래서 문맥이 충분히 길어지면 HBM을 채우는 것은 거의 전역 캐시입니다. 딥시크는 V4를 SWA로 가까운 문맥을 처리하는 뼈대에 압축된 전역 문맥을 덧붙인 모델로 다시 보고, 지역 갈래는 거의 그대로 둔 채 전역 갈래를 덜어 내는 데 힘을 모았습니다.

V4.1-Flash의 40개 레이어는 앞쪽 20개 인과 인코더와 뒤쪽 20개 디코더로 나뉩니다. 맨 앞 두 레이어는 SWA만 쓰고, 나머지 38개 레이어가 새 전역 어텐션 CSA2(Compressed Sparse Attention 2)를 씁니다.

레이어 40개 가운데 4개만 전역 캐시를 만듭니다

보고서는 KV 캐시를 줄이는 길을 서로 곱해지는 세 방향으로 정리했습니다. 캐시 항목 하나의 크기를 줄이는 방향(여러 헤드가 키와 값을 나눠 쓰는 GQA, 작은 잠재 벡터로 압축하는 MLA), 토큰 여러 개를 항목 하나로 묶는 방향(V4의 CSA·HCA), 레이어끼리 캐시를 나눠 쓰는 방향입니다. 딥시크는 앞선 연구 가운데 세 방향을 모두 다룬 방법이 없었다며, CSA2가 셋을 함께 쓴다고 적었습니다.

CSA2 레이어는 세 가지 모드 가운데 하나로 고정됩니다. Full 모드는 전역 캐시를 직접 만들고, 문맥에서 어떤 토큰을 볼지 고르는 인덱서까지 돌립니다. Reindex 모드는 앞 레이어가 만든 캐시를 빌려 쓰되 자기 질의로 볼 토큰을 다시 고르고, Reuse 모드는 캐시와 고른 목록(Top-K)까지 그대로 빌려 바로 어텐션을 계산합니다. 세 모드 모두 질의(Q)와 SWA 캐시는 레이어마다 따로 계산합니다.

모드 배치는 보고서의 설정표에 있습니다.

전역 캐시를 새로 만드는 레이어는 인코더의 Full 3개와 디코더의 Full 1개, 모두 4개입니다. 디코더의 Reindex 레이어들은 디코더 첫 레이어가 만든 캐시에서 볼 토큰만 다시 고릅니다.

제가 이 설정값으로 계산해 보면 890바이트가 그대로 나옵니다. 인코더 Full 레이어 3개는 토큰 2개당 항목 1개를 저장하니 토큰당 1.5개, 디코더 Full 레이어는 토큰당 1개라서, 토큰 하나에 저장하는 항목은 2.5개입니다. 항목 하나는 512채널 본 KV를 4비트로 적은 288바이트(값 256바이트, 16채널마다 붙는 배율 32바이트)와 128차원 인덱서 키 68바이트를 더한 356바이트입니다. 2.5개에 356바이트를 곱하면 보고서의 890바이트와 맞아떨어집니다. 같은 설정에서 38개 CSA2 레이어가 저마다 캐시를 저장했다면 토큰당 항목은 29개로 지금의 11.6배가 됩니다.

디코더에는 계층형 희소 인덱서도 붙었습니다. 디코더 첫 Full 레이어가 문맥 전체를 훑어 점수가 높은 블록을 최대 2,048개(블록당 8토큰, 후보 1만 6,384개) 골라 넘기면, 뒤쪽 Reindex 레이어들은 문맥 전체 대신 이 후보 안에서만 512개를 고릅니다. 문맥이 아무리 길어도 뒤쪽 인덱서가 매기는 점수는 질의 하나에 1만 6,384개를 넘지 않습니다.

4비트로 적어도 되는 이유

캐시를 줄인 또 하나의 수단은 저장 정밀도입니다. V4는 본 KV를 8비트(FP8)로 저장했는데, V4.1은 이를 4비트(FP4)로 낮춰 HBM과 SSD 모두에서 저장 용량을 거의 절반으로 줄였습니다. 형식은 엔비디아의 NVFP4를 따르되 2단계 전역 배율을 빼고, 값 16채널마다 8비트 배율 하나만 붙였습니다.

4비트는 표현할 수 있는 값이 적어 큰 값이 잘릴 위험이 있습니다. 딥시크는 이 형식이 2,688(448×6)까지 담을 수 있는 반면, 정규화와 회전 위치 인코딩(RoPE)을 거친 캐시 값은 이론상 약 22.6(√512)을 넘지 않고 학습 중 관측된 최댓값도 10 안팎이라고 계산했습니다. 그래서 전역 배율을 빼도 정확도가 잴 수 있을 만큼 떨어지지 않았다고 적었습니다. 4비트 캐시는 후속 학습 단계에서 양자화를 고려한 학습(QAT)으로 모델에 익혔고, 양자화에 민감한 SWA 캐시는 8비트로 남겼습니다.

저장하는 캐시와 다시 계산하는 캐시

SSD에 보관하는 영구 캐시에서는 SWA 캐시가 문제였습니다. V4 서비스에서는 영구 캐시 용량의 절반 가까이를 SWA 캐시가 차지했습니다. 전역 캐시는 앞부분이 맞으면 통째로 다시 쓰지만, SWA 캐시는 프롬프트 끝과 출력 끝 두 시점에서 윈도 크기만큼만 남겨 두었다가 거기서부터 계산을 이어 가는 방식이었습니다. 짧은 턴이 이어지는 대화일수록 SWA 캐시의 비중이 컸습니다.

SWA KV를 영구 저장하는 일은 비싸고 효과도 없습니다. 접근 방식이 영구 캐시의 긴 보존 정책과 맞지 않기 때문입니다.— 딥시크, V4.1-Flash 기술 보고서

전역 캐시는 시간이 꽤 지난 뒤에도 다시 쓰이는 일이 많지만, SWA 캐시는 한 세션 안에서 몇 분 동안만 쓰이고 세션이 끝나거나 다음 턴이 시작되면 쓸모가 없어진다는 관찰입니다. V4 보고서는 SWA 캐시를 저장하지 않고 필요할 때 다시 계산하는 방법을 제안했지만, 정확히 복원하려면 레이어 수와 윈도 크기를 곱한 만큼, V4.1 기준으로 40×128=5,120토큰을 모델에 다시 통과시켜야 해서 실제 서비스에서는 비용이 너무 컸습니다.

V4.1은 두 가지를 고쳤습니다. SWA 캐시를 SSD에서 빼서 서버마다 메모리(DRAM)의 10%를 떼어 만든 분산 메모리 풀에 몇 분만 두고, 시간이 지나면 새 세션에 넘깁니다. 전역 캐시는 그대로 SSD 영구 캐시에 두고 최소 72시간을 보장합니다. 전역 캐시는 남았는데 SWA 캐시가 사라진 요청에는 마지막 128토큰만 다시 계산해 SWA 상태를 근사로 복원하는 「SWA 제한 재생(Bounded Replay)」을 씁니다. 다시 계산하는 토큰이 5,120개에서 128개로, 40분의 1로 줄어듭니다.

복원한 상태는 원래 값과 수학적으로 같지 않습니다. 딥시크는 실험에서 응답 품질이 거의 떨어지지 않았다고 적었고, 이 제한 재생을 설계의 주춧돌로 불렀습니다. 영구 캐시가 V4의 8분의 1이 된 것은 SWA 캐시를 빼서 얻은 약 절반과 전역 캐시 압축의 4분의 1이 곱해진 결과입니다.

입력은 80억, 출력은 160억

캐시를 줄여도 새로 들어온 긴 입력을 읽는 프리필 계산은 남고, 에이전트는 도구를 부를 때마다 이 계산을 되풀이합니다. 딥시크는 마이크로소프트 연구진이 2024년 5월 낸 YOCO(You Only Cache Once)에서 착안한 인과 인코더-디코더(CED) 구조로 이 부분을 줄였습니다. 디코더 20개 레이어의 전역 캐시를 레이어마다 계산하지 않고, 인코더 마지막 레이어의 출력에서 바로 투영해 만듭니다.

그러면 새 입력은 인코더 20개 레이어만 통과하면 됩니다. 디코더에 따로 필요한 SWA 캐시는 앞서 본 제한 재생으로 마지막 128토큰만 디코더에 통과시켜 만듭니다. 보고서는 이렇게 프리필 계산이 절반 가까이 줄었고, 입력을 읽을 때는 파라미터 80억 개, 답을 쓸 때는 160억 개만 켠다고 적었습니다. 전체 백본 파라미터는 5,520억 개입니다.

답을 쓰는 디코드 계산도 문맥 길이에 거의 흔들리지 않습니다. 보고서에 따르면 문맥을 4,000토큰에서 100만 토큰으로 256배 늘려도 토큰 하나를 만드는 계산량은 4분의 1만 늘어납니다. 그래프에서 V4-Flash 곡선은 문맥이 길어질수록 가파르게 오르고, 두 곡선은 6만 4,000~25만 6,000토큰 사이에서 엇갈립니다. 문맥이 짧은 구간에서는 V4.1-Flash 곡선이 조금 위에 있는데, 답을 쓸 때 켜는 파라미터가 160억 개로 V4-Flash(130억 개)보다 많습니다.

추론 시스템도 같은 방향으로 다듬었습니다. 레이어 대부분을 차지하는 Reuse 모드 레이어는 연산을 묶어 프리필 때 커널 15개, 디코드 때 11개만으로 돌아갑니다. 강화학습에서는 최대 문맥을 51만 2,000토큰에서 100만 토큰으로 늘리자 Terminal-Bench 3.0처럼 아주 긴 과제의 점수가 계속 올랐다고 보고서는 적었고, 이 평가에서 V4.1-Flash는 30.0%로 V4-Flash(7.6%)의 4배 가까이 됐습니다.

줄인 만큼 성능은

딥시크는 캐시를 크게 줄이고도 성능은 V4-Flash보다 좋아졌다고 밝혔습니다. 후속 학습 전 기본 모델끼리 비교한 표를 보면 V4-Flash보다 오른 항목이 많지만 내려간 항목도 있고, 긴 문맥 평가는 거의 그대로입니다.

V4.1-Flash는 지식(MMLU-Pro)과 코딩(HumanEval)에서 V4-Pro까지 넘었지만, 긴 문맥 평가 LongBench-V2에서는 45.2점으로 V4-Flash(44.7점)와 0.5점 차이였고 V4-Pro(51.5점)보다 6.3점 낮았습니다. 다국어 수학 MGSM은 80.2점으로 세 모델 가운데 가장 낮았습니다. 후속 학습을 마친 모델의 에이전트 점수는 V4.1-Flash 공개 글에서 다뤘습니다.

압축이 품질을 얼마나 깎는지 따로 잰 숫자는 보고서에 없습니다. FP4 캐시는 손실이 「아주 작다」, SWA 제한 재생은 「무시할 만하다」고만 적었습니다. 결론에서는 시험하지 않은 경우를 직접 언급했습니다.

CSA2의 선택 오류와 SWA 제한 재생의 근사 복원이, 시험하지 않은 경계 조건에서 성능 저하를 일으킬 수 있습니다.— 딥시크, V4.1-Flash 기술 보고서

딥시크는 앞으로 긴 문맥에서의 희소 검색과, 캐시를 다시 불러오는 시점의 SWA 복원을 집중적으로 시험하겠다고 했습니다.

2019년 MQA에서 시작한 압축

KV 캐시를 줄이려는 시도는 오래됐습니다. 2019년 11월 구글의 노엄 샤지어는 여러 어텐션 헤드가 키와 값 한 벌을 나눠 쓰는 MQA(Multi-Query Attention)를 내놓으며, 답을 한 토큰씩 만들 때 느려지는 이유를 큰 키·값 텐서를 매번 메모리에서 불러오는 대역폭 비용으로 짚었습니다. 2023년 구글 연구진은 헤드를 몇 묶음으로 나눠 묶음마다 한 벌을 쓰는 GQA로 MQA의 품질 손실을 줄였습니다.

딥시크는 2024년 5월 V2에서 키와 값을 작은 잠재 벡터로 압축하는 MLA를 도입해, 이전 딥시크 67B 모델보다 KV 캐시를 93.3% 줄이고 최대 생성 처리량을 5.76배로 높였습니다. 같은 달 마이크로소프트의 YOCO와 MIT 연구진의 교차 레이어 어텐션(CLA)은 레이어끼리 캐시를 나눠 쓰는 방법을 냈습니다.

V4.1은 세 방향을 한 모델에 겹치고, 저장 정밀도와 서비스 방식까지 함께 손봤습니다. 보고서는 이 결과를 모델 구조와 캐시 정밀도, 배포 전략을 함께 최적화해서 얻었다고 설명합니다.

메모리를 덜 쓰는 모델과 메모리 수요

한국 독자에게 이 보고서가 가장 가깝게 닿는 곳은 메모리 반도체입니다. HBM을 만드는 SK하이닉스와 삼성전자에 거는 AI 수요 기대의 근거 가운데 하나가, 에이전트가 긴 문맥을 오래 붙들수록 HBM과 SSD가 더 필요하다는 계산입니다. 저는 9월 10일 스레드에서 딥시크처럼 모델 구조로 캐시를 줄이는 방식이 퍼지면, AI 사용량이 느는 만큼 메모리 수요가 그대로 늘지는 않는다는 악재로 받아들일 수 있다고 적었습니다.

보고서를 끝까지 읽으면 반대쪽 사실도 같이 보입니다. 딥시크는 캐시를 줄인 만큼 캐시 적중 입력 요금을 8월보다 57% 내렸고, 캐시가 싸지면 더 긴 문맥을 더 자주 쓰는 쪽으로 사용이 늘 수 있습니다. 전역 캐시는 여전히 SSD에 72시간 넘게 보관하고, 공식 공지는 GPU 2,000장과 스토리지 클러스터 규모로 배포를 준비하는 곳에 직접 연락해 달라고 안내했습니다.

가중치를 내려받아 사내 서버에서 돌리는 국내 기업에는 같은 GPU에 긴 작업을 더 많이 올릴 수 있다는 계산이 생깁니다. 다만 SWA 캐시를 서버 메모리 풀로 옮기고 제한 재생으로 복원하는 방식은 딥시크가 자기 서비스에 맞춰 짠 배포 설계입니다. 딥시크는 오픈소스 추론 엔진의 V4.1-Flash 지원을 커뮤니티와 함께 진행하겠다고 밝혔습니다.

다음은 V4.1-Pro

딥시크는 V4.1-Flash를 새 구조 계열에서 가장 작은 모델이라고 소개했고, 보고서 결론에서 이 모델을 다음 확장의 출발점으로 삼겠다고 적었습니다. V4-Pro로 들어오는 요청은 V4.1-Pro가 나올 때까지 V4.1-Flash가 처리합니다. 같은 구조를 더 큰 모델에 얹었을 때 토큰당 캐시가 몇 바이트가 되는지는 V4.1-Pro 보고서에서 확인할 수 있습니다.

소식·15분 읽기AI딥시크 "V4.1-Flash가 V4-Pro 앞서"… MIT 공개하고 요금 인하딥시크가 9월 10일 552B MoE 모델 V4.1-Flash를 MIT 라이선스로 공개했습니다. 토큰당 KV 캐시는 V4-Flash의 약 4분의 1이고, 오프피크 요금은 캐시 적중 입력 0.003달러, 출력 0.6달러로 8월보다 내렸습니다.읽기

읽어 주셔서 고맙습니다.

초이 드림