[3-1] A Survey of Large Language Models - 다양한 LLMs부터, Data, Architecture, Training 까지

업데이트:

Language Model

  • Statistical LM (SLM)
  • Neural LM (NLM)
  • Pretrained LM (PLM)
  • Large LM (LLM)

[1] Resources of LLM

LLM

GPT series

  • (1) training decoder-only Transfer (2) scaling up the size of language models
  • early explorations
    • decoder-only transformer 구조 덕분에 unsupervised learning 가능 & 다양한 task를 한번에 처리할 수 있게 됨
  • capacity leap
    • GPT1,2 → GPT3 로 넘어오면서 model capacity를 확 키웠음
    • 이때부터 in-context learning (ICL)이 잘됨
      • → LLM을 teach (instruct)하게 가능해진다는 것
  • capacity enhancement
    • training on code data
      • → 모델의 reasoning 성능을 높임. CoT 도 더 잘됨
    • human alignment
      • InstructGPT: GPT-3 모델을 human alignment에 맞게 finetuning (3 stage RLHF)

LLaMA series

  • LLaMA 는 성능도 좋고 opensoure 임
    • Llama를 instuction tuning + continual pretraining 하려는 움직임이 많음
      • 특히 LLaMA → non-english로 adaptation하려고 original vocab을 extend 하거나 target language data로 fine-tuning 하려는 움직임도 많음
    • architecture
      • (1) ReLU 대신 SwiGLU (2) PE 대신 RoPE (3) LN 대신 RMSNorm
  • Vicuna: LLaMA를 sharedGPT로 부터 수직한 user 데이터로 fine-tuning하는 모델. 이후 multimodal 모델로 발전
    • → LLaVA, miniGPT4, InstructBLIP,

Others

  • Mistral
  • PaLM Family
  • FLAN

  • Gopher

[2] Data

.    

2.1 Data Collection

2.2 Data Preprocessing

  • Quality Filtering
    • (1) classifier-based
      • binary classifier를 훈련시킨 후 분류
      • but 고퀄의 데이터를 실수로 지우는 경우도 많음 (→ pretraining corpus의 diversity를 훼손)
    • (2) heuristic-based
      • BLOOM, Gopher 같은 모델은 heuristic하게 제거 (well-designed rules에 따라 low qual text를 분류)
        • language based filtering: LLM으로 필터링
        • metric based filtering: eval metric으로 이상한 문장 필터링
        • statistic based filtering
        • keyword based filtering: HTML tags, hyperlink 와 같은 noisy한 데이터 제거
  • De-duplication
    • sentence level: repetitive pattern을 만들 수 있기 때문에 반복된 단어나 phrase는 제거해야함
    • document level
    • dataset level
    • https://tech.scatterlab.co.kr/deduplication/
  • Privacy reduction
    • personally identifiable information (PII)를 제거해야함
  • tokenization
    • word-based tokenization → subword tokenizers (transformer 계열부터 이를 많이 사용)
    • Byte-Pair Encoding (BPE) tokenization
      • subword segmentation 알고리즘 (기존에 있던 단어를 분리한다.)
      • character 단위에서 자주 보는 문자들끼리 merge 하여 vocab을 서서히 만들어내는 bottom-up 방식. 미리 정의된 vocab size에 도달할 때까지 께속 이 과정 반복
      • 미등록 단어(out-of-vocabulary, OOV)에 대해 robustness를 제공함
        • 단어를 더 의미있는 단위인 subword 단위로 분해 (형태학적 분해) 하기 때문에 OOV 단어도 유사한 패턴의 subword로 토큰화 가능
      • multilingual corpus을 잘 처리
        • 언어 독립적인 토큰화 - 일관된 방식으로 token화를 잘함
        • 다양한 언어는 subword를 공유하는 경우도 많은데, BPE는 이를 잘 처리
      • GPT-2, BART, LLaMA 등에서 사용
    • WordPiece tokenization
      • BPE랑 유사하나, merge 할 때 likelihood 기반 방식을 사용
      • merge) language model을 훈련시킨 후, training data의 likelihood를 최대화하는 방향으로 merge
      • BERT, DistilBERT
    • Unigram tokenization
      • 큰 vocab에서 필요없는 token들을 하나씩 제거하는 알고리즘
      • trained unigram language model을 활용해서 최적의 단어를 tokenization → 이후 expectation-maximization (EM) 알고리즘으로 unigram의 확률 추정 및 language model update

