cedis 님의 블로그

mini GPT 과제 2편 - GPTDataset과 InputEmbedding 구현 리뷰

cedis — Fri, 5 Jun 2026 00:24:34 +0900

mini GPT 과제 랩 구현 시리즈 2편

GPTDataset과 InputEmbedding 구현 리뷰

BPE가 token ID 목록을 만들었다면, `GPTDataset`은 이 목록을 학습 가능한 input/target 쌍으로 잘라낸다. `InputEmbedding`은 그 ID를 Transformer가 계산할 수 있는 벡터로 바꾼다.

이번 단계는 코드 양은 많지 않지만, 뒤의 attention과 model shape를 결정한다. 여기서 shape를 잘못 잡으면 나중에 attention에서 에러가 늦게 터진다.

테스트 통과 근거

tests/test_dataset.py
- GPTDataset 길이 계산
- __getitem__ input/target shape
- DataLoader batch shape
- InputEmbedding 출력 shape

결과: 4 passed

1. Dataset 길이는 context_length와 stride로 결정된다

한 샘플은 input `context_length`개와 target `context_length`개를 만들어야 한다. target은 input보다 한 칸 뒤이므로 실제로는 `context_length + 1`개의 token이 필요하다.

self.stride = stride if stride is not None else context_length
self._length = max(
    0,
    (len(token_ids) - context_length - 1) // self.stride + 1,
)

왜 `- 1`이 들어가나

input만 만들면 `context_length`개로 충분하다. 하지만 target은 한 칸 뒤까지 필요하므로 마지막 token 하나를 더 읽을 수 있어야 한다.

2. getitem은 input과 target을 한 칸 차이로 만든다

실제 구현은 단순하지만 의미는 중요하다. 같은 구간을 거의 그대로 쓰되 target만 시작 위치를 하나 뒤로 민다.

start = idx * self.stride
end = start + self.context_length

input_ids = self.token_ids[start:end]
target_ids = self.token_ids[start + 1: end + 1]

return (
    torch.tensor(input_ids, dtype=torch.long),
    torch.tensor(target_ids, dtype=torch.long),
)

예시: context_length = 4

원본

1011121314

input

10111213

target

11121314

3. create_dataloader는 Dataset을 batch 단위로 감싼다

DataLoader는 학습 루프가 한 번에 여러 샘플을 처리할 수 있게 묶어준다. 이때 반환 shape는 뒤의 모델 입력과 바로 연결된다.

dataset = GPTDataset(token_ids, context_length, stride=stride)

return DataLoader(
    dataset,
    batch_size=batch_size,
    shuffle=shuffle,
    drop_last=drop_last,
    num_workers=num_workers,
)

4. InputEmbedding은 token embedding과 position embedding을 더한다

token embedding은 “무슨 토큰인가”를 표현하고, position embedding은 “몇 번째 위치인가”를 표현한다. GPT 입력은 이 둘을 더한 값이다.

self.token_embedding = nn.Embedding(vocab_size, emb_dim)
self.position_embedding = nn.Embedding(context_length, emb_dim)
self.dropout = nn.Dropout(drop_rate)

def forward(self, x):
    batch_size, seq_len = x.shape
    positions = torch.arange(seq_len, device=x.device)
    token_embeddings = self.token_embedding(x)
    position_embeddings = self.position_embedding(positions)
    return self.dropout(token_embeddings + position_embeddings)

값	shape	역할
x	(B, T)	token ID batch
token_embeddings	(B, T, C)	각 토큰의 벡터
position_embeddings	(T, C)	각 위치의 벡터
output	(B, T, C)	TransformerBlock 입력

이 구현이 통과한 핵심 계약

Dataset 길이가 만들 수 있는 샘플 개수와 일치한다.
각 샘플의 input과 target은 `context_length` 길이를 가진다.
DataLoader는 `(batch_size, context_length)` 형태의 batch를 만든다.
InputEmbedding 출력은 `(batch_size, seq_len, emb_dim)`이다.

다음 글 예고

다음 구현 글에서는 `MultiHeadAttention`을 본다. 여기서부터 모델은 각 위치의 토큰이 이전 문맥을 어떤 비율로 참고할지 계산하기 시작한다.

한 줄 정리: Dataset은 다음 토큰 예측 문제를 만들고, InputEmbedding은 token ID와 위치 정보를 더해 Transformer가 받을 입력 shape를 만든다.

mini GPT 과제 1편 - src/bpe.py byte-level BPE 구현 리뷰

cedis — Mon, 1 Jun 2026 11:31:36 +0900

mini GPT 과제 랩 구현 시리즈 1편

이번 구현의 첫 관문은 토크나이저였다. 과제에서는 외부 tokenizer를 금지했기 때문에, 한국어 리뷰 문자열을 직접 UTF-8 byte-level BPE 방식으로 token ID 목록으로 바꿔야 했다.

이 글에서는 실제 구현된 `src/bpe.py`를 기준으로 초기 사전 구성, BPE 학습, 저장/로드, encode/decode 복원을 코드 블록 단위로 본다.

테스트 통과 근거

노트북 실행 결과 기준 `tests/test_bpe.py`는 6개 테스트가 통과했다.

tests/test_bpe.py
- special token ID 고정
- 초기 vocabulary 구성
- save/load 복원
- encode/decode 원문 복원
- get_pad_id/get_bos_id/get_eos_id 확인
- train 이후 vocabulary 증가 확인

결과: 6 passed

1. ID 배치를 먼저 고정한다

토크나이저에서 가장 먼저 정해야 하는 것은 약속이다. 어떤 ID가 padding이고, 어떤 ID가 문장 시작과 끝인지 고정되어 있어야 Dataset과 fine-tuning에서도 같은 기준을 쓸 수 있다.

PAD_TOKEN = "<pad>"
UNK_TOKEN = "<unk>"
BOS_TOKEN = "<bos>"
EOS_TOKEN = "<eos>"

SPECIAL_TOKENS = [PAD_TOKEN, UNK_TOKEN, BOS_TOKEN, EOS_TOKEN]
SPECIAL_IDS = {token: idx for idx, token in enumerate(SPECIAL_TOKENS)}
BYTE_OFFSET = len(SPECIAL_TOKENS)
NUM_BYTES = 256

ID 범위	의미	왜 필요한가
0~3	특수 토큰	padding, unknown, 문장 시작/끝 표시
4~259	byte 0~255	모든 UTF-8 문자열을 최소 단위로 표현
260 이상	BPE merge token	자주 붙는 byte/token 조합을 압축

2. 초기 vocabulary는 모든 byte를 포함한다

