TTFT의 작동 방식
TTFT를 측정하려면 두 개의 타임스탬프가 필요합니다.
TTFT = 첫 출력 시각 − 요청 시작 시각
공식은 간단합니다. 하지만 어떤 타임스탬프를 선택할지는 간단하지 않습니다.
클라이언트 관측 TTFT는 클라이언트가 요청을 전송하는 시점에 시작하고, 콘텐츠를 포함한 첫 토큰 또는 스트리밍 청크를 클라이언트가 수신하는 시점에 끝납니다. 이 구간에는 다음이 포함될 수 있습니다.
- 서비스로 요청 전송
- 인증, 라우팅 및 대기열 처리
- 프롬프트를 토큰으로 변환하는 작업
- 프롬프트 전체를 처리하는 작업. 이 단계를 프리필(prefill)이라고 합니다.
- 첫 출력 토큰 선택
- 해당 출력을 클라이언트로 변환하고 전송하는 작업
프리필 단계에서 모델은 입력을 처리하고, 이후 토큰을 생성할 때 재사용할 어텐션 정보를 저장할 준비를 합니다. 프롬프트가 길수록 일반적으로 더 많은 프리필 작업이 필요합니다. 서비스가 혼잡하면 이 작업이 시작되기 전에 대기열 처리 시간이 추가될 수 있습니다.
엔진 수준의 TTFT는 더 좁은 범위를 사용할 수 있습니다. 예를 들어, vLLM의 서버 메트릭은 프런트엔드 도착 시점, 현재는 토큰화가 시작되는 시점에 시작합니다. 따라서 클라이언트의 네트워크 경로나 상위 애플리케이션에서 수행된 작업은 포함하지 않습니다.
따라서 TTFT는 모든 상황에서 보편적으로 비교 가능한 하나의 수치가 아닙니다. NVIDIA의 벤치마킹 문서는 TTFT를 쿼리 제출 시점부터 첫 토큰 수신 시점까지로 정의합니다. Google Cloud의 용어집은 모델이 프롬프트를 받은 시점부터 첫 토큰을 생성하는 시점까지로 설명합니다. 두 관례 모두 유용하지만 요청의 서로 다른 구간을 측정합니다.
예시
스트리밍 요청 하나의 시간 흐름이 다음과 같다고 가정해 보겠습니다.
- 0ms: 클라이언트가 프롬프트를 전송하고 타이머를 시작합니다.
- 40ms: 서비스가 요청을 수신합니다.
- 110ms: 대기열 처리가 끝나고 처리가 시작됩니다.
- 350ms: 프롬프트 처리가 끝나고 첫 토큰이 생성됩니다.
- 390ms: 클라이언트가 콘텐츠를 포함한 첫 청크를 수신합니다.
클라이언트 관측 TTFT는 390ms입니다.
요청 도착 시점에 시작하여 토큰 생성 시점에 끝나는 서버 측 측정값은 310ms입니다. 350ms에서 40ms를 뺀 값입니다.
80ms의 차이는 측정 범위에서 비롯됩니다. 어느 타이머가 부정확하다는 뜻은 아닙니다.
같은 예시는 TTFT를 총 지연 시간으로 해석해서는 안 되는 이유도 보여 줍니다. 생성은 390ms 이후에도 계속됩니다. 이후 토큰 사이의 간격과 마지막 토큰까지 걸린 시간은 별도로 측정해야 합니다.
TTFT가 중요한 시점과 이유
출력이 시작되는 즉시 활용될 수 있을 때 TTFT가 가장 중요합니다. 채팅 인터페이스, 코딩 어시스턴트 및 실시간 텍스트 시스템은 첫 콘텐츠가 도착한 후 진행 상황을 표시할 수 있습니다. TTFT가 짧으면 해당 피드백이 나타나기 전의 조용한 대기 시간이 줄어듭니다.
애플리케이션이 완전한 답변을 기다려야 하는 경우에는 TTFT만으로는 중요도가 낮습니다. 예를 들어 일괄 요약 작업은 총 완료 시간이나 전체 처리량을 더 중요하게 볼 수 있습니다.
요청의 시작 구간을 조사할 때 TTFT를 사용하세요. 높은 값은 긴 프롬프트, 프롬프트 캐시를 활용하지 못한 상황, 부하로 인한 대기열 처리, 콜드 워커, 프런트엔드 오버헤드 또는 네트워크 거리 때문일 수 있습니다. TTFT만으로는 어느 단계가 원인인지 알 수 없습니다. 트레이스 또는 대기열, 프리필 및 네트워크에 대한 별도 측정값과 함께 사용하세요.
시스템을 비교할 때는 워크로드를 동일하게 유지하세요. 동일한 프롬프트 길이 분포, 캐시 상태, 동시성, 스트리밍 동작, 클라이언트 위치, 시작 및 종료 이벤트를 사용해야 합니다. 유난히 빠른 단일 요청 하나가 아니라 중앙값과 꼬리 백분위수 같은 분포를 보고하세요. MLCommons의 벤치마크 방법론이 정의된 시나리오를 사용하고 프롬프트 단계의 TTFT를 생성 단계의 시간 측정과 분리하는 이유도 여기에 있습니다.
흔한 오해
TTFT가 낮다고 해서 전체 응답이 빠르다는 뜻은 아닙니다. 한 시스템은 빠르게 시작한 뒤 느리게 생성할 수 있습니다. 반대로 다른 시스템은 시작은 느리지만 나머지 출력을 빠르게 생성할 수 있습니다.
스트리밍이 자동으로 모델의 계산 시간을 줄여 주는 것은 아닙니다. 스트리밍은 응답이 완료되기 전에 클라이언트가 부분 출력을 확인할 수 있게 합니다. 서버, 프록시 또는 클라이언트에서 버퍼링이 발생하면 모델이 첫 토큰을 생성하는 시점이 같더라도 관측된 TTFT가 더 길어질 수 있습니다.
첫 번째 청크가 항상 토큰 하나인 것은 아닙니다. 스트리밍 프로토콜은 여러 토큰을 하나의 이벤트로 묶을 수 있습니다. 사용 가능한 출력이 나타나는 시점을 측정하려는 경우, 빈 이벤트나 메타데이터가 타이머를 멈추게 해서는 안 됩니다.
맥락을 고려하지 않은 ‘좋은’ TTFT란 없습니다. 프롬프트 길이, 부하, 하드웨어, 캐싱, 네트워크 경로 및 측정 범위가 모두 결과를 바꿉니다. 목표값을 정할 때는 해당 목표가 적용되는 워크로드와 백분위수를 명시해야 합니다.
다음에 읽을 내용
전체 요청 타임라인에서 TTFT가 어디에 해당하는지 알아보려면 추론 지연 시간이란?을 읽어 보세요. 첫 토큰이 도착한 후의 생성 속도는 초당 토큰 수란?에서 알아볼 수 있습니다. 초기 대기 시간을 생성 속도 및 시스템 용량과 비교하려면 지연 시간 vs. TTFT vs. 초당 토큰 수 vs. 처리량을 사용하세요.