2.3 Data scheduling

Data Mixture

  • increasing the diversity of data sources
  • optimizing data mixtures
    • (1) target downstream task가 있을 때, feature space에 잘 근사하도록 pretraining data을 selecting (2) downstream task 에 긍정적인 영향을 주는 data 채택 (3) …
    • ex) DoReMI

Data Curriculum

  • Coding
    • CodeLLaMA: LLaMA2 → 추가 학습 (2T general tokens → 500B code-heavy tokens)
    • CodeLLaMA-Python (2T general tokens → 500B code-heavy tokens → 100B Python-heavy tokens)
  • Mathematics
    • Llemma: CodeLLaMA-Python (2T general tokens → 500B code-heavy tokens → 10(2T general tokens → 500B code-heavy tokens → 50∼200B math-heavy tokens).
      • Note that the pre-training data of Llemma also contains 5% general domain data as a form of regularization.
  • Long context
    • RoPE-based LLM의 position embeddings 채택
    • CodeLLaMA further extends the context window of LLaMA 2 (2.5T tokens with 4K context window → 20B tokens with 16K context window)
    • LongLLaMA also achieves longer context window with the help of external memory and a unique training objective (1T tokens with 2K context window → 10B tokens with 8K context window).

[3] Architecture

3.1 architecture

Encoder-decoder Architecture

  • vanilla Transformer
    • encoder: multi-head self-attention (input seq → encoding → latent representations)
    • decoder: 이 representation들에 대해 cross-attention. auto-regressive 하게 생성

Casual Decoder Architecture

  • 최근 LLM에서 가장 널리 사용되는 구조. input과 target 시퀀스를 구분 없이 처리하며, causal masking pattern으로 인해 이전 토큰에만 condition됨
  • unidirectional attention mask
    • 각각의 input token이 past tokens랑 자신만 attend 가능
    • 이후 input & output token은 decoder로 들어가서 처리
  • GPT series
    • 특히 GPT-3는 이 architecture가 in-context learning에 매우 효과적임을 보임

Prefix Decoder Architecture (non-casual decoder only)

  • decoder-only 모델이 입력/컨디셔닝 텍스트에 대해 더 풍부한 non-causal representation을 만들 수 있도록 attention mask를 수정한 구조
    • → prefix token에 대해서는 bidirectional attention을 수행 (encoder-decoder 모델처럼)
    • → generated token에 대해서는 unidirectional attention을 수행
  • 최근에는 scratch 부터 pretraining을 하지 않고, causual decoder를 학습시키다가 training 가속화를 위해 prefix decoder를 학습시키는 연구도 진행됨
    • ex) PaLM → U-PaLM

Mixture-of-Experts (MoE)

  • LLM 아키텍처에 Mixture of Experts(MoE)를 활용하기 글 참고
    • 하나의 레이어 또는 연산(예: 선형 레이어, MLP 또는 attention projection)의 계산을 여러 개의 “전문가(expert)” 하위 네트워크로 분할하는 신경망의 아키텍처 패턴
    • (1) expert의 하위 네트워크
    • (2) routing 알고리즘
  • computational cost를 유지하면서 model parameter를 scale up할 수 있음. experts 수를 늘리거나 total param을 늘리면 성능이 향상됨
  • ex) Mixtral 8x7B, GPT-4 (아마 110B x 16 way MoE, top-k routhing k=2)

  • 문제) instability (routing operation이 complex + hard-switching)
  • MoE-based LM 모델의 성능을 높이기 위해 routing module에 high-precision tensors를 쓴다던가, smaller range의 모델로 initializing 한다던가 하는 방법론이 생기고 있음

