DeepSeek-V3.2: Pushing the Frontier of Open Large Language Models Review

0. Introduction

Paper link

DeepSeek-V3.2는 “또 하나의 open LLM technical report” 정도로 읽으면 핵심을 놓치기 쉬운 논문이다. 이 논문은 단순히 benchmark score를 나열하는 보고서가 아니라, open model이 frontier closed model과 경쟁하려면 architecture efficiency, RL scaling, agent data synthesis를 동시에 밀어야 한다는 주장을 하나의 system recipe로 제시한다.

이 논문에서 가장 흥미로운 점은 기여가 한 층에 머물지 않는다는 것이다. 보통 LLM technical report는 pretraining data, model architecture, benchmark 중심으로 읽히기 쉽다. 반면 DeepSeek-V3.2는 세 레이어를 동시에 다룬다.

1. Architecture layer: long-context 비용을 낮추기 위해 DeepSeek Sparse Attention, 즉 DSA를 도입한다.
2. Post-training layer: GRPO 기반 RL을 더 크게 안정적으로 돌리기 위해 KL estimate, off-policy masking, MoE routing consistency 같은 training-system 문제를 다룬다.
3. Agent layer: reasoning과 tool-use를 한 trajectory 안에서 다루기 위해 agentic task synthesis와 context management를 설계한다.

이 논문의 핵심은 “DeepSeek-V3.2가 어떤 점수를 냈는가”보다 open LLM에서 다음 병목이 어디로 이동했는가를 보여준다는 점이다. V3.2의 메시지는 꽤 명확하다. 이제 open model의 경쟁력은 단순 pretraining scale만으로 설명하기 어렵고, long-context serving cost, RL compute budget, agent environment construction, test-time context management가 모두 성능 레버가 된다.

한 줄 요약: DeepSeek-V3.2는 DSA로 long-context attention 비용을 낮추고, scalable GRPO recipe와 대규모 agentic task synthesis를 결합해 reasoning / coding / tool-use 성능을 frontier 수준에 가깝게 끌어올리려는 open LLM system report다.

이 논문을 지금 볼 가치가 있는 이유는 다음과 같음.

• DeepSeek 계열의 핵심 관심사가 이제 MoE pretraining scale에서 sparse attention + RL scaling + agentic post-training으로 확장되고 있다.
• DSA는 NSA처럼 sparse attention을 hardware / serving 관점에서 다루지만, 이번에는 DeepSeek-V3.1-Terminus에서 계속 학습해 실제 flagship model에 넣는 방식으로 제시된다.
• GRPO를 크게 돌릴 때 생기는 off-policy, KL estimator, MoE routing mismatch, sampling mask mismatch를 꽤 구체적으로 적는다.
• agent benchmark 성능을 단순 tool-use prompt engineering으로 보지 않고, synthetic environment / verifier / reward model / context retention까지 포함한 training pipeline 문제로 본다.
• 결과 해석에서 token efficiency, internal environment, context length overflow 같은 한계도 같이 드러나기 때문에, benchmark score만 보는 것보다 배울 점이 많다.

DeepSeek-V3.2의 진짜 주제는 더 똑똑한 모델이 아니라 더 오래 생각하고, 더 많이 도구를 쓰고, 더 싸게 긴 context를 처리할 수 있는 모델을 어떻게 시스템적으로 만들 것인가에 가깝다.

1. Problem Setting

1-1. Problem definition

논문이 정의하는 문제는 open model과 closed frontier model 사이의 격차를 줄이는 것이다. 다만 이 격차를 단일 benchmark 문제로 보지 않는다. 저자들은 open model이 complex task에서 밀리는 이유를 크게 세 가지로 나눈다.

첫째, long-context efficiency bottleneck이다. reasoning model과 agent model은 짧은 질의응답만 하지 않는다. 긴 문제 설명, 코드베이스, 검색 결과, tool call history, intermediate reasoning trace를 모두 context에 넣고 처리해야 한다. 이때 vanilla attention의 비용은 pretraining, post-training, inference 모두에서 병목이 된다.

둘째, post-training compute budget의 부족이다. DeepSeek-R1 이후 reasoning model의 성능은 RL scaling과 밀접해졌다. 하지만 RL은 단순히 GPU를 더 태우면 되는 문제가 아니다. rollout을 대량으로 만들고 여러 mini-batch update를 돌리면 off-policy 문제가 생기고, MoE 모델에서는 inference와 training 사이의 routing mismatch도 생긴다. 즉 RL compute를 키우려면 optimization stability와 system consistency를 같이 해결해야 한다.

셋째, agent generalization의 부족이다. real-world agent task는 단순 function calling benchmark보다 훨씬 지저분하다. 검색을 반복해야 하고, 코드 실행 결과를 해석해야 하며, 잘못된 tool output이나 긴 history를 관리해야 한다. 논문은 open model이 이런 long-tail agent task에서 closed model 대비 instruction-following과 generalization이 뒤처진다고 본다.

정리하면 DeepSeek-V3.2의 문제 설정은 다음 질문으로 압축된다.

open LLM이 frontier model에 가까운 reasoning / coding / tool-use 능력을 가지려면, attention efficiency, RL scaling, agent task construction을 어떻게 함께 설계해야 하는가?

1-2. Why previous approaches are insufficient

기존 접근의 한계는 단순히 “모델이 작다”가 아니다. DeepSeek-V3.2 관점에서는 다음 세 가지가 병목이다.

