기업이 LLM을 실제 서비스에 적용하려면 반드시 추론(Inference)과 서빙(Serving) 단계를 거쳐야 해요. 아무리 뛰어난 모델을 학습시켜도 이를 효율적으로 서비스하지 못하면 실질적인 비즈니스 가치를 창출할 수 없어요. 이 가이드에서는 LLM 추론의 원리부터 서빙 아키텍처, 필수 하드웨어, 그리고 비용 최적화 전략까지 정리해 드릴게요.

LLM 추론이란 무엇인가요?

LLM 추론(Inference)은 이미 학습이 완료된 대규모 언어 모델에 새로운 입력(프롬프트)을 넣고, 그에 대한 답변(텍스트)을 생성하는 과정이에요. 학습이 '수개월 동안 공부하는 과정'*이라면, 추론은 '공부를 끝낸 모델이 시험장에서 실제 문제를 푸는 과정'*이라고 볼 수 있어요.

추론의 가장 중요한 특징은 학습 때처럼 가중치를 변경하지 않고, 이미 배운 가중치를 그대로 사용한다는 점이에요. 대신, 새로운 입력에 대해 "다음에 올 단어(토큰)는 무엇일까?"를 계속 예측해서 문장을 만들어 내죠. 이러한 방식을 오토리그레시브(Autoregressive) 추론이라고 부르고 있어요.

학습과 추론의 차이점은 무엇인가요?

학습과 추론은 LLM 생명주기의 완전히 다른 단계예요. **학습(Training)**은 모델이 언어 패턴을 익히는 과정으로, 순전파와 역전파를 거쳐 가중치를 업데이트해요. **추론(Inference)**은 학습이 완료된 모델의 가중치를 그대로 사용하여 새로운 입력에 대한 출력을 생성해요.

학습이 '대학에서 공부하는 시간'이라면, 추론은 '졸업 후 평생 하는 실제 업무'에 해당해요. 학습은 한 번 크게 투자하는 과정이지만, 추론은 서비스가 운영되는 동안 계속해서 발생하므로 비용 최적화가 핵심이에요.

LLM 서빙(Serving)이란 무엇인가요?

LLM 서빙(Serving)은 LLM 추론을 외부 서비스(웹/앱)에서 사용할 수 있도록 API 서버로 제공하는 것이에요. 단순히 모델을 로컬에서 실행하는 게 아니라, 다수의 사용자가 동시에 접속해도 안정적으로 응답할 수 있는 인프라를 구축하는 게 서빙의 핵심이에요.

서빙의 기본 구조는 간단해요. 사용자가 웹/앱에서 질문 입력 → API 서버가 요청을 받아 LLM 추론 서버로 전달 → GPU 위에서 LLM이 토큰을 하나씩 생성 → 결과를 API 서버 → 사용자에게 전송하는 흐름이에요. 카카오, 토스 등 국내 기업들도 Llama 3 8B 같은 모델을 vLLM, TensorRT-LLM 등 서빙 프레임워크로 배포해 서비스하고 있어요.

LLM 추론은 내부적으로 어떻게 동작하나요?

사용자가 *"오늘 서울 날씨 어때?"*라고 질문했을 때, LLM 내부에서는 어떤 일이 벌어지는지 단계별로 살펴볼게요.

1단계: 입력 전처리 및 토큰화

먼저 사용자의 문장을 토큰 단위로 분리해요. *"오늘 서울 날씨 어때?"*는 ["오늘", "서울", "날씨", "어때", "?"]와 같이 캠개지고, 각 토큰은 토크나이저에 의해 고유한 숫자 ID로 변환돼요. 토큰 수가 많을수록 추론 비용이 증가해요.

2단계: 임베딩 + 위치 인코딩

각 토큰 ID는 **임베딩 행렬(Embedding Matrix)**을 통해 고차원 벡터(예: 4096차원)로 변환돼요. 그 다음 **위치 인코딩(Positional Encoding)**을 더해서 각 토큰의 순서 정보를 반영해요. Transformer는 기본적으로 순서를 인식하지 못하기 때문에, *"나는 밥을 먹었다"와 "밥을 나는 먹었다"*를 구분하려면 위치 정보가 필수예요.

3단계: 프리필(Prefill) — 입력 전체를 한 번에 처리

프리필은 입력 프롬프트 전체를 한 번에 Transformer에 통과시키는 단계예요. 이 단계에서 모든 입력 토큰이 서로를 참조하는 Self-Attention 연산을 수행해요. 프리필 단계에서는 대규모 행렬×행렬 연산이 집중적으로 일어나며, GPU의 Tensor Core가 최대한 활용돼요. 즉 GPU 연산 성능(FLOPS)이 프리필 속도를 결정해요.

