전체 요약:
스캐터랩의 김준성은 인공지능 채팅 앱 ‘이루다’의 과거 이슈 및 현재 업데이트, 그리고 자체적으로 대화 모델을 개발한 동기와 과정에 대한 발표를 진행했습니다. ‘이루다’는 2021년 첫 출시 이후 문제를 겪고 서비스가 중단되었지만, 2022년에 2.0 버전으로 재출시되어 활발히 사용되고 있으며, 다른 AI 캐릭터들과의 콜라보레이션도 진행 중입니다. 김준성은 이루다의 대화 퀄리티, 데이터 보안, 운영 비용, 운영 안정성을 강조하며 왜 자체 개발을 선택했는지에 대해서 설명했습니다. 또한, 각종 기술적 도전과 문제를 해결한 과정, 비용 관리 및 멀티클라우드 운영 전략, 그리고 메모리 관리와 멀티모달 학습 방식에 대한 설명이 포함되었습니다.

목차 및 세부 내용:
1. 이루다 2.0 버전 개발 배경
– 이루다는 최초 1.0 버전 출시 후 여러 이슈로 서비스 중단을 겪었고, 이후 2022년 10월 2.0 버전으로 재출시 되었다. 회사는 다양한 AI 캐릭터와의 콜라보레이션을 진행하며 서비스를 확장하고 있다.

2. 자체 대화 모델 개발 이유
– 대화 퀄리티, 연구자의 유연성, 데이터 보안, 운영 비용 및 운영 안정성 때문에 기존의 오픈 소스 모델 대신 자체적으로 대화 모델을 개발하기로 결정했다. 이는 사용자와의 인터랙션과 관계 형성에 특화된 대화 모델을 만들기 위함이었다.

3. 기술적 도전과 문제 해결
– 멀티모달 학습, 대규모 데이터 관리, GPU 클러스터 최적화 등 다양한 기술적 도전이 있었으며, 이러한 도전을 해결하기 위해 여러 클라우드 서비스와 협업하고 최신 기술을 적용했다.

4. 비용 관리 및 멀티클라우드 운영 전략
– 이루다를 운영하면서 높은 비용과 리소스 부족 문제를 겪었고, 이를 해결하기 위해 하드웨어 최적화, 멀티 클라우드 배포, 쿼텀화 기술, 서버 최적화 등을 활용했다.

5. 메모리 관리 및 멀티모달 학습
– 대화의 연속성과 관계 형성을 위해 메모리 관리가 중요하며, 이미지와 텍스트 등의 다양한 데이터 타입을 통합한 멀티모달 학습 방식을 구현했다. 이러한 내부적인 리서치와 구현을 통해 인공지능의 대화 능력을 향상시켰다.

이 컨텐츠는 MLOps의 실천 방안과 인공지능 모델 배포에 대한 포괄적인 논의를 제공합니다. 특히, 스캐터랩의 AI 채팅 메신저 이루다 2.0의 개발 과정과 채택된 기술을 상세히 설명하며, 다양한 경험과 시행착오를 공유합니다. 어떤 모델을 선택할지, 비용을 어떻게 최적화할지, 그리고 대화의 질적 성능을 어떻게 개선할지를 고민하는 과정이 드러납니니다. 참가자 간의 피드백을 통해 적극적인 의사소통의 필요성이 강조되며, 각종 데이터 관리 문제를 해결하기 위한 노력도 소개됩니다. 전체적으로, 이 컨텐츠는 인공지능 시스템 구축과 운영에 대한 실질적인 통찰을 제공합니다.[1]

1. 🤖 스캐터랩의 자체 LLM 개발 배경더 자세히더 쉽게00:00:00 (8분)