`_init_special_tokens()`는 BPE 학습을 하는 함수가 아니다. 모든 문자를 최소한 byte 단위로 표현할 수 있도록 기본 사전을 까는 함수다.

def _init_special_tokens(self):
    self.id_to_token = {}
    self.token_to_id = {}
    self.merges = []

    for idx, token in enumerate(SPECIAL_TOKENS):
        self.id_to_token[idx] = token
        self.token_to_id[token] = idx

    for byte_value in range(NUM_BYTES):
        token_id = BYTE_OFFSET + byte_value
        token = bytes([byte_value])
        self.id_to_token[token_id] = token
        self.token_to_id[token] = token_id

여기서 `bytes([byte_value])`로 저장하는 이유가 중요하다. 나중에 decode할 때 merge token을 원본 byte까지 재귀적으로 펼쳐야 하기 때문이다.

3. train은 가장 자주 나온 pair를 하나씩 합친다

학습은 같은 corpus의 token ID 목록을 계속 압축해 가는 과정이다. 매 반복마다 인접 pair 빈도를 다시 세고, 가장 자주 나온 pair 하나를 새 토큰으로 등록한다.

corpus.encode("utf-8")
문자열을 byte 값으로 바꿈

↓

pair_counts
이웃한 token pair 빈도 계산

↓

best_pair
가장 많이 나온 pair를 새 token ID로 등록

↓

ids 갱신
해당 pair를 새 ID 하나로 치환

while len(self.id_to_token) < self.vocab_size and len(ids) >= 2:
    pair_counts = {}
    for i in range(len(ids) - 1):
        pair = (ids[i], ids[i + 1])
        pair_counts[pair] = pair_counts.get(pair, 0) + 1

    best_pair = max(pair_counts, key=pair_counts.get)
    best_count = pair_counts[best_pair]
    if best_count < 2:
        break

    new_id = len(self.id_to_token)
    self.merges.append(best_pair)
    self.id_to_token[new_id] = best_pair
    self.token_to_id[best_pair] = new_id

`best_count < 2`에서 멈추는 선택도 의미가 있다. 한 번만 나온 조합까지 계속 합치면 반복 패턴을 배운다기보다 corpus를 억지로 외우는 쪽에 가까워진다.

4. encode는 학습된 merge 순서를 재현한다

encode는 새로운 token을 만들면 안 된다. 학습 때 저장한 `self.merges`를 같은 순서로 적용해, 새 문장을 기존 vocabulary 안의 ID 목록으로 바꾼다.

ids = [BYTE_OFFSET + b for b in text.encode("utf-8")]

for pair in self.merges:
    merge_id = self.token_to_id.get(pair)
    if merge_id is None:
        continue
    ids = merge_current_pair(ids, pair, merge_id)

BPE에서 merge 순서가 바뀌면 결과 ID도 달라질 수 있다. 그래서 `save()`와 `load()`는 vocabulary뿐 아니라 merge rule의 순서도 보존해야 한다.

5. decode는 merge token을 byte까지 펼친 뒤 한 번에 복원한다

가장 위험한 실수는 token ID 하나를 곧바로 문자 하나로 생각하는 것이다. merge token 안에는 다른 token ID 두 개가 들어 있고, 그 안에 또 merge token이 들어 있을 수 있다.

def decode(self, ids, skip_special=True):
    byte_values = []

    for token_id in ids:
        if skip_special and token_id in SPECIAL_IDS.values():
            continue
        byte_values.extend(self._token_to_bytes(token_id))

    return bytes(byte_values).decode("utf-8", errors="replace")

실수 방지 포인트

한글은 여러 byte가 모여 한 글자가 된다. 따라서 byte를 중간에 하나씩 문자열로 바꾸면 깨질 수 있고, 원본 byte를 모두 모은 뒤 마지막에 한 번만 UTF-8로 복원해야 한다.

이 구현이 통과한 핵심 계약

`<pad>`, `<unk>`, `<bos>`, `<eos>` ID가 고정되어 있다.
모든 byte 0~255가 기본 vocabulary에 들어간다.
학습한 vocabulary를 저장하고 다시 불러와도 encode/decode가 유지된다.
한글, 영어, 숫자, 문장부호가 섞인 문장도 decode(encode(text))로 복원된다.

다음 글 예고

다음 구현 글에서는 `GPTDataset`과 `InputEmbedding`을 본다. BPE가 만든 token ID 목록을 “다음 토큰 예측” 학습 샘플로 자르고, 모델 입력 벡터로 바꾸는 단계다.

한 줄 정리: 이번 BPE 구현의 핵심은 한글을 byte 단위에서 안전하게 시작하고, 학습된 merge 규칙을 저장해 encode와 decode가 같은 약속을 공유하게 만드는 것이다.

mini GPT 과제 0편 - 구현 결과와 전체 구조 지도

cedis — Mon, 1 Jun 2026 11:31:14 +0900

mini GPT 과제 랩 구현 시리즈 0편

이번 과제는 PyTorch만 사용해 작은 GPT 계열 언어 모델을 직접 구현하는 과제였다. 완성 목표는 ChatGPT 같은 대형 모델이 아니라, LLM의 핵심 부품을 직접 만들어 보며 내부 흐름을 이해하는 것이다.

이 글은 정답 코드를 한 번에 던지는 글이 아니다. 실제 구현 브랜치와 노트북 실행 결과를 기준으로, 어떤 파일이 어떤 책임을 맡았고 어떤 테스트가 그 책임을 확인했는지 먼저 지도처럼 정리한다.

최종 확인 결과

제출 노트북에는 Python 3.11 가상환경과 CUDA 환경에서 실행한 테스트 결과가 저장되어 있었다. 현재 글은 이 실행 결과와 실제 소스 코드를 근거로 작성한다.

구분	결과	의미
전체 테스트	28 passed	필수 구현 함수가 단위 테스트 기준으로 연결됨
실행 환경	Python 3.11, CUDA	과제 권장 환경에서 실행 기록 확인
장기 사전학습 로그	best val loss 약 4.5587	학습 루프와 checkpoint 흐름이 실제로 동작

1. 과제는 여섯 개의 큰 부품으로 나뉜다

파일 이름만 보면 많아 보이지만 구현 흐름은 선형적이다. 토크나이저가 텍스트를 숫자로 바꾸고, 데이터셋이 다음 토큰 예측 샘플을 만들고, 모델이 logits를 만들고, 학습 루프가 loss를 줄인다.

BPE tokenizer
한글 리뷰 문자열을 UTF-8 byte 기반 token ID로 바꾼다.

