DeepSeek를 살펴보려면 좀 길다.
1. DeepSeek LLM (https://arxiv.org/pdf/2401.02954)
2. DeepSeek MOE (https://arxiv.org/pdf/2401.06066)
3. DeepSeek-V2 (https://arxiv.org/pdf/2405.04434)
4. DeepSeek-V3 (https://github.com/deepseek-ai/DeepSeek-V3/blob/main/DeepSeek_V3.pdf)
5. DeepSeek-R1 (https://github.com/deepseek-ai/DeepSeek-R1/blob/main/DeepSeek_R1.pdf)
전부 나름의 Contribution을 주장하고 있는데 ...
오늘 살펴볼만한 것은 R1의 방법론이기 때문에, 앞 부분은 나중에 살펴보는 것으로 하자.
대충만 살펴보면
결국 DeepSeek는 Transformer의 구조를 띄고 있기 때문에
핵심 Architecture는 Transformer Block 구조를 변화시키는 것에 불과하다.
이러한 변천사는 상기된 연구들을 하나하나 따라가면 조금씩 변화하고 있기 때문에
한 번에 V3를 읽으면, '우리가 앞선 V2에서 증명한 구조를 그대로 ~~' 같은 소리만 계속 보게 된다.
V3 Transformer Block의 핵심은, 앞선 두 연구에서 이미 나타난다.
먼저 공유 전문가(Shared Expert)의 구조이다.
결국 학습된 데이터의 특정 패턴은 구조적으로 동일하게 사용될 가능성이 있다.
이를 효과적으로 받아들일 수 있는 공유 전문가를 둔 구조가 있다면
전체적인 중복성이 감소하고 Parameter를 효과적으로 사용할 수 있다는 것이 저자들의 설명이다.
다음으로는 MLA다
이런 시도의 핵심은 심각한 Computation Cost의 효과적인 대처방안로부터 시작한다.
실제로 Inference 과정에서 Output_HiddenState인 u_t의 값을 구하기 위해서는
모든 Attention Head에서 계산된 K, V 값이 필요하다.
저자들은 이 과정이 개별 토큰 당 2 * n_h * d_h * l 개의 elements들을 Cache해야 한다고 이야기 하며
이것이 상당한 Bottleneck을 유발한다고 주장하고 있다.
실제로 Head의 개수와 모델의 Dimension이 증가하면, 중간 과정에서 산출되는 엄청난 양의 Q, K, V 값을
저장하고 있어야 하는 것은 맞다.
(트랜스포머의 연산은 결국, Input Hidden State의 Q, K, V Matrix와의 연산을 통해 해당 값들을 산출하는 구조이니 ..)
여기서 저자들은 한 가지 아이디어를 통해 이 문제를 해결하고자 하는데 ...
어차피 Matrix 계산 자체의 속도가 문제가 되는 것이 아니라, 상당한 Cache Memory가 문제를 야기하는 것이라면
이 중간 산출물인 Q, K, V를 어떠한 Latent Space로 적재시키면 된다는 것이다.
비슷한 아이디어가 이전에 리뷰한 Mamba에서도 조금 비슷하게 나타났던 것 같다.
결국 HiPPO 라는 Framwork또한 어떤 미분방정식의 과정을 Latency한 공간으로 Mapping하는 기술로 볼 수 있으니 말이다.
아무튼 핵심은 결국 어떠한 Down-Projection Matrix를 통해, Q, K, V의 값을 압축하여 저장하고
이를 사용해서 Attention 연산에 사용한다는 것이다.
이 밖에도 아래와 같은 기술들이 적용되었다고 한다.
- DeepSeekMoE with Auxiliary-Loss-Free Load Balancing (불균형 전문가 할당에 의한 붕괴 방지)
- Complementary Sequence-Wise Auxiliary Loss (Loss-Free 로드 밸런싱에 의한 문제 방지를 위한 Loss)
- Node-Limited Routing (커뮤니케이션 코스트를 제한하기위한 조치)
- Multi-Token Prediction
대충 살펴봤으니, 이제 본론으로 넘어가 R1이 무슨 이상한 구조를 채택하고 있는지 살펴보자
블로깅을 하며 리뷰하고자 결심한 결정적인 이유인데
DeepSeek-R1의 논문에 이상한 구문이 하나 있다.
RL 영역에서, 완전 자동화된 학습을 진행시키는 것은 딱히 놀라운 일은 아니지만 ...
실제로 RL에서 "스스로" 학습을 진행하기 위해서는 적당한 Policy의 설정이 굉장히 중요하다.
강화학습이란 결국
주어진 환경(environment)에서 에이전트(Agent)가 최대 보상(Reward)를 받을 수 있는 활동(Action)을 할 수 있도록 Policy를 학습하는 것이기 때문이다.
그렇다보니, 이것을 정확하게 설정하는 것이 굉장히 중요한 영역인 분야인데 ...
이것이 NLP의 영역에서도 가능하다는 것은 상당히 놀라운 발견인 것이다.
그러면 도대체 어떤 방식으로 이것을 구현해 놨을까?
한 번 이렇게 생각해보자.
LLM에 있어서 강화학습이란 ...
주어진 환경(Prompt)에서 생성 모델(Model)이 최대 보상(Reward)을 받을 수 있는 생성(Generated Text)을 하는 Policy(무엇을 생성할 것인지)를 학습하는 것이다.
즉, Reward만 정의할 수 있다면!
이러한 Reward를 최대화 하는 생성 전략(Policy)를 만족할 수 있도록 모델이 Tuning되면 된다는 것이다.
그러면 도대체 생성 전략은 무엇이고, Reward는 무엇이 될 것인가?
난해해 보이는 GRPO라는 Optimization 방법이다.
그러나 단순하게 보면, 학습을 통해 변화시키고 싶은 것은 결국
Policy 값인 파이를 학습시키는 과정인 것이다.
이는 생각보다 단순한 과정인데 .. 하나하나 살펴보면
여기서 D_KL의 경우는 정책의 쿨백-라이블리 발산 패널티로, 두 확률분포의 차이를 의미한다.
그냥 쉽게 둘이 너무 많이 다르면, 그 만큼 패널티를 주겠다는 것이다.
(즉, 변화가 너무 급격하게 나타나지 않도록 보정하는 항이다.)
다음으로 A_i의 경우는, 수식을 보면 알겠지만 Z-Score의 일종이다.
즉, 특정 Output i의 상대적인 Reward 점수를 의미한다고 볼 수 있겠다.
해당 수식은, 개별 정책에서 특정한 Sample Output의 등장 확률을 기반으로 한다.
(현재 정책 / 이전 정책) * (해당 output의 상대적 Reward Score)가 커지는 것이 목표이므로
업데이트 되는 정책은, Reward가 높은 Output의 샘플링 확률이 증가되도록 학습되는 것이다.
즉 업데이트 된 모델은, 이렇게 업데이트 된 정책과 유사한 방식으로 작동하는 모델이 된다는 것이다!
그러면 해당 정책 업데이트 과정의 핵심 Value인 Reward는 도대체 무엇일까?
조금 재미없게도, 이러한 Reward Model은 단순한 Rule-Based의 Reward 모델이다.
그것도 일종의 Correctness를 검사할 수 있는 Math Problems 혹은 Code Problems을 이용했다고 한다.
이에 더해, 추론 과정인 경우 <think>라는 Special Value를 출력하는지의 여부를 통해 Reward로 사용하였다고 한다.
조금 재미없는 방식의 Reward Model이지만
실제로 연구에서는 이러한 방식을 통해 R1-Zero의 성능이 상당히 상승하였음을 보고하고 있다.
실제로 이런 방식으로 몇 가지 신기한 현상이 발견되었다고 한다.
- AIME 2024 Benchmark에서 상당한 성능의 향상 (15.6% -> 71.0%)
- "Aha Moment"의 등장
여기서 더욱 발전한 형태가 R1 모델인데
해당 모델은 기존 R1-Zero를 개션하기 위해
고품질의 CoT 데이터를 통해, 선행 학습을 조금 진행한 뒤, 위와 같은 방식을 적용한 모델이라고 한다.
'A.I.(인공지능) & M.L.(머신러닝) > LLM' 카테고리의 다른 글
Embedding 모델과 Sentence-Transformer Training (0) | 2025.02.21 |
---|---|
CUDA를 넘어: DeepSeek (0) | 2025.02.05 |
Custom Model Training을 위한 Hugging Face Trainer 구조 파악하기 (0) | 2025.01.22 |
DeepSeek-V3 (0) | 2025.01.14 |
DeBERTa: Decoding-enhanced BERT with Disentangled Attention 느낌만 맛보기 (0) | 2024.12.24 |