도구 이름보다 먼저 측정 계약을 고정한다

한 줄 요약

모델 서버에는 보편적인 승자가 없다. 같은 모델·하드웨어·워크로드로 측정하고, 필요한 기능과 운영 비용을 함께 비교해야 한다.

왜 이게 필요했나

"어떤 서버를 써야 하나요"라는 질문에 벤치마크 표 하나로 답할 수 없습니다. 같은 도구가 워크로드에 따라 최선이 되기도 하고 부적합해지기도 하기 때문입니다.

기준을 먼저 정해야 합니다. 대화형인가 배치인가, 입력·출력 길이 분포는 어떤가, 프롬프트에 공통 접두어가 많은가, 동시성 피크가 얼마인가, 구조화된 출력이나 특정 양자화를 지원해야 하는가, 엔진 빌드와 버전 업그레이드 비용을 감수할 수 있는가를 적습니다.

어떻게 동작하나

비교를 재현하려면 먼저 측정 계약을 고정합니다.

모델 이름뿐 아니라 정확한 리비전, 토크나이저, dtype·양자화 방식과 서버 버전을 기록합니다.
GPU 모델·수량, 드라이버와 런타임 버전, 메모리 한도와 컨테이너 이미지를 같게 둡니다.
실제 트래픽에서 입력·출력 토큰 길이, 공통 접두어 비율, 동시성과 도착 간격을 추출해 재생합니다.
워밍업 뒤 여러 번 반복해 TTFT·ITL·종단 간 지연의 p50/p95/p99, 처리 토큰 수, 오류율, GPU 메모리와 선점률을 함께 기록합니다.
같은 품질 설정인지 확인합니다. 한 후보만 더 공격적인 양자화나 짧은 최대 출력을 쓰면 속도 비교가 아닙니다.

그다음 기능과 운영 제약을 봅니다. vLLM 의 블록 기반 KV 캐시 관리, SGLang 의 접두어 재사용 기능, TensorRT-LLM 의 사전 빌드 엔진, TGI 의 지원 모델·배포 통합, Ollama 의 로컬 실행 편의는 각각 후보를 좁히는 단서일 뿐 성능 순위를 보장하지 않습니다. 기능 이름이 같아도 릴리스, 모델과 요청 분포에 따라 이득이 달라지므로 실제 사용할 조합의 문서와 측정 결과로 결정합니다.

현장에서 만나는 모습

선택보다 중요한 것은 결과를 다시 만들 수 있는 것입니다. 벤치마크 보고서에는 실행 명령, 이미지와 모델 리비전, 워크로드 데이터 생성 방법, 동시성, 워밍업·반복 횟수와 원시 결과를 남깁니다. 평균 처리량만 좋아도 p99 TTFT 나 오류율이 제품 SLO 를 넘으면 채택할 수 없습니다.

그리고 서버 선택보다 앞에 오는 결정이 있습니다. 모델 크기와 양자화입니다. 7B fp16 가중치가 안 들어가는 GPU 에서 서버만 바꾸는 것은 의미가 없습니다. AWQ 나 GPTQ 로 가중치를 4비트로 양자화하면 가중치 메모리는 fp16 대비 이론상 약 4분의 1이지만, KV 캐시·런타임 작업 공간·양자화 메타데이터까지 포함한 전체 GPU 메모리가 4분의 1이 되는 것은 아닙니다. 실제 절감 폭과 품질 손실은 지원되는 모델·서버 조합으로 측정해야 합니다.

서버가 실제로 하는 일

vLLM·TGI·TensorRT-LLM 의 이름은 달라도 성능을 만드는 장치는 대체로 같습니다. 그것을 알면 설정 이름이 달라도 무엇을 조절하는지 압니다.

연속 배치(continuous batching). 요청이 끝날 때까지 기다리지 않고, 매 스텝마다 끝난 것을 빼고 새것을 넣습니다. 정적 배치보다 처리량이 몇 배 오릅니다. 이것이 켜져 있는지가 첫 확인 사항입니다.

PagedAttention. KV 캐시를 페이지 단위로 관리해 조각화를 없앱니다. 예전에는 최대 길이만큼 미리 잡아 실제 사용의 두세 배를 낭비했습니다.

프리픽스 캐시. 시스템 프롬프트처럼 앞부분이 같은 요청의 KV 를 재사용합니다. 정확도에 영향이 없으면서 TTFT 를 줄이므로 가장 먼저 켤 것 입니다.

양자화. 가중치를 4~8비트로 줄여 메모리와 대역폭을 아낍니다. 품질 손실이 있으므로 평가셋으로 확인하고 켭니다.

메모리를 어떻게 나누는가

GPU 메모리는 세 몫으로 갈립니다.

전체 24GB
 ├ 가중치         16.2GB   ← 모델 크기 × 비트수/8
 ├ KV 캐시         6.5GB   ← 나머지의 대부분. 동시 요청 수를 정한다
 └ 활성화·여유     1.3GB

gpu_memory_utilization 을 올리면 KV 캐시가 커져 동시 처리량이 늘지만, 너무 올리면 활성화 여유가 부족해 OOM 이 납니다. 0.90~0.93 이 실용 범위 입니다.

KV 캐시 크기는 동시 요청 수와 문맥 길이의 곱에 비례합니다.

KV 바이트 ≈ 2 × 레이어 × 헤드 × 헤드차원 × 문맥길이 × 배치 × 정밀도바이트

그래서 문맥을 16K 에서 32K 로 늘리면 동시 처리 가능한 요청 수가 절반 이 됩니다. "문맥을 길게 열어 두자" 는 공짜가 아닙니다.

무엇을 어떻게 재는가

도구를 고르기 전에 재는 방법을 고정합니다. 그러지 않으면 비교가 성립하지 않습니다.

값	정의	함정
TTFT	요청 → 첫 토큰	프리픽스 캐시가 켜지면 극적으로 좋아진다
TPOT	토큰 사이 평균 간격	배치가 크면 나빠진다
처리량	초당 출력 토큰(전체)	동시 요청 수를 함께 적어야 의미가 있다
p95 지연	상위 5%	평균만 보면 놓친다

세 번째가 중요합니다. "138 tok/s" 는 동시 4요청 합산인지 단일 요청인지에 따라 완전히 다른 숫자입니다. 벤치마크를 적을 때는 동시성·입력 길이·출력 길이를 함께 적습니다. 이 셋이 없으면 재현할 수 없습니다.

다음 확인에서 볼 것

퀴즈에서 워크로드 조건에 맞는 서버 선택 기준을 확인한 뒤, 다음 모듈에서 그 판단의 근거가 되는 GPU 메모리 산정을 계산기로 직접 만듭니다.