이 영역을 누르면 첫 페이지로 이동
천천히 꾸준히 조용히 블로그의 첫 페이지로 이동

천천히 꾸준히 조용히

페이지 맨 위로 올라가기

천천히 꾸준히 조용히

천천히 꾸준히 조용히.. i3months 블로그

[Transformer] Attention is all you need

  • 2026.01.02 19:54
  • 📚 공부
반응형

 

 

 

Attention은 정보를 처리할 때 어디에 집중할지 결정하는 수학적 원리이고, Transformer는 Attention을 기반으로 만든 모델이라고 생각하면 됨. 

 

즉, Attention은 모델 자체의 설계와 학습 방법에 관한 내용이지, 모델 배포에 대한 내용이 아니다. 

 

Recurrent Neural Networks, Long Short Term Memory, Gated Recurrent Neural Network 모델은 문장을 읽을 때 순차적으로 처리함. 

즉, 첫 번째 단어를 처리해야 두 번째 단어를 처리할 수 있는 것 처럼  의존성이 있다는 것..

문장이 길어질수록 계산 오버헤드가 너무 크고 병렬 처리가 힘들다.

 

그러니 복잡한 RNN, CNN을 다 치우고 Attention만 사용해서 모델을 만드는 방식을 도입한다.

문장을 구성하는 단어를 한 번에 때려놓고 계산할 수 있어 학습 속도가 빠르다.

 

CNN은 문장을 한 번에 병렬로 처리할 수 있지만, 멀리 떨어진 단어 사이의 관계를 파악하기 위해 CNN 레이어를 여러 층 쌓아올려야 한다.

즉, 단어 사이의 거리에 비례해서 연산량이 늘어나 문장이 길어질수록 정보를 학습하기가 어렵다.

 

Transformer는 한 번의 연산으로 모든 단어 사이의 관계를 파악한다.

문장이 아무리 길어도 모든 단어가 직접적으로 연결되지만, 정보를 한 번에 평균 때려버리니 Resolution이 낮아질 수 있다.

 

Attention은 기본적으로 Weighted Average를 구하는 작업으로, 여러 정보를 하나로 섞어버리면 각 단어의 특징이 희석된다.

복잡한 관계를 단 하나의 결과물로 요약하다 보니 Resolution이 낮아질 수 밖에 없음..

 

Self-Attention은 스스로에게 질문을 던지는 매커니즘이다.

문장 안에서 각 단어들이 서로 어떻게 연관되는지 계산해 문장의 전체적인 표현을 만들어냄.

 

The animal didn't cross the street because it was too tired.

 

 

이 문장에서 it이 가리키는걸 어떻게 알 수 있을까? 

사람은 그냥 문장보고 바로 알 수 있는데, 컴퓨터는 쉽지 않음.

 

Self-Attention 과정에서, it은 문장 내 다른 모든 단어와 스스로를 비교하고 tired라는 상태와 가장 잘 어울리는 animal에 높은 Attention을 준다. 

 

입력된 문장 내부에서 단어들끼리 서로 Attention을 주고받기에 Self-Attention 이라고 부른다.

여기서 Attention은 중요한 정보에 집중하고 덜 중요한 정보는 무시하는 테크닉 정도로 생각하면 됨.. 

 

이 논문에서 Attention이라는 개념이 새롭게 등장한건 아님.

예전에는 RNN을 메인으로 쓰고 정보 손실을 막기 위해 Attention을 보조 도구로 사용하는 구조였다.

 

다만, Attention Is All You Need 논문에서는 RNN을 아예 배제하고 Attention만 여러 개 이어붙이는 방식을 제안했고, 실제로 이걸 구현하는 방식을 설명했다는것.. 

 

 

 

 

 

 

전체적인 아키텍처를 보자. Encoder - Decoder 모델로 구성됨.

 

Encoder 

입력 문장을 제대로 이해하는 곳으로, 입력 문장을 받아서 숫자로 변환한다.

같은 층을 6번 중첩하는 구조로 구성되어있음. 각 층은 다시 두 개의 하위 층을 가진다.

 

하위 층 1 - Multi Head Self Attention : 단어들이 서로 어떤 관계인지 파악한다.

하위 층 2 - Feed Forward Network : 파악된 정보를 바탕으로 데이터를 가공한다.

 

