
대규모 언어 모델(LLM)을 사용할 때 많은 사람들이 한 가지 의문을 갖습니다. 수천 자에 달하는 긴 프롬프트는 거의 순식간에 읽는 것처럼 보이는데, 정작 답변은 한 글자(토큰)씩 차례대로 생성되는 이유는 무엇일까요?
이러한 차이는 LLM의 추론(Inference) 과정이 Prefill과 Decode라는 두 단계로 나뉘기 때문입니다. 두 단계는 동일한 AI 모델을 사용하지만 GPU를 활용하는 방식과 병목이 발생하는 지점이 완전히 다릅니다.
이번 글에서는 Prefill과 Decode의 동작 방식, GPU 성능과의 관계, KV Cache의 역할, 그리고 Continuous Batching이 추론 성능을 어떻게 개선하는지 알아보겠습니다.
LLM 추론(Inference)이란?
LLM 추론은 사용자의 입력을 받아 새로운 문장을 생성하는 전체 과정을 의미합니다.
많은 사람들이 하나의 과정으로 생각하지만 실제 내부에서는 다음 두 단계로 구분됩니다.
- Prefill : 사용자의 입력을 읽고 이해하는 단계
- Decode : 이해한 내용을 바탕으로 답변을 생성하는 단계
이 두 단계는 처리 방식이 다르기 때문에 GPU 자원 활용 방식 역시 크게 달라집니다.
Prefill: 입력을 병렬로 읽는 단계
예를 들어 다음과 같은 문장을 입력했다고 가정해 보겠습니다.
"The cat sat down."
LLM은 먼저 문장을 여러 개의 토큰(Token) 으로 분리합니다.
이후 Transformer 모델은 이 토큰들을 한 번에 병렬 처리(Parallel Processing) 합니다.
즉,
- 입력 전체를 동시에 읽고
- 토큰 간의 관계를 계산하며
- 이후 답변 생성에 필요한 정보를 저장합니다.
이 과정에서 함께 생성되는 것이 바로 KV Cache(Key-Value Cache) 입니다.
KV Cache는 이후 Decode 단계에서 이미 계산한 정보를 다시 계산하지 않도록 저장하는 역할을 합니다.
Prefill은 Compute-Bound 작업
Prefill 단계에서는 많은 토큰을 동시에 계산합니다.
GPU는 대량의 연산을 한꺼번에 수행할 수 있기 때문에 연산 장치가 거의 쉬지 않고 계속 동작합니다.
따라서 Prefill의 병목은 대부분 연산 성능(Compute) 에 의해 결정됩니다.
즉,
- GPU 코어가 얼마나 많은 연산을 수행할 수 있는지
- 연산 성능(FLOPS)이 얼마나 높은지
가 Prefill 속도를 좌우합니다.
TTFT(Time To First Token)이란?
사용자가 가장 먼저 체감하는 지표는 첫 번째 토큰이 생성되기까지 걸리는 시간입니다.
이를
TTFT(Time To First Token)
이라고 합니다.
TTFT는 대부분 Prefill 시간이 차지합니다.
즉,
- 프롬프트가 길수록
- 모델이 클수록
- Prefill 연산량이 많아질수록
첫 번째 응답까지의 시간이 증가합니다.
Decode: 한 토큰씩 답변을 생성하는 단계
Prefill이 완료되면 이제 답변 생성이 시작됩니다.
Decode에서는 다음과 같은 과정을 반복합니다.
- 다음 토큰 하나를 예측
- 생성한 토큰을 KV Cache에 추가
- 새 토큰을 다시 입력으로 사용
- 다음 토큰 예측
예를 들어
First Token : quietly
Second Token : and
Third Token : purred
처럼 하나씩 생성됩니다.
LLM이 답변을 실시간으로 출력하는 이유도 바로 이 Decode 과정 때문입니다.
Decode는 Memory-Bound 작업
Decode는 Prefill과 병목 지점이 다릅니다.
연산량 자체는 상대적으로 적지만,
매 토큰마다
- KV Cache를 읽고
- 새로운 KV를 추가하며
- 이전 토큰 정보를 계속 참조해야 합니다.
답변이 길어질수록 KV Cache 역시 계속 커집니다.
즉,
생성할 토큰이 많아질수록 GPU는 연산보다 메모리 접근에 더 많은 시간을 소비하게 됩니다.
그래서 Decode는 대표적인 Memory-Bound 작업으로 분류됩니다.
흥미로운 점은 GPU 사용률이 낮아 보이더라도 실제로는 메모리 대역폭이 병목이 되어 성능이 제한될 수 있다는 것입니다.
TPOT(Time Per Output Token)
Decode 단계에서 중요한 성능 지표는
TPOT(Time Per Output Token)
입니다.
이는
토큰 하나를 생성하는 데 걸리는 시간을 의미합니다.
사용자가 스트리밍 응답에서 느끼는 속도는 대부분 TPOT에 의해 결정됩니다.
즉,
- TPOT이 낮을수록
- 답변이 더 빠르게 출력되는 것처럼 느껴집니다.
Roofline 모델로 보는 Prefill과 Decode
Roofline 모델은 GPU 성능 병목을 이해하기 위한 대표적인 분석 방법입니다.
이 관점에서 보면 두 단계의 특성이 명확하게 구분됩니다.
Prefill
- Compute Limit에 가까움
- GPU 연산 성능이 중요
Decode
- Memory Bound 영역
- 메모리 대역폭이 성능을 결정
같은 모델이라도 단계에 따라 전혀 다른 하드웨어 자원을 사용하게 되는 것입니다.
Continuous Batching으로 GPU 활용률 높이기
GPU는 여러 요청을 동시에 처리할수록 효율이 높아집니다.
하지만 요청을 하나씩 처리하면 GPU에 빈 시간이 발생합니다.
이를 개선하기 위해 사용하는 기법이 Continuous Batching 입니다.
기존의 Static Batching은 하나의 배치가 끝나야 다음 요청을 처리할 수 있습니다.
반면 Continuous Batching은
- 하나의 요청이 끝나면
- 새로운 요청을 즉시 투입하여
- GPU가 쉬지 않도록 만듭니다.
또한
- 어떤 요청은 Prefill
- 다른 요청은 Decode
를 동시에 수행할 수 있어 GPU 활용률을 더욱 높일 수 있습니다.
결과적으로
- Idle Time 감소
- GPU 처리량 증가
- 동일한 GPU에서 더 많은 요청 처리
라는 효과를 얻을 수 있습니다.
핵심 정리
LLM 추론은 하나의 과정처럼 보이지만 실제로는 Prefill과 Decode라는 서로 다른 특성을 가진 두 단계로 구성됩니다.
- Prefill은 입력을 병렬로 처리하며 KV Cache를 생성하는 단계입니다.
- Prefill은 GPU 연산 성능이 중요한 Compute-Bound 작업입니다.
- Decode는 KV Cache를 활용해 토큰을 하나씩 생성하는 단계입니다.
- Decode는 메모리 접근이 성능을 좌우하는 Memory-Bound 작업입니다.
- TTFT는 첫 응답이 시작되는 속도를 나타내며, TPOT은 이후 응답이 이어지는 속도를 결정합니다.
- Continuous Batching은 Prefill과 Decode 작업을 효율적으로 스케줄링하여 GPU의 유휴 시간을 줄이고 처리량을 높입니다.
LLM의 응답 속도는 단순히 모델의 크기나 GPU 성능만으로 결정되지 않습니다.
입력을 얼마나 빠르게 이해하는 Prefill, 답변을 얼마나 효율적으로 생성하는 Decode, 그리고 이 두 단계를 어떻게 스케줄링하는지가 전체 추론 성능을 좌우합니다.
이러한 구조를 이해하면 "왜 첫 응답은 늦지만 이후에는 빠르게 생성되는지", "왜 GPU 사용률이 낮아 보여도 성능이 제한될 수 있는지", "왜 Continuous Batching이 대규모 LLM 서비스에서 필수적인 기술인지"를 보다 명확하게 이해할 수 있습니다.
최근 LLM 서빙 기술은 단순한 모델 최적화를 넘어 연산(Compute), 메모리(Memory), 스케줄링(Scheduling) 을 함께 고려하는 방향으로 발전하고 있으며, 앞으로도 이러한 추론 최적화 기술은 AI 서비스의 성능과 비용 효율성을 결정하는 핵심 요소로 자리 잡을 것입니다.
LLM Inference: Prefill & Decode Explained | Mayank Pratap Singh님이 토픽에 대해 올림 | LinkedIn
LLM Inference Optimization : 𝐏𝐫𝐞𝐟𝐢𝐥𝐥 & 𝐃𝐞𝐜𝐨𝐝𝐞 𝐄𝐱𝐩𝐥𝐚𝐢𝐧𝐞𝐝 Why can an LLM read a long prompt almost instantly, but write its answer one token at a time? The answer is hidden inside two stages o
www.linkedin.com

'인공지능' 카테고리의 다른 글
| AI 에이전트 기반 대규모 코드 마이그레이션 방법과 Claude Code 활용 사례 (0) | 2026.07.27 |
|---|---|
| OpenWorker란? 로컬에서 실행되는 오픈소스 AI 업무 자동화 에이전트 완벽 정리 (0) | 2026.07.27 |
| AI 에이전트의 Loops와 Graphs 차이점, 언제 어떤 방식을 선택해야 할까? (0) | 2026.07.27 |
| Claude 5가 바꾼 Context Engineering, 시스템 프롬프트보다 중요한 설계 전략 (0) | 2026.07.27 |
| AI 소프트웨어 팩토리, 왜 하네스 엔지니어링만으로는 부족할까? (0) | 2026.07.27 |