LLM이 돌아가는 구조 — GPU부터 양자화까지

ChatGPT를 쓸 때 "이거 서버에서 뭐가 돌아가는 거지?"라는 궁금증이 든 적이 있다면, 이 글이 그 답입니다. 트랜스포머, 어텐션, CUDA, PyTorch, PTX, 양자화 — 이 단어들이 어떻게 연결되는지를 한 번에 정리합니다. 교과서적 정의를 나열하는 게 아니라, 실제로 서비스가 돌아갈 때 각 요소가 어떤 역할을 하는지 흐름 중심으로 풀어봅니다.

전체 그림: 프롬프트 하나가 답변이 되기까지

사용자가 "오늘 날씨 어때?"를 입력하면, 내부적으로 이런 일이 벌어집니다:

[사용자 입력]
  → 토크나이저 (텍스트 → 숫자 시퀀스)
    → 트랜스포머 모델 (수십~수천억 파라미터)
      → GPU에서 행렬 연산 수만 회
        → 다음 토큰 확률 분포 출력
          → 샘플링 → 토큰 하나 생성
            → 반복 (자기회귀)
              → [답변 텍스트]

이 파이프라인의 모든 단계가 GPU 위에서 돌아갑니다. 그리고 각 단계의 속도와 비용을 결정하는 게 아래에서 다룰 기술들입니다.

트랜스포머: 왜 이게 전부의 기반인가

2017년 구글이 "Attention Is All You Need" 논문을 냈습니다. 그 전까지 시퀀스 처리의 대세였던 RNN/LSTM을 밀어내고, 지금은 GPT, Claude, Gemini, LLaMA까지 거의 모든 LLM이 이 구조를 씁니다.

트랜스포머가 이긴 이유는 단순합니다: 병렬화가 된다.

RNN은 토큰을 순서대로 처리해야 합니다. 1번 토큰 처리가 끝나야 2번을 볼 수 있는 직렬 구조입니다. GPU는 "같은 연산을 수천 개 동시에" 하는 데 최적화된 하드웨어인데, RNN은 그 특성을 못 씁니다.

트랜스포머는 다릅니다. 입력 시퀀스 전체를 한 번에 보고, 모든 토큰 간의 관계를 동시에 계산합니다. GPU에 딱 맞는 구조입니다. 이게 학습 속도를 극적으로 올렸고, 모델을 키울 수 있게 해줬습니다.

어텐션: "어디를 볼 것인가"의 메커니즘

트랜스포머의 핵심 연산이 Self-Attention입니다.

쉽게 말하면, 문장 내의 모든 단어가 다른 모든 단어를 "참조"하면서 **"지금 이 단어를 생성할 때 어디를 가장 많이 봐야 하는가"**를 계산하는 것입니다.

"은행에서 돈을 입금했다"와 "강둑 위 은행나무"에서 "은행"의 의미가 다릅니다. 어텐션은 주변 단어들과의 관계를 보고 "이 맥락에서 은행 = 금융기관"이라는 걸 파악합니다.

수학적으로는:

Attention(Q, K, V) = softmax(QK^T / √d) × V

Q(Query), K(Key), V(Value) 모두 행렬입니다. 이 행렬 곱셈이 모델의 파라미터 수만큼 반복됩니다. GPT-4급이면 이 연산이 수천억 번 일어납니다. 그래서 GPU가 필수입니다.

어텐션의 계산량은 시퀀스 길이의 제곱에 비례합니다. 토큰이 1000개면 1,000,000번의 비교가 필요합니다. 이게 "긴 컨텍스트가 비싼 이유"이고, Flash Attention 같은 최적화가 중요한 이유입니다.

CUDA: GPU를 범용 연산에 쓰는 방법

GPU는 원래 게임 그래픽용이었습니다. 수천 개의 픽셀을 동시에 계산하도록 만들어진 칩입니다. NVIDIA가 2007년에 "이 병렬 연산 능력을 그래픽 말고 다른 데도 쓸 수 있게 해주겠다"고 내놓은 게 CUDA입니다.

CUDA가 하는 일은 **"이 함수를 수천 개의 스레드에서 동시에 실행해라"**를 GPU에게 지시하는 프로그래밍 모델입니다.

