온프레미스 손익분기 14개월 — GPU 가동률 60%가 클라우드 분기점인 이유

사내 AI 인프라 VRAM 산정 공식 — H100 80GB로 70B를 못 돌리는 이유

사내에서 LLM·RAG·에이전트를 도입하려고 견적서를 받아 보면 H100·H200·L40S 같은 칩셋 이름이 등장합니다. 이 글은 그 스펙표를 단편적으로 비교하기 전에, 추론·파인튜닝·RAG·에이전트 4종 워크로드가 각각 어떤 메모리·인터커넥트·스토리지를 요구하는지를 정량 공식으로 정리합니다.

이 글은 사내 AI 인프라를 설계하는 개발팀 리드·아키텍트가 오픈소스 LLM·파인튜닝·RAG·에이전트 워크로드의 하드웨어 스펙 산정 메커니즘을 이해하고, 자사 워크로드에 맞는 GPU·RAM·인터커넥트·스토리지 구성과 온프레미스/클라우드 의사결정 기준을 얻도록 돕습니다.

사내 AI 파일럿이 "장비 먼저 사고 모델을 끼워 맞추는" 함정에 빠지지 않으려면, 워크로드별 메모리 점유 메커니즘과 가동률 기반 TCO 손익분기점을 먼저 잡아야 합니다. 이 글은 그 기준선을 숫자로 제시합니다.

이 글에서 다루는 것

• LLM 추론 VRAM 산정 (정적 가중치 + KV 캐시 + 여유분 공식)
• QLoRA/LoRA 파인튜닝 VRAM 산정과 Full FT와의 트레이드오프
• RAG 벡터DB의 시스템 RAM·NVMe 산정 (HNSW 오버헤드, DiskANN 회피책)
• NVLink vs PCIe 인터커넥트와 TP/PP 병렬화 전략
• H100 / H200 / L40S 비교와 워크로드별 선택 기준
• 온프레미스 vs 클라우드 TCO 손익분기점과 가동률 기반 의사결정

이 글에서 다루지 않는 것

• Kubernetes·Slurm MLOps 운영 세부 (오케스트레이션 구성, GitOps 등)
• 특정 벤더 소프트웨어 스택 설정 상세 (vLLM·TGI 옵션값 튜닝 등)
• 보안·네트워크 방화벽·망분리 구성 가이드
• 데이터 전처리·임베딩 모델 선정 방법론

LLM 추론 VRAM은 정적 가중치가 아니라 KV 캐시가 결정한다

사내 AI 에이전트에서 OOM은 대개 모델을 로드하는 순간이 아니라, 사용자가 긴 컨텍스트를 던지기 시작하는 런타임에서 터집니다. 정적 가중치만 보면 H100 80GB 2장에 70B 모델이 들어갈 것 같지만, 실제 운영 VRAM은 모델 가중치 + KV 캐시 + 20~30% 여유분으로 구성되며 KV 캐시가 정적 가중치보다 커지는 경우가 흔합니다.

정적 가중치는 단순 공식으로 산정됩니다. 파라미터 수 × 정밀도(바이트) × 1.2 (오버헤드 마진) 입니다. BF16 정밀도는 파라미터당 2바이트, INT4는 0.5바이트이므로 Llama-3.1-8B BF16은 약 16GB, 70B BF16은 약 140GB, 70B INT4는 약 35GB가 됩니다. 405B BF16급은 단일 노드에서는 적재 자체가 불가능한 810GB 영역입니다.

문제는 KV 캐시입니다. 자기회귀 생성 시 과거 토큰의 어텐션 결과를 VRAM에 보관해야 하며, 공식은 2 × L × H × d × T × N × 2bytes로 컨텍스트 길이 T에 선형 비례합니다. Llama-3.1-70B FP16 기준 실측치는 4K 토큰에서 약 1.31GB, 32K 토큰에서 약 10.48GB, 128K 토큰에서는 약 167.77GB까지 치솟습니다. 결과적으로 128K 컨텍스트 단일 사용자 1명을 서빙하려면 정적 140GB + KV 168GB = 약 308GB 이상이 필요합니다.

