서빙 용량 산정 — 어떤 모델을, 어떤 GPU로, 몇 명에게

왜 용량 산정이 어려운가 — 변수가 다섯 개다

「H100 한 장으로 몇 명을 서비스할 수 있나요?」라는 질문에는 답할 수 없다. 질문에 빠진 것이 너무 많기 때문이다. 실제로 답을 결정하는 변수는 다섯 개이고, 그중 하나만 바뀌어도 결과가 열 배씩 달라진다.

이 장에 나오는 숫자는 계산 구조를 보이기 위한 대표값이다. 모델 구성(레이어 수, KV 헤드 수)과 GPU 사양은 버전마다 다르므로, 실제 산정에서는 반드시 해당 모델의 config.json 과 GPU 공식 사양표에서 확인해 넣어야 한다.

① 메모리 예산 — 무엇이 HBM을 차지하는가

가중치 — 계산이 가장 단순한 부분

가중치 크기 (GB) = 파라미터 수(B) × 정밀도 바이트

  FP16 / BF16 → 2 바이트
  FP8         → 1 바이트
  FP4 (NVFP4) → 0.5 바이트  (+ 블록 스케일 오버헤드 약 3~6%)

예)  70B 모델을 FP8 로 서빙  →  70 × 1 = 70 GB

KV 캐시 — 사용자 수에 비례하는 부분

KV 캐시는 「이미 읽은 토큰들의 Key·Value를 저장해 두는 것」이다. 토큰 하나가 늘어날 때마다 정해진 크기만큼 커지고, 요청이 하나 늘어날 때마다 그만큼 또 늘어난다.

요청 1건 · 토큰 1개당 KV 바이트
  = 2 × 레이어 수 × KV 헤드 수 × 헤드 차원 × 정밀도 바이트
    ↑ Key 와 Value 두 벌

요청 1건의 총 KV
  = 위 값 × (입력 토큰 + 생성된 출력 토큰)

동시 요청 N건의 총 KV
  = 위 값 × N

여기서 KV 헤드 수가 핵심이다. 최근 모델은 대부분 GQA(Grouped Query Attention)를 써서 쿼리 헤드는 많지만 KV 헤드는 적게 둔다. KV 헤드가 8개면 64개일 때보다 캐시가 8분의 1이다. 모델 선택이 곧 서빙 용량 선택이라는 말이 여기서 나온다.

KV 캐시를 FP8로 양자화하면 위 표의 값이 절반이 된다. 정확도 손실이 가중치 양자화보다 작다고 알려져 있어 실무에서 자주 쓰인다. 10장의 오프로딩과 함께, 「KV를 어떻게 다룰 것인가」가 서빙 용량의 핵심 손잡이다.

② 모델 지형 — 오픈 웨이트와 상용 API

서빙할 모델을 고르는 것은 성능만의 문제가 아니다. 어떤 모델을 고르느냐가 필요한 하드웨어를 결정하고, 그것이 곧 예산이다.

오픈 웨이트 모델 — 계산이 가능한 쪽

가중치가 공개된 모델은 파라미터 수, 레이어 수, KV 헤드 수를 모두 알 수 있으므로 위의 계산을 그대로 적용할 수 있다. 산정의 출발점으로 삼기 좋다.

상용 API 모델 — 파라미터를 모를 때

상용 API 모델은 파라미터 수도 구조도 공개되지 않는다. 그렇다면 용량 산정을 할 수 없는가? 다른 방식으로 한다.

③ GPU 시스템 지형 — 무엇이 얼마를 감당하는가

2장에서 「용량 · 대역폭 · SRAM」의 트레이드오프를 봤다. 서빙 관점에서 다시 정리하면, 용량은 「몇 명을 받을 수 있는가」를, 대역폭은 「얼마나 빨리 답하는가」를 결정한다.

④ 서비스 종류 — 같은 사용자 수, 다른 부하

토큰 사용량을 추정하는 법

서비스가 아직 없어서 실측이 불가능하다면, 다음 순서로 추정한다.

1. 전형적인 요청 하나를 직접 만들어 본다. 시스템 프롬프트, 사용자 입력, 검색 결과, 대화 이력을 모두 포함해서.
2. 토크나이저로 실제 토큰 수를 센다. 한글은 영어보다 토큰이 1.5~2배 더 나오므로 영어 기준 추정치를 그대로 쓰면 안 된다.
3. 출력 길이는 실제로 답을 몇 개 뽑아 평균을 낸다. 「보통 500자」 같은 감이 아니라 분포(중앙값과 p95)를 봐야 한다.
4. 대화가 누적되는 서비스라면 세션 평균 길이를 반영한다. 10턴 대화의 마지막 요청은 첫 요청보다 입력이 훨씬 길다.

⑤ 사용자 수를 동시 요청 수로 바꾸기

GPU가 실제로 상대하는 것은 가입자 수가 아니다. 같은 순간에 살아 있는 요청의 개수다. 이 환산이 용량 산정에서 가장 자주 틀리는 지점이다.