Dataset / Embedding
입력과 정답을 한 칸 차이로 만들고, token ID를 벡터로 바꾼다.

Multi-Head Attention
각 토큰이 이전 문맥 중 어디를 볼지 계산한다.

GPTModel
LayerNorm, GELU, FeedForward, TransformerBlock을 조립한다.

Pretraining utilities
loss 계산, checkpoint, generate, 학습 루프를 담당한다.

Fine-tuning
GPT backbone 위에 감성 분류용 classification head를 붙인다.

2. 테스트는 무엇을 검증했나

테스트 통과 숫자만 적으면 별 의미가 없다. 중요한 것은 각 테스트가 어떤 책임을 확인했는지다.

테스트 파일	통과 수	핵심 검증
test_bpe.py	6	특수 토큰 ID, save/load, 한글 encode/decode 복원, BPE 학습
test_dataset.py	4	input/target 길이, DataLoader batch shape, embedding 출력 shape
test_attention.py	2	MHA 출력 shape, causal mask에서 미래 위치 attention 차단
test_model.py	7	LayerNorm, GELU, FFN, Block, GPT forward, loss, greedy generation
test_train.py	5	batch loss, loader loss, checkpoint, temperature/top-k generation
test_finetune.py	4	NSMC 분리, 리뷰 padding, classification head shape, train/eval 함수 존재

3. 전체 테스트 로그는 이렇게 읽는다

전체 테스트 통과는 좋은 신호지만, 모델이 좋은 문장을 만든다는 뜻은 아니다. 여기서 보장되는 것은 각 부품이 약속한 shape와 최소 동작 조건을 만족한다는 것이다.

pytest tests/ -v
collected 28 items

test_attention.py  2 passed
test_bpe.py        6 passed
test_dataset.py    4 passed
test_finetune.py   4 passed
test_model.py      7 passed
test_train.py      5 passed

따라서 이 시리즈는 테스트를 단순히 “통과했다”로 끝내지 않는다. 각 편에서 “이 테스트가 무엇을 막아주는가”까지 같이 볼 것이다.

4. 학습 로그는 결과보다 한계를 같이 봐야 한다

노트북에는 실제 CUDA 환경에서 사전학습을 돌린 기록이 남아 있다. loss는 줄었고 checkpoint를 이어서 학습한 흔적도 있다. 다만 생성 샘플에는 깨진 문자와 어색한 표현이 남아 있었다.

확인된 성과

train loss와 validation loss가 장기 실행에서 감소했다.

주의할 한계

loss 감소가 곧 자연스러운 한국어 생성 품질을 의미하지는 않는다.

다음 분석 지점

vocab 크기, 데이터 양, 모델 크기, 학습 시간의 영향을 따로 봐야 한다.

latest epoch: 1390
global_step: 305800
train_loss: 3.9400
val_loss: 4.5616
best_val_loss: 4.5587

이번 글에서 기억할 것

과제는 BPE부터 fine-tuning까지 GPT 흐름을 작은 부품으로 나누어 구현한다.
전체 테스트 28개 통과는 필수 부품의 최소 동작 계약을 만족했다는 의미다.
학습 로그는 구현이 실제로 돌아간 근거지만, 생성 품질까지 자동으로 보장하지는 않는다.

스스로 점검

BPE 테스트에서 한글 encode/decode 복원을 확인해야 하는 이유는 무엇인가?
attention 테스트에서 causal mask를 확인하지 않으면 어떤 문제가 숨어 있을 수 있는가?
fine-tuning에서 LM head와 classification head는 왜 역할이 다른가?

다음 글 예고

다음 글에서는 첫 구현 항목인 byte-level BPE를 본다. 핵심은 “한글을 깨지 않고 숫자 ID로 바꾸고 다시 원문으로 복원하는 법”이다.

한 줄 정리: 이번 과제의 성과는 한 번에 완성된 챗봇이 아니라, GPT를 이루는 부품들이 테스트와 학습 로그로 연결되었다는 점이다.

mini GPT 공부 7편 - GPT를 감성 분류기로 바꾸는 미세조정

cedis — Mon, 1 Jun 2026 11:30:48 +0900

밑바닥부터 만드는 mini GPT 공부 시리즈 7편

사전학습된 GPT는 기본적으로 다음 토큰을 맞히는 모델이다. 하지만 과제의 마지막 단계에서는 NSMC 리뷰가 긍정인지 부정인지 맞히는 분류 모델로 바꾼다.

여기서 핵심은 GPT 전체를 버리는 것이 아니다. 텍스트를 읽어 hidden state를 만드는 backbone은 그대로 쓰고, 마지막 목적에 맞는 classification head를 새로 붙인다.

LM head와 classification head

구분	출력	목적
LM head	vocab_size개 점수	다음 토큰 예측
classification head	2개 점수	부정/긍정 분류

이번 단계의 입력과 정답

{"text": "배우들의 연기가 좋고 끝까지 몰입됐다.", "label": 1}
{"text": "전개가 지루하고 결말도 아쉬웠다.", "label": 0}

사전학습에서는 문장 안의 다음 token이 정답이었다. 미세조정에서는 문장 하나에 label 하나가 붙는다. 이 차이 때문에 출력층도 바뀌어야 한다.

1. 리뷰 전체를 대표하는 벡터가 필요하다

GPT backbone은 각 token 위치마다 hidden state를 만든다. 하지만 감성 분류는 리뷰 전체에 대해 하나의 label만 필요하다. 그래서 여러 hidden state 중 문장을 대표할 하나를 골라 classifier에 넣는다.

리뷰 token IDs

↓ GPT backbone

각 token의 hidden state

↓ 마지막 유효 token 선택

문장 대표 벡터

↓ Linear classifier

부정/긍정 logits

2. classification head는 vocab이 아니라 label을 본다

사전학습의 `lm_head`는 hidden state 하나를 `vocab_size`개의 점수로 바꾼다. 감성 분류에서는 “다음 token 후보 전체”가 필요하지 않다. 필요한 것은 부정과 긍정 두 개의 점수다.

문장 대표 hidden state: (B, C)
classifier: Linear(C, 2)
logits: (B, 2)

그래서 GPT backbone은 재사용하지만, 마지막 head는 과제 목적에 맞게 바꿔 끼운다.

3. padding은 분류 위치 선택에서 제외해야 한다

리뷰 길이는 제각각이다. batch로 묶기 위해 짧은 리뷰는 pad token으로 채운다. 이때 마지막 위치를 무조건 고르면 pad의 hidden state를 대표 벡터로 쓰는 실수가 생긴다.

핵심 판단

마지막 token이 아니라, padding이 아닌 마지막 유효 token의 hidden state를 골라야 한다.

