AI API 지연 지표: TTFT, 첫 유효 응답 및 출력 속도
Upstream Header, 첫 SSE Event, 첫 Effective Response, 첫 Visible Text, End-to-End Latency와 Output Speed를 구분하는 가이드입니다.
AI API latency는 하나의 숫자가 아닙니다. Streaming request에서는 upstream Header, 첫 non-empty SSE Event, 첫 의미 있는 Content 또는 Action, 첫 Visible Text, Response Completion을 각각 기록해야 합니다. 서로 다른 질문에 답하는 지표를 모두 TTFT라고 부르면 원인을 구분할 수 없습니다.
Text-only Chat에서는 Time to First Visible Text가 사용자 경험을 나타냅니다. Reasoning 또는 Tool workflow에서는 Function Arguments 같은 First Effective Output이 더 일찍 나타날 수 있습니다. Generation Speed는 출력 시작 이후의 별도 측정입니다.
Metric 이름보다 Request Timeline부터 만들기
같은 Monotonic Clock과 Origin을 사용합니다.
t0 Gateway가 Request 수신
t1 Upstream Request 시작
t2 Upstream Response Headers 도착
t3 첫 Non-empty SSE Event 도착
t4 첫 Effective Content 또는 Action 도착
t5 첫 Visible Text Delta 도착
t6 Upstream Body 완료 또는 종료
t7 Gateway Handler 완료
모든 Request에 모든 시점이 있는 것은 아닙니다. 없는 값은 0이 아니라 absent로 저장해야 합니다.
| Field | 측정 내용 | 경계 |
|---|---|---|
auth_ms |
Token·User 인증 | Local phase |
distribution_ms |
Channel Selection·Routing | Local phase |
body_read_ms |
Downstream Body 읽기 | Routing 전 느린 Upload 탐지 |
upstream_headers_ms |
Upstream Start부터 Headers | Gateway Receipt가 Origin이 아님 |
first_sse_event_ms |
Receipt부터 첫 SSE Event | Metadata-only일 수 있음 |
first_response_ms |
첫 Effective Content/Action | Text, Reasoning, Function Arguments 포함 |
first_text_delta_ms |
첫 Visible Text | Text가 없으면 absent |
upstream_done_ms |
Upstream Body 종료 | Close가 성공을 뜻하지 않음 |
total_handler_ms |
Relay 최종 완료점 | Gateway E2E에 가장 가까움 |
visible_output_tps |
Output Tokens / Visible Window | 사용자 출력 진단, System TPS 아님 |
Origin이 다른 duration을 직접 빼지 마십시오.
TTFT의 실제 의미를 구분하기
NVIDIA NIM Benchmarking 가이드는 TTFT에 network, queueing, prompt prefill이 일반적으로 포함되며 empty initial response는 제외해야 한다고 설명합니다. 현대 API는 Visible Text 전 Metadata, Reasoning Summary, Function Arguments, Tool Input, Heartbeat를 보낼 수 있습니다.
| 이름 | 권장 의미 | 용도 |
|---|---|---|
| Time to Headers | Request Start부터 Upstream Headers | Network와 Admission |
| Time to First Event | 첫 Non-empty SSE | Transport Liveness |
| Time to First Effective Response | 유용한 Content 또는 Action | Agent와 Reasoning Responsiveness |
| Time to First Visible Text | Render 가능한 Text | Chat 사용자 경험 |
Dashboard가 TTFT만 표시한다면 어떤 정의인지 반드시 문서화합니다.
Responsiveness와 Generation Speed 분리하기
end_to_end_latency = final_response_time - request_start_time
visible_generation_window = final_response_time - first_visible_text_time
visible_output_tps = output_tokens / visible_generation_window_seconds
Inter-token Latency는 TTFT를 제외하고 보통 남은 시간을 output_tokens - 1로 나눕니다. SSE Event나 Text Delta 수를 Token 수로 사용하면 안 됩니다. Event 하나에는 Token이 없거나 여러 개 있을 수 있습니다.
First Text가 빠르고 TPS가 낮으면 빠르게 시작한 뒤 느려집니다. First Text가 늦고 TPS가 높으면 오래 멈춘 뒤 빠르게 끝납니다. Per-user TPS와 Aggregate Throughput도 별도입니다.
Reasoning과 Tool이 Visible Text보다 먼저 올 수 있음
Text-only에서는 first_response_ms와 first_text_delta_ms가 비슷합니다. Function Call Arguments가 1.8초, Visible Text가 6.4초에 온다면 시스템은 1.8초에 Action을 만들었지만 사용자는 6.4초까지 Text를 보지 못했습니다.
- Terminal Agent는 First Effective Action이 중요합니다.
- Text-only UI는 First Visible Text를 사용합니다.
- Tool-call API에는 Visible Text가 없을 수 있습니다.
- Early SSE Envelope는 연결 진행만 증명합니다.
AI API Streaming 가이드의 Parser 경계를 적용한 뒤 Metric을 계산해야 합니다.
느린 단계를 고정된 순서로 진단하기
| 증상 | 핵심 Metric | 우선 확인 |
|---|---|---|
| Header 전 지연 | upstream_headers_ms |
Network, Admission, Queue, Route, Region |
| Header 후 Effective Output 지연 | first_response_ms |
Model Queue, Prefill, Reasoning, Inflight |
| Event는 빠르고 Output은 늦음 | SSE→Response Gap | Metadata, Heartbeat, Reasoning Startup |
| Action은 빠르고 Text는 늦음 | Response→Text Gap | Tool/Reasoning, Composition |
| Text 후 생성이 느림 | visible_output_tps |
Decode, Contention, Long Context |
| Upstream 정상 | Local fields | Auth, Policy, Client Upload |
Metric 하나만으로 Root Cause를 단정하지 말고 Route, Region, Provider, Concurrent Load를 함께 봅니다.
세 가지 Synthetic Trace 읽기
Trace A: Upstream Headers 대기
| Metric | Value |
|---|---|
upstream_headers_ms |
6,100 ms |
first_response_ms |
6,350 ms |
first_text_delta_ms |
6,400 ms |
total_handler_ms |
9,200 ms |
visible_output_tps |
42 |
대부분의 지연이 Header 전입니다. UI보다 Route, Admission, Network, Region, Load를 먼저 확인합니다.
Trace B: Visible Text보다 빠른 Action
| Metric | Value |
|---|---|
upstream_headers_ms |
240 ms |
first_response_ms |
2,900 ms |
first_text_delta_ms |
8,700 ms |
total_handler_ms |
10,200 ms |
visible_output_tps |
55 |
2.9초에 Action이 있지만 Text는 5.8초 뒤입니다. Reasoning 또는 Tool Phase를 확인해야 하며 Header Timeout 증가는 해결책이 아닙니다.
Trace C: 빠른 시작, 느린 생성
| Metric | Value |
|---|---|
upstream_headers_ms |
260 ms |
first_response_ms |
420 ms |
first_text_delta_ms |
430 ms |
total_handler_ms |
20,430 ms |
visible_output_tps |
9.8 |
Text는 빨리 나오지만 20초 가까이 생성합니다. Output Length, Context, Channel, Inflight, Provider를 비교합니다. First-output Timeout으로는 잡히지 않습니다.
통제된 조건에서만 Latency 비교하기
정확한 Model과 Route, Input/Output Token Distribution, Streaming, Reasoning Effort, Tools, Region, Network Path, Concurrency, Sampling, Max Output, Warmup, Retry Policy, Sample Size, Percentile Method를 기록합니다.
Average 하나 대신 p50, p95, p99를 비교하고 Timeout과 Error를 제외하지 마십시오. Prompt, Output Length, Concurrency가 다르면 Model Speed Ranking으로 제시할 수 없습니다.
Content 대신 Diagnostic Metadata 보관하기
Request ID, Timestamp, Model, Group, Channel Reference, Status, Token Counts, Timing Fields, Event Counts, Inflight, Coarse Region, upstream_headers_slow 같은 Classifier만으로도 진단할 수 있습니다.
Prompt, Response, API Key, Plaintext Identity를 저장할 필요는 없습니다. Metadata에도 Retention과 Access Control을 적용합니다.
조사는 Timeline에서 시작하고 안정적인 AI API 라우팅으로 각 Attempt Route를 비교하며 AI API 오류 문제 해결로 Terminal Status를 연결합니다. Admission, Model Startup, Reasoning/Tool, Visible Generation, Local Gateway Overhead를 이렇게 분리할 수 있습니다.