첫째, full attention 기반 long-context model은 cost curve가 불리하다. context length가 128K까지 늘어나면 prefill과 decoding 모두에서 attention cost가 커진다. 특히 agent task에서는 모델이 답을 한 번에 내는 것이 아니라 tool call과 reasoning을 반복하기 때문에, 긴 trajectory를 유지할수록 비용이 누적된다.

둘째, RL post-training은 multi-stage로 나누면 domain 간 성능 균형이 깨지기 쉽다. reasoning RL, agent RL, human alignment를 따로 순차적으로 밀면 한쪽 능력을 얻는 동안 다른 능력이 잊히는 catastrophic forgetting이 생길 수 있다. 그래서 DeepSeek-V3.2는 reasoning, agent, human alignment를 하나의 mixed RL stage로 묶으려 한다.

셋째, agent data는 실제 사용자 로그만으로 충분히 만들기 어렵다. 고품질 agent task는 hard-to-solve but easy-to-verify 구조가 필요하고, code issue resolution이나 search QA처럼 실제 tool environment를 동반해야 한다. 기존 instruction data나 단순 tool-call trace만으로는 이런 일반화를 만들기 어렵다.

넷째, benchmark score를 높이는 test-time compute도 context limit에 막힌다. 논문은 Search Agent 평가에서 128K context가 있어도 약 20% 이상의 BrowseComp test case가 limit을 넘는다고 설명한다. 이건 agent model에서 “더 오래 생각하라”는 전략이 항상 공짜가 아님을 보여준다.

따라서 DeepSeek-V3.2는 model architecture, RL recipe, agent context management를 분리된 문제가 아니라 하나의 product-level system problem으로 본다.

2. Core Idea

2-1. Main contribution

DeepSeek-V3.2의 핵심 기여는 크게 세 가지다.

1. DeepSeek Sparse Attention, DSA
   • DeepSeek-V3.1-Terminus에서 계속 학습하는 방식으로 DSA를 도입한다.
   • DSA는 lightning indexer가 query별로 중요한 과거 token을 scoring하고, fine-grained token selection이 top-k key-value entry만 읽도록 만든다.
   • 핵심 attention complexity는 dense attention의 $O(L^2)$에서 $O(Lk)$로 줄어든다. 다만 indexer 자체는 여전히 $O(L^2)$ 요소가 있으므로, 실제 이득은 indexer가 충분히 가볍고 kernel 구현이 잘 되어 있다는 전제 위에 있다.
2. Scalable RL framework
   • DeepSeekMath / DeepSeek-R1 계열의 GRPO를 기반으로 하되, RL scaling에서 불안정성을 만드는 요소를 줄인다.
   • unbiased KL estimate, off-policy sequence masking, Keep Routing, Keep Sampling Mask를 통해 대규모 RL update의 안정성을 높인다.
   • 논문은 post-training compute budget이 pretraining cost의 10%를 넘는 수준까지 커졌다고 설명한다.
3. Large-scale agentic task synthesis pipeline
   • reasoning과 tool-use를 결합하기 위해 cold-start prompt 설계, thinking context management, search/code/general/code-interpreter agent task construction을 제안한다.
   • 특히 general agent에서는 1,827개의 synthesized environment와 4,417개의 task를 만든다.
   • Search Agent와 Code Agent는 실제 web search API, coding tools, Jupyter Notebook, GitHub issue-PR pair 기반 executable environment를 활용한다.

여기서 중요한 점은 세 기여가 서로 독립적이지 않다는 것이다. DSA가 없으면 long-context RL과 agent trajectory 비용이 커지고, RL scaling이 없으면 DSA가 있어도 reasoning 성능이 충분히 올라가지 않으며, agentic task synthesis가 없으면 tool-use generalization을 만들기 어렵다.

2-2. Design intuition

이 논문의 설계 직관은 “capability를 올리는 것”과 “capability를 쓸 수 있게 만드는 것”을 구분하는 데 있다.

DSA는 capability 자체를 직접 올리는 모듈이라기보다, 긴 context에서 capability를 감당 가능한 비용으로 쓰게 만드는 모듈이다. DeepSeek-V3.2-Exp와 DeepSeek-V3.1-Terminus의 parity evaluation이 중요한 이유가 여기에 있다. sparse attention을 넣었을 때 성능이 오르는 것보다 먼저 확인해야 하는 것은 성능이 크게 깨지지 않으면서 cost curve가 좋아지는가다.

RL framework는 reasoning capability를 키우는 축이다. 하지만 RL scaling에서는 “더 많은 rollout”이 항상 좋은 update로 이어지지 않는다. inference framework와 training framework가 다르면 policy probability, expert routing, sampling mask가 달라질 수 있다. DeepSeek-V3.2의 RL 안정화 기법들은 모두 이 mismatch를 줄이는 방향이다.

Agent pipeline은 capability를 실제 interactive setting에 맞게 접지하는 축이다. 논문은 reasoning trace를 tool-use conversation에 넣는 것만으로는 부족하다고 본다. tool output이 추가될 때 thinking context를 어떻게 유지할지, 새 user message가 들어오면 어떤 reasoning을 버릴지, tool history는 어떻게 보존할지까지 설계한다.

내가 보기엔 DeepSeek-V3.2의 설계 철학은 다음과 같다.

reasoning model은 더 이상 “question -> answer” 모델이 아니라, 긴 context 위에서 sparse하게 읽고, 여러 번 rollout하고, tool environment와 상호작용하는 system actor다.

3. Architecture / Method

3-1. Overview

