올여름의 불타는 LLM: 세상도 불타고 나도 불타고

Slide 1

Slide 1 text

올여름의 불타는 LLM 세상도 불타고 나도 불타고 신정규 래블업 주식회사 @inureyes 2023년 8월 2일

Slide 2

Slide 2 text

• Lablup Inc. : Make AI Accessible – 오픈소스 머신러닝 클러스터 플랫폼: Backend.AI 개발 – https://www.backend.ai • Google Developer Expert – ML / DL GDE – Google Cloud Champion Innovator – Google for Startup Accelerator Mentor • 오픈소스 – 텍스트큐브 개발자 / 모더레이터 (곧 20년…) • 물리학 / 뇌과학 – 통계물리학 박사 (복잡계 시스템 및 계산뇌과학 분야) – (전) 한양대학교 ERICA 겸임교수 (소프트웨어학부) 안녕하세요! 2

Slide 3

Slide 3 text

• 2023년의 봄: 거대 언어 모델의 보급 • 거대 언어 모델 개발의 요소 – 소프트웨어 – 하드웨어 • 거대 언어 모델 개발 – 분산훈련 기초 – 파인 튜닝 – 사전 훈련 • 거대 언어 모델 서비스 • 마무리: 2023년의 여름 오늘의 주제 3

Slide 4

Slide 4 text

• 여러분이 앞 이야기를 듣고 들어오셨다고 가정합니다 – 같은 이야기 두 번 안 할 예정입니다 – 뭐지? 하시면 5월 톡을 들어 보시는 것으로… • 이해를 위해 몇 장의 슬라이드는 들고 옵니다 – 이어서 이해하는 과정에 도움이 될 수 있을 것입니다 주의사항 4

Slide 5

Slide 5 text

2023년 상반기: 거대 언어 모델의 보급 5

Slide 6

Slide 6 text

• 진화 – 선형적이 아닌 과정 – 어느 순간 폭발적으로 지수적 증가 • 2018년 – 트랜스포머 아키텍처 이후 급속한 발전 • 2020년 – 거대 언어 모델의 특이점들 발견 • 2022년 – 거대 언어 모델의 대중화 서비스 시작 – ChatGPT… 더이상 말이 필요한가? 언어 모델의 선캄브리아 시대 [1] https://arxiv.org/pdf/2304.13712.pdf 6

Slide 7

Slide 7 text

• 2023년 5~7월 3개월 동안 – 약 10,000여개의 언어 모델이 등장 – 지금 이 순간에도 나오고 있음 • 10, 100, 10000 – 10여개의 사전 훈련 모델 – 100여개의 응용 모델 – 10000여개의 파인 튜닝 모델 • 그 결과 – 응용 모델 개발에 2주일 – 파인 튜닝은 하루: 의지의 문제가 된 세상 언어 모델의 선캄브리아 시대 [1] https://github.com/Mooler0410/LLMsPracticalGuide 7

Slide 8

Slide 8 text

• 대충 다 거대 언어 모델로 수렴중 • 왜? – 거대 언어 모델은 언어를 하는 게 아님 • 언어는 프로토콜 – 정보를 프로토콜에 담아 보내면 – 정보 처리 결과를 프로토콜로 리턴 – (지난 발표 참조) 응용하기 [1] https://github.com/Mooler0410/LLMsPracticalGuide/blob/main/imgs/decision.png 8

Slide 9

Slide 9 text

• 챗봇은 실제 대화를 하는 것이 아님 – 글을 계속 이어 쓰는 형태의 문장 생성 모델 – 질문 – 대답 – 질문 – 대답이 이어지는 그 모든 내용이 그 다음 질문의 입력 – 앞 대화 또는 앞의 텍스트가 구체적이고 내용이 많을 수록 그 다음 이어 쓰는 내용이 명확해짐 • 프롬프트 – 글의 중간을 채워 넣는 방법 – 프롬프트 인젝션: 실제 유저에게 보이지 않는 곳에서 다양한 중간 텍스트를 추가해서 특정 동작을 만드는 방법 짚고 넘어갈 점 이런 방식으로 동작하도록 중간에 인젝션을 합니다. 9

Slide 10

Slide 10 text

• PaLM 2 (2023년 5월) – 구글의 차세대 언어 모델 – 4가지 크기로 개발 ✓ Gecko, Otter, Bison, Unicorn ✓ 차기 안드로이드 모바일에도 넣을 예정 – 응용 분야별 개발 ✓ Med-PaLM, Sec-PaLM ✓ Duet AI 통합 – 한국어 및 일본어 특화 개발(!) • Claude v2 (2023년 7월) – Anthropic의 개선된 언어모델 – 엄청나게 긴 입력 토큰 길이: 10만토큰… – 이게 길면 ✓ 앞에서 설명한 ‘글’이 아주 길게 유지되는 것이고 ✓ 기억을 아주 많이 하는 언어 모델이 됨 격전지: 사전 훈련 언어 모델 • Falcon LLM (2023년 6월) – 아부다비의 자금력으로 만든 거대 언어 모델 – 제약이 없는 거대 언어 모델 • Llama 2 (2023년 7월) – 메타의 Llama 개선 모델 – 사실상 상업적 용도 무제한 허용 ✓ (사실상일 뿐 무제한은 아님) https://blog.google/technology/ai/google-palm-2-ai-large-language-model/ 10

Slide 11

Slide 11 text

• GPU: 그래픽 프로세싱 유닛..이나, 여기서는 딥 러닝 계산을 가속하는 장치로 생각하면 됨 • 딥 러닝: 딥 뉴럴 네트워크Deep NeuralNet 의 약자 – AI 구현을 컴퓨터 머신러닝 분야에서 접근하는 방법 중 최근 10년 동안 가장 활발히 발전 중인 방법 • NVIDIA A100: 2021년 발표한 NVIDIA의 딥러닝 훈련용 GPU – ..였는데 2023년 초에는 최고의 서비스용 GPU로 홍보 중[1] 대당 1500만원, 현재는 1000만원 • NVIDIA H100: 2022년 하반기 발표한 NVIDIA의 훈련용 GPU – 발매 당시엔 대당 4000만원, 현재는 대당 5000만원 (인데 중요하지 않음) – (어차피 못사요) 격전지: GPU/NPU 하드웨어 시장 / 용어 설명 11

Slide 12

Slide 12 text

• NPU: 뉴럴넷 프로세싱 유닛, 딥 러닝 계산을 가속하기 위해 특화한 기기 – NVIDIA의 엔터프라이즈 GPU들도 NPU라고 보면 됩니다. (화면 출력을 위한 부분이 전혀 없음) – 용어 국산화로 인해 AI 반도체 라는 표현을 많이 씀 ✓ NPU말고도 훨씬 많은데 보통 AI 반도체라고 하면 NPU – FPGA 로 특화 서킷을 만들거나, 정식으로 칩을 굽는 두 가지 모두 NPU라는 표현을 씀 • 구분 – 용도: 훈련용, 서빙[1]용 – 규모: IoT, 모바일, PC, 서버용 격전지: GPU/NPU 하드웨어 시장 / 용어 설명 [1] 모델을 서비스하는걸 모델 서빙이라는 표현을 씀 12

