긴 실행형 에이전트 워크로드에 집중합니다. 오늘날 프론티어 오픈 모델이 에이전트로 실행될 때 예측 가능한 방식으로 문제가 발생합니다. 모델이 멈추고, 다시 프롬프트를 입력하고, 추적 정보가 컨텍스트 예산을 초과하거나 KV 캐시가 GPU 를 채우거나, 도구 호출 라운드 트립이 긴 작업 중간에 열화됩니다. V4 는 이러한 알려진 실패를 해결하기 위해 설계되었으며, 커뮤니티가 따를 길을 제시합니다.
이 포스트는 다음 세 가지 내용을 다룹니다: 긴 컨텍스트 추론을 저렴하게 만드는 데 다른 점은 무엇인지, 그리고 그 위에 중첩되는 에이전트 특화 후 훈련 결정, 그리고 이러한 변화에 대해 추론하는 데 도움이 되는 논문에서 얻은 교훈들입니다.
1M 컨텍스트 윈도우는 단순히 용량일 뿐, 성능이 아닙니다. 이를 사용할 수 있는지는 해당 깊이에서의 모든 포워드 패스의 비용에 달려 있습니다. 에이전트가 긴 도구 사용 궤적을 실행할 때 (SWE-bench 작업, 다단계 브라우징 세션, 수백 개의 명령어로 구성된 터미널 세션), 각 도구 결과는 컨텍스트에 추가되고, 이후 토큰은 이전에 온 모든 것에 대해 전체 주의 비용을 지불합니다.
두 가지 숫자가 중요합니다: 단일 토큰 추론 FLOPs 와 KV 캐시 크기. 둘 다 시퀀스 길이와 함께 증가합니다. 1M 토큰에서 DeepSeek-V4-Pro 는 DeepSeek-V3.2 대비 단일 토큰 추론 FLOPs 의 27% 를 필요로 하므로, 동일한 하드웨어에서 더 빠르게 실행됩니다. 또한 KV 캐시 메모리의 10% 만 사용합니다. V4-Flash 는 이러한 숫자를 더욱 낮춥니다: FLOPs 의 10% 와 KV 캐시의 7%.
KV 캐시 메모리를 기존 아키텍처인 그룹 쿼리 attention (8 헤드) 과 비교할 때, 일반적인 bfloat16 형식으로 저장된 경우 DeepSeek v4 는 약 2% 의 캐시 크기를 필요로 합니다. 이는 매우 큰 컨텍스트 처리를 위한 배포를 훨씬 쉽게 만듭니다.
Figure 1: benchmark comparison (left), per-token FLOPs and accumulated KV cache against sequence length (right).
효율성 향상은 attention 을 두 메커니즘으로 나누고 레이어 간에 교차 배치하는 데서 비롯됩니다.
Compressed Sparse Attention (CSA) 는 softmax-gated pooling 과 학습된 위치 편향을 사용하여 시퀀스 차원에서 KV 엔트리를 4 배 압축합니다. Lightning indexer (FP4, ReLU-scored multi-head dot product) 는 각 쿼리에 대해 상위 k 개의 압축 블록을 선택합니다. 이는 V3.2 의 DeepSeek Sparse Attention 에서 희소 선택 아이디어를 계승하지만, 원래 시퀀스보다 4 배 짧은 블록 위에서 실행됩니다. 인덱서 검색 공간이 줄어듭니다.
Figure 3: CSA. The compressor collapses every 4 tokens into one compressed KV entry. The lightning indexer picks the top-k compressed blocks per query. A sliding-window branch handles the most recent uncompressed tokens.
Heavily Compressed Attention (HCA) 는 KV 엔트리를 128 배 압축하고 희소 선택을 제거합니다. 모든 쿼리는 각 압축 블록에 대해 밀집 방식으로 attention 을 가집니다. 압축된 시퀀스는 짧아 밀집 방식 attention 이 저렴합니다.
Figure 4: HCA. A heavier compressor (128x vs. 4x) followed by dense attention over the compressed stream, with the same sliding-window branch for recency.
레이어는 CSA 와 HCA 를 번갈아 가며 배치합니다. 다른 레이어는 다른 attention 패턴을 가지며, 모든 레이어에 하나의 메커니즘을 강제하면 용량을 낭비합니다. V4-Pro 의 61 레이어 스택에서, 레이어 0–1 은 HCA, 레이어 2–60 은 CSA 와 HCA 를 번갈아 가며 배치되고, 마지막 MTP 블록은 슬라이딩 윈도우만 실행합니다.
대부분의 KV 엔트리는 FP8 스토리지, RoPE 차원은 BF16 만 사용합니다. CSA 내부의 lightning 인덱서는 FP4 를 사용합니다. 이러한 스토리지 선택은 압축 비율과 결합하여 2% KV 캐시 수치를 만들어냅니다.
Figure 2: 전체 아키텍처. Attention 레이어는 CSA 와 HCA 가 교대로 사용됨. Feed-forward 레이어는 DeepSeekMoE 를 사용합니다. Residual 연결은 manifold-constrained hyper-connections (mHC) 로 대체됩니다.
효율적인 장 컨텍스트 attention 은 에이전트 워크플로우에 필수적이지만 충분하지 않습니다. 이 논문은 에이전트 사용 사례를 직접 목표로 삼은 세 가지 포스트 트레이닝 및 인프라 선택을 설명합니다.
V3.2 는 도구 결과 라운드 간 추론 흔적을 유지했지만, 새로운 사용자 메시지가 도착하면 이를 폐기했습니다. 단일 사용자 턴을 처리하는 에이전트에게는 괜찮았습니다. 에이전트가 여러 도구를 연쇄 호출한 후 사용자가 추가 메시지를 보낸 다중 턴 에이전트 워크플로우에서는 모델이 누적된 추론을 잃고 상태를 재구성해야 했습니다.
V4 는 대화에 도구 호출이 포함되어 있을 때 사용자 메시지 경계 간 추론 콘텐츠를 보존합니다. 모델은 모든 라운드, 심지어 사용자 턴까지도 완전한 추론 역사를 유지합니다. 이는 장 범위의 에이전트 작업에 대해 일관되고 누적된 사고 체인을 가능하게 합니다. 도구가 없는 대화 사용의 경우, 이전 동작이 보존됩니다: 각 턴마다 컨텍스트를 간결하게 유지하기 위해 추론이 flushed 됩니다.
Figure 7: 도구 사용 시 (상단) 모든 턴 간 추론을 보존합니다. 도구 사용 없이 사고할 때 (하단)는 새로운 사용자 메시지에서 추론을 폐기합니다.
V4 는 |DSML| 특수 토큰과 XML 기반 도구 호출 형식을 도입합니다. XML 형식은 JSON-in-string 도구 호출에 비해 이스케이프 실패를 줄입니다. 이는 모델이 중첩된 인용 내용을 방출할 때 흔한 실패 모드입니다.
스키마는 문자열 매개변수 (string="true"로 그대로 전달됨) 와 구조화 매개변수 (string="false"로 JSON 으로 전달됨) 를 분리합니다. 이는 JSON 도구 호출 형식이 일반적으로 겪는 숫자와 볼륨 주위 파싱 오류의 한 종류를 제거합니다.
에이전트 동작은 실제 도구 환경에 대한 RL 로 훈련되었습니다. 이 논문은 이를 위해 구축된 샌드박스 인프라를 설명합니다. DeepSeek Elastic Compute (DSec) 는 Python SDK 를 통해 네 가지 실행 서브스트라이트 (함수 호출, 컨테이너, microVMs (Firecracker), 전체 VMs (QEMU)) 를 하나의 Rust 플랫폼에서 노출합니다. 단일 클러스터는 수백만 개의 동시 샌드박스를 실행합니다.
에이전트 훈련에 중요한 세 가지 DSec 기능은: 계층 3FS 스토리지를 통한 빠른 이미지 로딩 (RL rollouts 가 컨테이너 시작을 기다리지 않도록 함), preemption-safe trajectory replay (중단된 훈련 단계가 도구 호출을 재실행하지 않고 재개되도록 함), 서브스트라이트 간 일관된 API (훈련 하네스가 함수 호출 또는 전체 VMs 를 목표로 할 때 리스크를 수정하지 않아도 됨). 이러한 인프라 결정은 에이전트 벤치마크 점수를 뒷받침합니다.
지식과 추론 숫자는 경쟁력 있지만 선도적이지 않습니다. 에이전트 숫자가 V4-Pro-Max 을 다른 분야에서 분리시킵니다.
Table 6 의 에이전트 섹션의 구체적인 숫자:
- Terminal Bench 2.0: V4-Pro-Max 점수 67.9, GLM-5.1 (63.5) 과 K2.6 (66.7) 보다 앞서, GPT-5.4-xHigh (75.1) 과 Gemini-3.1-Pro (68.5) 보다 뒤.
- SWE Verified: 80.6 해결됨, Opus-4.6-Max (80.8) 과 Gemini-3.1-Pro (80.6) 에 한 점 차이.
- MCPAtlas Public: 73.6, Opus-4.6-Max (73.8) 에 두 번째로.
- Toolathlon: 51.8, K2.6 (50.0), GLM-5.1 (40.7), Gemini-3.1-Pro (48.8) 보다 앞서.
내부 R&D 코딩 벤치마크에서, PyTorch, CUDA, Rust, C++ 를 포함한 30 개의 큐레이티드( Curated) 작업 중 V4-Pro-Max 은 67% 의 패스율을 기록했으며, Sonnet 4.5 는 47%, Opus 4.5 는 70% 로 각각 뒤지거나 앞서는 결과를 보였습니다.
85 명의 DeepSeek 개발자를 대상으로 한 설문조사에서, V4-Pro 를 일상적인 코딩 도구로 사용하는 개발자 중 52% 는 현재 주력 코딩 모델을 대체할 준비가 되었다고 답했고, 39% 는 찬성 의견을 표명했습니다.
장기 컨텍스트 검색 수치는 Figure 9 에 있습니다. MRCR 8-needle 정확도는 256K 토큰을 통해 0.82 이상을 유지하며, 1M 토큰에서는 0.59 로 고정됩니다.
Figure 9: MRCR 8-needle retrieval. V4-Pro-Max stays above 0.82 through 256K and holds at 0.59 at 1M.
Hub 에는 4 개의 체크포인트가 있습니다. Instruct 모델은 MoE 전문가 가중치를 위해 FP4 를 사용하며, 나머지 모든 것은 FP8 을 사용합니다. Base 모델은 전역적으로 FP8 을 사용합니다.
- deepseek-ai/DeepSeek-V4-Pro (1.6T / 49B 활성화, instruct)
- deepseek-ai/DeepSeek-V4-Flash (284B / 13B 활성화, instruct)
- deepseek-ai/DeepSeek-V4-Pro-Base (1.6T / 49B 활성화, base)
- deepseek-ai/DeepSeek-V4-Flash-Base (284B / 13B 활성화, base)
두 instruct 모델은 세 가지 추론 모드를 지원합니다: Non-think(빠른 속도, 체인 오브 싱크 없음), Think High(<thinking> 블록에서 명시적인 추론), 그리고 Think Max(최대 추론 노력과 전용 시스템 프롬프트 사용). Think Max 는 최소 384K 토큰의 컨텍스트 윈도우가 필요합니다. 모든 모드에 대한 권장 샘플링 파라미터는 temperature=1.0, top_p=1.0 입니다.
SWE Verified, MCPAtlas, 그리고 내부 R&D 벤치마크에서의 V4-Pro 수치는 에이전트 작업에서 프론티어 클로즈드 모델과 평등한 수준임을 보여줍니다. 열린 질문은 커뮤니티의 도구 허브가 |DSML| 스키마에 어떻게 적응할 것이며, 교차된 추론 이득이 도메인 밖 에이전트 프레임워크에 전이될 수 있는지에 대한 것입니다.
이 블로그 포스트의 그래프는 DeepSeek_V4.pdf 의 기술 보고서에서 가져왔습니다.