위치 선택 예시

input_ids:
[좋다, 영화, <eos>, <pad>, <pad>]

대표 위치:
마지막 index 4가 아니라, 마지막 유효 token인 <eos> 위치 2

4. 미세조정에서 학습되는 것은 “분류 기준”이다

backbone은 문장을 hidden state로 바꾸는 역할을 한다. classifier는 그 hidden state를 보고 부정/긍정 기준을 학습한다. 이때 loss는 다음 token 예측용 cross entropy가 아니라 label 0/1에 대한 cross entropy다.

사전학습

각 위치마다 다음 token ID를 맞힌다.

미세조정

리뷰 전체의 label 0/1을 맞힌다.

스스로 점검

감성 분류에서 LM head를 그대로 쓰면 왜 맞지 않는가?
리뷰 전체 label을 예측하려면 token별 hidden state 중 무엇을 선택해야 하는가?
padding 위치를 대표 벡터로 쓰면 어떤 문제가 생기는가?
사전학습 loss와 분류 미세조정 loss는 무엇이 다른가?

시리즈 마무리

여기까지 오면 mini GPT 구현의 큰 흐름은 연결된다. 텍스트는 BPE로 token ID가 되고, Dataset과 Embedding을 거쳐 attention과 Transformer block을 통과하고, 사전학습 또는 분류 미세조정 목표에 맞게 loss를 계산한다.

한 줄 정리: 미세조정은 GPT backbone의 문장 이해 흐름을 재사용하고, 마지막 목적에 맞는 작은 head를 새로 붙이는 과정이다.

mini GPT 공부 6편 - 사전학습, loss, 생성, checkpoint

cedis — Mon, 1 Jun 2026 11:30:33 +0900

밑바닥부터 만드는 mini GPT 공부 시리즈 6편

GPTModel이 logits를 만들 수 있게 되면, 이제 학습 루프가 필요하다. 사전학습의 목적은 다음 토큰 예측 loss를 줄이는 것이다.

이때 loss 계산, optimizer update, 검증 loss, 텍스트 생성, checkpoint는 따로 떨어진 기능처럼 보이지만 하나의 학습 루프 안에서 연결된다.

사전학습 루프

batch
-> model(input, targets)
-> cross entropy loss
-> loss.backward()
-> optimizer.step()
-> 주기적으로 validation loss 확인
-> 주기적으로 checkpoint 저장

학습과 생성은 같은 모델을 다르게 쓰는 일이다

구분	입력	출력 사용법
사전학습	input IDs + target IDs	모든 위치의 logits로 loss 계산
생성	지금까지 만든 input IDs	마지막 위치 logits에서 다음 token 선택

1. loss는 다음 토큰 예측이 얼마나 틀렸는지다

모델 출력 logits의 shape는 `(batch_size, seq_len, vocab_size)`다. 각 위치마다 vocabulary 전체에 대한 점수를 낸다. target은 `(batch_size, seq_len)`이고, 각 위치의 정답 token ID를 가진다.

cross entropy 계산 전 shape 변환

logits:  (B, T, V) -> (B*T, V)
targets: (B, T)    -> (B*T)

2. 생성은 마지막 위치의 logits에서 다음 token을 고르는 일이다

텍스트 생성은 학습과 다르게 target이 없다. 현재까지 만든 token ID를 모델에 넣고, 마지막 위치의 logits에서 다음 token을 고른다. 그 token을 뒤에 붙이고 다시 반복한다.

현재 문맥 token IDs

↓

모델 forward

↓

마지막 위치 logits 선택

↓

argmax 또는 sampling으로 다음 token 선택

temperature가 0이면 가장 높은 점수의 token을 고르는 greedy 방식이 된다. temperature가 크면 확률적으로 더 다양한 token을 고를 수 있다. top-k는 후보를 상위 k개로 제한한다.

생성 설정을 읽는 감각

`temperature = 0`: 가장 그럴듯한 token만 고른다. 결과는 안정적이지만 반복적일 수 있다.
`temperature > 0`: 확률적으로 뽑는다. 다양해지지만 이상한 token도 나올 수 있다.
`top_k`: 후보를 줄여 너무 낮은 확률의 token이 뽑히는 일을 막는다.

3. checkpoint는 가중치만 저장하는 것이 아니다

Colab 학습은 끊길 수 있다. 이어서 학습하려면 모델 가중치뿐 아니라 optimizer 상태, epoch, global step도 함께 저장해야 한다.

저장 항목	이유
model state	현재 학습된 가중치 복원
optimizer state	Adam 같은 optimizer 내부 상태 복원
epoch / global_step	어디까지 학습했는지 이어가기

loss 로그를 읽을 때 주의할 점

loss가 줄어드는 것은 모델이 다음 토큰 예측을 더 잘하고 있다는 신호다. 하지만 작은 모델과 제한된 데이터에서는 자연스러운 한국어 생성 품질까지 바로 보장하지 않는다. loss와 생성 샘플을 함께 봐야 한다.

4. train loss와 validation loss는 서로 다른 질문이다

train loss는 모델이 학습에 사용한 데이터에 얼마나 맞춰지고 있는지를 본다. validation loss는 학습에 직접 쓰지 않은 데이터에서도 비슷하게 동작하는지를 본다.

둘 다 감소

학습이 정상적으로 진행 중일 가능성이 높다.

train만 감소

훈련 데이터에만 맞춰지는 과적합을 의심한다.

둘 다 정체

모델 크기, 학습률, 데이터, tokenizer 설정을 다시 본다.

스스로 점검

cross entropy 전에 logits와 targets를 왜 펼치는가?
temperature와 top-k는 생성 결과에 어떤 영향을 주는가?
checkpoint에 optimizer state가 필요한 이유는 무엇인가?

다음 글 예고

다음 글에서는 GPT backbone 위에 classification head를 붙여 감성 분류 모델로 바꾸는 fine-tuning 흐름을 본다.

한 줄 정리: 사전학습은 다음 토큰 예측 loss를 줄이는 반복이고, 생성과 checkpoint는 그 학습 상태를 관찰하고 이어가기 위한 도구다.

mini GPT 공부 5편 - GPT Block을 이루는 LayerNorm, GELU, Residual

cedis — Mon, 1 Jun 2026 11:30:05 +0900

밑바닥부터 만드는 mini GPT 공부 시리즈 5편

attention만으로 GPT 모델이 완성되지는 않는다. attention 결과를 안정적으로 쌓고, 각 위치별로 비선형 변환을 수행하고, 깊은 층에서도 신호가 흐르도록 만드는 장치들이 필요하다.

