LLM 자체 호스팅에 필요한 서버 규모 추정: VRAM 계산부터 동시 사용자까지

“사내에 LLM 하나 띄우려면 서버가 얼마나 필요한가요?“라는 질문에는 정해진 답이 없지만, 정해진 계산 순서는 있습니다. 모델 크기에서 VRAM을 계산하고, 동시 사용량에서 여유분을 잡고, 목표 속도에서 대역폭을 확인하는 순서입니다. 이 글은 그 순서를 따라가며 시나리오별 구성 예시까지 잇습니다. 학습과 추론의 차이에서 이어지는 글이고, 여기서 다루는 것은 추론(서빙) 쪽입니다. LLM의 동작 원리 자체는 교양 편, 애플리케이션 개발은 LLM 앱 개발 시리즈에서 다뤘습니다.

1단계. 모델 가중치의 VRAM: 파라미터 × 바이트 #

출발점은 단순한 곱셈입니다. 모델 가중치가 차지하는 메모리는 파라미터 수 × 파라미터당 바이트입니다.

여기서 두 가지 실무 감각이 나옵니다. 첫째, BF16 70B(140GB)는 웬만한 단일 GPU에 안 들어갑니다(H100 80GB에는 안 들어가고, B200 192GB에는 들어갑니다). 여러 장에 나누는 텐서 병렬이 필요하고, 그 순간 요구 사양이 NVLink 있는 장비로 올라갑니다. 둘째, 양자화가 규모 추정을 통째로 바꿉니다. 같은 70B가 4비트에서는 48GB급 카드 한 장 + 여유분 구성으로 내려옵니다. 품질 손실은 있지만 많은 사내 용도에서 수용 가능한 수준이라, 예산 검토는 양자화 포함/미포함 두 줄로 하는 것이 실용적입니다.

2단계. KV 캐시: 동시 요청이 먹는 메모리 #

가중치만 계산하고 끝내면 배포 첫날 메모리 부족에 부딪힙니다. LLM 서빙은 요청마다 KV 캐시(진행 중인 대화의 어텐션 키·값 저장소)를 유지하는데, 이 크기가 동시 요청 수 × 컨텍스트 길이에 비례해서 자랍니다. 모델과 설정에 따라 다르지만, 긴 컨텍스트의 동시 요청이 수십 개 쌓이면 KV 캐시만 수십 GB가 되는 것이 보통입니다.

실무 규칙은 이렇습니다.

• 가중치 외에 VRAM의 20〜40%를 KV 캐시와 런타임 여유로 남깁니다. 80GB 카드에 70GB짜리 가중치를 얹는 구성은 동시성 1〜2에서 이미 터집니다.
• 컨텍스트 길이 상한을 정책으로 정합니다. “최대 128K 지원"을 그대로 열어 두면 소수의 긴 요청이 메모리를 독식합니다. 용도에 맞는 상한(예: 사내 문서 질의는 16K〜32K)이 규모 추정의 전제가 됩니다.

3단계. 속도와 동시성: 대역폭이 정합니다 #

필요한 GPU 수를 정하는 마지막 변수는 목표 속도입니다. 지표는 두 개로 나눠 봅니다. 첫 토큰까지의 시간(TTFT)과 토큰당 생성 시간(TPOT)입니다. 체감 품질의 기준선은 TTFT(수 초를 넘으면 느리게 느껴짐)와 초당 20〜30토큰 이상의 생성 속도(읽는 속도보다 빠름)입니다.

토큰 생성은 전편에서 본 대로 메모리 대역폭에 좌우됩니다. 단순화하면 단일 요청의 생성 속도 상한 ≈ 메모리 대역폭 ÷ 가중치 크기입니다. 3,000GB/s급 대역폭에 40GB 가중치면 이론상 초당 70토큰대가 상한이고, 실효는 그 아래입니다. 동시 요청은 vLLM 같은 서빙 엔진의 continuous batching이 배치로 묶어 GPU를 채우므로, 총 처리량은 올라가지만 요청당 속도는 동시성이 높아질수록 내려갑니다. 동시 사용자 수가 두 배가 되면 GPU를 늘리는 게 아니라, 먼저 “요청당 속도가 SLO 안에서 버티는 동시성 상한"을 벤치마크로 찾는 것이 순서입니다.

