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

한 줄 요약

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

왜 이게 필요했나

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

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

어떻게 동작하나

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

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

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

현장에서 만나는 모습

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

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

다음 확인에서 볼 것

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