GQA(Grouped-Query Attention)는 이 부담을 완화하는 핵심 기법입니다. 복수 쿼리 헤드가 소수 KV 헤드를 공유하므로 공식의 H가 대폭 축소되며, GQA를 채택한 Llama-3.1-8B는 128K 토큰에서도 약 16.78GB 수준에서 KV 캐시가 멈춥니다. 그래도 8B만큼은 단일 GPU에서 다룰 만하지만, 70B급에서 GQA만으로는 부족합니다.

vLLM의 PagedAttention은 KV 캐시 메모리 단편화를 OS 페이징 방식으로 해결합니다. 기존 구현은 메모리 낭비가 60~80%에 달하지만 PagedAttention은 이를 4% 미만으로 줄이고, 처리량을 2~4배 향상시킵니다. 다만 vLLM의 H100 80GB 실측 기준 70B FP16을 로드하면 KV 캐시용 여유 VRAM이 약 30~35GB밖에 남지 않으므로, 단일 H100 2장으로 긴 컨텍스트 다중 사용자 에이전트를 서빙하기는 어렵습니다.

요약하면 운영 VRAM 공식은 "정적 가중치 × 1.2 + KV 캐시(컨텍스트 길이·동시성)" 이고, 컨텍스트 길이 T와 동시 사용자 N을 모르면 GPU 장수 산정이 불가능합니다. 사내 에이전트의 평균·최대 컨텍스트 길이를 PoC 단계에서 측정하는 것이 첫 번째 과제입니다.

파인튜닝 VRAM은 학습 방식에 따라 23배 차이가 난다

같은 70B 모델이라도 학습 방식에 따라 VRAM 요구량이 극적으로 갈립니다. Full Fine-Tuning은 옵티마이저 상태(FP32 8B) + 그래디언트 + 마스터 가중치 + 활성화를 모두 메모리에 올려야 하므로 경험칙으로 파라미터 1B당 약 16GB VRAM을 요구합니다. 7B Full FT가 약 112GB, 70B Full FT는 1.1TB+ 영역입니다.

반면 PEFT 계열은 다른 그림을 보여줍니다. LoRA는 베이스 모델 가중치를 동결한 채 가중치 변화량 ΔW를 두 저랭크 행렬 A·B로 근사·학습하며, 학습 파라미터를 전체의 0.5~5%로 축소합니다. QLoRA는 한 발 더 나아가 베이스 모델을 4-bit NF4로 양자화한 채 LoRA 어댑터만 BF16으로 학습하고, 옵티마이저 상태는 Paged Optimizer로 RAM에 오프로드합니다.

수치로 보면 차이가 분명합니다.

모델	LoRA 16-bit	QLoRA 8-bit	QLoRA 4-bit
7B	15GB	9GB	5GB
13B	28GB	17GB	9GB
30B	63GB	38GB	20GB
70B	146GB	88GB	46GB
110B	229GB	138GB	72GB

(시퀀스 ~512 토큰 기준)

70B 모델을 Full FT로 학습하려면 1.1TB+ VRAM이 필요해 8×H100 SXM + ZeRO-3 클러스터가 필수지만, QLoRA 4-bit는 단일 H100 80GB 한 장으로도 46GB만 사용해 학습이 가능합니다. 동일 모델 동일 학습이지만 VRAM 차이는 약 23배입니다. 사내 도메인 특화 학습 대다수는 이 차이만큼의 인프라 투자를 정당화할 만큼의 품질 차이를 요구하지 않습니다.

