같은 ‘느리다’에도 다른 원인이 있다
LLM에 질문했는데 한참 동안 아무것도 나타나지 않을 때가 있다. 반대로 답변은 바로 시작하지만, 글자가 조금씩 느리게 나오는 경우도 있다.
사용자에게는 둘 다 느린 서비스다. 하지만 원인을 찾으려면 첫 출력까지의 대기 시간과 출력이 시작된 뒤의 생성 속도를 나눠 봐야 한다.
앞선 양자화 글에서는 모델 용량을 줄여도 속도가 반드시 빨라지는 것은 아니라고 설명했다. 이번에는 일반적인 자기회귀 방식의 텍스트 LLM을 기준으로, 요청이 처리되는 과정과 속도를 확인하는 기준을 정리한다. 아래 계산과 측정표는 설명용 예시이며 특정 장비의 실측 결과가 아니다.
1. 입력을 처리하는 Prefill, 출력을 이어가는 Decode
모델이 답변을 만드는 과정은 크게 두 단계로 나눌 수 있다.
| 단계 | 하는 일 | 이해할 점 |
|---|---|---|
| Prefill | 입력 토큰을 처리하고 이후 생성에 사용할 KV Cache를 구성 | 입력은 이미 주어져 있어 여러 토큰의 계산을 병렬로 처리할 수 있음 |
| Decode | 앞선 문맥을 바탕으로 다음 토큰을 반복 생성 | 일반적인 생성에서는 다음 토큰이 이전에 생성한 토큰에 의존 |
KV Cache는 앞서 계산한 Attention의 Key·Value를 저장해 재사용하는 공간이다. 매번 과거 토큰의 같은 계산을 모두 반복하지 않도록 한다.
Prefill은 긴 입력을 한꺼번에 처리하므로 연산량이 커질 수 있다. 반면 작은 배치에서의 Decode는 가중치와 캐시를 읽는 메모리 대역폭이 병목인 경우가 많다. 배치 크기와 모델 구조에 따라 병목은 달라진다. TNG의 Prefill·Decode 설명
1
요청 전송 → 대기·입력 준비 → Prefill → 첫 출력 토큰 → Decode 반복 → 마지막 토큰
여기서 토큰은 글자나 단어와 정확히 일치하지 않는다. 같은 문장도 토크나이저에 따라 토큰 수가 달라지므로, 서로 다른 모델의 tokens/s를 곧바로 읽기 속도로 비교하기는 어렵다.
2. 첫 토큰까지의 시간과 전체 완료 시간을 구분하자
응답 속도를 기록할 때는 다음 항목을 함께 본다.
| 지표 | 의미 | 알 수 있는 것 |
|---|---|---|
| TTFT · Time to First Token | 요청 전송부터 첫 출력 토큰을 받을 때까지 | 처음 기다리는 시간이 얼마나 긴가 |
| 평균 TPOT · Time per Output Token | 첫 토큰 이후 토큰 하나당 걸린 평균 시간 | 출력이 얼마나 빠르게 이어지는가 |
| 전체 응답 시간 | 요청 전송부터 마지막 출력까지 | 작업이 언제 끝나는가 |
TTFT에는 Prefill뿐 아니라 서버 대기와 네트워크 지연 등도 포함된다. 따라서 TTFT가 길다는 이유만으로 모델의 입력 처리가 느리다고 단정할 수는 없다.
측정 도구마다 지표 정의가 조금씩 다르다. 첫 토큰을 제외한 평균 TPOT를 사용하면, 출력이 두 토큰 이상일 때 다음처럼 계산할 수 있다. NVIDIA 지표 정의
1
평균 TPOT = (전체 응답 시간 - TTFT) ÷ (출력 토큰 수 - 1)
예를 들어 첫 토큰을 2초 뒤에 받았고, 총 101개 토큰을 7초 만에 받았다고 가정하자.
1
2
평균 TPOT = (7 - 2) ÷ (101 - 1) = 0.05초 = 50ms
첫 토큰 이후 평균 생성률 = 100 ÷ 5 = 20 tokens/s
첫 토큰을 기다린 시간까지 포함해 101 ÷ 7로 계산하면 약 14.4 tokens/s다. 둘은 측정 구간이 다르다. 속도 수치 옆에 계산 기준을 적어야 비교가 가능하다.
평균값이 같아도 중간에 긴 멈춤이 있을 수 있다. 스트리밍이 끊기는 문제라면 토큰 사이 간격인 ITL의 분포도 확인한다. 다만 네트워크 청크 하나에 여러 토큰이 묶일 수 있으므로, 청크 도착 간격을 그대로 토큰 간격으로 해석하지 않는다.
3. 질문은 짧은데 왜 첫 답변이 늦을까?
채팅창에 입력한 한 문장이 모델 입력의 전부는 아닐 수 있다.
1
실제 입력 = 시스템 지시문 + 대화 이력 + 검색 문서 + 도구 정의 + 사용자 질문
RAG 서비스에서 질문은 짧아도 검색 문서를 여러 개 붙이면 입력이 길어진다. 긴 대화를 매번 다시 보내거나 많은 도구의 설명을 포함해도 마찬가지다.
또한 사용자가 버튼을 누른 시점과 모델 서버가 요청을 받은 시점은 다르다. 문서 검색이나 재정렬이 먼저 실행된다면, 그 시간은 모델 추론 바깥에서 발생한다.
| 확인할 구간 | 확인 방법 |
|---|---|
| 검색·전처리 | 검색, 재정렬, 프롬프트 구성 시간을 별도 기록 |
| 요청 대기 | 모델 서버의 큐 대기 시간 확인 |
| 입력 처리 | 실제 입력 토큰 수와 Prefill 시간 확인 |
| 전송·화면 표시 | 서버가 출력을 보낸 시점과 화면 표시 시점 비교 |
예를 들어 검색에 3초, 모델의 첫 출력까지 1초가 걸렸다면 GPU를 바꿔도 검색에 쓰인 3초는 그대로 남을 수 있다. 어느 구간이 오래 걸리는지 먼저 나눠 기록하는 이유다.
4. 답변이 길면 완료 시간도 길어진다
일반적인 Decode에서는 토큰을 순서대로 생성한다. 같은 조건에서 출력해야 할 토큰이 많아지면 완료까지 더 오래 걸린다. Speculative Decoding처럼 여러 후보를 제안하고 검증하는 최적화도 있지만, 모든 출력이 한 번에 완성되는 것으로 이해하면 안 된다.
출력 상한을 낮춘다고 실제 답변이 항상 짧아지는 것은 아니다. 상한은 최대 허용량이다. 원래 답변이 상한보다 짧았다면 상한만 바꿔도 생성량은 같을 수 있고, 너무 낮추면 답변이 중간에 끊길 수 있다.
업무에서 필요한 결과를 먼저 정하는 편이 낫다.
- 분류 작업은 필요한 라벨과 근거만 요청한다.
- 정보 추출은 필요한 필드와 출력 형식을 명시한다.
- 요약은 원하는 항목 수와 분량을 정한다.
단, 출력이 짧아도 필요한 정보가 빠지면 개선으로 보기 어렵다. 응답 길이와 함께 정답률·누락 여부도 확인한다.
5. 혼자 쓸 때 빠르던 모델이 여러 명이 쓰면 느려지는 이유
서빙 엔진은 여러 요청을 배치로 처리해 GPU를 효율적으로 사용할 수 있다. 하지만 서버 전체 처리량이 늘어나는 것과 각 사용자가 빠른 답변을 받는 것은 같은 목표가 아니다.
Continuous Batching은 완료된 요청을 빼고 새 요청을 진행 중인 처리에 참여시킨다. 이때 새 요청의 Prefill과 기존 요청의 Decode가 자원을 공유한다. 스케줄링 방식에 따라 대기 시간과 생성 간격이 달라질 수 있다. TNG의 동시 요청 처리 설명
서버 전체 tokens/s만 보고 대화 서비스의 속도를 평가하지 않는다. 동시 요청을 늘리면서 개별 요청의 TTFT와 완료 시간을 함께 측정해야 한다.
평균뿐 아니라 p95도 기록하면 일부 사용자의 긴 지연을 살펴볼 수 있다. p95는 측정값을 정렬했을 때 약 95%가 그 값 이하에 있다는 뜻이다. 측정 건수가 너무 적으면 안정적인 비교가 어려우므로 요청 수와 테스트 시간도 남긴다.
6. 스트리밍과 캐싱은 무엇을 줄여줄까?
스트리밍: 생성된 내용을 먼저 보여주기
스트리밍은 전체 답변이 끝나기 전에 일부 출력을 전달한다. 사용자가 내용을 읽기 시작하는 시점을 앞당길 수 있지만, 모델의 연산 자체를 자동으로 빠르게 만드는 기능은 아니다.
서버에서는 스트리밍하는데 화면에 한꺼번에 나타난다면 프록시의 버퍼링이나 클라이언트의 표시 방식을 확인할 필요가 있다. 모델 설정만 살펴봐서는 발견하기 어려운 문제다.
Prefix Caching: 동일한 입력 앞부분의 계산 재사용
반복되는 시스템 지시문이나 같은 문서를 포함한 요청에서는 Prefix Caching이 도움이 될 수 있다. vLLM의 Automatic Prefix Caching은 공유되는 접두부의 KV Cache를 재사용해 해당 입력의 계산을 줄인다.
이 기능은 주로 Prefill을 줄이는 데 도움이 된다. 새로운 출력 토큰을 생성하는 Decode를 직접 빠르게 만드는 기능은 아니다. 같은 뜻의 문장이라고 재사용되는 것도 아니므로, 엔진의 캐시 일치 조건을 확인해야 한다. vLLM Prefix Caching 문서
속도 비교에서는 캐시가 없는 경우와 적중한 경우를 나눠 기록한다. 같은 질문만 반복하면 실제 사용자들의 다양한 입력보다 결과가 좋게 나올 수 있다.
7. 장비를 바꾸기 전에 사용할 측정표
아래는 벤치마크 결과가 아니라 비교 실험을 준비하기 위한 표다. 토큰 수는 사용하는 모델의 토크나이저로 확인한다.
| 비교 목적 | 입력 | 출력 조건 | 동시 요청 | 주요 확인 항목 |
|---|---|---|---|---|
| 기준 성능 | 짧은 입력 | 일정한 목표 분량 | 1 | TTFT, TPOT, 전체 시간 |
| 긴 입력의 영향 | 긴 입력 | 기준과 같은 조건 | 1 | TTFT, 실제 입력 토큰 수 |
| 긴 출력의 영향 | 기준과 같은 입력 | 더 긴 목표 분량 | 1 | 실제 출력 토큰 수, 전체 시간 |
| 서비스 부하 | 같은 입력 길이 분포 | 같은 출력 조건 | 단계적으로 증가 | p95 지연, 전체 처리량, 실패율 |
모델 버전, 양자화 형식, 엔진 버전, GPU 구성, 생성 설정을 함께 기록한다. 출력 길이를 정확히 고정하기 어렵다면 실제 생성된 토큰 수를 남겨 비슷한 길이끼리 비교한다.
첫 실행에 모델 로딩이나 초기화가 포함됐다면 평상시 요청과 구분한다. 모델을 준비한 상태의 테스트와 처음 기동하는 테스트는 서로 다른 질문에 답한다.
양자화나 GPU 추가도 이 측정표에서 비교할 후보가 된다. GPU 용량 산정에서 다룬 메모리 확보와 실제 지연 개선은 각각 확인해야 한다.
느린 구간에 맞춰 개선하기
첫 출력이 늦으면 입력 길이와 검색·대기 시간을 확인한다. 출력이 천천히 이어지면 Decode 성능과 동시 부하를 본다. 출력은 빠르게 이어지는데 완료가 늦으면 실제 생성량부터 확인한다.
LLM 응답 속도를 개선하는 출발점은 하나의 tokens/s 숫자가 아니라, 어느 구간에서 사용자가 기다리는지 기록하는 것이다. 같은 업무 입력과 품질 기준을 유지하면서 한 가지 조건씩 바꿔야 개선 효과를 판단할 수 있다.