Item	Description
Goal	open LLM의 reasoning / coding / agent 성능을 frontier closed model에 가깝게 끌어올리는 것
Base transition	DeepSeek-V3.1-Terminus에서 128K long-context checkpoint를 기반으로 continued pre-training + post-training
Main architecture change	DeepSeek Sparse Attention, DSA 도입
Attention design	lightning indexer + fine-grained top-k key-value selection
DSA under MLA	MLA의 MQA mode를 기반으로 구현해 key-value entry를 여러 query head가 공유
Post-training	specialist distillation + mixed RL training
RL algorithm	GRPO 기반, reasoning / agent / human alignment를 하나의 RL stage로 통합
Agent recipe	thinking context management + cold-start + large-scale synthesized / real-tool agent tasks
High-compute variant	DeepSeek-V3.2-Speciale: reasoning data 중심, reduced length penalty, 더 긴 reasoning token 사용
Core caution	benchmark result는 internal environment, context management, output token budget에 크게 의존함

3-2. Module breakdown

1) DSA: lightning indexer + top-k token selection

DSA의 prototype은 두 부분으로 구성된다.

첫 번째는 lightning indexer다. query token $h_t$와 과거 token $h_s$ 사이의 index score $I_{t,s}$를 계산한다. 논문 식을 직관적으로 쓰면 다음과 같다.

\[I_{t,s} = \sum_{j=1}^{H_I} w^I_{t,j} \cdot \text{ReLU}(q^I_{t,j} \cdot k^I_s)\]

여기서 $H_I$는 indexer head 수이고, $q^I$, $k^I$, $w^I$는 각각 query token과 preceding token에서 나온다. ReLU를 쓰는 이유는 throughput consideration이다. 저자들은 indexer head 수가 작고 FP8 구현이 가능하므로 indexer 자체는 충분히 가볍다고 설명한다.

두 번째는 fine-grained token selection이다. 각 query token에 대해 index score가 높은 top-k key-value entry만 가져와 attention을 계산한다.

\[u_t = \text{Attn}(h_t, \{c_s \mid I_{t,s} \in \text{Top-k}(I_{t,:})\})\]

이 구조는 NSA의 block selection과는 조금 다르게 읽힌다. NSA는 compression / selection / sliding-window branch를 통해 blockwise hardware alignment를 전면에 세웠다면, DSA는 DeepSeek의 MLA 구조 위에서 indexer가 selected key-value entry를 고르는 방식이다. 즉 논문 관점에서 DSA는 DeepSeek-V3.1-Terminus의 architecture lineage를 최대한 유지하면서 sparse attention을 넣는 선택에 가깝다.

2) DSA under MLA: 왜 MQA mode인가

DeepSeek-V3.2는 DSA를 MLA 위에 구현한다. 이유는 continued training 때문이다. 기존 DeepSeek-V3.1-Terminus checkpoint에서 너무 멀리 벗어나면 sparse attention을 넣는 과정에서 capability가 깨질 수 있다.

중요한 구현 포인트는 MLA의 MQA mode다. 논문은 kernel level에서 key-value entry가 여러 query에 의해 공유되어야 computational efficiency가 나온다고 설명한다. 따라서 각 latent vector, 즉 MLA의 key-value entry가 query token의 모든 query head에 공유되는 MQA mode를 사용한다.

이 부분은 단순 architecture detail처럼 보이지만 실제로는 매우 중요하다. sparse attention에서 query head마다 다른 key-value를 읽게 만들면 선택된 KV access의 union이 커지고, decoding 단계에서 memory bandwidth 이득이 줄어든다. DSA가 MLA/MQA mode와 결합되는 이유는 sparse selection을 실제 serving cost reduction으로 연결하려는 선택이다.

3) Continued pre-training: dense warm-up -> sparse training

DeepSeek-V3.2는 DSA를 처음부터 새로 pretraining하지 않는다. DeepSeek-V3.1-Terminus의 128K context checkpoint에서 시작해 continued pre-training을 수행한다.

학습은 두 단계다.

Stage	핵심 목적	설정
Dense warm-up	lightning indexer가 dense attention distribution을 모방하도록 초기화	main model parameter는 freeze, indexer만 학습, 1,000 steps, 2.1B tokens
Sparse training	top-k selection을 실제로 도입하고 model 전체가 sparse pattern에 적응	all parameters optimize, 15,000 steps, 943.7B tokens, query마다 2,048 KV tokens 선택

Dense warm-up에서는 dense attention을 유지한 상태에서 main attention score를 모든 attention head에 대해 합산하고, sequence dimension으로 L1 normalize해 target distribution $p_t$를 만든다. 그런 다음 indexer output $I_{t,:}$의 softmax가 이 distribution을 따라가도록 KL divergence loss를 둔다.

Sparse training에서는 fine-grained token selection을 켜고, 선택된 token set $S_t$ 위에서 indexer output과 main attention distribution을 계속 align한다. 여기서 흥미로운 점은 indexer input을 computational graph에서 detach한다는 것이다. 논문은 indexer의 training signal은 indexer loss에서만 오고, main model은 language modeling loss로만 최적화된다고 설명한다.

내 해석으로는 이 detach 선택이 중요하다. Sparse selector를 end-to-end로 강하게 엮으면 main model과 selector가 서로 불안정하게 co-adapt할 수 있다. DeepSeek-V3.2는 selector를 dense attention imitation으로 안정화하고, main model은 sparse pattern에 적응하게 만드는 쪽을 택한다.

4) Post-training: specialist distillation + mixed RL