품질 트레이드오프는 명확히 알려져 있습니다. QLoRA는 Full FT 대비 80~90% 수준, LoRA 16-bit는 90~95% 수준의 품질을 달성합니다. 사내 도입 초기·예산 제약 환경이라면 QLoRA가 사실상 유일한 현실적 선택지이지만, 도메인 지식을 깊이 주입하는 지속학습(Continual Pre-training)이나 대규모 데이터셋 SFT에서는 Full FT만이 답이 되는 경우도 있습니다.

추가로 유의할 변수는 시퀀스 길이입니다. 시퀀스를 512에서 1024로 늘리면 VRAM은 1.5~2배 증가하고, 4096 토큰 이상에서는 기준치 대비 약 30%가 더 붙습니다. 위 표는 512 토큰 기준치이므로, 긴 문서를 다루는 도메인이라면 표 수치에 추가 마진을 두고 산정해야 합니다.

요약하면 사내 학습이 8B~32B 모델 범위에 머무르고 도메인 어댑터 수준이라면 QLoRA는 L40S 한두 장으로도 시작할 수 있습니다. 70B+ Full FT를 고려한다면 그 순간부터 인프라 등급은 H100 SXM 클러스터로 점프합니다.

RAG 벡터DB의 진짜 병목은 GPU가 아니라 시스템 RAM이다

RAG 인프라를 GPU 중심으로 설계하면 실제 운영에서 OS 스와핑으로 쿼리 지연이 ms에서 초 단위로 폭증하는 사고가 납니다. 1,000만 벡터 RAG의 진짜 병목은 GPU 한 장이 아니라 시스템 RAM과 PCIe Gen 4.0+ NVMe입니다.

원시 벡터 데이터 크기 공식은 단순합니다. vector 수 × 차원 × 4 bytes 입니다. 1M vectors × 1536 dim × 4B = 약 6.14GB이고, 1,000만 벡터로 늘리면 60GB가 됩니다. 문제는 여기에 HNSW 인덱스 오버헤드가 붙는다는 점입니다. HNSW(Hierarchical Navigable Small World)는 각 벡터를 노드로 연결하는 그래프 인덱스로, 인-메모리 상주가 전제되며 원시 데이터의 1.5~2배 RAM 오버헤드가 발생합니다.

오버헤드 공식은 1.1 × (dim + 8 × M) bytes/vector (M은 연결 수, 기본값 32)입니다. 1,000만 벡터(1536 dim) 사례에 적용하면 원시 60GB + HNSW 그래프 = 총 100~180GB RAM이 필요합니다. Milvus의 작은 예시(1M vectors, 128 dim, FP32)에서도 raw 512MB + HNSW 그래프 128MB = 640MB로 약 25%의 오버헤드가 확인됩니다.

RAG 규모	vector 수	권장 RAM	권장 NVMe
PoC	~10만	64~128GB	1~2TB
소규모	~100만	128~256GB	2~4TB
중규모	~500만~1000만	256~512GB	4~16TB
대규모	1000만+	512GB+ / 3노드 HA	10TB+

RAM 폭증을 회피하는 두 갈래가 있습니다. 첫째는 양자화입니다. Milvus의 IVF4096 + PQ8 조합은 원시 FP32 대비 약 99% 메모리 절감이 가능하며, HNSW M=16과 결합하면 원시의 약 1.3배 수준까지 내려갑니다. 다만 양자화는 재현율(recall) 손실을 동반하므로 사내 검색 품질 기준선과의 트레이드오프 검증이 필요합니다.

둘째는 DiskANN 계열 on-disk 인덱스입니다. Qdrant의 on_disk=True 옵션처럼 HNSW 그래프를 디스크에 보관하고 mmap I/O로 페이징하는 방식인데, RAM 요구량은 극적으로 줄지만 PCIe Gen 4.0+ 엔터프라이즈 NVMe가 필수가 됩니다. 초당 수만 건의 랜덤 I/O가 발생하므로 SATA SSD(~550MB/s)로는 즉시 병목이 발생하고, PCIe Gen 4.0 NVMe(~7GB/s) 또는 Weka·BeeGFS 같은 병렬 파일 시스템으로 10~20GB/s를 확보해야 합니다.