이 글에서는 GPT block을 이루는 핵심 부품인 LayerNorm, GELU, FeedForward, residual connection을 한 흐름으로 정리한다.

GPT block의 기본 흐름

x
-> LayerNorm
-> Causal Multi-Head Attention
-> residual add
-> LayerNorm
-> FeedForward
-> residual add

이 흐름에서 가장 중요한 규칙은 shape가 계속 `(B, T, C)`로 유지된다는 점이다. 그래야 원래 입력과 새 계산 결과를 residual로 더할 수 있다.

1. LayerNorm은 각 토큰 벡터를 안정화한다

LayerNorm은 마지막 차원, 즉 한 토큰의 embedding 벡터 내부를 기준으로 평균과 분산을 맞춘다. batch 전체를 기준으로 보는 BatchNorm과 다르게, 문장 길이나 batch 크기가 바뀌어도 토큰 단위로 동작한다.

정규화	기준	GPT에서의 감각
LayerNorm	각 토큰 벡터의 마지막 차원	한 토큰의 표현을 안정화
BatchNorm	batch 방향 통계	언어 모델보다 CNN 등에서 더 익숙한 방식

2. GELU는 딱 잘라 버리지 않는 비선형 함수다

FeedForward 안에는 보통 GELU가 들어간다. ReLU가 0보다 작으면 바로 0으로 잘라내는 함수라면, GELU는 값을 더 부드럽게 통과시키거나 줄인다. 여기서 중요한 것은 이름을 외우는 것이 아니라, GPT block 안에서 “선형층만 반복되는 구조”를 막는 비선형 변환이 필요하다는 점이다.

ReLU와 GELU를 감으로 구분하기

ReLU

음수는 0, 양수는 그대로. 단순하고 빠르다.

GELU

입력을 확률적으로 부드럽게 통과시키는 느낌에 가깝다.

3. FeedForward는 각 위치별 작은 MLP다

attention이 토큰들 사이의 관계를 섞는다면, FeedForward는 각 위치의 벡터를 더 풍부한 표현으로 바꾼다. 보통 `d_model -> 4*d_model -> d_model` 구조를 사용한다.

d_model
현재 토큰 표현

↓ Linear

4 * d_model
표현 공간 확장

↓ GELU

d_model
다음 block이 받을 크기로 복귀

4. Residual connection은 원래 신호를 살려둔다

Transformer block은 attention이나 FeedForward 결과를 그대로 다음으로 넘기지 않는다. 원래 입력 `x`에 새로 계산한 결과를 더한다.

x = x + attention(layer_norm(x))
x = x + feed_forward(layer_norm(x))

이렇게 하면 깊은 모델에서도 정보와 gradient가 더 잘 흐른다. 처음 공부할 때 residual을 단순한 더하기로만 보면 안 된다. 깊은 층을 안정적으로 쌓기 위한 핵심 통로다.

5. pre-norm 구조로 읽으면 block이 덜 헷갈린다

이번 구현은 attention이나 FeedForward에 넣기 전에 먼저 LayerNorm을 적용한다. 그래서 흐름을 `정규화 -> 계산 -> 원래 값에 더하기`로 읽으면 된다.

attention branch
x + attention(layer_norm(x))

feed-forward branch
x + feed_forward(layer_norm(x))

이 관점으로 보면 GPT block은 낯선 부품 묶음이 아니라, 같은 패턴을 두 번 반복하는 구조가 된다.

이번 글에서 기억할 것

LayerNorm은 토큰 벡터의 스케일을 안정화한다.
GELU는 FeedForward 안에서 비선형 변환을 담당한다.
FeedForward는 각 위치의 표현을 비선형으로 변환한다.
Residual connection은 깊은 block을 쌓을 수 있게 하는 정보 통로다.

스스로 점검

LayerNorm은 어느 차원을 기준으로 평균과 분산을 계산하는가?
GELU가 없다면 FeedForward는 어떤 종류의 변환만 반복하게 되는가?
FeedForward가 `4*d_model`로 확장했다가 다시 줄어드는 이유는 무엇인가?
Residual connection이 없다면 깊은 모델에서 어떤 문제가 커질 수 있는가?

다음 글 예고

다음 글에서는 loss 계산, 생성, checkpoint를 포함한 사전학습 흐름을 정리한다.

한 줄 정리: GPT block은 attention 하나가 아니라, 정규화와 비선형 변환과 residual connection이 함께 묶인 반복 가능한 층이다.

mini GPT 공부 4편 - Multi-Head Attention은 왜 head를 나누는가

cedis — Sun, 31 May 2026 00:19:18 +0900

밑바닥부터 만드는 mini GPT 공부 시리즈 4편

self-attention 하나로도 각 토큰이 문맥을 참고할 수 있다. 그런데 GPT는 보통 attention을 하나만 쓰지 않고 여러 head로 나눈다.

핵심은 여러 관점이다. 같은 문장을 보더라도 한 head는 가까운 단어 관계를, 다른 head는 문장 전체 분위기를, 또 다른 head는 특정 패턴을 더 잘 보도록 학습될 수 있다.

이번 글에서 다루는 것

head를 나눈다는 말의 shape 의미
`d_model`과 `n_heads`, `head_dim`의 관계
각 head 결과를 다시 합치는 이유
Multi-Head Attention을 shape 흐름으로 읽는 법

1. head는 embedding 차원을 나눈 작은 attention 공간이다

입력 벡터의 마지막 차원이 `d_model`이라고 하자. head를 4개로 나누면 각 head는 `d_model / 4` 크기의 작은 공간에서 attention을 계산한다.

예: d_model = 128, n_heads = 4

head 1
32차원

head 2
32차원

head 3
32차원

head 4
32차원

그래서 `d_model`은 `n_heads`로 나누어떨어져야 한다. 나누어떨어지지 않으면 각 head가 같은 크기의 `head_dim`을 가질 수 없다.

2. shape는 이렇게 움직인다

Multi-Head Attention을 이해할 때는 수식보다 shape를 먼저 보는 편이 좋다. 입력은 `(B, T, C)`이고, head를 나누면 `(B, H, T, D)`가 된다.

x:          (B, T, C)
q, k, v:    (B, T, C)
split head: (B, H, T, D)
score:      (B, H, T, T)
context:    (B, H, T, D)
merge:      (B, T, C)

여기서 `T x T`는 각 위치가 다른 위치를 얼마나 볼지 나타내는 attention weight 행렬이다. causal mask도 바로 이 `T x T` 위에서 적용된다.

숫자를 넣은 예

B = 2, T = 5, C = 128, H = 4
D = C / H = 32