Slide 13

Slide 13 text

• HBM: High bandwidth Memory – 대역폭을 넓혀서 속도를 올리기 위해, DDR 메모리로 아파트를 만들고 데이터 통로를 뚫은 메모리 – NVIDIA A100엔 HBM2e, H100엔 HBM3e를 사용 • GDDR6 – 그래픽 카드용 DDR 메모리 – 배타적 입출력 제한을 없애고, 램타이밍을 풀고 클럭을 올림 ✓ 속도를 올리고 동기화를 희생 – 2023년 기준 엔터프라이즈용 GPU가 아닌 경우 대부분 GDDR6을 메모리로 사용 ✓ DDR3 기반: GDDR4, GDDR5, GDDR5x ✓ DDR4 기반: GDDR6 격전지: GPU/NPU 하드웨어 시장 / 용어 설명 [1] https://www.amd.com/en/technologies/hbm 13

Slide 14

Slide 14 text

• 환상의 물건 GPU – 테슬라의 A100 10,000대 주문 (2022년 하반기), 이후 GPU 100,000대 기반 자율주행 데이터센터 목표 공개 – 마이크로소프트 / OpenAI의 H100 10,000대 주문 (1월) – 트위터의 H100 10,000대 주문 (4월) – 구글의 A100/H100 26,000대 사용 A3 슈퍼컴퓨터 구축 (5월) – 바이트댄스의 A800/H800 100,000대 주문 (6월) / $1B 규모 – 알리바바의 H800 몇 만 대 규모 주문 (6월) – 바이트댄스 및 알리바바의 주문 후 ✓ 미국의 대중국 H800 GPU 수출 규제 시작 ✓ (이미 주문한 양에는 영향을 주지 않음…) • 우리도 GPU 주세요 – 없어요. 돌아가세요~ 격전지: GPU 하드웨어 시장 / 상황 https://www.hpcwire.com/2023/02/20/google-and-microsoft-set-up-ai-hardware-battle-with-next-generation-search/ https://cloud.google.com/blog/products/compute/introducing-a3-supercomputers-with-nvidia-h100-gpus?hl=en https://www.cnbc.com/2023/07/28/microsoft-annual-report-highlights-importance-of-gpus.html https://www.ajunews.com/view/20230727113146316 14

Slide 15

Slide 15 text

• 클라우드 및 AI 업체들의 자급자족을 위한 움직임 – Amazon Inferentia2 (2022) ✓ NeuronCore v1 기반 칩렛 구성 – Microsoft Athena (Working in Progress) – Meta MTIA (gen2) ✓ 2021년 초기 모델 공개, 2023년 5월 2세대 개요 공개 – Tesla Dojo (2023) ✓ 6월에 첫 테이프 아웃 ✓ Google TPU와 구조가 유사 (Toroidal architecture) 격전지: GPU 하드웨어 시장 / 상황 https://www.reuters.com/technology/microsoft-developing-its-own-ai-chip-information-2023-04-18/ https://www.hpcwire.com/2021/06/22/ahead-of-dojo-tesla-reveals-its-massive-precursor-supercomputer/ 15

Slide 16

Slide 16 text

거대 언어 모델 개발의 요소 16

Slide 17

Slide 17 text

800GB A100 GPU 10장 TPUv4 Pod 0.6% GPT-3 인퍼런스 모델 용량 GPT-3.5 / ChatGPT 인퍼런스 모델 용량 (추정) 320GB A100 GPU 4장 8.9TB A100 GPU 112장 Cerebras 1장 TPUv4 Pod 7% PaLM 모델 훈련시 요구 용량 (추정) “거대” 언어 모델: 스케일 17

Slide 18

Slide 18 text

필요한 것들 소프트웨어 하드웨어 에 대한 이해가 필요합니다. 18

Slide 19

Slide 19 text

소프트웨어 구성 요소들 Corpus Language Corpus Knowledge base Task-oriented corpus Mixer Tokenizer English Korean Morpheme Runtime Distributed executor Experiment Monitor 19

Slide 20

Slide 20 text

• 말뭉치 Corpus – 텍스트 데이터 – 형식 ✓ 일반 텍스트 데이터 ✓ 질문 / 답변 텍스트 데이터 ✓ 비논리적 텍스트 데이터 (훈련용) • 일반 텍스트 데이터 – 태깅 없는 데이터를 어떻게 훈련에 쓰나요? ✓ 문장 데이터의 구조만으로도 훈련이 됨 – 언어 모델의 훈련 ✓ “문장”이 어떻게 만들어지는지 이해하는 것 ✓ “문맥”에 맞거나 안 맞는 표현 / 형식 / 단어에 대해 학습하는 것 말뭉치 20

Slide 21

Slide 21 text

• 지식 자료 (또는 지식 베이스)KnowledgeBase – 언어 모델은 지식이 ‘없음’ – 지식이 있는 것 처럼 보이는 것은 언어를 배우는 과정에서 언어의 내용이 반영된 결과 • In-context 학습 – 언어 모델 재훈련 코스트가 너무 큼 – ”그럼 말만 잘하는 모델을 만들고 필요 정보는 그 때 그 때 주면 안될까?” – 모델 크기가 충분히 크면 in-context 학습이 가능함 • 지식자료KnowledgeBase + In-context 학습 – 프롬프트 인젝션: 질문에 따라 1차적으로 KB를 검색하고, 해당 데이터를 추가로 프롬프트 형태로 in-context 정보를 주는 방법 – Microsoft Bing, Google Bard 등의 구현체 지식 자료 21

Slide 22

Slide 22 text

• 벡터 저장소 vector storage – 지식자료의 형태 – In-context에 참조할 데이터를 저장하고 필요에 따라 쿼리 – 프롬프트 인젝션을 통해 in-context 학습을 하고 그에 따라 답변 생성 • 사용 이유 – 빠른 텍스트 입출력 – 복잡한 텍스트 데이터 쿼리 지원 – 유연한 확장성 지식 베이스 22

Slide 23

Slide 23 text

• 문장을 원하는 단위로 쪼개는 전처리 도구 • 토큰: 텍스트를 벡터화한 단위 – 의미론적 단위로 쪼갠 후 인덱스에 대응 – 자주 보는 토큰: 형태소 토크나이저 • 한국어 토크나이저 – 1세대: 형태소 분석기 기반 ✓ Mecab (Taku Kudo et al., 오픈소스, 2006) ✓ 한나눔 (KAIST, 1999) ✓ Komoran (Shineware, 2013) – 2세대: 딥러닝 모델 기반 ✓ SentencePiece (Google, 2018) ✓ Khaiii (카카오, 2018) ✓ BERT multilingual (Google, 2019) ✓ KoELECTRA (박장원 외, 오픈소스, 2020) ✓ HuggingFace Tokenizer (HuggingFace, 2020) 23