• 스캐터랩은 AI 채팅 메신저 이루다 2.0을 개발하면서 오픈소스 LLM 대신 자체 LLM을 개발하기로 결정하였으며, 그 이유는 주로 대화의 질적 성능 때문이었다.[1-3]
• 자체 LLM 개발의 첫 번째 이유는 사용자의 대화 인터랙션을 향상시키기 위함이다.[1-22]
• 대화의 질뿐만 아니라 다양한 기능을 구현 가능하도록 연구자 관점에서 더 나은 기술적 유연성을 확보하기 위해 이를 선택했다.[1-24]
• 데이터 보안 이슈 해결 및 법적 가이드라인을 엄격히 준수하기 위한 조치의 일환으로도 필요했다.[1-37]
• 운영 비용을 절감하고 오픈 AI의 불안정성을 극복하기 위함으로, 높은 API 비용과 제한으로 인해 자체 LLM을 개발해 운영하게 되었다.[1-41]

2. 💡 모델 사이즈 및 학습 비용 고려하기더 자세히더 쉽게00:08:20 (5분)

• 모델 사이즈를 결정하는 과정에서 서빙 비용을 중요하게 분석하였다. [2-2]
• 서빙 최적화 후, 적정한 모델 사이즈를 판단하여 약 30비 언더에서 모델 개발을 추진하였다. [2-8]
• GPU 클러스터의 높은 비용으로 인해 직접 구입하기 어려웠고, 대규모 학습을 진행하기 위한 전략을 고민하였다. [2-10]
• 모델 학습 성공을 위해 고퀄리티 데이터와 최적화 기법을 활용하여 한 번의 시도로 학습을 완료하였다. [2-19]
• 유저 데이터와 직접 레이블링한 데이터셋을 기반으로 모델 학습을 동시에 진행하였다. [2-27]

3. 🚀 GPU 클러스터의 효율적 활용 문제더 자세히더 쉽게00:13:38 (3분)

• 회사에는 20명 이상의 리서치 및 엔지니어 팀이 있으며, 그들의 요청으로 인해 실험 수가 많아지고 있다.[3-1]
• GPU 클러스터의 자원이 한정적이기 때문에, 단 하나의 GPU 머신만 활용되고 있는 상황이다.[3-2]
• 실험 요청이 많아지면서, GPU 리소스가 비효율적으로 배정되고 있으며, 사용하지 못하는 GPU가 생기고 있다.[3-3]
• 자동 스케줄링 기능이 없어 수동으로 관리하게 되면서, GPU 사용의 비효율성이 발생하고 있으며, 비용 및 실험 관리 문제도 동반되고 있다.[3-5]
• 이러한 문제를 해결하기 위해 베셀 측과 협업하여 솔루션을 개발하여, 효율적인 GPU 사용을 기대하고 있다.[3-7]

4. 🚀 서비스 배포를 위한 도전과 해결책더 자세히더 쉽게00:16:42 (5분)

• 서비스 배포 시 가장 큰 도전은 비용으로, GPS 비용이 매우 비쌌고 자원 부족 문제로 고민이 많았다.[4-4]
• GPU 메모리가 부족해 큰 모델을 서빙하기 어려웠고, 최적화된 코덱 서비스 개발도 비용 효율성의 문제로 생각해야 했다.[4-8]
• 하드웨어 비용 문제를 해결하기 위해 최신 머신러닝 모델 최적화 출력 칩인 AWS의 임프란시아2를 활용해 최적화를 시도했다.[4-9]
• 다중 클라우드 운영을 통해 여러 GPU 클라우드 업체와 협력하고, 각각의 GPU 특성을 분석해 자원 분산 문제를 해결하고 있다.[4-11]
• 최근에는 모델 크기를 압축하기 위해 퀀타이제이션 기법을 적용하고 있으며, 최신 연구 결과를 반영해 검증하고 활용하고 있다.[4-20]

5. 🚀 LLM 개발과 배포 경험 요약더 자세히더 쉽게00:22:37 (8분)

• 자체적인 LLM 구현을 위해 3개월 내에 제한된 비용과 리소스 안에서 빠르게 진행해야 했던 상황이었다. [5-1]
• 인하우스에서 모든 것을 개발하는 것은 불가능하다는 것을 깨달았고, 고품질 데이터와 최고의 학습 환경이 필요하다는 점을 인식했다. [5-2]
• 데이터 생성과 가공은 팀의 몫이나, 지원 시스템은 외부 도움을 받아야 한다는 결론을 내렸다. [5-3]
• 대기업보다 저렴한 비용으로도 LLM을 구축할 수 있다는 경험을 공유하고 싶었다. [5-4]
• 이미지와 텍스트를 함께 활용한 멀티 모델 블렌딩 방식을 적용하여 학습을 진행하고 있음을 설명했다. [5-35]

