베어메탈 GPU LLM Serving: AI가 다시 ‘하드웨어’를 보기 시작한 이유

베어메탈 GPU LLM Serving은 가상머신을 거치지 않고 물리 GPU 서버의 자원을 직접 사용해, LLM이 사용자의 요청을 받아 답변하도록 운영하는 방식을 말한다.

쉽게 표현하면 다음과 같다.

빌린 사무실의 일부를 사용하는 것이 아니라, GPU가 장착된 건물 전체를 직접 운영하며 AI 서비스를 제공하는 방식이다.

LLM Serving은 무엇인가?

LLM을 만드는 과정과 사용하는 과정은 다르다.

구분	의미
Training	많은 데이터를 이용해 모델을 학습시키는 과정
Fine-tuning	특정 업무에 맞게 모델을 추가 학습하는 과정
Inference	학습된 모델이 입력을 바탕으로 답을 계산하는 과정
Serving	여러 사용자가 모델을 안정적으로 호출하도록 API 형태로 운영하는 것

따라서 LLM Serving은 단순히 모델을 실행하는 것을 넘어선다.

text

사용자 요청
    ↓
API 서버
    ↓
요청 대기열과 배치 처리
    ↓
GPU에서 LLM 추론
    ↓
토큰 스트리밍
    ↓
사용자에게 답변 전달

여기에는 요청 분산, 동시 사용자 처리, 장애 복구, GPU 메모리 관리, 응답 속도 측정까지 포함된다.

베어메탈이라고 해서 Docker나 Kubernetes를 쓰지 않는 것은 아니다

가장 많이 오해하는 부분이다.

베어메탈은 컨테이너를 사용하지 않는다는 뜻이 아니라, 하이퍼바이저 기반 가상머신 계층 없이 물리 서버를 직접 사용한다는 뜻에 가깝다.

text

가상화 GPU 환경

LLM
↓
컨테이너
↓
가상머신
↓
하이퍼바이저
↓
물리 GPU 서버

text

베어메탈 GPU 환경

LLM
↓
컨테이너 또는 Kubernetes
↓
운영체제와 GPU 드라이버
↓
물리 GPU 서버

실제로 NVIDIA의 AI 인프라 구성도 베어메탈 서버 위에 Kubernetes를 설치하고 GPU 자원을 통합 관리하는 방식을 사용한다. Kubernetes에서는 Device Plugin이나 GPU Operator 같은 구성요소를 통해 GPU를 워크로드에 할당한다. NVIDIA 베어메탈 GPU 아키텍처

즉,

베어메탈과 Kubernetes는 반대 개념이 아니다.
베어메탈은 서버를 제공하는 방식이고, Kubernetes는 그 서버에서 서비스를 운영하는 방식이다.

왜 LLM에서 베어메탈이 중요해졌을까?

일반적인 웹서비스는 CPU와 메모리가 조금 남더라도 큰 문제가 되지 않는다. 하지만 비싼 GPU가 놀고 있으면 곧바로 비용 문제가 된다.

LLM Serving의 성능은 GPU 연산량 하나만으로 결정되지 않는다.

GPU 메모리에 모델이 들어가는가
여러 GPU가 얼마나 빠르게 통신하는가
KV Cache를 얼마나 효율적으로 관리하는가
요청을 얼마나 잘 묶어서 처리하는가
첫 토큰을 얼마나 빨리 보여주는가
초당 몇 개의 토큰을 생성하는가

베어메탈의 핵심 장점은 단순히 “가상화가 없어서 빠르다”가 아니다.

GPU, 메모리, NVLink, 네트워크까지 하나의 성능 시스템으로 직접 설계하고 통제할 수 있다는 것이 진짜 장점이다.

LLM은 GPU 한 장으로 끝나지 않는다

모델이 GPU 한 장의 메모리에 들어가지 않으면 여러 GPU에 나눠야 한다.

대표적으로 다음 방법을 사용한다.

방식	개념	적합한 상황
Tensor Parallelism	하나의 연산을 여러 GPU가 나눠 수행	한 서버 안의 고속 GPU 연결
Pipeline Parallelism	모델의 층을 여러 GPU나 서버에 나눔	모델이 한 서버에도 들어가지 않을 때
Data Parallelism	같은 모델을 여러 GPU에 복제	동시 요청이 많을 때
Expert Parallelism	MoE 모델의 전문가 영역을 분산	대규모 MoE 모델

vLLM은 단일 서버의 멀티 GPU부터 여러 서버에 걸친 Tensor·Pipeline·Data Parallel 구성을 지원한다. vLLM 병렬화 공식 문서