Slide 24

Slide 24 text

• MLOps 플랫폼/운영 시스템 = – 오케스트레이터 + 스케일러 + 스케쥴러 + 모듈 도구 + 파이프라인 관리 도구 + 사용자 관리 도구 실행기: 파이프라인 시스템 구성 요소 오케스트레이터 스케쥴러 스케일러 컨테이너 MLOps 모듈 파이프라인 관리 도구 컨테이너 MLOps 모듈 VM MLOps 모듈 클러스터 관리 도구 하드웨어 관리도구 파일 스토리지 특성 스토어 파일 스토리지 데이터 스토어 … 유저 인터페이스 사용자 관리 도구 24

Slide 25

Slide 25 text

• 추상화된 파이프라인 예시 (Backend.AI FastTrack의 예) 실행기: 운영 시스템 파이프라인 추상화 25

Slide 26

Slide 26 text

• 컨테이너/VM 오케스트레이터 – 워크로드들을 격리하고 실행 및 배치하는 도구 / 런타임 엔진에 해당 – 컨테이너 운영 오케스트레이터 ✓ Kubernetes (Google) ✓ OpenShift (RedHat) ✓ Helios (Spotify) ✓ Backend.AI / Sokovan (Lablup) – VM 운영 오케스트레이터 ✓ VMWare orchestrator / Tanzu (VMWare) ✓ System Center Orchestrator (Microsoft) ✓ Chef Infra (Chef) ✓ SolarWinds Virtualization Manager (SolarWinds) 실행기: 오케스트레이터 26

Slide 27

Slide 27 text

• Horovod (2018~) – Uber가 개발 / Michelangelo의 일부분 – 분산 처리 및 분산 훈련시 과정시 요구되는 다양한 설정을 자동화해주는 도구 – 다양한 노드간 통신 지원: NCCL (NVIDIA), oneCCL (Intel), MPI • Ray (2018~) – 분산 워크로드를 쉽게 운영할 수 있도록 지원하는 wrapper로 시작 – 추상화를 통한 간단한 적용 지원 – 다양한 도구들의 통합으로 단순한 wrapper 이상의 편의성 제공 실행기: 분산/병렬 처리 도구 27

Slide 28

Slide 28 text

• TensorFlow Extended (2018~) – 각 워크로드를 처리하는 모듈들을 구현해 놓은 결과물 – 데이터 전처리, 검증, A/B 테스트, 서빙용 컴포넌트들 포함 – 높은 성숙도를 보이지만, 거대한 규모로 인하여 컴포넌트 간의 충돌로 인한 어려운 버전업 실행기: 파이프라인 모듈 (일반) https://www.tensorflow.org/tfx 28

Slide 29

Slide 29 text

• TorchX (2021~) – E2E 파이프라인을 만들기 위한 다양한 도구 제공을 목표로 함 – 다양한 컴포넌트가 추가되는 중 실행기: 파이프라인 모듈 (일반) https://pytorch.org/torchx/latest/basics.html 29

Slide 30

Slide 30 text

• 모델 서버 – 모델 파일을 읽어 메모리에 적재하고, 요청을 받아 인퍼런스를 처리함 • 모델 서버 래퍼 – 모델 서버의 사용을 쉽게 만들기 위해 API 등을 붙이는 도구 • 자세한 내용은 뒤에서… 실행기: 모델 서빙 솔루션 30

Slide 31

Slide 31 text

• AirFlow + TensorFlow Extended – Apache AirFlow: AirBnB가 개발한 일반 용도의 워크플로우 관리 플랫폼 – 장점: ETL 보다 훨씬 넓은 범위를 커버함, GCP에서 지원 (Google Cloud Composer) – 단점: MLOps 특화 기능들의 부족. 파이프라인 자원 관리 기능 부재 • KubeFlow – Kubernetes 기반의 MLOps 운영도구 – 장점: TFX 모듈 기반 사용, 클라우드 서비스 (Google Vertex AI 등) – 단점: 온프레미스 설치 시 너무 간략화된 사용자 관리 시스템, 버전업 안정성 이슈 • MLFlow – Databricks에서 만든 MLOps 플랫폼 / Tracking, Projects, Models를 효율적으로 분리하여 지원 – 장점: TensorFlow, PyTorch 등 프레임워크에 의존성 없음 – 단점: 특정 버전의 TensorFlow / Pytorch에 맞춘 지원, 프레임워크의 버전 의존성이 존재 • FastTrack – Backend.AI 기반의 MLOps 플랫폼 – 장점: 다양한 하드웨어 및 시스템 지원. 프레임워크 의존성 없음 – 단점: Backend.AI 의존성 존재 (사용자 시스템 등 공유) 실행기: 오픈소스 MLOps 파이프라인 운영 도구 31

Slide 32

Slide 32 text

하드웨어 구성 요소들 GPU Nodes NVIDIA CUDA AMD ROCm Google TPU Others Fast Network Infiniband Backbone / spine NVLink / NVSwitch NAS / Data Lake Object storage File system storage Distributed file system 32

Slide 33

Slide 33 text

• CUDA (Compute Unified Device Architecture) (NVIDIA, 2008~) – NVIDIA의 GPU로 일반 연산을 하기 위한 병렬 컴퓨팅 플랫폼 라이브러리 – 병렬 연산 및 행렬 연산에 특화 – 딥 러닝 분야에 엄청나게 활용 중 ✓ CUDA가 아니라 그걸로 만든 cuDNN 에 의존적 ✓ 2016~2020년: TensorFlow / PyTorch 모두 GPU기반 딥 러닝 가속을 자체 구현 대신 cuDNN에 사실상 맡겼음 • 장점 – 장기간 기기 호환성 유지 – 텐서 코어 내장 ✓ 혼합 정밀도 (Mixed-precision) 기반 행렬 연산에 특화 – 더 폭넓은 소프트웨어 생태계 (사실상 표준) • 단점 – 개발사 종속성 심화 가속기: NVIDIA CUDA-호환 GPU 33

Slide 34

Slide 34 text

• ROCm (Radeon Open Compute Ecosystem) (AMD, 2016~) – AMD GPU로 일반 연산을 수행하기 위한 라이브러리 • 장점 – 탁월한 고정밀도 연산 성능 (FP32 / FP64) – 정밀도를 요하는 슈퍼컴퓨팅 분야에서 유용 – 오픈소스 • 단점 – CUDA가 아님 (진지한 단점) ✓ 소프트웨어 생태계가 완전히 CUDA로 쏠려 있음 – 매우 약한 하위 호환 지원 – 불안정한 드라이버 스택 가속기: AMD ROCm-호환 GPU 34

Slide 35

Slide 35 text