3.2 Transformer의 주요 configuration

(1) normalization (2) positional embeddings (3) activation functions (4) attention & bias

일반화 성능과 학습 안정성을 위해 pre RMSNorm, SwiGLU/GeGLU 활성화 함수를 사용하고, 임베딩 레이어 직후에는 LN을 사용하지 않는 것이 좋음. 또한, 위치 임베딩으로는 RoPE나 ALiBi가 긴 시퀀스에서 더 좋음.

(1) Normalization

  • LayerNorm
    • BatchNorm은 다양한 길이를 가진 sequence data를 다루기 어려웠음 → layernorm 등장: sequence에 따른 고정길이를 정규화.
  • RMSNorm
    • LN의 속도를 높이기 위해 RMSNorm 등장
      • activation 값들의 re-scaling만 진행: mean & variance 계산 대신 activations의 합에 대해 RMS
    • Gopher, Chinchilla, LLaMA가 RMSNorm 사용
  • DeepNorm
    • deep transformer를 안정적으로 학습하기 위해 Microsoft에서 제안
    • DeepNorm을 residual connection 처럼 사용 → Transformer를 1000 layer 로 확장 가능. + 성능, stability 좋음
    • GLM-130B에서 사용

(2) Normalization Position

  • post-LN
    • vanilla Transformer에서 사용. residual blocks 사이에 위치
    • But post-LN은 output layer 근처의 큰 gradient 때문에 안정적이게 학습이 안됨
    • → 최근엔 잘 사용 안함
  • Pre-LN
    • 각각의 sub-layer 전에 위치함. 추가 LN은 final prediction 전에 위치
      • → post-LN에 비해 학습 때 stable함
    • GLM 같은 큰 모델에서 unstable
  • Sandwich-LN
    • pre-LN 기반. residual connection 전에 extra LN을 추가 → Transformer layer output의 value explosion 방지
    • Sandwich-LN을 사용하면 가끔 학습의 stability가 망가지기도 함 (→ training collapse)

(3) activation functions

  • in existing LLMs, GeLU activations이 많이 사용
  • 최근엔 GLU activation이 많이 사용
    • SwiGLU, GeGLU … → 성능은 매우 좋지만, GeLU보다 50% 더 param이 많음

(2) positional embeddings

  • Absolute position embedding
    • vanilla Transformer에서 사용
    • sinusoidal & learned position embedding
    • 각 위치마다 고정된 embedding vector를 사용
    • 각 위치의 임베딩을 독립적으로 학습. (위치 간의 상대적 관계를 모델링하지는 않음)
  • Relative position embedding
    • 입력 토큰 사이의 상대적 거리를 기반으로 위치 정보를 encoding (입력 시퀀스 길이에 무관함) → 토큰 간의 관계를 더 잘 포착할 수 있음
    • key와 query 벡터에 상대 위치를 embedding 한 후, 내적하여 attention score 계산. (sequence의 key와 query 사이의 거리에 따라 상대적 위치로 encoding)
  • Rotary positional embedding
    • 위치 정보를 임베딩 벡터에 직접 더하는 rotation 변환을 적용.
    • 각 위치마다 고유한 회전 각도를 할당하고, 이를 입력 임베딩에 적용하여 위치 정보를 주입 (rotation 행렬을 이용해서 절대 위치를 encoding 하고, self-attention 식에서 relative position dependency (상대 위치 의존성) 정보를 더해줌)
    • 최근 LLM에서 많이 사용
  • ALiBi

