LLM Basics

LLM 기초 - 대형 언어 모델의 원리와 시스템 관점

Tokenization · Transformer · Next-token Prediction · Training/Post-training · Inference · KV Cache · Serving

개요

LLM(Large Language Model, 대형 언어 모델)은 앞선 토큰들의 문맥을 조건으로 다음 토큰의 확률분포를 예측하는 모델입니다. 학습 목표 자체는 단순하지만, 대규모 데이터, 충분한 파라미터, Transformer의 문맥 처리 능력이 결합되면 번역, 요약, 질의응답, 코드 생성처럼 다양한 과제를 하나의 인터페이스, 즉 텍스트 입력과 생성으로 처리할 수 있습니다.

실제 제품의 LLM은 모델 하나만을 뜻하지 않습니다. 토크나이저, 모델 가중치, 프롬프트 템플릿, 샘플러, 안전 정책, 검색 또는 도구 호출, 추론 엔진과 GPU 메모리 관리자가 함께 동작하는 시스템입니다. 따라서 "모델이 답을 생성한다"는 설명은 맞지만, 지연 시간과 비용, 품질은 이 전체 경로에서 결정됩니다.

시스템 관점에서 가장 중요한 구분은 추론의 두 단계입니다. 프롬프트 전체를 처리하는 prefill은 큰 행렬곱을 많이 수행하는 경향이 있고, 이후 한 토큰씩 생성하는 decode는 모델 가중치와 과거 KV cache를 반복해서 읽는 메모리 대역폭 제약이 큽니다. 이 차이가 FlashAttention, PagedAttention, continuous batching, speculative decoding, prefill-decode 분리 같은 서빙 최적화가 필요한 이유입니다.

먼저 용어 정리

문헌과 구현체는 같은 개념에 서로 다른 이름을 쓰기도 합니다. 특히 d_model, hidden dimension, hidden size는 대체로 같은 모델 설정을 가리키며, 토큰 하나를 표현하는 벡터의 폭입니다. 예를 들어 d_model=4096이면 각 레이어를 통과하는 토큰 표현과 hidden state의 마지막 차원은 4096입니다.

그림으로 보는 한 토큰의 생성

아래 첫 번째 그림은 실제 추론의 시간축입니다. 프롬프트 S개 토큰은 prefill에서 한 번에 처리하지만, 이후 출력 토큰은 하나씩 입력 끝에 붙여 decode합니다. 이때 각 토큰마다 새로운 모델이 만들어지는 것이 아니라, 동일한 L개 decoder block의 가중치를 반복 사용합니다.

두 번째 그림은 그중 한 decoder block을 가장 기본적인 MHA 구조로 확대한 것입니다. 일반적인 입력 hidden state X의 형태는 [B, S, d_model]이지만, 그림은 vector와 matrix를 시각적으로 구분하기 위해 batch 차원을 생략하고 decode token 하나의 [1, d_model] vector를 기준으로 표시합니다. 각 head의 Query는 [1, d_head] vector, 누적 Key/Value는 각각 [d_head, T], [T, d_head] matrix이며, head별 결과를 concat한 뒤 output projection으로 합칩니다. attention 출력은 residual connection으로 원래 입력과 합쳐지고, 기본 2-layer FFN을 거쳐 다시 residual로 더해집니다.

그림 1a. 동일한 decoder 가중치를 재사용하는 prefill과 자기회귀 decode 흐름

그림 1b. Vector는 얇은 strip, matrix는 면적이 있는 block으로 구분한 기본 MHA와 2-layer FFN의 한 decode step

그림 2. 입력 -> 토큰화 -> 임베딩 -> Transformer -> 확률분포 -> 샘플링을 반복하는 자기회귀 생성

1. 전체 동작 흐름

사용자가 텍스트를 보내고 화면에 응답이 나타날 때까지의 경로를 먼저 잡으면 각 구성 요소의 역할을 구분하기 쉽습니다.