CPU·메모리 채널도 변수입니다. AMD EPYC 9005(Turin)는 단일 소켓 128 PCIe Gen 5 레인 + 12채널 DDR5(460GB/s+ 대역폭)를 제공하므로 GPU 4장 이상의 RAG 노드에서 사실상 기준선이 됩니다. CPU 메모리 채널 부족은 임베딩 생성·인덱싱 단계의 처리량을 직접 깎습니다.

요약하면 RAG는 "GPU 한 장"의 문제가 아니라 256GB ECC DDR5 RAM·PCIe Gen 4.0 NVMe·128레인 CPU가 함께 결정합니다. PoC에서 1,000만 벡터로 확장하는 시점에 RAM·NVMe 산정을 미루면 운영 단계에서 인프라를 통째로 재구매해야 하는 비용이 발생합니다.

NVLink와 PCIe의 7~8배 격차가 병렬화 전략을 강제한다

다중 GPU 환경에서 어떤 병렬화를 선택할지는 인터커넥트가 결정합니다. 텐서 병렬(Tensor Parallel, TP)은 한 레이어의 행렬 곱을 GPU 여러 장에 쪼개고 매 레이어마다 All-Reduce 통신으로 결과를 합치는 방식이고, 파이프라인 병렬(Pipeline Parallel, PP)은 레이어를 GPU에 분배하고 노드 간 1회 전달로 끝내는 방식입니다.

대역폭 격차를 보면 둘의 적용 영역이 갈립니다.

인터커넥트	측정 대역폭
PCIe Gen 4.0 x16	24~26 GB/s
PCIe Gen 5.0	52~60 GB/s
H100 SXM NVLink (이론)	900 GB/s
H100 SXM NVLink (측정)	400~478 GB/s

NVLink와 PCIe Gen 5.0의 격차는 약 7~8배입니다. TP는 레이어마다 통신을 발생시키므로 PCIe로 운용하면 통신 지연이 곧바로 연산 지연으로 직결되고, H100 SXM 대비 최대 2.6배 가까운 성능 손실이 보고됩니다. 반면 PP는 노드 간 1회 전달로 끝나므로 PCIe·이더넷으로도 충분히 운용됩니다.

실무 모범 패턴은 노드 내 TP + 노드 간 PP의 하이브리드입니다. vLLM 권장 구성이 그렇고, 한 노드 안에서는 NVLink로 묶인 8장 GPU에 TP를 적용하고, 노드를 넘어갈 때는 PP로 분리합니다. PP는 파이프라인 버블(빈 단계)로 인한 GPU 활용률 페널티가 있지만 통신 비용이 압도적으로 낮아 이 트레이드오프가 일반적으로 받아들여집니다.

이 격차가 인프라 의사결정에 미치는 영향은 직접적입니다. 70B+ 모델 Full FT는 NVLink 없이는 통신 병목이 전체 학습 시간을 결정하므로, L40S(PCIe·NVLink 미지원)로는 사실상 시도할 수 없습니다. 반대로 8B~32B 모델 다중 인스턴스 서빙은 PP만으로도 운용 가능하므로 NVLink가 필수 요건이 아닙니다. NVLink는 SXM 폼팩터에만 존재한다는 제약도 함께 기억해 둘 필요가 있습니다.

H100 / H200 / L40S — 같은 NVIDIA지만 다른 인프라 등급

NVIDIA 데이터센터 GPU 3종은 같은 카탈로그에 있지만 사실상 다른 인프라 등급으로 보아야 합니다. 스펙 비교부터 정리해 보겠습니다.

