이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.
TL;DR
LLM 추론은 입력 문맥을 병렬 처리해 KV cache를 만드는 Prefill과, 그 상태를 읽으며 출력 토큰을 하나씩 생성하는 Decode로 나뉩니다. Prefill은 첫 토큰 지연인 TTFT에, Decode는 토큰 사이 간격인 ITL과 전체 완료 시간에 주로 영향을 주지만 대기열·네트워크·동시성도 같은 증상을 만들 수 있습니다. 긴 문맥·RAG 요청에는 입력 토큰 분포와 TTFT를, 긴 출력에는 ITL과 출력 길이를, 혼합 트래픽에는 대표 조건의 p95·p99를 측정해야 합니다. 최적화는 실제 요청 경로를 재현한 뒤 batching, chunked prefill, KV-cache 관리, speculative decoding, 단계별 자원 분리의 비용과 운영 복잡성을 비교하는 순서로 진행해야 합니다.
섹션별 상세
LLM 추론은 입력 문맥을 처리하는 Prefill과 출력 토큰을 순차 생성하는 Decode로 나뉘며, 두 단계가 사용자에게 서로 다른 지연 현상으로 나타납니다. Prefill에서는 시스템 지침, 검색 문맥, 대화 기록, 사용자 프롬프트를 하나의 입력 토큰 시퀀스로 모은 뒤 KV cache를 만듭니다. Decode에서는 이 상태를 읽어 토큰을 하나씩 생성하므로 첫 토큰이 늦는 문제와 스트리밍이 느리거나 끊기는 문제를 같은 지표로 판단하면 안 됩니다.
근거
- LLM 추론은 Prefill과 Decode라는 서로 다른 두 단계로 구성되며 각각 입력 처리와 출력 생성을 맡는다. — 기사 도입부의 ‘LLM inference has two phases’ 문단과 Prefill·Decode 작동 원리 절
Prefill은 입력 토큰을 병렬 처리해 모델 연산량이 커지는 연산 중심 단계이고, Decode는 이전 토큰이 나와야 다음 토큰을 만들 수 있어 순차적이며 메모리 대역폭의 영향을 크게 받습니다. KV cache는 대화 자체를 기억하는 모델 메모리가 아니라 현재 요청의 문맥에서 생성된 serving 상태이며, 응답 토큰이 늘어날수록 함께 커집니다. 따라서 긴 입력은 주로 첫 토큰 지연에, 긴 출력과 동시 요청은 스트리밍 간격과 메모리 압력에 영향을 줄 수 있습니다.
근거
- Prefill은 일반적으로 연산 중심이고 Decode는 순차 생성과 메모리 대역폭의 영향을 크게 받는다. — ‘The phases have different access patterns’ 문단에서 입력 토큰 병렬 처리와 이전 토큰 의존성을 비교한 부분
지연 증상에 맞춰 Time to First Token, Inter-token Latency, end-to-end latency, throughput을 분리해 측정해야 합니다. TTFT는 응답 시작 시점을, ITL은 토큰 사이의 간격과 스트리밍의 균일성을, end-to-end latency는 전체 완료 시간을 나타내며 throughput은 시스템이 일정 시간에 처리한 총 작업량을 나타냅니다. 평균 tokens per second만으로는 개별 요청의 시작 시점과 체감 스트리밍 품질을 판단할 수 없으므로 p95와 p99를 포함한 요청 단위 측정이 필요합니다.
근거
- TTFT, ITL, end-to-end latency, throughput은 서로 다른 사용자 경험과 시스템 성능 질문에 답한다. — ‘How the two phases show up in latency and throughput’ 절의 지표 정의와 trade-off 설명
워크로드 형태에 따라 먼저 볼 지표가 달라집니다. 긴 문맥이나 검색 결과가 많은 RAG 요청은 입력 토큰 분포, TTFT, tail latency를 우선 확인하고, 코드 생성·초안 작성·작업 과정을 길게 출력하는 agent 요청은 ITL, 출력 길이 분포, 전체 완료 시간을 함께 봐야 합니다. 동시성 환경에서는 대표적인 입력·출력 길이와 도착 패턴으로 p95와 p99를 측정해야 하며, 하나의 평균 프롬프트와 평균 응답만으로 운영 성능을 결정할 수 없습니다.
근거
- 긴 문맥·검색 중심 요청은 TTFT와 입력 토큰 분포를, 긴 출력 요청은 ITL과 출력 길이를 우선 측정해야 한다. — ‘Start with the workload shape’ 절의 long-context, retrieval-heavy, long-output workload 문단
측정 결과에 따라 in-flight batching, scheduling, chunked prefill, KV-cache 관리, speculative decoding, disaggregated serving을 검토할 수 있습니다. Chunked prefill은 큰 입력을 작은 조각으로 나눠 Decode와 교차 실행하고, speculative decoding은 draft mechanism이 후보 토큰을 만든 뒤 주 모델이 검증해 여러 토큰을 한 번에 진행하도록 시도합니다. Prefill과 Decode를 별도 GPU 풀로 분리하는 disaggregated serving은 두 단계를 독립적으로 조정할 여지가 있지만 KV cache 전송 비용과 운영 복잡성이 추가되므로 지속적인 단계 간 경합이 있을 때만 타당성을 비교해야 합니다.
최적화 전에는 실제 사용자 요청 경로와 동일한 조건으로 벤치마크를 구성해야 합니다. 프롬프트·출력 길이 분포, 동시성·버스트 패턴, 스트리밍 여부, 모델 설정, 캐시 동작과 요청 유사성, TTFT·ITL·end-to-end latency·throughput·p95·p99를 함께 기록해야 합니다. 짧은 프롬프트와 낮은 동시성에서 얻은 TTFT나 단일 스트림의 ITL은 검색 중심 워크플로의 피크 트래픽 성능을 판단하는 근거가 될 수 없습니다.
근거
- 대표적인 입력·출력 길이와 동시성 조건에서 p95·p99를 측정해야 실제 운영 성능을 평가할 수 있다. — ‘Test the request path your users actually take’ 절의 벤치마크 항목과 비교 조건
용어 해설
- Prefill
- — LLM이 입력 문맥 전체를 처리해 첫 출력 토큰을 생성할 준비를 하는 단계입니다. 입력 토큰을 병렬 처리하고 KV cache를 구축하므로 일반적으로 연산량과 TTFT에 큰 영향을 줍니다.
- Decode
- — Prefill 이후 LLM이 KV cache를 참조하면서 출력 토큰을 하나씩 순차 생성하는 단계입니다. 이전 토큰에 의존하고 메모리를 반복해서 읽기 때문에 스트리밍 속도와 ITL에 직접 연결됩니다.
- KV Cache
- — 입력 문맥을 처리하는 동안 생성되는 요청별 serving 상태로, 모델이 출력 토큰을 만들 때 반복 참조합니다. 응답이 길어질수록 상태가 커져 메모리 압력과 동시 처리 용량에 영향을 줍니다.
- 첫 토큰 지연시간(Time to First Token)
- — 사용자가 요청을 보낸 뒤 스트리밍 응답의 첫 토큰이 도착할 때까지 걸리는 시간입니다. 긴 입력, 검색 결과, 대화 기록뿐 아니라 대기열과 네트워크 경로도 이 값을 늘릴 수 있습니다.
- 토큰 간 지연시간(Inter-token Latency)
- — 스트리밍 응답에서 연속된 출력 토큰 사이의 간격입니다. TTFT가 짧아도 ITL이 길거나 불규칙하면 사용자는 응답을 끊기는 흐름으로 느끼므로 Decode 성능을 별도로 확인해야 합니다.
- 청크형 Prefill(Chunked Prefill)
- — 큰 입력 문맥을 여러 작은 조각으로 나누어 처리하면서 이미 진행 중인 Decode 작업과 번갈아 실행하는 방식입니다. 대형 입력이 스트리밍 응답을 방해하는 현상을 줄일 수 있지만 효과는 요청 구성과 스케줄링 정책에 좌우됩니다.
기술
- LLM
- KV cache
- RAG
- in-flight batching
- Chunked Prefill
- Speculative Decoding
- Disaggregated Serving
- GPU
활용 사례
- 긴 대화 기록과 검색 결과를 사용하는 RAG 애플리케이션의 첫 토큰 지연 측정
- 코드 생성과 초안 작성처럼 출력이 긴 스트리밍 워크플로의 ITL 측정
- 여러 요청이 동시에 들어오는 LLM serving 환경의 p95·p99 성능 평가
- 사용자 대기형 서비스와 배치 작업의 latency·throughput 우선순위 비교
AI 분석 전체 내용 보기
AI 요약 · 북마크 · 개인 피드 설정 — 무료
출처 · 인용 안내
원문 발행 2026. 08. 15.수집 2026. 08. 15.출처 타입 RSS
인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.