1. 텍스트 정규화와 토큰화: 입력 문자열을 모델 어휘에 있는 정수 토큰 ID로 바꿉니다.
2. 프롬프트 구성: system, user, assistant 역할 표기와 대화 이력을 모델별 chat template에 맞춰 하나의 토큰열로 만듭니다.
3. Prefill: 프롬프트 전체를 병렬 처리해 각 레이어의 과거 Key/Value와 첫 출력 분포를 만듭니다.
4. 샘플링: logits를 확률로 바꾸고 정책에 따라 다음 토큰 하나를 선택합니다.
5. Decode: 선택한 토큰을 입력 끝에 붙이고, 새 토큰의 K/V만 계산한 뒤 저장된 KV cache를 참조해 다음 분포를 계산합니다.
6. 종료와 후처리: EOS(end-of-sequence) 토큰, 최대 길이, stop 문자열 등을 확인하고 토큰을 문자열로 되돌립니다.

같은 모델이라도 프롬프트 길이, 출력 길이, 동시 요청 수, 샘플링 설정, 캐시 적중률에 따라 비용은 크게 달라집니다. 예를 들어 긴 문서는 prefill과 KV 용량을 키우고, 긴 답변은 decode 시간과 가중치 읽기 횟수를 키웁니다.

2. 토큰, 임베딩, 위치 정보

토큰과 토큰화

토큰(token)은 LLM이 직접 읽고 출력하는 이산 단위입니다. 자연어의 단어와 일치하지 않으며, 대개 자주 등장하는 문자 조각이나 서브워드(subword)입니다. 예를 들어 unbelievable은 여러 조각으로, 이모지나 드문 문자도 하나 이상 토큰으로 나뉠 수 있습니다. 같은 문장이라도 토크나이저가 다르면 토큰 수와 ID열이 달라집니다.

• BPE(Byte-Pair Encoding): 자주 함께 나타나는 문자 조각을 반복 병합하는 계열입니다. GPT 계열에 널리 쓰입니다.
• WordPiece: 언어 모델 점수를 이용해 서브워드를 고르는 방식입니다.
• Unigram/SentencePiece: 언어에 독립적인 정규화와 서브워드 분할에 자주 쓰입니다. 공백을 명시적인 기호로 다루기도 합니다.
• Special token: BOS, EOS, PAD, 역할 구분자, 도구 호출 구분자처럼 일반 텍스트가 아닌 제어 목적의 토큰입니다. chat template을 임의로 바꾸면 모델이 학습 때 보지 못한 형식이 되어 품질이 떨어질 수 있습니다.

토큰 수는 LLM의 실질적인 입력 길이이자 과금, 지연 시간, KV cache 사용량의 기준입니다. 문자 수나 단어 수만으로 문맥 길이를 추정하면 오차가 크며, 코드, 숫자열, URL, 한국어와 영어가 섞인 텍스트는 특히 토큰화 차이가 큽니다.

그림 3. 문자열이 토큰 ID와 임베딩을 거쳐 다음 토큰 확률분포와 샘플링 결과가 되는 흐름

임베딩과 표현의 크기

토큰 ID t는 임베딩 테이블 E에서 d_model 차원의 벡터 x = E[t]로 바뀝니다. d_model은 hidden dimension 또는 hidden size라고도 하며, 모델 전체에서 토큰 표현의 기본 폭을 정합니다. 배치 크기 B, 시퀀스 길이 S라면 첫 입력 텐서의 형태는 보통 [B, S, d_model]입니다. 이 연속 벡터가 각 Transformer 층을 지나면서, 토큰 자체뿐 아니라 앞 문맥을 반영한 표현으로 바뀝니다.

마지막 hidden state h는 LM head를 거쳐 어휘 크기 V개의 점수(logits)가 됩니다.

logits = h @ W_vocab^T + b
p(next_token = i | context) = softmax(logits)_i

logit은 확률이 아니라 정규화 전 점수입니다. softmax가 모든 어휘 후보의 점수를 더해 합이 1인 분포로 바꾸며, 모델은 이 분포를 통해 다음 토큰을 예측합니다.

위치 정보와 문맥 창

Self-attention만으로는 토큰 순서를 알 수 없으므로 위치 정보가 필요합니다. 원래 Transformer는 sinusoidal positional encoding을 입력에 더했고, 현대 decoder-only LLM은 RoPE(Rotary Position Embedding)를 많이 사용합니다. ALiBi처럼 attention score에 위치 편향을 주는 방식도 있습니다.

문맥 창(context window)은 한 번의 요청에서 모델이 처리하도록 설계된 최대 토큰 수입니다. 큰 문맥 창은 더 많은 이력을 넣을 수 있게 하지만, 모든 토큰이 자동으로 동등하게 잘 활용된다는 뜻은 아닙니다. 긴 입력일수록 attention 비용과 KV cache가 커지고, 모델의 장거리 검색 정확도나 위치 편향도 별도로 평가해야 합니다.

3. Transformer 내부 구조

오늘날의 생성형 LLM은 대체로 decoder-only Transformer입니다. 같은 블록을 L개 반복해 쌓고, 각 블록은 문맥을 섞는 attention과 토큰별 변환을 하는 FFN(Feed-Forward Network)으로 구성됩니다. 구현마다 순서와 정규화가 다르지만, 현대 LLM은 흔히 pre-norm 또는 RMSNorm 계열을 사용합니다.

x = x + Attention(Norm(x))
x = x + FFN(Norm(x))

Residual connection은 블록 입력을 출력에 더해 깊은 네트워크의 학습과 정보 전달을 안정화합니다. Norm은 LayerNorm 또는 RMSNorm이며, 분포를 안정화해 학습을 돕습니다.

Norm, attention, residual, gated FFN까지 이어지는 전체 데이터 경로는 앞의 그림 1b에 통합했습니다. 여기서는 중복된 block 개요 대신 attention과 FFN의 계산 의미를 이어서 설명합니다.

Multi-head self-attention

각 토큰 표현 X에서 세 선형 변환으로 Query(Q), Key(K), Value(V)를 만듭니다. 현재 토큰의 Q가 과거 토큰들의 K와 얼마나 관련 있는지 점수로 계산하고, 그 점수로 V를 가중합합니다.

Q = XW_Q, K = XW_K, V = XW_V
Attention(Q, K, V) = softmax((QK^T) / sqrt(d_head) + causal_mask) V

• Causal mask: 위치 i의 토큰이 미래 위치 j > i를 보지 못하게 합니다. 학습 중에는 전체 시퀀스를 병렬 처리하면서도 다음 토큰 예측 규칙을 지킬 수 있습니다.
• Multi-head attention(MHA): 여러 head가 서로 다른 표현 부분공간에서 관계를 계산한 뒤 합칩니다. 문법, 참조, 장거리 의존성 같은 패턴을 병렬로 포착할 수 있습니다.
• GQA/MQA: Query head보다 Key/Value head 수를 적게 둡니다. GQA(Grouped Query Attention)는 여러 Q head가 하나의 KV head를 공유하고, MQA(Multi-Query Attention)는 모든 Q head가 하나의 KV head를 공유합니다. 품질-메모리 절충을 통해 KV cache 크기와 decode 대역폭 요구를 줄입니다.

Self-attention의 score 행렬은 시퀀스 길이에 따라 S x S가 됩니다. 따라서 표준적인 전체 attention은 학습 또는 긴 prefill에서 시간과 중간 메모리가 O(S^2)로 증가합니다. 다만 실제 wall-clock 시간은 FLOPs만이 아니라 GPU HBM과 SRAM 사이의 데이터 이동, 구현 커널, 배치 형태에 따라서도 달라집니다.

FFN과 활성화 함수

Attention이 토큰 간 정보를 섞은 뒤, FFN은 각 토큰에 독립적으로 비선형 변환을 적용합니다. 기본 형태는 두 개의 선형층과 활성화 함수입니다.

FFN(x) = W_down * activation(W_up * x)

많은 최신 LLM은 GELU 대신 SwiGLU 같은 gated FFN을 사용합니다. FFN의 중간 차원은 보통 d_model보다 크므로, dense 모델에서 파라미터와 연산의 상당 부분은 FFN에 있습니다. MoE Analysis는 이 FFN을 여러 전문가로 나누고 일부만 활성화하는 희소 구조를 다룹니다.

대표 구조의 관계

4. 확률분포와 생성 제어

모델은 답을 문자열로 직접 고르는 것이 아니라 매 단계 어휘 전체의 확률분포를 냅니다. 샘플러는 이 분포에서 실제 출력 토큰을 고르는 정책입니다. 동일한 모델과 프롬프트도 샘플러 설정에 따라 서로 다른 문장을 만들 수 있습니다.

Temperature, top-k, top-p

Temperature T는 logits의 날카로움을 조절합니다.

p_i = softmax(logits_i / T)

T < 1이면 높은 확률 후보에 더 집중하고, T > 1이면 분포가 평평해져 다양성이 커집니다. T = 0은 실무에서 보통 샘플링을 끄고 greedy 선택을 뜻하는 관례로 쓰입니다.

정확성은 샘플링만으로 보장되지 않습니다. 모델이 학습하지 않은 사실을 그럴듯하게 조합할 수 있으므로, 최신 정보나 검증 가능한 답이 필요한 경우에는 검색, 도구 호출, 인용 검증, 구조화된 출력 검사 같은 외부 검증 경로가 필요합니다. RAG Analysis는 외부 지식을 문맥으로 주입하는 방식을 설명합니다.

5. 학습과 포스트트레이닝

Pretraining: 다음 토큰 예측

사전학습은 대규모 텍스트 토큰열에서 다음 토큰의 negative log-likelihood, 즉 cross-entropy를 최소화합니다. 입력 x_1, ..., x_{t-1}가 있을 때 정답 x_t의 확률을 높이도록 모든 가중치를 역전파로 갱신합니다.

loss = -sum_t log p_theta(x_t | x_<t)

학습 데이터 파이프라인은 수집만큼 중요합니다. 중복 제거, 품질 필터링, 라이선스와 개인정보 검토, 언어/도메인 비율 조정, 오염된 평가셋 제거가 학습 품질과 안전성에 영향을 줍니다. 모델 크기만 키우고 고품질 데이터나 충분한 학습 토큰을 늘리지 않으면 compute를 비효율적으로 쓸 수 있습니다.

분산 학습과 메모리

대형 모델 학습에서는 파라미터, gradient, optimizer state, activation이 모두 메모리를 차지합니다. 그래서 여러 GPU에 작업을 나눕니다.

Activation checkpointing은 순전파 중간값을 전부 저장하지 않고 역전파 때 일부를 재계산해 메모리를 아끼는 대표적 시간-공간 절충입니다. 학습에서는 이처럼 재계산이 유리할 수 있지만, 사용자 지연 시간이 중요한 추론에서는 같은 선택이 항상 이득인 것은 아닙니다.

Post-training: 지시 따르기와 선호 정렬

사전학습 모델은 문장을 이어 쓰는 능력은 있지만, 대화 규칙이나 사용자의 의도를 안정적으로 따르도록 보장되지는 않습니다. post-training은 이 기반 모델을 실제 assistant로 만드는 과정입니다.

• SFT(Supervised Fine-Tuning): 사람이 작성하거나 정제한 지시-응답 예시로 원하는 형식, 대화 방식, 작업 수행 방법을 학습합니다.
• Preference learning: 같은 프롬프트의 여러 응답 중 선호되는 응답을 이용해 더 도움이 되는 방향을 학습합니다. RLHF는 보상 모델과 강화학습을 사용하고, DPO는 선호 쌍에서 직접 정책을 조정합니다.
• Safety tuning과 평가: 유해 요청 거절, 개인정보 노출, jailbreak 저항, 편향, 환각 등을 평가하고 완화합니다. 모델 정렬은 한 번의 학습으로 끝나는 성질이 아니라 데이터, 정책, 배포 환경에 따라 반복 검증해야 합니다.

6. 추론의 두 단계: Prefill과 Decode

Prefill

Prefill은 프롬프트의 모든 토큰을 처리하는 단계입니다. causal mask가 있어도 프롬프트 내부 토큰은 한 번의 큰 행렬 연산으로 병렬 처리할 수 있습니다. 각 레이어는 모든 입력 위치의 K/V를 만들고 이를 KV cache에 기록합니다.

일반적인 프롬프트 길이와 충분한 배치에서는 큰 GEMM이 GPU tensor core를 잘 활용하므로 compute-bound 성격이 강합니다. 그러나 매우 긴 문맥에서는 attention의 O(S^2) 작업과 HBM I/O가 커져, prefill도 메모리와 커널 효율의 영향을 크게 받습니다. FlashAttention Analysis는 이 단계의 중간 attention 행렬을 HBM에 만들지 않는 방법을 다룹니다.

Decode

Decode는 새 토큰 하나를 입력해 다음 토큰 하나의 분포를 만드는 루프입니다. 새 Q는 길이 1이지만, attention은 과거 전체 K/V를 읽어야 합니다. 또한 모델 가중치도 각 토큰마다 다시 읽으므로, 작은 배치에서는 행렬-벡터 곱(GEMV)에 가까워져 연산 장치보다 HBM 대역폭이 먼저 포화되는 경우가 많습니다.

배치를 크게 하면 여러 요청의 decode를 묶어 행렬 연산 효율을 높일 수 있지만, 너무 큰 배치는 개별 요청의 토큰 간 지연시간(ITL)을 늘릴 수 있습니다. 이 처리량-지연시간 절충 때문에 서빙 엔진은 토큰 단위로 요청을 섞는 Continuous Batching Analysis를 사용합니다.

그림 4. prefill은 프롬프트 전체의 KV를 만들고, decode forward는 과거 KV를 읽는 동시에 새 토큰의 K/V를 cache에 추가한다.

사용자와 운영자가 보는 지표

TTFT가 나쁘면 긴 프롬프트, 대기열, prefill 자원 부족부터 확인하고, TPOT/ITL이 나쁘면 decode 배치, HBM 대역폭, 모델 병렬 통신, KV cache 배치를 먼저 확인하는 것이 합리적입니다. 평균 throughput만 보면 긴 tail latency나 사용자 체감 문제를 놓칠 수 있습니다.

7. KV Cache와 메모리 산정

왜 KV를 저장하는가

새 토큰을 생성할 때마다 과거 모든 토큰의 K/V를 매번 다시 계산하면, 생성 길이가 늘수록 같은 계산을 반복하게 됩니다. KV cache는 각 레이어에서 과거 토큰의 K/V를 한 번 계산해 저장하고 이후 decode에서 재사용합니다. 덕분에 새 토큰의 projection만 계산하면 되지만, 저장된 캐시를 읽어야 하므로 메모리 용량과 대역폭이 핵심 제약이 됩니다.

KV cache의 대략적인 크기는 다음처럼 계산할 수 있습니다.

KV_bytes = 2 * L * n_kv_heads * d_head * seq_len * batch * dtype_bytes

• 2: Key와 Value를 모두 저장합니다.
• L: Transformer layer 수입니다.
• n_kv_heads * d_head: 레이어당 KV 표현의 폭입니다. MHA에서는 대체로 d_model과 같고, GQA/MQA에서는 더 작습니다.
• seq_len과 batch: 각각 문맥 길이와 동시에 살아 있는 요청 수입니다.