https://www.databricks.com/blog/gpt-3-quality-for-500k

Mosaic LLM: GPT-3 품질, 50만 달러 미만

아비 베니 갈라 (Abhi Venigalla) 와 린든 리(Linden Li)

2022년 9월 29일 Mosaic AI Research

---

이 게시물을 공유하세요

대규모 언어 모델(LLM)을 훈련하는 데 드는 비용은 생각보다 저렴합니다. MosaicML 플랫폼을 사용하여 이러한 모델을 대규모로 훈련하는 것이 얼마나 빠르고 저렴하며 쉬운지 보여드립니다(1B -> 70B 매개변수). 대규모 워크로드에 맞게 설계된 새로운 훈련 레시피와 인프라를 통해 모델과 데이터 세트에 대한 완전한 사용자 정의를 유지하면서 LLM을 훈련할 수 있습니다.

대규모 언어 모델(LLM)은 인기가 폭발적으로 증가하고 있지만 GPT-3와 같은 거대한 모델을 처음부터 학습시키는 능력은 방대한 리소스와 심층적인 기술 전문성을 갖춘 몇몇 조직으로 제한되었습니다. 나머지 사람들이 LLM을 사용하려면 추론에 대해 프리미엄을 청구하고 모델의 출력에 콘텐츠 제한을 부과하는 API 제공업체에서 임대해야 합니다. 그들이 제공하는 모델은 일괄 적용되며 특정 도메인에 적합하지 않은 일반적이고 군중 소싱된 데이터에서 학습됩니다. 어떤 경우에는 이러한 일반 데이터가 의도치 않게 인간의 편견을 증폭시킬 수 있습니다 .

MosaicML에서 저희의 사명은 모든 사람이 딥 러닝을 효율적으로 사용할 수 있도록 하는 것입니다. LLM의 맥락에서 이는 비용을 절감하고 교육을 가속화하여 누구나 자신의 필요에 맞는 맞춤형 LLM을 만들 수 있도록 하는 것을 의미합니다(예: Reddit이 아닌 의학 저널에서 사전 학습된 의료 기관용 LLM). 저희는 수백만 개의 고유한 모델이 특정 애플리케이션에서 사용하기 위해 다양한 데이터 세트에서 학습되는 세상을 상상합니다.

오늘, 우리는 이 여정의 다음 단계를 발표합니다. MosaicML 플랫폼에서 LLM을 교육하기 위한 일류 지원과 이를 위한 비용에 대한 투명한 데이터입니다. 결론은 GPT-3 품질*에 도달하는 모델을 교육하는 데 약 45만 달러가 들며, 이는 사람들이 생각하는 것보다 2~10배 적습니다. 그리고 이것은 시작에 불과합니다. 앞으로 몇 달 동안 우리는 그 가격표를 더욱 낮추는 MosaicML 교육 레시피를 개발할 것입니다. 아래에서 공유하는 많은 참조 모델이 이제 기업에서 사용할 수 있게 되었지만, 우리는 LLM이 모든 사람에게 접근 가능하기를 바랍니다. 모든 기업, 연구자 또는 학생이 이러한 모델을 독립적으로 분석하고 교육할 수 있어야 합니다.

* 품질 == Chinchilla 스케일링 법칙을 사용한 예측 평가 손실; 아래의 레시피 및 세부 정보 참조

우리는 그 신화를 깨고 싶습니다. 처음으로 MosaicML 플랫폼에서 측정한 컴퓨팅 최적화 LLM을 훈련하는 데 드는 시간과 비용을 소개합니다. 저희의 프로파일링은 컴퓨팅 최적화 GPT-30B를 50만 달러 미만으로 610B 토큰에서 훈련할 수 있음을 보여줍니다. 그리고 아래에서 설명하겠지만, 새로운 Chinchilla 스케일링 법칙 에 따라 이 모델 레시피는 매개변수 가 더 많았지만(1,750억 개의 매개변수) 더 적은 데이터(3,000억 개의 토큰)에서 훈련된 원래 GPT-3 와 동일한 품질에 도달할 것으로 예상합니다 .