x:      (2, 5, 128)
split:  (2, 4, 5, 32)
score:  (2, 4, 5, 5)
merge:  (2, 5, 128)

head를 나눠도 최종 출력 차원은 원래 C로 돌아온다. 다음 Transformer block이 같은 형식의 입력을 받아야 하기 때문이다.

3. 여러 head 결과는 다시 하나의 벡터로 합쳐진다

head를 나누는 것은 모델 출력을 여러 갈래로 분리해서 끝내겠다는 뜻이 아니다. 각 head가 계산한 문맥 벡터를 다시 이어 붙여 원래 `d_model` 크기로 되돌린다.

head별 attention - 각 head가 자기 공간에서 문맥 계산

↓

concat - head 결과를 마지막 차원으로 이어 붙임

↓

output projection - 다시 다음 layer가 쓰기 좋은 `d_model` 표현으로 섞음

head를 나누는 이유를 한 문장으로

Multi-Head Attention은 하나의 큰 attention으로 모든 관계를 한 번에 보려 하지 않고, embedding 차원을 여러 작은 관점으로 나누어 각 관점에서 문맥을 본 뒤 다시 합치는 방식이다.

구현할 때 자주 나는 실수

`view` 뒤에 head 차원을 앞으로 옮기지 않으면 score shape가 맞지 않는다.
`transpose` 이후에는 메모리가 연속적이지 않을 수 있어, 병합 전 `contiguous()`가 필요할 수 있다.
head를 합친 뒤에는 output projection을 거쳐 head별 결과를 다시 섞는다.

스스로 점검

`d_model`이 `n_heads`로 나누어떨어져야 하는 이유는 무엇인가?
attention weight의 shape가 `(B, H, T, T)`가 되는 이유는 무엇인가?
head를 나눈 뒤 왜 다시 합쳐야 하는가?

다음 글 예고

다음 글에서는 LayerNorm, GELU, FeedForward, residual connection을 묶어 GPT Block을 만드는 흐름을 본다.

한 줄 정리: Multi-Head Attention은 여러 관점으로 문맥을 본 뒤, 그 결과를 다시 하나의 표현으로 합치는 구조다.

mini GPT 공부 3편 - Self-Attention과 Causal Mask

cedis — Sun, 31 May 2026 00:18:57 +0900

밑바닥부터 만드는 mini GPT 공부 시리즈 3편

embedding까지 끝나면 각 토큰은 벡터가 된다. 하지만 벡터가 되었다고 해서 문맥을 이해하는 것은 아니다. 각 위치의 토큰이 앞뒤 토큰과 어떤 관계를 맺는지 계산해야 한다.

self-attention은 같은 문장 안의 토큰들이 서로를 참고하는 방식이다. GPT에서는 여기에 causal mask가 붙어서 현재 토큰이 미래 토큰을 보지 못하게 만든다.

이번 글에서 다루는 것

attention이 “어떤 토큰을 얼마나 참고할지” 정하는 방식
Query, Key, Value를 너무 어렵게 보지 않는 방법
causal mask가 왜 다음 토큰 예측에서 필수인지
attention score, softmax, weighted sum의 흐름

1. Attention은 참고 비율을 계산한다

문장 안의 각 토큰은 혼자 의미를 가지지 않는다. “좋았다”라는 토큰은 앞에 “영화가”, “정말” 같은 토큰이 있을 때 더 분명해진다. attention은 현재 위치가 다른 위치를 얼마나 참고할지 비율을 계산한다.

현재 토큰: “좋았다”

영화가 참고 비율 0.20

정말 참고 비율 0.35

좋았다 참고 비율 0.45

실제 값은 사람이 정하지 않는다. Query와 Key의 유사도를 계산하고 softmax를 통과시켜 비율로 만든다.

작은 숫자로 보면

현재 토큰의 score
영화가: 1.0
정말:   2.0
좋았다: 2.4

softmax 뒤 참고 비율
영화가: 0.12
정말:   0.33
좋았다: 0.55

score는 비교용 점수이고, softmax 뒤의 값은 합이 1인 참고 비율이다. 이 비율로 Value를 섞으면 현재 위치의 문맥 벡터가 된다.

2. Query, Key, Value는 역할 이름이다

Query, Key, Value라는 이름 때문에 처음에는 어렵게 느껴진다. 하지만 구현 관점에서는 같은 입력 벡터를 세 개의 다른 선형층에 통과시킨 결과다.

이름	직관	계산에서 하는 일
Query	내가 찾고 싶은 기준	Key와 점곱해 attention score를 만듦
Key	각 토큰이 가진 검색용 표지	Query와 얼마나 맞는지 비교됨
Value	실제로 가져올 정보	attention weight와 곱해져 문맥 벡터가 됨

3. Causal mask는 미래 정답을 가린다

GPT는 다음 토큰을 맞히는 모델이다. 그런데 학습 중 현재 위치가 미래 토큰을 볼 수 있다면, 정답을 미리 훔쳐보는 셈이 된다. causal mask는 이 부정행위를 막는다.

볼 수 있는 위치 표시

토큰 0	보기 가능	가림	가림	가림
토큰 1	보기 가능	보기 가능	가림	가림
토큰 2	보기 가능	보기 가능	보기 가능	가림

구현에서는 보통 현재 위치보다 오른쪽 위 영역을 `-inf`로 채운다. 그러면 softmax를 통과한 뒤 그 위치의 확률이 0에 가까워진다.

attention 흐름 요약

x
-> Q, K, V
-> Q @ K.T / sqrt(head_dim)
-> causal mask
-> softmax
-> attention weight @ V
-> context vector

헷갈리기 쉬운 구분

score는 아직 확률이 아니다. softmax 전의 비교 점수다.
mask는 Value를 지우는 것이 아니라 score 단계에서 미래 위치를 막는다.
최종 출력은 attention weight 자체가 아니라, 그 weight로 Value를 섞은 벡터다.

스스로 점검

Value는 언제 사용되는가?
causal mask가 없다면 train loss는 좋아 보일 수 있지만 왜 위험한가?
attention score를 softmax에 넣는 이유는 무엇인가?

다음 글 예고

다음 글에서는 여러 개의 attention head를 병렬로 사용하는 Multi-Head Attention을 정리한다.

한 줄 정리: self-attention은 문맥 안에서 참고 비율을 계산하고, causal mask는 현재 토큰이 미래 정답을 보지 못하게 막는다.

mini GPT 공부 2편 - Dataset과 Embedding, 다음 토큰 예측 샘플 만들기

cedis — Sun, 31 May 2026 00:18:44 +0900