• TPU (Tensor Processing Unit) (Google, 2018~) – 머신 러닝 워크로드에 특화해 만든 전용 가속칩 – TensorFlow 인퍼런스 기기로 시작 (v1) / 이후 훈련용으로 확장됨 – 인퍼런스용은 i로 끝남. (예: TPUv4i) • 장점 – 강력한 성능 – 거대 모델 훈련시 고성능 달성 / 모델 규모 확장이 쉽고 유리함 • 단점 – 비싸고 할당 받기 어려움 – 성능을 다 이끌어내기 위해서는 TPU 구조에 대한 이해가 필요함 / 특정 워크로드에 최적화됨 – TPU 훈련한 모델을 GPU로 서비스하거나 추가 훈련을 할 경우 호환성 문제를 겪는 경우가 자주 발생 가속기: Google Cloud TPU 35

Slide 36

Slide 36 text

• 다양한 가속기 지원 – CPU 내장 명령어셋 (Intel AMX) 및 라이브러리 (OneAPI) – Xeon 스케일러블 프로세서에 딥러닝 가속 기능 추가 ✓ VNNI (Vector Neural Network Instruction) 명령어셋 – Xeon Max ✓ 램 억세스시 대역폭 부족으로 인한 병목 해결을 위한 패키징 ✓ 128GB HBM을 CPU에 붙임 • Habana Gaudi 2 – 인텔 산하 하바나랩스의 AI 가속기 – 여러 워크로드에서 타사 가속기에 견주거나 능가하는 성능 달성 가속기: Intel CPU / Gaudi 36

Slide 37

Slide 37 text

• Infiniband (1999~, IBTA) – 고성능 컴퓨팅에서 사용되는 컴퓨터 네트워크 통신 표준 – 컴퓨터 간 및 내부 데이터 상호 연결에 사용 – 서버-스토리지, 서버-서버 인터커넥트 또는 스토리지 인터커넥트로 사용 – 최근에는 GPU 인터커넥트로도 사용 • 장점 – 다양한 프로토콜 지원 – 표준 프로토콜 중에서는 가장 빠른 속도 (2.5Gb~400Gb/s) – DMA를 통한 초저지연 전송 • 단점 – 비싸서 자주 보기 어려움… (200Gb/s 짜리는 케이블 한 줄에 백 만원 넘음) – 그로 인한 호환성 문제 네트워크: Infiniband 37

Slide 38

Slide 38 text

• NVLInk (NVIDIA, 2014~) – GPU간 인터커넥트 – SLI (Scalable Link Interface, 3dfx, 1998) 기술로부터 파생 – GPU간 고속통신을 통해 데이터 I/O 속도를 비약적으로 향상 ✓ GPU당 900GB/s, H100 기준 (400+400+100) • NVSwitch (NVIDIA, 2018~) – 다수의 NVLink 를 서로 연결하는 인터커넥트 – 단일 노드 내 NVSwitch (최대 8GPU) 또는 NVLink-NVSWitch 시스템을 통해 인터노드 확장 (Hopper 이상) – NVLink와 동일한 GPU당 900GB/s 의 대역폭을 전체 네트워크에 제공 ✓ 인터노드 연결시 최대 256대 연결 및 57.6TB/s 대역폭 사용 – 단점: DGX 제품군에 우선 포함, 이후 보급 네트워크: NVLink / NVSwitch 38

Slide 39

Slide 39 text

• 파일 기반 스토리지 – 데이터를 파일로 저장하고, 파일 프로토콜 또는 파일 마운트를 통해 공유 – 일반 컴퓨터의 입출력 단위와 동일하므로 편의성이 뛰어남 – 다수의 파일을 접근할 경우 불필요한 프로토콜 부담 발생 • 오브젝트 스토리지 – 메타데이터 + 데이터 번들 (오브젝트)을 묶어 주소로 관리하는 개념 – 네트워크만 되면 파일 프로토콜과 상관 없이 사용 가능 – 접근 권한을 상세하게 설정할 수 있음 – 오브젝트 자체로는 훈련에 사용할 수 없음: 변환하여 일반적인 데이터 형태로 만들어야 함 – 실질적 표준: Amazon S3-like 데이터 스토리지 39

Slide 40

Slide 40 text

• 분산 파일 시스템 – 다수의 클라이언트가 데이터 입출력을 수행하기에 최적화된 파일 시스템들 – 데이터를 분산하여 저장하고, 마찬가지로 분산된 클라이언트에 데이터 제공 – HDFS (Hadoop Distributed File System) – GlusterFS, CephFS, LustreFS (DDN), WekaFS 등 • 장점 – 확장성 / 속도 / 리던던시 제공 / 대규모 데이터 관리 시 가격 경쟁력 등 – 샤딩: 다수의 연산 노드가 동시에 다른 데이터를 읽어 수행할 때 필수적 ✓ GPU 1000대에 각각 1GB/s의 속도로 데이터를 읽어도 스토리지엔 1TB/s 의 속도가 필요함 • 단점 – 보안 / 데이터 유실 등 분산 파일 시스템 40

Slide 41

Slide 41 text

• 모델+데이터가 작은 경우 – 오브젝트 저장소로 충분함 – 필요할 때 불러오고 훈련하는데 드는 비용이 크지 않음 • 모델이 큰 경우 – 분산 파일 시스템 추천 – 파일 기반 스토리지 또는 오브젝트 스토리지 중 모델 환경에 맞는 스토리지 선택 – 데이터 파일 갯수가 적은 경우 / 데이터 청크가 큰 경우: 파일 기반 스토리지 – 파일의 seek 을 활용 가능 – 데이터 갯수가 많고 비정형인 경우: 오브젝트 스토리지 – 메타데이터 활용 쉬움 • 그럼 코드는? – 파일 기반 스토리지가 유리함 ✓ 오브젝트 스토리지에 코드를 관리하는 잇점이 없음 ✓ 버전 컨트롤이 필요한 경우 git 등의 VCS 권장 스토리지 선택 41

Slide 42

Slide 42 text

톺아보기: 소프트웨어 구성 요소들 Corpus Language Corpus Knowledge base Task-oriented corpus Mixer Tokenizer English Korean Morpheme Runtime Distributed executor Experiment Monitor 42

Slide 43

Slide 43 text

톺아보기: 하드웨어 구성 요소들 GPU Nodes NVIDIA CUDA AMD ROCm Google TPU Others Fast Network Infiniband Backbone / spine NVLink / NVSwitch NAS / Data Lake Object storage File system storage Distributed file system 43

Slide 44

Slide 44 text

분산 훈련 하기 44

Slide 45

Slide 45 text

Slide 46

Slide 46 text

• 빠른 훈련 속도 – 분산 정도를 높일 경우 훈련 속도가 빨라져야 함 • 최소한의 추가적인 수고 – 코드 수정 최소화로 스케일 달성 • 재현 용이성 – 낮은 시스템 의존성 모델 훈련 분산 처리 목표 46

Slide 47

Slide 47 text