* 이 레시피는 원래 GPT3-175B 레시피와 동일한 품질을 달성할 것으로 예상됩니다.
** 이 레시피는 Chinchilla-70B와 동일합니다.

그림 2 에 따르면 , 이러한 LLM 대부분을 훈련하는 데 드는 비용은 수백만 달러가 아니라 수천 달러에서 수십만 달러 범위입니다. 설문 조사에 참여한 사용자의 약 80%가 비용이 더 높을 것으로 예상했습니다! 13억 달러에서 67억 달러 범위의 소규모 모델의 경우 훈련 비용은 이제 스타트업과 학술 연구실에서 충분히 감당할 수 있으며, 모델은 몇 달이 아니라 며칠 만에 제공될 수 있습니다. †

MosaicML을 사용하여 맞춤형 LLM을 교육하려면 플랫폼 데모에 등록하세요 .

바로 시작 코드를 알아보려면 여기를 확인하세요 .

여러분이 ML 엔지니어이고, ‘ 우리가 어떻게 여기까지 왔을까 ?!’라고 궁금해하신다면, 계속 읽어보세요!

구성 요소 #1: MosaicML 플랫폼

사용자 지정 LLM을 학습하고자 할 때 가장 큰 과제 중 하나는 컴퓨팅 인프라를 소싱하는 것입니다. BLOOM 및 OPT 와 같은 오픈 소스 활동에서 알 수 있듯이 이는 중요한 결정입니다. 수백 개의 GPU에서 다중 노드 작업을 조율하는 것은 까다롭고 더 작은 규모에서는 발생하지 않는 오류가 발생할 수 있습니다. 하드웨어 오류와 손실 급증은 흔하며 학습 중에 지속적인 모니터링과 재개가 필요합니다. 모든 것이 작동하더라도 작업을 초기화하고, 체크포인트를 저장/로드하고, 데이터로더를 재개하는 데 여전히 엄청나게 느릴 수 있습니다. 게다가 모델이 예상대로 수렴하지 않아 비용이 많이 드는 재실행과 하이퍼파라미터 튜닝이 필요할 수 있습니다.

MosaicML 플랫폼은 이러한 과제를 해결하기 위해 처음부터 구축되었습니다. 당사 플랫폼을 사용하면 컴퓨팅을 소싱하고, 교육 작업을 조정하고 모니터링하고, 팀원과 리소스를 공유할 수 있습니다. 무엇보다도 당사 연구팀이 LLM 워크로드에 최적화된 실전 테스트된 교육 코드와 레시피를 제공합니다. 클라우드 인프라에 구애받지 않으며 모든 클라우드 공급자(AWS, OCI, Google, Azure)에 저장된 데이터와 호환됩니다.

몇 가지 주요 기능을 살펴보겠습니다.

다중 노드 확장

첫째, MosaicML 플랫폼은 모든 클러스터(귀하의 클러스터, 당사 클러스터 또는 클라우드 공급업체의 클러스터)에서 작동하는 작업 스케줄러를 제공하며, 작업을 시작하고 확장하는 것을 마법처럼 느끼게 합니다. 작업 부하를 가속화하는 것은 `gpus: 8`을 `gpus: 256`으로 변경하는 것만큼 쉽습니다. MosaicML 플랫폼과 Composer 라이브러리는 모든 분산 학습 세부 정보를 처리합니다. 그림 3 에서 노트북에서 GPT-13B 학습 실행을 시작하고 클러스터를 모니터링할 때의 모습을 볼 수 있습니다(256개 GPU에서 단일 실행!). LLM 시리즈의 1부 에서 보여준 것처럼 , 적절한 인프라를 갖춘 다중 노드 학습은 오버헤드가 거의 발생하지 않습니다. 당사 플랫폼에서 최대 수백 개의 GPU에서 LLM을 학습할 때 선형에 가까운 확장을 확인합니다. 즉, 총 비용이 최소한으로 증가하면서 작업을 훨씬 더 빨리 완료할 수 있습니다.