DSA 이후 final DeepSeek-V3.2를 만들기 위해 post-training을 수행한다. 논문은 post-training도 sparse attention 방식으로 유지한다고 설명한다.

첫 단계는 specialist distillation이다. 각 domain마다 specialist model을 만들고, 이들이 final checkpoint용 domain-specific data를 생성한다. 논문이 언급하는 specialized domain은 다음과 같다.

• mathematics
• programming
• general logical reasoning
• general agentic tasks
• agentic coding
• agentic search

여기에 writing task와 general QA도 포함된다. 또 각 domain은 thinking mode와 non-thinking mode를 모두 지원한다. 저자들은 specialist가 생성한 distilled data로 학습한 모델이 domain-specific specialist보다 약간 낮은 성능을 보이지만, subsequent RL training으로 그 gap이 거의 사라진다고 보고한다.

두 번째는 mixed RL training이다. DeepSeek-V3.2는 GRPO를 사용하고, reasoning / agent / human alignment를 하나의 RL stage 안에 합친다. reasoning과 agent task에는 rule-based outcome reward, length penalty, language consistency reward를 사용하고, general task에는 prompt별 rubric을 갖는 generative reward model을 사용한다.

이 선택은 DeepSeek-V3.2의 중요한 design point다. Multi-stage RL로 각 능력을 순차적으로 강화하는 대신, 하나의 mixed RL stage에서 균형을 맞추려 한다. 논문은 이 방식이 multi-stage training에서 흔한 catastrophic forgetting을 피하는 데 도움이 된다고 설명한다.

5) Scaled GRPO: RL scaling을 막는 작은 mismatch들

DeepSeek-V3.2의 GRPO 안정화 파트는 이 논문에서 가장 실무적인 부분 중 하나다. 논문이 제안하는 안정화 장치는 네 가지로 읽을 수 있다.

Unbiased KL Estimate

기존 K3 estimator가 특정 상황에서 noisy gradient update를 만들 수 있다고 보고, importance-sampling ratio를 사용해 KL estimate를 보정한다. 핵심은 KL regularization의 gradient가 systematic bias를 갖지 않도록 만드는 것이다.

흥미로운 점은 모든 domain에 같은 KL strength를 쓰지 않는다는 것이다. 논문은 mathematics 같은 domain에서는 약한 KL penalty 또는 KL penalty 제거가 더 나을 수 있다고 언급한다. 즉 RL scaling은 하나의 global hyperparameter로 풀리는 문제가 아니라 domain별 reward / KL balance 문제다.

Off-Policy Sequence Masking

대규모 RL에서는 rollout batch를 크게 만들고 여러 mini-batch update를 수행한다. 이 과정에서 old policy와 current policy 사이의 divergence가 커지고, training-inference framework 차이까지 겹치면 off-policy 문제가 생긴다.

DeepSeek-V3.2는 KL divergence가 큰 negative-advantage sequence를 mask한다. 직관은 명확하다. 모델은 자기 실수에서 배워야 하지만, 이미 current policy와 너무 멀어진 negative sample은 잘못된 방향으로 optimization을 흔들 수 있다.

Keep Routing

MoE 모델에서는 동일한 input이라도 inference framework와 training framework에서 expert routing이 달라질 수 있다. RL rollout을 만들 때 사용한 expert path와 training update에서의 expert path가 다르면, 실제로 optimize되는 parameter subspace가 달라진다.

DeepSeek-V3.2는 sampling 시 사용한 expert routing path를 저장하고 training 때 같은 route를 강제한다. 논문은 이 Keep Routing이 MoE RL stability에 중요하며 DeepSeek-V3-0324 이후 pipeline에 채택되었다고 설명한다.

Keep Sampling Mask

Top-p / top-k sampling은 rollout quality를 높이지만, sampling policy와 training policy의 action space mismatch를 만든다. DeepSeek-V3.2는 sampling 시의 truncation mask를 보존하고, training 때 current policy에도 같은 mask를 적용한다. 이를 통해 importance sampling 원칙을 덜 깨고 language consistency를 유지하려 한다.

내가 보기엔 이 네 가지는 모두 같은 방향을 향한다.

RL scaling의 병목은 reward design만이 아니라, rollout을 만든 시스템과 gradient를 계산하는 시스템 사이의 불일치다.

6) Thinking in Tool-Use: reasoning trace를 언제 보존할 것인가

DeepSeek-R1식 thinking은 complex reasoning에 유용하지만, tool-use scenario에서는 그대로 쓰기 어렵다. tool call이 여러 번 오가면 reasoning trace를 언제 버리고 언제 유지할지가 중요하다.

DeepSeek-V3.2의 context management rule은 다음과 같다.

• 새로운 user message가 들어오면 historical reasoning content를 버린다.
• tool output처럼 tool-related message만 추가되는 경우에는 reasoning content를 유지한다.
• reasoning trace를 제거하더라도 tool call history와 tool result는 context에 보존한다.

이 설계는 token efficiency를 위한 선택이다. DeepSeek-R1처럼 두 번째 round message가 오면 reasoning content를 버리는 방식은 multi-tool scenario에서 매번 처음부터 다시 reasoning하게 만들 수 있다. DeepSeek-V3.2는 tool interaction 중에는 reasoning을 유지해 반복 reasoning 비용을 줄이려 한다.

다만 논문은 중요한 caveat도 남긴다. Roo Code나 Terminus처럼 tool interaction을 user message로 simulate하는 framework에서는 이 context management가 충분히 작동하지 않을 수 있다. 이런 framework에서는 non-thinking model을 사용하는 것이 더 적절할 수 있다고 말한다.