분산 처리 지점 단일 훈련 단계 분할 데이터 파이프라인 분산 파라미터 탐색 장점 단점 단일 코드 기반 분산처리 난이도 낮음 성능 향상 대비 연산자원이 너무 많이 필요 노드-데이터 파이프라인 대역폭 단일 노드대 효과 적음 멀티노드 분산처리 결합 필요 데이터 소스 대역폭 한계 극복 멀티쓰레딩이 쉬움 어려움 계산 그래프내 Reduce시 타이밍 이슈 잘못 쓰면 더 느려짐 모델이 클수록 효과가 큼 분산 처리시 발생하는 추가 비용이 상대적으로 적음 거대 모델 분할 GPU 유휴 시간 비율 증가 전체 훈련 시간 증가 큰 딥 러닝 모델 훈련 가능 (Tensor Parallel) 47

Slide 48

Slide 48 text

데이터 병렬화 모델 변수 업데이트 장치 0 장치 1 장치 2 장치 3 Input shard 0 Input shard 1 Input shard 2 Input shard 3 48

Slide 49

Slide 49 text

• 값을 reduce하고 그 결과를 전체 프로세스로 전파 • 역전파 단계에서 그라디언트 교환을 통해 전체 동기화 – “All” : 모든 기기에서 모든 기기로 – “reduce”: 합 / 평균값 링구조 All-reduce ΔvA2 ΔvA3 ΔvA1 장치 0 장치 1 ΔvA0 장치 3 장치 2 49

Slide 50

Slide 50 text

멀티노드 / 멀티 GPU 환경 Worker Node Worker Node Worker Node Worker Node 50

Slide 51

Slide 51 text

• Horovod (2018~) – All-reduce시 요구되는 다양한 설정을 자동화 – 프레임워크에 영향받지 않음: TensorFlow, PyTorch, MXNet 등 모두 지원 – 다양한 노드간 통신 지원: NCCL (NVIDIA), oneCCL (Intel), MPI • Ray (2018~) – 추상화를 통한 간단한 분산 훈련 적용 지원 – 병렬화 및 연산 자원 최적화에 강점 • DeepSpeed (2020~) – PyTorch용 분산 훈련 라이브러리 – 모델 분산 및 적재 오프로드에 최적화 • 필요에 맞게 사용하면 됨 – 몇가지는 뒤에서 또 등장할 예정 분산 훈련 도구들 51

Slide 52

Slide 52 text

거대 언어 모델 파인 튜닝 52

Slide 53

Slide 53 text

• 거대 모델의 시대 – Feature 크기의 증가: ~1M – 모델 사이즈의 증가: 320GB (GPT-3, 2020) ~ > 1TB – 데이터 먹이기: GPUDirect Storage / Magnum IO - 초당 120GiB 이상 • “서비스가 불가능한” 딥 러닝 모델들 – 정밀도 희생, 압축, 미니모델 그 어떠한 방식을 써도 줄일 수 없는 한계 크기 ✓ 예) Pathways: SOTA 0.1% 향상마다 8천만원 ✓ 모델 압축 시 발생하는 정확도 하락폭 – FP64, FP32, BF16, FP8, INT4, INT3, INT2…INT2? 안 들어가져요 53

Slide 54

Slide 54 text

• 즐길 수 없다면 피하라 – 서비스가 가능한 모델로의 관심 전환 • Pathways가 있지만 RankT5 발표 – Google, 2022년 11월 – 왜? 다시 T5? – MegatronLM의 예 ✓ 쓰이는 모델들이 따로 있더라 – PaLM 2 (2023.5) 의 경우 아예 작은 모델도 발표 (Gecko) • 실질적인 한계: 16GB~32GB – 인퍼런스용 GPU 메모리의 마진 포인트 – NPU 번들 메모리 최대 크기 – NVIDIA T4, A4000… – 그래서 어느 정도의 크기를? -> 서빙 섹션에서 다룹시다 생성 모델과 “적정 모델 크기” 적정모델 54

Slide 55

Slide 55 text

• 생성 모델들의 약진과 AI 서비스 – Stable Diffusion 기반 모델 – GPT-2/3mini 기반 언어 모델 – 16GB 한계 안에서 돌아가는 전문가 시스템 구현 • 현실과의 타협 – 42는 없다 – 불가능하다고 생각된 많은 문제를 해결 가능 – 눈앞으로 다가온 전문가 AI 서비스 대중화 – EleutherAI / Stability.ai의 접근 방법 ✓ 우린 언어 모델도 할 수 있다! 16기가로! ✓ 어쨌든 손에 닿는 것들을 해야! 생성 모델과 “적정 모델 크기” 생성모델 AI회사답지! 55

Slide 56

Slide 56 text

• 좀 덜 거대한 언어 모델 – sLLM 등의 요상한 이름들이 등장 ✓ Small Large Language Model 이라니 – 모든 일에 꼭 창발 현상이 필요한 것은 아니다 – 적절히 결과가 잘 나오면 되는것 아닐까? Size does not matter sLLM… 모로가도 서울로! 56

Slide 57

Slide 57 text

• 좀 덜 거대한 언어 모델 – sLLM 등의 요상한 이름들이 등장 – 모든 일에 꼭 창발 현상이 필요한 것은 아니다 – 적절히 결과가 잘 나오면 되는거 아닐까? • 적정 모델 크기 찾기 – 그래서 몇 개? – 3개월동안 10,000여 개 ✓ 기반 모델 및 파인튜닝 모델 다 합쳐… ✓ 5월~7월 Size does not matter 57

Slide 58

Slide 58 text

상업적으로 사용 가능한 공개 언어 모델들 License Data Architecture Weights Size Checkpoints Language Meta Llama2 Llama license Open Open Open 7, 13, 70 Yes English / Multilingual EleutherAI Pythia Apache 2.0 Open Open Open 7, 12 Yes English EleutherAI Polyglot GPL-2.0 Open Open Open Yes English / Multilingual GPT-J MIT Open Open Open 6 Yes English Databricks Dolly 2 Apache 2.0 Open Open Open 7, 12 Yes English Cerebras- GPT Apache 2.0 Open Open Open 7, 13 Yes English / Multilingual StableLM CC BY-SA- 4.0 Open Open Open 3, 7, (15, 30, 65, 175) Yes English Mosaic MPT Apache 2.0 Open Open Open 7, 30 Yes English Falcon GPT Apache 2.0 Open Open Open 7, 40 Yes English 58

Slide 59

Slide 59 text

• 수십~수백대의 연산 노드 사용 • 노드간 연결 네트워크 – 데이터 플레인 – 서비스 플레인 – GPU 플레인 – 인터노드 분산 훈련 플레인 • 개발 및 서비스 환경 자동화 – 예시: Backend.AI 를 사용하는 경우 분산 연산 환경 59

Slide 60

Slide 60 text

• 체크포인트 기반 파인 튜닝 – 모델 코드와 데이터 포맷이 주어진 경우 – 추가 데이터를 사용하여 딥 러닝 모델을 계속 훈련 가능 • 문젯점 – 원 모델 훈련이 요구했던 연산 자원 종류 / 연산 자원량이 필요 – 자원이 적을 경우 ✓ 훈련 속도가 느려짐 ✓ 모델을 GPU 메모리에 올릴 수 없는 경우 발생 – 최소한 체크포인트 적재가 가능한 만큼의 GPU 메모리 필요 – CUDA / ROCm 호환성이 발생하는 경우들 존재 ✓ 혼합 정밀도를 사용하는 모델에서 심심치 않게 발생 파인 튜닝하기: 체크포인트 기반 추가 학습 60