(4) attention & bias

  • Full attention
    • vanilla Transformer에서 사용
  • sparse attention
    • full attention의 계산 복잡도를 해결하기 위해 제안됨
    • 각 query가 위치에 따라 token의 부분집합에만 attention을 수행
    • GPT-3, Factorized Attention이 적용됨
  • Multi-query / grouped-query attention
    • multi-query attention (MQA)
      • 서로 다른 head가 key와 value에 대해 동일한 선형 변환 행렬을 공유 (단일 key-value head를 사용) → 모델의 성능은 조금 떨어지지만, inference 속도가 매우 빨라짐
      • PaLM, StarCoder 등에 사용
    • group-query attention (GQA)
      • MQA와 MHA의 절충안
      • 여러개의 head에 대해 group을 나눈 후, group에 대해 key, value transformation matrices 적용
      • LLaMA2, 3 등에 사용

  • FlashAttention
    • 다양한 attention methods: mode quality와 computing efficiency간의 trade-off가 있음
    • GPU내 attention 모듈의 속도와 메모리 소모량을 최적화한 방법
      • transformer self attention 연산시에 주로 memory throughput이 낮아 tensor core의 연산 효율이 떨어짐. → 연산을 중복해서 실행하더라도 HBM과 SRAM 사이의 IO를 최소화하여 기존보다 약 2배 이상 latency를 줄임 (출처)
      • 모델의 성능에 전혀 영향을 주지 않음. 단지 HW level의 bottleneck을 SW 기법으로 해결
    • Pytorch, DeepSpeed, Megatron-LM 등에 통합됨
  • PagedAttention
    • 서버에 배포된 LLM에서 GPU 메모리 사용 효율을 높이기 위해 제안됨 (GPU를 KV cache가 엄청 잡아먹음)
      • KV cache는 반복 계산되는 값을 저장해 둔 것
    • 메모리를 잡아먹는 주된 원인은 다양한 길이의 input length → 따라서 PagedAttention: 각 sequence를 subsequence로 나눈 후, 하위 시퀀스의 KV 캐시를 non-contiguous 블록에 할당함