이 두 개의 층은 Residual Connection과 Layer Normalization으로 포장되어있음.

 

Embedding Layer는 512로 설정한다.

일단 Embedding Layer는 자연어를 고차원 공간의 좌표로 변환해주는 매핑 테이블로 생각하면 됨. 

512로 설정한다는거는 단어 하나를 512개의 실수로 표현한다는 것. 

 

즉, 사과라는 단어가 Embedding Layer를 거치면 [0.1, 0.12, 0.4 ..] 처럼 크기가 512인 벡터가 된다는거임.

단어의 의미가 다각적이니까. 이게 과일임? 먹는거임? 전자제품임? 문장에서 몇번째 위치임? 이런 특징을 512개의 공간에 나눠담는것.

너무 크게 잡으면 학습 시 GPU VRAM이 부족하고.. 너무 작게 잡으면 성능이 구리고.. 이 논문에서는 적당히 타협해서 512로 잡은듯

 

Decoder

인코더가 만들어둔 정보를 넘겨받아 출력을 만들어낸다.

인코더처럼 같은 층을 6번 중첩하지만 각 층은 세 개의 하위 층을 가진다. 

 

하위 층 1 - Masked Self Attention : 미래의 단어를 미리 보는걸 방지해야 하니 Masking 처리함. 지금까지의 관계를 파악한다.

하위 층 2 - Encoder Decoder Attention : 인코더가 만든 정보를 살펴보면서 지금 어떤 입력에 집중해서 출력을 만들지를 결정함.

하위 층 3 - Feed Forward Network : 최종적으로 정보를 가공해 다음 단어를 예측한다.

 

Softmax 적용하기 전에 미래 단어에는 -∞ 값을 넣어준다. 미래 단어를 참고하고 싶어도 정보량이 0이 되니 구조적으로 참고할 수 없음.

 

 

 

 

 

 

$$Attention(Q, K, V) = \text{softmax}\left(\frac{QK^T}{\sqrt{d_k}}\right)V$$

 

Q는 쿼리 K는 인덱스 V는 실제 값

쿼리와 키를 내적한다. 유사도를 검사한다는거임. 비슷하면? 큰 값으로 나오겠지..

 

dk 로 나누는데, 차원이 커지면 내적 값도 커져서 Softmax를 통과할 때 Gradient Vanishing이 발생함. 미분값이 0이 되고 학습에 반영이 안되어버리는..

그러니 크기를 줄여서 연산을 안정화한다.

Softmax로 sum이 1이 되도록 수정해주고, 실제 값을 곱해서 최종 정보를 추출한다.

 

차원을 512로 설정했는데. 이걸 다 계산하지는 않고, 8개로 쪼개서 병렬로 처리한다. (Multi-Head Attention)

각 헤드는 64차원씩 담당함. 각각 다른 정보를 담당해서 처리한다. (주어가 누구? 이건 뭘 꾸미지? 등등..)

이러면 연산량은 같은데 병렬로 여러 관점을 한 번에 볼 수 있어서 이득.

 

 

$$
\begin{aligned}
PE_{(pos, 2i)} &= \sin\left(pos / 10000^{2i / d_{model}}\right) \\
PE_{(pos, 2i+1)} &= \cos\left(pos / 10000^{2i / d_{model}}\right)
\end{aligned}
$$

 

RNN 같은 순서 개념이 없어서 이 단어는 n번째 단어라는 위치 신호를 수동으로 넣어 줘야 함..

그러니 삼각함수로 각 위치마다 고유한 주파수를 부여한다.

 

거리가 k만큼 떨어진 두 단어의 위치 관계를 선형으로 표현할 수 있고, 모델들이 상대적인 거리를 쉽게 학습할 수 있음.

그냥 순서개념 넣어주려고 삼각함수 쓴다. 

 

 

 


 

 

 

일단 개념은 여기까지고.. 여기서부터는 RNN과 CNN말고 Transformer를 사용해야 하는 이유를 다룬다.

 

한 층을 계산할 때의 연산량, 순서대로 계산해야 하는 연산의 개수, 단어와 단어 사이의 거리를 기준으로 비교했을 때 Transformer 모델의 성능이 압도적임을 확인할 수 있음.

 

