모든 AI 게이트웨이는 사용자 앱과 모델 사이에 추가적인 연결 지점(hop)을 만듭니다. 중요한 질문은 사용자가 빈 채팅창을 응시하고 있을 때 그 연결 지점이 어떤 비용을 초래하는가, 즉 첫 토큰까지 걸리는 시간(time to first token, TTFT)입니다. 대부분의 게이트웨이 지연 시간 논쟁은 측정 없이 아키텍처를 두고 주장만 합니다. 그래서 저희는 직접 측정했습니다.

저희는 동일한 장치에서 동일한 모델을 사용하여 open-source TTFT 벤치마크를 LLM Gateway와 OpenRouter에 대해 교차로 실행했습니다. 총 75회 실행의 중앙값(median)은 다음과 같습니다: LLM Gateway는 콜드 연결 상태에서 첫 콘텐츠 토큰을 906ms 만에, 웜 연결 상태에서는 814ms 만에 받았습니다. OpenRouter는 각각 1392ms와 1232ms가 걸렸습니다. 이는 콜드 연결 상태에서 약 35% 빠르고, 웜 연결 상태에서 약 34% 빠른 수치이며, 총 300회의 측정 실행 동안 오류가 없었습니다. 이 수치는 각 웜 측정 앞에 선행하는 폐기(throwaway) 웜업 호출을 포함하여 총 450개의 HTTP 요청에 대한 것입니다. 모든 요청은 HTTP 200으로 응답했습니다. 개별 실행의 원시 데이터는 여기에서 전체 공개할 수 있습니다.

AI 게이트웨이 성능 측정 방법

저희는 Ronny Badilla가 최근 비교 대상으로 Vercel AI Gateway, OpenRouter, Cloudflare AI Gateway를 언급하며 사용한 open-source 스크립트 ai-gateways-benchmark을 사용했습니다. 이 스크립트는 Python 표준 라이브러리만을 사용합니다(raw sockets, HTTP 라이브러리 없음). 그리고 스트리밍 요청의 모든 단계를 개별적으로 측정합니다: DNS, TCP 연결, TLS 핸드셰이크, TTFB (요청이 첫 응답 바이트로 전송되는 시간), 그리고 TTFT (요청이 SSE 스트림의 첫 콘텐츠 토큰으로 전송되는 시간).

이러한 분리가 핵심입니다. '게이트웨이 지연 시간'이라는 주장은 보통 연결 비용, 엣지 근접성(edge proximity), 실제 라우팅 오버헤드를 혼동합니다. 이 도구는 이들을 분리하여 측정합니다.

저희의 설정은 2026년 7월 22일이었습니다:

• 두 게이트웨이 모두 동일한 모델 사용: claude-haiku-4.5, 스트리밍 (streaming), max_tokens: 16, 동일한 프롬프트 (prompt)
• 게이트웨이당 75회의 콜드 (cold) + 75회의 웜 (warm) 실행, 시간대 변화 (time-of-day drift)가 양측에 동일하게 영향을 미치도록 라운드 로빈 (round-robin) 방식으로 교차 실행
• 콜드 (Cold) = 새로운 TLS 컨텍스트 (세션 재개 없음)와 함께 DNS + TCP + TLS 비용을 모두 지불하는 새로운 연결
• 웜 (Warm) = 이미 열려 있는 소켓(socket)에서의 두 번째 요청 — 실제 운영 트래픽이 주로 존재하는 커넥션 풀 (connection-pool) 케이스
• 하나의 주거용 관측 지점 사용, 450개의 모든 HTTP 요청(웜업 포함) 동안 두 게이트웨이 모두에서 오류 0건

결과: LLM Gateway vs OpenRouter

각 셀(cell)당 n=75의 중앙값 (Medians). 콜드 TTFT는 엔드 투 엔드 (end-to-end) 기준입니다: DNS + TCP + TLS + 첫 번째 콘텐츠 토큰까지의 시간 — 즉, 수명이 짧은 프로세스가 지불해야 하는 비용입니다.

분포 범위 (p10–p90 범위의 중앙값):

중앙값 외에 두 가지가 눈에 띕니다. LLM Gateway의 p90 콜드 TTFT (1380ms)는 OpenRouter의 중앙값보다 낮았습니다 — 즉, 한 분포의 느린 꼬리(tail) 부분이 다른 분포의 중간값보다 빨랐습니다. 그리고 LLM Gateway의 웜 TTFB는 거의 변하지 않습니다: p10–p90 범위 전체에서 171–193ms를 기록했으며, 이는 운영 환경의 커넥션 풀 (connection pool)에서 원하는 안정성입니다.

시간이 소요되는 구간

단계별 분석(phase breakdown) 결과, 오버헤드는 연결(connection) 단계에서 발생하지 않습니다:

OpenRouter의 우위는 실제로 핸드셰이크 (handshake) 단계에서 나타납니다 — 우리의 40ms 대비 13ms의 TLS. 하지만 요청이 전송된 이후의 모든 단계에서 손실을 봅니다.

TTFB(Time to First Byte) 열에 대한 한 가지 솔직한 주의 사항이 있습니다. 구조적인 이유로 인해 LLM Gateway에 유리하게 나타납니다. 우리의 게이트웨이는 첫 번째 업스트림(upstream) 토큰이 도착하기 전인 약 200ms 만에 응답 스트림(response stream)을 시작합니다. 반면 OpenRouter는 첫 번째 토큰이 준비될 때까지 첫 바이트를 보유하므로, 모든 실행에서 TTFB가 TTFT(Time to First Token)와 동일하게 나타납니다. TTFB는 누가 헤더를 일찍 스트리밍하는지를 알려주지만, TTFT는 사용자가 실제로 체감하는 수치이며, 이 포스트의 진정한 핵심 주제입니다.

두 번째 주의 사항은 각 게이트웨이가 이 모델에 대해 기본 라우팅(default routing)을 실행했다는 점입니다. OpenRouter는 요청마다 업스트림을 선택하지만(우리가 조사한 요청은 Amazon Bedrock을 통해 제공되었습니다), 우리의 실행은 Anthropic의 API로 고정되었습니다. 둘 다 기본 설정(out of the box) 상태이지만, 서로 다른 업스트림입니다.

Vercel AI Gateway와의 비교

우리가 직접 Vercel을 벤치마크한 것은 아닙니다. 벤치마크 작성자가 동일한 스크립트를 사용하여 자신의 관점에서 다른 날짜에 실행한 결과를 공개했습니다. 그는 Vercel AI Gateway, OpenRouter, 그리고 OpenRouter를 프록시하는 Cloudflare AI Gateway를 비교했습니다:

이 수치들은 우리의 결과와 직접적으로 비교할 수 없습니다. 위치, 네트워크, 날짜가 다르고, 샘플 크기도 n=5 대 n=75로 다릅니다. 다만 이 수치들은 검증(sanity check) 용도로 유용합니다. 그의 실행 결과와 우리의 실행 결과 모두 인터넷의 서로 다른 지점에서 측정했음에도 불구하고, OpenRouter는 첫 번째 토큰까지 1초 이상이 소요되었습니다. 그의 표와 비교했을 때, LLM Gateway의 906ms(cold) 및 814ms(warm)는 가장 좋은 행과 비슷하거나 그보다 낮게 위치합니다. 하지만 우리가 사실로서 명시할 유일한 비교는 한 대의 머신에서 교차 실행하며 직접 측정한 결과뿐입니다.

위치 의존성은 양날의 검이며, 벤치마크의 README에도 명시되어 있습니다. 결과는 전 세계적인 순위가 아니라 측정하는 위치의 특성입니다. 이것이 바로 직접 실행해 보는 것이 올바른 방법인 이유입니다.

직접 벤치마크 실행하기

전체 과정은 설정 파일 하나와 두 개의 API 키로 구성됩니다:

git clone https://github.com/rbadillap/ai-gateways-benchmark
cd ai-gateways-benchmark

{
  "runs_cold": 75,
  "runs_warm": 75,
...

LLM_GATEWAY_API_KEY=... OPENROUTER_API_KEY=... python3 bench.py config.json

실행되는 동안 각 실행(run)에 대한 라인을 출력하며, 그 후 중앙값(median) 테이블을 보여주고, 요청 ID 영수증이 포함된 원시 실행별 JSON 데이터를 덤프합니다. 만약 귀하의 지역에서 실행했을 때 다른 수치(우리가 패배하는 경우를 포함하여)가 나온다면, 저희는 그 수치를 확인하고 싶습니다.

지연 시간(Latency)은 모든 요청에 대해 지불하는 세금입니다

게이트웨이는 장애 조치(failover), 통합 결제(unified billing), 그리고 라우팅하는 모든 모델에 대해 하나의 API를 제공함으로써 그 단계(hop)를 정당화합니다. 하지만 귀하는 모든 단일 요청에 대해 영구적으로 그 지연 시간(latency)을 지불해야 합니다. 이로 인해 첫 번째 토큰 생성 시간(time to first token, TTFT)은 도입을 결정하기 전에 측정할 가치가 있는 몇 안 되는 게이트웨이 속성 중 하나가 되며, 도구가 오픈 소스이고 실행에 몇 분밖에 걸리지 않기 때문에 가장 쉬운 측정 항목 중 하나이기도 합니다.

현재 OpenRouter를 사용 중이라면, LLM Gateway는 동일한 OpenAI 호환 API를 사용합니다. 전환하려면 기본 URL(base URL)을 변경하고 LLM Gateway API 키로 교체하기만 하면 되며, 이에 대한 내용은 OpenRouter 마이그레이션 가이드에서 확인할 수 있습니다.

자주 묻는 질문 (Frequently Asked Questions)

TTFT란 무엇이며 왜 TTFB보다 더 중요한가요?

TTFT (time to first token)는 요청을 보낸 시점과 스트림에서 모델 출력의 첫 번째 조각을 받는 시점 사이의 지연 시간입니다. TTFB (time to first byte)는 서버가 응답을 시작하는 시점만을 측정합니다. 게이트웨이는 모델이 아직 침묵하고 있는 동안에도 즉시 헤더를 스트리밍할 수 있습니다. 사용자가 실시간으로 지켜보는 모든 작업에 있어, TTFT는 사용자가 실제로 경험하는 지연 시간입니다.

AI 게이트웨이의 좋은 TTFT 기준은 무엇인가요?

이는 모델과 게이트웨이 엣지(edge)로부터의 거리에 따라 다르므로, 절대적인 기준보다는 게이트웨이들을 서로 비교하십시오. 이 AI 게이트웨이 성능 벤치마크에서, 동일한 세션의 동일한 머신에서 측정한 결과 claude-haiku-4.5의 첫 번째 토큰은 LLM Gateway를 통해 약 800900ms, OpenRouter를 통해 12001400ms 내에 도착했습니다.

이 결과가 모든 위치에서 유효한가요?

아니요 — 지연 시간 (Latency) 벤치마크는 관측 지점 (Vantage point)의 특성을 따르며, 벤치마크 자체의 README에도 이 점이 명시되어 있습니다. 저희의 수치는 하루 동안 하나의 주거용 연결 (Residential connection)에서 얻은 것이며, 저자의 Vercel 수치는 다른 환경에서 얻은 것입니다. 스크립트는 오픈 소스이며 실행하는 데 몇 분밖에 걸리지 않으므로, 귀하의 서버가 실제로 위치한 곳에서 직접 측정해 보시기 바랍니다.

LLM Gateway는 OpenRouter와 동일한 모델을 지원하나요?

LLM Gateway는 중첩되는 카탈로그를 라우팅합니다 — 전체 목록은 models page에서 확인할 수 있으며, providers page에 있는 주요 폐쇄형 (Closed) 및 오픈 웨이트 (Open-weight) 제공업체들을 아우릅니다. 두 방식 모두 OpenAI 호환 (OpenAI-compatible) 형식을 사용하므로, 워크로드를 두 서비스 간에 이동하는 것은 베이스 URL (Base URL)과 키 (Key)를 변경하는 것만으로 충분합니다.

직접 측정해 보세요:

• LLM Gateway 무료 체험하기 — 하나의 키로 첫날부터 스트리밍 (Streaming) 가능
• OpenRouter에서 마이그레이션하기 — 베이스 URL과 API 키 변경만으로 가능
• LLM 게이트웨이란 무엇인가? — 홉 (Hop)을 거치는 것이 이득이 되는 경우