처리량이 늘었는데 첫 토큰은 왜 더 늦게 나올까? AI 추론 업그레이드 검수 체크리스트

개념도: 출력 시작까지의 대기 시간, 스트리밍 간격, 전체 처리량은 서비스의 서로 다른 측면을 나타냅니다. 실측 데이터가 아닙니다.

서버가 초당 더 많은 토큰을 생성하는데도 채팅창에 답변이 나타나기까지는 더 오래 걸릴 수 있습니다. 추론 업그레이드를 승인하기 전에 실무적인 질문을 던져야 합니다. 사용자의 대기 시간 중 어느 구간을 줄이려는 걸까요?

하나의 평가표에 담긴 두 가지 ‘속도’

10월 6일 병합된 vLLM PR #60140은 GLM-5.3의 KV 캐시를 FP8로 전환한 결과를 보고합니다. TP4, 입력 8,000토큰, 출력 1,000토큰, 동시 요청 수 1·4·16이라는 조건에서 표에 제시된 처리량 증가 폭은 2.3%~5.5%입니다. 그러나 첫 토큰까지 걸리는 시간(TTFT)의 중앙값은 6.9%~11.1% 늘었습니다. 총 지연 시간의 중앙값은 3.1%~6.3% 줄었습니다. 답변은 더 늦게 시작됐지만 더 일찍 끝난 것입니다. 출처: PR #60140

이 수치는 기여자가 보고한 결과이며, 우리는 이를 재현하지 않았습니다. 더 긴 입력 길이 전반을 검증한 결과도 포함되어 있지 않습니다. 후속 패치는 이 기본 동작의 적용 범위를 NVIDIA SM100으로 제한했습니다. 이 결과를 모든 GLM 배포 환경에 적용하는 것은 근거의 범위를 벗어납니다. 출처: PR #60281

대기 시간을 구간별로 나누기

사용자는 첫 출력을 기다린 다음 이어지는 내용을 기다리고, 마지막으로 완성된 답변을 받습니다. 서버 처리량은 전체 산출량을 측정하고, TTFT는 출력 시작까지의 지연을 측정합니다. 토큰 간 지연 시간(ITL)은 연속된 스트리밍 출력 사이의 간격을 나타내며, 완료 시간은 요청 전체를 포괄합니다. vLLM의 서버 측 TTFT에는 입력 처리도 포함되므로 GPU 연산 시간만을 나타내는 지표가 아닙니다. 네트워크, 게이트웨이, 화면 표시에서 발생하는 오버헤드도 클라이언트 측에서 관찰할 필요가 있습니다. 출처: 지표 설계

스케줄링에는 절충이 따릅니다. vLLM의 청크 단위 프리필(chunked prefill)은 긴 입력을 여러 조각으로 나누고, 이미 생성 중인 요청과 함께 스케줄링합니다. 공식 문서는 배치에 허용하는 토큰 수가 적으면 ITL에 유리하고, 많으면 TTFT에 유리하다고 설명합니다. 이는 지연 시간 지표가 서로 다른 방향으로 움직일 수 있는 일반적인 원리입니다. 앞서 언급한 PR은 이 원리가 해당 FP8 변경에 따른 TTFT 악화의 원인이라고 입증하지 않았습니다. 출처: 최적화 가이드

캐시 역시 어느 단계의 작업을 줄이는지 살펴봐야 합니다. 접두사 캐싱(prefix caching)은 공통 입력 접두사의 연산 결과를 재사용해 프리필을 돕습니다. 새 토큰을 생성하는 디코딩 작업을 직접 줄이지는 않습니다. 따라서 하나의 긴 문서를 두고 반복해서 질문하는 경우와 긴 답변 생성이 주를 이루는 워크로드는 서로 다른 효과를 얻을 수 있습니다. 출처: 접두사 캐싱과 한계

업그레이드 전에 검수 기준 정하기

다음은 우리가 제안하는 테스트 계획이며, 이미 완료한 실험 결과가 아닙니다.

1. 비교 조건을 일정하게 유지합니다. GPU, 모델 버전, 추론 프레임워크 커밋, 양자화 방식, 병렬화 방식, 추측 디코딩, 샘플링 설정을 기록합니다. 성능 향상의 원인을 식별할 수 있도록 한 번에 평가 대상 항목 하나만 변경합니다.

2. 작은 테스트 매트릭스를 만듭니다. 실제 작업 중 짧은 대화, 긴 문서에 대한 짧은 답변, 긴 출력이라는 세 가지 유형을 고릅니다. 각 유형을 새로운 접두사와 재사용 가능한 접두사로 나누고, 저부하·일상 부하·처리 한계에 가까운 부하에서 각각 테스트합니다. 총 18개 조건입니다. 입력은 모델이 지원하는 범위 안으로 제한하고, 부하 수준은 자체 트래픽을 기준으로 정합니다.

3. 트래픽 급증 상황을 추가합니다. 실제 도착률, 실제 동시 요청 수, 큐 대기, 실패한 요청을 기록합니다. 동시 요청 수를 고정한 테스트와 사용자가 갑자기 몰리는 상황은 서로 다른 부담을 줍니다. 속도 제한 장치가 대기 시간을 클라이언트로 옮길 수도 있습니다. vLLM 벤치마크 도구는 요청률과 최대 동시 요청 수를 별도로 설정하며, 클라이언트 큐 지표도 제공합니다. 출처: 벤치마크 매개변수

4. 모든 조건에서 전체 평가 항목을 기록합니다. 최소한 TTFT, ITL, 총 지연 시간의 p50/p95/p99와 처리량, 캐시 적중, 선점, 타임아웃, 오류율을 기록합니다. 테스트를 독립적으로 반복하고 워밍업 방법과 표본 수를 공개합니다. 표본이 적을 때는 특히 꼬리 구간의 백분위수를 신중하게 해석해야 합니다. 양자화 변경에는 별도의 작업 품질 검증도 필요합니다. 속도만으로 정확성을 입증할 수는 없습니다.

5. 개선 폭을 비교하기 전에 기준값을 정합니다. 대화형 어시스턴트는 첫 출력까지의 시간과 스트리밍 중 멈춤을 우선할 수 있고, 오프라인 배치 작업은 완료한 작업량을 우선할 수 있습니다. 실제 기준값은 제품 요구사항에 따라 정해야 합니다. 성공한 요청 중 지연 시간 목표까지 충족한 요청을 세면 서비스 처리 능력을 더 유용하게 평가할 수 있습니다. vLLM은 TTFT, 출력 토큰당 시간, 종단 간 지연 시간에 대한 goodput 기준값을 지원합니다. 출처: goodput 옵션

결과를 사용자 경험과 연결하기

유용한 검수 보고서는 다음과 같은 구체적인 질문에 답해야 합니다. “우리 트래픽과 품질 요구사항 아래에서 시간당 요청을 얼마나 더 완료할 수 있으며, 가장 오래 기다리는 사용자의 대기 시간은 얼마나 될까?”

처리량 증가는 반가운 일입니다. 대기 시간, 품질, 실패와 함께 살펴봐야 업그레이드가 정확히 무엇을 개선하는지 알 수 있습니다.

출처 확인일: 2026년 10월 19일. 이 글은 기여자가 공개한 벤치마크와 공식 문서를 바탕으로 한 엔지니어링 분석입니다. 테스트 매트릭스는 우리의 제안이며, 독립적인 성능 또는 품질 테스트는 수행하지 않았습니다. 문서의 latest 페이지는 변경될 수 있으므로 실제 배포 버전을 확인하세요.