일단 모든 단어들이 서로 직접적으로 연결되어 있으니 거리가 1이다. 그러니 아주 멀리 있는 단어의 관계도 쉽게 인식할 수 있고, 모든 단어의 Attention을 동시에 계산하니 GPU를 효과적으로 사용할 수 있다. 

 

실제로 이 방식으로 학습시킬 때는 Warmup 방식을 사용함.

JVM 웜업이랑 비슷한 느낌으로다가 초반에는 학습률을 서서히 높였다가 다시 서서히 낮춘다. 

아무것도 모를 때 머리에 팍팍 집어넣으면 파라미터가 망가질 수 잇으니, 조금씩 증가시키고, 마지막에는 다시 세밀하게 조정한다.

 

과적합 방지를 위해서 무작위로 10%정도의 노드를 꺼버린다던지, 정답확률을 살짝씩 깎아준다던지 몇 가지 테크닉을 사용함.

 

 

Decoder만 떼어내서 만든 모델이 GPT

Transformer의 Decoder 블록만 수백개 쌓아올린다. - 생성에 all in

 

Encoder만 떼어내서 만든 모델이 BERT

마스킹으로 뒷부분을 가리는 GPT와 다르게 문장 전체를 양방향으로 한 번에 보고 관계를 파악한다. - 이해에 all in

 

 

근데 모든 단어를 다 보니까 잘 기억해야 하는거 아닌가? 왜 내가 챗지피티 쓸때는 대화 좀 쌓이면 헛소리 하는거지?

->

O(1) 으로 모든 단어를 볼 수는 있는데, 실제로 컴퓨터가 한 번에 처리할 수 있는 Context Window에는 물리적인 한계가 있음.

대화가 길어져서 Window 크기를 넘어가버리면 가장 오래된 대화부터 잘라내거나 안 중요하다고 판단한 부분을 요약해버린다.

 

Attention 연산 복잡도는 O(N^2) 이다. 단어가 2배 늘어나면 연산량은 지수적으로 증가해버리는..

모델은 이전 대화를 기억하기 위해 각 단어의 Key와 Value를 VRAM에 저장한다. 대화가 길어지면? GPU VRAM이 꽉 차버림.. 그럼 속도가 느려짐.. 

 

그냥 VRAM이 문제임. 그냥 이거때문에 엣지 디바이스에서 고성능 모델 돌리기도 힘들고 이전 대화 기억도 힘들어지는거임.

요즘 나오는 논문에서처럼 RAM이나 SSD에 저장해놓고 스왑하는 Offloading 방식을 쓸 수도 있는데..

 

보통 HBM에서는 2TB/s 속도로 데이터를 주고받는다.

Attention 연산을 하려면 이전 대화의 모든 데이터가 GPU 코어로 들어와야 함. 

그러니, 대화가 쌓이면 요약하거나 안중요한거 지워버리지 않으면 연산이 구조적으로 불가능하다는 것.. 어쩔수가없다

 

OpenAI는 H100같은 하이엔드 GPU를 수만대씩 쌓아두고 쓸텐데. 그걸 나 혼자 다 쓰는지 아니니까..

GPU 한대가 수백명의 사용자를 동시에 처리하는 셈이니. 기업 입장에서도 적당한 선에서 기억을 잘라내고 더 많은 손님을 받는게 이득이다.

 

사실 GPU 100장을 나 혼자 쓴다고 해서 성능이 무조건 잘 나온다는 보장은 없음...

메모리 저장 문제는 해결되긴 하지만, 애초에 모델이 학습할 때 128k 길이의 문장으로만 학습했다면 한계가 있다.

 

데이터가 VRAM에 다 들어간다고 해도, 모델이 그 위치를 계산할 수 없으면 구조적으로 헛소리를 할 수 밖에 없다.

그리고 Attention에는 Softmax를 사용하는데, 대화가 100만 단어로 길어지면 각 단어가 가져가는 점수가 너무 작아져서 어디에 집중해야 할 지가 흐릿해지고.. 답변이 제대로 안뜸;; 

 

그래서 사실상.. HOBBIT이나 Offloading 방식으로 엣지 디바이스 (VRAM 8GB정도) 에서 고성능 llm을 구겨서 넣고 돌리더라도 대화 조금 하다 보면 이전 대화 기억 못하고 헛소리 할 가능성이 매우 높음..

 