3.3 Long Context Modeling

  1. Scaling Position Embedding
    • LLM의 context length를 훈련때보다 늘릴려면 position indics를 확장해야함
    • 훈련된 length보다 긴 text를 잘 일반화하여 position embedding하는 능력을 extrapolation capacity 라 함
    • 👇🏻 RoPE를 더 긴 문장으로 scaling 하는 방법론들
    • [a] Direct model fine-tuning
      • model을 더 긴 text로 fine-tuning 하는 방식
      • multi-stage approach (e.g., 2K → 8K → 32K).
      • 좋은데 느림
      • ex) CodeLLaMA, LongLLaMA
        • CodeLLaMA further extends the context window of LLaMA 2 (2.5T tokens with 4K context window → 20B tokens with 16K context window)
        • LongLLaMA also achieves longer context window with the help of external memory and a unique training objective (1T tokens with 2K context window → 10B tokens with 8K context window).
    • [b] Position interpolation
      • 주어진 문장을 original context window 안으로 downscaling → pretraining 동안의 rotation angle을 벗어나지 않음
      • [a] 방법론보다 context window를 효과적으로 키우지만, 짧은 text 처리를 잘 못함 (side-effect)
    • [c] Position truncation
      • context length보다 긴 부분은 truncation 하는 방식
      • ReRoPE, LeakyReRoPE 같은 모델은 maximum-training length 보다 window length를 작게 미리 설정 → pre-defined window 내의 문장은 유지, 그 이상의 문장은 maximum training length에 맞게 interpolate (혹은 유지)
      • local position relationship을 잘 유지하고 extrapolation capacity를 향상시킬 수 있지만, attention 을 두번 계산해야함 (→ computing resource 많이 듦)
    • [d] Base modification
      • RoPE 연산의 formula를 약간 수정하여 (base를 작게) 모든 dimension의 wavelength를 train length 아래로 rescale 하는 방식. 이 방식이 extrapolation capacity 측면에 더 좋다 함
    • [e] Base truncation
      • Base modification과 유사하게, basis truncation도 training length를 초과하는 wavelength를 가진 dimension을 처리
      • 더 큰 position indices에 대해 out-of-distribution rotation angle을 피할 수 있음. BUT long context task에서 성능 별로
  2. Adapting Context Window
    • [a] Parallel context window (PCW)
      • fusion-in-decoder (FiD)처럼 divide-and-conquer 전략을 사용하여 input text를 처리
      • 방법론
        • (1) input text를 여러 segments로 나눈 후 각각을 shared position embeddings으로 encoding
          • context window 끼리 PE를 공유 → 각 window에서 생성된 토큰이 같은 거리에 있음
        • (2) 이후 generation stage에서 각 segment 별로 attention 계산.
          • masked attention → window 내의 이전 토큰들에 대해서만 attention
      • 문제: segments 의 순서를 고려 안함 + window 간의 관계를 모델링 하지 않음 → multi-hop reasoning과 같이 시퀀셜한 추론이 필요한 task에서는 성능 저하
    • [b] A-shaped context window
      • lost in the middle
        • 긴 input sequence를 처리할 때, LLM은 초반부와 마지막 부분만 기억하고 (더 큰 attention weight) 중반부를 까먹는 경향이 있다.
      • → LM-infinite, StreamLLM은 “A-shaped” attention mask를 제안
        • initial token과 nearest token에서는 query에 대해 attention이 큰 token들만 선택적으로 냅두고 나머진 버림
        • 고정된 memory에 대해 extra-long text generation은 잘 하지만.. 버려진 토큰에 중요한 정보가 있다면, 이용이 어렵다는 단점이 있음
    • [c] External memory
      • document의 사이즈가 늘어날수록 문제 해결에 필요한 중요한 tokens은 일부임 (실제로 top-k attention key들이 original full attention를 근사할 수 있음)
      • → 외부 메모리에 과거의 중요 key들을 저장해놨다가 생성할 때 k-NN search method를 통해 관련성 높은 k개의 주요 관련 토큰들만 사용하는 방법론 제안 (Memory Transformer, LongLLaMA..)

3.4 Decoding Strategy

  • Greedy search
    • 각 단계에서 가장 확률이 높은 토큰을 선택하는 방식 (이전 토큰들에 대해 most likely token 예측). 좀 더 일관되고 문법적으로 올바른 문장을 생성하는 경향이 있음
    • Beam search
      • decoding 하는동안 각 단계에서 n (beam size) highest probabilities의 문장을 유지한 후, 최종적으로 가장 높은 확률의 문장을 선택하는 방식
      • Length penalty (length normalization)
        • beam search은 짧은 문장을 선호하기 때문에 length penalty 를 통해 이를 극복
  • Sampling-based methods
    • 확률 분포에 따라 무작위로 토큰을 선택하는 방식 (diversity하게 생성을 잘 하도록 probability distribution를 base로 하여 next token을 random sampling). 더 다양하고 창의적이지만 문법 오류나 비문이 많이 발생
    • Temperature sampling
      • 언어 모델의 확률 분포를 조정하는 하이퍼파라미터. Temperature가 높을수록 확률 분포가 평평해져서 다양한 토큰이 선택될 가능성이 높아지고, 낮을수록 확률이 높은 토큰에 집중되어 결정론적인 출력을 생성.
        • Temperature가 1일 때는 원래의 확률 분포를 유지
        • 1보다 작으면 높은 확률의 토큰이 더 자주 선택됨
        • 1보다 크면 확률 분포가 평평해져 다양한 토큰이 선택될 가능성이 높아짐
    • Top-k sampling
      • 각 단계에서 확률이 가장 높은 k개의 토큰을 선택한 후, 그 중에서 확률에 비례하여 무작위로 토큰을 선택하는 방식
        • k 값이 클수록 더 많은 옵션 중에서 선택하게 되므로 다양성이 증가
        • 작을수록 높은 확률의 토큰에 집중하게 됨
      • 확률이 낮은 토큰을 제거함으로써 완전한 random sampling보다는 관련성 높은 토큰을 선택할 가능성을 높이면서도, 그 중에서 무작위로 선택하여 어느 정도의 다양성을 확보할 수 있음
    • Top-p sampling
      • 누적 확률이 특정 임계값 p를 넘는 토큰들 중에서 무작위로 선택하는 방식
        • p 값이 클수록 더 많은 토큰을 고려하게 되므로 다양성이 증가
        • 작을수록 높은 확률의 토큰에 집중
      • 일반적으로 p 값은 0.9 내외로 설정됨 (상위 90% 확률 질량에 해당하는 토큰들 중에서 선택한다)
  • Reducing data transfer → GPU 메모리 효율화
    • PagedAttention
      • KV cache를 non-continous memory block에 저장해서 메모리 효율화
    • Flash-Decoding
      • attention 효율화
    • MQA, GQA
      • KV parameter를 공유하는 방식