Slide 61

Slide 61 text

• LoRA (Low-Rank Adaptation of Large Language Models) – 사전 훈련된 모델 가중치를 고정 – Transformer 아키텍처의 각 레이어에 학습 가능한 랭크 분해 행렬을 삽입 ✓ 훈련 가능한 레이어들을 별도로 붙이고 추가 훈련을 통해 학습시킴 – 하위 작업에 대한 학습 가능한 매개변수 수를 크게 줄임 • 적용 – 일반 도메인 데이터 기반의 대규모 사전 훈련 모델을 특정 작업이나 도메인에 적용 할 때 – 원래 가중치를 고정한 채 랭크 분해 행렬 쌍을 학습함으로써 학습 가능한 매개변수 수를 크게 줄임 – 특정 작업에 적합하게 조정된 대규모 언어 모델의 저장 요구 사항을 크게 줄임 – 추론 대기 시간 없이 배포 중 효율적인 작업 전환 가능 • 단점 – 모델 자체를 추가 훈련할 때의 성능은 넘을 수 없음 파인 튜닝하기: LoRA http://kimsungmo.com 61

Slide 62

Slide 62 text

• Meta의 Llama 공개 (Meta, 2023. 2. 24) – 연구 목적으로 weight / checkpoint 공개 (7B, 13B, 33B, 65B) – ＂오픈 데이터 셋만으로도 충분히 좋은 모델을 만들 수 있다!” • 체크포인트 유출 (2023. 3. 3) – 토렌트를 통해 weight, checkpoint가 모두 유출됨 • Alpaca 모델 공개 (Stanford, 2023. 3. 13) – Llama 모델을 52000 질문/답변 공개 데이터로 파인튜닝한 결과 공개 – 데이터 공개함. Meta 허가 할 경우 모델도 공개 의향 표명: 그러나 허가받지 못함 • Alpaca-LoRA 모델 공개 (2023. 3. 14) – Alpaca 모델의 재현을 위해 Alpaca 공개 모델을 LoRA로 파인 튜닝 • Vicuna-13B 공개 (2023. 4. 3) – Google Bard 급의 성능을 내는 파인 튜닝 모델 • 라이선스 위반 문제 – 엄청나게 강력한 라이선스가 걸려있음 (Llama License) – 유출 이후 라이선스가 무시 되는 중: Meta의 적극적 차단에서 수동적 차단으로 (도저히 다 잡을 수가 없음…) Llama 사태 62

Slide 63

Slide 63 text

• 공공재가 된 Llama – Llama 기반의 instruct fine-tuning 전성시대 – 사전 모델 훈련을 하기 힘든 개인, 기업, 연구소들이 전부 달려듬 • Meta의 Llama 2 공개 (Meta, 2023. 7. 16) – 거의 제약이 없는 weight / checkpoint 공개 (7B, 13B, 70B) ✓ (34B는 아직 공개 전) – 상업화에도 (거의) 자유롭게 사용 가능 ✓ 월 액티브 유저 7억 명 미만인 경우 • 이 조건에 해당되는 회사들은 대개 자체 모델이 있음… ✓ Microsoft 및 Alibaba에서 상업화 진행 중 ✓ (래블업에서도 8월 파인튜닝 파이프라인 기능과 서빙을 묶어 공개) Llama 사태 (2) 63

Slide 64

Slide 64 text

• Dolly 1.0 (3월 28일) – Databricks의 모델 / GPT-J 6B 모델 기반 파인튜닝 – 비상업적 라이선스 / 데이터가 연구용으로만 가능 – Alpaca와 같은 방식으로 훈련하되, 베이스 모델로 GPT-J 6B 사용 – 실사용 보다는 데모에 가까움 • Dolly 2.0 공개 (4월 12일) ✓ Alpaca 데이터셋을 대체하는 자체 데이터 셋도 함께 공개 ✓ databricks-dolly-15k dataset • 파인튜닝 – DeepSpeed 사용 – 모델 및 코드: https://github.com/databrickslabs/dolly.git – 파인튜닝 데이터셋:https://huggingface.co/datasets/tatsu-lab/alpaca • 상세 내용은 supplement를 참고 예제: Dolly 훈련 / GPT-J 파인튜닝 Llama GPT-J Dolly Alpaca Alpaca dataset 64

Slide 65

Slide 65 text

거대 언어 모델 사전 훈련 65

Slide 66

Slide 66 text

• 거대 언어 모델 – 실용화할 타이밍은 아님 – “Attention is all you need” (Google, 2017) – Stable Diffusion 과 ChatGPT가 가져가 버린 것 ✓ 나도 한 입만… ✓ 이제 K- 나올 차례 ✓ 그런데 전세계에서 다 나오는 중이다. A-, B-, C-, … J-… • 예: BritGPT – 힌튼 교수의 구글 퇴사 (5월 2일) ✓ 하고 싶은 말이 많아 퇴사하셨다고.. ✓ “다들 너무 뛰기만 하는거 아니냐?” Size does matter LLM! 진심으로 그길을? 66

Slide 67

Slide 67 text

• 한 발 먼저 온 현실 – 42는 없지…만 비슷하게 만들 수는 있다! – 사람들이 이미 봐 버렸다 • 콩 심은데 콩 나고 팥 심은데 팥 난다 – 어느 정도까지 줄여야 거대 언어 모델의 특징이 살아 있을까? – 어떻게 모델을 만들어야 가능할까? ✓ Chinchilla law ✓ 초고품질 데이터 기반 모델 • 1B로 10B 이길 수 있다! ✓ 특이한 아이디어들이 다양하게 나오는 중 Size still does matter 67

Slide 68

Slide 68 text

• MegatronLM[1] – NVIDIA의 Applied Deep Learning Research 팀 개발 – 대규모 트랜스포머 언어 모델 훈련용 • 장점 – 모델 병렬화 (텐서, 시퀀스 및 파이프라인) – 다중 노드 기반 사전 훈련 기술 – 혼합 정밀도 (Mixed-precision) • 제공 – GPT, BERT 및 T5 등의 사전 훈련된 모델 및 도구 제공 – 파인튜닝 및 추가 훈련으로 모델 개발 지원 • NeMo-Megatron – 유료 버전 MegatronLM [1] https://github.com/NVIDIA/Megatron-LM [2] https://michaelbaystransformers.fandom.com/wiki/Megatron 68

Slide 69

Slide 69 text

