vLLM·TGI 비교: 동시 처리량과 첫 토큰·완료 지연

같은 모델을 서비스할 때 동시 요청의 처리량을 우선한다면 vLLM이 유력하지만, 빠른 첫 응답을 중시한다면 TGI도 비교 대상이다. vLLM과 TGI 비교 실험에서 LLaMA-2 7B에 동시 요청 100건을 보냈을 때 초당 출력 토큰은 각각 15,243개와 4,156개였다. 반면 동시 요청 25건에서 첫 토큰 시간의 p99는 TGI가 0.71초, vLLM이 1.42초였고, 전체 응답 시간의 p99는 vLLM이 14.18초, TGI가 23.47초였다.

따라서 평균 속도나 최대 처리량만으로 서버를 고르면 사용자가 기다리는 구간을 잘못 판단할 수 있다. 대화형 서비스의 첫 토큰, 완성된 답변을 넘기는 작업의 종료 시간, 피크 시간의 완료량을 분리해야 한다. 또 Hugging Face의 TGI 문서는 TGI가 유지보수 모드이며 가벼운 버그 수정과 문서 개선 위주로 관리되고, 향후 추론 엔진으로 vLLM과 SGLang 등을 권장한다고 명시한다.

높은 동시성의 처리량 우위를 어디까지 적용할 수 있나

처리량은 여러 요청을 합쳐 단위 시간에 생성한 토큰이나 완료한 요청의 양이다. 동시에 접속하는 사용자가 늘면 배칭과 메모리 사용 방식이 이 값에 영향을 준다. 앞서 본 실험에서 동시 요청 200건의 처리량 차이는 최대 24배까지 커졌고, TGI는 높은 부하에서 먼저 포화되며 지연도 커졌다. 높은 배수를 평상시 트래픽의 성능 예상치로 사용하면 과장된다.

실험은 NVIDIA A100 80GB GPU에서 FP16 LLaMA-2 모델을 구동했고, 작은 모델은 단일 GPU, 큰 모델은 여러 GPU로 분산했다. 요청에는 길이가 다른 대화 입력과 생성 출력이 사용됐다. 모델 크기, GPU 수, 입력 길이, 출력 제한 가운데 하나만 바뀌어도 한 번에 수용할 수 있는 요청 수와 캐시 압박이 달라진다. 특히 긴 답변을 많이 생성하는 서비스의 초당 토큰 수는 짧은 답변 위주의 서비스에서 완료되는 요청 수와 같은 뜻이 아니다.

vLLM의 벤치마크 구성은 개발 중 성능 변화를 보는 시험과 TGI 등을 상대하는 비교 시험을 구분한다. 공개 성능 수치는 어느 쪽이 낸 것이든 모델과 버전, 가중치 정밀도, GPU, 요청 길이와 부하 발생 방식을 함께 놓고 읽어야 한다. 최대 처리량은 필요한 서버 용량을 추정할 때 유용하지만, 개별 요청의 체감 속도를 대신하지는 못한다.

첫 토큰과 전체 응답의 p95·p99가 다른 이유

첫 토큰 시간인 TTFT는 요청을 보낸 뒤 스트리밍 출력이 처음 도착할 때까지의 대기다. 전체 응답 시간은 마지막 출력까지 걸린 시간이고, 출력 토큰당 시간인 TPOT는 첫 토큰 이후 생성 속도를 보여준다. 첫 토큰을 빨리 보내더라도 뒤따르는 토큰이 천천히 도착하면 완성된 답변은 늦어진다. 따라서 지연을 하나의 숫자로 압축하면 어느 구간이 병목인지 가려진다.

앞의 실험에서는 동시 요청 25건에서 TGI의 첫 토큰 p95·p99가 낮았고, vLLM의 전체 응답 p95·p99가 낮았다. 대화창에서 답변이 시작됐다는 신호가 중요한 제품과 생성 결과 전체를 다음 단계에 넘기는 작업은 대기 시간을 느끼는 지점이 다르다. 같은 서버라도 사용자에게 보이는 첫 출력과 백엔드가 받는 완료 신호를 따로 기록해야 하는 이유다.

p95는 느린 축에 속한 요청을, p99는 더 드문 꼬리 요청을 드러낸다. 평균이 좋아져도 일부 요청이 배치 대기나 긴 생성 작업 때문에 밀릴 수 있다. 다만 표본이 작거나 긴 프롬프트가 특정 구간에만 몰리면 백분위수 비교도 흔들린다. 입력과 출력의 길이 분포를 보존해야 처리 엔진의 효과와 작업량 차이를 구분할 수 있다.

같은 부하를 주지 않으면 순위가 바뀐다

서버 비교에는 동일한 모델 가중치, 정밀도, GPU 수, 최대 출력 길이와 샘플링 설정이 필요하다. 한쪽에만 짧은 출력 제한을 걸면 초당 완료 요청은 늘고 전체 응답 시간은 줄어든다. 스트리밍 방식도 맞춰야 첫 토큰 시점을 같은 기준에서 잡을 수 있다. 결과를 소비하는 API 경로가 다르면 직렬화나 네트워크 비용까지 섞일 수 있다.

vLLM의 서빙 벤치마크 안내는 요청률과 최대 동시 요청을 별도로 조절하고, TTFT·토큰 간격·출력 토큰당 시간의 측정점을 설명한다. 요청을 가능한 한 빨리 보내는 시험은 포화 처리량을 찾는 데 맞고, 일정한 도착률로 보내는 시험은 실제 서비스의 대기 시간을 살피는 데 맞다. 도구마다 지표 이름이 같아도 시작점과 종료점이 다를 수 있으므로 계산 방식까지 맞춰야 한다.

