모델 API를 평가할 때 LLM Latency(지연 시간)와 Throughput(처리량) 간의 상충 관계(trade-off)를 이해하는 것은 사용자 경험과 인프라 비용을 모두 최적화하는 데 필수적입니다. Latency는 모델이 쿼리에 응답하는 데 걸리는 시간을 측정하며, Throughput은 특정 시간 동안 시스템이 처리하거나 생성한 토큰의 양을 측정합니다. 개발자와 AI 제품 빌더에게 있어 한 가지 지표를 최적화하는 것은 종종 다른 지표와의 타협을 의미합니다.
잘못된 속도 지표를 선택하면 사용자 인터페이스가 느려지거나 불필요하게 높은 API 비용이 발생할 수 있습니다. 이 분석에서는 이러한 지표를 측정하고, 특정 워크로드에 적합한 API를 선택하며, 최적화 전략을 구현하기 위한 프레임워크를 제공합니다.
핵심 요약
- Time to First Token (TTFT)는 채팅 인터페이스와 같은 대화형 애플리케이션에서 사용자 체감 속도에 직접적인 영향을 미치는 중요한 Latency 지표입니다.
- Tokens Per Second (TPS)는 문서 요약이나 대량 데이터 추출과 같은 백그라운드 처리 작업에서 스트림당 처리량을 나타내는 주요 지표입니다.
- 모델 아키텍처와 크기가 기본 성능을 결정하며, DeepSeek V4 Flash나 Gemini 3.5 Flash와 같은 소형 모델은 Claude Fable 5나 GPT-5.5와 같은 플래그십 모델보다 더 빠른 속도를 제공합니다.
- 멀티 프로바이더 라우팅을 통해 개발자는 실시간 프로바이더 성능에 따라 Latency나 Throughput을 동적으로 최적화할 수 있습니다.
핵심 지표 정의: Latency vs. Throughput
API를 구매하거나 라우팅할 때 정보에 입각한 결정을 내리려면 개발자는 "속도"를 별개의 측정 가능한 구성 요소로 분해해야 합니다.
LLM API 요청 타임라인:
[사용자 요청 전송]
│
▼ (네트워크 전송 + 프롬프트 처리)
[Time to First Token (TTFT)] <--- 대화형 UX에 필수적
│
▼ (자기회귀 생성: 초당 토큰 수)
[Inter-Token Latency (ITL)] <--- 읽기 편의성 결정
│
▼ (생성 완료)
[Total Latency] <--- 스트리밍하지 않는 차단 호출에 필수적
1. Time to First Token (TTFT)
TTFT는 API 요청을 보낸 시점부터 응답의 첫 번째 토큰을 받을 때까지의 시간입니다. 이 지표에는 네트워크 왕복 시간, 프롬프트 직렬화, 그리고 모델이 입력 토큰을 처리하는 데 필요한 시간(prefill 단계)이 포함됩니다. 대화형 애플리케이션의 경우, 사용자가 응답 스트리밍이 시작되는 것을 얼마나 빨리 볼 수 있는지 결정하므로 TTFT가 가장 중요한 지표입니다.
2. Inter-Token Latency (ITL)
ITL은 스트리밍 단계에서 연속적인 토큰을 생성하는 사이의 평균 시간입니다. ITL이 너무 높으면 텍스트가 사람이 읽는 속도보다 느리게 스트리밍되어 사용자 경험이 저하됩니다. 안정적이고 낮은 ITL은 텍스트의 부드러운 렌더링을 보장합니다.
3. Tokens Per Second (TPS)
TPS는 모델의 생성 처리량을 나타냅니다. 이는 전체 출력 토큰 수를 전체 생성 시간(prefill 단계 제외)으로 나눈 값입니다. 처리량을 평가할 때 개발자는 다음을 구분해야 합니다.
- Single-user TPS: 단일 활성 스트림의 생성 속도.
- System throughput: API 프로바이더가 모든 활성 사용자 전반에서 동시에 처리할 수 있는 총 토큰 수.
4. Total Latency
Total Latency는 API 요청의 시작부터 끝까지의 전체 시간입니다. 구조화된 JSON 추출이나 백그라운드 분류와 같이 스트리밍하지 않는 요청의 경우, Total Latency가 모니터링해야 할 주요 지표입니다.
아키텍처 상충 관계: 속도가 달라지는 이유
LLM Latency와 Throughput 간의 상충 관계는 트랜스포머 아키텍처의 물리적 특성과 하드웨어 메모리 대역폭에 기인합니다. TTFT를 결정하는 prefill 단계에서는 전체 입력 프롬프트를 한 번에 처리하므로 계산을 병렬화하기 매우 좋습니다. 이 단계는 일반적으로 컴퓨팅 집약적(compute-bound)입니다.
TPS를 결정하는 생성 단계에서는 모델이 토큰을 하나씩 생성합니다. 새로운 토큰이 생성될 때마다 HBM(고대역폭 메모리)에서 GPU SRAM으로 모든 모델 가중치를 로드해야 합니다. 이 자기회귀(autoregressive) 과정은 메모리 대역폭 제한(memory-bandwidth bound)을 받습니다.
이러한 제약으로 인해 개발자는 자신의 주요 성능 요구 사항에 맞춰 모델을 선택해야 합니다.
- 플래그십 모델: Claude Fable 5, Claude Opus 4.8, GPT-5.5와 같은 모델은 원시 속도보다 추론의 깊이를 우선시합니다. 이들은 방대한 파라미터 수를 가지고 있어 더 높은 TTFT와 더 낮은 TPS를 보입니다.
- 빠르고 저렴한 모델: DeepSeek V4 Flash, Gemini 3.5 Flash, Laguna XS 2.1과 같은 모델은 속도에 최적화되어 있습니다. 이들은 더 적은 파라미터 수, 추측 디코딩(speculative decoding) 또는 증류된 아키텍처를 사용하여 매우 낮은 TTFT와 높은 TPS를 제공합니다.
개발자는 TokenLab LLM API Leaderboard for Developers를 참조하여 이러한 모델 계층 전반의 실시간 속도 지표를 비교할 수 있습니다.
의사결정 프레임워크: Latency와 Throughput 중 무엇을 우선할 것인가
Latency와 Throughput 중 무엇을 우선할지는 애플리케이션의 사용 사례에 전적으로 달려 있습니다.
| 사용 사례 | 주요 지표 | 보조 지표 | 권장 모델 클래스 |
|---|---|---|---|
| 대화형 챗봇 | Time to First Token (TTFT) | Inter-Token Latency (ITL) | Fast Frontier (예: Gemini 3.5 Flash) |
| 코딩 어시스턴트 | TTFT & 단일 스트림 TPS | Total Latency | Specialized Coding (예: Claude Sonnet 5, Kimi K2.7 Code) |
| 대량 데이터 추출 | System Throughput | 작업당 비용 | Low-Cost Open-Weight (예: DeepSeek V4 Flash, GLM-5.2) |
| 자율 에이전트 | Total Latency (비스트리밍) | TTFT | High-Reasoning Open-Weight (예: DeepSeek V4 Pro) |
| 이미지/비디오 생성 | Total Latency | 이미지당 비용 | Specialized Media APIs (예: Nano Banana 2, Seedance) |
대화형 애플리케이션 (Latency 우선)
대화형 UI, 고객 지원 봇, 실시간 검색 어시스턴트의 경우 시스템이 응답하지 않는 것처럼 느껴지면 사용자 이탈률이 높아집니다. 개발자는 TTFT를 최소화하는 데 우선순위를 두어야 합니다. 전체 생성 시간이 몇 초가 걸리더라도 TTFT가 300밀리초 미만이면 사용자는 계속 참여하게 됩니다.
배치 처리 및 파이프라인 (Throughput 우선)
수천 개의 PDF 송장 처리, 일일 보고서 생성, 배치 평가 실행과 같은 오프라인 작업의 경우 TTFT는 중요하지 않습니다. 목표는 가능한 최저 비용으로 분당 처리되는 총 토큰 양을 극대화하는 것입니다. 개발자는 시스템 처리량과 비용 효율성에 집중해야 합니다. 배치 처리 중 비용 최적화에 대한 심층 분석은 TokenLab AI Model Routing Benchmark Cost Per Task를 참조하십시오.
API 성능 측정: 실용적인 코드 예제
TTFT, ITL, TPS를 정확하게 측정하려면 스트리밍 API를 사용하고 요청 수명 주기의 특정 지점에서 타임스탬프를 기록해야 합니다. 아래는 특정 모델에 대해 이러한 지표를 측정하기 위해 OpenAI 호환 클라이언트를 사용하는 실행 가능한 Python 스크립트입니다.
import time
import os
from openai import OpenAI
# 클라이언트 초기화 (OpenRouter 또는 호환되는 프로바이더용으로 구성)
client = OpenAI(
base_url="https://openrouter.ai/api/v1",
api_key=os.environ.get("OPENROUTER_API_KEY", "your_api_key_here")
)
def measure_api_performance(model_name: str, prompt: str):
print(f"Evaluating speed metrics for: {model_name}")
start_time = time.time()
response = client.chat.completions.create(
model=model_name,
messages=[{"role": "user", "content": prompt}],
stream=True
)
ttft = None
token_timestamps = []
total_tokens = 0
for chunk in response:
chunk_time = time.time()
# 청크에 텍스트 콘텐츠가 있는지 확인
if chunk.choices and chunk.choices[0].delta.content:
content = chunk.choices[0].delta.content
# 토큰 수 추정 (대략적인 측정을 위해 1 토큰 ≈ 4 문자)
estimated_tokens = max(1, len(content) // 4)
total_tokens += estimated_tokens
if ttft is None:
ttft = chunk_time - start_time
print(f"-> Time to First Token (TTFT): {ttft:.3f} seconds")
token_timestamps.append(chunk_time)
end_time = time.time()
total_duration = end_time - start_time
generation_time = total_duration - ttft if ttft else total_duration
# Inter-Token Latency (ITL) 및 Tokens Per Second (TPS) 계산
if len(token_timestamps) > 1:
intervals = [token_timestamps[i] - token_timestamps[i-1] for i in range(1, len(token_timestamps))]
avg_itl = sum(intervals) / len(intervals)
tps = total_tokens / generation_time if generation_time > 0 else 0
else:
avg_itl = 0
tps = 0
print(f"-> Total Latency: {total_duration:.3f} seconds")
print(f"-> Average Inter-Token Latency (ITL): {avg_itl:.3f} seconds")
print(f"-> Estimated Throughput (TPS): {tps:.2f} tokens/sec")
print("-" * 50)
# 빠르고 저렴한 모델을 사용한 예시
if __name__ == "__main__":
test_prompt = "Write a 200-word essay on the history of computing."
# 현재 저비용 라우팅 모델 예시 사용
measure_api_performance("google/gemini-3.5-flash", test_prompt)
API 구매자를 위한 최적화 전략
측정 결과 선택한 API가 너무 느리거나 비싸다면, 몇 가지 최적화 전략을 통해 성능을 개선할 수 있습니다.
1. 프롬프트 최적화 및 Prefill 감소
prefill 단계는 입력 프롬프트의 크기에 따라 확장되므로, 프롬프트 길이를 줄이면 TTFT가 직접적으로 감소합니다.
- 불필요한 지침을 제거합니다.
- 프로바이더가 지원하는 경우 시스템 프롬프트 캐싱을 사용합니다. 이를 통해 API 호스트는 긴 시스템 프롬프트의 컴파일된 상태를 캐싱하여 후속 요청 시 prefill 계산을 건너뛸 수 있습니다.
2. 동적 프로바이더 라우팅
OpenRouter 프로바이더 선택 문서에 따르면, 모델의 성능은 요청을 처리하는 기본 호스트(프로바이더)에 따라 크게 달라질 수 있습니다. 일부 프로바이더는 낮은 Latency에 최적화되어 있고, 다른 프로바이더는 속도를 희생하는 대신 더 낮은 비용을 제공합니다.
라우팅 계층을 활용하면 개발자는 다음을 수행할 수 있습니다.
- 여러 프로바이더에 쿼리하여 현재 가장 낮은 Latency를 찾습니다.
- 기본 프로바이더에서 Latency 급증이 발생할 경우 자동으로 더 빠른 대안으로 요청이 라우팅되도록 폴백 경로를 설정합니다.
- 특정 성능 임계값을 기준으로 프로바이더를 필터링합니다.
3. 모델 계층화
더 작은 모델로 처리할 수 있는 작업에 Claude Fable 5나 GPT-5.5와 같은 플래그십 모델을 사용하지 마십시오. 단순 쿼리(예: 분류, 서식 지정)는 DeepSeek V4 Flash나 GLM-5.2로 보내고, 복잡한 추론 단계에만 비싼 모델을 예약하는 라우터를 구현하십시오.
속도 벤치마크의 한계
속도 지표를 평가할 때 개발자는 다음 한계를 염두에 두어야 합니다.
- 네트워크 변동성: API Latency는 애플리케이션 서버와 API 프로바이더의 호스팅 지역 간의 물리적 거리에 크게 의존합니다. 항상 프로덕션 배포와 동일한 지역에 있는 서버에서 벤치마크를 실행하십시오.
- 프로바이더 혼잡: Throughput과 Latency는 글로벌 트래픽 패턴에 따라 하루 종일 변동됩니다. 단일 벤치마크 실행이 일관된 프로덕션 성능을 나타내지는 않습니다.
- 토큰 추정 불일치: 모델마다 서로 다른 토크나이저를 사용합니다. TPS가 더 높은 모델이라도 토크나이저가 단어를 경쟁 모델보다 더 작고 많은 토큰으로 분할한다면 실제로는 더 빠르지 않을 수 있습니다.
자주 묻는 질문 (FAQ)
더 높은 처리량(TPS)이 항상 더 빠른 사용자 경험을 의미하나요?
아닙니다. API의 처리량은 높지만 TTFT가 좋지 않다면, 사용자는 텍스트가 화면에 갑자기 나타나기 전까지 길고 응답 없는 대기 시간을 경험하게 됩니다. 대화형 애플리케이션의 경우 높은 TPS보다 낮은 TTFT가 훨씬 중요합니다.
프롬프트 캐싱이 Latency에 어떤 영향을 미치나요?
프롬프트 캐싱은 긴 프롬프트에 대한 TTFT를 크게 줄여줍니다. 시스템 지침이나 컨텍스트 문서의 처리된 토큰을 캐싱함으로써, 프로바이더는 후속 요청 시 계산 집약적인 prefill 단계를 건너뛰어 응답 속도를 높입니다.
최고의 속도를 위해 오픈 웨이트 모델과 클로즈드 소스 모델 중 무엇을 선택해야 하나요?
호스팅 인프라에 따라 다릅니다. Qwen3.7 Plus, GLM-5.2, DeepSeek V4 Pro와 같은 오픈 웨이트 모델은 전용 개인 하드웨어에 배포할 수 있어 처리량을 보장할 수 있습니다. 그러나 관리형 클로즈드 소스 API는 개인 인스턴스에서 비용 효율적으로 복제하기 어려운 방대하고 최적화된 인프라를 사용하는 경우가 많습니다. TokenLab Model Rankings에서 현재 성능 순위를 비교할 수 있습니다.
다음 단계
애플리케이션의 속도와 비용 효율성을 최적화하려면 위에서 설명한 스트리밍 지표를 사용하여 현재 프로덕션 워크로드를 측정하는 것부터 시작하십시오.
프로덕션 파이프라인을 위한 최신 모델을 평가하고 비교할 준비가 되셨나요? TokenLab의 포괄적인 모델 순위를 통해 애플리케이션에 최적화된 Latency, Throughput, 비용의 균형을 찾아보세요.
출처
2026-07-14 기준 가격
- OpenRouter latency and performance2026-07-14 기준 확인
- OpenRouter provider routing2026-07-14 기준 확인
- TokenLab model rankings2026-07-14 기준 확인