빠르고 자동적이며 우아한 재개

다음으로, 이러한 LLM을 실행하고 학습할 때까지 기다리면 bfloat16 혼합 정밀도 학습을 사용하더라도 불가피하게 하드웨어 문제와 손실 급증이 발생합니다 . 이러한 문제를 해결하기 위해 MosaicML 플랫폼은 Composer 와 원활하게 작동하여 자동 우아한 재개를 지원합니다. 실행이 중단되거나 손실 급증이 감지되면 플랫폼은 자동으로 중지하고 다시 시작하며 최신 안정된 체크포인트에서 실행을 재개합니다. Composer는 기본적으로 파일 시스템 및 객체 저장소 기반 체크포인팅을 모두 지원하므로 모든 클러스터에서 작업을 중지하고 재개하고 모델 아티팩트를 하나의 중앙 위치에 보관할 수 있습니다.

그림 4 에서 ‘hang'(아마도 통신 작업 실패)이 발생한 GPT-6.7B 훈련 실행과 손실 급증이 발생한 GPT-2.7B를 어떻게 재개했는지 확인할 수 있습니다. 두 경우 모두 마지막 안정된 체크포인트에서 원활하게 다운로드하고 재개할 수 있었으며, 자동으로 또는 `load_path: s3://my-bucket/my-run/ep0-ba48000.pt`와 같이 체크포인트 경로를 지정하여 이를 수행할 수 있었습니다.

마지막 세부 사항: 훈련 실행의 깊은 곳에서 체크포인트에서 재개할 때 데이터로더 상태를 다시 로드하는 데 오랜 시간이 걸릴 수 있습니다. 예를 들어, Meta의 최근 OPT-175B 훈련 로그 에서는 데이터로더가 체크포인트 상태로 “빠르게 전달”하는 데 약 30분이 소요되었다고 나와 있습니다. 이는 30분 동안 모든 1024개 GPU가 유휴 상태로 대기하여 리소스를 낭비하고 짜증나는 지연 시간을 더한 것입니다. 이러한 문제를 피하기 위해 결정적이고 거의 즉각적인 재개를 특징으로 하는 자체 스트리밍 데이터세트 구현을 구축했으며, Composer와 원활하게 작동하여 빠르게 전달할 필요가 없습니다. 또한 LLM 훈련 처리량에 영향을 미치지 않고 S3, GCS 등과 같은 객체 저장소에서 스트리밍 데이터세트를 지원하도록 처음부터 구축되었습니다. 스트리밍 데이터세트에 대한 자세한 정보가 포함된 다가올 블로그 게시물을 기대하세요!

구성 요소 #2: Composer + PyTorch FSDP

컴퓨팅 인프라가 구축되면 LLM의 다음 주요 장애물은 GPU 클러스터에서 이러한 거대한 모델을 맞추고 병렬화하는 것입니다. 메모리 부족(OOM) 오류와 느린 학습 처리량이 일반적입니다. 이러한 문제를 완화하기 위해 일반적으로 Megatron-LM 과 같은 프레임워크를 채택 하고 이국적인 형태의 3D 병렬 처리 (파이프라인, 모델 및/또는 텐서 병렬 처리)를 적용하여 모델을 여러 장치에 분산합니다. 이러한 프레임워크는 성능이 뛰어나지만 사용자 정의하기 어렵고 모델이 어떻게 구성되어야 하는지에 대한 강력한 가정이 있으며 종종 비표준 검사점 형식과 정밀도 전략을 사용합니다. 이러한 프레임워크를 사용하는 것은 물론 사용자 정의 학습 레시피를 사용하도록 수정하는 것은 힘든 일이 될 수 있습니다. (알고 있습니다. 시도해 보았습니다.)

그래서 MosaicML에서 저희 팀은 가능한 한 간단하고 유연한 LLM 스택을 구축하기로 했습니다. 저희는 Composer에서 여러 가지 설계 선택을 했는데, 이를 통해 위의 장애물을 피할 수 있었고, 사용자가 순수 PyTorch로 모델을 구축하고 성능을 저하시키지 않고 데이터 병렬성만으로 학습할 수 있었습니다 . 특히, 저희는 LLM과 같은 대규모 워크로드를 위한 엔진으로 PyTorch FSDP (FullyShardedDataParallel)를 통합하기로 했습니다.