산정 절차 — 일곱 단계

앞의 다섯 변수를 순서대로 넣으면 답이 나온다. 이 절차를 그대로 따라 하면 된다.

[1] 서비스 정의
      모델 · 정밀도 · 서비스 종류 · 목표 SLO(TTFT, TPOT)

[2] 요청 프로파일
      평균 입력 토큰  I
      평균 출력 토큰  O
      요청당 왕복 횟수 R      (에이전트가 아니면 1)

[3] 동시 요청 수
      QPS       = DAU × 피크집중률 × 세션당요청 ÷ 피크시간(초)
      평균 응답 = TTFT + O × TPOT
      동시요청 N = QPS × 평균 응답 × R        ← Little's Law

[4] 메모리 상한 검사
      가중치        = 파라미터 × 정밀도바이트
      요청당 KV     = 2 × 레이어 × KV헤드 × 헤드차원 × (I+O) × 바이트
      필요 메모리   = 가중치 + 요청당KV × N + 오버헤드(약 10%)
      → GPU 메모리에 들어가는가?  안 들어가면 GPU를 늘리거나 N을 줄인다

[5] 처리량 상한 검사
      필요 출력 토큰/초 = QPS × O
      GPU 1대 실효 처리량 = (실측 또는 추정) tok/s
      필요 GPU 수(처리량) = 필요 토큰/초 ÷ GPU 1대 처리량

[6] 목표 활용률 반영
      최종 GPU 수 = max(메모리 기준, 처리량 기준) ÷ 목표활용률
                     ( 지연 중시 0.6 · 처리량 중시 0.9 )

[7] 여유와 검증
      + 장애 대비 여유 (N+1)
      + 성장 여유 (6~12개월)
      → 부하 테스트로 실측 검증

워크 예제 ① — 학과 챗봇 (학생 500명)

워크 예제 ② — 사내 코딩 어시스턴트 (개발자 2,000명)

워크 예제 ③ — 공공 RAG 문서 서비스 (동시 접속 200)

예제 ③에서 보듯, 긴 컨텍스트 서비스는 KV 캐시가 가중치보다 훨씬 큰 몫을 차지한다. 이런 서비스에서는 「어떤 모델을 쓸까」보다 「KV를 어떻게 줄일까」가 예산을 결정한다. 10장의 오프로딩·프리픽스 재사용, 그리고 KV 양자화가 여기서 실제 돈이 된다.

시뮬레이션과 검증 — 계산은 시작일 뿐

위 계산은 출발점이지 답이 아니다. 실제 성능은 엔진 구현, 스케줄링, 요청 분포에 따라 계산값의 절반이 나올 수도 있다. 반드시 실측으로 검증해야 한다.

검증 절차

1. 단일 요청 기준선 — 동시 요청 1건으로 TTFT·TPOT을 잰다. 이것이 그 GPU·모델 조합의 최선이며, 여기서부터만 나빠진다.
2. 포화점 찾기 — 동시 요청 수를 1, 2, 4, 8, 16, 32… 로 올리며 처리량과 p99 지연을 기록한다. 처리량이 더 이상 안 늘고 지연만 늘기 시작하는 지점이 포화점이다.
3. SLO 경계 찾기 — p99 지연이 목표 SLO를 넘는 동시 요청 수를 찾는다. 이것이 그 GPU 한 대의 실제 용량이다.
4. 계산값과 비교 — 계산에서 나온 N과 실측 용량의 비율을 구한다. 이 비율이 여러분 환경의 보정 계수이며, 이후 산정에 그대로 쓸 수 있다.
5. 장시간 부하 — 30분 이상 돌려 메모리 단편화, 성능 저하, 스로틀링이 없는지 확인한다.

자주 나오는 함정

실습 — 우리 조건으로 산정하고 실측으로 검증하기

# 모델을 띄우고 동시 요청 수를 올려 가며 측정
vllm serve <model> --max-model-len 8192

# 동시성 1 → 2 → 4 → 8 → 16 → 32 …
#   기록: 처리량(tok/s), TTFT p50/p99, TPOT p50/p99, GPU 메모리 사용량

# KV 캐시 사용량 확인 (엔진 로그 또는 메트릭)
#   - 할당된 KV 블록 수
#   - 요청당 실제 KV 점유량

참고 자료

• 각 오픈 웨이트 모델의 config.json — 레이어 수·KV 헤드 수·헤드 차원의 1차 출처
• Kwon et al., PagedAttention (SOSP 2023) — KV 캐시 관리가 동시 처리 수를 어떻게 바꾸는가
• vLLM · SGLang 벤치마크 문서 — 부하 테스트 방법
• Little, A Proof for the Queuing Formula L = λW (1961) — 동시 요청 수 환산의 근거
• NVIDIA Dynamo AIConfigurator 문서 — SLO 기반 구성 탐색 도구