오늘 우리는 AI 게이트웨이 오버헤드 (overhead)를 위한 벤치마크를 오픈 소스로 공개했습니다. 이 벤치마크는 코딩 에이전트 (coding agent)의 관점에서 측정된, 게이트웨이가 업스트림 LLM (upstream LLM) 위에 추가하는 지연 시간 (latency), 메모리 (memory) 및 비용 (cost)을 테스트합니다.

github.com/BerriAI/ai-gateway-bench

이것이 존재하는 이유

모든 AI 게이트웨이는 빠르다고 주장합니다. 어떤 곳은 "54배 더 빠르다"고 주장하기도 합니다. 하지만 아무도 그 근거를 보여주지 않습니다.

대부분의 게이트웨이 벤치마크는 형편없습니다. 이들은 라이브 LLM 엔드포인트 (live LLM endpoints)를 대상으로 테스트하기 때문에, 게이트웨이가 아닌 네트워크 지터 (network jitter)와 제공업체의 부하를 측정하게 됩니다. 또한 수평 확장 (horizontal scaling)이 없는 아주 작은 인스턴스에서 실행됩니다. 하나의 지표만 골라내고(cherry-pick) 나머지는 숨깁니다.

우리는 누구나 실행하고 검증할 수 있는 무언가를 원했습니다. 그래서 직접 만들었습니다.

작동 방식

모든 게이트웨이는 동일한 로컬 결정론적 Rust 모크 (deterministic Rust mock)를 가리킵니다. 네트워크도 없고, 제공업체의 변동성도 없습니다. 남은 것은 순수한 게이트웨이 오버헤드뿐입니다:

오버헤드 (overhead) = 지연 시간 (latency)(클라이언트 -> 게이트웨이 -> 모크) - 지연 시간 (latency)(클라이언트 -> 모크 직접)

테스트 대상 게이트웨이: LiteLLM (Rust), LiteLLM (Python v1), Portkey, Bifrost.

네, 저희 자신의 Python 게이트웨이도 포함했으며, 그것이 가장 느립니다. 그것이 핵심입니다. 만약 우리가 최악의 수치를 숨겼다면, 왜 좋은 수치들을 신뢰하겠습니까?

측정 항목

이것들은 챗봇 지표가 아닙니다. 코딩 에이전트 (Claude Code, Codex)는 긴밀한 루프를 실행합니다: 계획 스트리밍 (stream a plan), 도구 호출 (tool calls) 방출, 편집 적용, 반복. 세션당 수천 번의 턴 (turns)이 발생합니다. 몇 밀리초 (ms)의 게이트웨이 오버헤드가 누적되면 실제 체감되는 지연 (wall-clock lag)으로 이어집니다.

결과

p99 추가 지연 시간 (added latency) (엔드포인트당 n=5000, 단일 호스트):

• LiteLLM Rust: 0.7 ms
• Portkey: 2.3 ms
• Bifrost: 4.5 ms
• LiteLLM Python v1: 257.7 ms

피크 메모리 (Peak memory):

• LiteLLM Rust: 21.8 MB
• Portkey: 90.4 MB
• Bifrost: 199.1 MB
• LiteLLM Python v1: 329.5 MB

100만 건의 요청당 예상 비용 (Estimated cost per 1M requests):

• LiteLLM Rust: $0.000175
• Bifrost: $0.001008
• Portkey: $0.001042
• LiteLLM Python v1: $0.015354

시간당 USD당 RPS (RPS per USD/hour):

• LiteLLM Rust: 283,833
• Bifrost: 63,246
• Portkey: 17,964
• LiteLLM Python v1: 4,296

30회 턴 코딩 세션 오버헤드 (30-turn coding session overhead) (Claude Code + Codex 제어 루프 기준):

• LiteLLM Rust는 전체 세션에 약 40ms를 추가합니다.
• Bifrost는 약 150ms를 추가합니다.
• LiteLLM Python v1은 약 950ms를 추가합니다.

해자 지표 (The moat metric)

대부분의 벤치마크는 평균값을 보고합니다. 에이전트(Agents)에게 실제로 중요한 수치는 **동시성 (Concurrency)이 증가함에 따라 일정하게 유지되는 p99 청크 간 지연 시간 (p99 inter-chunk latency)**이며, 이는 1:1 청크 충실도 (Chunk fidelity)와 결합되어야 합니다.

이는 구조적으로 속이기 어렵습니다. 출력 버퍼링 (Output buffering)이 없어야 하며, 스트림 경로 (Stream path) 상에서 요청당 재직렬화 (Re-serialization)가 발생하지 않아야 하고, 부하 상황에서도 런타임 일시 중단 (Runtime pauses)이 없어야 합니다. 가비지 컬렉션 (Garbage-collected) 런타임은 부하 상황에서 평균값으로는 숨겨질 수 있는 주기적인 지터 스파이크 (Jitter spikes)를 보여줄 것입니다.

직접 실행해 보세요

git clone https://github.com/BerriAI/ai-gateway-bench
cd ai-gateway-bench
python -m venv .venv && . .venv/bin/activate && pip install -r requirements.txt
...

모든 원시 데이터 (Raw data)는 results/ 디렉토리에 CSV 파일로 커밋되어 있습니다. 차트는 하드코딩된 것이 아니라 데이터를 기반으로 생성됩니다. 여러분의 게이트웨이를 추가하고 동일한 시나리오를 실행해 보세요.

이를 구축하며 배운 점

게이트웨이 오버헤드는 모델 지연 시간 (Model latency)에 비하면 노이즈에 불과합니다. 우리의 Python 게이트웨이조차 p99에서 258ms를 추가하지만, 실제 모델 호출은 500ms에서 30s 사이입니다. Rust 게이트웨이는 0.7ms를 추가합니다.

하지만 세션당 30회 이상의 턴을 실행하는 코딩 에이전트의 경우, 그 노이즈가 복리로 쌓입니다. 그리고 64개의 에이전트가 동시에 실행될 때는 평균보다 꼬리 지연 시간 (Tail latency)이 더 중요해집니다.

또한 이번 벤치마크를 통해 Portkey의 오픈 소스 (OSS) 게이트웨이가 현재 Anthropic Messages 요청을 스트리밍할 때 HTTP 500 오류를 반환한다는 사실이 드러났습니다. 이는 성능 문제가 아니라 기능적 격차 (Functionality gap)입니다. 저희는 차트에 이를 정직하게 표시했습니다.

포크(Fork)하고, 여러분의 게이트웨이를 추가한 뒤, PR을 보내주세요. 동일한 조건에서 더 많은 게이트웨이가 테스트될수록 모두에게 더 좋습니다.

github.com/BerriAI/ai-gateway-bench