PyTorch FSDP는 PyTorch DDP(DistributedDataParallel)와 유사한 전략으로, 모델의 매개변수가 어떻게 분할되고 여러 장치에서 그래디언트가 어떻게 계산되는지 정의합니다( 그림 5 참조 ). 중요한 세부 사항은 FSDP를 사용하면 파이프라인, 모델 또는 텐서 병렬 처리 없이 LLM과 같은 대규모 모델을 학습할 수 있다는 것입니다. 파이프라인, 모델 또는 텐서 병렬 처리 는 모델 코드에 통합하기 어려울 수 있으며 성능에 대한 추론을 복잡하게 만들 수 있습니다. 대신 FSDP는 ML 사용자에게 가장 간단하고 익숙한 전략인 데이터 병렬 처리만 사용하여 작업을 분산하며 사용되는 모델 아키텍처, 최적화 프로그램 또는 알고리즘에 어떠한 제한도 부과하지 않습니다.

FSDP의 유연성을 강조하기 위해 이 블로그 게시물의 모든 훈련 결과는 바닐라 손으로 쓴 GPT 모델( Andrej Karpathy의 minGPT에서 영감을 받음! )을 사용하여 측정되었습니다. 이 모델은 본질적으로 순수 PyTorch로, 사용자가 원하는 대로 사용자 정의하기가 매우 간단합니다. 예를 들어, `torch.nn.MultiheadAttention` 레이어를 Dao et. al의 새로 출시된 `FlashMHA` 모듈로 대체했고, Composer는 FSDP로 사용자 정의 모델을 훈련하는 데 아무런 문제가 없었습니다. 코드를 확인 하고 직접 사용자 정의해 보세요!

어떻게 가능한 걸까요?FSDP는 ZERO 샤딩 전략 의 PyTorch 네이티브 구현입니다 .ZERO는 각 GPU에 복제하는 대신 전체 클러스터에 걸쳐 모델 + 그래디언트 + 옵티마이저 상태를 샤딩합니다.즉, ~1TB의 상태를 가진 70B 매개변수 모델조차도 각 GPU가 아닌 전체 클러스터 메모리 에 맞아야 합니다 .32xA100-40GB 클러스터 또는 16xA100-80GB 클러스터 등으로 이를 달성할 수 있습니다.Composer로 CPU 오프로딩을 활성화하면(작업 진행 중!) 더 작은 시스템을 더욱 쉽게 사용할 수 있습니다.

Composer + FSDP에는 삶의 질을 높여주는 몇 가지 멋진 기능도 있습니다.

• 체크포인트는 N개의 다른 디바이스에서 샤딩된 파일 모음 대신 글로벌 디바이스0에서 단일 Pytorch `.pt` 파일로 저장됩니다. 이를 통해 다른 클러스터 크기에서 실행을 재개하고 다운스트림 작업에 대한 모델을 공유하는 것이 더 쉬워집니다.
• FSDP는 PyTorch로 구축되었으며 `torch.autocast(…)`를 통한 표준 혼합 정밀도 학습과 원활하게 작동하는 동시에 저정밀도 그래디언트 통신 및 저정밀도 마스터 가중치 + 옵티마이저 상태와 같은 고급 기능도 지원합니다.
• FSDP는 Composer의 자동 마이크로 배칭 엔진 과 함께 사용해 학습 중에 OOM 오류를 동적으로 포착하고 조정할 수 있으며, 하드웨어에 독립적인 학습 구성을 구현할 수 있습니다.

이제 이 모든 것이 훌륭하지만 성능은 어떨까요? MosaicML 플랫폼을 사용할 때 이러한 LLM을 Megatron-LM과 같은 고도로 최적화된 프레임워크와 동등하거나 더 나은 활용도로 훈련할 수 있다는 사실을 보고하게 되어 기쁩니다. 256xA100 GPU에서 GPT-13B 모델과 같은 실제 설정으로 훈련할 때 정기적으로 40%+ MFU(모델 FLOPS 활용도)를 확인합니다. 이는 하위 계층 카드(40GB 대 80GB)를 사용하고 더 많은 장치 수(256개 GPU 대 8-64개 GPU)를 사용하며 훨씬 더 많은 유연성을 제공하는 다른 프레임워크의 보고서와 일치합니다.

