온프레미스 AI 인프라, 현장에서 본 것들
Jay
컨설팅 대외사업 리더가 쓰는 AI 구축 노트
1편. "GPU 몇 장이면 되나요?" — 이 질문부터 다시 시작해야 합니다
GPU 몇 장 사면 되나요?
AI 사업의 첫 미팅에서 거의 예외 없이 나오는 질문이 있습니다.
"저희 GPU 몇 장 사면 되나요?"
사실 이 질문에는 그 자리에서 바로 답하기 어렵습니다.
정확히 말하면, 그 자리에서 숫자를 바로 말하는 것이 오히려 위험합니다.
그런데 실제 사업 현장에서는 숫자가 너무 빨리 결정됩니다.
누군가 "8장이면 충분할 것 같습니다"라고 말합니다.
그 숫자가 회의록에 들어가고, 어느 순간 RFP의 요구 규격이 됩니다. 그리고 6개월 뒤 실제 서비스를 열었을 때 문제가 시작됩니다.
왜 이런 일이 생길까요?
GPU 수량은 설계의 입력값이 아니라 결과값이기 때문입니다.
사용자가 얼마나 들어오는지, 동시에 몇 명이 요청하는지, 어떤 모델을 사용할지, 컨텍스트를 얼마나 길게 넣을지, 어느 정도 응답 속도를 보장할지에 따라 필요한 GPU 수량은 달라집니다.
그렇다면 GPU 수량은 어떻게 계산해야 할까요?
간단한 가정을 하나 놓고 숫자로 역산해보겠습니다.
1단계. 사용자 수를 '동시 세션 수'로 바꾼다
AI 사업을 논의하다 보면 이런 요구사항을 자주 듣습니다.
"전사 3,000명이 사용할 예정입니다."
하지만 3,000명은 아직 인프라 설계에 사용할 수 있는 숫자가 아닙니다.
3,000명의 사용자가 동시에 엔터를 누르는 것은 아니기 때문입니다.
인프라 사이징에서 필요한 숫자는 전체 사용자 수가 아니라 피크 시점에 동시에 처리해야 하는 세션 수입니다.
예를 들어 다음과 같이 가정해보겠습니다.
- 전사 사용자: 3,000명
- 일일 활성 사용자(DAU) 비율: 30%
- 실제 일일 활성 사용자: 900명
- 1인당 일평균 질의 수: 8회
- 전체 일일 질의 수: 7,200회
- 전체 질의의 20%가 피크 1시간에 집중
- 피크 시간 요청 수: 1,440회/시간
- 초당 요청 수: 약 0.4회/초
즉, 피크 시간에는 평균적으로 초당 약 0.4개의 요청이 들어오는 셈입니다.
여기에 리틀의 법칙(Little's Law)을 적용할 수 있습니다.
동시 처리 수 = 요청 도착률 × 평균 처리시간
평균적으로 하나의 요청을 처리하는 데 20초가 걸린다고 가정하면,
0.4회/초 × 20초 = 8세션
평균값만 기준으로 인프라를 설계할 수는 없습니다.
특정 시간대에 요청이 몰리는 상황을 고려해 버스트 여유를 3배 정도 잡아보겠습니다.
8세션 × 3 = 24세션
따라서 이 서비스의 설계 기준을 동시 24세션으로 잡을 수 있습니다.
여기에서 세션당 생성 속도를 30 token/s로 목표한다고 가정하면 전체 시스템이 처리해야 할 생성 처리량은 다음과 같습니다.
24세션 × 30 token/s = 720 token/s
처음에는 단순히 "사용자 3,000명"이었지만, 계산을 거치면 실제 인프라 설계에 필요한 숫자는 다음과 같이 바뀝니다.
동시 세션 24개, 전체 생성 처리량 약 720 token/s
이제야 GPU 계산을 시작할 수 있습니다.
2단계. 모델 가중치는 쉽다. 진짜 문제는 KV 캐시다
GPU 메모리를 계산할 때 가장 먼저 보는 것은 모델 가중치입니다.
가중치 메모리는 비교적 계산이 단순합니다.
가중치 메모리 ≈ 파라미터 수 × 파라미터당 바이트
예를 들어 30B 모델이라면 대략 다음과 같습니다.
- FP16: 약 60GB
- FP8: 약 30GB
- INT4: 약 15GB
여기까지는 많은 사람들이 계산합니다.
문제는 그다음입니다.
실제 LLM 추론 환경에서는 모델 가중치뿐 아니라 KV Cache가 상당한 GPU 메모리를 사용합니다.
특히 동시 사용자 수가 많아지거나 컨텍스트가 길어질수록 KV 캐시의 영향은 커집니다.
KV 캐시는 세션마다, 그리고 토큰마다 증가합니다.
단순화하면 토큰당 KV 캐시 메모리는 다음과 같이 계산할 수 있습니다.
토큰당 KV 바이트 = 2 × 레이어 수 × KV 헤드 수 × 헤드 차원 × 정밀도 바이트
여기서 2는 Key와 Value를 의미합니다.
예를 들어 다음과 같은 30B급 GQA 모델을 가정해보겠습니다.
- 레이어 수: 48
- KV 헤드 수: 8
- Head Dimension: 128
- KV Cache 정밀도: FP16
- FP16 데이터 크기: 2Byte
계산하면 다음과 같습니다.
2 × 48 × 8 × 128 × 2 = 196,608 Byte ≈ 토큰당 192KB
이제 컨텍스트 길이를 넣어보겠습니다.
앞에서 계산한 동시 세션 24개를 기준으로 합니다.
컨텍스트 8K
- 세션당 KV Cache: 약 1.5GB
- 24세션 KV Cache: 약 36GB
- FP16 모델 가중치 포함: 약 96GB
컨텍스트 16K
- 세션당 KV Cache: 약 3GB
- 24세션 KV Cache: 약 72GB
- FP16 모델 가중치 포함: 약 132GB
컨텍스트 32K
- 세션당 KV Cache: 약 6GB
- 24세션 KV Cache: 약 144GB
- FP16 모델 가중치 포함: 약 204GB
여기서 중요한 사실이 하나 보입니다.
사용자 수도 같고 모델도 같은데, 컨텍스트 길이만 늘렸더니 필요한 메모리가 거의 두 배씩 증가합니다.
기업용 AI에서는 이 부분이 특히 중요합니다.
대부분의 기업용 LLM 서비스가 결국 RAG를 붙이기 때문입니다.
예를 들어 사내 규정 검색 시스템을 만든다고 해보겠습니다.
검색 결과 상위 10개의 청크를 가져오고, 각 청크가 평균 1,000토큰이라면 검색 문서만으로 이미 10,000토큰입니다.
여기에 시스템 프롬프트, 사용자 질문, 이전 대화 이력, 검색된 문서, 응답 생성을 위한 출력 공간까지 붙습니다.
처음에는
"사내 챗봇 하나 만들려고 합니다."
라고 시작했던 사업이 별다른 논의 없이 어느 순간 16K, 32K 컨텍스트를 사용하는 시스템으로 이동합니다.
그리고 GPU 요구량도 같이 달라집니다.
3단계. GPU를 늘리기 전에 레버를 하나씩 당겨본다
이제 같은 요구사항에서 설정만 바꿔보겠습니다.
조건은 다음과 같습니다.
- 동시 세션: 24
- 컨텍스트 길이: 32K
- GPU: NVIDIA H200 141GB 기준
먼저 아무런 최적화를 하지 않고 FP16을 사용한다고 가정해보겠습니다.
FP16 가중치 + FP16 KV Cache
- 모델 가중치: 약 60GB
- KV Cache: 약 144GB
- 합계: 약 204GB
H200 한 장의 VRAM이 141GB이므로 단순 메모리 기준으로는 한 장에 들어가지 않습니다.
FP8 가중치 + FP16 KV Cache
이번에는 가중치만 FP8로 낮춰보겠습니다.
- 모델 가중치: 약 30GB
- KV Cache: 약 144GB
- 합계: 약 174GB
모델 가중치를 절반으로 줄였는데도 여전히 한 장에는 들어가지 않습니다.
왜일까요?
이미 이 구간에서는 모델 가중치보다 KV Cache가 더 많은 메모리를 사용하고 있기 때문입니다.
이번에는 KV Cache까지 FP8로 낮춰보겠습니다.
FP8 가중치 + FP8 KV Cache
- 모델 가중치: 약 30GB
- KV Cache: 약 72GB
- 합계: 약 102GB
단순 메모리 계산으로는 H200 한 장 안으로 들어옵니다.
여기에서 모델 가중치를 INT4까지 낮춘다면 다음과 같습니다.
INT4 가중치 + FP8 KV Cache
- 모델 가중치: 약 15GB
- KV Cache: 약 72GB
- 합계: 약 87GB
메모리 여유는 더 커집니다.
이 계산에서 중요한 것은 단순히 "FP8이 좋다"는 이야기가 아닙니다.
핵심은 이것입니다.
LLM 추론 인프라에서는 모델 가중치만 보고 GPU 메모리를 계산하면 안 됩니다.
특히 긴 컨텍스트와 높은 동시성을 사용하는 서비스에서는 KV Cache가 모델 가중치보다 더 큰 메모리 요소가 될 수도 있습니다.
그래서 가중치 양자화만 고민하고 KV Cache를 보지 않으면 필요 이상의 GPU를 구매할 수도 있습니다.
반대로 KV Cache의 정밀도를 낮추는 것도 공짜는 아닙니다.
KV Cache를 FP8 등으로 낮췄을 때 긴 문맥에서 정보 유지 능력이나 답변 정확도가 어느 정도 유지되는지는 반드시 실제 업무 데이터로 확인해야 합니다.
이 부분은 모델마다 다르고, 업무 특성에 따라서도 결과가 달라질 수 있습니다.
그런데 메모리만 맞으면 GPU 수량이 결정되는 걸까?
앞의 계산을 보면 이런 생각이 들 수 있습니다.
"그러면 총 메모리가 204GB이고 H200이 141GB니까 2장이면 되는 거네요?"
개념적인 1차 계산으로는 그렇습니다.
하지만 실제 GPU 사이징은 이렇게 단순하게 끝나지 않습니다.
LLM Serving 환경에서는 모델 가중치와 KV Cache 외에도 추가적인 GPU 메모리가 필요합니다.
예를 들어 다음과 같은 요소들이 있습니다.
- CUDA Runtime 및 CUDA Graph
- 모델 실행 과정에서 발생하는 Activation
- Attention Workspace
- vLLM이나 SGLang 같은 Serving Engine의 Overhead
- Continuous Batching을 위한 메모리
- Tensor Parallel 통신 Buffer
- Memory Fragmentation
- 운영 안정성을 위한 VRAM 여유 공간
따라서 실제 서비스에서는 GPU VRAM을 100%까지 채워서 운영하지 않습니다.
또 GPU 두 장을 장착했다고 해서 141GB + 141GB를 단순히 하나의 282GB 메모리처럼 사용할 수 있는 것도 아닙니다.
Tensor Parallel이나 Pipeline Parallel을 어떻게 구성하는지에 따라 모델 배치 방식과 GPU 간 통신 비용이 달라집니다.
더 중요한 문제도 있습니다.
메모리가 충분하다는 것과 성능이 충분하다는 것은 전혀 다른 이야기입니다.
GPU 사이징에는 결국 두 가지 조건을 동시에 만족해야 합니다.
첫 번째는 메모리입니다.
모델과 KV Cache가 GPU에 올라가는가?
두 번째는 연산 성능입니다.
목표 동시 사용자와 token/s를 실제로 처리할 수 있는가?
그래서 지금까지의 계산은 어디까지나 1차적인 Capacity Planning입니다.
최종 GPU 수량은 실제 사용할 모델과 Serving Engine을 GPU에 올린 뒤 부하 테스트를 통해 검증해야 합니다.
4단계. 계산으로 시작하고 Benchmark로 끝낸다
LLM 추론에는 또 하나 중요한 특성이 있습니다.
LLM이 답변을 만드는 과정은 크게 Prefill과 Decode 두 단계로 나뉩니다.
Prefill은 사용자가 입력한 프롬프트와 문서를 처음 읽는 단계입니다.
Decode는 이후 실제 답변 토큰을 하나씩 생성하는 단계입니다.
앞에서 계산한
24세션 × 30 token/s = 720 token/s
는 주로 Decode 처리량 관점의 목표값입니다.
하지만 RAG 시스템처럼 16K, 32K의 긴 컨텍스트를 사용하면 이야기가 달라집니다.
수십 페이지에 해당하는 입력을 먼저 읽어야 하므로 Prefill 부하가 커지고, 사용자가 첫 번째 답변 토큰을 보기까지 걸리는 시간인 **TTFT(Time To First Token)**도 길어질 수 있습니다.
따라서 실제 Benchmark에서는 단순히 "초당 몇 토큰이 나오느냐"만 봐서는 안 됩니다.
최소한 다음 지표를 함께 봐야 합니다.
- 최대 동시 세션 수
- TTFT(Time To First Token)
- ITL(Inter-Token Latency)
- 사용자당 Output token/s
- 전체 Aggregate token/s
- P95 Latency
- GPU Memory Utilization
- GPU Compute Utilization
그리고 실제 업무와 비슷한 입력 길이를 만든 뒤 동시 사용자를 단계적으로 증가시켜봅니다.
동시 사용자 8명 → 16명 → 24명 → 32명 → 48명
이 과정에서 TTFT와 응답 속도가 어떻게 변화하는지 측정합니다.
예를 들어 24명까지는 30 token/s가 유지되지만 32명이 되는 순간 18 token/s로 떨어진다면, 그 지점이 실제 시스템의 중요한 Capacity 경계가 됩니다.
그래서 GPU 사이징은 크게 두 단계로 나눠서 보는 것이 좋습니다.
1차. 계산을 통한 Capacity Planning
사용자 수에서 출발해 대략적인 GPU 요구량을 계산합니다.
사용자 수 → 요청량 → 피크 요청률 → 동시 세션 → 컨텍스트 길이 → KV Cache → 모델 메모리 → 예상 GPU 수량
이 단계에서 "대략 몇 장 정도 필요한가"를 판단합니다.
2차. 실제 모델 Benchmark
실제로 사용할 GPU에 실제 모델과 Serving Engine을 올립니다.
그리고 실제 업무와 유사한 프롬프트, RAG 문서, 컨텍스트 길이를 넣고 동시성을 높여가며 성능을 측정합니다.
그리고 비로소
"이 업무에서는 H200 몇 장이 적정한가?"
라는 결론을 내립니다.
결국 GPU 사이징은 계산으로 시작하지만 Benchmark로 끝나야 합니다.
사이징은 두 방향으로 실패한다
GPU 사이징이 잘못되는 경우는 크게 두 가지입니다.
과다 산정
가장 흔한 경우 중 하나는 학습 기준으로 추론 인프라를 설계하는 것입니다.
사업 초기에는 이런 이야기가 자주 나옵니다.
"나중에 파인튜닝도 할 수 있지 않을까요?"
그 한마디 때문에 학습까지 고려한 GPU 구성이 견적에 들어갑니다.
그런데 실제 파인튜닝 계획은 '언젠가'이고, 장비 구매는 지금 이뤄집니다.
결국 장비는 데이터센터에 들어왔지만 GPU 가동률은 20%대에 머물고, 감가상각은 계속 진행됩니다.
AI 인프라는 부족해도 문제지만 너무 많이 사도 명확한 비용 실패입니다.
과소 산정
반대의 경우도 있습니다.
PoC 단계에서 담당자 한두 명이 사용해보고
"속도 괜찮네요."
라고 판단한 뒤 그 환경을 그대로 전사 서비스로 가져가는 경우입니다.
PoC에서는 사용자가 한 명이었지만 운영에서는 동시에 수십 명이 들어옵니다.
결국 서비스 오픈 첫 주부터 요청 대기열이 발생하고 응답 속도가 급격히 떨어집니다.
AI 서비스에서 이 문제는 생각보다 치명적입니다.
사용자에게 첫인상은 한 번뿐입니다.
한 번
"이 AI 느리다."
라는 인식이 생기면 이후 GPU를 증설하고 성능을 개선해도 사용자가 다시 돌아오지 않는 경우가 많습니다.
그런데 RFP에 이미 "GPU N장"이라고 적혀 있다면?
여기까지 이야기하면 현실적인 질문이 하나 남습니다.
"이미 RFP에 GPU 8장이라고 적혀 있는데요?"
공공이나 금융 프로젝트에서는 이런 경우가 생각보다 흔합니다.
GPU 수량이 기술 검토보다 먼저 예산이나 규격으로 확정되어 RFP에 들어옵니다.
이 경우 반드시 GPU 수량 자체를 뒤집으려고 할 필요는 없습니다.
수행사 입장에서는 오히려 주어진 GPU 수량에서 어떤 성능까지 보장하는지를 명확하게 정의하는 것이 더 중요합니다.
예를 들어 제안서에 다음과 같이 적을 수 있습니다.
[제안서 문구 예시]
본 제안의 성능 지표는 동시 세션 24, 평균 입력 컨텍스트 8,000토큰, 출력 속도 30 token/s 조건을 전제로 산출되었습니다. 운영 중 평균 컨텍스트 길이가 16,000토큰을 초과하거나 동시 세션이 40을 초과하는 경우 목표 응답 성능 유지를 위해 추가 자원 증설이 필요할 수 있으며, 이에 따른 인프라 변경은 별도 협의 대상으로 합니다.
여기에서 중요한 것은 한 문장입니다.
"요구 규격을 충족한다"와 "요구 성능을 보장한다"는 전혀 다른 이야기입니다.
GPU 8장을 설치했다고 해서 어떤 워크로드에서도 일정한 응답 속도를 보장한다는 의미는 아닙니다.
사용자 수, 동시성, 컨텍스트 길이, 모델 크기, 양자화 방식, 출력 토큰 수가 변하면 성능도 변합니다.
따라서 제안 단계에서 성능 보장의 전제조건을 숫자로 명시해야 합니다.
이 구분을 제안 단계에서 하지 않으면 프로젝트 마지막 검수 단계에서 이런 질문을 받게 됩니다.
"GPU는 규격대로 들어갔는데 왜 느리죠?"
그리고 그때부터는 대부분 수행사의 문제가 됩니다.
GPU 수량은 질문의 시작이 아니라 마지막 숫자다
AI 인프라를 설계할 때 중요한 것은
"GPU를 몇 장 살 것인가?"
부터 결정하는 것이 아닙니다.
그보다 먼저 물어야 할 질문이 있습니다.
몇 명이 동시에 사용할 것인가.
평균 컨텍스트는 얼마나 긴가.
몇 token/s의 응답 속도를 보장할 것인가.
어느 정도의 응답 지연을 허용할 것인가.
그리고 어느 수준의 품질까지 유지할 것인가.
이 값들이 정해지면 그다음 순서는 자연스럽습니다.
사용자 ↓ 요청량 ↓ 동시 세션 ↓ 컨텍스트 길이 ↓ KV Cache ↓ Prefill / Decode 요구량 ↓ 모델 및 Serving 구성 ↓ GPU 후보 산정 ↓ 실제 Benchmark ↓ 최종 GPU 수량
결국 GPU 수량은 처음부터 정해놓는 숫자가 아닙니다.
GPU는 시작점이 아니라 계산의 마지막에 나오는 숫자입니다.
그리고 GPU를 구매하고 나면 또 다른 문제가 기다리고 있습니다.
이번에는 모델이나 토큰보다 훨씬 더 물리적인 문제입니다.
전기와 열입니다.
다음 편에서는 GPU 서버를 데이터센터에 넣는 순간 만나게 되는 전력, 발열, 랙 밀도 이야기를 해보겠습니다.