시나리오 예시: 세 가지 규모 #

계산을 시나리오로 이으면 감이 잡힙니다. 구체적 GPU 선택은 이름 읽는 법의 VRAM·대역폭 기준을 적용합니다.

• 소규모 사내 도구(동시 사용자 〜10명, 8B급 모델): 4비트 8B는 5GB 안팎이라 24GB급 추론 카드(L4급) 한 장으로 KV 캐시까지 넉넉합니다. 서버 한 대, 월 비용은 클라우드 기준 수십만 원대부터 시작합니다. 이 규모에서 플래그십 GPU는 과투자입니다.
• 중규모 서비스(동시 수십, 32B〜70B 양자화): 4비트 70B(약 40GB+캐시)는 48GB 카드 두 장 또는 80GB급 한 장이 출발점입니다. 텐서 병렬을 쓸 거면 NVLink 있는 구성이 유리해집니다. 이중화까지 고려해 동일 구성 2노드 + 로드밸런서가 실무 최소선입니다.
• 대규모·고품질(비양자화 70B급 이상, 높은 동시성): 80GB급 여러 장의 텐서 병렬 노드를 수평 확장하는 구성이고, 이때부터는 학습 서버급 인프라 논의(전력·냉각·활용률)가 서빙에도 적용됩니다. 이 규모의 투자 전에 아래 손익분기 계산이 특히 중요합니다.

자체 호스팅 전에: API와의 손익분기 #

규모 추정의 마지막 단계는 “정말 자체 호스팅이 싼가?“라는 검산입니다. 상용 API는 토큰당 과금이라 사용량이 적을수록 유리하고, 자체 호스팅은 고정비라 사용량이 많고 꾸준할수록 유리합니다. 월 토큰 사용량 추정치로 API 요금을 계산해 GPU 비용(클라우드 임대료 또는 구매 상각 + 전력 + 운영 인력)과 나란히 놓으면 손익분기가 나옵니다. 실무에서 자체 호스팅이 정당화되는 흔한 근거는 비용보다 데이터 반출 불가 요건, 응답 지연 요건, 커스텀 모델입니다. 비용만이 이유라면 활용률 가정(GPU가 하루 몇 시간 일하는가)을 보수적으로 잡고 다시 계산해 보길 권합니다. 유휴 GPU는 가장 비싼 형태의 낭비이기 때문입니다.

결정 순서 정리 #

1. 모델과 품질 요건 확정: 후보 모델 크기와 양자화 허용 여부를 정합니다.
2. VRAM 계산: 파라미터 × 바이트 + KV 캐시·여유 20〜40%로 카드 용량과 장수를 산출합니다.
3. 속도 요건 확인: TTFT·생성 속도 SLO를 정하고, 대역폭 기준으로 후보 GPU를 거릅니다.
4. 벤치마크: 후보 구성에서 vLLM 등으로 실제 워크로드 형태(컨텍스트 길이, 동시성)를 재현해 동시성 상한을 실측합니다. 스펙 계산은 후보를 거르는 데까지만 쓰고, 최종 결정은 실측으로 합니다.
5. API 손익분기 검산: 추정 사용량으로 자체 호스팅과 API를 비교하고, 비용 외 요건(데이터·지연·커스텀)을 명시합니다.

정리 #

• 규모 추정은 곱셈에서 시작합니다. 가중치 VRAM = 파라미터 수 × 정밀도 바이트이고, 양자화가 이 숫자를 절반 이하로 바꿉니다.
• 가중치 외에 KV 캐시 몫으로 VRAM의 20〜40%를 남기고, 컨텍스트 길이 상한을 정책으로 정합니다.
• 생성 속도는 메모리 대역폭이 정하고, 동시성은 배칭으로 처리량과 교환됩니다. SLO 안의 동시성 상한은 실측으로 찾습니다.
• 소규모는 추론 카드 한 장이면 충분하고, 플래그십 GPU가 필요한 것은 비양자화 대형 모델과 높은 동시성부터입니다.
• 마지막 검산은 API와의 손익분기입니다. 자체 호스팅의 정당화 근거가 비용뿐이라면 활용률 가정을 의심합니다.