호스팅된 AI API를 기반으로 무엇인가를 구축한다면, 지연 시간(Latency)은 무시할 수 있는 세부 사항이 아니라 하나의 기능입니다. 느린 첫 번째 토큰 생성 시간(Time-to-first-token)은 살아있는 것처럼 느껴지는 어시스턴트와 고장 난 것처럼 느껴지는 어시스턴트 사이의 차이를 만듭니다.

하지만 제가 내 사용자들이 실제로 있는 곳에서 제공업체 X는 얼마나 빠른가? 라는 단순한 질문에 대한 정직한 답을 찾으려 했을 때, 어디에서도 찾을 수 없었습니다. 사람들이 인용하는 수치들은 대개 단일 지역(보통 미국 어딘가)의 단일 머신에서 나온 것이거나, 벤더가 보고하는 상태 페이지(status pages)에서 가져온 것이거나, 한 번 실행된 후 업데이트되지 않은 벤치마크 결과인 경우가 많았습니다. 독립적이고, 측정된, 지역별 관점의 데이터가 없었습니다.

그래서 제가 직접 만들었습니다: LLM Latency Tracker, AI 추론(Inference) API의 지연 시간(Latency)과 가동 시간(Uptime)을 추적하는 제공업체 중립적인 트래커입니다.

작동 방식

핵심 아이디어는 의도적으로 지루합니다: 스크래핑하지 말고, 실제로 측정하십시오.

작은 Python 프로버(Prober) — 표준 라이브러리만 사용하며, 에지 프로브(edge probes)에는 API 키가 필요하지 않음 — 가 각 제공업체의 엔드포인트(Endpoint)에 실제 연결을 열고 핸드셰이크(Handshake)의 모든 단계인 **DNS resolution → TCP connect → TLS negotiation → 첫 번째 바이트 도달 시간(Time-to-first-byte, TTFB)**을 측정합니다. 이것이 바로 에지(edge) 관점입니다. 즉, 단 1바이트가 돌아오기 전까지 네트워크 경로 자체에 걸리는 시간입니다.

이와 별개로, 가능한 경우 추론의 **첫 번째 토큰 생성 시간(Time-to-first-token, TTFT)**을 측정합니다. 이는 사용자가 실제로 체감하는 부분, 즉

현재 약 45개의 제공업체(Provider)를 포함하고 있습니다. 일반적인 서구권 연구소(OpenAI, Anthropic, Google, Mistral, Groq, Together, Fireworks, Cerebras, OpenRouter, Perplexity, xAI, DeepSeek…)뿐만 아니라, 서구권 벤치마크에는 거의 등장하지 않는 중국 업체들(GLM/Zhipu, Kimi/Moonshot, Qwen, MiniMax)도 포함됩니다. 이 모든 것은 CC-BY-4.0 라이선스 하에 무료로 공개되어 있으며, JSON API와 OpenAPI 사양(Spec)을 제공합니다.

흥미로운 점: 에이전트 네이티브(Agent-native)로 구축하기

이 프로젝트가 단순한 대시보드 그 이상인 이유는 다음과 같습니다. 저는 이것을 단순히 사람이 읽기 위한 것이 아니라, **기계(Machines)**가 읽을 수 있도록 구축했습니다.

사람들이 질문하는 방식이 검색창에서 답변 엔진(Answer engines)과 에이전트(Agents)로 변화하고 있습니다. 만약 당신의 데이터가 JavaScript로 감싸진 HTML 형태로만 존재한다면, 에이전트는 이를 신뢰성 있게 소비하거나 인용할 수 없습니다. 이는 당신의 측정 데이터가 _"지금 유럽에서 TTFT가 가장 낮은 제공업체는 어디인가요?"_라고 실제로 묻는 사람에게 결코 도달하지 못함을 의미합니다.

따라서 이 사이트는 여러 에이전트 방언(Dialects)을 지원합니다:

• /mcp 경로에 위치한 **실제 MCP 서버 (Streamable HTTP)**를 통해 get_ai_api_latency 도구를 노출합니다. 에이전트는 이를 직접 호출하여 구조화된 지연 시간(Latency) 데이터를 받아올 수 있습니다. 스크래핑(Scraping)이나 추측이 필요 없습니다.
• /.well-known/mcp/server-card.json에 위치한 **MCP 서버 카드(MCP Server Card)**와 WebMCP를 통해 에이전트가 해당 도구를 발견할 수 있도록 합니다.
• **llms.txt 및 llms-full.txt**를 제공하여 모델에게 사이트의 깔끔한 지도를 제공합니다.
• 마크다운 콘텐츠 협상(Markdown content negotiation): 페이지에 text/markdown을 요청하면 역공학(Reverse-engineer)이 필요한 DOM 대신 깔끔한 마크다운을 받을 수 있습니다.

이러한 방식의 좋은 부수 효과는 에이전트를 위해 구축하다 보면 자연스럽게 모두를 위해 깔끔한 구조를 만들게 된다는 점입니다. 페이지를 LLM이 읽기 쉽게 만드는 규율(구조화되고, 빠르며, 불필요한 요소가 없는 것)은 Lighthouse 100점과 Cloudflare의 "당신의 사이트는 에이전트 준비가 되었습니까?" 체크리스트에서 "Agent-Native" (Level 5) 등급을 받는 결과로 이어졌습니다. 이것이 그 자체로 엄청난 의미가 있다고 주장하지는 않겠습니다. 이것은 트로피가 아니라 체크리스트일 뿐이니까요. 하지만 "이 데이터는 실제로 접근 가능하다"라는 것을 보여주는 괜찮은 대리 지표(Proxy)는 됩니다.

또한 작은 보조 도구도 있습니다. /deprecations 경로에 있는 **모델 지원 종료 및 마이그레이션 캘린더 (model deprecation & migration calendar)**입니다. 이는 공식 제공업체의 문서를 직접 확인하여 검증되었으므로, 모델이 서비스 종료(sunset)되어 앱이 작동을 멈추기 전에 미리 파악할 수 있습니다.

솔직한 한계점

자신의 가치를 과장하는 트래커는 아예 없는 것보다 못하기에, 솔직하게 말씀드립니다:

• 데이터셋이 아직 초기 단계입니다. 이 글을 쓰는 시점에서 데이터가 생성된 지 불과 며칠 되지 않았습니다. 추세는 잠정적인 것으로 간주하십시오. 단일 스냅샷을 과도하게 해석하지 마세요.
• 에지 지연 시간 (Edge latency)은 전체 왕복 시간 (round-trip)이 아닙니다. 엔드포인트에 대한 TTFB (Time to First Byte)는 네트워크 경로를 측정하는 것이지, 생성이 완료될 때까지의 시간을 측정하는 것이 아닙니다. TTFT (Time to First Token)가 실제 체감 성능에 더 가깝지만, 이 역시 전체 완료 시간은 아닙니다.
• 키가 없는 네트워크 프로브 (Keyless network probes)와 키가 있는 추론 프로브 (Keyed inference probes)는 서로 다른 것을 측정합니다. 추론 커버리지 (Inference coverage)는 에지 커버리지 (Edge coverage)보다 좁습니다.
• 4개의 지역은 샘플일 뿐, 전 세계를 대변하지 않습니다. 만약 사용자가 제가 프로브하지 않는 지역에 있다면, 여러분의 결과는 다를 것입니다.

이것은 기준점(baseline)이자 시작점일 뿐, 절대적인 진리는 아닙니다.

사용해 보세요 / 테스트해 보세요

이 프로젝트는 무료이며 오픈 소스이고, 데이터는 CC-BY-4.0 라이선스를 따릅니다. 사용하고, 차트를 만들고, 인용하고, 이를 기반으로 무언가를 구축해 보세요.

• 사이트: https://llmlatency.dev
• JSON API: https://llmlatency.dev/api/rankings.json
• MCP 엔드포인트: https://llmlatency.dev/mcp
• 코드: https://github.com/mazamaka/llm-latency-tracker

여러분이 중요하게 생각하는 제공업체나 지역이 누락되어 있다면, 이슈(issue)를 생성하거나 PR (Pull Request)을 보내주세요. 그것이 바로 이 프로젝트를 모두에게 더 유용하게 만드는 기여 방식입니다. 그리고 에이전트 (agents)를 구축하고 있다면, MCP 엔드포인트를 연결해 보고 무엇이 작동하지 않는지 알려주세요.