[4] Training

4.1 Optimization Setting

Batch Training

  • GPT-3, PaLM 같은 모델: 훈련 중에 dynamic하게 batch size를 올림
    • GPT-3 (32K → 3.2M tokens)
  • dynamic batch scheduling이 LLM 을 안정적으로 학습하는데 도움이 됐다 함
    • 배치 크기를 동적으로 조정하면 모델의 학습 단계와 사용 가능한 계산 리소스에 맞춰 샘플 수를 최적화할 수 있음 → 학습 효율을 높이고 계산 비용을 절감하며 모델 성능을 향상시킬 수 있음 (참고)

Learning Rate

  • warm-up & decay strategies

Optimizer

  • LLM: Adam & AdamW 많이 사용 (GPT-3)
  • Adafactor - PALM, T5

4.2 Scalable Training Techniques

GPU Memory

FP16 & x parameters

  • parameters: 2x (2 bytes for fp16)
  • gradients: 2x
  • optimizer state: 12x
    • parameter copy: 4x (4 bytes for fp32)
    • momentums: 4x
    • variance: 4x

4.2.1 3D Parallerism

다음 세미나 참고 https://www.youtube.com/watch?v=JA1l96tjrs4&t=1256s

4.2.1.1 Data Parallelism

  • 여러 GPU들에 model paramameters, model gradients, optimizer paramters를 복제 → 전체 training corpus를 나눠서 (data parallelism) 여러 GPU로 학습
  • GPU는 할당된 데이터만 처리하고, forward와 backward propagation을 수행하여 gradient를 얻음
  • 서로 다른 GPU에서 계산된 gradient는 aggregation되어 전체 배치의 gradient를 얻고, 전체 GPU의 모델을 업데이트
Data Parallelism 추가 설명