• DeepSpeed[1] – Microsoft의 훈련 최적화 라이브러리 – “더 적은 자원으로 더 큰 모델을 훈련할 방법이 없을까?” • 목표: 대규모 처리를 가능하도록 하기 위한 기술 – 대규모 멀티 노드 시스템에서 워크로드 분산을 위한 기법들 도입 ✓ 혼합 정밀도 연산 자동화 ✓ 모델 / 파이프라인 병렬화 등 – 주요 특징 : ZeRO ✓ 연산량 및 메모리 사용 감소를 위한 기술 DeepSpeed [1] https://www.deepspeed.ai/ 69

Slide 70

Slide 70 text

• 대규모 분산 딥러닝을 위한 메모리 최적화 기술 – 다양한 연산 하드웨어에 걸친 워크로드 분배: CPU, GPU… – 다양한 모델 훈련 상태를 분할 처리 ✓ Weight, Gradient, Optimizer 상태 등 – 이를 통해 각 GPU의 메모리 사용량을 줄여 더 큰 모델을 훈련 가능하게 함 • ZeRO 1 – 옵티마이저 상태를 프로세스 간 별도로 분할. 각 프로세스는 자신의 파티션만 업데이트 • ZeRO 2 – 모델 가중치 업데이트에 사용하는 축소된 32비트 그라디언트를 – 현재 프로세스에 해당되는 옵티마이저 상태 파티션에 해당하는 그라디언트만 각 프로세스에 유지 • ZeRO 3 – 모델 가중치와 활성화도 추가적으로 프로세스 간에 분할 ZeRO (Zero Redundency Optimizer) [1] https://www.deepspeed.ai/tutorials/zero/ 70

Slide 71

Slide 71 text

• ZeRO Infinity – ZeRO의 개선 버전: 목표: 1조~10조개 이상의 매개변수로 구성된 모델 훈련용 – 모든 장치 및 스토리지를 동원하여 전체 메모리량 확보 ✓ 연산 장치: GPU, CPU ✓ 스토리지: NVMe – 모델의 각 계층을 모든 데이터 병렬 프로세스에서 분할하고 – 분할한 파티션을 해당되는 데이터 병렬 NVMe 장치에 배치 – GPU 및 CPU에서 각각 순전파/역전파와 가중치 업데이트에 필요한 데이터 이동 조정 • 어디까지 써야 하나? – 사용 중인 자원의 규모에 따라 다름 – ZeRO는 수렴 속도를 희생해서 모델 규모를 올리는 방식임 – 잘 모르겠으면 ZeRO-1부터 시작 ZeRO (Zero Redundency Optimizer) 71

Slide 72

Slide 72 text

• GPT-4가 나왔는데 왜 GPT-2? – GPT-2와 GPT-3의 차이는 크기임 ✓ GPT-3: 96 어텐션 레이어, (96x128) 차원 헤드 – GPT-3와 GPT-4의 차이는 아직 미공개 ✓ 크기상 차이는 크지 않은 것으로 추정 중 ✓ Instruct-led 의 차이? – GPT-2 기반으로 대량의 데이터와 크기를 확대하여 GPT-3 – GPT-3에 RLHF 등을 추가하여 GPT-3.5 등 • 따라서 – GPT-2 분산 훈련은 이후 다양한 기반 모델foundation model을 만드는 바탕이 됨 – 기반 모델? GPT-2 훈련 72

Slide 73

Slide 73 text

• 기반 모델 – 라벨링되지 않은 대규모 데이터를 자기지도 방식으로 학습한 거대 AI 모델 – 광범위한 데이터 대상으로 대규모 사전학습 수행 – 다양한 용도의 임무에 맞추어 파인튜닝 또는 in-context 러닝 후 바로 사용 • 왜 큰 모델을? – 닭 잡는데 소 잡는 칼인가? – 필요한건 닭고기만큼인데, 모든 임무들의 크기가 소 만 하다. – 임무는 ✓ 논리 구조에 따라 맥락을 이해하고 ✓ 그 과정이 인간과 충분히 상호작용 하에 이루어져야 하는데 ✓ 이 두 가지가 엄청나게 큰 일임 기반 모델 Foundation Model 73

Slide 74

Slide 74 text

• GPT-2 훈련하기 – Supplement 를 참고해서 훈련해 봅시다! • Megatron-DeepSpeed로 T5 훈련하기 – 스크립트의 일부를 수정해서 바로 T5를 훈련할 수 있음 – pretrain_t5.py 참조 및 앞에서 만든 run_deepspeed_gpt2.sh 를 수정하여 바로 훈련 – 참고: 2022~2023년 상업적으로 사용하는 실질적인 모델은 T5임. (220m ~ 11B 매개변수) • 한국어 데이터로 GPT-2 훈련하기 – 다양한 한국어 말뭉치들이 존재함 – 이미 가공된 것도 있고, 가공되지 않은 말뭉치도 있음 – 끝까지 못 돌려보더라도 일단 한 번 모델 epoch 을 한 번 돌려 보는 것으로 • 해 보면 알게 되는 것 – 거대 언어 모델의 트러블슈트는 두 가지임 – 하드웨어 트러블, 이유를 모를 cost 튐 해결 기반 모델 만들어 보기 74

Slide 75

Slide 75 text

• MosaicLM의 MPT 훈련의 예 – 하드웨어 트러블 해결의 문제 • GPT-4 훈련 관련 레포트들 – GPU 가동률이 40% 미만 – 대부분의 이유는 체크포인트부터 재시작 거대 언어 모델 훈련: 트러블슈트 [1] https://www.mosaicml.com/blog/mpt-7b MPT-7B 훈련시의 시간에 따른 훈련 진행과 하드웨어 불량 기록[1] 75

Slide 76

Slide 76 text

거대 언어 모델 서빙 76

Slide 77

Slide 77 text

• 모델 개발 완료 ≠ 모델 서비스 • 고려할 점 – 모델 크기 및 모델 배포 – GPU-GPU 인터커넥트 네트워크 – 자원 배치 정책 – 스케일링 모델을 ‘서비스’ 하기 77

Slide 78

Slide 78 text

• 하드웨어로 생기는 제약 – 최대한 한 장에 모델 하나를 올리도록 – 그렇지 않으면 N장에 올릴 수 있도록 • 예 (원본 모델 서비스) – 12B 언어모델: A10, L4 – 30B 언어모델: A100 – 45B 언어모델: A100 x 2 • FP16 vs. FP8 – FP16 또는 원본 모델 기반 서비스 – 말이 이어질 수록 컨텍스트가 요상하게 깨지는 현상이 있다. 모델 크기 GPU Memory H/W Memory Bus CUDA Core Model (FP32, 16) 10GB NVIDIA RTX 3080 (10GB) NVIDIA RTX 3080ti 320bit 320bit 8704 10240 5B 10B 12GB NVIDIA A2000 NVIDIA RTX 3080 (12GB) NVIDIA RTX 4070 192bit 384bit 192bit 3584 8960 5888 6B 12B 20GB NVIDIA A4500 NVIDIA RTX 3080ti (20GB) 256bit 320bit 8960 10240 10B 20B 24GB NVIDIA A10 NVIDIA A30 NVIDIA L4 384bit HBM2e 3072bit 192bit 9216 3584 7680 12B 24B 40GB NVIDIA A100 (40GB) HBM2e 3072bit 6912 20B 40B 48GB NVIDIA A40 NVIDIA A6000 384bit 384bit 10752 10752 24B 48B 80GB NVIDIA A100 (80GB) NVIDIA H100 HBM2e 3072bit HBM2e 5120bit 6912 14592 40B 80B 78