예를 들어 MHA 모델이 L=80, d_model=8192, seq_len=8192, batch=1, FP16(2 bytes)라면 KV cache는 약 21.5 GB(십진 기준)입니다. 같은 모델에서 GQA가 KV head 수를 query head 수의 1/8로 줄이면, 다른 조건이 같을 때 KV cache도 대략 1/8 수준으로 줄어듭니다. 실제 사용량에는 block table, 정렬, 임시 버퍼, 모델 구현의 오버헤드가 더해집니다.

가중치도 별도로 큰 메모리를 차지합니다. 70B 파라미터 모델은 가중치만 FP16/BF16에서 대략 140 GB가 필요합니다. 그래서 단일 GPU에 맞지 않는 모델은 양자화 또는 tensor/pipeline parallelism이 필요하고, 남은 메모리 예산이 곧 수용 가능한 KV cache와 동시 요청 수를 제한합니다.

KV cache 문제를 푸는 축

PagedAttention Analysis, KV Cache Quantization Analysis, KV Cache Offloading Analysis, Prefix Caching Analysis는 위 축을 각각 더 깊게 다룹니다.

8. 서빙 시스템의 설계 판단

LLM 서빙은 단순히 model.generate()를 호출하는 일이 아니라, 제한된 가속기 메모리와 SLO 안에서 서로 길이가 다른 요청을 관리하는 문제입니다. 다음 최적화들은 서로 대체재라기보다 병목이 다르므로 대개 함께 적용됩니다.

모델 병렬화도 모델 크기와 네트워크에 맞춰 골라야 합니다. Tensor parallelism은 레이어 내부를 나눠 단일 요청 지연시간을 낮추지만 매 레이어 통신이 필요합니다. Pipeline parallelism은 레이어 묶음을 나누지만 작은 배치에서 pipeline bubble이 생깁니다. MoE는 expert parallelism과 all-to-all 통신이 추가됩니다. LLM Inference Engine Analysis는 vLLM, TensorRT-LLM, SGLang, llama.cpp 같은 구현체의 선택 기준을 비교합니다.

9. 장점, 한계, 오해하기 쉬운 점

LLM은 데이터베이스나 추론 규칙 엔진을 그대로 대체하지 않습니다. 문맥에 있는 패턴을 바탕으로 다음 토큰의 분포를 모델링하기 때문에, 근거가 필요한 답은 출처 제공과 검증 도구를 결합해야 합니다. 또한 "문맥 창이 크다"와 "아주 긴 입력에서 필요한 정보를 정확히 찾는다"는 서로 다른 주장입니다. 실제 워크로드 길이, 검색 정확도, 비용, 지연시간을 함께 측정해야 합니다.

10. 관련 기술과 읽는 순서

내부 문서

주요 원문

11. 핵심 정리

LLM은 토큰열의 다음 원소 확률을 예측하는 decoder-only Transformer가 주류입니다. 토큰화로 문자열을 ID열로 바꾸고, 임베딩, 위치 정보, attention, FFN을 거쳐 logits를 만든 뒤 샘플러가 다음 토큰을 선택합니다. 이 과정을 반복하는 자기회귀성이 생성 능력의 기반이자 decode가 순차적인 이유입니다.

학습은 대규모 next-token prediction으로 일반적인 언어 능력을 만들고, SFT와 선호 학습 같은 post-training으로 assistant 행동을 다듬습니다. 그러나 모델 출력은 확률적 생성이지 사실 검증이 아니므로, 최신성이나 정확성이 중요한 작업에는 검색, 도구, 인용 검증을 결합해야 합니다.

추론에서는 prefill과 decode를 구분하는 것이 핵심입니다. prefill은 긴 프롬프트의 병렬 처리와 TTFT에, decode는 가중치/KV cache 읽기와 TPOT/ITL에 직접 영향을 줍니다. 따라서 LLM 시스템은 모델 정확도만이 아니라 토큰 수, KV cache 예산, 메모리 대역폭, 배치 정책, 캐시 재사용, SLO를 함께 설계해야 합니다.