네 가지 서로 다른 지연 신호 측정
단일 지연 시간 수치는 사용자가 어디에서 기다리는지 숨깁니다. 스트리밍 채팅은 낮은 TTFT로 빠르게 느껴질 수 있지만 전체 완료에는 더 오래 걸릴 수 있으며, 배치 추출은 종단 간 소요 시간만 중요할 수 있습니다.
- 첫 토큰까지의 시간: 요청 시작부터 첫 스트리밍 토큰까지의 시간.
- 생성 처리량: 출력 토큰 수를 생성 시간으로 나눈 값.
- 종단 간 소요 시간: 요청 시작부터 응답 완료까지의 시간.
- 신뢰성: 전체 시도 횟수 대비 성공한 응답의 비율.
벤치마크 워크로드 제어
의도한 워크로드를 대표하는 고정 프롬프트 집합을 사용하세요. model ID, provider route, region, request parameters, input tokens, 요청된 출력 길이를 기록하세요.
- 측정 기록 전에 워밍업 요청을 실행하세요.
- 시간대 편향을 줄이기 위해 provider 순서를 무작위화하세요.
- 하나 이상의 트래픽 구간에서 테스트를 반복하세요.
- 스트리밍 결과와 비스트리밍 결과를 분리해서 유지하세요.
리더보드 스크린샷이 아닌 분포를 사용
샘플 크기와 함께 중앙값, p90, p95 값을 보고하세요. 중앙값은 가장 빠르지만 극단적 지연이 자주 발생하는 경로는, 약간 느리지만 더 안정적인 경로보다 프로덕션 경험이 나쁠 수 있습니다.
{
"sample_size": 100,
"ttft_ms": { "median": 640, "p95": 1840 },
"output_tokens_per_second": { "median": 42.1 },
"end_to_end_ms": { "median": 5120, "p95": 9080 },
"success_rate": 0.98
}위 값들은 실제 CometAPI 벤치마크 결과가 아니라 예시 보고 형식입니다.
모든 보고서에 방법론 공개
벤치마크는 무엇이 측정되었는지 독자가 이해하고 접근 방식을 재현할 수 있을 때만 유용합니다. 제한 사항을 포함하고, provider route가 고정되었는지 자동 선택되었는지 설명하세요.