제원	H100 SXM5	H200 SXM	L40S PCIe
아키텍처	Hopper	Hopper	Ada Lovelace
VRAM	80GB HBM3	141GB HBM3e	48GB GDDR6
메모리 대역폭	3.35 TB/s	4.8 TB/s	864 GB/s
FP16 Tensor Core	1,979 TFLOPS	~2,000+ TFLOPS	733 TFLOPS
NVLink	지원(SXM)	지원(SXM)	미지원
폼팩터	SXM	SXM	PCIe
2026.1 시스템 참고가	8x ~$277,897	8x ~$277,897	4x ~$52,390

세 칩의 결정적 차이는 메모리 대역폭입니다. LLM 디코딩(토큰 생성)은 매 스텝마다 모델 가중치 전체를 메모리에서 읽어야 하는 메모리 바운드 연산이라, 대역폭이 곧 토큰/초 처리량으로 직결됩니다. H100의 3.35TB/s와 L40S의 864GB/s 사이 약 4배 격차가 LLM 추론 속도 차이를 결정합니다. H200은 여기에 더해 VRAM 141GB·대역폭 4.8TB/s로 Llama 2 70B 추론에서 H100 대비 약 2배 처리량, 주요 워크로드에서 최대 45% 성능 향상을 보입니다.

L40S는 MIG·NVLink 미지원이라는 두 약점이 70B+ 영역에서 치명적입니다. 48GB VRAM 단일로는 70B BF16 모델을 적재조차 할 수 없고, NVLink 없이는 TP를 쓸 수 없으므로 다중 GPU로 묶어도 70B를 서빙하기 어렵습니다. 반대로 8B~32B 모델 다중 인스턴스 서빙, QLoRA 파인튜닝, 파이프라인 병렬 워크로드에서는 L40S가 동일 예산에 더 많은 GPU 장수를 확보하는 강점을 가집니다. 통념과 달리 8B~32B 중심 사내 RAG 환경에서는 4×L40S($52K)가 8×H100($278K) 대비 약 5배의 비용 효율로 앞서는 사례가 있습니다.

선택 기준을 정리하면 다음과 같습니다.

• 8B~32B 추론 + QLoRA 중심: L40S 4~8장 구성. 비용 효율 우위.
• 70B+ TP 서빙 또는 Full FT: H100 SXM 8장 + NVLink가 사실상 필수.
• 긴 컨텍스트(128K+)·고동시성 에이전트: VRAM 141GB·대역폭 4.8TB/s의 H200이 우세.

가격은 2026.1 기준 참고가이며 시장 가용성에 따라 변동합니다. Blackwell 전환 중에는 H100·H200 재고와 신차 가격이 매월 흔들리므로, 발주 시점의 견적과 위 참고가 사이의 갭을 반드시 확인해야 합니다.

온프레미스 vs 클라우드 — 가동률 60%가 분기점이다

토큰당 비용만 보면 온프레미스가 클라우드의 1/8, 상용 API의 1/18 수준입니다. Lenovo 2026년 분석에 따르면 온프레미스는 $0.11/1M tokens, Azure 클라우드는 $0.89/1M, GPT-5 mini급 상용 API는 약 $2.00/1M로 책정됩니다. 5년 누적으로 8×B300급 구성에서 온프레미스 약 $1.01M vs 클라우드 약 $6.24M, $5.2M(83.8%) 절감이 보고됩니다.

다만 이 비교가 성립하려면 GPU 가동률이 90%+ 수준으로 유지된다는 가정이 필요합니다. CapEx 회수는 가동률의 함수이므로, 가동률이 낮으면 손익분기점이 무한정 늘어집니다. Lenovo 분석은 8×H100 온프레미스 vs AWS P5 온디맨드의 손익분기를 가동률 가정 하에 약 3.7개월로 산정합니다.

GPU 가동률	온프레미스 유리 시점	경제성 평가
90%+	7~14개월	온프레미스 압도적 승리
60~80%	14~24개월	온프레미스 유리
40~60%	24~36개월+	하이브리드 고려
40% 미만	손익분기 미달	클라우드가 경제적