Slide 79

Slide 79 text

• NVIDIA 하드웨어 지원 – CUDA Compute Capability 7.5 이상부터 지원 – Turing 아키텍처 이후 ✓ 일반 대상 Geforce 20XX 계열 / 엔터프라이즈 계열 RTX / 데이터센터 계열 A시리즈 이상 ✓ 잘 모르는 경우: 2019년 이후 발매된 대부분의 모델 • 소프트웨어 양자화 라이브러리 – Bitsandbytes (8bit 양자화) – GPT-Q (3/4bit 양자화) • 문젯점 – 트랜스포머 아키텍처가 양자화에 적합하지 않음 ✓ 긴 디코더 길이에 따른 ＂오차 누적”의 문제 – 실서비스: 양자화를 적용하지 않는 사례가 훨씬 많은 상황 “적정 모델 크기”를 위한 양자화 79

Slide 80

Slide 80 text

• 모델 서버와 모델 체크포인트/모델 파일을 별도 관리 – 장점 ✓ 쉬운 모델 업데이트 ✓ 용이한 모델 서버 버전업 – 단점 ✓ 배포의 유연성 감소: 띄울때 • 모델 서버 + 모델 체크포인트/파일을 컨테이너 이미지화 – 장점 ✓ 실행가능단위로 배포되므로 쉬운 설정 – 단점 ✓ 모델 서버 교체 및 최적화 과정의 번거로움 ✓ 거대한 컨테이너 이미지 파일 크기로 인한 배포 트래픽 증가 모델 배포 80

Slide 81

Slide 81 text

모델 서빙 솔루션 TensorFlow Serving Google, 2016~ Triton Inference Server NVIDIA, 2018~ OpenVINO Intel, 2018~ ONNXRuntime Microsoft, 2018~ RedisAI RedisAI, 2019~ TorchServe Facebook, 2020~ Seldon Core SeldonIO, 2018~ Kserve Google, 2020~ TensorFlow PyTorch 멀티모델 포맷 지원 모델 서버 래퍼 K8s 전용 CUDA GPU 특화였으나 현재는 멀티 백엔드 지원 인텔 CPU 특화 Triton OpenAI, 2023~ 81

Slide 82

Slide 82 text

마무리 82

Slide 83

Slide 83 text

• 편견 – Microsoft Tay (2021) 및 Google LaMDA (2022) – Amazon Rekognition 의 인종차별 문제 (2023) • 안전성 – 현존하는 거의 모든 언어 모델 jailbreak (7월 27일) ✓ 가이드 월을 뚫고 뭐든 물어볼 수 있음 • 공정성 – 아마존 면접 AI 의 인종 편향 (2020) – 구글의 Genesis (뉴스 작성 AI) 테스트 (2023년 7월 19일) 대중 당면 과제 https://arxiv.org/abs/2307.15043 83

Slide 84

Slide 84 text

• 모바일 게이트키퍼들 – 구글 안드로이드+PaLM 2 ✓ 가장 작은 Gecko의 파라미터 수: 14.7B (사실 모바일에 넣기엔 아직도 매우 큼…) – 애플 iOS의 언어 모델 ✓ 시리: 세계에서 가장 강력한 AI 브랜드 ✓ ‘언제냐’만 남아 있음 • Meta + – 메타의 페르소나 봇 (9월 예정) ✓ Llama 2 공개 후 바로 발표 – Microsoft Azure 서비스로 제공 – Alibaba 에서 Llama 정식 서비스 – 클라우드 업체들의 합종연횡 AI 시장: 눈치게임 • 오픈소스 LLM들 – Mosaic MPT 및 Falcon 제공으로 기반 모델을 손에 쥠 – Llama 2 로 클라우드 업체들과 동일한 경쟁선상에 섬 – 다양한 다국어 기반 모델들 훈련 및 공개 중 – 저렴해지는 파인 튜닝 과정 ✓ (래블업은 기관내 튜닝 및 서비스 과정을 자동화해서 제공 중…) • 국내의 기반 모델 시도 – LG, 네이버, KT, 카카오 등 – 11B~45B 사이의 기반 모델 개발 중 – 아직 결과물을 공개한 곳이 없어서 판단이 어려움 ✓ 다음 기회에… 84

Slide 85

Slide 85 text

• 생성 AI의 고도화 – SDXL 1.0 (7월 29일) ✓ Stability.ai 의 새 이미지 생성 모델 • 멀티모달 – 구글 RT-2 발표 (7월 31일) ✓ 다양한 센서 데이터를 시각 언어 모델과 엮어 자체적인 판단을 하고 움직이는 모델 ✓ PaLM-e 나온지 석 달 밖에 안됐는데… 기술적 도전 https://arstechnica.com/information-technology/2023/07/googles-rt-2-ai-model-brings-us-one-step-closer-to-wall-e/ 85

Slide 86

Slide 86 text

• 규제 – Frontier Model Forum: 자율 규제를 위한 포럼 창설 ✓ 구글, 마이크로소프트, OpenAI 및 Antrophic 등 ✓ 저작권, 딥페이크 및 사기등에 대한 자율 규제 추진 – EU의 AI 법 입안 ✓ 자율에 맡겨둘 수 없다 ✓ 빅테크와 오픈소스 진영의 규제 분리 주장 (7월 26일) 사회적 도전 https://venturebeat.com/ai/hugging-face-github-and-more-unite-to-defend-open-source-in-eu-ai-legislation/ https://www.theverge.com/2023/7/26/23807218/github-ai-open-source-creative-commons-hugging-face-eu-regulations 86

Slide 87

Slide 87 text

• 2023년 7월 21일 앤드류 응 세미나 중 질문 드린 내용 • 이 더 큰 팜 만들고 계속 큰 모델 만드는 사이클은 언제 끝날까? • 답변 – 현재 AI 분야는 거의 인간이 할 것이 없다. 고가의 GPU를 엄청나게 산다. 왜? – 유저 한 명, 한 시간당 몇 센트의 인퍼런스 비용으로 텍스트 생성 가능. 엄청 비싸긴 한데, 규모가 되면 말이 된다. – 아직 GPU를 갈아 넣는 것이 사람보다 싸다. 이 비용 불균형이 유지되는 동안 사이클이 계속 될 것이다. 마치며 87

Slide 88

Slide 88 text

감사합니다 [email protected] https://www.facebook.com/lablupInc Lablup Inc. https://www.lablup.com Backend.AI https://www.backend.ai Backend.AI GitHub https://github.com/lablup/backend.ai Backend.AI Cloud https://cloud.backend.ai 88