밑바닥부터 만드는 mini GPT 공부 시리즈 2편

BPE가 문장을 token ID 목록으로 바꾸었다면, 다음 단계는 그 목록을 학습 샘플로 자르는 일이다. GPT는 현재까지의 토큰을 보고 다음 토큰을 맞히도록 학습한다.

이 단계에서 자주 헷갈리는 지점은 두 가지다. 첫째, input과 target은 길이가 같지만 한 칸 밀려 있다. 둘째, token ID는 그 자체로 의미 벡터가 아니므로 embedding을 거쳐야 한다.

이번 글에서 다루는 것

GPTDataset이 input과 target을 어떻게 만드는지
context_length와 stride가 샘플 수에 어떤 영향을 주는지
token embedding과 position embedding을 왜 더하는지
최종 입력 shape가 왜 `(batch_size, seq_len, emb_dim)`인지

1. 다음 토큰 예측은 input과 target을 한 칸 어긋나게 만든다

token ID 목록이 `[10, 11, 12, 13]`이고 context 길이가 3이라고 하자. 모델은 `[10, 11, 12]`를 보고 `[11, 12, 13]`을 맞히도록 훈련된다.

한 칸 밀린 학습 샘플

input

10 11 12

target

11 12 13

이 구조는 한 번의 forward에서 여러 위치의 다음 토큰 예측을 동시에 학습하게 만든다. 첫 번째 위치는 10 다음 11을, 두 번째 위치는 11 다음 12를, 세 번째 위치는 12 다음 13을 맞히는 식이다.

2. context_length는 모델이 한 번에 보는 문맥 길이다

context_length는 한 샘플 안에 들어가는 토큰 수다. 너무 짧으면 긴 문맥을 배우기 어렵고, 너무 길면 계산량이 늘어난다. 이번 과제에서는 처음부터 크게 잡지 않고 작은 설정으로 동작을 확인한 뒤 키우는 방식이 권장된다.

값	의미	주의점
context_length	한 샘플의 input 길이	target까지 만들려면 실제로는 `context_length + 1`개 토큰이 필요
stride	다음 샘플로 이동하는 간격	작을수록 샘플은 많아지지만 겹침도 늘어남
batch_size	한 번에 묶어 계산하는 샘플 수	GPU 메모리와 학습 안정성에 영향

3. token ID는 embedding을 거쳐야 의미 있는 계산 대상이 된다

token ID 10과 token ID 11은 숫자 크기 자체에 의미가 있는 것이 아니다. 11이 10보다 크다고 해서 더 중요한 토큰이라는 뜻은 아니다. 그래서 ID를 바로 계산하지 않고 embedding table에서 벡터를 꺼낸다.

token ID
[10, 11, 12]

↓ token embedding table 조회

token embedding
각 token을 emb_dim 길이의 벡터로 변환

+ position embedding

모델 입력
토큰 의미와 위치 정보를 함께 가진 벡터

position embedding이 필요한 이유도 여기서 나온다. 같은 token이라도 문장 안에서 어디에 놓였는지에 따라 역할이 달라질 수 있기 때문이다.

shape로 기억하기

이 단계의 최종 출력 shape는 다음처럼 기억하면 된다.

input token IDs: (batch_size, seq_len)
token embedding: (batch_size, seq_len, emb_dim)
position embedding: (seq_len, emb_dim)
final input: (batch_size, seq_len, emb_dim)

스스로 점검

target이 input보다 한 칸 뒤로 밀리는 이유는 무엇인가?
token ID 숫자 자체를 바로 모델 입력으로 쓰지 않는 이유는 무엇인가?
position embedding이 없다면 같은 토큰의 위치 차이를 어떻게 알 수 있을까?

다음 글 예고

다음 글에서는 attention을 다룬다. 핵심은 각 토큰이 문맥 안의 다른 토큰을 어떤 비율로 참고하는지 계산하는 방식이다.

한 줄 정리: Dataset은 다음 토큰 예측 문제를 만들고, Embedding은 token ID를 모델이 계산할 수 있는 위치 포함 벡터로 바꾼다.

mini GPT 공부 1편 - 한글 토큰화와 byte-level BPE

cedis — Sun, 31 May 2026 00:18:28 +0900

밑바닥부터 만드는 mini GPT 공부 시리즈 1편

GPT는 문자열을 직접 읽지 않는다. 먼저 문장을 숫자 ID의 목록으로 바꾼다. 이 변환을 담당하는 부품이 토크나이저다.

이번 과제에서 중요한 지점은 교재처럼 이미 만들어진 토크나이저를 쓰지 않는다는 점이다. 특히 한글 리뷰 데이터를 다루기 때문에, 공백 기준 단어 분리보다 더 낮은 단위에서 시작해야 한다.

이번 글에서 다루는 것

토큰화가 왜 GPT 구현의 첫 단계인지
한글에서 공백 기준 토큰화가 왜 쉽게 무너지는지
UTF-8 byte에서 시작하는 BPE가 어떤 문제를 해결하는지
encode와 decode에서 가장 조심해야 할 복원 원칙

1. 토큰화는 문장을 모델의 입력으로 바꾸는 번역기다

사람은 “이 영화는 정말 좋았다”를 문장으로 읽는다. 하지만 모델은 이 문장을 그대로 받지 못한다. 모델이 처리할 수 있는 것은 정수 ID이고, 그 ID는 다시 embedding layer를 통해 벡터가 된다.

문장
이 영화는 정말 좋았다

↓ tokenizer.encode()

토큰 ID
[2, 431, 128, 87, ... , 3]

↓ embedding

벡터
모델이 계산할 수 있는 실수 배열

그래서 토크나이저가 깨지면 그 뒤의 모델은 아무리 잘 만들어도 출발점부터 잘못된다. 특히 decode했을 때 원문이 복원되지 않는다면, 학습과 생성 결과를 해석하기 어렵다.

2. 한글은 공백 기준으로만 보기 어렵다

영어는 공백으로 단어가 비교적 잘 나뉘는 편이다. 하지만 한국어는 조사와 어미가 붙어서 같은 뿌리의 표현도 계속 다른 모양으로 나타난다.

표현	사람의 감각	단순 단어 토큰화의 문제
재미있다	기본 표현	별도 단어로 등록 필요
재미있었다	과거형	처음 보면 새로운 단어처럼 처리
재미있네요	감상 표현	어휘에 없으면 알 수 없는 토큰이 늘어남

byte-level BPE는 이 문제를 완전히 해결하는 만능 해법은 아니다. 다만 모든 문자열을 최소한 byte 단위로 표현할 수 있게 만들어, 처음 보는 표현도 처리할 수 있는 출발점을 만든다.