[출처: soochel 님 블로그](https://medium.com/tesser-team/%EB%8B%A4%EC%A4%91-gpu%EB%A5%BC-%ED%9A%A8%EC%9C%A8%EC%A0%81%EC%9C%BC%EB%A1%9C-%EC%82%AC%EC%9A%A9%ED%95%98%EB%8A%94-%EB%B0%A9%EB%B2%95-dp%EB%B6%80%ED%84%B0-fsdp%EA%B9%8C%EC%A7%80-3057d31150b6), [참고: NCCL](https://docs.nvidia.com/deeplearning/nccl/user-guide/docs/usage/collectives.html#reducescatter), [youtube](https://www.youtube.com/watch?v=By_O0k102PY) 1. 입력 데이터와 모델의 파라미터를 각 GPU에 전달해줘야 된다. 2. backward 과정에서는 각 GPU에 전달된 데이터와 관련된 gradient를 나누어 주어야 한다. 3. 마지막으로 모든 gradient를 모으고 업데이트를 해주어야 한다. Data Parallelism은 첫번째 GPU가 하는 일이 너무 많음 → pytorch, multi-processing을 이용한 Distributed Data Parallelism - multiprocessing을 사용하기 때문에 multi-thread의 단점 해결 가능 - 여러개의 process를 사용 → GPU-1 이 모든일을 다 하지 않고, GPU들이 일을 나눠서 함. 다만, GPU 간 통신이 필요해짐 The key insight to unlock full parameter sharding is that we can decompose the [all-reduce](https://docs.nvidia.com/deeplearning/nccl/user-guide/docs/usage/collectives.html#allreduce) operations in DDP into separate [reduce-scatter](https://docs.nvidia.com/deeplearning/nccl/user-guide/docs/usage/collectives.html#reducescatter) and [all-gather](https://docs.nvidia.com/deeplearning/nccl/user-guide/docs/usage/collectives.html#allgather) operations [(출처)](https://engineering.fb.com/2021/07/15/open-source/fsdp/)

DDP (`Distributed Data Parallelism`)

[DP부터 FSDP까지 글 발췌](https://medium.com/tesser-team/%EB%8B%A4%EC%A4%91-gpu%EB%A5%BC-%ED%9A%A8%EC%9C%A8%EC%A0%81%EC%9C%BC%EB%A1%9C-%EC%82%AC%EC%9A%A9%ED%95%98%EB%8A%94-%EB%B0%A9%EB%B2%95-dp%EB%B6%80%ED%84%B0-fsdp%EA%B9%8C%EC%A7%80-3057d31150b6) DDP에서는 기본적으로 sampler를 통해 각 GPU에 서로 다른 데이터가 전송되며, 각 데이터를 이용해서 모델 파라미터의 gradients A, B, C, D를 계산합니다. 이후 All Reduce 연산을 통해 gradients A, B, C, D에 대한 평균을 구한 뒤, 모든 GPU에 전달됩니다. 이후 optimizer의 step을 통해 각 GPU에서 모델 파라미터가 업데이트 되고, 똑같은 gradients 값을 사용했기 때문에, 똑같은 모델 정보가 보장됩니다.

FSDP (`Fully Sharded Data Palleral`)

반면 FSDP에서는 모델의 모든 정보가 하나의 GPU에 있는 것이 아니라, 여러 GPU에 분산되어(sharded) 있습니다. 따라서 forward 과정에서 모델의 각 layer를 통과할 때마다 다른 GPU에 저장되어 있는 파라미터를 가져와 사용하고 제거합니다 (All Gather 연산). 이후 backward 과정에서 다시 gradients를 계산하기 위해 다른 GPU에 저장되어 있는 파라미터를 가져와서 사용하고 (All Gather 연산), 각 GPU에서 계산된 gradients를 다시 원래 속해 있던 GPU에 전달하기 위해서 Reduce Scatter 연산을 사용합니다. 최종적으로 각 GPU에는 각 GPU가 갖고 있던 모델에 대한 gradients만 남기 때문에, 이후 optimizer의 step 연산을 통해 모델의 파라미터를 업데이트할 수 있습니다.

|

--|--

ZeRO

- DeepSpeed에서 제안됨. data parallelism에서의 memory dedundancy 이슈에 집중 - data parallelism은 각 GPU에 모델을 copy (model paramameters, model gradients, optimizer paramters) → memory redundancy 문제 생김 - memory redundancy 문제를 해결하기 위해 각 GPU에서 data의 일부만 유지하고, 나머지 데이터는 필요할 때 다른 GPU에서 검색 (retrieve)하는 방법론 (총 3가지) - (1) optimizer state partitioning (2) gradient partitioning → communication overhead X - (3) parameter partitioning → communication overhead 는 있지만 (50%) 메모리 효율화 가능 - Pytorch는 ZeRO와 비슷한 FSDP 제공

4.2.1.2 Tensor Parallelism

  • multi GPU 연산을 위해 LLM의 tensor(parameter 행렬)를 decompose
  • matrix multiplication을 여러 GPU에서 병렬 연산
  • Megatron-LM 등에서 사용 가능

4.2.1.3 PipeLine Parallelism

  • LLM의 서로 다른 layer를 multi GPU 에 분배
  • ex) Transformer
    • 같은 GPU에 연속적인 layer를 로드 → GPU간의 전송 비용을 줄임 (gradient, hidden state..)
  • Pipeline Parallelism은 다른 GPU에서 진행된 연산 결과를 기다려야함 → bubble overhead 존재
    • 이를 해결하기 위해 GPipe, PipeDream 은 padding multiple batches of data와 asynchronous gradient update 기술을 제안하여 pipeline 효율성을 개선

4.2.2 Mixed Precision Training

  • 과거 PLMs (ex. BERT)들은 주로 FP32 사용했지만, 최근엔 메모리 효율화 + communication overhead 감소를 위해 FP16를 사용
    • Overflow 문제 생길 수 있음 (뒤쪽 layer로 갈수록 GEMM - matrix multiplication 의 연산 결과값이 커질 수 있는데, 이때 이 값이 FP16의 최댓값인 66504보다 클 경우 overflow 발생
  • A100 같은 NVIDIA GPUs는 FP16 연산을 2번 해서 FP32 처럼 사용
  • BUT, FP16은 계산 정확도를 떨어트릴 수 있음 → 모델 성능 하락
  • 이를 완화하기 위해 BF16 (Brain Floating Point) 가 등장
    • BF16는 FP16보다 더 많은 exponent bit와 더 적은 significant bit를 할당
    • Pre-training의 경우, BF16이 일반적으로 representation accuracy 면에서 FP16보다 우수

[5] [LLM Serving] Inference

참고 글:

[1] https://tech.scatterlab.co.kr/serving-architecture-3/ [2] https://engineering.clova.ai/posts/2022/03/hyperclova-part-3

multi batch

  • 추론 과정은 학습 때와는 다르게, throughput을 높이는 것보다 latency를 줄이는 게 중요함 → batch size를 최대화하기 보다는 한번에 single batch만 처리하는 방식으로 latency를 줄임

dynamic batch

https://clear.ml/blog/increase-huggingface-triton-throughput-by-193/

  • 실제 REST API를 구성하고 사용자의 입력을 받으면, 시간 차이를 두고 각기 다른 요청들이 들어오게 됨. 이때 각 요청마다 single inference를 하면 latency가 길어짐
    • → dynamic batch 사용: 여러개의 입력을 한개의 batch로 묶어 최대한 tensor core의 utilization을 높임

  • 다만, 실제로 dynamic batch (multi batch)를 해보니 대체적으로는 latency의 큰 변동 없이 처리량이 늘어났지만 특정상황에서는 지연시간이 배로 증가하는 현상이 발생.
  • WHEN? 하나의 batch 로 묶은 요청들의 입력 문장의 길이가 크게 다른 경우에는 짧은 문장을 기준으로 generation이 되기 때문에 처리 시간이 지체됨
  • 해결방법
    • [1] 버킷팅 전략
      • 입력 문장의 길이가 비슷한 요청끼리 분류하여 bucket을 만든 후 multi batch 연산
      • 다만 bucket으로 잘 묶는다 해도 각 입력 문장의 길이차가 여전히 존재 (→ 지연시간 증가). 또 버킷으로 묶으려다가 서비스에서 멀티배치연산을 못하기도 함
    • [2] GPT의 attentnion mask의 특징을 이용
      • 이렇게 attention mask를 수정하는 방식을 적용 → 입력 길이가 서로 다른 요청이 하나의 배치로 묶일 때 지연시간이 크게 증가하는 현상을 막을 수 있었다고 함

Iteration Batching

  • FriendliAI의 Iteration-level Scheduling
  • batch로 묶인 요청들에서 output token이 하나씩 형성될 때마다 새로운 요청을 batch 포함 시킴

댓글남기기