7) Agentic task synthesis: hard-to-solve, easy-to-verify environment 만들기

DeepSeek-V3.2는 agentic RL task를 네 그룹으로 나눈다.

Agent task	Number of tasks	Environment	Prompt source
Code agent	24,667	real	extracted
Search agent	50,275	real	synthesized
General agent	4,417	synthesized	synthesized
Code interpreter	5,908	real	extracted

Search Agent는 web corpus에서 long-tail entity를 뽑고, question-construction agent가 search tool을 사용해 QA pair를 만든다. 여러 answer-generation agent가 후보 답을 만들고, verification agent가 search를 통해 ground truth와 후보 답을 검증한다. 이후 generative reward model이 rubric 기반으로 response를 scoring한다.

Code Agent는 GitHub issue-PR pair를 mining하고, gold patch와 test patch가 있는 executable environment를 만든다. 환경 구축 agent가 dependency installation, test execution, JUnit format output까지 처리한다. 환경은 gold patch 적용 시 false-to-positive test가 생기고 pass-to-fail regression이 없어야 유효하다고 본다.

General Agent는 automatic environment-synthesis agent가 1,827개의 task-oriented environment를 만든다. 예를 들어 여행 계획처럼 제약 조건이 많고 검색 공간은 크지만, candidate solution이 조건을 만족하는지는 programmatic verifier로 쉽게 확인할 수 있는 task를 만든다.

이 부분이 중요한 이유는 명확하다. Agent RL에서 좋은 데이터는 “그럴듯한 tool call trace”가 아니라 검증 가능한 environment다. DeepSeek-V3.2는 model이 실패할 수 있을 만큼 어렵지만 reward를 자동으로 줄 수 있는 task를 대규모로 만드는 데 집중한다.

4. Training / Data / Recipe

4-1. Data

논문이 pretraining data mixture 자체를 자세히 공개하지는 않는다. DSA continued pre-training에 대해서는 두 stage 모두 DeepSeek-V3.1-Terminus의 128K long-context extension data distribution과 aligned되어 있다고 설명한다.

구체적으로 공개된 것은 DSA 도입을 위한 continued pre-training 규모와 agentic post-training data construction이다.

• Dense warm-up: 1,000 steps, step당 16 sequences x 128K tokens, 총 2.1B tokens
• Sparse training: 15,000 steps, step당 480 sequences x 128K tokens, 총 943.7B tokens
• Sparse training에서 query마다 2,048 key-value tokens 선택
• Agent tasks: code / search / general / code interpreter를 합쳐 85K 수준의 prompt/task가 구성됨
• General synthetic environments: 1,827 environments, 4,417 tasks

여기서 조심해야 할 점은, 논문이 “data recipe를 충분히 공개했다”기보다 agentic data generation pattern을 공개했다에 가깝다는 것이다. Pretraining mixture, filtering threshold, reward model training detail 등은 여전히 완전한 재현을 위해서는 부족하다.

4-2. Training strategy

Training flow를 크게 보면 다음 순서다.

1. DeepSeek-V3.1-Terminus 128K checkpoint에서 시작
2. DSA dense warm-up
   • dense attention 유지
   • main model freeze
   • lightning indexer만 attention distribution imitation으로 학습
3. DSA sparse continued pre-training
   • top-k token selection 활성화
   • main model과 indexer 모두 학습
   • indexer input detach
   • main model은 LM loss, indexer는 KL alignment loss로 학습
4. Specialist distillation
   • domain별 specialist model 생성
   • thinking / non-thinking data를 따로 생성
5. Mixed RL training
   • GRPO 기반
   • reasoning, agent, human alignment를 하나의 RL stage에 통합
6. DeepSeek-V3.2-Speciale 실험
   • reasoning data만 사용
   • reduced length penalty
   • DeepSeekMath-V2 dataset / reward method 일부 사용

이 recipe에서 흥미로운 점은 DSA와 post-training이 분리되어 있지 않다는 점이다. Final DeepSeek-V3.2 post-training도 sparse attention을 유지한 채 진행된다. 즉 sparse attention은 inference optimization trick이 아니라 final model의 학습 trajectory 안에 들어간다.

4-3. Engineering notes

이 논문은 engineering note가 꽤 많다. 특히 아래 포인트들이 실무적으로 중요하다.

DSA는 성능 향상보다 parity가 먼저다

DSA를 넣는 목적은 dense attention 대비 capability를 크게 올리는 것이 아니다. 목적은 long-context efficiency를 개선하면서 기존 DeepSeek-V3.1-Terminus 수준의 성능을 유지하는 것이다. 논문도 DeepSeek-V3.2-Exp와 V3.1-Terminus의 standard benchmark, ChatbotArena Elo, long-context eval을 비교해 “성능 손상이 크지 않다”는 점을 먼저 보인다.

RL scaling은 framework consistency 문제다

Keep Routing과 Keep Sampling Mask는 paper algorithm이라기보다 distributed RL system에서 생기는 mismatch를 막는 장치다. MoE expert route가 rollout과 training에서 달라지면 같은 sample로 다른 parameter subset을 update하게 된다. Top-p/top-k sampling mask가 다르면 action space가 달라진다. 이런 작은 불일치가 대규모 RL에서는 누적된다.

Agent context management는 benchmark score의 일부다

