같은 오픈모델도 백엔드 따라 첫 응답이 8배 느려질 수 있다
모델을 에이전트에 붙여 여러 백엔드에서 벤치마크한 결과, 같은 모델·같은 인데도 백엔드에 따라 성능 차이가 컸다. 캐시를 매번 새로 만드는 최악의 조건()에서 400토큰 출력 기준, 전용 추론 호스트는 첫 토큰까지 걸리는 시간(TTFT)이 1.2초, 초당 약 77토큰을 뽑아내며 167개의 SSE(서버가 데이터를 조금씩 순차 전송하는 방식) 청크로 매끄럽게 스트리밍했다. 반면 대형 클라우드 업체의 매니지드 는 TTFT가 10초나 걸렸고 초당 약 38토큰에 그쳤으며, 실제로는 스트리밍을 하지 않았다 — API 요청에는 stream:true가 붙어 있었지만 서버가 응답 전체를 다 만들 때까지 약 10초간 아무것도 보내지 않다가 한 번에 몽땅 쏟아냈다.
입장에서는 매 턴마다 10초씩 그냥 멈춰버리는 셈이다. 지역 거리(서버와의 물리적 거리) 문제인가 싶어 더 가까운 리전으로 옮겨봤지만 18% 빨라졌을 뿐 여전히 버퍼링(서버가 응답을 모아뒀다가 한�is번에 보내는 것)됐고, 자신의 프록시 문제도 아니었다(전용 호스트는 같은 경로로도 정상 스트리밍). 결국 원인은 그 클라우드 제공자 자체였다.
다만 중요한 반전이 있는데, 테스트는 최악의 시나리오였고 실제 에이전트 트래픽은 와 툴 정의가 매 턴 거의 그대로라 캐시가 많이 걸린다. 캐시가 데워진(warm) 상태로 다시 테스트하니 문제였던 의 TTFT가 10초에서 2.7초로 줄었고 버퍼링도 대부분 사라졌다 — 즉 앞서 본 최악의 수치는 실제 프로덕션에서는 잘 나오지 않는 콜드 캐시 특유의 현상이었다.
핵심 포인트
- 같은 모델·같은 API 스펙이어도 백엔드에 따라 TTFT가 최대 8배(1.2초 vs 10초) 차이 날 수 있다
- 일부 '매니지드' 는 stream:true를 받아도 실제로는 응답을 다 만든 뒤 한 번에 전송한다(가짜 스트리밍)
- 지역 거리 문제로 착각하기 쉽지만 실제 원인은 서버 측 버퍼링일 수 있다
- 캐시가 워밍된 실제 에이전트 트래픽에서는 TTFT 격차가 10초→2.7초로 크게 줄어든다
- 여러 백엔드를 쓰는 에이전트라면 콜드/웜 캐시 양쪽 조건으로 직접 벤치마크해야 한다