트랜스포머의 행렬 곱셈, 어텐션 계산, 활성화 함수 모두 "같은 연산을 대량의 데이터에 동시 적용"하는 패턴입니다. GPU와 CUDA가 LLM에 필수인 이유가 여기 있습니다.

일반 개발자가 CUDA를 직접 쓸 일은 드뭅니다. 대부분은 PyTorch 같은 프레임워크가 내부적으로 CUDA를 호출해주니까요. 하지만 "왜 LLM에 NVIDIA GPU가 필수인가?"를 이해하려면 이 계층을 알아야 합니다.

PTX: GPU의 어셈블리어

CUDA 코드를 컴파일하면 최종적으로 GPU에서 실행되는 건 PTX라는 중간 표현입니다. CPU 세계에서 C 코드가 x86 어셈블리로 변환되는 것처럼, CUDA 코드는 PTX로 변환됩니다.

CUDA C/C++ → (nvcc 컴파일러) → PTX → (GPU 드라이버) → 실제 GPU 명령어

왜 이게 중요할까요? GPU 아키텍처(Ampere, Hopper, Blackwell)마다 실제 명령어가 다른데, PTX가 중간 계층 역할을 해서 하나의 CUDA 코드가 여러 세대 GPU에서 돌아갈 수 있게 해줍니다.

앞서 다룬 CUDA Agent 논문에서 "AI가 CUDA 커널을 최적화한다"는 건, 결국 이 PTX 레벨에서 더 효율적인 명령어 패턴을 만들어내는 것을 포함합니다.

일반적인 LLM 서비스 운영에서 PTX를 직접 볼 일은 없습니다. 하지만 "내 GPU에서 모델이 느린데 왜?"를 깊이 파고들면 결국 PTX 레벨의 occupancy(GPU 활용률), register 사용량 같은 이야기로 내려가게 됩니다.

PyTorch: 이 모든 것을 연결하는 프레임워크

연구자가 "트랜스포머 모델을 만들자"고 했을 때, CUDA를 직접 짜지 않습니다. PyTorch로 짭니다.

PyTorch의 역할:

계층	하는 일
사용자 코드 (Python)	모델 구조 정의, 학습 루프, 데이터 처리
PyTorch 내부	자동 미분(Autograd), 텐서 연산, 메모리 관리
백엔드	cuBLAS(행렬곱), cuDNN(딥러닝 연산), NCCL(멀티GPU) 호출
GPU	CUDA 커널 실행

사용자는 Python으로 y = model(x) 한 줄을 쓰지만, 내부에서는 수백 개의 CUDA 커널이 GPU에서 순차/병렬로 실행됩니다.

torch.compile은 PyTorch 2.0에서 추가된 기능으로, 사용자 코드를 분석해서 더 효율적인 CUDA 커널 호출 패턴으로 자동 최적화합니다. CUDA Agent 논문에서 "torch.compile을 이겼다"는 건, 이 자동 최적화보다 LLM이 더 좋은 커널을 만들어냈다는 의미입니다.

추론(Inference)은 학습(Training)과 왜 다른가

LLM 서비스에서 사용자가 체감하는 건 추론 속도입니다. 학습은 이미 끝난 상태니까요.

구분	학습 (Training)	추론 (Inference)
목적	파라미터 업데이트	입력 → 출력 생성
방향	Forward + Backward	Forward만
배치	대형 배치 (GPU 활용 극대화)	작은 배치 또는 단일 요청
병목	연산량 (compute-bound)	메모리 대역폭 (memory-bound)
비용	한 번 (수백만 달러)	매 요청마다 (서빙 비용)

추론이 memory-bound인 이유는, 자기회귀 생성에서 토큰을 하나씩 뽑을 때 매번 전체 모델의 파라미터를 GPU 메모리에서 읽어야 하기 때문입니다. 연산량보다 "메모리에서 데이터를 얼마나 빨리 가져오는가"가 병목이 됩니다.

이게 아래에서 다룰 양자화의 동기입니다. 파라미터 크기를 줄이면 메모리 대역폭 병목이 완화됩니다.

경량화와 양자화: 거대한 모델을 현실적으로 서빙하기