구성 요소 #3: Chinchilla Compute-Optimal Training

인프라와 코드에 대해 이야기했지만 실제 모델 레시피는 어떨까요? 100B+ 또는 1조 개의 매개변수 모델을 밀집적으로 훈련해야 할까요? 그렇지 않다고 생각합니다. 최근 몇 년 동안 연구 커뮤니티는 LLM의 품질 및 컴퓨팅 요구 사항을 제어하는 ​​스케일링 법칙을 개발하는 데 있어 놀라운 진전을 이루었습니다. 최근 Hoffmann et. al의 논문 Training Compute-Optimal Language Models (일명 Chinchilla 논문)에서 GPT3-175B 및 Gopher-280B와 같은 대형 모델은 더 적은 매개변수와 더 많은 데이터를 사용하여 훨씬 더 효율적으로 훈련할 수 있다는 흥미로운 발견을 했습니다. 이러한 모델을 설계하는 데 사용된 스케일링 법칙을 신중하게 재측정하여 저자는 N := 매개변수 수, D := 데이터 토큰 수를 기준으로 모델의 사전 훈련 손실을 추정하기 위한 함수 (Eq. 10) 를 업데이트했습니다.

이 업데이트된 스케일링 법칙은 Gopher-280B와 동일한 컴퓨팅 예산으로 학습되었지만 훨씬 더 나은 손실 및 다운스트림 결과를 얻은 Chinchilla-70B라는 모델에 대한 제안으로 이어졌습니다.

우리는 동일한 스케일링 법칙을 사용하고 (N=175e9, D=300e9)의 원래 GPT3-175B 레시피를 플러그인하여 예측 손실 값 L=2.078을 얻었습니다. 대신 논문의 권장 사항에 따라 모델 크기에 비례하여 데이터를 스케일링하고(대략 D=20 * N) 하드웨어 효율적인 레이어 크기를 염두에 두면 손실 값 L=2.071이 약간 낮아질 것으로 예측되는 GPT-30B 모델과 레시피(N=30e9, D=610e9)에 도달합니다. 이 새로운 레시피는 이전보다 65% 적은 컴퓨팅을 사용하므로( 그림 6 참조 ) 학습 시간과 비용이 엄청나게 줄었습니다!

GPT-30B의 최종 품질은 여전히 ​​예측이며 , 더 작은 실행에서 유망한 결과가 있지만, GPT-30B를 완료할 때까지 계속 훈련하고 있으며 곧 업데이트할 것입니다. 하지만 Chinchilla 작업과 AlexaLM-20B (GPT3-175B보다 성능이 뛰어나고 동일한 권장 사항을 사용하여 훈련됨)와 같은 최근 결과는 더 나은 스케일링 법칙이 GPT-3 품질 모델 훈련 비용을 극적으로 줄인다는 압도적인 증거를 제공합니다. 훈련 실행이 계속됨에 따라 훈련 세부 정보, 결과 및 평가에 대해 자세히 알아볼 후속 LLM 블로그를 기대하세요!

다음은 무엇인가요?

이 블로그 게시물에서 우리는 MosaicML 플랫폼으로 사용자 정의 LLM을 훈련하는 것이 얼마나 빠르고 저렴하고 쉬운지 보여주었습니다. 또한 GPT-3 품질 모델은 50만 달러 미만의 최종 비용으로 컴퓨팅 최적화 레시피로 훈련될 수 있다고 예측했습니다. 이러한 결과에 관심이 있다면, 커뮤니티 슬랙 에 가입하거나 Twitter 에서 우리를 팔로우하여 개선된 훈련 레시피를 설명하는 다가올 LLM 블로그를 기대하세요 . 귀하의 조직이 오늘 LLM 훈련을 시작하려면 데모에 등록하세요 !

†구체적인 가격은 고객의 요구에 따라 달라질 수 있습니다.