3. 한글 한 글자는 byte 여러 개다

사람에게 “한”은 한 글자다. 하지만 UTF-8로 저장하면 여러 byte로 표현된다. byte-level 토크나이저는 바로 이 byte 목록에서 시작한다.

"한"의 byte 관찰

문자: 한 → 237 149 156

이때 byte 값 0~255를 그대로 모델 ID로 쓰지 않고, 앞쪽 ID는 특수 토큰에 배정한다. 과제에서는 0~3을 특수 토큰으로 고정하고, byte 0~255는 ID 4~259에 둔다.

4. BPE는 자주 붙는 조각을 합쳐간다

byte에서 시작하면 모든 문자를 표현할 수 있지만, 너무 잘게 쪼개진다. BPE는 여기서 자주 붙어 나오는 이웃한 토큰 쌍을 하나의 새 토큰으로 합쳐간다.

1단계 byte token 목록에서 시작한다.

2단계 이웃한 token pair의 빈도를 센다.

3단계 가장 자주 나온 pair를 새 token으로 등록한다.

4단계 같은 pair를 새 token 하나로 바꾸고 다시 반복한다.

여기서 중요한 것은 merge 순서다. 학습할 때 어떤 pair를 어떤 순서로 합쳤는지 저장해야 나중에 새로운 문장을 encode할 때 같은 규칙을 재현할 수 있다.

decode에서 가장 조심할 점

byte를 하나씩 문자로 바꾸면 한글이 깨질 수 있다. merge token을 원래 byte까지 모두 펼친 뒤, 마지막에 모은 byte 배열 전체를 한 번에 UTF-8로 decode해야 한다.

스스로 점검

한국어에서 공백 기준 토큰화가 쉽게 부족해지는 이유는 무엇인가?
byte 0이 token ID 0이 아니라 ID 4가 되는 이유는 무엇인가?
decode할 때 byte를 마지막에 한 번만 UTF-8로 복원해야 하는 이유는 무엇인가?

다음 글 예고

다음 책 공부 글에서는 Dataset과 Embedding을 본다. 핵심은 “현재 토큰을 보고 다음 토큰을 맞히는 샘플”을 어떻게 만드는지다.

한 줄 정리: byte-level BPE는 한글을 포함한 모든 문자열을 최소 단위에서 안전하게 표현하고, 자주 붙는 조각을 합쳐 모델이 다루기 좋은 토큰으로 만드는 방법이다.

cedis 님의 블로그

mini GPT 과제 2편 - GPTDataset과 InputEmbedding 구현 리뷰

GPTDataset과 InputEmbedding 구현 리뷰

테스트 통과 근거

1. Dataset 길이는 context_length와 stride로 결정된다

2. __getitem__은 input과 target을 한 칸 차이로 만든다

3. create_dataloader는 Dataset을 batch 단위로 감싼다

4. InputEmbedding은 token embedding과 position embedding을 더한다

이 구현이 통과한 핵심 계약

다음 글 예고

mini GPT 과제 1편 - src/bpe.py byte-level BPE 구현 리뷰

테스트 통과 근거

1. ID 배치를 먼저 고정한다

2. 초기 vocabulary는 모든 byte를 포함한다

3. train은 가장 자주 나온 pair를 하나씩 합친다

4. encode는 학습된 merge 순서를 재현한다

5. decode는 merge token을 byte까지 펼친 뒤 한 번에 복원한다

이 구현이 통과한 핵심 계약

다음 글 예고

mini GPT 과제 0편 - 구현 결과와 전체 구조 지도

최종 확인 결과

1. 과제는 여섯 개의 큰 부품으로 나뉜다

2. 테스트는 무엇을 검증했나

3. 전체 테스트 로그는 이렇게 읽는다

4. 학습 로그는 결과보다 한계를 같이 봐야 한다

이번 글에서 기억할 것

스스로 점검

다음 글 예고

mini GPT 공부 7편 - GPT를 감성 분류기로 바꾸는 미세조정

LM head와 classification head

이번 단계의 입력과 정답

1. 리뷰 전체를 대표하는 벡터가 필요하다

2. classification head는 vocab이 아니라 label을 본다

3. padding은 분류 위치 선택에서 제외해야 한다

4. 미세조정에서 학습되는 것은 “분류 기준”이다

스스로 점검

시리즈 마무리

mini GPT 공부 6편 - 사전학습, loss, 생성, checkpoint

사전학습 루프

학습과 생성은 같은 모델을 다르게 쓰는 일이다

1. loss는 다음 토큰 예측이 얼마나 틀렸는지다

2. 생성은 마지막 위치의 logits에서 다음 token을 고르는 일이다

3. checkpoint는 가중치만 저장하는 것이 아니다

loss 로그를 읽을 때 주의할 점

4. train loss와 validation loss는 서로 다른 질문이다

스스로 점검

다음 글 예고

mini GPT 공부 5편 - GPT Block을 이루는 LayerNorm, GELU, Residual

GPT block의 기본 흐름

1. LayerNorm은 각 토큰 벡터를 안정화한다

2. GELU는 딱 잘라 버리지 않는 비선형 함수다

3. FeedForward는 각 위치별 작은 MLP다

4. Residual connection은 원래 신호를 살려둔다

5. pre-norm 구조로 읽으면 block이 덜 헷갈린다

이번 글에서 기억할 것

스스로 점검

다음 글 예고

mini GPT 공부 4편 - Multi-Head Attention은 왜 head를 나누는가

이번 글에서 다루는 것

1. head는 embedding 차원을 나눈 작은 attention 공간이다

2. shape는 이렇게 움직인다

3. 여러 head 결과는 다시 하나의 벡터로 합쳐진다

head를 나누는 이유를 한 문장으로

구현할 때 자주 나는 실수

스스로 점검

다음 글 예고

mini GPT 공부 3편 - Self-Attention과 Causal Mask

이번 글에서 다루는 것

1. Attention은 참고 비율을 계산한다

2. Query, Key, Value는 역할 이름이다

3. Causal mask는 미래 정답을 가린다

attention 흐름 요약

헷갈리기 쉬운 구분

스스로 점검

다음 글 예고

mini GPT 공부 2편 - Dataset과 Embedding, 다음 토큰 예측 샘플 만들기

이번 글에서 다루는 것

1. 다음 토큰 예측은 input과 target을 한 칸 어긋나게 만든다

2. context_length는 모델이 한 번에 보는 문맥 길이다

3. token ID는 embedding을 거쳐야 의미 있는 계산 대상이 된다

2. getitem은 input과 target을 한 칸 차이로 만든다