GPT-4급 모델은 파라미터가 수천억 개입니다. 각 파라미터가 16비트(FP16)라면, 모델 하나를 메모리에 올리는 데만 수백 GB가 필요합니다. A100 GPU 한 장의 메모리가 80GB니까, GPU 여러 장을 묶어야 합니다.

이 문제를 해결하는 접근이 경량화이고, 가장 대표적인 기법이 **양자화(Quantization)**입니다.

양자화란

파라미터의 숫자 정밀도를 낮추는 것입니다.

FP32 (32비트) → FP16 (16비트) → INT8 (8비트) → INT4 (4비트)

정밀도	파라미터당 크기	70B 모델 메모리	품질 영향
FP32	4 bytes	~280 GB	기준
FP16	2 bytes	~140 GB	거의 차이 없음
INT8	1 byte	~70 GB	미미한 품질 저하
INT4	0.5 byte	~35 GB	눈에 띄는 저하 가능

INT4까지 가면 70B 모델이 35GB로 줄어 A100 한 장에 올라갑니다. GPU 수가 줄어드니 서빙 비용이 반 이하로 떨어집니다.

양자화의 트레이드오프

공짜 점심은 없습니다.

장점: 메모리 감소, 추론 속도 향상, GPU 비용 절감
단점: 수치 정밀도 손실로 품질 저하 가능. 특히 수학, 코딩, 논리 추론에서 민감

실무에서는 INT8 양자화가 황금 비율이라는 게 업계 공감대입니다. FP16 대비 메모리 절반, 속도 1.5~2배, 품질 저하는 대부분의 태스크에서 인지 불가 수준입니다.

GPTQ, AWQ, GGUF: 양자화 포맷

포맷	특징	용도
GPTQ	GPU 추론 최적화. 가중치만 양자화	서버 배포
AWQ (Activation-aware)	활성화 분포 고려한 가중치 양자화. GPTQ보다 정확	서버 배포
GGUF (llama.cpp)	CPU/GPU 혼합 추론. 개인 PC에서도 구동	로컬 추론, 엣지
bitsandbytes	PyTorch 네이티브. NF4 등	학습 시 메모리 절약 (QLoRA)

LLaMA 3 70B를 개인 PC에서 돌리는 사람들이 있습니다. GGUF + INT4 양자화로 35GB까지 줄이면, 48GB VRAM GPU(RTX 4090 등) 한 장에 올라갑니다. 물론 INT4까지 가면 "원본 모델"과 동일한 품질은 아니지만, "로컬에서 70B를 돌린다"는 것 자체가 2년 전에는 불가능한 일이었습니다.

MoE: 파라미터는 크게, 연산은 적게

Mixtral, GPT-4(추정), DeepSeek — 최근 대형 모델들이 채택하는 아키텍처가 MoE입니다.

핵심 아이디어는, 파라미터가 수백억~수조 개 있지만 하나의 토큰을 처리할 때 전체의 일부(Expert)만 활성화한다는 것입니다.

총 파라미터: 230B
활성 파라미터: 23B (한 번에 8개 Expert 중 2개만 사용)

결과적으로 큰 모델의 지식 용량은 유지하면서, 추론 비용은 작은 모델 수준으로 유지할 수 있습니다. CUDA Agent 논문의 베이스 모델(Seed1.6)도 이 구조입니다. 총 230B인데 활성은 23B입니다.

서빙 인프라: 실제 서비스에서는 어떻게 돌아가나

ChatGPT, Claude, Gemini 같은 서비스의 백엔드 구조는 이렇습니다:

[로드 밸런서]
  → [추론 서버 클러스터]
      ├── GPU 노드 1: 모델 파라미터 샤딩 (Tensor Parallel)
      ├── GPU 노드 2: 모델 파라미터 샤딩
      └── GPU 노드 N: ...
          ↓
      [vLLM / TensorRT-LLM / TGI]
        - KV Cache 관리
        - Continuous Batching
        - PagedAttention

핵심 기술들:

