트랜스포머 기반 LLM의 추론 과정을 Prefill과 Decode 단계로 나누어 분석하고, 메모리 바운드와 컴퓨트 바운드의 개념, 핵심 지연시간 지표를 정리합니다.
LLM(Large Language Model) 추론은 학습이 완료된 모델에 입력 프롬프트를 주고, 그에 대한 응답 토큰을 하나씩 생성해 나가는 과정을 뜻합니다. 학습(Training)이 모델의 파라미터를 업데이트하는 과정이라면, 추론(Inference)은 고정된 파라미터를 사용해 결과를 만들어내는 과정입니다.
겉으로 보면 단순해 보이지만, 수백억 개의 파라미터를 가진 모델이 토큰 하나를 생성할 때마다 전체 모델 가중치에 접근해야 한다는 사실을 떠올리면, 이 과정이 왜 비용과 지연시간의 핵심 과제인지 이해할 수 있습니다.
70B 파라미터 모델이 FP16 정밀도로 로드되면 약 140GB의 GPU 메모리를 차지합니다. 토큰 하나를 생성할 때마다 이 140GB의 가중치를 HBM에서 읽어와야 합니다.
LLM 추론은 크게 Prefill(프리필) 단계와 Decode(디코드) 단계로 나뉩니다.
Prefill 단계에서는 입력 프롬프트의 모든 토큰을 한 번에 병렬 처리합니다. 이 과정에서 각 트랜스포머 레이어의 Self-Attention 연산이 수행되며, 입력 토큰들에 대한 Key와 Value 텐서가 계산되어 캐시에 저장됩니다. 이것이 바로 다음 장에서 자세히 다룰 **KV 캐시(KV Cache)**입니다.
입력: "오늘 날씨가 좋아서" (5개 토큰)
처리: 5개 토큰을 병렬로 한 번에 Attention 연산
출력: 첫 번째 생성 토큰 + KV 캐시 저장Prefill은 입력 길이에 비례해 연산량이 증가하지만, GPU의 병렬 연산 능력을 최대한 활용할 수 있어 컴퓨트 바운드(Compute-bound) 특성을 보입니다. 즉, GPU의 연산 처리 능력(FLOPS)이 병목이 됩니다.
Decode 단계에서는 토큰이 하나씩 순차적으로 생성됩니다. 각 스텝에서 새로 생성된 토큰 하나만 입력으로 들어가고, 이전에 저장된 KV 캐시를 참조해 Attention 연산을 수행합니다.
스텝 1: "오늘 날씨가 좋아서" + KV캐시 → "산책"
스텝 2: "...산책" + KV캐시 → "을"
스텝 3: "...을" + KV캐시 → "하러"
...반복...이 단계가 LLM 추론에서 시간의 대부분을 차지합니다. 한 번에 토큰 하나만 처리하므로 GPU의 행렬 연산 유닛이 충분히 활용되지 못하고, 대신 메모리에서 모델 가중치를 읽어오는 속도가 병목이 됩니다. 이것이 메모리 바운드(Memory-bound) 특성입니다.
LLM의 텍스트 생성은 자기회귀(Autoregressive) 방식을 따릅니다. 이전에 생성한 토큰들이 다음 토큰 생성의 입력이 되는 구조입니다. 수식으로 표현하면 다음과 같습니다.
여기서 x는 입력 프롬프트, y_t는 t번째에 생성되는 토큰입니다. 모델은 전체 어휘(Vocabulary)에 대한 확률 분포를 출력하고, 샘플링 전략(Greedy, Top-k, Top-p 등)에 따라 다음 토큰을 선택합니다.
이 자기회귀 특성이 바로 LLM 추론의 근본적인 병목입니다. 500개의 토큰을 생성하려면 모델을 500번 순차적으로 실행해야 합니다. GPU가 아무리 빨라도, 이 순차적 의존성을 깨뜨리기는 어렵습니다.
자기회귀 생성의 순차적 특성은 근본적인 한계이지만, 5장에서 다룰 Speculative Decoding은 이 제약을 우회하는 영리한 접근법을 제시합니다.
GPU 연산의 병목은 크게 두 가지로 나뉩니다.
GPU의 연산 처리 속도(FLOPS)가 병목이 되는 경우입니다. Prefill 단계에서 수천 개의 토큰에 대한 Attention 행렬 연산을 수행할 때 이 특성이 나타납니다. 데이터는 충분히 빨리 공급되지만, 계산 자체에 시간이 걸리는 상황입니다.
메모리 대역폭(Memory Bandwidth)이 병목이 되는 경우입니다. Decode 단계에서 토큰 하나를 위해 수백 GB의 모델 가중치를 HBM에서 읽어와야 하지만, 실제 연산량은 매우 적습니다.
| 특성 | Prefill | Decode |
|---|---|---|
| 처리 토큰 수 | 수백~수천 개 (병렬) | 1개 (순차) |
| 병목 유형 | 컴퓨트 바운드 | 메모리 바운드 |
| GPU 활용률 | 높음 | 낮음 |
| 핵심 지표 | FLOPS | 메모리 대역폭 (GB/s) |
H100 GPU를 예로 들면, FP16 연산 성능은 약 990 TFLOPS이고 HBM3 대역폭은 약 3.35 TB/s입니다. **산술 강도(Arithmetic Intensity)**가 약 295 FLOP/byte인데, Decode 단계에서 토큰 하나를 생성하는 연산의 산술 강도는 이보다 훨씬 낮아서 메모리 바운드에 빠지게 됩니다.
LLM 추론 성능을 측정하는 핵심 지표들을 정리합니다.
첫 번째 토큰이 생성되기까지의 시간입니다. Prefill 단계의 처리 시간과 직결됩니다. 사용자 경험에서 "응답이 시작되기까지 기다리는 시간"에 해당하며, 대화형 서비스에서는 보통 200ms 이하를 목표로 합니다.
토큰 하나를 생성하는 데 걸리는 시간입니다. Decode 단계의 스텝 하나에 소요되는 시간이며, 이 값이 작을수록 텍스트가 빠르게 스트리밍됩니다.
초당 생성되는 토큰 수로, TPOT의 역수입니다. 사용자 체감 속도를 직관적으로 나타내며, 30 TPS 이상이면 사람이 읽는 속도보다 빠르게 느껴집니다.
시스템 전체가 단위 시간당 처리할 수 있는 총 토큰 수입니다. 단일 요청의 속도와는 다르게, 동시에 여러 요청을 배칭(Batching)해 처리하면 개별 지연시간은 다소 늘더라도 전체 처리량을 크게 높일 수 있습니다.
단일 요청 성능:
전체 지연시간 = TTFT + (출력 토큰 수 x TPOT)
시스템 성능:
처리량(tokens/s) = 동시 요청 수 x 요청당 TPS
비용 효율 = 처리량 / GPU 비용이 시리즈에서 다룰 최적화 기법들을 계층별로 정리하면 다음과 같습니다.
| 장 | 최적화 대상 | 핵심 효과 |
|---|---|---|
| 2장 | KV 캐시 | 메모리 사용량 이해와 절감 |
| 3장 | PagedAttention | 메모리 낭비 96% 감소 |
| 4장 | Continuous Batching | 처리량 극대화 |
| 5장 | Speculative Decoding | 지연시간 2-3배 감소 |
| 6장 | Prefix Caching | 반복 연산 60%+ 제거 |
| 7장 | 양자화 | 메모리 50% 절감, 처리량 1.6배 |
| 8장 | 모델 병렬화 | 대형 모델 분산 서빙 |
| 9장 | 비용 최적화 | GPU 선택과 비용 모델링 |
| 10장 | 프로덕션 | 전체 스택 조합과 실전 배포 |
이 기법들은 독립적으로도 효과가 있지만, 조합했을 때 시너지가 극대화됩니다. 10장에서는 이 모든 기법을 조합해 5-8배의 비용 효율 개선을 달성하는 실전 사례를 다룹니다.
이 장에서는 LLM 추론의 기본 구조를 살펴보았습니다.
다음 장에서는 LLM 추론에서 가장 큰 메모리 소비원인 KV 캐시의 메커니즘을 심층적으로 분석합니다. 70B 모델이 요청 하나에 왜 20GB의 KV 캐시를 필요로 하는지, 그리고 이 메모리의 60-80%가 왜 낭비되는지 알아보겠습니다.
이 글이 도움이 되셨나요?
관련 주제 더 보기
트랜스포머 Attention에서 KV 캐시의 역할과 메모리 사용량 계산법을 다루고, MQA/GQA 등 캐시 절감 기법과 압축 전략을 분석합니다.
OS 가상 메모리에서 영감받은 PagedAttention의 원리를 설명하고, vLLM의 아키텍처와 Automatic Prefix Caching, 계층적 KV 캐시를 분석합니다.
정적 배칭의 한계를 분석하고, Continuous Batching의 iteration-level 스케줄링 원리와 vLLM, TGI, TensorRT-LLM의 구현 차이를 비교합니다.