DeepSeek LLM

세미나 발제를 위한 자료로 작성했지만 공개할만한 가치가 있을 것 같아 공유합니다.

DeepSeek은 High-Flyer라는 중국 헤지 펀드 산하의 AI 기업이다. (https://en.wikipedia.org/wiki/High-Flyer_(company)) Qwen의 알리바바나 ERNIE의 바이두만큼 지명도는 없긴 하지만 A100을 최소 1만 대, 그리고 아마도 적지 않은 수의 H800을 갖고 있는 회사이기도 하다.

DeepSeek이 개발한 LLM은 성능 대비 저렴한 비용(1M 토큰 당 입력 $0.14, 출력 $0.28)으로 중국 내 LLM들 사이에 가격 경쟁을 촉발했다는 평이 있고, 코드 모델 같은 경우 이런저런 코딩 벤치마크에서 최상위권에 위치하고 있다. (https://aider.chat/docs/leaderboards/, https://bigcode-bench.github.io/)

DeepSeek이 흥미로운 이유는 굉장히 빠른 속도로 최고 수준의 LLM을 개발해냈다는 것과 그 발전 과정을 비교적 상세한 테크니컬 리포트로 공개하고 있다는 것에 있다. 이 리포트들을 좇아가다 보면 LLM을 어떤 식으로 개발하고 발전시켜 나가야 하는지에 대한 단서를 포착할 수 있다. 이는 이전에 LLM을 개발한 전적이 없는 회사가 어떻게 경쟁력 있는 모델을 개발하는데 까지 나아갈 수 있었는가에 대한 힌트가 될 것이다. (물론 구성원들은 이미 많은 경험을 갖고 있었을 수도 있긴 하다.)

따라서 DeepSeek의 리포트들을 정리하면서 그들이 어떤 개발 과정을 거쳤는지에 대해 생각해보기로 했다. LLM 프리트레이닝만을 다루도록 할 것이다. 또한 필요하다면 다른 LLM들에 대한 정보도 결합하려고 한다. 어차피 디테일을 모두 포착하려면 직접 점검하고 읽어야 할 것이기 때문에 중요한 흐름과 아이디어만 정리하기로 한다. 그것만으로도 써야할 양이 적지는 않을 것이다.

DeepSeek LLM

7B/67B 2T 학습 모델. 성능적으로는 Llama 2 7B/70B와 차이가 아주 크게 두드러지지는 않는다. 다만 수학과 코딩 벤치마크에서 강점이 있긴 하다.

데이터

데이터 측면에서는 Global Deduplication이라는 지금도 논란이 많은 방법을 들고 왔다. 웹 텍스트의 주요 소스인 Common Crawl은 기간으로 구분된 100개 가량의 덤프로 구성되어 있는데 이전에는 각 덤프 내에서만 Deduplication을 하는 접근이 많았다. 그러나 DeepSeek LLM은 이 덤프를 하나로 합쳐 Deduplication을 한다면 중복 문서를 훨씬 더 줄일 수 있다는 이야기를 한다.

이 방법이 효과적일까? 이후 나온 Common Crawl 전처리 결과들에서는 좋은 결과가 나오지 않았다. (https://arxiv.org/abs/2406.17557, https://arxiv.org/abs/2406.11794) DeepSeek에서도 정확히 어떤 세팅으로 Deduplication을 했는지 분명하지 않고, 이후 데이터의 양을 증가시키면서 방식을 바꿨을 수도 있다.

이 부분에서는 FineWeb에서 언급하는 것처럼 공격적인 Deduplication이 상대적으로 고가치 문서의 비율을 낮출 수 있다는 것, Duplicate라고 하더라도 시간적으로 퀄리티가 변화한다는 점에 대해 생각해볼 필요가 있겠다. (https://arxiv.org/abs/2407.06380) 일단 Global Deduplication을 사용하지 않는 쪽이 더 나은 결과가 나오고 있지만 Global Deduplication이 적용되지 않는 경우 학습량이 증가할수록 Duplicate의 비율이 증가한다는 점을 고려할 필요가 있을 것이다. (반대로 Global Deduplication을 수행할 경우 남는 데이터의 양이 상당히 적어진다는 점도.)

추가적으로 Instruction 데이터를 프리트레이닝에 추가하는 전략에 대한 분석이 있다. 이는 중국 쪽의 LLM에서 자주 채택된다고 알려진 방법이다. 이에 대해서 벤치마크 스코어를 상승시키는 것은 사실이지만 실질적으로 능력을 향상시키는 것은 아닌 것 같다는 주장을 한다. (정확히는 능력을 향상시킬 정도가 되기에는 양이 부족한 것 같다는 평가.) 직접적은 데이터셋 오염이 아니라도 Multiple Choice QA 같은 특정한 벤치마크 포맷에 익숙해지는 효과로 스코어가 상승하는 현상에 대해서는 생각해볼만 하다. (https://arxiv.org/abs/2407.07890)

학습 전략

Learning Rate 스케줄러로는 ImageNet 시절의 Multi Step 스케줄러를 사용했다. 이는 소위 Infinite 스케줄러의 일종이다. (https://arxiv.org/abs/2106.04560) Cosine 스케줄러에 대해서 최종 성능은 비슷하면서 중간 체크포인트를 가져와 추가 학습을 하는 것이 용이하기에 Continual Pretraining 시나리오에서 장점이 있다. 또한 이 Continual Pretraining 시나리오를 Scaling Law 추정에 사용할 같은 모델 크기에서 학습량을 다르게 하는 실험을 좀 더 효율적으로 할 수 있다. (https://arxiv.org/abs/2403.08763, https://arxiv.org/abs/2404.06395, https://arxiv.org/abs/2405.18392)

Scaling Law

Kaplan Scaling Law와 Chinchilla Scaling Law에서는 모델 파라미터 N과 데이터 양 D에 대해 학습 FLOPS C = 6ND라는 근사를 통해 Scaling Law를 추정했다. 그러나 모델 파라미터 N에 임베딩이 포함되어야 하는가 아닌가의 차이가 있었고 이것이 Kaplan Scaling Law와 Chinchilla Scaling Law 사이에 큰 차이를 만들었다. (https://arxiv.org/abs/2406.12907, https://arxiv.org/abs/2406.19146)

DeepSeek에서는 이 문제가 널리 알려지기 전 시점에 이미 모델 파라미터 N을 모델의 토큰 당 FLOPS M으로 대체하는 것을 제안했다. 그리고 이를 통해 학습 FLOPS의 증가에 따라 배치 크기와 Learning Rate가 어떻게 변화하는 것이 최적인가와 같은 하이퍼파라미터 최적화의 문제를 Scaling Law로 접근했다.

추가적으로 모델 크기와 데이터 양 증가의 최적 비율이 데이터 퀄리티에 따라 달라진다는 결과를 보고한다. 즉 데이터 품질이 높다면 모델의 크기를 더 키우고 데이터 양을 감소시키는 쪽이, 낮다면 모델의 크기를 줄이고 데이터 양을 늘리는 쪽이 최적이라는 것이다. 이를 흥미로운 문제와 연결해볼 수 있겠다. 현재 모델의 크기에 비해 더 많은 데이터를 사용하는 추세인데, 저품질의 데이터라도 많이 사용하는 쪽이 고품질의 데이터를 반복 사용하는 것보다 나을 것인가라는 문제이다. (https://arxiv.org/abs/2404.07177)

DeepSeekMoE

MoE 모델. 비교적 평이한 구조를 채택했던 DeepSeek LLM과는 달리 상당히 다른 세팅의 MoE 모델을 사용했다. Dense 모델과 동일한 크기의 FFN을 Expert로 사용하던 MoE 모델과는 달리 그보다 훨씬 작은 Expert를 더 많이 사용하고, Forward 시점에서도 Top 2 정도를 사용하던 것과는 달리 Top 6을 사용한다. 동시에 모든 토큰에 대해서 공유되는 Expert가 2개 있어 각 토큰 당 Expert가 총 8개 사용된다.

Expert의 수가 많기 때문에 각 Expert에 대한 토큰 밸런스 Loss를 완화한 같은 디바이스에 있는 Expert들의 그룹 레벨에 대한 토큰 밸런스 Loss를 추가로 사용한다.

모든 토큰들에 대해 공통된 지식은 공유 Expert에 할당되고, 좀 더 특화된 지식들이 더 다양한 Expert에 분산되면서 훨씬 더 다양한 방식으로 Expert가 조합되어 사용되기를 기대한다는 것이 주된 아이디어이다. 이런 형태로 더 작은 Expert를 더 많이 사용하고 공유 Expert를 할당하는 것은 Qwen 쪽에서도 실험했다. (https://qwenlm.github.io/blog/qwen-moe/)

이 구조가 의도하던 목표를 달성했을까? 일단 성능적으로 우수하다고 주장하는 것과는 별개로 Expert가 좀 더 특화된 것 같다고 해석할 수 있는 결과는 있다. (https://arxiv.org/abs/2406.18219)

DeekSeep-Coder

코드 모델. GitHub 데이터 기반으로 87개 언어에 대해 학습. 가장 두드러지는 부분은 Dependency Parsing이다.

이는 코드 파일들 사이에는 의존 관계가 있기 마련인데 이 의존 관계에 따라 의존하는 파일이 의존 대상이 되는 파일의 뒤에 위치하도록 정렬하는 방법이다. 이는 각 코드들에 대해 더 많은 맥락을 제공하게 된다는 장점이 있다. 추가적으로 레포 레벨의 코드 작성 시나리오를 고려할 때 레포 레벨의 구조가 프리트레이닝에 반영되어 있다는 것은 장점이 될 수 있다.

이는 InternLM2와 CodeGemma에도 사용되었다. (https://arxiv.org/abs/2403.17297, https://arxiv.org/abs/2406.11409) 사실상 표준이라고 생각할 수 있을 듯 하다.

DeepSeekMath

수학 특화 모델. 수학 올림피아드 대회가 있었는데 (https://www.kaggle.com/competitions/ai-mathematical-olympiad-prize) 상위 팀들이 모두 채택한 모델이라고 알려져 있다.

DeepSeekMath에서 가장 중요한 부분은 Common Crawl에서 수학 관련 텍스트들을 발굴한 과정이다. 이는 OpenWebMath (https://arxiv.org/abs/2310.06786) 데이터를 사용해 OpenWebMath와 유사한 문서들을 찾는 것에서 시작한다.

그리고 Common Crawl의 도메인들을 추출한 다음 이렇게 찾은 유사한 문서들이 등장한 도메인을 찾아 수학 관련 도메인으로 지정한다. 이 도메인에서 수학과 관련이 높은 서브 도메인들을 찾아내고 이 도메인들로 링크하는 문서들을 Positive 데이터로 추가한다. 이를 반복해서 120B 토큰 가량의 수학 데이터셋을 구축했다. OpenWebMath가 13.6B 토큰 규모라는 것을 고려하면 훨씬 큰 규모이다.

이는 Common Crawl을 이미 학습 데이터로 사용하고 있더라도 Common Crawl 내에서 고가치 데이터를 추출하고 포맷을 개선하는 것이 중요한 의미가 잇을 수 있다는 것을 시사한다. 이 접근 또한 최근 채택되고 있다. (https://medium.com/snowflake/snowflake-arctic-cookbook-series-arctics-approach-to-data-b81a8a0958bd, https://arxiv.org/abs/2405.19327)

DeekSeek-VL

Vision Language 모델. 평이하지만 데이터셋 구성 측면에서 흥미로운 사실이 하나 있다. 바로 Anna's Archive에서 획득한 1M 규모의 E-Book 데이터를 사용했다는 것. Book3 데이터가 200K 규모로 25B 토큰 정도라는 것을 생각하면 100B 정도의 규모라고 생각할 수 있겠다.

InternLM2 (https://arxiv.org/abs/2403.17297) 혹은 Yi-34B (https://arxiv.org/abs/2403.04652) 같은 모델들 또한 100B 규모의 책 데이터를 학습에 포함하고 있다. DeepSeek-VL에서는 Vision Language 학습용으로 사용했지만 사실 LLM 학습에 사용하지 않을 이유도 없을 것이다.

DeepSeek-V2

21B Activated, 236B 8.1T 학습 MoE 모델. Llama 3 70B에 근접하는 모델이다. 이 모델을 출력 토큰 1M에 $0.3 수준으로 제공해서 중국 LLM API 시장을 뒤흔들었다고 한다.

데이터

데이터와 학습량이 8.1T로 상승했지만 이 데이터의 기원이 무엇인지는 분명하지 않다. 일단 중국어 토큰 수가 영어 토큰보다 12% 많다는 것을 고려하면 상당 부분이 중국쪽의 웹이나 서적 데이터에서 왔다고 할 수 있을 것이다.

특징적인 부분은 잘못 삭제했던 데이터들을 복구했다고 하는 언급이다. Deduplication이나 퀄리티 필터링의 개선 혹은 완화로 데이터의 양을 늘렸을 수 있다.

아키텍처

DeepSeekMoE를 채택하면서 동시에 Attention을 Multi-head Latent Attention이라는 방법으로 교체했다. 이는 MHA나 MQA/GQA와는 달리 임베딩을 Linear Projection으로 차원 축소한 다음 다시 Linear Projection으로 차원을 증가시키고 헤드를 구성하여 Attention을 계산하는 방식이다. KV Cache로는 차원을 축소한 Latent만 저장하면 되기 때문에 메모리 부담이 줄어든다. 8 Head를 사용하는 일반적인 GQA 이상으로. 동시에 MHA 이상의 성능을 달성한다. 물론 이는 헤드의 수와 차원이 다르기 때문일 가능성은 높다.

다만 추론 시점의 효율성 때문에 Position Embedding이 포함된 헤드를 따로 분리해야 하는 등 번거로워지는 점은 있다.

추가적으로 각 디바이스에서 전송하는 토큰의 양과 수신하는 토큰의 양의 밸런스를 맞추기 위한 Loss가 사용되었다.

인프라

DeepSeek은 HAI-LLM이라는 이름을 붙인 Megatron 기반 프레임워크를 학습에 사용하고 있는데, DeepSeek-V2에서는 Zero-Bubble Pipeline Parallelism (https://arxiv.org/abs/2401.10241) 을 도입했다는 것이 특징적이다. 최소한 이 방법이 학습 효율성을 낮추지는 않는다는 점을 확인했다고 생각할 수 있을 것 같다.

H800 클러스터에서 DeepSeek 67B는 1T 학습에 301K GPU 시간이 필요했다면 DeepSeek-V2는 173K GPU 시간이 소요되었다고 한다. 물론 이 두 모델이 동등한 Capacity를 갖고 있는가는 다른 문제이긴 하다. 그렇다고 한다면 DeepSeekMoE 모델이 70% 더 학습 연산량에 대해 효율적이라는 의미가 된다. 사실 MoE 모델 쪽이 Capacity가 더 높을 수도 있고, 그렇다면 연산 효율성은 더 상승할 것이다.

DeepSeek-Coder-V2

코드 모델 V2. 4.2T 학습한 DeepSeek-V2에 대해 6T 추가 학습한 모델이다. 추가 학습할 계획이 없었는지 Multi Step 대신 Cosine 스케줄러를 사용했다.

데이터

338개 언어에 대해 821B 코드 데이터와 코드 관련 텍스트 185B를 구축했다. StarCoder 2 (https://arxiv.org/abs/2402.19173) 가 900B 수준의 코퍼스를 사용했다는 것을 고려하면 상당한 규모라고 할 수 있겠다.

DeepSeekMath에서 사용했던 방법을 코드에도 적용해 Common Crawl에서 70B, GitHub에서 94B 토큰을 추가 수집했다. 수학 관련 문서도 더 수집했는지 수학 관련 데이터도 221B로 증가했다.

종합

새로운 데이터 수집, Common Crawl 내에서도 고가치 데이터를 발굴하고 포맷을 개선하는 작업들, 데이터의 퀄리티 컨트롤, 데이터를 검증하는 실험과 실험을 뒷받침할 수 있는 데이터, 특히 학습 효율성을 위한 아키텍처와 모델링 개선, 학습 인프라의 효율성 개선. 7편의 논문을 정리했지만 결국 요점은 이러한 대규모 딥 러닝 모델 개발에서 늘 성공적이었던 레시피들을 가다듬은 것에 있다고 할 수 있을 듯 싶다.

그리고 이것으로 현재 수준에서 최고 수준의 LLM을 만들기 위한 레시피로 충분한 정도가 아닐까 하는 생각을 한다. 다음 단계로 넘어가기 위해서는 합성 데이터 등의 적극적인 활용과 방법의 고안이 필요하리라고 생각한다. 그렇지만 합성 데이터 또한 사람이 생성한 데이터 위에서 시작할 때 정말로 의미가 있을 가능성이 높지 않을까 싶다.