BrowseComp에서 context management를 사용하면 score가 크게 달라진다. 논문은 DeepSeek-V3.2의 BrowseComp score를 51.4 / 67.6*처럼 표기하며, 별표는 context management technique 적용을 의미한다. 즉 agent benchmark는 model weight만의 함수가 아니라 context strategy의 함수다.

Speciale는 capability frontier이지만 serving model과는 다르다

DeepSeek-V3.2-Speciale는 length penalty를 완화해 더 긴 reasoning token을 쓰는 high-compute variant다. 성능은 강하지만 token efficiency는 나빠진다. 논문도 Gemini-3.0-Pro 대비 token efficiency가 열세라고 명시한다. 따라서 Speciale 결과는 “가능한 최고 성능”을 보여주는 실험으로 보고, official V3.2는 cost-latency trade-off를 고려한 checkpoint로 보는 편이 낫다.

5. Evaluation

5-1. Main results

논문은 DeepSeek-V3.2를 Claude-4.5-Sonnet, GPT-5 High, Gemini-3.0 Pro, Kimi-K2 Thinking, MiniMax M2 Thinking 등과 비교한다. 다만 이 비교는 논문이 설정한 evaluation protocol과 internal environment에 의존하므로, 수치를 읽을 때는 “논문 기준”이라는 전제를 붙이는 것이 안전하다.

선별된 결과를 축별로 정리하면 다음과 같다.

Axis	Metric	DeepSeek-V3.2 Thinking	해석
General / Knowledge	MMLU-Pro	85.0	GPT-5 High 87.5, Gemini-3.0 Pro 90.1보다는 낮지만 Kimi-K2 Thinking 84.6과 유사
Science Reasoning	GPQA Diamond	82.4	GPT-5 High 85.7, Gemini-3.0 Pro 91.9 대비 낮음
Hard Knowledge	HLE text-only	25.1	GPT-5 High 26.3과 유사, Gemini-3.0 Pro 37.7과는 차이 큼
Math	AIME 2025	93.1	GPT-5 High 94.6, Gemini 95.0, Kimi 94.5와 가까운 구간
Math	HMMT Feb 2025	92.5	GPT-5 High 88.3, Kimi 89.4보다 높고 Gemini 97.5보다 낮음
Code	LiveCodeBench	83.3	GPT-5 High 84.5, Kimi 82.6과 비슷한 수준
Code Agent	Terminal Bench 2.0	46.4	open model 대비 강하지만 Gemini 54.2보다는 낮음
Code Agent	SWE Verified	73.1	GPT-5 High 74.9, Gemini 76.2, Claude 77.2와 비교 가능한 범위
Search Agent	BrowseComp	51.4 / 67.6*	context management 적용 시 크게 상승
Tool Use	MCP-Universe	45.9	Gemini 50.7, GPT-5 High 47.9보다 낮지만 open models 대비 강함
Tool Use	MCP-Mark	38.0	GPT-5 High 50.9, Gemini 43.1에는 못 미침
Tool Use	Tool-Decathlon	35.2	Claude 38.6, Gemini 36.4와 근접, GPT-5 High 29.0보다 높음

논문이 강조하는 메시지는 다음과 같다.

• Reasoning benchmark에서는 DeepSeek-V3.2가 GPT-5 High와 비슷한 구간까지 접근했지만, Gemini-3.0-Pro에는 대체로 뒤진다.
• Coding / code agent에서는 open model 대비 강한 결과를 보인다.
• Search agent와 tool-use에서는 context management가 결과에 큰 영향을 준다.
• Agent benchmark에서 DeepSeek-V3.2는 기존 open model 대비 gap을 줄이지만, frontier closed model과의 gap은 여전히 남아 있다.

5-2. DeepSeek-V3.2-Speciale: 성능은 올라가지만 token efficiency가 비싸다

DeepSeek-V3.2-Speciale는 official serving-oriented model이라기보다 high-compute reasoning variant로 읽는 것이 맞다. length penalty를 줄이고 reasoning data 중심으로 학습해 더 긴 output token budget을 사용한다.

논문 Table 3 기준으로 일부 결과는 다음과 같다.

Benchmark	DeepSeek-V3.2	DeepSeek-V3.2-Speciale	차이
AIME 2025	93.1 (16k)	96.0 (23k)	accuracy 상승, token 증가
HMMT Feb 2025	92.5 (19k)	99.2 (27k)	큰 상승
HMMT Nov 2025	90.2 (18k)	94.4 (25k)	상승
IMOAnswerBench	78.3 (27k)	84.5 (45k)	상승, token 크게 증가
LiveCodeBench	83.3 (16k)	88.7 (27k)	상승
Codeforces	2386 (42k)	2701 (77k)	rating 상승, token 매우 증가
GPQA Diamond	82.4 (7k)	85.7 (16k)	상승
HLE	25.1 (21k)	30.6 (35k)	상승

이 결과는 “더 오래 생각하면 더 잘한다”는 단순한 메시지를 준다. 하지만 동시에 중요한 한계를 보여준다. DeepSeek-V3.2-Speciale는 여러 benchmark에서 강해지지만, output token count가 크게 증가한다. 논문도 Speciale의 token efficiency가 Gemini-3.0-Pro 대비 열세라고 말한다.

Competition-style 평가에서는 다음 결과가 보고된다.

Competition	DeepSeek-V3.2-Speciale result	Medal
IMO 2025	35 / 42	Gold
CMO 2025	102 / 126	Gold
IOI 2025	492 / 600	Gold
ICPC WF 2025	10 / 12	Gold