기술	하는 일
Tensor Parallelism	하나의 모델을 여러 GPU에 쪼개서 분산
KV Cache	이전 토큰의 Key/Value를 캐시해서 재계산 방지
Continuous Batching	여러 사용자의 요청을 동적으로 배치해서 GPU 활용률 극대화
PagedAttention	KV Cache를 OS의 가상 메모리처럼 페이지 단위로 관리. 메모리 낭비 방지

vLLM, TensorRT-LLM(NVIDIA), TGI(Hugging Face) 같은 프레임워크가 이 최적화들을 구현하고 있습니다. "모델을 학습시키는 것"과 "모델을 서비스로 돌리는 것"은 완전히 다른 엔지니어링입니다.

추론 서빙에서 가장 비싼 자원은 GPU 메모리입니다. KV Cache가 시퀀스 길이에 비례해서 커지므로, 긴 대화를 하면 할수록 메모리가 차오릅니다. "컨텍스트 윈도우 128K"라고 써놓은 모델이 실제 서비스에서는 비용 문제로 긴 컨텍스트를 꺼리는 이유가 여기 있습니다.

정리: 스택 전체 조감도

사용자 프롬프트
  ↓
[토크나이저] → 텍스트를 토큰 ID 시퀀스로 변환
  ↓
[트랜스포머 모델]
  ├── Self-Attention (어텐션 계산 — Q×K^T/√d × V)
  ├── FFN (Feed-Forward Network)
  └── MoE Router (해당하는 Expert만 활성화)
  ↓
[PyTorch / 추론 프레임워크]
  ├── torch.compile / TensorRT 그래프 최적화
  ├── cuBLAS (행렬곱 CUDA 커널)
  └── Flash Attention (메모리 효율 어텐션 커널)
  ↓
[CUDA Runtime]
  ↓
[PTX → GPU 명령어 → SM에서 실행]
  ↓
[GPU 하드웨어] — NVIDIA H100 / A100 / B200 등

계층	관심 주체	최적화 키워드
모델 아키텍처	AI 연구자	Attention 변형, MoE, 아키텍처 탐색
프레임워크	ML 엔지니어	양자화, 배치 최적화, KV Cache
CUDA 커널	시스템 엔지니어	커널 퓨전, 메모리 접근 패턴, occupancy
하드웨어	NVIDIA	칩 설계, HBM 대역폭, NVLink

마치며

이 글에서 다룬 걸 한 문단으로 압축하면 이렇습니다.

트랜스포머가 모델의 뼈대이고, 어텐션이 그 핵심 연산이며, 이 연산을 빠르게 돌리려면 GPU가 필요하고, GPU를 프로그래밍하는 체계가 CUDA입니다. 그 위에서 개발자가 편하게 모델을 만들 수 있게 해주는 게 PyTorch이며, 거대한 모델을 현실적인 비용으로 서빙하기 위해 양자화와 경량화를 적용합니다.

각 레이어에서 1%의 효율을 개선하면, 그게 수천만 사용자의 서비스에서는 수백만 달러의 비용 차이로 이어집니다. 결국 LLM 서비스의 경쟁력은 "모델이 얼마나 똑똑한가"만큼이나 "이 인프라를 얼마나 효율적으로 돌리는가"에 달려 있습니다. OpenAI, Anthropic, Google 모두 모델 연구만큼 인프라 최적화에 인력을 태우는 이유가 여기 있습니다.

LLM이 돌아가는 구조 — GPU부터 양자화까지 ​

전체 그림: 프롬프트 하나가 답변이 되기까지 ​

트랜스포머: 왜 이게 전부의 기반인가 ​

어텐션: "어디를 볼 것인가"의 메커니즘 ​

CUDA: GPU를 범용 연산에 쓰는 방법 ​

PTX: GPU의 어셈블리어 ​

PyTorch: 이 모든 것을 연결하는 프레임워크 ​

추론(Inference)은 학습(Training)과 왜 다른가 ​

경량화와 양자화: 거대한 모델을 현실적으로 서빙하기 ​

양자화란 ​

양자화의 트레이드오프 ​

GPTQ, AWQ, GGUF: 양자화 포맷 ​

MoE: 파라미터는 크게, 연산은 적게 ​

서빙 인프라: 실제 서비스에서는 어떻게 돌아가나 ​

정리: 스택 전체 조감도 ​

마치며 ​