DeepSeek-Coder-V2: 오픈소스 코드-LLM이 GPT-4 급으로 뛰어오른 순간
한 줄 요약 (TL;DR)
236 B 파라미터 MoE + 10.2 T 토큰 + YaRN 128 K 컨텍스트 만으로, **HumanEval 90.2 %·MATH 75.7 %**를 기록해 오픈모델 최초로 GPT-4-Turbo와 동일 선상에 올라섰다. —
핵심 아이디어
거대하지만 희소한 Mixture-of-Experts 구조에 초대형 코드·수학 데이터를 투입하고, RoPE를 YaRN으로 확장해 “성능-규모-메모리” 삼각 역설을 동시에 깨트린다.
배경: 그들이 해결한 문제
- 성능 격차 – StarCoder, CodeLlama 등 공개 모델은 HumanEval ≤ 79 %, MATH ≤ 60 %로 GPT-4 계열보다 10 %p 이상 낮았다.
- 스케일 한계 – 오픈코드-LLM 최대 규모가 70 B 파라미터였고, 긴 코드베이스(> 16 K tokens)를 처리하지 못했다.
- 추론 비용 – “성능을 올리려면 파라미터가 폭증”이라는 통설 때문에 실제 서빙이 어려웠다.
새로운 접근법: DeepSeek-Coder-V2
| 구성 요소 | 새로움 | 핵심 효과 |
|---|---|---|
| 236 B Top-2 MoE (128 experts, 21 B 활성) | 대규모 코드-LLM 최초 100 B+ | 70 B Dense 수준 메모리로 GPT-4 급 정확도 |
| 10.2 T 멀티소스 코퍼스 (코드 60 %, 수학 10 %, NL 30 %) | 언어 86→338개, 수학 데이터 대폭 확대 | 코드·수학 능력 동시 향상 |
| YaRN(×32) RoPE 외삽 | RoPE 각도 축소만으로 128 K 컨텍스트 | 대형 리포지토리·멀티파일 프로그래밍 지원 |
| GRPO Alignment | Critic 없는 경량 RLHF | Instruction-following 성능 개선 |
작동 원리: 구체적인 예시로 살펴보기
- 토큰
["a", "+", "b"]를 BPE로 변환. - Embed + YaRN: 위치
p를p/32로 압축해 128 K 토큰까지 각도를 안정화. - Router가 각 토큰을 확률 분포
g = [g₁, g₂,…]로 스코어링 → 상위 2개 전문가 $E_1, E_2$ 선택. - 전문가별 FFN이 독립적으로 변환 후, 가중 합 $o = g_{E_1}·\text{FFN}{E_1}(h)+g{E_2}·\text{FFN}_{E_2}(h)$.
- 96개 층을 거치며 21 B 파라미터만 활성화되므로 연산량이 Dense 70 B와 유사하다.
- 16 B Lite 모델은 입력을
<prefix><suffix>[HOLE] <middle>형태로 섞어 Fill-In-Middle 학습까지 수행, IDE 인라인 완성 품질을 끌어올린다.
성능 검증: 주요 결과
| 벤치마크 | DeepSeek-Coder-V2 | 기존 공개 최고 | GPT-4-Turbo / GPT-4o |
|---|---|---|---|
| HumanEval | 90.2 % | 78 % (CodeLlama-70 B) | 88–91 % |
| MBPP+ | 76.2 % | 68 % | 74–76 % |
| LiveCodeBench | 43.4 % | 34.6 % (Codestral-22 B) | 45.7 % |
| SWE-Bench | 12.7 % | 2.7 % | 18–27 % |
| MATH | 75.7 % | 60 % | 76.6 % |
| GSM8K | 94.9 % | 90.8 % | 95 % |
| MMLU | 79.2 % | 80.0 % (Llama-3-70 B) | 86 %+ |
LiveCodeBench에서는 GPT-4o와 동률, SWE-Bench는 공개 모델 최초 두 자릿수, MATH는 GPT-4o와 0.9 %p 차이에 불과.
우리의 관점: 강점, 한계, 그리고 이 연구가 중요한 이유
강점
- 성능 vs 비용의 새로운 균형: 236 B 총량으로 표현력을 확보하면서도 21 B 활성 덕분에 추론 메모리는 억제.
- 다언어·장문 코드 지원: 338개 언어, 128 K 토큰 창까지 수용해 실전 대형 저장소를 한 번에 처리.
- 개방 라이선스: 연구·상업 모두 허용되어 생태계 파급력이 크다.
한계
- Instruction-following·지식 QA는 여전히 GPT-4-Turbo에 뒤처짐(MMLU, TriviaQA).
- 연산/서빙 복잡도: MoE 라우팅-통신, 236 B 전체 파라미터 저장은 고비용 인프라를 요구.
- 법·안전 리스크: GPL 코드 포함 가능성과 잠재적 취약 코드 생성에 대한 대응책이 논문에 없다.
왜 중요한가?
오픈소스 진영이 드디어 “코드·수학 = GPT-4 급” 라는 상징적 벽을 넘어섰고, 희소화 + 데이터 설계 + RoPE 외삽 조합이 규모-성능-비용 삼각 문제를 해결할 현실적 로드맵임을 증명했다.
다음 단계는?: 앞으로의 길
- Instruction Alignment 업그레이드 – GRPO를 확장해 복합·장기 지시 수행력 강화.
- 웹·지식 데이터 보강 – TriviaQA·NaturalQuestions 격차 해소를 위한 대규모 크롤·RAG 프리트레인.
- 서빙 최적화 연구 – Expert-Locality 스케줄링, 4-bit NF4 양자화로 지연·비용 감축.
- 안전·라이선스 툴체인 – SPDX 태깅, 취약 코드 정적 분석 루프, 법적 클린룸 데이터셋 구축.
- 128 K+ 품질 검증 – Doc-QA, RepoBench 등 실제 긴 사용 시나리오에서 논리 일관성·버그율 측정.
맺음말
DeepSeek-Coder-V2는 “오픈소스는 성능이 한참 뒤처진다”는 통념을 무너뜨렸다. 앞으로 지시 이해와 운영 효율만 다듬으면, 닫힌 모델 의존도를 대폭 줄인 새로운 개발 워크플로우가 가능해질 것이다.
토글을 클릭하면 논문에 대한 자세한 LLM 질의응답 내용을 확인할 수 있습니다.
▶️클릭하여 펼치기
프롬프트 1.1.1 (연구의 공백)
"논문의 'Introduction'과 'Related Work' 섹션을 분석하여, 이 연구가 명시적으로 해결하고자 하는 핵심적인 연구 공백(research gap), 기존 연구의 결정적 한계, 또는 미해결 질문이 무엇인지 설명해 줘. 저자들이 설명하는, 이 논문 출판 시점의 '최신 기술(state of the art)'은 어떤 상태였는지 요약해 줘."
한눈에 보는 결론 (TL;DR)
닫힌 모델(GPT-4-Turbo, Claude 3, Gemini 1.5)에 비해 코드·수학 작업 정확도가 10 %p 이상 뒤처지던 오픈소스 코드-LLM의 격차를 메우기 위해, DeepSeek-Coder-V2는 ① 236 B-MoE(21 B active) 규모의 초대형 모델, *② 6 조 토큰 추가 사전학습(총 10.2 T), *③ 컨텍스트 16 K→128 K 확장으로 HumanEval 90.2 %, MATH 75.7 %로 GPT-4-Turbo와 동급 성능을 달성했다.
1. 연구 공백 (Research Gap)
| 미해결 문제 | 기존 한계 | DeepSeek-Coder-V2의 해결책 |
|---|---|---|
| 오픈소스 코드-LLM 성능 한계 | StarCoder, CodeLlama, DeepSeek-Coder-33B 등은 HumanEval ≤ 79 % 수준 → GPT-4-Turbo 88 % 대비 9–12 %p 차이 | 236 B MoE + 6 T 추가 데이터로 HumanEval 90.2 % 달성 → 격차 해소 |
| 대규모 다언어·장문 코드 처리 미비 | 기존 모델 지원 언어 ≤ 86개·컨텍스트 ≤ 16 K → 대형 저장소·멀티파일 상황 대응 부족 | 언어 338개(+252), 컨텍스트 128 K(+8×) 지원 |
| 수학·추론 능력 부족 | MATH ≤ 50–60 %로 폐쇄형 SoTA 대비 15 %p 이상 열세 | MATH 75.7 %, GSM8K 94.9 %로 GPT-4o 76.6 %에 근접 |
| 백억-단위 오픈소스 코드 모델 부재 | 70 B(Llama 3)·33 B(DeepSeek-Coder) 등에 머무름 | 첫 100 B+ 오픈소스 코드 모델(236 B) 공개 및 자유 라이선스 |
2. 최신 기술 (State-of-the-Art) 요약
| 범주 | 폐쇄형 SoTA (2024 Q2 기준) | 오픈소스 최상위 (기존) | DeepSeek-Coder-V2 |
|---|---|---|---|
| 모델 대표 | GPT-4-Turbo, Claude 3 Opus, Gemini 1.5 Pro | Codestral 22 B, Llama-3 70 B, DeepSeek-Coder 33 B | DeepSeek-Coder-V2 236 B |
| HumanEval | 88 – 91 % | ≤ 78 % | 90.2 % |
| MBPP+ | 74 – 76 % | ≤ 68 % | 76.2 % |
| MATH | 76.6 %(GPT-4o) | ≤ 60 % | 75.7 % |
| LiveCodeBench | 45.7 %(GPT-4-Turbo) | 34.6 %(Codestral) | 43.4 % |
| 파라미터(총/활성) | ~1 T / 공개 안 됨 | 70 B / 70 B | 236 B / 21 B MoE |
| 컨텍스트 길이 | 128 K(Gemini 1.5) | 16 K | 128 K |
| 지원 언어 수 | 대부분 비공개 | 86(CodeLlama/StarCoder) | 338 |
정리
- 연구 공백 — 오픈소스 모델이 폐쇄형 SoTA 대비 성능·스케일·장문 처리에서 모두 부족했다.
- 기술적 기여 — DeepSeek-Coder-V2는 ▲백억-단위 MoE 설계, ▲코드 60 %·수학 10 %·NL 30 %의 6 T 신규 코퍼스, ▲YARN 기반 128 K 컨텍스트 확장으로 이 격차를 메웠다.
- 현재 SoTA — 코드·수학 영역에서는 사실상 GPT-4-Turbo와 어깨를 나란히 하며, 오픈소스 진영의 성능 장벽을 돌파했다는 점이 핵심 의미다.
프롬프트 1.1.2 (핵심 가설)
"이 논문의 중심 가설(central hypothesis) 또는 핵심 주장은 무엇인가? '저자들은 [제안 기법]을 사용함으로써 [기존 한계점]을 극복하는 [구체적 결과]를 달성할 수 있다고 가정한다'와 같은 형식으로, 명확하고 간결한 한 문장으로 서술해 줘."
저자들은 236 B 파라미터의 MoE 구조·6 T 추가 사전학습·128 K 컨텍스트 확장을 적용한 DeepSeek-Coder-V2를 통해, 오픈소스 코드-LLM이 지니던 GPT-4-Turbo 등 폐쇄형 모델 대비 코드·수학 정확도 및 장문 처리 한계를 극복하여 HumanEval 90.2 %・MATH 75.7 % 등 동급 성능을 달성할 수 있다고 가정한다.
프롬프트 1.2.1 (독창성 식별)
"논문 전체를 바탕으로, 가장 중요하고 독창적인 기여(contribution) 1~3가지를 구별되는 항목으로 나열해 줘. 각각이 새로운 아키텍처 구성요소, 새로운 학습 기법, 새로운 이론적 통찰, 새로운 데이터셋, 또는 기존 방법론의 새로운 적용 중 어디에 해당하는지 명확히 구분해 줘."
독창적 기여 Top 3
| # | 기여 내용 | 범주 |
|---|---|---|
| 1 | 236 B-parameter Mixture-of-Experts(MoE) 코드-LLM — 총 236 B 파라미터 중 활성(전문가 선택) 파라미터는 21 B(≈9 %)만 사용하도록 설계해, 백억 단위이면서도 70 B 단일 모델 수준의 GPU 메모리로 학습·추론이 가능하게 함. | 새로운 아키텍처 구성요소 (대규모 MoE 설계) |
| 2 | 10.2 T 토큰 대규모 멀티소스 코퍼스 — 신규 6 T 토큰을 추가 수집하여 전체 학습량을 10.2 T로 확장. 구성은 ▲코드 60 %(1.17 T, 338개 언어) ▲수학 10 %(221 B) ▲자연어 30 %로, 코드 언어 수를 86→338로 4× 확대. | 새로운 데이터셋 (초대형 멀티도메인·다언어 코드 + 수학 코퍼스) |
| 3 | YARN 기반 128 K 토큰 컨텍스트 확장 — 기존 16 K 한계를 8× 늘려 대형 저장소·다파일 입력을 한 번에 처리하며, HumanEval 90.2 %·LiveCodeBench 43.4 % 수준의 장문 코드 완전성을 실증. | 기존 방법론의 새로운 적용 (YARN 긴 컨텍스트 기법을 코드-LLM에 최초 대규모 적용) |
프롬프트 1.2.2 (저자 관점에서의 강점)
"저자들의 관점에서, 자신들의 접근법이 이전 방법들보다 우월한 이유는 무엇인가? 그들이 자신들의 연구가 지닌 독창성과 강점을 뒷받침하기 위해 사용하는 핵심 논거를 인용하거나 알기 쉽게 설명해 줘."
한눈에 보는 결론
저자들은 “성능·규모·메모리 효율·장문 처리·개방성” 의 다섯 축에서 기존 오픈소스 코드-LLM을 압도한다고 주장한다.
| 핵심 논거 | 왜 우월한가? | 근거(저자 인용) |
|---|---|---|
| 1. 폐쇄형 SoTA급 코드·수학 성능 | HumanEval 90.2 %, MATH 75.7 % 등으로 GPT-4-Turbo·Claude 3 Opus와 동급이며 모든 오픈소스 모델을 크게 앞섬 | “코드·수학 벤치마크에서 GPT-4 Turbo·Gemini 1.5 Pro에 필적” |
| 2. 236 B MoE→21 B 활성 파라미터 | 100 B+ 최초 오픈소스 코드 모델이면서도 활성 파라미터가 9 %에 불과해 70 B 단일 모델 수준의 GPU 메모리·추론 비용 | “MoE 프레임워크로 236 B 총↔21 B 활성 파라미터” |
| 3. 6 T 추가·다언어(338) 데이터셋 | 코드 언어 수 86→338, 총 10.2 T 토큰 노출로 데이터 다양성·전이 학습 효과 입증—1 B 모델에서도 HumanEval +6.7 %↑ | “새 코드 코퍼스가 기존 대비 우수, 소규모 실험서도 성능 향상” |
| 4. 128 K 컨텍스트 확장 (YARN) | 대형 저장소·멀티파일 입력을 한 번에 처리하며 NIAH 테스트 전 구간에서 높은 정확도 유지 | “128 K까지 안정적, NIAH 전 길이 구간에서 우수” |
| 5. 자유 라이선스 공개 | 연구·상업 모두 무제한 사용 가능해 생태계 파급력 확보 | “236 B 모델을 permissive license로 공개” |
핵심 메시지
“백억-단위 MoE 구조 + 초대형 다언어·수학 코퍼스 + 128 K 컨텍스트를 결합해, 오픈소스 모델이 처음으로 폐쇄형 최고 성능을 실질적으로 추월 또는 동률로 만들었다.”
즉, 저자들은 **“성능 격차를 사실상 제거하면서도(①) 메모리·비용 효율성(②)과 데이터 범용성(③)을 함께 달성했고, 실무적 긴 입력 처리(④)까지 가능하며, 누구나 활용할 수 있도록 공개했다(⑤)”**는 점을 자신들의 접근법의 결정적 강점으로 내세운다.
프롬프트 1.3.1 (알고리즘 단계별 설명)
"핵심 알고리즘, 모델 아키텍처, 또는 주요 방법론을 단계별(step-by-step)로 설명해 줘. 독자는 AI 분야의 대학원생 수준이라고 가정해. 특히, 간단한 문장, 3x3 픽셀 이미지, 작은 상태 공간(state space) 등 아주 간단하고 구체적인 예시(toy example)와 샘플 입력을 만들어서, 이 예시를 통해 각 단계를 거치며 입력이 최종 출력으로 어떻게 변환되는지 전체 과정을 보여줘. 등장하는 모든 핵심 용어와 변수는 그 즉시 정의해 줘."
TL;DR — 한 줄 핵심 알고리즘
“236 B-MoE Transformer + YARN(128 K) + FIM/NT-P 학습” 파이프라인이, 각 토큰을 ‘라우터→전문가 선택→합성’ 흐름으로 처리하여 오픈소스 최초 GPT-4-급 코드·수학 성능을 달성한다.
1. DeepSeek-Coder-V2 계산 그래프 : 단계별 흐름
| 단계 | 내부 연산 (주요 변수 정의) | 장치·특징 |
|---|---|---|
① 토큰화S → {t₀…tₙ} |
SentencePiece 기반 BPE로 코드·NL·수학 338 언어 공통 토큰 집합 사용 | 다언어 338개 |
② 임베딩 & YARN 위치 부호eᵢ = E[tᵢ] ⊕ YARN( posᵢ ; s=40, α=1, β=32 ) |
Rotary PE를 스케일링·오프셋해 128 K까지 안정화 | 128 K 컨텍스트 & YARN 파라미터 |
③ MH-Self-Attentionhᵢ = Attn(eᵢ , …) |
KV 캐시·Flash Attn; 긴 입력에서도 NIAH 전구간↑ | 긴 문맥 시험 결과 |
| ④ MoE Feed-Forward (L=96 계층) | 4-a. 라우팅 gᵢ = Softmax(W_r hᵢ)상위 k=2 확률 선택 → 전문가 id E₁,E₂4-b. 전문가 계산 oᵢ^j = FFN_{E_j}(hᵢ)4-c. 가중 합성 oᵢ = gᵢ¹·oᵢ¹ + gᵢ²·oᵢ² |
128 experts × ≈1.6 B 파라미터 each → 총 236 B, **활성 21 B (9 %)**만 메모리 사용 |
| ⑤ 잔차·정규화 & 반복 | 각 블록 출력은 LayerNorm→다음 층 입력 | Exponential Norm 제거해 학습 안정화 |
⑥ 출력 로짓p(next token)=Softmax( W_o h_last ) |
NT-Prediction, FIM (33 % 문서) 학습 목표 | FIM PSM 모드 설명 |
2. 장난감 예시 — 3 토큰 + 3×3 픽셀로 보는 MoE 한 사이클
입력 : 간단한 파이썬 코드
“a+b”토큰 :t₀=“a”,t₁=“+”,t₂=“b”
| 단계 | 토큰별 3×3 벡터(숫자는 toy) | 설명 |
|---|---|---|
| Embed | e₀=[[1,0,0]…]e₁=[[0,1,0]…]e₂=[[0,0,1]…] |
임베딩 + YARN RoPE 각 행 |
| Router gᵢ | g₀=[0.8,0.2]g₁=[0.1,0.9]g₂=[0.6,0.4] |
2 개 전문가 선택 (E₁, E₂) |
| Expert MLP 출력 oᵢʲ | E₁ :[[2,0,0]], E₂ :[[0,0,2]] 등 |
각 FFN이 다른 가중치 |
| 가중 합성 oᵢ | o₀ = 0.8·[2,0,0]+0.2·[0,0,2]=[1.6,0,0.4] |
고빈도 전문가 비중 ↑ |
| LayerNorm → 다음 층 | h₀ 갱신 |
다음 블록으로 반복 |
이렇게 “토큰→라우터→2 전문가→합성” 파이프가 96 층을 지나며 최종 확률 분포를 출력한다.
3. 왜 이 단계들이 중요한가?
-
MoE → 메모리·속도 효율 236 B 전체를 불러오지 않고 21 B만 활성하므로 70 B Dense 모델과 유사한 GPU 필요량으로 GPT-4-급 정확도를 달성.
-
YARN → 128 K 장문 코드 스케일 인자 40 등으로 RoPE 외삽 오류를 억제, NIAH 테스트 전길이에서 >90 % 유지.
-
FIM+NT-P 혼합 학습 함수·클래스 중간 삽입(PSM) 데이터를 50 % 비율로 노출해, 단일 줄 Infilling 벤치 최상위.
요약 한마디
라우터가 ‘토큰별로 최적 전문가 2 명’을 골라주는 거대 MoE Transformer에, 128 K YARN 포지션·PSM FIM 학습을 접목 → 폐쇄형 모델 수준의 코드·수학 능력을, 70 B 급 리소스로 누구나 재현·확장 가능하게 만든다.
프롬프트 1.3.2 (‘비밀 병기’ 식별)
"이 논문의 핵심 기여를 가능하게 하는 가장 결정적인 단일 수학 공식, 알고리즘 단계, 또는 아키텍처 구성요소를 식별해 줘. 그것의 기능과, 그것이 이 방법론의 성공에 왜 필수적인지 설명해 줘."
결론만 먼저 한 줄로
DeepSeek-Coder-V2의 ‘비밀 병기’는 Top-2 MoE 라우터 게이팅으로, 236 B 총 파라미터를 두 개의 전문가(≈ 21 B 활성 파라미터)만 선택·집중하게 함으로써 닫힌 모델급 정확도를 메모리·연산 비용 10 분의 1 수준으로 달성한다 .
1. 구성 & 수식 (Top-2 Router-Gate)
| 단계 | 연산 | 설명 |
|---|---|---|
| ① 게이트 로짓 계산 | $ \mathbf{g}_i=\operatorname{Softmax}(W_r\mathbf{h}_i)$ | 토큰 표현 $\mathbf{h}_i$를 라우터 행렬 $W_r$로 투영해 각 전문가 중요도를 추정 |
| ② 상위 2개 전문가 선택 | $E_1,E_2=\operatorname{TopK}(\mathbf{g}_i,k=2)$ | 부하 균형·희소성 확보 (각 토큰은 최대 2개 FFN만 통과) |
| ③ 전문가별 변환 | $ \mathbf{o}i=\sum{j\in{E_1,E_2}} g_i^{(j)}\; \mathrm{FFN}_j(\mathbf{h}_i)$ | 선택된 FFN 결과를 확률적 가중 합산 |
| ④ 로드-밸런싱 손실 | $\mathcal{L}_{\text{load}}=\sum_j\left(p_j-\frac{1}{N}\right)^2$ | 전문가 호출 편중을 완화해 학습 안정성 확보 |
변수 정의 — $\mathbf{h}_i$: i번째 토큰 은닉, $W_r$: 라우터 가중치, $g_i^{(j)}$: j번 전문가 확률, $N$: 전체 전문가(64 개), $p_j$: 배치 내 전문가 호출 비율.
2. 왜 필수적인가? (효과 정량)
| 항목 | Dense 236 B 가정 | MoE 236 B (Top-2) |
|---|---|---|
| 활성 파라미터/토큰 | 236 B | 21 B (↓ 11.1×) |
| GPU 메모리(추론) | ≈ 5.3 TB | ≈ 0.5 TB |
| HumanEval 정확도 | — (실험 불가) | 90.2 % |
| AIME 2024 점수 | — | 2/30 → GPT-4o 동급 |
- Top-2 라우팅이 없으면 모든 236 B FFN이 동시에 활성화되어 학습·추론 자원이 현실적으로 불가능.
- 같은 21 B 활성 규모의 Dense 모델(예: Llama-3 70 B) 대비 HumanEval +19 pp, MATH +8 pp 수준 성능 향상 .
- 부하-균형 손실이 없으면 특정 전문가에 토큰이 몰려 발산·품질 하락이 보고됨(저자 ablation).
3. 기능적 핵심
- 희소성 스케일링 — 파라미터 총량을 10× 이상 늘려 표현력을 확보하면서도 토큰-당 연산은 21 B에 머무름.
- 전문분업 — 코드·수학 같이 상이한 도메인 특징을 서로 다른 FFN이 학습, 다중 재능을 한 모델에 공존시킴.
- 학습 안정성 — Top-2 선택과 로드-밸런싱이 그래디언트 폭주를 막아 대규모 MoE 훈련을 ‘현실 가능’하게 함.
결국, Top-2 MoE 라우터가 없었다면 DeepSeek-Coder-V2는 ‘236 B 규모의 개방형 코드 모델’이라는 목표 자체가 성립하지 않았다—이것이 논문의 성패를 가른 단일 핵심 장치다.
프롬프트 1.3.3 (Yet Another RoPE eNhancement)
한눈에 보는 결론
YaRN( Yet another RoPE extensioN) 은 RoPE 각도를 “스케일 s 배로 압축” 하는 단순-치환만으로, 4 K-pretrain 모델을 64 K~128 K 토큰까지 안정적으로 확대한다.
- 400 스텝(≈0.1 % 토큰) 미세조정만으로 Llama-2 13 B를 128 K까지 확장하면서도 Code-Llama NTK 방식보다 **perplexity 20 %↓**를 기록했다 .
1. 왜 RoPE만으로는 길이를 못 늘리나?
RoPE는 차원 d별 회전주기(θ₍d₎)로 위치 p를 sin·cos(θ₍d₎ p) 에 각인한다. 훈련 길이 L₀ 밖(> 4 K)에서는 고차원 주기가 360°를 넘지 못해 각도가 “꺾여” 성능이 급락한다 (gradient.ai).
2. YaRN 핵심 아이디어 ― “스케일-s 압축”
- 목표 길이 결정 L_target = s × L₀ (예: 4 K→128 K면 s = 32).
-
위치 재매핑 실제 위치 p를
\[p'=\frac{p}{s}\]로 축소해 RoPE 각도 계산을 원래 범위(0 ∼ L₀) 안에 되돌린다.
- 동일 모델·가중치 유지
코드 한 줄:
theta = theta / s(HF 구현 기준). 구조나 파라미터 수는 변하지 않는다. -
짧은 Fine-Tuning
- 원본 토큰의 0.1 %만 사용해 64 K(혹은 128 K) 길이 샘플에 적응.
- 추가 기법: Dynamic Scaling — 실사용 길이 ℓ마다 s_dyn = max(1, √(ℓ/L₀)) 로 자동 조정해 추가 파인튜닝 없이 2× 이상 윈도우를 늘린다 .
3. 장난감 예시로 보는 동작
가정 : 원 모델 L₀ = 4, θ = 90°(1단위마다 90° 회전). 목표 : 8-토큰 입력(s = 2)을 처리.
| 위치 p | 원 RoPE 각도 θ·p | YaRN p′ = p/2 | YaRN 각도 θ·p′ |
|---|---|---|---|
| 0 | 0° | 0 | 0° |
| 4 | 360° | 2 | 180° |
| 7 | 630° | 3.5 | 315° |
원본에선 4·θ부터 이미 주기 넘침(360°=0°와 겹침) → 정보 소실. YaRN은 p′=3.5로 재투영돼 각도가 정상 범위(≤360°)에 머무르므로 장문에서도 위상 정보가 보존된다.
4. 다른 RoPE 확장법과 비교
| 방법 | 수식 한 줄 | 필요 토큰 | 13 B 모델 128 K PPL↓ | 특징 |
|---|---|---|---|---|
| PI (Position Interp.) | p′ = p · (L₀/Lₜ) | 4× | 3.67 | 간단하지만 주파수 왜곡 |
| NTK-Aware | θ′₍d₎ = θ₍d₎ / f(d) | 1× | 4.22 | 고주파 보정, 학습 필요 많음 |
| YaRN | p′ = p / s | 0.1× | 3.39 | 학습이 가장 적고 성능↑ |
5. 실전 파라미터 가이드
| 목적 컨텍스트 | 스케일 s | 권장 파인튜닝 길이 | GPU 메모리 증가 | 비고 |
|---|---|---|---|---|
| 64 K | 16 | 32 K~64 K | +0 % | DeepSeek-Coder-V2 |
| 128 K | 32 | 64 K | +0 % | Llama-2 YaRN |
| 256 K (동적) | √2× | 128 K 미세조정 없을 수도 | +0 % | Dynamic-YaRN |
*스케일 변경만으로 모델 크기는 그대로, 긴 컨텍스트 지원이 “공짜”*라는 점이 YaRN의 실질적 매력이다.
요약
YaRN = RoPE 위치를 p/s로 ‘압축’ + 소량 재학습. 덕분에 4 K 훈련 모델도 400 스텝만에 128 K 입력을 읽고, 같은 모델 크기로 기존 NTK 방식 대비 perplexity 최대 20 % 개선을 확인했다.
프롬프트 1.4.1 (핵심 결과 분석)
"'Experiments' 또는 'Results' 섹션의 표와 그림을 포함한 주요 결과를 분석해 줘. 사용된 핵심 성능 지표(performance metrics)는 무엇인가? 어떤 벤치마크 데이터셋에서 결과가 보고되었는가? 저자들이 자신들의 방법론의 성공 증거로 가장 강조하는 주요 결과를 요약해 줘."
요약 — 저자들이 강조한 “결정적 증거”
- 코드 생성: HumanEval 90.2 %, MBPP+ 76.2 %, LiveCodeBench 43.4 %, SWE-Bench 12.7 % → 모든 오픈소스 모델을 크게 앞서며, LiveCodeBench는 GPT-4o와 동률·SWE-Bench는 오픈소스 최초 두 자릿수 달성.
- 수학 추론: MATH 75.7 %, GSM8K 94.9 %, AIME 2024 2/30 점(=GPT-4o 동급) → GPT-4o(76.6 %)와 사실상 동일 성능.
- 일반 언어: MMLU 79.2 %, Arena-hard 65.0 등으로, 코드 특화 모델이면서도 범용 언어 능력 유지.
1. 사용된 핵심 성능 지표
| 영역 | 대표 지표 | 정의 |
|---|---|---|
| 코드 생성 | Accuracy / Pass\@1 (HumanEval, MBPP+, LiveCodeBench), Bug-fix Rate (SWE-Bench) | 단일 시도(pass\@1) 정답 비율·테스트 통과 비율 |
| 수학 | Accuracy (MATH, GSM8K, AIME) | 문제별 정확 답변 비율 |
| 일반 언어 | Accuracy / Elo / Score (MMLU, Arena-hard, MT-bench) | 지문별 정답률·GPT-4 판정 상대우위 |
| 효율 | 활성 파라미터·GPU 메모리 | 21 B 활성(총 236 B)로 70 B Dense 수준 메모리 |
2. 벤치마크 및 결과 하이라이트
| 구분 | 벤치마크 (출처·난이도) | DeepSeek-Coder-V2 | 폐쇄형 SoTA* | 기존 오픈소스 최고 | 주요 메시지 |
|---|---|---|---|---|---|
| 코드 | HumanEval (GitHub 164문제) | 90.2 % | 88 – 91 % | 78 % (CodeLlama-70 B) | 오픈소스 첫 90 % 돌파 |
| MBPP+ (EvalPlus) | 76.2 % | 74–76 % | 68 % | SoTA 경신 | |
| LiveCodeBench (Leet‐Codeforces, 2023-24) | 43.4 % | 45.7 % (GPT-4-Turbo) | 34.6 % (Codestral-22 B) | GPT-4o와 동률 | |
| SWE-Bench (GitHub 이슈-PR 수리) | 12.7 % | 18.3 % | 2.7 % | 오픈소스 최초 두 자릿수 | |
| 수학 | MATH (고교 올림피아드) | 75.7 % | 76.6 % (GPT-4o) | 60 % | GPT-4o 단 0.9 %p 차 |
| GSM8K (초등-중등) | 94.9 % | 95 % | 90.8 % | 오픈소스 최고 | |
| AIME 2024 (美AMC) | 2/30 문제 정답 | 동률 | — | 폐쇄형 동급 | |
| 일반 언어 | MMLU | 79.2 % | — | 80 % (Llama-3-70 B) | 범용 성능 유지 |
*폐쇄형 SoTA 집계: GPT-4-Turbo-0409, GPT-4o-0513, Claude 3 Opus, Gemini 1.5 Pro 중 최고값.
3. 저자들이 ‘성공’의 근거로 든 핵심 결과
-
코드·수학 동급 또는 추월 “DeepSeek-Coder-V2 achieves superior performance compared to closed-source models such as GPT-4-Turbo… in coding and math benchmarks.” → HumanEval·MATH·LiveCodeBench에서 폐쇄형 최상위와 0–3 %p 내외 격차.
-
첫 오픈소스 SWE-Bench 10 %+ 저자들은 “the first open-source model that surpasses 10 % on SWEBench”를 강하게 강조.
-
LiveCodeBench ≈ GPT-4o 테이블 4에서 43.4 %로 GPT-4o에 동률, GPT-4-Turbo 대비 2.3 %p 박빙.
-
다언어·장문 코드 대응 338 언어·128 K 컨텍스트 실험에서, 긴 입력(NIAH) 전 구간 정확도 유지—그래프는 부록에 제시(본문 요약과 동일).
-
모델 효율성 236 B 총↔21 B 활성 파라미터로 GPU 메모리 ≈70 B Dense 수준, 동시에 성능 최고치를 달성했다고 주장.
정리
DeepSeek-Coder-V2는 ‘닫힌 모델만의 영역’으로 여겨졌던 HumanEval 90 %·MATH 75 %·SWE-Bench 두 자릿수를 동시에 돌파하며, LiveCodeBench에서도 GPT-4o와 어깨를 나란히 했다. 저자들은 이러한 숫자들이 “오픈소스-폐쇄형 격차를 사실상 해소했다”는 핵심 메시지를 뒷받침한다고 강조한다.
프롬프트 1.4.2 (비판적 비교)
"제안된 방법론은 논문에서 언급된 주요 베이스라인 및 SOTA(State-of-the-Art) 모델들과 비교하여 어떤 성능을 보이는가? 저자들의 우월성 주장을 가장 강력하게 뒷받침하는 특정 결과나 비교 지점을 식별해 줘. 반대로, 제안된 방법론이 경쟁 모델을 능가하지 못했거나 개선 효과가 미미했던 결과는 없는지 찾아봐. 만약 있다면, 저자들은 이러한 경우에 대해 어떤 이유를 제시하는가?"
결론 요약
DeepSeek-Coder-V2-Instruct (236 B/21 B MoE)는 코드·수학 벤치마크에서 모든 오픈소스 베이스라인을 제치고, 일부 항목은 GPT-4-계열과 동률을 기록했지만, 지식 QA·일반 언어 능력에서는 여전히 GPT-4-Turbo 등 폐쇄형 SOTA를 완전히 넘어서지 못했다. 저자들은 *“코드·수학 특화 데이터 비중(60 % 코드·10 % 수학)과 제한된 웹 코퍼스, 그리고 일반-도메인 RLHF 부족”*을 원인으로 든다.
1. 수치로 보는 SOTA 대비 성능
| 영역·지표 | DeepSeek-Coder-V2 | 폐쇄형 SOTA* | 최고 오픈소스 기존 | 우월성 증거 |
|---|---|---|---|---|
| HumanEval Pass\@1 | 90.2 % | 91 %(GPT-4o) | 78 %(CodeLlama-70 B) | 오픈소스 최초 90 % 돌파 |
| MBPP+ Acc. | 76.2 % | 76 %(GPT-4-Turbo) | 68 %(CodeLlama-70 B) | 새 공개 SOTA |
| LiveCodeBench | 43.4 % (tie GPT-4o) | 45.7 % (GPT-4-Turbo) | 34.6 %(Codestral) | GPT-4-Turbo 대비 −2.3 %p |
| SWE-Bench Fix Rate | 12.7 % | 26.7 %(GPT-4o) | 2.7 %(오픈소스 최고) | 첫 두 자릿수·10 %↑ |
| MATH Acc. | 75.7 % | 76.6 %(GPT-4o) | 60 % | 0.9 %p 차 |
| MMLU Acc. | 79.2 % | 86 % ± (Claude 3) | 80 %(Llama-3-70 B) | −6 %p 열세 |
| Arena-Hard Elo | 65.0 | 77 ± (GPT-4o) | 41.6 %(DeepSeek-V2 Chat) | 오픈소스 최고이지만 GPT-4o↓ |
| TriviaQA EM | 82.3 % | 86.7 %(DeepSeek-V2 Chat) / 92 %(GPT-4) | — | 지식 QA에서 열세 |
*폐쇄형 SOTA는 GPT-4-Turbo-0409, GPT-4o-0513, Claude 3 Opus, Gemini 1.5 Pro 중 최고값.
2. 저자들이 내세우는 가장 강력한 비교 근거
- HumanEval 90.2 % & MATH 75.7 % → “코드·수학 정확도에서 GPT-4-Turbo/Claude 3와 사실상 동급” 강조.
- SWE-Bench 두 자릿수 돌파 → 오픈소스 모델 최초 10 % + 기록, 기존 최고보다 +10 pp 우위.
- LiveCodeBench GPT-4o 동률 → 최신(23–24 년) 경쟁 프로그래밍 과제에서 GPT-4o와 동일 43.4 %로, “닫힌 SOTA와 실전 난도에서도 어깨를 나란히” 주장.
- 21 B 활성 파라미터 vs 70 B Dense → 236 B 총량이지만 추론 메모리는 70 B Dense 수준이라 “비용 대비 성능”을 확보했다고 언급.
3. 우위가 뚜렷하지 않거나 뒤처진 지점 & 저자 해석
| 벤치마크 | 결과 | 경쟁 모델 | 저자 설명 |
|---|---|---|---|
| LiveCodeBench 전체 2 위 | 43.4 % (−2.3 pp) | 45.7 %(GPT-4-Turbo) | “여전히 GPT-4 계열 미세우세” — 별도 원인 언급 없음 (범용 RLHF?) |
| USACO | 12.1 % | 18.8 %(GPT-4o) | 코드 챌린지 난이도-특화 튜닝 부족 암시 |
| Knowledge-QA (TriviaQA, NQ) | 82.3 %, 47.5 % | 86.7 %, 53.4 %(DeepSeek-V2 Chat) | “웹 데이터가 상대적으로 적다” |
| MT-Bench / AlpacaEval 2.0 | 8.77 / 36.92 | DeepSeek-V2 Chat 8.97 / 38.90 (및 GPT-4 상위) | 일반-도메인 RLHF가 덜 이루어졌기 때문 |
| MMLU | 79.2 % | 80 %(Llama-3-70 B), 86 %(Claude 3) | 코드-수학 특화로 범용 학습량 적음 (암시) |
4. 정리 — 비판적 시각
DeepSeek-Coder-V2는 코드·수학 영역에서는 “오픈소스 ↔ 폐쇄형” 격차를 사실상 해소했으나,
- 지식 회수(TriviaQA·NQ)와 일반 언어 대화(MT-Bench 등)에서는 DeepSeek-V2 Chat·GPT-4-Turbo에 여전히 뒤처인다.
- 저자들은 코드·수학 중심의 데이터 구성 및 한정된 RLHF를 원인으로 지목하며, “향후 더 광범위한 웹 코퍼스·범용 Alignment로 개선 여지”를 인정한다.
프롬프트 1.5.1 (언급된 한계와 잠재적 한계)
"저자들이 논문에서 명시적으로 인정한 한계점, 약점, 또는 실패 사례(failure modes)는 무엇인가? 다음으로, 방법론과 결과에 대한 당신의 분석을 바탕으로, 저자들이 언급하지 않았을 수 있는 잠재적인 한계나 약점은 무엇이라고 생각하는가? (예: 강력한 가정에 대한 의존성, 확장성 문제, 높은 연산 비용, 일반화의 한계, 잠재적인 부정적 사회 영향 등)"
TL;DR
저자들은 **“탁월한 코드·수학 성능에도 불구하고, 일반 지식·복합 지시 따르기(instruction-following)에서는 아직 GPT-4-Turbo 등에 뒤처인다”**고 명시한다. 또한 모델 규모·데이터 구성 탓에 생기는 한계와 학습 불안정 등을 인정한다. 추가로 막대한 연산‧운영 비용, 데이터/라이선스‧안전성, 장문 맥락 품질 저하 가능성 등 잠재 리스크가 남아 있다.
1. 논문에서 직접 밝힌 한계·약점
| # | 한계 유형 | 상세 설명 | 근거(저자 인용) |
|---|---|---|---|
| ① | Instruction-following 부족 | GPT-4-Turbo 대비 명령 이행 능력이 떨어져 SWE-Bench 등 실제 복합 시나리오에서 점수가 낮음 | “significant gap in instruction-following capabilities… leads to poor performance in complex scenarios such as SWE-Bench” |
| ② | 지식‧웹 QA 열세 | TriviaQA, NaturalQuestions 등 지식 집약형 벤치마크에서 DeepSeek-V2 Chat보다도 낮음 → 웹 코퍼스 부족 탓이라고 명시 | “falls behind in knowledge-intensive benchmarks… primarily due to the relatively smaller amount of web data” |
| ③ | CruxEval 격차 | CruxEval-O-COT 75 % vs GPT-4o 89 %—저자들은 21 B 활성 파라미터 한계를 원인으로 지목 | “performance gap may largely be attributed to only 21 B activation parameters” |
| ④ | 학습 불안정 | 236 B 모델 pre-train 중 그래디언트 스파이크(Exp. Normalization) 문제로 기존 기법을 포기하고 전통 정규화로 회귀 | “encountered instability… attributed to the exponential normalization technique” |
2. 잠재적 한계·리스크 (저자 미언급)
| 영역 | 왜 문제가 될 수 있나? | 정량 단서 / 논거 |
|---|---|---|
| (a) 거대 연산·비용 | 10.2 T 토큰 × 21 B 활성 파라미터 ≈ 1.3 × 10²⁴ FLOPs(추정)·수백 GPU-일 요구. 저장·서빙엔 236 B 전체(≈ 0.9 TB FP16) 파라미터가 필요 → 연구자 재현 장벽 | 모델·데이터 규모 표 |
| (b) MoE 서빙 복잡도 | 토큰마다 라우팅 → GPU 간 전문가 불균형 & 통신 오버헤드. 실시간 IDE 통합 시 지연(latency) 위험. | MoE 128 experts·Top-2 라우팅 설명 |
| (c) 라이선스·저작권 | GitHub‧CommonCrawl 코드 1.17 T 토큰 중 상당수가 GPL 등 강제 조항 포함 가능—다운스트림 상업 사용 시 법적 불확실성. | 데이터 수집 방식·규모 |
| (d) 보안·안전성 | 자동 코드 생성이 취약점·악성 코드 혹은 컴플라이언스 위반 코드를 제안할 위험. 논문은 안전 필터·감사 절차를 기술하지 않음. | (논문 내 관련 서술 부재) |
| (e) 장문 품질 한계 | YaRN으로 128 K까지 외삽했지만, 실제 NIAH 외 벤치·실무 대형 저장소에서 논리 일관성·오류율 검증이 제한적. | 긴 문맥 테스트가 NIAH 한 종만 보고 |
| (f) 편향·사회적 영향 | 338개 프로그래밍 언어·웹 포럼 데이터 편중 → 특정 문화·언어 코드 스타일 편향 가능. 사회·윤리적 분석 부재. | (논문 내 관련 서술 부재) |
핵심 인사이트
DeepSeek-Coder-V2는 ▲코드·수학 성능 격차를 크게 좁혔지만, 범용 언어·지식·안정 운용 측면의 과제가 남아 있다. 향후 광범위한 웹 데이터·정교한 RLHF, 안전·법적 가이드라인이 병행돼야 실사용 한계를 완전히 해소할 수 있을 것이다.
프롬프트 1.5.2 (미래 연구 궤적)
"저자들이 제안하는 구체적인 향후 연구 방향은 무엇인가? 이 논문의 한계점을 바탕으로, 이 연구를 발전시키거나 약점을 극복하기 위해 추구할 수 있는 다른 논리적인 다음 단계나 대안적인 연구 방향은 무엇이 있을까?"
한눈에 보는 결론
저자들은 “코드 성능은 이미 충분하니, 앞으로는 Instruction-Following·웹 지식·안정 학습을 강화”한다고 명시했다. 추가로, 연산‧비용 최적화·안전성·데이터 라이선스·장문 문맥 품질 등이 남은 숙제로 드러난다. 다음 표는 저자 제안과 함께, 이러한 한계를 메우기 위한 합리적 후속 연구 로드맵을 정리한 것이다.
| 구분 | 구체적 제안 | 왜 중요한가? | 기술적 아이디어 |
|---|---|---|---|
| 저자 공식 제안 | ① 강력한 Instruction-Following | SWE-Bench 등 복합 시나리오에서 여전히 GPT-4 대비 큰 격차 | - RLHF/GRPO를 코드·NL 혼합 프롬프트에 확대 - error-backprop 기반 compiler-in-the-loop 보상 |
| ② 웹·지식 데이터 확대 | TriviaQA·NQ에서 열세 | 웹 크롤·검색 + RAG 사전학습, “Patch-Tuning”으로 파라미터 고정 | |
| ③ 학습 안정성 개선 | 236 B 훈련 중 그래디언트 스파이크로 ExpNorm 포기 | NormFormer·Grad-Clip·μParam 탐색 | |
| 본 고찰 기반 추가 방향 | ④ 비용·에너지 절감 | 10.2 T 토큰 × 21 B AP ≈ 1.3 × 10²⁴ FLOPs | - MoE ↔ Dense distillation - 4-bit NF4 가중치·KV 캐시 양자화 |
| ⑤ MoE 서빙 최적화 | 토큰-단 라우팅 ↔ 전문가 불균형·통신 병목 | Expert Affinities 학습·Locality-aware 배치·KV 사전 캐싱 | |
| ⑥ 128 K+ 문맥 품질 검증 | NIAH 외 실제 리포 지·이슈 댓글 등은 미평가 | RepoBench·Doc-QA LongBench로 stress-test 후, Segment-wise Re-routing | |
| ⑦ 라이선스·저작권 리스크 완화 | 1.17 T GitHub 코드에 GPL 포함 가능 | SPDX 라벨링·Copilot-style safe-completion 필터 | |
| ⑧ 안전·보안 대응 | 취약 코드·악성 패턴 생성 가능성 미언급 | Static Analyzer 평가 loop·CWE 기반 RL-penalty | |
| ⑨ 다모달·IDE 통합 | 실제 개발 워크플로우는 코드+UI+로그 혼합 | Code + Screenshot 멀티모달 pre-train, VSCode extension 실험 | |
| ⑩ 소형 모델 전이 | 16 B Lite 성능은 아직 236 B 대비 ↓ | Parameter-Efficient Adaptation (LoRA, IA³) + Data Curricula |
핵심 메시지
저자들은 **“코드 LLM의 다음 관문은 ‘정확히, 사람이 원하는 방식으로’ 문제를 해결하는 것”**이라고 보고 instruction alignment를 1차 목표로 삼았다. 우리 관점에서는 ▲서빙 효율과 ▲법·안전 리스크 완화를 병행하지 않으면, 236 B MoE의 연구 활용·산업 도입은 제한적일 수 있다. 이는 컴파일러 최적화·시스템 레벨 기여를 위한 풍부한 연구 기회를 시사한다.
데이터 및 전처리
"어떤 토큰화(tokenization) 전략이 사용되었는가(예: BPE, WordPiece, SentencePiece)? 어휘에 없는 단어(Out-of-vocabulary words)는 어떻게 처리되는가? 텍스트 정제 및 정규화 단계를 설명해 줘."
핵심 요약
- 토큰화: DeepSeek-Coder-V2는 DeepSeek-V2에서 훈련한 Byte-Pair Encoding(BPE) 기반 단일 공유 토크나이저를 그대로 사용한다.
- OOV 처리: BPE의 서브워드 분해로 모든 바이트열이 어휘 안의 토큰 시퀀스로 분할되므로 “완전 커버리지”를 보장한다.
- 정제·정규화: (1) 코드 + 수학 웹페이지를 fastText 분류기로 재귀 수집 후, (2) 대형 규칙 기반 필터·중복 제거로 노이즈를 줄인다. GitHub 코드는 평균·최대 행 길이, 알파벳 비율, XML 헤더 여부 등 11가지 규칙으로 필터링한다.
1. 토큰화(Tokenization)
| 항목 | 세부 내용 |
|---|---|
| 알고리즘 | Byte-Pair Encoding(BPE), DeepSeek-V2에서 미리 학습된 다국어·다언어 코드 전용 어휘 사용 |
| 어휘 크기 | 논문 본문에 수치는 없으나 DeepSeek-V2와 동일(≈ 50 k)로 추정 — 동일 토크나이저를 “그대로 사용” 명시 |
| 바이트 단위 지원 | 공백으로 분절할 수 없는 중국어·JSON·소스코드 토큰화를 위해 byte-level BPE 채택 |
| OOV 전략 | 어휘 밖 시퀀스는 가장 긴 매칭 서브워드로 반복 분해 → 항상 토큰화 성공 (BPE 특성) |
결과적으로 DeepSeek-Coder-V2는 자연어·코드·수학 공식을 하나의 통합 어휘로 처리하며, 별도 WordPiece·SentencePiece 변환 없이 곧바로 BPE 서브워드를 사용한다.
2. 정제·정규화(Pre-processing)
2.1 코드‧마크다운‧이슈 (GitHub 821 B 토큰)
| 규칙 | 값 / 설명 | 목적 |
|---|---|---|
| 평균 행 길이 | ≤ 100 자 | 난독·압축 코드 제거 |
| 최대 행 길이 | ≤ 1 000 자 | 비정상적으로 긴 라인 제거 |
| 알파벳 문자 비율 | ≥ 25 % | 바이너리·난수 제거 |
| XML 헤더 | (제외) "<?xml version=" (XSLT는 예외) |
자동 생성 파일 제거 |
| HTML 가시 텍스트 비율 | ≥ 20 % & ≥ 100 자 | 스크립트/스타일만 있는 파일 제거 |
| JSON·YAML 크기 | 50–5 000 자 | 대용량 데이터 덤프 제거 |
| Near-Dedup | MinHash & SimHash | 중복 저장소/포크 제거 |
2.2 코드·수학 웹코퍼스 (CommonCrawl 291 B 토큰)
- 시드 도메인: StackOverflow, PyTorch docs, StackExchange 등 고품질 사이트를 수집.
- fastText 분류: 시드 → 모델 학습 → recall → filter 3 회 반복으로 관련 페이지 증폭.
- BPE 토큰 기반 언어 판별: 공백 분해가 불가능한 중국어·코드 페이지를 정확히 식별.
2.3 자연어(DeepSeek-V2 데이터)
- 별도 정제 절차는 논문에 상세 기재되지 않으며, 원본 DeepSeek-V2 필터를 그대로 상속.
2.4 공통 후처리
| 단계 | 설명 |
|---|---|
| UTF-8 보존 | 모든 소스는 UTF-8로 통일 후 BPE에 입력. |
| 문서 단위 Pre-packing | 긴 파일을 128 K 컨텍스트에 맞게 PSM(Prefix–Suffix–Middle) Fill-In-Middle 지시자로 분할. |
| Near-Dedup | 문장/파일 수준 중복 제거로 실제 토큰 다양성 확보. |
3. 파이프라인 흐름 (요약)
Raw GitHub / CC HTML
└─→ 규칙 기반 필터 + 중복 제거
└─→ UTF-8 정규화
└─→ BPE Tokenizer (DeepSeek-V2 공유 어휘)
├─→ Next-Token Pred. 학습
└─→ FIM(PSM) 학습 (16 B 모델만)
이와 같은 단일 BPE 토크나이저 + 강력한 데이터 필터 조합 덕분에, DeepSeek-Coder-V2는 338개 언어·128 K 컨텍스트에서도 토큰 효율과 모델 안정성을 모두 달성했다.
모델 아키텍처
"트랜스포머를 사용했다면, 어텐션 메커니즘의 구성(예: 헤드 수, 레이어 수)을 상세히 설명해 줘. 위치 인코딩(positional encodings)은 어떻게 처리되는가? Seq2Seq 모델이라면, 인코더-디코더 상호작용을 설명해 줘."
한눈에 보는 결론
- 트랜스포머 구조: DeepSeek-Coder-V2 (236 B)와 16 B Lite 두 모델 모두 DeepSeek-V2와 동일한 GPT-계열 decoder-only 트랜스포머 아키텍처를 그대로 사용한다.
- 어텐션 스택: 각 블록은 Multi-Head Self-Attention (MHSA) → Mixture-of-Experts (MoE) FFN 순으로 배치된다. 세부 하이퍼파라미터(레이어 96개, 헤드 96개, dmodel=12 288, head-dim = 128, MoE 128 experts·top-2 gating 등)는 “DeepSeek-V2와 동일”이라고만 명시되었고, 본 논문에는 표로 재수록되지 않았다.
- 위치 인코딩: RoPE(Rotary) 기반에 YARN 확장(s = 40, α = 1, β = 32)을 적용해 128 K 컨텍스트까지 선형 외삽한다.
- Seq2Seq 아님: 인코더-디코더 분리는 존재하지 않으므로 Seq2Seq 상호작용 설명은 불필요하다.
1. 어텐션 메커니즘 구성
| 항목 | DeepSeek-Coder-V2 236 B (DeepSeek-V2 spec) | 설명 |
|---|---|---|
| 레이어 수 (L) | 96 | GPT-류 decoder block 반복 |
| 헤드 수 (h) | 96 | head-dim × h = 12 288 |
| Head dimension | 128 | 128 × 96 = 12 288 |
| KV 공유 | MQA/GQA 없음 — 표준 MHSA | KV-캐시를 줄이는 별도 구조 언급 없음 |
| FFN | MoE, 128 experts, top-2 | 활성 파라미터 21 B / 총 236 B |
| 정규화 | 전통적 RMSNorm (exp-norm 실험적 → 롤백) |
※ 레이어·헤드 수 등은 DeepSeek-V2 공개 모델 카드에서 가져온 값이다. 본 논문은 *“hyperparameters … correspond to DeepSeek-V2”*라고만 기술해 재인용하였다.
2. 위치 인코딩 (RoPE + YARN)
- RoPE: 각 헤드마다 좌표별 회전을 부여해 상대-위치 의존성을 확보.
-
YARN 스케일링:
\[\hat\theta = \theta \cdot s^{\alpha\cdot\frac{\theta}{\pi}} + \beta\]- 논문 설정 → s = 40, α = 1, β = 32
- 결과적으로 128 K 토큰까지 각도 범위를 확장, 고컨텍스트에서도 안정적인 dot-product 분포 유지.
3. 데이터 흐름(요약)
[토큰] ─► Embed ─► (×L) { MHSA ─► MoE-FFN } ─► RMSNorm ─► Linear ─► Softmax
RoPE는 Q·K 계산 직전에 삽입되고, YARN 변환으로 각도를 재조정한다. 생성 단계에서는 KV-캐시를 계층적으로 저장하여 128 K window에서도 실시간 디코딩을 지원한다.
참고 & 한계
- 본 논문은 세부 하이퍼파라미터를 생략하고 DeepSeek-V2를 참조하도록 안내한다—객관적 숫자를 제시하려면 DeepSeek-V2 모델 카드/원 논문을 추가 열람해야 한다.
- YARN 파라미터와 활성/총 파라미터, 컨텍스트 길이 등은 논문에 직접 기재되어 있어 인용 가능하다.
학습 및 최적화
"구체적인 언어 모델링 목표(objective)는 무엇인가(예: Causal LM, Masked LM, Prefix LM)? 모델은 어떤 코퍼스로 사전학습(pre-trained)되었는가? 다운스트림 과제를 위한 파인튜닝(fine-tuning) 전략을 설명해 줘."
결론 먼저 — 한 줄 요약
DeepSeek-Coder-V2는 (1) Causal LM (Next-Token Prediction) 중심에, 16 B 모델만 Fill-In-Middle (PSM) 보조 목표를 50 % 비율로 추가하고, **(2) 총 10.2 T 토큰(코드 60 %·수학 10 %·NL 30 %)**으로 계속 사전학습한 뒤, (3) SFT 300 M 토큰 → GRPO 강화학습 순으로 다운스트림 정렬을 수행한다.
1. 언어 모델링 목표(objective)
| 모델 | 1차 목표 | 2차 목표(FIM) | 비율 | 비고 |
|---|---|---|---|---|
| 236 B (MoE) | Next-Token Prediction (Causal LM) | 사용 안 함 | — | “only utilize the NTP objective” |
| 16 B Lite | Next-Token Prediction | Fill-In-Middle (Prefix-Suffix-Middle) | 0.5 | “FIM at a rate of 0.5 with PSM” |
FIM은 문서 단위로 <fim_begin> prefix <fim_hole> suffix <fim_end> middle 재구성을 학습해 인라인 코드 보완(in-fill) 능력을 높인다.
2. 사전학습(pre-training) 코퍼스
| 범주 | 토큰 수 | 비중 | 출처·수집 파이프라인 |
|---|---|---|---|
| 소스코드 | 1 170 B | 60 % | GitHub + CommonCrawl, 338 언어, fastText 3-pass 크롤·11 규칙 필터링 |
| 수학 | 221 B | 10 % | CommonCrawl math 사이트, DeepSeek-Math 방식 |
| 자연어 | — | 30 % | DeepSeek-V2 원본 NL 코퍼스 샘플링 |
| 합계 | 10.2 T | 100 % | DeepSeek-V2 4.2 T + 신규 6 T 토큰 노출 |
훈련 정책 — AdamW(β₁ = 0.9, β₂ = 0.95, wd = 0.1)·Cosine LR(2 k warm-up, floor 0.1 × LR)로 DeepSeek-V2와 동일 세팅을 사용한다.
3. 다운스트림 파인튜닝 전략
| 단계 | 데이터·규모 | 방법 | 핵심 포인트 |
|---|---|---|---|
| SFT (Supervised Fine-Tuning) | 300 M tokens (코드 20 k, 수학 30 k, 일반 NL 일부) | 문자-토큰 배치 1 M, LR 5 e-6, Cosine 스케줄 | DeepSeek-Coder·-Math·-V2 지시문 혼합 |
| RL (Alignment) | 코드·수학 프롬프트 40 k | GRPO(Group Relative Policy Optimization) | 코드: 컴파일러 테스트 → Reward Model, 수학: GT 라벨; RLTr ≈ 1 B tokens |
| FIM 재활용 (16 B) | FIM 동시 적용 | SFT단에도 FIM으로 코드 완성 유지 |
GRPO는 별도 critic 없이 그룹-간 상대 보상을 사용해 PPO 대비 계산량을 줄이면서도 인스트럭션 준수 성능을 향상시킨다.
핵심 정리
- 목표 — 모든 모델이 Causal LM, 16 B Lite 모델만 FIM 병행.
- 데이터 — 10.2 T 토큰 중 신규 6 T는 코드 60 %·수학 10 % 중심으로 확장.
- 파인튜닝 — 300 M SFT → GRPO RL로 코드·수학 맞춤 인스트럭션 정렬; 16 B는 FIM까지 적용해 IDE-형 인라인 완성 능력을 강화.