AI 요청이 성공적으로 반환되는 것이 AI 제품이 반응성이 좋다고 느껴지게 만드는 것과 동일하지는 않습니다.

대화형 제품에서 사용자는 최종 완료 시간(completion time)을 인지하기 전에 그 사이의 침묵을 먼저 알아차립니다.

사용자들은 다음과 같이 질문합니다:

• 요청이 시작되었나?
• 모델이 생각 중인가?
• 다시 시도해야 하나?
• 앱이 멈췄나?

이것이 바로 멀티 모델 (multi-model) AI 애플리케이션에서 첫 번째 토큰 생성 시간, 즉 TTFT (Time to First Token)가 별도의 지표로서 가치를 갖는 이유입니다.

더 빠른 완료가 여전히 더 느리게 느껴질 수 있는 이유

고객 지원 챗봇에 사용되는 두 가지 모델을 상상해 보세요.

• 모델 A는 700ms 만에 스트리밍을 시작하여 8초 만에 완료됩니다.
• 모델 B는 4초 만에 스트리밍을 시작하여 6초 만에 완료됩니다.

모델 B의 총 완료 시간은 더 짧습니다.

하지만 처음 4초 동안 아무런 일도 일어나지 않기 때문에 사용자에게는 여전히 더 느리게 느껴질 수 있습니다.

이러한 차이는 앱이 채팅, RAG (Retrieval-Augmented Generation), 코딩 에이전트 (coding agents), 문서 분석, 자동화 및 백그라운드 작업을 위해 여러 모델을 사용할 때 더욱 중요해집니다.

단일 평균 지연 시간 (latency) 수치로는 실제 경험을 설명할 수 없습니다.

TTFT가 실제로 측정하는 것

첫 번째 토큰 생성 시간 (Time to first token)은 요청을 보낸 시점과 첫 번째로 보이는 스트리밍 응답을 받는 시점 사이의 시간입니다.

여기에는 모델 생성 외에도 다음과 같은 요소들이 포함될 수 있습니다:

• 인증 (authentication) 및 요청 검증 (request validation)
• 대기 시간 (queue time)
• 모델 라우팅 (model routing)
• 검색 (retrieval)
• 제공자 연결 시간 (provider connection time)
• 프롬프트 프리필 (prompt prefill)
• 추론 노력 (reasoning effort)
• 도구 준비 (tool preparation)
• 폴백 결정 (fallback decisions)

TTFT가 느리다고 해서 항상 선택된 모델이 느린 것을 의미하지는 않습니다.

문제는 거대한 프롬프트, 캐시 미스 (cache miss), 느린 검색 단계, 스트리밍을 차단하는 도구 호출 (tool call), 또는 폴백 경로 (fallback route)일 수 있습니다.

그렇기 때문에 팀에는 요청 수준의 가시성 (request-level visibility)이 필요합니다.

멀티 모델 시스템은 다양한 지연 시간 프로필을 가집니다

서로 다른 모델들은 프로덕션 환경에서 매우 다르게 동작할 수 있습니다.

어떤 모델은 배치 추론 (batch reasoning)에는 탁월하지만 실시간 채팅 경험에는 적합하지 않을 수 있습니다. 또 다른 모델은 스트리밍 (streaming)은 빠르지만 완료하는 데 더 오래 걸릴 수도 있습니다. 추론 모델 (reasoning model)은 첫 번째 토큰을 생성하기 전까지 더 많은 시간을 소비할 수 있습니다. 폴백 모델 (fallback model)은 가용성 (availability)을 보호하는 동안 사용자 경험을 조용히 악화시킬 수도 있습니다.

다음과 같이 질문하지 마세요:

우리의 AI 지연 시간 (latency)은 얼마인가?

대신 다음과 같이 질문하세요:

이 워크플로 (workflow), 이 모델, 이 경로 (route), 그리고 이 프롬프트 크기 (prompt size)에 대한 p95 첫 번째 토큰 생성 시간 (time to first token)은 얼마인가?

그 질문이 더 나은 의사결정으로 이어집니다.

올바른 필드를 기록하세요

모든 AI 요청에 대해 HTTP 상태 코드 이상의 정보를 기록하십시오.

{
...