프리필 과정에서 각 토큰에 대한 **Key(K)와 Value(V)**를 계산해 KV 캐시에 저장해요. 이 캐시는 다음 디코드 단계에서 재사용되어 연산량을 크게 줄여줘요.

4단계: 디코드(Decode) — 토큰을 하나씩 생성

프리필이 끝나면, 모델은 첫 번째 출력 토큰을 만들 준비가 된 상태예요. 디코드 단계에서는 이 과정이 반복돼요: 다음 토큰 확률 계산 → 토큰 샘플링 → KV 캐시 업데이트 → 반복. 디코드 단계의 핵심 특징은 매 토큰마다 전체 시퀀스를 다시 계산할 필요가 없다는 점이에요. KV 캐시 덕분에 새 토큰에 해당하는 연산만 수행하면 돼요. 다만 이 단계는 행렬×벡터 연산 위주이고 KV 캐시를 자주 읽어야 하므로, 메모리 대역폭이 병목이 돼요.

프리필 vs 디코드, 왜 나눠서 생각해야 하나요?

NVIDIA, Baseten, BentoML 모두 LLM 추론을 프리필과 디코드 두 단계로 나눠서 설명해요. 이 구분이 중요한 이유는 각 단계의 병목이 다르기 때문이에요.

실제 서비스에서는 프리필과 디코드 각각에 맞는 최적화를 적용해야 해요. 긴 문서 요약 작업은 프리필 비중이 높고, 대화형 챗봇은 디코드 비중이 높아요. 워크로드 특성에 따라 GPU 선택과 최적화 전략이 달라져야 해요.

서빙 아키텍처는 어떻게 구성되나요?

대부분의 LLM 서비스는 다음과 같은 구조로 동작해요.

클라이언트(웹/앱) → API Gateway / Web 서버(인증, 로깅, 라우팅, Rate Limiting 처리) → LLM 서빙 서버(vLLM, TensorRT-LLM, SGLang 등 서빙 프레임워크) → 백엔드 서비스 / RAG 파이프라인(옵션, 벡터DB·검색엔진 연계) → 모니터링 & 로깅(Grafana, Prometheus로 응답 속도, GPU 사용률, 에러율 관측).

서빙 성능 핵심 지표

LLM 서빙의 성공 여부는 세 가지 핵심 지표에 달려 있어요.

응답 지연시간(Latency)은 쵙밋이나 검색 서비스에서 수 초 내에 답변을 제공해야 해요. TTFT(Time To First Token)는 첫 번째 토큰이 나오기까지 걸리는 시간으로 프리필 속도에 좌우되고, TPS(Tokens Per Second)는 초당 생성되는 토큰 수로 디코드 속도를 나타내요.

동시 접속 처리량(Throughput)은 수백–수천 명의 사용자가 동시에 요청할 때도 안정적으로 처리해야 해요. 배칭, 연속 배칭, KV 캐싱 같은 기술이 필수적으로 적용돼요.

비용 효율성은 양자화(4bit/8bit), 작은 모델 + RAG 조합, 서빙 전용 GPU 선택(H100 대신 L4/A10G), 스팟 인스턴스 활용 등으로 최적화해요.

최적화된 서빙 프레임워크 사용 시 일반 Transformers 대비 처리량이 10–100배 향상돼요.

주요 LLM 서빙 프레임워크는 어떻게 비교되나요?

vLLM은 UC Berkeley에서 개발한 오픈소스로, PagedAttention이라는 혁신적인 메모리 관리 기법을 도입했어요. 이를 통해 KV 캐시를 페이지 단위로 관리해서 메모리 낭비를 크게 줄였죠. TensorRT-LLM은 NVIDIA가 직접 개발해 NVIDIA GPU에서 최고의 성능을 발휘하지만, 설정과 빌드 과정이 vLLM보다 복잡해요.

LLM 서빙에 필요한 GPU 메모리(VRAM)는 정확히 얼마인가요?

VRAM은 GPU에 탑재된 전용 메모리로, 모델 가중치와 추론 중 생성되는 중간 계산값(KV 캐시 등)을 저장해요. LLM 서빙에서 VRAM은 가장 중요한 제약 조건이며, VRAM이 부족하면 모델 자체를 로드할 수 없거나 Out of Memory(OOM) 오류가 발생해요.

핵심 공식

M = P × (Q ÷ 8) × 1.2

M은 필요한 GPU 메모리(GB), P는 모델 파라미터 수(B 단위), Q는 비트 정밀도(16bit, 8bit, 4bit), 1.2는 *20% 오버헤드(KV 캐싱, 중간 계산값, CUDA 시스템)*예요.

빠른 경험 법칙