여기서도 주의할 점이 있다. IOI / ICPC / IMO / CMO 평가는 일반 benchmark와 다르게 generation length, sampling, filtering, generate-verify-refine loop 등 protocol에 민감하다. 논문은 Appendix D에서 protocol을 설명하지만, 이 수치를 일반 서비스 성능으로 바로 옮겨 읽으면 과하다.

5-3. Agentic synthesis와 context management가 보여주는 것

논문의 agentic task synthesis ablation도 중요하다. General synthesized task 50개를 샘플링해 평가했을 때 DeepSeek-V3.2-Exp는 Pass@1 12%, Sonnet-4.5는 34%, Gemini-3.0 Pro는 51%, GPT-5-Thinking은 62%를 기록한다. 즉 synthesized tasks가 너무 쉬운 self-play toy가 아니라, frontier model에도 어려운 task를 포함한다는 주장이다.

또 synthetic general agent data만으로 RL을 돌렸을 때 Tau2Bench, MCP-Mark, MCP-Universe에서 DeepSeek-V3.2-SFT 대비 개선이 나타난다. 반대로 code/search scenario에만 제한된 RL은 이 benchmark들에서 개선이 작다. 이건 agent generalization에 domain-diverse synthetic task가 중요할 수 있음을 시사한다.

Context management 실험도 실무적으로 중요하다. Search agent에서 context usage가 80%를 넘으면 다음 전략을 사용한다.

1. Summary: overflowed trajectory를 요약하고 rollout을 재시작
2. Discard-75%: tool call history 앞 75%를 버림
3. Discard-all: 이전 tool call history를 모두 버리고 context reset
4. Parallel-fewest-step: 여러 trajectory를 병렬 샘플링하고 가장 step 수가 적은 trajectory를 선택

논문은 Summary가 average step을 364까지 늘려 BrowseComp 60.2를 달성하지만 효율이 낮고, Discard-all은 67.6으로 더 높은 점수와 좋은 scalability를 보인다고 설명한다. 여기서 중요한 takeaway는 agent benchmark에서 context management가 단순 compression trick이 아니라 test-time compute scaling method라는 점이다.

5-4. What really matters in the experiments

내가 보기엔 이 논문의 실험에서 진짜로 중요한 것은 절대 점수보다 다음 세 가지다.

1) DSA parity

Sparse attention을 flagship model에 넣을 때 가장 중요한 것은 “얼마나 빨라졌는가” 이전에 “얼마나 덜 망가졌는가”다. DeepSeek-V3.2-Exp가 V3.1-Terminus와 유사한 standard benchmark / human preference / long-context performance를 유지한다는 점이 DSA의 핵심 validation이다.

2) RL compute scaling의 안정화

DeepSeek-V3.2의 reasoning 성능은 더 큰 post-training compute와 연결되어 있다. 하지만 논문의 가치는 “RL을 많이 했다”가 아니라, RL을 많이 하기 위해 필요한 estimator / off-policy / routing / sampling consistency 문제를 구체적으로 적은 데 있다.

3) Agent 성능은 model + environment + context policy의 합성 결과다

BrowseComp, MCP, Tool-Decathlon 같은 agent benchmark는 model weight만 비교한다고 끝나지 않는다. 어떤 tool role format을 쓰는지, internal environment가 official과 얼마나 다른지, context management를 켰는지, thinking mode가 framework와 맞는지에 따라 결과가 달라진다.

그래서 DeepSeek-V3.2의 agent 결과는 “open model이 closed model을 이겼다/졌다”보다, agentic post-training과 test-time context policy가 성능의 일부가 되었다는 관점으로 읽는 편이 낫다.

6. Limitations

1. World knowledge gap은 여전히 남아 있다.
   논문은 DeepSeek-V3.2가 Gemini-3.0-Pro 같은 frontier closed model 대비 total training FLOPs가 적고, 그 결과 world knowledge breadth가 부족하다고 명시한다. 이는 HLE나 GPQA 같은 benchmark에서 드러나는 차이와도 연결된다.

2. Token efficiency가 큰 과제다.
   DeepSeek-V3.2-Speciale는 더 긴 reasoning으로 성능을 끌어올리지만, output token count도 크게 증가한다. 실제 serving에서는 token cost, latency, context overflow가 모두 문제가 된다. 논문도 reasoning chain의 intelligence density를 높이는 것이 future work라고 말한다.

3. Complex task에서는 frontier model 대비 gap이 있다.
   Tool-use, MCP-Mark, GPQA, HLE 등에서는 여전히 Gemini-3.0-Pro나 GPT-5 High 대비 낮은 결과가 있다. 논문 자체도 complex task 해결 능력은 frontier model보다 낮다고 인정한다.

4. Agent benchmark의 comparability가 완전히 깨끗하지 않다.
   MCP-Universe와 MCP-Mark는 internal environment에서 평가되며, search / playwright environment가 official setting과 다를 수 있다고 논문이 밝힌다. SWE Verified도 primary score는 internal framework 기준이고, 다른 framework robustness는 범위로 보고된다. 따라서 agent score는 재현 환경까지 같이 봐야 한다.

5. Context management가 score의 일부다.
   BrowseComp의 67.6*은 context management 적용 결과다. without context management score는 51.4다. 즉 model 자체 성능과 test-time trajectory management 성능을 분리해서 읽어야 한다.

6. DSA의 exact speedup은 deployment stack에 의존한다.
   Figure 3은 H800 cluster, 특정 service deployment, 2 USD / GPU hour 가정의 cost plot이다. 다른 GPU, batch size, inference kernel, serving scheduler에서는 cost curve가 달라질 수 있다.