근데 대화를 기억할 필요가 없거나 짧은 대화만 처리하는 경우면 의미 있을듯 

 

그냥 하드웨어가 깡패다 

 

 

 

참고

1. Attention Is All You Need

https://arxiv.org/abs/1706.03762

 

 

 

 

 

반응형
저작자표시 (새창열림)

'📚 공부' 카테고리의 다른 글

[Fault Injection] A Micro Architectural Events Aware Real-Time Embedded System Fault Injector  (0) 2026.01.11
[Fault Injection] SoK: Analysis of Fault Injection Attacks  (1) 2026.01.08
[HOBBIT] A Mixed Precision Expert OffloadingSystem for Fast MoE Inference  (1) 2025.12.28
[MoE] Mixture Of Experts  (1) 2025.12.25

댓글

이 글 공유하기

  • 구독하기

    구독하기

  • 카카오톡

    카카오톡

  • 라인

    라인

  • 트위터

    트위터

  • Facebook

    Facebook

  • 카카오스토리

    카카오스토리

  • 밴드

    밴드

  • 네이버 블로그

    네이버 블로그

  • Pocket

    Pocket

  • Evernote

    Evernote

다른 글

  • [Fault Injection] A Micro Architectural Events Aware Real-Time Embedded System Fault Injector

    [Fault Injection] A Micro Architectural Events Aware Real-Time Embedded System Fault Injector

    2026.01.11
  • [Fault Injection] SoK: Analysis of Fault Injection Attacks

    [Fault Injection] SoK: Analysis of Fault Injection Attacks

    2026.01.08
  • [HOBBIT] A Mixed Precision Expert OffloadingSystem for Fast MoE Inference

    [HOBBIT] A Mixed Precision Expert OffloadingSystem for Fast MoE Inference

    2025.12.28
  • [MoE] Mixture Of Experts

    [MoE] Mixture Of Experts

    2025.12.25
다른 글 더 둘러보기

정보

천천히 꾸준히 조용히 블로그의 첫 페이지로 이동

천천히 꾸준히 조용히

  • 천천히 꾸준히 조용히의 첫 페이지로 이동

검색

방문자

  • 전체 방문자
  • 오늘
  • 어제

카테고리

  • 분류 전체보기 (674)
    • Algorithm (205)
      • Data Structure (5)
      • Theory && Tip (33)
      • Baekjoon (166)
      • ALGOSPOT (1)
    • Spring (123)
      • Spring (28)
      • Spring Web MVC (20)
      • Spring Database (14)
      • Spring Boot (6)
      • Spring 3.1 (11)
      • Spring Batch (6)
      • Spring Security (16)
      • JPA (12)
      • Spring Data JPA (5)
      • QueryDSL (4)
      • eGovFramework (1)
    • Programming Language (74)
      • C (25)
      • C++ (12)
      • Java (19)
      • JavaScript (15)
      • Python (1)
      • PHP (2)
    • Computer Science (142)
      • Machine Learning (38)
      • Operating System (18)
      • Computer Network (28)
      • System Programming (22)
      • Universial Programming Lang.. (8)
      • Computer Architecture (4)
      • Compiler Design (11)
      • Computer Security (13)
    • Database (21)
      • Database (7)
      • MySQL (3)
      • Oracle (3)
      • Redis (5)
      • Elasticsearch (3)
    • DevOps (20)
      • Docker && Kubernetes (8)
      • Jenkins (4)
      • Amazon Web Service (8)
    • Mobile (28)
      • Android (21)
      • Flutter (7)
    • 💡 솔루션 (17)
    • 👥 모각코 (8)
    • 💬 기록 (6)
    • 📚 공부 (5)
    • -------------- (25)

최근 글

나의 외부 링크

메뉴

  • 홈
반응형

정보

i3months의 천천히 꾸준히 조용히

천천히 꾸준히 조용히

i3months

블로그 구독하기

  • 구독하기
  • RSS 피드

티스토리

  • 티스토리 홈
  • 이 블로그 관리하기
  • 글쓰기
Powered by Tistory / Kakao. Copyright © i3months.

티스토리툴바