Modal의 기술 문서에 따르면, FP16 정밀도로 로드되는 LLM은 파라미터 10억 개(1B)당 약 2GB의 GPU 메모리가 필요해요.

• FP16 (16bit): 1B 파라미터당 약 2GB

• INT8 (8bit): 1B 파라미터당 약 1GB

• INT4 (4bit): 1B 파라미터당 약 0.5GB

모델 크기별 VRAM 요구량

Llama 70B (FP16) 계산 예시: M = 70 × (16 ÷ 8) × 1.2 = 168GB. A100 80GB 단일 GPU로는 부족해서 A100 80GB × 2장 또는 H100 80GB × 2장이 필요해요.

Llama 70B (4bit 양자화): M = 70 × (4 ÷ 8) × 1.2 = 42GB. A10 24GB × 2장 또는 RTX 4090 24GB × 2장으로 서빙이 가능해요.

20% 오버헤드가 필요한 이유

공식의 1.2 배수에는 명확한 기술적 이유가 있어요. KV 캐시가 Self-Attention 연산에서 이전 토큰들의 Key와 Value를 저장하고(시퀀스가 길어지면 모델 가중치보다 더 많은 메모리 소모), Activation 메모리가 순전파 과정에서 생성되는 중간 계산값을 저장해요. 여기에 CUDA 커널 및 시스템 오버헤드, 메모리 단편화까지 고려해야 해요.

60GB 가중치가 필요한 LLM이 80GB GPU에서 안정적으로 동작하지 못하는 경우가 많아요. 긴 프롬프트, 높은 동시 접속, 멀티턴 대화에서 문제가 발생해요. 제한 요소는 가중치가 아니라 런타임 메모리 증가예요.

용도별 권장 GPU는 무엇인가요?

로컬 실험/프로토타입 개발: RTX 4070/4070 Ti(12GB)는 7B 모델 추론과 양자화된 13B까지 가능해요. RTX 4090(24GB)은 13B 모델 추론, 양자화된 30B까지 가능하고 개인 연구자에게 가성비가 최고예요.

워크스테이션/온프레미스: RTX 6000 Ada(48GB)는 65B 추론 및 다중 세션 서빙, ECC 메모리를 지원해요. RTX A6000(48GB)은 이전 세대지만 여전히 강력한 워크스테이션 GPU예요.

데이터센터/대규모 서빙: A100(40/80GB)은 데이터센터 표준으로 학습과 추론 모두 우수해요. H100(80GB)은 최신 Hopper 아키텍처로 A100 대비 2–3배 추론 성능을 보여줘요. L4(24GB)는 추론 특화, 전력 효율이 우수해서 클라우드에서 인기에요.

CPU, RAM, 네트워크, 스토리지는 어떻게 구성할까요?

GPU가 핵심이지만, 다른 구성 요소도 적절히 갖춰야 전체 시스템이 원활하게 동작해요.

CPU는 요청 처리, 토큰화, 데이터 전처리, 로깅, RAG용 DB 조회 등을 처리해요. DGX H100 기준 *2x Xeon Platinum 8480C (112코어)*처럼 다코어 서버 CPU를 사용해요.

시스템 RAM은 일반적으로 VRAM의 1.5–2배를 권장해요. 16GB VRAM GPU는 24–32GB RAM, 24GB VRAM GPU는 48GB RAM, 80GB VRAM GPU는 128GB 이상 RAM을 권장해요.

네트워크는 단일 GPU 서빙은 일반 1GbE/10GbE로 충분하지만, 멀티 GPU/멀티 노드 환경에서는 100GbE, 200–400Gb/s InfiniBand, NVLink 등 고속 네트워크가 필수예요.

스토리지(SSD)는 모델 체크포인트 파일이 수 GB–수백 GB이므로 NVMe SSD가 필수예요. Llama 70B FP16 기준 약 140GB, Llama 405B는 800GB에 달해요. 고성능 NVMe SSD(읽기 7,000MB/s 이상)를 권장해요.

추론을 빠르고 저렴하게 만드는 최적화 기법은?

양자화(Quantization)

양자화는 FP32/FP16 대신 INT8/INT4 같은 낮은 정밀도 숫자로 가중치를 표현하는 방법이에요. 메모리 사용량과 연산량을 크게 감소시켜요.

• 메모리 사용량: 2–4배 감소

• 처리 용량: 같은 GPU로 더 큰 모델 서빙 가능

• 추론 속도: 메모리 대역폭 병목 완화로 속도 향상

• 정확도 손실: 잘 튜닝하면 1–2% 이내

양자화 적용 예시를 보면, Llama 70B FP16은 약 140GB VRAM이 필요하지만, INT8은 70GB(H100 1장으로 가능), INT4는 35GB(A6000 1장으로 가능)로 줄어요.

KV 캐싱