7. Data / reward model 재현성은 제한적이다.
   논문은 agent task synthesis pipeline을 꽤 자세히 설명하지만, pretraining data mixture, reward model 세부, filtering criteria, specialist data generation detail은 완전 재현 가능한 수준까지 공개되지는 않는다.

7. My Take

7-1. Why this matters for my work

이 논문은 LLM 연구와 실무가 어디로 가고 있는지를 꽤 잘 보여준다. 최근까지 LLM technical report를 읽을 때는 model size, data tokens, MoE routing, tokenizer, benchmark를 중심으로 봤다. 그런데 DeepSeek-V3.2에서는 관점이 더 system-oriented로 이동한다.

• attention은 architecture block이면서 동시에 serving cost function이다.
• RL은 algorithm이면서 동시에 rollout system / inference framework / training framework consistency 문제다.
• agent data는 instruction data가 아니라 environment construction problem이다.
• test-time compute는 단순 sampling budget이 아니라 context management policy다.

내가 보기엔 DeepSeek-V3.2는 “open model도 frontier 성능에 가까워졌다”보다 frontier급 model을 만들기 위한 recipe가 점점 infrastructure-heavy해지고 있다는 점에서 더 중요하다.

특히 agent 쪽에서 배울 점이 많다. 많은 agent 프로젝트는 prompt, tool schema, planner를 먼저 만진다. 그런데 DeepSeek-V3.2는 agent training을 environment synthesis, verifier, reward rubric, context retention rule, RL stability까지 포함한 full-stack problem으로 본다. 이 관점은 실제 서비스형 agent를 만들 때 훨씬 현실적이다.

7-2. Reuse potential

실무나 연구에서 바로 재사용할 만한 아이디어는 다음과 같다.

1) Context management as test-time scaling

긴 agent trajectory에서 context가 차면 무조건 summarization만 쓰는 대신, task 성격에 따라 Summary / Discard-75% / Discard-all / parallel rollout을 비교하는 실험은 바로 재사용할 수 있다. 특히 search agent나 data analysis agent에서는 과거 tool history를 모두 보존하는 것이 항상 최선이 아니다.

2) Keep Routing for MoE RL

MoE 모델로 RL을 한다면 rollout 시의 expert route와 training 시의 expert route를 맞추는 것은 매우 중요해 보인다. 이건 논문 contribution이라기보다 production RL system에서 반드시 체크해야 할 consistency invariant에 가깝다.

3) Agent environment synthesis

General agent task를 만들 때 “정답 생성이 어려운가”보다 “정답 검증이 쉬운가”를 먼저 보는 접근이 좋다. 여행 계획 예시처럼 constraint satisfaction 형태로 task를 만들면 verifier를 붙이기 쉽고, RL reward도 안정적으로 줄 수 있다.

4) Specialist distillation + mixed RL

도메인별 specialist를 먼저 만들고, 그 distilled data를 final general model에 넣은 뒤 mixed RL로 domain balance를 맞추는 흐름은 꽤 재사용 가치가 있다. 특히 coding, math, search, general QA가 섞인 모델을 만들 때 multi-stage fine-tuning보다 안정적일 수 있다.

5) Sparse attention parity evaluation

새 sparse attention을 붙일 때는 최종 benchmark 상승만 보지 말고, 이전 dense model과의 parity evaluation을 먼저 해야 한다. standard benchmark, human preference proxy, long-context benchmark를 나눠서 regression을 확인하는 방식은 다른 architecture 실험에도 그대로 쓸 수 있다.

7-3. Follow-up papers

이 논문을 제대로 이해하려면 아래 흐름으로 이어 읽는 것이 좋다.

• DeepSeek-V3 Technical Report
  MLA, DeepSeekMoE, MTP, FP8 training 등 DeepSeek base architecture lineage를 이해하기 위해 필요하다.

• DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning
  GRPO와 reasoning RL이 DeepSeek-V3.2 post-training에 어떻게 이어지는지 보기 좋다.

• DeepSeekMath / DeepSeekMath-V2
  GRPO와 mathematical proof capability, generate-verify-refine style evaluation을 이해하는 데 필요하다.

• Native Sparse Attention
  DeepSeek Sparse Attention과 비교해 sparse attention을 hardware-aligned system problem으로 보는 관점을 보완해준다.

• Efficient Memory Management for Large Language Model Serving with PagedAttention
  long-context serving에서 attention/KV cache가 실제 system bottleneck이 되는 이유를 이해하는 데 좋다.

• Tool-use / MCP / SWE-bench 계열 evaluation papers
  DeepSeek-V3.2의 agent results를 benchmark protocol 관점에서 다시 해석하기 위해 필요하다.

8. Summary

• DeepSeek-V3.2는 DSA, scalable GRPO, agentic task synthesis를 결합한 open LLM system report다.
• DSA의 핵심은 DeepSeek-V3.1-Terminus lineage를 유지하면서 sparse top-k key-value selection을 넣고, long-context cost curve를 개선하는 것이다.
• Post-training의 핵심은 GRPO를 크게 돌릴 때 생기는 KL, off-policy, MoE routing, sampling mask mismatch를 줄이는 것이다.
• Agent 성능은 synthetic / real-tool environment construction과 thinking context management까지 포함한 pipeline 결과로 봐야 한다.
• 가장 큰 한계는 world knowledge gap, token efficiency, internal evaluation environment, context management 의존성이다.