2025년 6월 AWS H100 인스턴스 가격이 시간당 약 $7.57에서 $3.90으로 44% 인하되었고, GCP·Azure도 동반 인하 추세입니다. 이는 손익분기점을 일정 부분 연장시키며 클라우드 경쟁력을 강화하는 방향으로 작용합니다. Blackwell 전환 중 H100 재고가 클라우드로 먼저 풀린다는 점도 클라우드 PoC의 진입 장벽을 낮춥니다. Deloitte는 클라우드 지출이 온프레미스 구축비의 60~70%에 도달하면 전환을 검토할 시점으로 제시하기도 합니다.

GPU 시장가도 의사결정에 직결됩니다. 2024~2025년 기준 H100은 $30~40K, A100은 $10~15K, L40S는 $7~10K 수준에서 거래되고 있으며, 이 변동이 CapEx 회수 기간을 흔듭니다. 데이터 주권·컴플라이언스가 강한 영역(금융·헬스케어·방위)에서는 TCO 계산 결과와 무관하게 온프레미스가 강제되는 경우도 있으므로, 비용표만으로 결정하기 어려운 변수도 함께 봐야 합니다.

가장 안전한 경로는 초기 6개월 클라우드 PoC + 실측 가동률 기반 결정입니다. 가동률 예측은 PoC 없이 추정이 거의 불가능하므로, 첫 단계에서 추정으로 온프레미스 8×H100을 구매하는 것은 회수 실패 위험이 높습니다.

사내 AI 인프라 의사결정 — 4가지 워크로드 분리부터 시작하라

지금까지의 내용은 단일 스펙표가 아니라 4종 워크로드별 메모리·인터커넥트 메커니즘을 정리한 것입니다. 사내 AI 인프라 설계가 어려운 이유는 추론·파인튜닝·RAG·에이전트가 서로 다른 자원을 두고 경합하기 때문이며, 단일 매트릭스로 결정할 수 없습니다.

워크로드	주 병목	GPU 필요성
LLM 추론	VRAM (KV 캐시)	메모리 대역폭 큰 GPU 필수
파인튜닝 (QLoRA)	VRAM (학습 + 시퀀스)	단일 H100·L40S로 가능
파인튜닝 (Full FT)	VRAM × 인터커넥트	NVLink 클러스터 필수
RAG 벡터DB	시스템 RAM × NVMe	GPU는 부차적
에이전트 (긴 컨텍스트)	VRAM (KV 캐시 폭증)	H200·H100 클러스터

하향식 4단계 설계 흐름을 권장합니다. (1) 타겟 모델 크기·양자화 정책 결정 → (2) KV 캐시 포함 운영 VRAM 산정 → (3) RAG 규모 기반 시스템 RAM·NVMe 산정 → (4) 인터커넥트·TCO 의사결정. 이 순서를 따르면 "장비 먼저 사고 모델 끼워 맞추기"의 실수를 피할 수 있습니다.

전형적인 사내 도입 경로는 PoC 단계와 운영 단계의 분기입니다. PoC는 L40S 1~2장 + 128GB RAM 환경에서 8B 모델 + 소규모 RAG로 시작하고, 6개월 실측 후 사용량·가동률·컨텍스트 길이 데이터를 확보합니다. 운영 단계 확장이 필요해지면 H100·H200 SXM + 256~512GB RAM 구성으로 점프하며, 이때부터 NVLink·하이브리드 병렬화·온프레미스 TCO 분석이 본격적으로 의미를 가집니다.

마지막으로 다음 단계로 측정해야 할 세 가지 수치를 남깁니다. (1) 자사 워크로드의 평균·P95 컨텍스트 길이, (2) 피크 시간대 동시 사용자 수, (3) 6개월 PoC 기반 예상 GPU 가동률. 이 세 수치 없이는 H100 몇 장이 필요한지 답할 수 없습니다. 사내 AI 인프라 설계의 출발점은 칩 비교가 아니라, 이 세 수치를 측정할 PoC 환경을 먼저 세우는 것입니다.