DeepSeek-AI가 긴 맥락을 다루는 에이전트 작업에 특화된 새 모델 DeepSeek-V4.1-Flash를 내놓았다. 핵심은 하나다. 100만 토큰까지 처리하는 552B(5,520억) 규모의 멀티모달 MoE 모델이면서도, 항상 고속 메모리(HBM)에 올라가는 KV 캐시를 토큰당 890바이트까지 줄여 이전 모델의 약 4분의 1로 압축했다. 그러면서도 성능은 오히려 더 좋아졌다는 것이 저자들의 주장이다.
이 글은 논문 초록에 명시된 사실만을 근거로, 이 모델이 무엇을 풀었고 어떤 방식을 썼으며 실제 제품에 어떤 의미가 있는지 정리한다.
요즘 LLM 사용 방식이 바뀌고 있다. 예전에는 사람이 짧은 질문을 던지고 모델이 긴 답을 쓰는 식이었다면, 지금은 '오래 일하는 에이전트(long-horizon agent)'가 대세다. 긴 문서, 코드베이스 전체, 여러 단계의 대화 기록을 통째로 넣어두고 계속 참조하며 일한다. 초록의 표현대로 작업이 점점 '입력 중심(input-heavy)'으로 무거워지고 있다.
여기서 두 가지 비용이 문제가 된다.
첫째는 프리필(prefill). 모델이 답을 만들기 전에 입력 전체를 한 번 읽어들이는 단계다. 입력이 길수록 이 계산이 비싸진다. 그동안 긴 맥락 계산 비용을 줄이는 연구가 많이 진행됐지만, 초록은 프리필이 여전히 계산상 비싸다고 짚는다.
둘째는 KV 캐시(KV cache). 이것을 도서관 사서의 메모지에 비유할 수 있다. 모델은 앞서 읽은 토큰들의 정보를 매번 다시 계산하지 않으려고 메모지(캐시)에 적어둔다. 맥락이 길어질수록 이 메모지 뭉치가 두꺼워진다. 문제는 이 메모지를 어디에 두느냐다.
초록은 큰 KV 캐시가 HBM과 SSD 용량, 그리고 데이터 전송 대역폭을 모두 압박한다고 말한다. 결국 계산·저장·대역폭이라는 세 부담이 배포 비용을 더 낮추지 못하게 막는 핵심 병목이라는 것이다. 이 논문은 바로 이 병목을 겨냥한다.
DeepSeek-V4.1-Flash가 병목을 뚫기 위해 쓴 방법은 크게 세 갈래다.
이 모델은 Causal Encoder-Decoder(CED, 인과적 인코더-디코더)라는 구조를 쓴다. 그리고 MoE(Mixture-of-Experts, 전문가 혼합) 방식이다. MoE는 5,520억 개의 파라미터를 다 갖고 있되 토큰마다 그중 일부 전문가만 깨워 쓰는 방식이라고 이해하면 된다. 백과사전 전체를 소유하되 질문마다 관련된 몇 페이지만 펼치는 셈이다.
CED의 묘미는 단계별로 깨우는 규모를 다르게 뒀다는 점이다. 초록에 따르면 답을 만들어내는 디코드(decode) 단계에서는 토큰당 16B(160억) 파라미터를 활성화하지만, 입력을 읽어들이는 프리필 단계에서는 8B(80억) 파라미터만 활성화한다. 입력을 훑을 때는 가볍게, 실제로 답을 뽑아낼 때는 무겁게 일하는 것이다. 앞서 말한 프리필이 비싸다는 문제를 정면으로 겨눈 설계이며, 초록은 이것이 에이전트 작업의 비용 효율을 크게 개선한다고 밝힌다.
KV 캐시를 줄이기 위해 두 기법을 결합했다.
이 둘을 합친 결과, 항상 HBM에 올라가 있어야 하는 전역(global) KV 캐시가 토큰당 890바이트까지 줄었다. 초록은 이것이 이전 모델인 DeepSeek-V4-Flash의 약 4분의 1 수준이라고 밝힌다. 책상 위에 두어야 할 메모지 부피를 4분의 1로 줄인 것이다.
책상뿐 아니라 창고도 정리했다. SWA Bounded Replay라는 전용 배포 최적화 기법으로, 항상 SSD나 호스트 메모리에 남아 있어야 하는 지속형(persistent) KV 캐시를 DeepSeek-V4-Flash의 약 8분의 1로 줄였다. 이름의 SWA는 슬라이딩 윈도우 어텐션(Sliding Window Attention) 계열을 가리키는 것으로 보이지만, 초록은 구체적인 내부 동작까지는 서술하지 않으므로 여기서는 '창고에 쌓이는 메모지를 8분의 1로 줄이는 배포 기법'이라는 결과만 확정적으로 받아들이는 것이 정확하다.
이 밖에도 초록은 DeepSeek-V4 아키텍처를 간결하게 정리하고(streamline) 몇 가지 효율적인 구조 확장을 도입했다고만 밝힌다. 세부 내용은 초록에 없다.
초록이 명시하는 성과를 정리하면 다음과 같다.
| 항목 | 내용 |
|---|---|
| 모델 규모 | 백본 552B 파라미터의 멀티모달 MoE |
| 최대 맥락 | 최대 100만(1M) 토큰 |
| 활성 파라미터 | 디코드 16B, 프리필 8B |
| 전역 KV 캐시(HBM 상주) | 토큰당 890바이트, V4-Flash의 약 1/4 |
| 지속형 KV 캐시(SSD/호스트 상주) | V4-Flash의 약 1/8 |
| 사전학습 데이터 | 멀티모달 코퍼스 45T(45조) 토큰 |
| 성능 | 캐시가 훨씬 작음에도 기준 모델보다 상당히 우수 |
가장 눈여겨볼 대목은 '더 작은데 더 좋다'는 조합이다. 보통 무언가를 압축하면 성능이 깎이기 마련인데, 초록은 훨씬 작은 KV 캐시 용량에도 불구하고 기준(baseline)보다 상당히 나은 성능을 낸다고 주장한다. 또한 텍스트 기반과 멀티모달 에이전트 시나리오 전반에서 강한 성능을 보였다고 한다. 사전학습은 45T 토큰의 멀티모달 코퍼스로 진행했고, 종합적인 사후학습(post-training)을 거쳤다. 모델 체크포인트는 HuggingFace에 공개되어 있다.
다만 초록에는 구체적인 벤치마크 점수, 어떤 데이터셋에서 몇 점이 올랐는지, 어떤 baseline과 어떤 조건에서 비교했는지 같은 수치는 담겨 있지 않다. 따라서 '기준 대비 상당히 우수'는 정성적 서술로 받아들이는 것이 정직하다.
초록만으로 판단할 때 아래 질문들이 남는다.
이런 세부는 논문 본문과 공개된 체크포인트로 확인해야 한다.
온틀은 'AI 프로젝트 매니저를 파견하는 SaaS'다. AI PM은 전형적인 long-horizon agent다. 프로젝트 기록, 이전 회의록, 이슈 히스토리, 팀의 맥락을 오래 들고 다니며 여러 단계에 걸쳐 판단한다. 초록이 지목한 '입력 중심 작업'과 정확히 겹친다.
이 연구가 제품에 주는 시사점을 정리하면 다음과 같다.
정리하면 이 논문은 '더 긴 맥락을 더 싸게'라는 방향을 KV 캐시 압축이라는 구체적 축에서 밀어붙인 사례다. 오래 일하는 에이전트를 제품으로 운영하는 입장에서는, 성능 벤치마크 이전에 '메모리 발자국을 어떻게 줄일 것인가'가 곧 서비스의 마진이라는 점을 다시 확인시켜 준다.
MoE(전문가 혼합) 구조라 552B를 전부 동시에 쓰지 않기 때문입니다. 초록에 따르면 토큰마다 답을 만드는 디코드 단계에서 16B, 입력을 읽는 프리필 단계에서 8B만 활성화합니다. 전체 규모는 크지만 실제 매 순간 계산에 동원되는 부분은 작습니다.
초록은 이 값이 항상 HBM에 올라가는 전역 KV 캐시 기준이며, 이전 모델인 DeepSeek-V4-Flash의 약 4분의 1 수준이라고 밝힙니다. 또한 SSD·호스트 메모리에 상주하는 지속형 캐시는 SWA Bounded Replay 기법으로 약 8분의 1까지 줄였습니다. 다른 회사 모델과의 절대 비교치는 초록에 없습니다.
초록은 훨씬 작은 KV 캐시에도 기준 모델보다 상당히 우수한 성능을 낸다고 주장합니다. 다만 구체적인 벤치마크 점수나 향상 폭은 초록에 제시되어 있지 않으므로, 정확한 수치는 논문 본문과 공개 체크포인트로 확인하는 것이 맞습니다.
모델 체크포인트가 HuggingFace에 공개되어 검증은 가능합니다. 다만 FP4 캐싱과 CED의 비대칭 활성화 이점을 온전히 누리려면 그에 맞는 추론 환경이 전제됩니다. 실제 도입 여부는 서비스의 인프라와 비용 구조에 따라 별도 검토가 필요합니다.