LLM은 오토리그레시브 방식으로 토큰을 생성하므로, 원래라면 매 토큰 생성 시 전체 시퀀스를 처음부터 다시 계산해야 해요. 이는 엄청난 낭비예요.

KV 캐싱은 프리필 단계에서 계산한 Attention의 Key(K)와 Value(V)를 메모리에 저장해두고, 디코드 단계에서 새 토큰에 대해서만 Q/K/V를 계산하며 이전 토큰들은 캐시에서 재사용하는 기술이에요. 긴 대화나 문서 처리에서 토큰당 지연시간을 획기적으로 줄일 수 있어요.

연속 배칭(Continuous Batching)

배칭은 여러 사용자의 요청을 모아서 한 번에 GPU에 처리하는 방식이에요. 기존 정적 배칭은 가장 긴 요청이 끝날 때까지 다른 요청도 대기해야 해서 비효율적이었어요.

연속 배칭(Continuous Batching)은 들어오는 요청을 실시간으로 지능적으로 합치는 기술이에요. 완료된 요청을 즉시 배치에서 빼고, 새로운 요청을 바로 추가해서 GPU 활용률을 극대화해요. vLLM, TensorRT-LLM, TGI 같은 최신 서빙 엔진은 모두 연속 배칭을 지원해요.

추측 추론(Speculative Decoding)

추측 추론은 작고 빠른 드래프트 모델이 먼저 토큰을 여러 개 생성하고, 큰 메인 모델이 이를 검증/수정하는 방식이에요. 드래프트 모델의 예측이 맞으면 여러 토큰을 한 번에 확정할 수 있어서, 메인 모델만 사용할 때보다 2–4배 빠르게 토큰 생성이 가능해요.

실무 로드맵은 어떻게 세워야 할까요?

1단계 — 요구사항 분석. 서비스할 모델의 크기(7B, 13B, 70B 등), 예상 동시 사용자 수, 허용 가능한 응답 지연시간(TTFT, TPS)을 먼저 정의해요.

2단계 — GPU 선택. 모델 크기에 맞는 VRAM을 가진 GPU를 선택해요. 로컬 실험용은 RTX 4070/4090, 워크스테이션은 RTX 6000 Ada, 데이터센터는 A100/H100/L40S를 고려해요.

3단계 — 서빙 프레임워크 선택. vLLM은 빠른 프로토타입, TensorRT-LLM은 최고 성능, SGLang은 구조화된 출력에 강점이 있어요.

4단계 — 최적화 기법 적용. 양자화(VRAM 부족 시 INT8/INT4로 2–4배 절감), KV 캐싱(기본 활성화), 연속 배칭(자동 적용), 추측 추론(지연시간 중요 시 고려)을 순차로 적용해요.

5단계 — 인프라 구성. GPU 외에 CPU(다코어 서버급), RAM(VRAM의 1.5–2배), 네트워크(멀티 GPU 시 NVLink/InfiniBand), 스토리지(고성능 NVMe SSD)를 적절히 구성해요.

6단계 — 모니터링 및 튜닝. Grafana/Prometheus로 TTFT, TPS, GPU 사용률, VRAM 사용량, 에러율, 큐 대기 시간을 지속적으로 모니터링해요.

정리하자면

기업 AI 담당자가 기억해야 할 핵심은 열 가지예요.

첫째, LLM 추론은 학습 완료된 AI가 실시간으로 답변을 생성하는 과정이에요.

둘째, 추론은 순전파만 수행하고, 역전파와 가중치 업데이트가 없어요.

셋째, 내부적으로 프리필(입력 처리)과 디코드(토큰 생성) 두 단계로 구분돼요.

넷째, 프리필은 GPU 연산 성능, 디코드는 메모리 대역폭이 병목이에요.

다섯째, GPU는 대규모 행렬 연산을 병렬 처리해 CPU 대비 10–100배 효율적이에요.

여섯째, VRAM은 모델을 돌릴 수 있는지, 연산능력/대역폭은 얼마나 빠른지를 결정해요.

일곱째, 양자화(INT8/INT4)로 VRAM 요구량을 2–4배 줄일 수 있어요.

여덟째, KV 캐싱은 긴 시퀀스에서 연산량을 획기적으로 줄이는 필수 기술이에요.

아홉째, vLLM, TensorRT-LLM 같은 서빙 프레임워크로 10–100배 처리량 향상이 가능해요.

열째, 연속 배칭, 추측 추론 등 고급 기법으로 추가 최적화가 가능해요.

LLM 서빙 인프라를 고민 중이시라면, 엑스디노드에 편하게 문의해 주세요. 모델 크기와 요구 지연시간에 맞춰 최적의 GPU 서버 구성을 함께 제안드릴게요.