여기서 중요한 사실이 하나 드러난다.

GPU의 개수보다 중요한 것은 GPU 사이의 거리다.

같은 서버 안에서 NVLink로 연결된 GPU와 서로 다른 서버에서 일반 네트워크로 연결된 GPU는 같은 8장이라도 전혀 다른 성능을 낼 수 있다. LLM 인프라는 이제 서버 수량이 아니라 GPU 토폴로지를 설계하는 문제에 가까워지고 있다.

응답 속도보다 처리량이 더 중요할 수도 있다

LLM Serving에서는 “몇 초 만에 답했는가”만 봐서는 안 된다.

대표적인 지표는 다음과 같다.

TTFT(Time to First Token): 첫 글자가 나오기까지 걸린 시간
TPOT(Time per Output Token): 이후 토큰 하나를 만드는 시간
Throughput: 일정 시간 동안 처리한 전체 토큰 또는 요청 수
Concurrency: 동시에 처리할 수 있는 사용자 수
GPU Utilization: GPU가 실제로 일한 비율

사용자 한 명에게 가장 빠른 시스템과 사용자 천 명을 효율적으로 처리하는 시스템은 설계가 다르다.

예를 들어 요청을 하나씩 즉시 처리하면 개인 응답은 빠를 수 있지만 GPU의 병렬 처리 능력을 충분히 활용하지 못한다. 반대로 여러 요청을 배치로 묶으면 전체 처리량은 높아지지만 일부 사용자는 더 기다릴 수 있다.

따라서 좋은 LLM Serving은 단순한 속도 경쟁이 아니라 다음 균형을 맞추는 일이다.

text

사용자가 느끼는 속도
       ↕
동시에 처리하는 요청 수
       ↕
GPU 한 장당 운영 비용

베어메탈이 항상 정답은 아니다

베어메탈은 성능 통제력이 높은 대신 운영 책임도 커진다.

베어메탈의 장점	베어메탈의 부담
물리 GPU를 독점적으로 사용	초기 장비 구매 비용
GPU 연결 구조를 직접 최적화	드라이버·CUDA 관리
성능 예측이 비교적 안정적	장애 장비 교체 책임
장기 고사용률에서 비용 효율 가능	사용량이 적어도 장비 비용 발생
보안·데이터 위치 통제	증설 속도가 느림

그래서 다음과 같이 판단할 수 있다.

베어메탈이 유리한 경우

GPU 사용량이 장기간 일정하게 높다.
금융·공공·의료처럼 데이터 외부 반출이 어렵다.
응답 지연과 성능 편차에 민감하다.
여러 GPU의 고속 연결이 중요하다.
장비와 플랫폼을 운영할 전문 인력이 있다.

클라우드 GPU가 유리한 경우

서비스 규모와 사용량을 아직 예측하기 어렵다.
실험과 모델 변경이 잦다.
짧은 기간에 많은 GPU가 필요하다.
초기 투자보다 빠른 출시가 중요하다.

실무에서는 개발과 검증은 클라우드에서 시작하고, 사용량이 안정된 핵심 서비스는 베어메탈로 이전하는 혼합 전략도 많이 고려한다.

가장 중요한 인사이트

과거의 일반적인 서버 운영에서는 애플리케이션이 하드웨어를 몰라도 괜찮았다. 가상화와 클라우드는 개발자를 물리 장비로부터 멀어지게 했다.

하지만 LLM Serving에서는 다시 다음을 알아야 한다.

모델의 크기와 정밀도
GPU 메모리 용량
KV Cache 사용량
GPU 간 연결 방식
네트워크 대역폭
요청의 길이와 동시 사용자 수
토큰 생성 속도와 비용

즉, AI 시대의 서버 개발자는 다시 하드웨어를 이해해야 한다.

베어메탈 GPU LLM Serving은 단순히 AI를 물리 서버에서 실행한다는 뜻이 아니다. 모델과 하드웨어를 하나의 제품처럼 함께 설계하는 방식이다.

결국 좋은 LLM 서비스는 가장 비싼 GPU를 많이 산다고 만들어지지 않는다.

어떤 모델을, 어떤 GPU에, 어떻게 나누어 올리고, 사용자의 요청을 어떤 방식으로 묶어 처리할 것인가.

이 질문에 제대로 답하는 것이 베어메탈 GPU LLM Serving의 본질이다.

베어메탈 GPU LLM Serving: AI가 다시 ‘하드웨어’를 보기 시작한 이유

중년개발자