낮은 동시성에서 시작해 정상 부하와 피크 부하로 높이면 처리량이 증가하다 멈추는 구간을 볼 수 있다. 그 지점부터 꼬리 지연만 가파르게 늘어난다면 최대 처리량 수치가 곧 운영 가능한 용량은 아니다. 완료한 요청과 실패한 요청을 함께 세어야 한다. 실패를 제외한 빠른 응답만 집계하면 과부하 구간의 성능이 실제보다 좋아 보인다.

캐시와 대기열도 비교 결과를 바꾼다

반복 프롬프트는 접두어 캐시를 재사용할 수 있어 새 입력만 들어오는 서비스보다 처리량이 높게 나올 수 있다. 반대로 실제 서비스에서 같은 시스템 프롬프트를 자주 공유한다면 캐시 적중은 정상적인 이점이다. 중요한 것은 두 서버에 같은 프롬프트 재사용 비율을 적용하고, 캐시를 비운 첫 실행과 캐시가 찬 반복 실행을 구별하는 일이다. 어느 쪽 결과를 제품의 예상 부하에 대응시킬지도 이 차이에 따라 달라진다.

부하 발생기에서 동시 요청 수를 제한하면 요청은 서버에 도달하기 전에도 기다릴 수 있다. 이 시간을 서버 내부의 대기와 섞으면 엔진이 느린지, 클라이언트가 속도를 막았는지 알 수 없다. 실제 이용자가 경험하는 시간에는 게이트웨이와 네트워크도 들어가므로, 서버 성능 시험과 사용자 경험 측정은 서로 다른 경계를 명시해야 한다. 두 지표를 섞어 하나의 p99로 제시하면 배포 결정에 필요한 원인이 사라진다.

GPU 메모리 사용량 역시 처리량과 함께 읽을 필요가 있다. 요청마다 보관하는 키·값 캐시가 커지면 새 요청을 배치에 넣을 여유가 줄어들 수 있다. 추론의 메모리 병목이 중요한 긴 입력 서비스라면 모델 가중치의 크기뿐 아니라 동시 실행 중인 요청의 캐시 수요를 봐야 한다. 이 차이는 같은 GPU에서도 안정적으로 수용할 수 있는 동시 요청 규모에 영향을 준다.

기능 지원과 유지보수는 성능표 밖의 조건이다

TGI는 토큰 스트리밍, 연속 배칭, Paged Attention, 텐서 병렬화, 양자화와 구조화된 출력 기능을 제공한다. 당시 실험의 메모리 설명은 TGI를 연속 할당 방식으로 다루지만, 현재 TGI 기능 목록에는 Paged Attention이 포함된다. 따라서 공개 실험의 성능 격차를 이 기능의 유무만으로 설명할 수 없다. 특정 모델과 양자화 형식의 조합이 필요한 팀이라면 기능 목록보다 실제 배포 경로에서 그 조합이 동작하는지가 중요하다.

유지보수 모드는 TGI가 갑자기 실행 불가능해졌다는 뜻이 아니다. 이미 안정적으로 쓰는 환경에서는 변경의 편익과 이전 비용을 따져볼 수 있다. 그러나 새 모델 아키텍처나 새로운 추론 기능에 계속 대응해야 하는 플랫폼이라면 공식 개발 범위가 좁아진 상태가 장기 비용으로 이어질 수 있다. 장애 수정, 버전 업그레이드, 모델 지원을 내부에서 얼마나 맡을 수 있는지가 선택의 일부가 된다.

배포 단계에 따라 달라지는 선택

시범 배포에서는 대상 모델이 필요한 API와 출력 형식으로 응답하는지가 우선이다. 대화형 제품은 낮은 동시성의 TTFT와 전체 응답 시간을 함께 봐야 한다. 첫 토큰이 빠른 서버를 골라도 긴 응답이 느리게 끝나면 사용자가 기다리는 시간은 줄지 않는다. 반대로 완료량이 핵심인 일괄 생성 작업에는 첫 토큰보다 단위 시간에 끝나는 작업량이 직접적인 기준이 된다.

트래픽이 늘어나는 단계에는 목표 처리량을 달성하는 지점의 p95·p99를 비교해야 한다. vLLM의 높은 부하 처리량 우위는 중요한 단서지만, 실제 요청 길이와 GPU 구성에서 같은 차이가 난다는 보장은 없다. TGI의 첫 토큰 우위도 공개 실험의 부하 조건을 벗어나면 다시 측정해야 한다. 처리량과 지연 목표를 동시에 충족하는지 보고 필요한 복제본 수와 GPU 비용을 계산하는 편이 맞다.

기존 TGI 서비스의 이전 여부는 현재 장애율과 지연, 모델 교체 계획, 운영 인력의 부담까지 포함한 결정이다. 신규 구축이라면 유지보수 상태 때문에 vLLM을 먼저 검토할 이유가 크지만, 응답 시작 속도가 결정적인 제품에서는 TGI를 동일 조건에서 비교할 가치가 남는다. 선택을 가르는 값은 한 번의 최고 기록보다 실제 동시성 분포에서 지킬 수 있는 완료량과 꼬리 지연이다.

함께 읽기: