반달곰의 개발이야기

단일 GPU로 120B 모델 학습하는 법 - MegaTrain

반달bear — Thu, 11 Jun 2026 10:20:50 +0900

들어가며

100B급 모델을 학습한다고 생각해보겠습니다. 보통은 GPU 수십 장을 묶은 분산 학습을 떠올립니다. 가중치와 옵티마이저 상태만으로 GPU 한 장의 메모리를 크게 초과하기 때문입니다. 그런데 2026년에 공개된 MegaTrain은 H200 1장과 host RAM 1.5TB로 최대 120B 모델 학습을 주장합니다. 이 글에서는 학습에 필요한 메모리가 어떻게 구성되는지 계산해보고 MegaTrain이 단일 GPU로 이를 감당하는 방법을 알아보겠습니다.

1. 학습 메모리의 회계

학습에는 추론보다 훨씬 많은 메모리가 필요합니다. mixed-precision 학습 기준으로 파라미터 1개당 유지해야 하는 상태는 다음과 같습니다.

항목 정밀도 크기

weight	fp16	2 B
gradient	fp16	2 B
master weight	fp32	4 B
(Adam 모멘텀 2종)	fp32	8 B

모멘텀을 제외해도 파라미터당 8 B입니다. Adam까지 포함하면 16 B입니다. 120B 모델에 적용하면 weight만 240 GB이고 persistent state 전체는 약 887 GB입니다. Adam 포함 시 약 1.85 TB까지 늘어납니다. H200의 HBM은 141 GB이므로 단순 계산으로 GPU 7~13장이 필요합니다.

여기에 activation이 추가됩니다. forward 과정의 중간 결과는 backward에서 다시 쓰이므로 어딘가에 들고 있어야 합니다.

2. 메모리 계층과 offload의 기본 발상

GPU에 다 들어가지 않는 데이터를 다루는 공통 전략이 있습니다. 데이터를 메모리 계층에 나눠 두고 연산 직전에만 GPU로 끌어올리는 offload입니다. ZeRO-3 Offload, ZeRO-Infinity, FSDP, MegaTrain 모두 같은 발상에서 출발합니다.

계층 매체 용량 대역폭 역할

L1	GPU SRAM	수십 MB	~80 TB/s	연산 직전 캐시
L2	HBM	수십~수백 GB	TB/s 급	GPU 주력 작업 메모리
L3	host DDR5/LPDDR5X	TB 단위	수백 GB/s (HBM의 약 1/10)	대용량 보관
L4	NVMe	수십 TB	한 자리 GB/s	persistent storage

이 전략이 성립하는 근거는 학습 연산의 구조에 있습니다. forward와 backward는 레이어 단위로 순차 진행됩니다. 그래서 HBM에는 지금 연산 중인 레이어 1개분(120B 기준 약 10 GB)만 있으면 됩니다. 나머지 weight는 host RAM에 둡니다.

3. 기존 offload의 두 가지 한계

같은 발상의 ZeRO 계열이 이미 있는데 MegaTrain이 새로 필요한 이유는 두 가지입니다.

전송이 연산을 막습니다. host와 GPU 사이의 PCIe 대역폭은 HBM보다 훨씬 좁습니다. ZeRO는 전송을 하나의 레인이 모두 담당하는 구조라 backward에서 GPU가 데이터를 기다리며 유휴 상태로 머무는 시간이 커집니다. 게다가 작은 덩어리 다수로 나눠 보내기 때문에 PCIe 대역폭도 충분히 활용하지 못합니다.

activation은 레이어 단위로 쪼갤 수 없습니다. weight는 연산 중인 레이어 것만 있으면 되지만 activation은 다릅니다. backward가 끝날 때까지 전체 레이어의 중간 결과를 유지해야 합니다. ZeRO는 이 activation을 GPU에 남겨 둡니다. 그래서 모델이 32B를 넘으면 activation만으로 OOM이 발생합니다.

4. 해법 1: 3개 stream과 double-buffer

MegaTrain의 첫 번째 해법은 전송 시간을 연산 시간 뒤에 숨기는 것입니다. GPU가 데이터를 기다리며 유휴 상태로 머무는 시간을 제거합니다.

3개 CUDA stream: 연산(S_comp), 다음 레이어 weight 올리기(S_H2D), gradient 내리기(S_D2H)를 별도 stream으로 분리합니다. 올리기와 내리기가 서로를 막지 않습니다.
Double-buffer: 레이어 크기의 버퍼 2개를 둡니다. 연산 stream이 버퍼 0을 읽는 동안 전송 stream이 버퍼 1을 채웁니다. 두 버퍼를 번갈아 사용합니다.
Large-burst tiling: 레이어 하나의 상태를 큰 덩어리 한 번에 전송합니다. ZeRO의 잦은 소량 전송과 달리 PCIe 대역폭을 거의 포화시킵니다.

여기에 activation까지 host로 offload합니다. ZeRO가 GPU에 남겨 두던 activation을 같은 겹치기 방식으로 host에 내리고 올립니다. 32B에서 막히던 한계가 120B까지 늘어난 핵심 차이입니다.

5. 해법 2: Stateless Layer Template

두 번째 해법은 GPU 메모리 점유를 레이어 1개분으로 고정하는 장치입니다. 레이어의 데이터 스키마만 GPU에 상주시킵니다. streaming buffer로 도착한 데이터를 스키마에 동적으로 bind하고 연산한 뒤 unbind합니다. 레이어마다 별도의 메모리를 잡지 않으므로 모델이 커져도 GPU 메모리 사용량은 늘지 않습니다.

6. 성능과 적용 범위

논문이 제시하는 결과는 다음과 같습니다.

환경 결과

H200 1장 + host 1.5 TB	최대 120B 모델 학습
GH200 1장, 7B 모델	512K token context 학습
GH200 1장, 14B 모델	ZeRO-3 Offload 대비 1.84× throughput (264 vs 약 143 TFLOPS)

512K context 실험은 activation 병목을 보여주는 사례입니다. 7B 모델의 weight는 14 GB에 불과합니다. 그런데 context가 4,096에서 524,288 토큰으로 128배 늘면 activation이 폭증합니다. attention score는 시퀀스 길이의 제곱에 비례하기 때문입니다. weight가 아니라 activation이 병목인 상황도 offload로 해결할 수 있음을 보여줍니다.

적용 범위는 분명합니다. MegaTrain은 multi-GPU 분산 학습에는 아직 부적합합니다. 단일 GPU에 큰 모델을 올려야 하는 상황에 특화된 기법입니다. ZeRO-3가 OOM으로 막히는 30B 이상을 단일 GPU로 학습해야 한다면 현재로서는 유일한 선택지입니다.

정리

항목 내용

문제	120B 학습의 persistent state는 약 887 GB로 GPU 1장을 한참 초과
기본 전략	weight·activation을 host RAM에 두고 연산 직전에만 GPU로 올리는 offload
ZeRO의 한계	전송이 연산을 막고 activation을 GPU에 남겨 32B+에서 OOM
해법 1	3개 CUDA stream + double-buffer + large-burst로 전송을 연산에 겹침
해법 2	Stateless Layer Template로 GPU 점유를 레이어 1개분으로 고정
적용 범위	단일 GPU에 큰 모델. multi-GPU 분산에는 부적합

GPU 1장의 HBM 용량이 모델 크기를 결정하지 않는다는 점이 이 논문의 핵심입니다. 전송을 연산 뒤에 완전히 숨길 수 있다면 host RAM까지가 사실상의 학습 메모리가 됩니다.

출처

"MegaTrain: Full Precision Training of 100B+ Parameter Large Language Models on a Single GPU", arXiv:2604.05091 — https://arxiv.org/abs/2604.05091
코드: https://github.com/DLYuanGod/MegaTrain
사내 세미나 발표 정리 노트 (2026-05-20, 발표자: 진희솜)

LLM 서빙 prefill·decode 분리 (2) - 오케스트레이션 레이어

반달bear — Thu, 11 Jun 2026 09:37:18 +0900

들어가며

1편에서는 prefill과 decode를 왜 분리해야 하는지 살펴봤습니다. 둘을 분리하면 새 prefill 요청 때문에 decode가 멈추는 일을 줄일 수 있습니다. 대신 한 가지 일이 새로 필요합니다. prefill 워커가 만든 KV 캐시를 decode 워커로 옮겨야 합니다.

분리된 워커는 따로 실행하는 것만으로 충분하지 않습니다. 요청을 어느 워커로 보낼지 정해야 합니다. prefill 워커와 decode 워커의 수를 따로 조절해야 합니다. KV 캐시도 워커 사이로 옮겨야 합니다. 이 일을 맡는 층을 오케스트레이션 레이어라고 합니다.

이 글에서는 대표적인 오케스트레이션 레이어 두 가지를 비교합니다. 하나는 NVIDIA가 만든 Dynamo입니다. 다른 하나는 Kubernetes 기반의 llm-d입니다.

1. 오케스트레이션 레이어가 하는 일

prefill과 decode를 분리하면 관리해야 할 일이 세 가지로 늘어납니다.

첫째는 라우팅입니다. 들어온 요청을 어느 워커로 보낼지 정해야 합니다.

둘째는 스케일링입니다. prefill 워커와 decode 워커를 각각 몇 개씩 둘지 정해야 합니다. 입력이 긴 요청이 많으면 prefill 쪽이 더 바빠집니다. 출력이 긴 요청이 많으면 decode 쪽이 더 바빠집니다. 그래서 두 워커의 비율은 계속 바뀝니다.

셋째는 전송입니다. prefill 워커가 만든 KV 캐시를 decode 워커로 옮겨야 합니다. 이 전송이 느리면 분리로 얻은 이득이 사라집니다.

오케스트레이션 레이어는 이 세 가지를 자동으로 처리합니다. Dynamo와 llm-d는 같은 문제를 서로 다른 계층에서 해결합니다.

2. NVIDIA Dynamo

Dynamo는 NVIDIA가 만든 추론 전용 프레임워크입니다. prefill 워커와 decode 워커를 나누고 요청 라우팅과 KV 캐시 전송까지 함께 다룹니다. 아래 그림이 전체 구조입니다.

2-1. prefill 워커와 decode 워커를 나눈다

Dynamo는 prefill 워커와 decode 워커를 서로 다른 서비스로 둡니다. prefill 워커는 프롬프트 처리를 맡습니다. decode 워커는 토큰 생성을 맡습니다. 두 워커는 따로 늘리고 줄일 수 있습니다.

2-2. KV-aware Router

KV-aware Router는 요청을 알맞은 워커로 보내는 부분입니다. 보통의 로드밸런서는 부하가 낮은 워커를 고릅니다. KV-aware Router는 한 가지를 더 봅니다. 어느 decode 워커가 이미 관련 KV 캐시를 들고 있는지 확인합니다. 그리고 가능한 한 그 워커로 요청을 보냅니다. 이렇게 하면 같은 KV 캐시를 다시 만들지 않아도 됩니다.

2-3. GPU Planner

GPU Planner는 prefill 워커와 decode 워커의 비율을 정하는 부분입니다. GPU 사용 패턴을 계속 봅니다. 입력이 긴 요청이 많으면 prefill 워커를 늘립니다. 출력이 긴 요청이 많으면 decode 워커를 늘립니다.

2-4. NIXL

NIXL은 KV 캐시를 워커 사이로 옮기는 전송 라이브러리입니다. 정식 이름은 NVIDIA Inference Xfer Library입니다.

KV 캐시는 크기가 큽니다. 그래서 전송이 느리면 분리로 얻은 이득이 줄어듭니다. 그런데 워커를 잇는 연결은 환경마다 다릅니다. 같은 서버 안의 GPU는 NVLink로 연결될 수 있습니다. 다른 서버의 GPU는 InfiniBand로 연결될 수 있습니다. 그 밖에 PCIe나 SSD도 경로에 들어갈 수 있습니다.

NIXL은 이렇게 다른 연결을 하나의 방식으로 다룹니다. 그래서 상위 코드는 연결 종류를 직접 다루지 않고 KV 캐시 전송을 요청할 수 있습니다.

실제 추론은 Dynamo가 직접 하지 않습니다. TensorRT-LLM과 vLLM 그리고 SGLang 같은 엔진을 백엔드로 씁니다.

3. llm-d

llm-d는 Kubernetes 위에서 동작하는 추론 플랫폼입니다. 목표는 여러 종류의 GPU가 섞여 있고 여러 사용자가 함께 쓰는 클라우드 환경에서 prefill과 decode 분리를 운영하는 것입니다. 아래 그림이 전체 구조입니다.

3-1. Inference Gateway

Inference Gateway는 요청이 가장 먼저 도착하는 입구입니다. Kubernetes의 표준 Gateway를 추론에 맞게 확장한 것입니다.

보통의 Gateway는 HTTP 경로나 헤더를 보고 라우팅합니다. Inference Gateway는 여기에 추론 정보를 더 봅니다. 요청이 어떤 모델을 부르는지 확인합니다. 관련 KV 캐시가 어디에 있는지도 확인합니다.

3-2. Inference Scheduler

Inference Scheduler는 요청을 어느 pod로 보낼지 정하는 부분입니다. 먼저 각 pod의 상태를 모읍니다. 다음으로 각 pod에 점수를 매깁니다. 마지막으로 부적합한 pod를 걸러냅니다.

이 과정에서 워커의 부하를 봅니다. 관련 KV 캐시가 어디에 있는지도 봅니다. 요청이 prefill인지 decode인지도 함께 고려합니다.

3-3. LeaderWorkerSet

LeaderWorkerSet은 여러 pod를 하나의 단위로 다루는 도구입니다. 큰 모델은 GPU 하나에 모두 올라가지 않습니다. 그래서 여러 노드에 나눠서 실행해야 합니다. 이때 여러 pod가 하나의 단위로 함께 동작합니다.

llm-d는 prefill 그룹과 decode 그룹을 각각 하나의 LeaderWorkerSet으로 관리합니다.

3-4. Variant Autoscaler

Variant Autoscaler는 prefill 워커와 decode 워커의 수를 자동으로 조절하는 부분입니다. 판단 기준이 일반적인 오토스케일러와 다릅니다. CPU나 메모리 사용량만 보지 않습니다. KV 캐시 사용률과 큐 길이를 봅니다. 앞에서 본 TTFT와 TPOT도 함께 봅니다.

3-5. 이기종 GPU를 섞어 쓴다

llm-d는 한 클러스터에 여러 종류의 가속기를 섞어 둘 수 있습니다. 예를 들어 NVIDIA H100과 Google TPU와 AMD MI300X를 함께 쓸 수 있습니다. prefill은 연산 성능이 강한 장비에 배치할 수 있습니다. decode는 메모리 대역폭이 큰 장비에 배치할 수 있습니다.

4. 둘은 무엇이 다른가

Dynamo와 llm-d는 같은 일을 합니다. 둘 다 prefill 워커와 decode 워커를 나눕니다. 둘 다 KV 캐시 위치를 보고 라우팅합니다. 둘 다 두 워커를 따로 스케일링합니다.

차이는 기반 계층입니다. Dynamo는 추론 전용 프레임워크입니다. NVIDIA 하드웨어에서 높은 성능을 내는 데 집중합니다. llm-d는 Kubernetes 위에 올라갑니다. 일반적인 클라우드 운영 방식과 잘 맞게 만드는 데 집중합니다.

주도	NVIDIA	Red Hat·Google·IBM
기반	추론 전용 프레임워크	Kubernetes 네이티브 플랫폼
설정 방식	프레임워크 구성	Kubernetes manifest
강점	NVIDIA 하드웨어 최적화·성능	클라우드 운영·멀티테넌트
잘 맞는 환경	대규모 NVIDIA GPU 클러스터	여러 GPU가 섞인 일반 클라우드

정리

오케스트레이션 레이어는 분리된 워커를 관리합니다. 요청을 알맞은 워커로 보냅니다. 워커 수를 워크로드에 맞춰 조절합니다. KV 캐시를 워커 사이로 옮깁니다.

Dynamo와 llm-d는 이 일을 서로 다른 방식으로 해결합니다. Dynamo는 NVIDIA 하드웨어 성능에 집중합니다. llm-d는 Kubernetes 운영에 집중합니다. 두 방식 모두 prefill과 decode 분리를 전제로 설계되어 있습니다.

이 레이어 아래에는 또 다른 층이 있습니다. KV 캐시를 어디에 저장하고 어떻게 여러 워커가 나눠 쓰는지를 다루는 스토리지 레이어입니다. LMCache와 Mooncake가 대표적입니다. 이 주제는 다음 기회에 따로 다루겠습니다.

출처

Hao AI Lab, "Disaggregated Inference: 18 Months Later" — https://haoailab.com/blogs/distserve-retro/
NVIDIA Dynamo — https://github.com/ai-dynamo/dynamo · docs
llm-d — https://llm-d.ai/

LLM 서빙 prefill·decode 분리 (1) - 분리의 이유

반달bear — Thu, 11 Jun 2026 09:33:58 +0900

들어가며

LLM 추론 서버는 두 가지 일을 합니다. 하나는 사용자가 보낸 프롬프트를 읽는 일입니다. 다른 하나는 답변 토큰을 하나씩 만들어 내보내는 일입니다. 앞의 일을 prefill이라고 부릅니다. 뒤의 일을 decode라고 부릅니다.

오랫동안 이 두 일은 같은 GPU에서 함께 처리됐습니다. 그런데 2024년에 DistServe라는 연구가 다른 방식을 제안했습니다. prefill과 decode를 서로 다른 GPU로 나누자는 것입니다. 이것을 disaggregation이라고 합니다.

처음에는 이 방식이 크게 주목받지 못했습니다. 분리하려면 서빙 구조를 많이 바꿔야 했기 때문입니다. 하지만 18개월이 지난 지금은 상황이 달라졌습니다. vLLM과 NVIDIA Dynamo를 비롯한 주요 서빙 프레임워크가 모두 이 방식을 채택했습니다.

이 글에서는 두 일을 왜 분리해야 하는지 살펴보겠습니다. 먼저 prefill과 decode가 어떻게 다른지 짚어 보겠습니다. 그다음 둘을 한 GPU에서 함께 돌릴 때 생기는 문제를 살펴보겠습니다.

1. prefill과 decode는 필요한 자원이 다르다

prefill은 프롬프트 전체를 한 번에 읽어 들입니다. 토큰이 수백 개라도 한 번에 처리합니다. 그래서 GPU의 연산 장치를 가득 채워 씁니다. 이렇게 연산이 병목이 되는 상태를 compute-bound라고 합니다.

decode는 한 번에 토큰 하나만 만듭니다. 한 토큰을 만들 때마다 모델 가중치 전체를 메모리에서 다시 읽어야 합니다. 정작 계산량은 많지 않습니다. 그래서 연산 장치는 충분히 쓰이지 않습니다. 대신 메모리에서 데이터를 읽는 속도가 병목이 됩니다. 이렇게 메모리 대역폭이 병목이 되는 상태를 memory-bound라고 합니다.

정리하면 prefill은 연산량이 병목입니다. decode는 메모리 대역폭이 병목입니다. 두 일은 느려지는 이유가 다릅니다. 이 차이가 뒤에 나올 문제의 출발점입니다.

2. 한 GPU에 섞으면 decode가 멈춘다

서버는 보통 여러 요청을 묶어서 한 배치로 처리합니다. 배치로 묶으면 GPU를 더 효율적으로 쓸 수 있기 때문입니다. 그런데 한 배치 안에 prefill 요청과 decode 요청이 섞이면 문제가 생깁니다.

배치는 가장 무거운 작업이 끝날 때까지 함께 기다립니다. prefill은 decode보다 훨씬 무겁습니다. 그래서 decode 요청은 prefill이 끝날 때까지 기다립니다. 이 시간 동안 decode는 새 토큰을 만들지 못합니다.

추론 엔진에는 또 다른 우선순위가 있습니다. 새 요청이 들어오면 먼저 prefill을 처리하려고 합니다. 사용자가 첫 응답을 받기까지 걸리는 시간을 짧게 유지해야 하기 때문입니다. 이 시간을 TTFT(Time To First Token)라고 합니다. 그래서 엔진은 진행 중이던 decode를 잠시 멈추고 새 prefill을 먼저 처리합니다.

decode 요청은 지금까지 만든 토큰들의 중간 계산 결과를 메모리에 들고 있습니다. 이 결과 묶음을 KV 캐시라고 합니다. prefill은 여기에 더해 프롬프트 전체를 메모리에 올려두고 연산합니다. 그래서 새 prefill 요청이 들어오면 GPU 메모리가 빠르게 부족해집니다.

이때 GPU는 진행 중이던 decode 요청의 KV 캐시를 CPU 메모리로 잠시 옮깁니다. 이것을 swapping이라고 합니다. 공간이 더 부족하면 일부 요청은 완전히 제거합니다. 그리고 나중에 다시 계산합니다.

3. 예시로 보는 간섭 문제

요청 세 개가 시간차를 두고 들어오는 상황을 생각해 보겠습니다.
각 요청을 Req0, Req1, Req2라고 부르겠습니다.
아래 그림은 두 방식에서 시간이 어떻게 흘러가는지 비교한 것입니다.
주황색은 prefill입니다.
파란색은 decode입니다.
흰색은 decode가 멈춰 있는 시간입니다.
초록색은 KV 캐시를 옮기는 시간입니다.

위쪽이 colocation입니다. 한 GPU에서 prefill과 decode를 함께 처리합니다. Req1이 도착하면 Req0의 decode가 멈춥니다. Req2가 도착하면 Req0과 Req1의 decode가 함께 멈춥니다. 그래서 흰색 칸이 곳곳에 생깁니다. 이 흰색 칸은 토큰을 만들지 못한 시간입니다.

아래쪽이 disaggregation입니다. decode 워커와 prefill 워커가 따로 있습니다. 새 요청의 prefill은 prefill 워커가 맡습니다. 그래서 decode 워커는 멈추지 않고 토큰을 계속 만듭니다. Req0의 파란색 칸이 끊김 없이 이어지는 것을 볼 수 있습니다.

대신 초록색 칸이 새로 생깁니다. prefill 워커가 만든 KV 캐시를 decode 워커로 옮기는 시간입니다. 분리하면 간섭은 줄어들지만 전송 비용이 새로 생깁니다.

같은 시간 동안 각 요청이 처리한 토큰 수를 세어 보면 차이가 분명합니다.

요청 colocation disaggregation

Req0	9 토큰	22 토큰
Req1	4 토큰	12 토큰
Req2	3 토큰	6 토큰

세 요청 모두 disaggregation에서 더 많은 토큰을 처리했습니다. 특히 가장 먼저 들어온 Req0의 차이가 큽니다. colocation에서는 뒤따라 들어온 요청의 prefill이 우선 처리됩니다. 그래서 Req0의 decode가 자주 멈춥니다.

4. 분리하면 무엇이 달라지는가

prefill과 decode를 서로 다른 GPU로 나누면 이런 방해가 사라집니다. prefill 전용 GPU는 prefill만 처리합니다. decode 전용 GPU는 decode만 처리합니다. 두 작업이 한 배치에서 섞이지 않습니다. 그래서 decode 요청이 새 prefill 때문에 멈추는 일이 없어집니다.

대신 한 가지 일이 새로 필요합니다. prefill GPU가 만든 KV 캐시를 decode GPU로 옮겨야 합니다. 이 전송이 느리면 분리로 얻은 이득이 줄어듭니다. 그래서 prefill과 decode를 분리한 뒤에는 KV 캐시 전송을 어떻게 줄일지가 핵심 과제가 됩니다.

5. disaggregation은 왜 표준이 되었는가

disaggregation을 처음 본격적으로 제안한 연구가 DistServe입니다. 2024년에 나온 논문입니다. 이 논문은 prefill과 decode를 서로 다른 GPU 그룹에서 처리하자고 주장했습니다.

당시 반응은 회의적이었습니다. 한 GPU에서 작동하던 서빙 구조를 둘로 나누려면 공수가 많이 듭니다. KV 캐시를 GPU 사이로 옮기는 경로도 새로 만들어야 합니다. 이런 비용에 비해 이득이 분명하지 않다고 보는 시각이 많았습니다.

시간이 지나며 평가가 바뀌었습니다. 사용자가 첫 토큰을 받기까지 걸리는 시간과 그다음 토큰이 이어지는 속도는 서로 다른 목표입니다. 앞의 목표를 TTFT라고 합니다. 뒤의 목표를 TPOT(Time Per Output Token)라고 합니다. prefill과 decode를 한 GPU에 함께 두면 이 두 목표를 동시에 맞추기 어렵습니다. 분리하면 두 목표를 따로 관리할 수 있습니다.

18개월이 지난 지금은 분리가 표준에 가깝습니다. vLLM과 NVIDIA Dynamo, llm-d, SGLang 같은 주요 프레임워크가 모두 prefill과 decode 분리를 지원합니다.

6. 지금은 무엇이 연구되고 있는가

이제 분리할지 말지는 더 이상 핵심 쟁점이 아닙니다. 질문은 어떻게 더 잘 분리하느냐로 옮겨갔습니다. 크게 세 방향이 연구되고 있습니다.

첫째는 이기종 GPU 배치입니다. prefill과 decode는 필요한 자원이 다릅니다. 그래서 두 작업에 서로 다른 종류의 GPU를 배정하는 것이 유리할 수 있습니다. 어떤 GPU를 얼마나 배정할지가 과제입니다.

둘째는 KV 캐시 효율입니다. 여기에는 두 가지 측면이 있습니다. 하나는 KV 캐시를 어디에 어떻게 저장하느냐입니다. 다른 하나는 KV 캐시를 GPU 사이로 얼마나 빠르게 옮기느냐입니다.

셋째는 네트워크 오버헤드입니다. 분리하면 KV 캐시가 GPU와 GPU 사이를 오갑니다. 이 이동이 느리면 분리로 얻은 이득이 줄어듭니다. 그래서 전송을 빠르게 만드는 방법이 중요해집니다.

이 세 과제를 실제로 풀어내는 것이 오케스트레이션 레이어입니다. 다음 편에서 NVIDIA Dynamo와 llm-d를 예로 들어 살펴보겠습니다.

정리

한 GPU에 섞을 때의 문제 원인

decode가 멈춘다	무거운 prefill과 같은 배치에서 함께 기다린다
decode가 자주 중단된다	TTFT를 줄이기 위해 새 prefill을 먼저 처리한다
KV 캐시를 옮기거나 다시 계산한다	prefill이 GPU 메모리를 추가로 점유한다

prefill과 decode는 부족한 자원이 서로 다릅니다. 그래서 한 GPU에 함께 두면 서로를 방해합니다. 분리하면 이 방해가 사라집니다. 대신 KV 캐시를 GPU 사이로 옮기는 일이 새로 필요해집니다. 이 전송을 잘 해내는 것이 다음 편의 주제입니다.

출처

Zhong et al., "DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving", OSDI 2024
Hao AI Lab, "Disaggregated Inference: 18 Months Later" — https://haoailab.com/blogs/distserve-retro/

pytest 핵심정리

반달bear — Thu, 11 Jun 2026 08:58:51 +0900

들어가며

테스트 코드를 작성하다 보면 반복을 자주 만납니다. pytest는 이 두 반복을 줄여 주는 도구를 갖고 있습니다.
이 글에서는 parametrize와 fixture를 중심으로 pytest의 핵심 기능을 하나씩 살펴보겠습니다.

1. parametrize

덧셈 함수를 테스트한다고 해보겠습니다. 입력 조합이 여러 개라면 보통 테스트 함수를 여러 개 만들게 됩니다. 같은 코드를 입력만 바꿔 반복하는 셈입니다.

@pytest.mark.parametrize는 이 반복을 없애 줍니다. 입력과 기대값의 목록을 한 번에 넘기면 됩니다. 그러면 pytest가 목록의 각 줄을 별도 테스트로 실행합니다.

import pytest

@pytest.mark.parametrize("a, b, expected", [(1, 2, 3), (2, 3, 5), (3, 5, 8)])
def test_addition(a, b, expected):
    assert a + b == expected

테스트 함수는 하나지만 실제로는 세 번 실행됩니다. 어떤 입력에서 실패했는지도 따로 표시됩니다.

2. 예외가 잘 발생하는지 확인 - pytest.raises

테스트는 정상 동작만 확인하지 않습니다. 잘못된 입력에서 예외가 제대로 발생하는지도 확인해야 합니다. pytest.raises는 이때 씁니다. 지정한 예외가 블록 안에서 발생하면 테스트가 통과합니다.

import pytest

def test_divide_by_zero():
    with pytest.raises(ZeroDivisionError):
        1 / 0

예외가 발생하지 않으면 이 테스트는 실패합니다. "예외가 발생해야 정상"인 상황을 검증하는 방법입니다.

3. 반복되는 준비 작업 묶기 - fixture

테스트마다 같은 데이터나 객체를 미리 만들어야 할 때가 있습니다. 이 준비 작업을 매 테스트에 복사해 넣으면 코드가 지저분해집니다.

fixture는 이 준비 작업을 함수 하나로 분리하는 방법입니다. @pytest.fixture를 붙여 함수를 만듭니다. 그리고 테스트 함수의 인자 이름에 그 fixture 이름을 적습니다. 그러면 pytest가 fixture를 먼저 실행하고 그 결과를 테스트에 넘겨 줍니다.

import pytest

@pytest.fixture
def sample_list():
    return [1, 2, 3, 4, 5]

def test_list_sum(sample_list):
    assert sum(sample_list) == 15

test_list_sum은 sample_list를 인자로 받습니다. pytest가 sample_list()를 실행해 반환값 [1, 2, 3, 4, 5]를 넣어 줍니다.

4. fixture의 생명주기 - scope

fixture는 기본적으로 테스트 함수마다 새로 실행됩니다. 그런데 데이터베이스 연결처럼 만드는 비용이 큰 자원은 매번 새로 만들면 낭비입니다.

scope 매개변수로 fixture를 얼마나 자주 만들지 정합니다. 값은 function, class, module, session 네 가지입니다. 뒤로 갈수록 더 넓은 범위에서 한 번만 만들어 재사용합니다.

@pytest.fixture(scope="module")
def db_connection():
    conn = create_db_connection()
    yield conn
    conn.close()

scope="module"은 모듈 하나에서 연결을 한 번만 만듭니다. 그 모듈의 모든 테스트가 같은 연결을 함께 씁니다.

fixture는 다른 fixture를 인자로 받아 조합할 수도 있습니다.

@pytest.fixture
def user_data():
    return {"name": "John", "age": 30}

@pytest.fixture
def user(user_data):
    return User(**user_data)

def test_user_age(user):
    assert user.age == 30

user fixture가 user_data fixture를 받아 씁니다. pytest가 의존 순서를 파악해 차례대로 실행합니다.

5. 정리 작업 자동화 - yield와 teardown

테스트가 끝난 뒤에는 정리가 필요할 때가 있습니다. 만든 임시 유저를 지우거나 파일을 닫는 작업입니다.

fixture 안에서 return 대신 yield를 쓰면 정리 작업을 붙일 수 있습니다. yield까지가 준비 작업입니다. yield 다음 줄부터가 정리 작업입니다. pytest는 테스트가 끝난 뒤 yield 다음 부분을 이어서 실행합니다.

아래는 메일 송수신을 테스트하는 예제입니다. 유저를 만듭니다. 테스트가 끝나면 유저를 삭제합니다.

@pytest.fixture
def sending_user(mail_admin):
    user = mail_admin.create_user()
    yield user
    mail_admin.delete_user(user)        # teardown

@pytest.fixture
def receiving_user(mail_admin):
    user = mail_admin.create_user()
    yield user
    user.clear_mailbox()                # teardown
    mail_admin.delete_user(user)

def test_email_received(sending_user, receiving_user):
    email = Email(subject="Hey!", body="How's it going?")
    sending_user.send_email(email, receiving_user)
    assert email in receiving_user.inbox

실행 순서는 다음과 같습니다.

sending_user 실행 → 유저 생성 후 yield에서 멈춤
receiving_user 실행 → 유저 생성 후 yield에서 멈춤
test_email_received 본문 실행
receiving_user의 yield 이후 실행 → 메일박스 비우고 유저 삭제
sending_user의 yield 이후 실행 → 유저 삭제

정리는 만든 순서의 반대로 진행됩니다. 나중에 만든 fixture가 먼저 정리됩니다.

6. 테스트 분류하고 골라 실행 - 마커

테스트가 많아지면 종류별로 골라 실행할 필요가 생깁니다. 느린 테스트만 제외하거나 데이터베이스 테스트만 실행하는 경우입니다.

마커는 테스트에 붙이는 이름표입니다. 먼저 pytest.ini나 pyproject.toml에 쓸 마커를 정의합니다.

markers =
    slow: 느린 테스트
    db: 데이터베이스 관련 테스트

그다음 테스트 함수에 @pytest.mark.<이름>을 붙입니다.

@pytest.mark.slow
def test_large_computation():
    assert large_computation() == expected_value

이제 -m 옵션으로 특정 마커만 골라 실행합니다.

pytest -m slow

7. 실행 범위 지정과 실패 메시지

테스트 파일이 여러 개면 실행 대상을 지정할 수 있습니다.

pytest test_*.py     # 와일드카드로 파일 묶음 지정
pytest mymodule      # 특정 모듈 지정
pytest ./            # 현재 디렉터리 전체

실패했을 때 보여줄 메시지도 직접 붙일 수 있습니다. assert 문 뒤에 쉼표로 메시지를 적습니다.

def test_even():
    a = 11
    assert a % 2 == 0, "value was odd, should be even"

이 테스트가 실패하면 "value was odd, should be even"이 함께 출력됩니다. 왜 실패했는지 바로 알 수 있습니다.

8. 자주 쓰는 플러그인

pytest는 플러그인으로 기능을 확장합니다. 자주 쓰는 두 가지를 소개합니다.

pytest-cov는 테스트가 전체 코드 중 얼마나 실행하는지를 측정합니다. 이 비율을 커버리지라고 합니다.

pip install pytest-cov
pytest --cov=my_module

pytest-xdist는 테스트를 여러 코어로 나눠 병렬 실행합니다. 테스트가 많을 때 전체 시간이 줄어듭니다.

pip install pytest-xdist
pytest -n auto

정리

기능	무엇을 하는가	핵심
parametrize	같은 테스트를 여러 입력으로	`@pytest.mark.parametrize`
pytest.raises	예외 발생 검증	`with pytest.raises(예외):`
fixture	준비 작업을 함수로 분리	인자 이름으로 주입
scope	fixture 재사용 범위	function / class / module / session
yield teardown	테스트 후 정리 자동화	`yield` 이후가 정리
마커	테스트 분류·선택 실행	`@pytest.mark` + `-m`
플러그인	기능 확장	pytest-cov, pytest-xdist

pytest의 핵심은 반복을 줄이는 데 있습니다. parametrize는 입력 반복을 줄입니다. fixture는 준비 작업 반복을 줄입니다. 여기에 마커와 플러그인을 더하면 테스트를 골라 실행하고 측정까지 할 수 있습니다.

출처

LLM 서빙의 메모리 문제와 PagedAttention (2) - PagedAttention과 vLLM

반달bear — Tue, 12 May 2026 09:38:50 +0900

들어가며

이전 포스트에서 기존 LLM 서빙의 메모리 낭비 문제를 확인했습니다. 미리 점유, 내부/외부 단편화, 공유 불가라는 네 가지 문제가 GPU 활용률을 낮추고 동시 처리 요청 수를 제한합니다.

vLLM은 이 문제를 OS의 가상 메모리(Virtual Memory) 개념을 빌려와서 해결했습니다. OS가 물리 메모리를 고정 크기 페이지로 나눠 관리하듯, KV 캐시도 고정 크기 블록으로 나눠 비연속 공간에 저장하는 방법이 바로 PagedAttention입니다.

1. PagedAttention의 핵심 아이디어

기존 방식은 요청마다 연속된 메모리 공간에 KV 캐시를 저장했습니다. PagedAttention은 이 제약을 없앱니다.

KV 캐시를 고정 크기 블록(block) 단위로 분할
각 블록은 연속할 필요 없이 GPU 메모리 어디든 배치 가능
블록 테이블(Block Table) 이 논리 블록 번호 → 물리 블록 번호 매핑 관리

OS의 페이지 테이블과 완전히 같은 구조입니다. 해당 figure에서 논리 블록은 가독성을 위한 것이고 실제로는 block table의 인덱스를 논리 블록으로 인식합니다. 덕분에 물리 메모리가 비연속으로 흩어져 있어도 논리적으로는 연속된 KV 캐시처럼 접근할 수 있습니다.

2. KV 캐시 매니저와 블록 할당

vLLM의 KV 캐시 매니저는 물리 블록을 관리하는 운영체제 역할을 합니다.

GPU 메모리를 시작할 때 고정 크기 블록으로 분할 (보통 블록당 16토큰)
요청이 들어오면 필요한 만큼만 블록 할당 (최대 길이 기준 사전 할당 없음)
생성이 진행되면서 필요한 블록을 on-demand로 추가 할당
요청이 끝나면 해당 블록들을 즉시 반환

이 방식으로 미리 점유와 내부 단편화 문제가 해결됩니다. 블록 단위로만 약간의 낭비가 생길 수 있지만(마지막 블록이 꽉 차지 않는 경우), 기존 방식에 비하면 무시할 수준입니다.

3. Parallel Sampling — Copy-on-Write

같은 프롬프트에서 여러 출력을 동시에 생성하는 parallel sampling을 생각해보겠습니다. 기존 방식은 프롬프트 KV 캐시를 샘플 수만큼 복사했습니다.

PagedAttention은 OS의 Copy-on-Write(CoW) 방식을 적용합니다.

샘플 1 블록 테이블:  논리 0 → 물리 5 (ref count: 3)
샘플 2 블록 테이블:  논리 0 → 물리 5 (같은 블록 공유)
샘플 3 블록 테이블:  논리 0 → 물리 5 (같은 블록 공유)

→ 샘플 1이 블록 5를 수정하려 할 때
  ref count > 1 이므로 새 블록(물리 9)에 복사 후 수정
  샘플 1 블록 테이블: 논리 0 → 물리 9
  샘플 2, 3: 계속 물리 5 공유

프롬프트 부분(공통 prefix)은 모든 샘플이 같은 물리 블록을 가리키므로 중복 저장 없이 공유됩니다. 출력이 갈라지는 시점부터만 별도 블록을 할당합니다.

4. Beam Search — 트리 구조 공유

Beam search는 상위 k개 후보를 유지하면서 생성하는 방법입니다. 각 후보는 이전 단계의 특정 후보에서 파생됩니다

PagedAttention은 이 트리 구조를 그대로 물리 블록 공유로 표현합니다. 각 빔이 fork되기 전의 블록들은 ref count로 공유되고 갈라진 이후의 블록만 독립적으로 할당됩니다. Beam이 pruning되면 해당 블록들의 ref count가 감소하고 0이 되면 즉시 반환됩니다.

5. Shared Prefix 캐싱

시스템 프롬프트처럼 많은 요청이 공통 prefix를 가지는 경우 prefix의 KV 캐시를 한 번만 계산하고 재사용할 수 있습니다.

vLLM은 이 prefix 블록들을 캐싱해두고 동일 prefix가 들어오는 요청에 재사용합니다. Prefill 비용과 메모리를 모두 절약합니다.

6. 선점과 메모리 압박 처리 — Swapping과 Recomputation

GPU 메모리가 부족해지면 일부 요청을 선점(preemption) 해야 합니다. vLLM은 두 가지 방법을 제공합니다.

Swapping

KV 캐시 블록을 CPU 메모리로 이동시킵니다.

GPU 메모리: [요청A 블록] [요청B 블록] ← 가득 참
→ 우선순위 낮은 요청C 블록을 CPU로 스왑
→ 새 요청 D를 위한 GPU 공간 확보
→ 나중에 요청C 재개 시 CPU 블록을 GPU로 다시 스왑인

블록 단위 관리 덕분에 스왑 단위도 블록 단위입니다. OS의 페이지 스왑과 동일한 개념입니다.

Recomputation

KV 캐시를 버리, 나중에 필요할 때 처음부터 다시 계산합니다. Swapping보다 메모리 전송 비용은 없지만 연산 비용이 발생합니다. 시퀀스가 짧거나 CPU 대역폭이 병목일 때 유리합니다.

7. 분산 환경 — Tensor Parallelism

vLLM은 Megatron-LM 스타일의 텐서 병렬화(Tensor Parallelism)를 지원합니다. 모델을 여러 GPU에 나눠 올리는 방식입니다.

GPU 0: 어텐션 헤드 절반 + FFN 절반
GPU 1: 어텐션 헤드 절반 + FFN 절반
→ All-reduce로 결과 합산

KV 캐시도 각 GPU에 분산됩니다. vLLM의 CPU에 있는 중앙 스케줄러가 모든 GPU의 KV 캐시 상태를 통합 관리하고, 어느 블록이 어느 GPU에 있는지 추적합니다.

[중앙 스케줄러 + KV 캐시 매니저]
        ↓              ↓
   [GPU Worker 0]  [GPU Worker 1]
   KV 캐시 일부    KV 캐시 일부

SPMD(Single Program Multiple Data) 방식으로 모든 워커가 같은 코드를 실행하고 스케줄러가 보내는 명령에 따라 동기화됩니다.

8. vLLM 전체 구조

vLLM의 아키텍처를 한 장으로 정리하겠습니다.

사용자 요청
    ↓
[스케줄러]
 - 어떤 요청을 이번 스텝에 처리할지 결정
 - KV 캐시 매니저와 협력해 블록 할당/반환
    ↓
[KV 캐시 매니저]
 - 물리 블록 풀 관리
 - 블록 테이블 유지
 - ref count 기반 공유/CoW 처리
    ↓
[GPU 워커들]
 - PagedAttention으로 비연속 KV 캐시 어텐션 계산
 - 텐서 병렬화 적용
    ↓
출력 토큰

정리

기술	해결한 문제	OS 유사 개념
블록 단위 KV 캐시	외부 단편화, 미리 점유	페이지 가상 메모리
블록 테이블	비연속 메모리 접근	페이지 테이블
On-demand 할당	내부 단편화	지연 할당
Copy-on-Write	parallel sampling 중복 저장	CoW fork
Swapping	GPU 메모리 압박	페이지 스왑
Shared prefix	공통 프롬프트 중복 계산	공유 메모리

vLLM의 핵심 통찰은 LLM 서빙의 메모리 관리 문제가 OS의 메모리 관리 문제와 구조적으로 같다는 것입니다. 30년간 OS가 발전시켜온 기법들을 GPU KV 캐시에 적용해서 성능 향상을 이뤄냈습니다.

출처

Kwon et al., "Efficient Memory Management for Large Language Model Serving with PagedAttention", SOSP 2023
vLLM GitHub: https://github.com/vllm-project/vllm
vLLM Blog: https://vllm.ai/blog/2023/06/20/vllm.html

LLM 서빙의 메모리 문제와 PagedAttention (1) - KV 캐시와 단편화

반달bear — Tue, 12 May 2026 09:37:52 +0900

들어가며

ChatGPT 같은 LLM 서비스를 운영한다고 생각해보겠습니다. 수천 명의 사용자가 동시에 요청을 보내는데 추론 과정에서 생성되는 중간 데이터가 메모리를 크게 잡아먹기 때문에 중간에 데이터 정체가 일어납니다. 이 포스트에서는 그 중간 데이터의 정체인 KV 캐시가 무엇인지, 그리고 기존 방식이 왜 메모리를 낭비하는지 알아보겠습니다.

1. KV 캐시란 무엇인가

트랜스포머의 셀프 어텐션은 다음 수식으로 동작합니다.

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

토큰을 하나씩 생성하는 자기회귀(autoregressive) 방식에서는 새 토큰을 생성할 때마다 이전 토큰들의 K, V를 다시 계산해야 합니다. 같은 계산을 반복하는 것은 낭비이므로, 이미 계산한 K, V를 GPU 메모리에 저장해두고 재사용하는 것이 KV 캐시입니다.

KV 캐시 덕분에 매 스텝에서 새 토큰 하나의 Q만 계산하고, 저장된 K, V와 어텐션을 계산하면 됩니다. 속도는 빨라지지만, 메모리 사용량이 증가한다는 트레이드오프가 생깁니다.

2. Prefill과 Decode

LLM 추론은 크게 두 단계로 나뉩니다.

페이즈	설명	특성
Prefill	입력 프롬프트 전체를 한 번에 처리	Compute-bound (연산이 병목)
Decode	토큰을 한 개씩 생성	Memory-bound (메모리 대역폭이 병목)

Decode 단계에서는 매 스텝마다 GPU의 모든 가중치를 메모리에서 읽어야 합니다. 처리하는 연산량(FLOPs)에 비해 메모리 읽기 비용이 압도적으로 크기 때문에 메모리 대역폭이 병목이 됩니다.

이 때문에 Decode 단계에서 배치 크기(batch size)를 키워서 한 번 메모리를 읽을 때 더 많은 요청을 처리하면 연산량을 늘려서 메모리 읽기 비용 대비 연산량을 늘릴 수 있습니다.

3. 배치를 키워야 하는 이유

GPU는 병렬 연산에 특화되어 있습니다. Decode 단계에서 배치 크기 1과 배치 크기 32는 메모리를 읽는 시간은 거의 같지만, 처리하는 요청 수는 32배가 되기에 배치를 키울수록 GPU 연산 효율이 올라갑니다. 문제는 배치를 키우려면 각 요청의 KV 캐시를 모두 메모리에 올려야 한다는 것입니다. 이때 HBM에서 SRAM에 올려야 하는 횟수가 빈번해진다는 문제가 있습니다.

OPT-13B 모델 기준으로 토큰 하나당 KV 캐시 크기를 계산해보면 아래와 같기에 하나의 토큰을 처리하기 위해서는 배치 사이즈 이상의 메모리 대역폭이 필요해집니다. 그러므로 연산량을 늘리기 위해서 배치를 늘렸지만 여전히 메모리 병목 문제는 존재합니다. 또한 절대적 용량의 문제도 있습니다.

레이어 수(40) × 헤드 수(40) × 헤드 차원(128) × 2(K,V) × 2bytes(FP16)
= 약 800KB / 토큰

A100 HBM의 경우 KV 캐시가 약 30%를 차지합니다. 시퀀스 길이가 길어질수록 KV 캐시는 빠르게 불어납니다. 게다가 기술의 발전에 따라 GPU FLOPs는 빠르게 늘어나는데 HBM 용량은 80GB 대에서 정체되어 있기 때문에 대역폭 뿐만 아니라 절대적 메모리 용량의 효율화도 필요한 상황입니다.

4. 기존 메모리 관리의 세 가지 낭비

기존 LLM 서빙 프레임워크(FasterTransformer, Orca 등)는 각 요청에 대해 최대 시퀀스 길이만큼 메모리를 미리 할당했습니다. 이 방식은 세 가지 문제를 만듭니다.

낭비 1: 미리 점유 (Over-reservation)

요청이 들어오면 "이 요청이 최대 몇 토큰을 생성할지 모르니까 최대치만큼 잡아두자"고 합니다. 실제 생성 길이가 짧으면 남은 공간은 그냥 낭비됩니다.

낭비 2: 내부 단편화 (Internal Fragmentation)

미리 잡아둔 공간 중 실제로 쓰이지 않는 부분이 그 요청에 묶여있어 다른 요청이 사용할 수 없습니다.

낭비 3: 외부 단편화 (External Fragmentation)

여러 요청이 들어오고 나가다 보면 메모리 공간이 군데군데 비는 조각(fragment) 이 생깁니다. 총 여유 메모리는 충분해도 연속된 공간이 없어서 새 요청을 할당하지 못하는 상황이 발생합니다.

공유 불가 (No Sharing)

Beam search나 parallel sampling처럼 하나의 프롬프트에서 여러 후보를 생성하는 경우, 공통 프롬프트 부분의 KV 캐시를 공유하면 메모리를 아낄 수 있습니다. 그러나 기존 방식은 각 요청마다 별도로 복사해서 관리합니다.

5. Compaction이 불가능한 이유

일반 메모리 관리에서는 외부 단편화를 해결하기 위해 compaction(데이터를 한쪽으로 모아서 빈 공간을 합치는 작업)을 수행합니다. 그런데 GPU에서 KV 캐시는 compaction을 하기 어렵습니다.

Decode 단계에서는 매 스텝마다 KV 캐시를 읽고 써야 합니다. 실시간으로 데이터를 옮기면 추론이 중단되고, 이동 비용이 추론 비용보다 훨씬 큽니다. 결국 단편화된 메모리를 그대로 쓸 수밖에 없는 구조입니다.

정리

문제	원인	결과
미리 점유	최대 길이 기준 사전 할당	실제 사용량보다 많은 메모리 소비
내부 단편화	할당된 공간 중 미사용 부분 존재	메모리 묶임, 활용률 저하
외부 단편화	비연속 빈 공간 발생	충분한 총량에도 할당 실패
공유 불가	요청별 독립 할당	중복 KV 캐시 저장
Compaction 불가	실시간 이동 비용 과다	단편화 해결 수단 없음

이 다섯 가지 문제가 맞물려 GPU 메모리 활용률이 60~80%에 그치고, 같은 GPU에서 처리할 수 있는 동시 요청 수가 심각하게 제한됩니다.

다음 포스트에서는 vLLM이 이 문제를 어떻게 해결했는지 OS의 페이지 가상 메모리 개념을 KV 캐시에 적용한 PagedAttention 을 살펴보겠습니다.

출처

Kwon et al., "Efficient Memory Management for Large Language Model Serving with PagedAttention", SOSP 2023
vLLM Blog: https://vllm.ai/blog/2023/06/20/vllm.html

쿠버네티스 컨테이너 런타임 비교 정리 — 도커 지원 중단과 CRI, OCI, shim

반달bear — Wed, 22 Apr 2026 18:24:43 +0900

들어가며

Kubernetes 1.24부터 kubelet이 Docker를 직접 지원하지 않습니다 (정 docker를 사용하겠다면 cri-dockerd로 도커를 계속 사용할 수는 있습니다). 그래서 찾다보면 도커의 대체제로 다양한 컨테이너 런타임이 존재합니다. containerd, CRI-O, 부터 runC, Podman, nerdctl, crictl, ctr, shim, OCI, CRI와 같은 어떤 역할인지 알지 못하는 개념들이 많이 나옵니다.

이 글에서는 쿠버네티스와 컨테이너 런타임 사이에 왜 표준(OCI, CRI)이 필요했는지부터 시작해서, 그 표준 위에 올라간 구현체들이 각자 어떻게 서로를 호출하는지, 마지막에는 그래서 뭘 골라야 하는가까지 이어집니다.

1. 쿠버네티스는 OCI와 CRI 위에서 컨테이너를 띄운다

CRI — kubelet과 컨테이너 런타임 사이의 규격 (일종의 인터페이스)

kubelet은 컨테이너를 직접 띄우지 않습니다. 컨테이너 런타임에게 gRPC로 요청을 던집니다. "이 이미지로 컨테이너 만들어줘", "이거 로그 보여줘", "이거 멈춰". 이 gRPC 규격이 CRI(Container Runtime Interface)입니다.

CRI는 2016년쯤 쿠버네티스 프로젝트가 직접 만들었습니다. 그 전에는 kubelet이 특정 런타임(도커)에 직접 묶여 있어서, 다른 런타임을 지원하려면 kubelet 코드를 수정해야 했습니다. CRI가 생긴 뒤로는 kubelet을 다시 컴파일하지 않아도 CRI를 구현한 런타임이면 뭐든 붙일 수 있습니다.

CRI가 정의하는 RPC는 대략 이런 것들입니다.

이미지 pull
Pod 생성 / 제거
컨테이너 생성 / 시작 / 중지
컨테이너·Pod 상태 조회
로그 스트림

OCI — CRI와 커널(OS)를 연결하는 규격 (일종의 인터페이스)

CRI 요청을 받은 런타임은 커널(OS)에서 namespace를 만들고, cgroup을 걸고, 파일 시스템을 마운트한 뒤 프로세스를 fork/exec 합니다. 이 저수준 작업의 규격이 OCI(Open Container Initiative)입니다.

OCI는 리눅스 재단 산하 단체로, 두 가지를 표준화했습니다.

런타임 스펙 — 특정 설정 파일(bundle)을 주면 컨테이너를 이렇게 띄워야 한다는 규격
이미지 스펙 — 컨테이너 이미지의 레이어 구조, 메타데이터 포맷

OCI 덕분에 도커로 빌드한 이미지를 containerd나 CRI-O에서 그대로 사용할 수 있습니다.

두 표준의 위치

정리하면 쿠버네티스와 커널 사이에 표준이 두 개 겹쳐 있습니다.

[ kubelet ]
     │
     │  ← CRI (kubelet ↔ 런타임)
     ▼
[ 컨테이너 런타임 ]
     │
     │  ← OCI (런타임 ↔ 커널, 이미지 포맷)
     ▼
[ namespace + cgroup = 컨테이너(프로세스) ]

이 두 표준 덕분에 kubelet은 어떤 런타임이 밑에 있는지 몰라도 되고 런타임은 어느 이미지 빌더가 만든 이미지인지 몰라도 됩니다.

2. shim이란?

docker-shim, containerd-shim 과 같이 컨테이너 런타임 조사를 하다보면 shim이란 단어가 많이 나옵니다. shim이란 단어를 범용적으로 사용하는데이름이 비슷해서 혼동하기 쉽지만 기술별로 가지는 의미가 다릅니다. 대표적으로 containerd-shim docker-shim을 다뤄보겠습니다.

containerd-shim - 고수준(containerd)과 저수준(runC) 사이

실제로 컨테이너를 띄우는 저수준 도구는 보통 한 번 실행되고 종료되도록 설계돼 있습니다(뒤에서 자세히 설명할 runC가 그렇습니다). 컨테이너를 띄운 도구는 곧바로 죽고, 띄워진 컨테이너 프로세스만 남습니다.

여기서 질문이 생깁니다. 컨테이너의 부모는 누구인가? 리눅스에서 부모 프로세스가 죽으면 자식은 PID 1(init)에 입양됩니다. 그런데 컨테이너 입장에서는 로그는 누가 모으고, 종료 코드는 누가 받아주고, 고수준 런타임 데몬(containerd 같은 것)이 재시작됐을 때 "이 컨테이너는 내 거야"라고 누가 주장해줄지 문제가 생깁니다.

이 빈자리를 메우는 게 containerd-shim입니다. containerd-shim은 컨테이너마다 하나씩 붙어서 구동이 됩니다.

저수준 런타임은 컨테이너를 띄우고 바로 종료
shim이 컨테이너 프로세스의 부모 역할을 이어받음
고수준 런타임 데몬(containerd 프로세스라고 이해해도 됩니다)이 재시작돼도 shim은 독립적으로 살아 있어서 컨테이너가 고아가 되지 않음
컨테이너의 stdout/stderr을 받아두고, 종료 코드를 기다렸다가 데몬에 보고

containerd-shim은 컨테이너의 라이프사이클을 데몬과 분리시키기 위해 끼어 있는 얇은 프로세스입니다. 초기 모델에서는 컨테이너마다 shim이 하나씩 떴고, 현재의 shim v2에서는 보통 Pod(샌드박스)당 하나의 shim이 떠서 같은 Pod 안의 컨테이너들을 함께 관리합니다.

dockershim — kubelet과 고수준(Docker) 사이

shim이라는 이름이 쿠버네티스 맥락에서 또 등장하는데 여기선 다른 의미를 가집니다.

쿠버네티스가 CRI를 만들었을 때 containerd와 CRI-O는 이걸 구현했습니다. 그런데 도커는 CRI를 구현하지 않은 상태였습니다.

그래서 쿠버네티스 프로젝트가 직접 어댑터를 만들어서 kubelet 안에 넣었습니다. 이것이 docker-shim입니다. kubelet에서 CRI 호출이 나가면 docker-shim이 받아서 도커 API로 번역해 dockerd에 전달합니다. (1.24에서 제거됐습니다, 이유는 뒤에서)

두 shim의 공통점과 차이점

	containerd-shim	dockershim
위치	런타임 ↔ 컨테이너 프로세스	kubelet ↔ 도커
목적	컨테이너 라이프사이클을 데몬과 분리	CRI를 도커 API로 번역
현재 상태	컨테이너 하나당 하나씩 상시 동작	1.24에서 제거됨

3. 고수준 컨테이너 런타임 — Docker, containerd, CRI-O

컨테이너 런타임은 실제로는 두 층으로 나뉘어 있습니다.

저수준 런타임 — 실제로 namespace/cgroup을 설정하고 프로세스를 fork/exec합니다. 대표적으로 runC. OCI 런타임 스펙을 구현합니다.
고수준 런타임 — 그 위에서 이미지 pull, 컨테이너 라이프사이클 관리, API 제공 같은 저수준 런타임 운영에 필요한 일을 합니다. 대표적으로 Docker, containerd, CRI-O. 데몬 프로세스로 돌면서 내부에서 저수준 런타임(runC)을 호출합니다.

Docker

도커는 원래 CLI, 데몬, 이미지 빌드, 레지스트리 통신, 컨테이너 실행, 저수준 커널 조작까지 다 하는 하나의 덩어리였습니다. 그러다 규모가 커지면서 내부가 쪼개지기 시작했습니다. 저수준 부분은 runC로 분리되어 나갔고, 고수준의 상당 부분은 containerd로 분리되어 나갔습니다. 지금의 도커는 내부적으로 이렇게 생겼습니다.

docker — 사용자가 치는 CLI
dockerd — Docker 데몬. CLI 요청을 받아서 처리
docker-containerd — containerd를 얇게 래핑한 것
docker-runc — runC를 얇게 래핑한 것

docker run nginx를 치면 네 개 계층을 거칩니다.

도커는 왜 쿠버네티스에서 빠졌나

도커의 문제는 하나였습니다. CRI를 직접 구현하지 않습니다. 그래서 쿠버네티스는 docker-shim이라는 어댑터를 별도로 유지해야 했습니다.

그런데 도커가 이미 내부적으로 containerd를 쓰고 있다면, kubelet → docker-shim → dockerd → docker-containerd를 거쳐서 간접적으로 containerd를 부르는 셈입니다. docker-shim(kubelet과 도커 프로세스/데몬을 연결), dockerd(docker-shim과 docker-containerd를 연결)이 중복인 셈입니다. kubelet이 containerd를 직접 부르면 깔끔합니다.

그래서 쿠버네티스는 1.24에서 docker-shim을 제거했습니다. (도커로 빌드한 이미지는 OCI 표준이라 containerd에서 그대로 돌아갑니다.)

현재 도커는 래핑 바이너리가 아니라 표준인 containerd/runc를 그대로 호출합니다.

containerd — 도커에서 독립한 범용 런타임

containerd는 원래 도커의 일부였다가 분리되어 나와 CNCF 프로젝트가 됐고, 지금은 졸업 프로젝트입니다. 범용적으로 설계돼 있어서 쿠버네티스 외의 용도로도 쓸 수 있습니다.

CRI 표준이 없었을 때 — containerd 자체는 CRI를 몰랐고, 별도의 cri-containerd 데몬이 kubelet과 containerd 사이에 다리를 놓음
CRI 표준이 생기고 난 후 — containerd에 CRI 플러그인이 내장되어 kubelet이 직접 containerd를 호출

CRI-O — 처음부터 쿠버네티스 전용으로 설계된 경량 런타임

CRI-O는 레드햇에서 만든 런타임인데, 이름에서 드러나듯 처음부터 CRI 구현만을 목적으로 만들어졌습니다. 쿠버네티스 전용이라고 보면 됩니다. containerd와 달리 범용 용도를 버린 대신 경량화돼 있고, kubelet → CRI-O → runC → 컨테이너의 호출 경로가 가장 짧습니다.

kubelet이 컨테이너를 띄울 때 거치는 경로는 아래와 같습니다.

Docker-shim 경유 — kubelet → docker-shim → Dockerd(도커 엔진) → containerd → runC → 컨테이너. 1.24에서 제거. 중간이 너무 많음.
Containerd + CRI Plugin — kubelet → containerd(CRI Plugin 내장) → containerd-shim → runC → 컨테이너. 현재 표준.
CRI-O — kubelet → CRI-O → runC → 컨테이너.

4. Podman은 뭘까?

자료를 찾아보면 RedHat에서 공식적으로 지원하는 툴은 Podman이라는 말이 자주 보이는데 Podman은 어디에 들어가는 걸까요?

결론부터 말하면 Podman은 쿠버네티스 노드 런타임 후보가 아닙니다.

Podman이 푸는 문제

Podman은 레드햇이 만든 OCI 호환 컨테이너 엔진입니다. 가장 큰 특징은 데몬리스라는 점입니다. 도커처럼 dockerd 같은 중앙 데몬을 두지 않고, podman run 명령이 현재 사용자 프로세스로 직접 runC를 호출해서 컨테이너를 만듭니다.

중앙 데몬 없음 → rootless 실행이 자연스러움
CLI가 도커와 호환됨 → alias docker=podman으로 거의 그대로 대체 가능
별도의 고수준 런타임 레이어 없이 Podman 자체가 그 역할을 함

데몬이 없다는 건 "항상 떠 있는 컨테이너"를 관리할 주체가 없다는 뜻이기도 합니다. Podman은 이 문제를 systemd에 서비스로 등록하는 방식으로 풉니다. podman generate systemd로 서비스 파일을 뽑아 systemd에 맡기면, 부팅 시 자동 시작이나 실패 시 재시작을 systemd가 대신 관리합니다.

또한 Podman 생태계는 한 덩어리가 아니라 작은 도구들이 역할을 나눠 가집니다.

buildah — 이미지 빌드 담당. docker build를 대체
skopeo — 이미지 레지스트리 간 전송 담당. docker push/docker pull 영역을 대체

이 설계는 전부 단일 호스트 사용 사례에 맞춰져 있습니다. 개발자 로컬 머신, CI 러너, 단일 서버에서 도커를 대체하는 용도입니다. RHEL 계열에 기본 탑재된 이유도 이것입니다.

Podman은 왜 쿠버네티스 노드 런타임이 될 수 없는가

kubelet이 노드에서 컨테이너를 띄울 때는 CRI gRPC 규격으로 런타임을 호출합니다. Podman은 CRI를 구현하지 않습니다. 그래서 kubelet이 호출할 수가 없습니다.

Podman이 쿠버네티스와 엮이는 경로가 없진 않습니다.

podman generate kube — 로컬에서 띄운 컨테이너를 쿠버네티스 YAML로 뽑아줌
podman play kube — 쿠버네티스 YAML을 Podman이 단일 호스트에서 실행 (mini-k8s 흉내)

둘 다 개발 편의 도구지, 실제 클러스터 노드 런타임이 아닙니다. 같은 회사(레드햇)에서 쿠버네티스 노드 런타임으로 미는 건 Podman이 아니라 CRI-O입니다.

요점

Podman과 containerd/CRI-O가 나란히 비교되는 표가 종종 있는데 사실 층위가 다릅니다.

containerd, CRI-O: 쿠버네티스 노드 런타임 (CRI 구현)
Podman: 단일 호스트용 컨테이너 엔진 (CRI 미구현, 도커 CLI 대체재)

5. CLI는 뭘 사용해야 할까?

런타임을 containerd로 바꾸기로 했다고 하면 다음 질문이 나옵니다. 그럼 docker ps, docker logs 대신 뭘 쓰지?

도커에서는 docker가 CLI이고 dockerd가 데몬이었습니다. 그런데 쿠버네티스 노드에서 실제로 컨테이너를 띄우는 주체는 사람이 아니라 kubelet입니다. containerd만 깔려 있으면 쿠버네티스는 정상 동작합니다. CLI는 사실 필수가 아닙니다.

그래도 운영자가 노드에 들어가서 확인할 일이 있기 때문에 CLI는 필요합니다. containerd 환경에서 쓸 수 있는 CLI는 세 가지입니다.

crictl — 쿠버네티스 표준 디버깅 도구

CRI gRPC를 직접 호출하는 CLI입니다. kubelet이 보는 것과 같은 관점으로 컨테이너를 봅니다.

crictl ps              # kubelet이 관리하는 컨테이너 목록
crictl pods            # Pod 목록
crictl logs <id>       # 컨테이너 로그
crictl exec -it <id> sh

kubelet이 만든 것만 보이고 이미지 빌드는 못 합니다. 쿠버네티스 관점에서 사용할 수 있는 CLI입니다.

ctr — containerd 네이티브 CLI

containerd에 기본으로 딸려오는 CLI입니다. 굉장히 저수준이고 containerd의 모든 네임스페이스를 볼 수 있습니다.

ctr -n k8s.io containers list
ctr images pull ...

-n k8s.io를 안 붙이면 쿠버네티스 컨테이너가 안 보이고 도커와 명령어 체계가 달라서 추가 학습이 필요합니다. 일상적으로 쓰기는 불편합니다.

nerdctl — Docker 호환 CLI for containerd

containerd 공식 서브프로젝트입니다. 도커 CLI 문법을 그대로 containerd에 사용할 수 있게 해줍니다.

nerdctl run -d nginx
nerdctl ps
nerdctl images
nerdctl build -t myapp .
nerdctl login my-registry.local

docker를 nerdctl로 바꾸면 거의 다 동작합니다. 도커에 익숙한 운영자가 containerd 환경으로 가장 저항감 없이 넘어갈 수 있습니다.

그래서 뭘 골라야 할까?

노드 런타임: containerd

Docker는 공식 탈락. 1.24에서 dockershim이 제거됨. 쓰려면 별도의 cri-dockerd를 운영해야 함.
Podman은 애초에 후보가 아님. CRI를 구현하지 않아 kubelet이 호출 불가. 단일 호스트용 도구.
CRI-O는 기능은 containerd와 거의 동등하지만 생태계가 좁음.
containerd는 CNCF 졸업 프로젝트로 EKS, GKE, AKS의 기본 런타임이고, Kubespray의 기본값이기도 함. 범용성과 문서, 트러블슈팅 자료가 가장 두터움.

Kubespray로 에어갭 환경에서 클러스터를 올리는 상황이면, 기본값을 바꾸지 않고 그대로 쓰는 게 맞습니다. 프라이빗 레지스트리 구성(library/ 프리픽스 문제, insecure registry 설정)도 containerd 기준으로 맞춰두면 혹시라도 추후에 컨테이너 런타임을 변경하거나 런타임을 직접 개발하더라도 고도화 하기에 편리합니다.

CLI: nerdctl, 필요하면 ctr

nerdctl — 도커처럼 쓰고 싶을 때 (이미지 pull/push, 레지스트리 로그인, 수동 실행)
ctr — 가끔 저수준 확인 (네임스페이스별 조회 등)

최종 스택

kubelet
  │ CRI
  ▼
containerd (CRI Plugin 내장)
  │
  ▼
containerd-shim (컨테이너마다 하나씩)
  │ OCI
  ▼
runC
  │
  ▼
namespace + cgroup = 컨테이너

참조자료

https://docs.redhat.com/ko/documentation/red_hat_enterprise_linux/9/html/building_running_and_managing_containers/selecting-a-container-runtime_building-running-and-managing-containers

https://mkdev.me/posts/the-tool-that-really-runs-your-containers-deep-dive-into-runc-and-oci-specifications

https://mkdev.me/posts/dockerless-part-3-moving-development-environment-to-containers-with-podman

https://www.youtube.com/watch?v=sK5i-N34im8

https://velog.io/@yange/Kubernetes-container-runtime%EC%97%90-%EB%8C%80%ED%95%98%EC%97%AC

https://docs.redhat.com/ko/documentation/red_hat_enterprise_linux/9/html/building_running_and_managing_containers/selecting-a-container-runtime_building-running-and-managing-containers

https://atl.kr/dokuwiki/doku.php/podman_%EB%A1%9C%EC%BB%AC_%EC%BB%A8%ED%85%8C%EC%9D%B4%EB%84%88_%EB%9F%B0%ED%83%80%EC%9E%84%EC%97%90%EC%84%9C_%ED%8F%AC%EB%93%9C_%EB%B0%8F_%EC%BB%A8%ED%85%8C%EC%9D%B4%EB%84%88_%EA%B4%80%EB%A6%AC

https://blog.naver.com/pjt3591oo/222992244712

https://www.cncf.co.kr/blog/k8s-crio-runc/

https://labex.io/ko/tutorials/linux-how-to-check-if-a-container-runtime-is-installed-in-linux-558703

https://kimsanghyeon.tistory.com/237

https://www.ncsc.go.kr:4018/main/cop/bbs/selectBoardArticle.do?bbsId=InstructionGuide_main&nttId=18590&pageIndex=1

https://insujang.github.io/2019-10-31/container-runtime/

https://www.tutorialworks.com/difference-docker-containerd-runc-crio-oci/

트랜스포머 쉽게 이해하기 (2) - 디코더

반달bear — Mon, 20 Apr 2026 19:38:45 +0900

들어가며

[이전 글]에서는 영어 문장 "I am studying"이 인코더를 거치면서 어떻게 문맥이 녹아든 벡터로 변환되는지 살펴봤습니다.

이번 글에서는 그 벡터를 받아 불어(혹은 독일어) 문장을 한 토큰씩 만들어내는 디코더를 다룹니다.

예시 문장은 다음과 같이 가정하겠습니다.

원문(영어): I am studying Transformer
번역(독일어): Ich studiere Transformer

그리고 지금까지 디코더가 "Ich", "studiere"까지 생성했고, 이제 그 다음 단어 "Transformer"를 예측하려는 상황을 떠올려봅시다.

디코더 블록의 전체 구조

인코더 블록이 3단계(멀티헤드 셀프 어텐션 → FFN → 잔차 연결/층 정규화)였다면, 디코더 블록은 한 단계가 더 있습니다.

입력(독일어 임베딩 + 위치 벡터)
  ↓
① 마스크드 멀티헤드 셀프 어텐션  (Q=K=V, 모두 독일어)
  ↓  잔차 연결 + 층 정규화
② 인코더-디코더 어텐션 (크로스 어텐션)
     Q = ①의 출력 (독일어)
     K, V = 인코더 최종 출력 (영어)
  ↓  잔차 연결 + 층 정규화
③ 앞먹임 신경망 (FFN)
  ↓  잔차 연결 + 층 정규화
출력(512차원)

이 블록을 N=6번 쌓으면 디코더 하나가 완성됩니다.

인코더와 다른 점은 멀티헤드 어텐션에 "마스크드"가 붙다는 점과 인코더-디코더 어텐션에서 인코더의 출력을 K, V로 받아온다는 점입니다.

1단계: 마스크드 멀티헤드 셀프 어텐션

디코더는 번역을 왼쪽에서 오른쪽으로 한 단어씩 만들어냅니다. "Ich"를 만들 때는 "studiere"나 "Transformer"가 아직 존재하지 않아야 하고, "studiere"를 만들 때는 "Transformer"를 아직 몰라야 합니다.

그런데 훈련할 때는 정답 문장 "Ich studiere Transformer"를 한꺼번에 디코더에 집어넣습니다(이래야 학습이 빠릅니다). 이렇게 한꺼번에 넣으면 셀프 어텐션이 미래 단어까지 참고해서 현재 단어를 예측해 버립니다. 즉 "studiere" 위치에서 "Transformer"를 미리 보고 다음 단어를 맞추는 상황이 생깁니다.

마스크는 "어디서" 일어나는가? — 가장 헷갈리는 부분

많은 설명이 "미래 토큰을 마스킹한다"고만 말해서 마치 입력에서 토큰을 빼는 것처럼 느껴지는데 "Ich studiere Transformer" 세 토큰이 디코더에 모두 들어갑니다. 각 토큰은 자기 몫의 Q, K, V 벡터를 만듭니다. 그 다음 Q와 K를 곱하면 3×3 어텐션 스코어 행렬이 나오는데, 바로 이 행렬의 오른쪽 위 삼각형을 `-∞`로 덮어버리는 것이 마스킹입니다.

토큰이 사라지는 게 아니라, 어텐션 가중치만 0으로 만듭니다. 그래서 입력 토큰 수는 항상 3개(또는 문장 길이만큼)이고 출력 벡터도 항상 토큰 수와 동일한 개수만큼 나옵니다.

여기서 왜 -∞로 덮는지가 궁금할 수 있는데, 어텐션 스코어는 마지막에 소프트맥스를 거칩니다. 소프트맥스는 exp(-∞) = 0이므로, -∞로 마스킹된 자리는 최종 어텐션 가중치에서 정확히 0이 됩니다.

마스킹 이후 각 토큰 벡터에 담기는 정보

마스킹을 거친 후 각 토큰 위치의 출력 벡터가 볼 수 있는 정보는 다음과 같이 달라집니다.

2단계: 인코더-디코더 어텐션 (크로스 어텐션)

마스크드 셀프 어텐션이 독일어 문장 내부의 관계를 본다면, 크로스 어텐션은 독일어 ↔ 영어의 관계를 봅니다.

Q: 마스크드 어텐션의 출력 (독일어에서 옴)
K, V: 인코더 최종 출력 (영어에서 옴)

여기서 헷갈릴 수 있는 부분이 인코더 최종 출력 하나를 디코더의 6개 블록이 전부 공유해서 K, V로 쓴다는 것입니다. 인코더는 딱 한 번만 돌고 그 최종 출력을 디코더 6개 블록이 똑같이 참조합니다.

3단계: 앞먹임 신경망(FFN) + 잔차 연결 + 층 정규화

인코더와 동일합니다. 잔차 연결과 층 정규화를 다시 거칩니다.

여기까지가 디코더 블록 하나입니다. 이걸 6번 반복하면 디코더가 완성됩니다.

4단계: 선형 층(Linear)과 소프트맥스 — 다음 단어 예측

디코더 6개 블록을 다 통과한 결과물은 토큰 개수만큼의 512차원 벡터 (512차원이라는 건 처음 토큰 1개를 몇 차원의 벡터로 정의할지 정하는 과정에서 정해지게 됩니다)입니다. "Ich studiere"를 넣었다면 512차원 벡터 2개가, "Ich studiere Transformer"를 넣었다면 3개가 나옵니다.

그런데 실제로 다음 단어를 고르려면, 이 512차원 벡터를 어휘 사전 전체(약 3만 개)의 확률 분포로 변환해야 합니다. 이 역할을 선형 층이 맡습니다.

512차원 벡터  ──(512 × 30,000 가중치 행렬)──▶  30,000차원 벡터
                                                 │
                                                 ▼
                                            소프트맥스
                                                 │
                                                 ▼
                                      어휘 사전 각 단어의 확률
                                      (가장 큰 값이 다음 단어)

가장 헷갈리는 질문: 어느 위치의 벡터를 선형 층에 넣어야 하지?

지금까지 "Ich", "studiere"를 만들었고, 그 다음인 "Transformer"를 예측하고 싶다고 합시다. 디코더의 출력 벡터는 2개입니다.

벡터 A: "Ich" 위치의 출력 (512차원)
벡터 B: "studiere" 위치의 출력 (512차원)

둘 중 어떤 걸 선형 층에 넣어야 할까요? 정답은 B(= 마지막 위치)의 벡터입니다. 왜일까요?

벡터 A ("Ich" 위치) = [Ich] 정보만 담고 있음
벡터 B ("studiere" 위치) = [Ich, studiere] 정보를 담고 있음

벡터 A에는 "studiere"가 이미 생성되었다는 사실조차 들어있지 않습니다. 벡터 A를 선형 층에 넣으면 모델은 "Ich 다음에 올 단어는?"이라는 질문에 답하게 되고 그 답은 바로 "studiere"가 될 가능성이 높습니다. 이미 우리가 아는 단어죠.

반면 벡터 B는 "Ich studiere까지 봤을 때, 그 다음에 올 단어는?"이라는 질문에 해당합니다. 그 답이 우리가 원하는 Transformer입니다.

디코더의 각 위치 출력 벡터는 그 위치까지의 문맥을 보고 그 다음 단어를 예측하는 용도로 만들어집니다. 그래서 "n번째 다음 단어"를 예측하려면 "n번째 위치의 출력 벡터" 를 선형 층에 넣는 것이고, 현재 시점까지 생성된 마지막 단어의 위치가 곧 "다음 단어를 예측할 자리"입니다.

훈련할 때는 벡터 A도 버리지 않고 "studiere"를 맞추는 손실 함수에 사용되지만(모든 위치가 각자 다음 단어를 예측하도록 병렬 학습) 추론 시 새 단어를 뽑을 때는 마지막 위치의 벡터만 사용합니다.

전체 흐름 한 번에 보기

지금까지 본 디코더 블록 구조 → 마스크드 셀프 어텐션 → 크로스 어텐션 → FFN → 선형 층 → 소프트맥스 → 다음 단어 선택의 흐름을, 인코더와 합쳐서 한 장으로 정리하면 다음과 같습니다.

이렇게 뽑힌 다음 단어를 다시 디코더 입력 맨 뒤에 붙여 넣고, 같은 과정을 반복합니다. 문장 종결 토큰(<EOS>)이 나올 때까지 이 과정이 이어지면서 번역 문장이 완성됩니다.

정리

디코더 블록 = 마스크드 셀프 어텐션 + 크로스 어텐션 + FFN, 각 단계 뒤에 잔차 연결과 층 정규화
마스킹은 토큰을 빼는 게 아니라 어텐션 스코어 행렬의 오른쪽 위 삼각형을 -∞로 만드는 것. 토큰은 전부 들어가고 출력도 전부 나오지만 각 위치가 볼 수 있는 정보가 자기 자신과 그 이전 위치로 제한됨.
크로스 어텐션에서는 Q는 디코더, K·V는 인코더에서 옴. 인코더는 한 번만 돌고 그 최종 출력을 디코더 6개 블록이 모두 공유.
선형 층에 넣는 벡터는 항상 마지막 위치의 벡터. 마스킹 구조상 n번째 위치는 n번째까지 보고 n+1번째를 예측하는 용도로 만들어졌기 때문.

GPU는 어떻게 트랜스포머의 행렬 연산을 가속하는가

반달bear — Fri, 17 Apr 2026 17:58:54 +0900

들어가며

딥러닝 모델, 특히 트랜스포머(Transformer) 기반 모델을 학습시키거나 추론할 때 GPU가 CPU보다 훨씬 빠르다는 사실은 널리 알려져 있습니다. 하지만 "왜" 빠른지, 그리고 "어떻게" 빠른지를 구체적으로 설명하려고 하면 갑자기 막막해집니다. CUDA 코어, 텐서 코어, FP16, 혼합 정밀도, FLOPS, TFLOPS 같은 용어들이 줄줄이 등장하고, 각 용어의 의미를 찾다 보면 또 다른 낯선 용어를 만나게 됩니다.

이 글은 그 용어들을 한 자리에서 하나씩 풀어가며, 최종적으로는 "트랜스포머의 어텐션 연산이 GPU에서 왜 그렇게 빠르게 돌아가는가"라는 질문에 답하는 것을 목표로 합니다. CPU와 GPU의 내부 구조 차이부터 시작해서, 숫자를 표현하는 방식, 연산 유닛의 종류, 그리고 이것들이 트랜스포머의 행렬곱과 어떻게 맞물려 작동하는지까지 이어서 설명하겠습니다.

1. CPU와 GPU의 구조 차이

CPU의 내부 구조

CPU는 Central Processing Unit의 약자로, 컴퓨터의 중앙 처리 장치입니다. CPU 칩 안에는 여러 구성 요소가 들어 있는데, 대표적으로 다음과 같습니다.

첫째, 코어(core) 가 있습니다. 코어는 실제로 명령어를 실행하는 단위입니다. 예전에는 한 칩에 코어가 하나였지만, 지금은 4코어, 8코어, 16코어처럼 한 칩에 여러 개의 코어가 들어 있습니다. 각 코어는 독립적으로 프로그램의 명령어를 읽고 실행할 수 있기 때문에 코어가 많을수록 동시에 처리할 수 있는 작업이 많아집니다.

둘째, 코어 안에는 ALU(Arithmetic and Logical Unit, 산술 논리 장치) 가 있습니다. ALU는 덧셈, 뺄셈, 곱셈, 나눗셈 같은 사칙 연산과 AND, OR 같은 논리 연산을 실제로 수행하는 회로입니다.

셋째, 캐시 메모리(cache memory) 가 있습니다. CPU가 매번 RAM(주기억장치)까지 가서 데이터를 가져오면 속도가 느려지기 때문에, 자주 쓰는 데이터는 CPU 바로 옆의 작고 빠른 메모리에 보관해 둡니다. 이것이 캐시 메모리입니다. L1, L2, L3로 계층이 나뉘어 있고, L1이 가장 작고 가장 빠르며, L3가 상대적으로 크고 느립니다.

넷째, 제어 장치(control unit) 와 분기 예측기(branch predictor), 디스패처(dispatcher) 같은 복잡한 제어용 회로들이 있습니다. 이들의 역할은 다음에 어떤 명령어를 실행할지, 조건문에서 어느 쪽으로 분기할지, 각 명령어를 어느 연산 유닛에 보낼지를 결정하는 것입니다. 현대 CPU는 한 번에 여러 명령어를 파이프라인 방식으로 처리하면서 분기를 미리 예측해서 실행하기 때문에 이런 제어 회로가 전체 칩 면적의 상당 부분을 차지합니다.

CPU 코어 블록 다이어그램 읽는 법

CPU 코어 내부의 블록 다이어그램을 보면 보통 4~5개의 큰 영역으로 색이 나뉘어 있습니다. 각 영역이 하는 역할을 연결해서 보면 앞에서 설명한 구성 요소들이 어디에 해당하는지 한눈에 보입니다.

Front End (프론트엔드 영역): 다이어그램 위쪽에 크게 자리잡은 영역입니다. 이 안에는 Branch Predictor(분기 예측기, 때로는 L1 BTB, L2 BTB 같은 세부 표가 함께 표시됨), L1 Instruction Cache(명령어 캐시), Instruction Queue, Simple Decoder × 여러 개, μcode, Op Queue, Rename / Dispatch 같은 박스가 있습니다. 이 모든 것이 "다음에 어떤 명령어를 어떤 순서로 어디로 보낼지"를 결정하는 제어용 회로입니다. 즉, 넷째 항목에서 말한 복잡한 제어 장치가 다이어그램의 이 넓은 영역 전체에 해당합니다.
Execution Engine (실행 엔진 영역): 프론트엔드 아래, 중앙에 위치한 큰 회색 영역입니다. ReOrder Buffer, 여러 개의 Scheduler(ALU Scheduler, Branch Scheduler, Load Scheduler 등), 그리고 그 아래에 실제 연산을 수행하는 ALU, ALU Shift, ALU MUL DIV, Branch 박스들이 있습니다. 여기서 실제로 숫자를 더하고 곱하는 ALU는 전체 다이어그램에서 보면 의외로 작은 부분만 차지한다는 것을 볼 수 있습니다. ALU 몇 개를 움직이기 위해 그 위의 스케줄러와 리오더 버퍼가 훨씬 더 큰 공간을 쓰고 있습니다.
FP / Vector Execution (부동소수점/벡터 실행 영역): 왼쪽 아래의 파란색 영역입니다. Vector RF(벡터 레지스터 파일), 그리고 ALU, ALU MUL ADD AES SHA DIV 같은 부동소수점/SIMD 연산 유닛이 들어 있습니다. CPU에서 소수점 연산과 벡터 연산은 정수 ALU와는 별개의 유닛에서 처리됩니다.
Load / Store (데이터 입출력 영역): 오른쪽 아래의 주황색 영역입니다. Store Queue, Load Queue, L1 Data Cache(보통 32KiB 정도), DTLB 같은 박스가 있습니다. 연산 유닛이 필요로 하는 데이터를 메모리에서 가져오고, 결과를 다시 메모리로 내보내는 통로입니다.
Memory (메모리 영역): 가장 오른쪽에 위치한 분홍색 영역입니다. Shared L2 Cache(보통 2~4 MiB), L2 TLB가 있고, 그 위로 L3 캐시까지 이어지는 화살표가 붙어 있습니다. 셋째 항목에서 말한 캐시 계층이 바로 이 부분입니다.

이 다이어그램에서 가장 중요하게 볼 점은 "실제 계산을 수행하는 ALU가 전체 면적에서 차지하는 비율" 입니다. 숫자를 직접 더하고 곱하는 박스는 FP/Vector 영역의 ALU 몇 개와 Execution Engine 영역의 ALU 몇 개뿐이고, 나머지 대부분의 공간은 "그 ALU들을 효율적으로 쓰기 위한 제어 회로"가 차지하고 있습니다.

GPU의 내부 구조

GPU는 Graphics Processing Unit의 약자로, 원래는 그래픽을 렌더링하기 위해 만들어진 칩입니다. 화면에 나타나는 수백만 개의 픽셀에 대해 거의 같은 연산(색 계산, 변환 행렬 곱 등)을 동시에 수행해야 하기 때문에, 처음부터 "같은 연산을 엄청나게 많은 데이터에 동시에 적용"하는 용도로 설계되었습니다.

GPU의 가장 중요한 구조적 단위는 SM(Streaming Multiprocessor) 입니다. SM은 NVIDIA GPU에서 쓰는 용어이고, CPU의 "코어 하나"에 대응되는 모듈이라고 생각하면 됩니다. 즉, GPU 한 장에는 SM이 여러 개 있고, 각 SM은 독립적으로 동작할 수 있는 하나의 처리 단위입니다.

SM 내부에는 CPU의 코어와는 다른 비율로 회로가 배치되어 있습니다.

첫째, ALU가 매우 많습니다. CPU 한 코어에 ALU가 몇 개 들어 있는 정도라면, GPU의 SM 하나에는 수십 개에서 백여 개 단위의 ALU(NVIDIA 용어로는 CUDA 코어)가 들어 있습니다. 그래서 SM 하나만 봐도 같은 연산을 동시에 수십~백여 개 수행할 수 있습니다.

둘째, 제어 회로(디스패처, 분기 예측기 등)는 CPU보다 적습니다. GPU는 연산이라는 용도에 특화되어 있어서, 복잡한 분기 예측이나 정교한 명령 스케줄링이 덜 필요합니다. 그래서 제어 회로에 쓸 칩 면적을 줄이고 그만큼을 ALU에 더 할당하여서 연산 능력을 강화하였습니다.

셋째, SM 내부의 ALU들은 보통 4개의 묶음(처리 블록) 으로 그룹화되어 있습니다. 각 묶음은 한 번에 하나의 명령어 스트림을 받아서 그 안의 ALU들이 서로 다른 데이터에 대해 동시에 같은 연산을 수행하는 방식으로 동작합니다.

결과적으로 GPU가 잘하는 일은 같은 계산을 서로 다른 수많은 데이터에 동시에 적용하는 일입니다.

GPU SM 다이어그램 읽는 법

GPU SM 다이어그램을 처음 보면 CPU 다이어그램과 구조가 상당히 다릅니다. 위쪽에 얇게 L1 Instruction Cache가 하나 있고, 그 아래로 거의 똑같이 생긴 네 개의 블록이 2 × 2 격자 형태로 배치된 구조가 먼저 눈에 들어옵니다. 이 네 블록이 위에서 말한 4개의 처리 블록입니다. SM 한 개 안에서 네 개의 처리 블록이 독립적인 명령어 스트림을 받아 서로 다른 일을 동시에 진행합니다.

각 처리 블록의 안을 위에서 아래로 읽으면 다음과 같은 순서로 구성되어 있습니다.

L0 Instruction Cache: 그 블록에서 실행할 명령어를 잠깐 보관해 두는 가장 작은 캐시입니다.
Warp Scheduler (32 thread/clk): 워프(warp)는 32개의 스레드를 하나로 묶은 GPU의 기본 실행 단위입니다. 이 스케줄러가 "이번 클럭에는 어느 워프를 돌릴지"를 결정합니다. 즉, 32개의 스레드가 동시에 같은 명령어를 서로 다른 데이터에 대해 수행하도록 묶어서 보냅니다.
Dispatch Unit (32 thread/clk): 스케줄러가 선택한 명령어를 실제 연산 유닛들에게 분배하는 회로입니다.
Register File (16,384 × 32-bit): 블록 안의 모든 연산 유닛이 공유하는 고속 저장 공간입니다. ALU가 계산할 값을 꺼내고, 결과를 저장하는 곳입니다.
INT32, FP32, FP64 컬럼: 여기가 바로 ALU, 즉 CUDA 코어가 놓인 곳입니다. 초록색 점들로 빼곡히 채워진 세 개의 열이 눈에 들어오는데, 각각 "정수 연산용", "단정밀도 부동소수점용", "배정밀도 부동소수점용" CUDA 코어를 뜻합니다. 한 블록 안에 이런 유닛이 수십 개씩 줄지어 있고, 이것이 네 블록에 걸쳐 있으니 SM 하나 안의 CUDA 코어 총합이 백 단위로 금방 커집니다.
TENSOR CORE 4th GENERATION: 각 블록에서 INT32/FP32/FP64 컬럼 오른쪽에 크게 자리잡은 초록 박스입니다. 이것이 행렬곱 전용 연산 유닛인 텐서 코어이고, 세대별로 크기와 성능이 다릅니다. 다이어그램을 보면 CUDA 코어들과 거의 맞먹는 면적을 차지하고 있다는 점이 중요합니다. 최신 GPU로 올수록 텐서 코어가 칩 면적에서 차지하는 비중이 점점 커지고 있습니다.
LD/ST (Load/Store) 유닛과 SFU: 블록의 맨 아래쪽에 줄지어 있는 빨간색 박스들입니다. LD/ST 유닛은 메모리에서 데이터를 읽어오거나 쓰고, SFU(Special Function Unit)는 사인, 코사인, 제곱근, 역수 같은 특수 함수 연산을 담당합니다.

그리고 네 블록 아래 공통으로 자리잡은 영역이 또 있습니다.

Tensor Memory Accelerator (최신 세대에서 등장): 텐서 코어가 사용할 큰 행렬 데이터를 메모리에서 고속으로 옮겨주는 전용 회로입니다. 텐서 코어가 아무리 빨라도 데이터를 제때 공급하지 못하면 성능이 나오지 않기 때문에, 메모리 전송 자체를 담당하는 회로를 별도로 둔 것입니다.
256 KB L1 Data Cache / Shared Memory: SM 안의 네 블록이 함께 쓰는 데이터 캐시이자 공유 메모리입니다. 같은 SM 안의 스레드들은 이 공유 메모리를 통해 빠르게 데이터를 주고받을 수 있습니다.

이 다이어그램에서 가장 중요하게 볼 점은 CPU 다이어그램과의 비례 차이입니다. CPU 다이어그램에서는 실제 연산 유닛(ALU)이 전체에서 차지하는 비중이 매우 작았던 반면 GPU SM 다이어그램에서는 면적의 대부분을 연산 유닛(INT32/FP32/FP64 컬럼 + 텐서 코어)이 차지합니다. 제어 회로에 해당하는 워프 스케줄러와 디스패치 유닛은 각 블록의 맨 위에 얇은 띠처럼 있을 뿐입니다.

또 한 가지 짚어야 할 점은, 이 전체 다이어그램이 SM 하나에 불과하다는 사실입니다. 실제 GPU에는 이런 SM이 수십에서 백 개 이상 들어 있습니다. 예를 들어 H100에는 SM이 132개 있고, RTX 3060에는 SM이 28개 있습니다. 다이어그램 한 장 분량의 구조가 수십 번 복제되어 있는 셈이라, GPU 전체로 보면 연산 유닛의 수가 수천~수만 개 단위가 됩니다.

왜 GPU가 딥러닝에 유리한가

딥러닝 모델의 핵심 연산은 대부분 행렬과 벡터의 곱셈, 그리고 그에 수반되는 덧셈입니다.

여기서 행렬(matrix)은 숫자를 직사각형으로 배열한 표이고, 벡터(vector)는 한 줄짜리 행렬이라고 생각하면 됩니다. 예를 들어 [1, 2, 3]은 길이 3짜리 벡터이고, 아래 같은 것은 2행 3열의 행렬입니다.

[1, 2, 3]
[4, 5, 6]

행렬곱 A × B는 A의 각 행과 B의 각 열을 짝지어서 대응되는 원소끼리 곱한 뒤 그 결과를 모두 더하는 방식으로 계산됩니다. 결과 행렬의 원소 하나를 구하는 데만 해도 여러 번의 곱셈과 덧셈이 필요하고 결과 행렬의 모든 원소를 구하려면 그 연산이 어마어마하게 반복됩니다.

중요한 점은 각 원소를 구하는 계산이 서로 독립적이라는 것입니다. 결과 행렬의 (1,1) 원소를 구하는 계산과 (2,3) 원소를 구하는 계산은 서로 영향을 주지 않습니다. 그래서 GPU처럼 같은 연산을 수많은 데이터에 동시에 적용하는 구조가 행렬곱에 아주 잘 맞습니다. 수천 개의 ALU가 동시에 결과 행렬의 서로 다른 원소들을 계산하고 마지막에 합치면 행렬곱이 끝납니다.

반면 CPU는 코어 수가 적어서 동시에 처리할 수 있는 곱셈-덧셈의 개수가 훨씬 적고 큰 행렬 하나를 계산하는 데도 상대적으로 긴 시간이 걸립니다.

CPU가 "이 큰 행렬곱을 해줘"라고 GPU에 작업을 던지면, GPU가 그 대규모 계산을 맡아서 빠르게 처리한 뒤 결과를 돌려줍니다. 딥러닝 프레임워크(PyTorch, TensorFlow 등)가 내부적으로 이런 역할 분담을 처리해 줍니다.

2. FLOPS: 연산 능력을 재는 단위

CPU와 GPU의 성능을 비교할 때 가장 자주 등장하는 단위가 FLOPS입니다. FLOPS는 FLoating-point Operations Per Second의 약자로, 초당 수행할 수 있는 부동소수점 연산의 횟수를 뜻합니다.

여기서 "부동소수점 연산"이란 소수점이 있는 숫자(예: 3.14, 0.0001, -2.5 등)를 더하거나 곱하는 연산을 말합니다. 딥러닝의 모든 계산은 부동소수점 연산으로 이루어지기 때문에, FLOPS는 곧 "이 하드웨어가 1초에 얼마나 많은 딥러닝 계산을 할 수 있는가"를 나타내는 지표가 됩니다.

숫자가 너무 크기 때문에 보통은 접두어를 붙여서 표기합니다.

GFLOPS (Giga FLOPS): 10⁹, 즉 초당 10억 번의 부동소수점 연산
TFLOPS (Tera FLOPS): 10¹², 즉 초당 1조 번의 부동소수점 연산
PFLOPS (Peta FLOPS): 10¹⁵, 즉 초당 1000조 번의 부동소수점 연산

참고로 정수 연산만 세는 경우에는 TOPS(Tera Operations Per Second) 라는 단위를 씁니다. 정수는 부동소수점보다 단순해서 연산 속도가 빠른데 이 구분은 뒤에서 INT8 설명할 때 다시 나옵니다.

구체적인 수치로 비교해 보면 차이가 분명합니다. 한 세대 최상급 CPU인 Intel Core i9-12900KF의 이론적 최대 성능은 약 800 GFLOPS 수준, 즉 0.8 TFLOPS 정도입니다. 반면 데이터센터용 GPU인 NVIDIA H100은 FP16 기준 약 1,000 TFLOPS에 달합니다. 약 1,000배 이상 차이가 나는 셈입니다.

3. 숫자를 표현하는 방법: FP32, FP16, INT8

비트와 정밀도의 관계

컴퓨터는 모든 숫자를 0과 1의 조합, 즉 이진수로 표현합니다. 이때 하나의 숫자를 저장하는 데 몇 비트를 사용하느냐에 따라 표현할 수 있는 값의 범위와 정밀도(precision) 가 달라집니다.

비트(bit)는 0 또는 1 중 하나를 저장하는 최소 단위입니다. 1비트로는 2가지(0 또는 1), 2비트로는 4가지(00, 01, 10, 11), n비트로는 2ⁿ가지의 서로 다른 값을 표현할 수 있습니다. 비트 수가 많을수록 한 숫자를 더 섬세하게 표현할 수 있지만, 그만큼 메모리를 더 많이 차지하고 연산 회로도 더 복잡해집니다.

부동소수점 형식의 구조

부동소수점(floating-point) 형식은 과학적 표기법과 비슷한 방식으로 소수를 표현합니다. 예를 들어 3.14를 3.14 × 10⁰처럼 "유효숫자 × 기수^지수" 형태로 표현하는 방식을 이진수로 확장한 것입니다. 부동소수점 숫자는 크게 세 부분으로 나뉩니다.

부호 비트: 양수(0)인지 음수(1)인지를 나타내는 1비트
지수 비트: 숫자가 얼마나 큰지/작은지를 나타내는 부분. 비트 수가 많을수록 표현할 수 있는 숫자의 범위가 넓어집니다.
가수 비트(유효숫자): 실제 숫자의 정밀한 값을 나타내는 부분. 비트 수가 많을수록 소수점 아래를 더 정확하게 표현할 수 있습니다.

이 세 부분에 각각 몇 비트를 할당하느냐에 따라 다양한 부동소수점 형식이 만들어집니다.

딥러닝에서 자주 마주치는 세 가지 형식은 다음과 같습니다

FP32 (32비트 부동소수점, 단정밀도)

부호 1비트 + 지수 8비트 + 가수 23비트
전통적으로 과학 계산과 딥러닝에서 표준으로 쓰이는 형식
넓은 범위와 높은 정밀도를 동시에 제공

FP16 (16비트 부동소수점, 반정밀도)

부호 1비트 + 지수 5비트 + 가수 10비트
FP32의 딱 절반 크기
메모리도 절반, 연산에 쓰는 회로도 단순해서 속도가 빠름
대신 표현 범위와 정밀도가 줄어듦

INT8 (8비트 정수)

부동소수점이 아니라 정수로 값을 표현
가장 작은 8비트만 사용하므로 가장 빠르고 가장 적은 메모리를 차지
소수점 이하가 없으므로 그대로 쓸 수 없고, 별도의 변환(양자화, quantization) 과정을 거침
주로 학습이 끝난 모델을 추론(inference, 이미 학습된 모델로 예측값을 뽑는 과정) 할 때 사용

숫자로 보는 정밀도 차이

같은 값을 각 형식으로 저장하면 어떤 차이가 나는지 살펴보겠습니다. 원주율 3.14159265358979… 를 저장할 때,

FP32로 저장: 약 3.14159274 — 소수점 아래 6~7자리까지 정확
FP16으로 저장: 약 3.140625 — 소수점 아래 2~3자리까지만 정확, 뒤쪽은 반올림/버림됨
INT8로 저장: 3 — 정수만 저장되므로 소수점 이하가 전부 사라짐

왜 딥러닝은 낮은 정밀도로도 괜찮은가

"소수점 이하가 이렇게 잘려나가는데 학습이 제대로 되나?"라는 의문이 생길 수 있습니다. 그러나 딥러닝 모델은 수치의 미세한 오차에 생각보다 강합니다.

이유는 두 가지입니다. 첫째, 딥러닝의 가중치(weight, 신경망이 학습하는 매개변수) 값 자체가 아주 작은 실수들이고, 그 값들은 학습 과정에서 매 스텝마다 업데이트됩니다. 예를 들어 어떤 가중치가 0.123456789인지 0.123456인지는 모델의 최종 성능에 거의 영향을 주지 않습니다. 어차피 다음 업데이트에서 그 값이 또 조금 바뀌기 때문입니다.

둘째, 어텐션 가중치처럼 확률적으로 정규화되는 값들도 마찬가지입니다. 어떤 두 단어 사이의 어텐션 가중치가 0.0723이든 0.0720이든, 예측 결과는 거의 똑같이 나옵니다.

그래서 현대 딥러닝에서는 "정확도를 유지할 수 있는 만큼 최대한 낮은 정밀도로 계산하자"는 전략이 표준이 되었습니다. 이 전략의 대표적인 형태가 뒤에서 다룰 혼합 정밀도(mixed precision) 입니다.

4. CUDA 코어와 텐서 코어: 두 종류의 연산 유닛

GPU의 SM 안에는 두 종류의 연산 유닛이 들어 있습니다. CUDA 코어와 텐서 코어입니다.

CUDA 코어

CUDA(Compute Unified Device Architecture) 는 NVIDIA가 만든 GPU 프로그래밍 플랫폼의 이름이고, CUDA 코어는 그 플랫폼에서 프로그램이 실행되는 기본 연산 유닛을 가리킵니다. 앞에서 설명한 SM 안의 ALU가 바로 CUDA 코어입니다.

CUDA 코어의 특징은 범용성입니다. 덧셈, 곱셈, 비교, 형 변환 같은 다양한 연산을 할 수 있고, 프로그램에서 지시하는 대로 자유롭게 사용됩니다. 다만 한 번에 할 수 있는 일은 "숫자 하나에 대한 연산 하나"입니다. 한 CUDA 코어는 한 클럭 사이클에 한 번의 부동소수점 연산(덧셈 한 번, 또는 곱셈 한 번, 또는 경우에 따라 곱셈-덧셈 한 번)을 수행합니다.

여기서 클럭 사이클(clock cycle) 은 GPU가 한 번 신호를 내보내는 기본 시간 단위입니다. CUDA 코어 하나가 1 GHz 클럭에서 동작한다면, 초당 10억 번의 연산을 처리한다고 보시면 됩니다. 흔하게 아시는 RTX 3060에는 3,584개의 CUDA 코어가 들어 있습니다. 이 3,584개가 동시에 작동하면서 서로 다른 데이터에 대해 병렬로 연산을 수행합니다.

간단한 2×2 행렬곱을 예로 들어 CUDA 코어가 어떻게 작동하는지 보겠습니다.

[1, 2]   [5, 6]   [1×5+2×7, 1×6+2×8]   [19, 22]
[3, 4] × [7, 8] = [3×5+4×7, 3×6+4×8] = [43, 50]

결과 행렬의 원소 하나, 예를 들어 19 = 1×5 + 2×7을 구하려면 곱셈 2번 + 덧셈 1번 = 총 3번의 연산이 필요합니다. 결과 행렬에 원소가 4개이므로, 2×2 행렬곱 전체에는 4 × 3 = 12번의 연산이 필요합니다.

CUDA 코어는 이 12번의 연산을 하나씩 처리합니다. 여러 CUDA 코어가 서로 다른 원소를 맡아 병렬로 진행할 수 있지만, 각 코어가 한 번에 하는 일은 어디까지나 "숫자 하나 × 숫자 하나" 또는 "숫자 하나 + 숫자 하나" 수준입니다. 결과 행렬의 원소 4개를 CUDA 코어 4개에 하나씩 배정해도, 각 코어는 3번의 연산을 순차적으로 수행해야 합니다.

텐서 코어

텐서 코어(Tensor Core) 는 행렬곱에 특화된 전용 연산 유닛입니다. 2017년 NVIDIA의 Volta 아키텍처(V100)에서 처음 도입된 이후, 세대를 거치며 발전해 왔습니다.

텐서 코어의 가장 큰 특징은 작은 행렬 단위를 한 번에 곱하고 더한다는 것입니다. CUDA 코어가 숫자 하나에 대해 연산 하나를 하는 것과 대비됩니다. 예를 들어 RTX 3060의 3세대 텐서 코어는 8×4×8 크기의 행렬 연산을 1 클럭 사이클에 처리합니다(정확한 형식은 뒤에서 다룹니다).

텐서 코어가 수행하는 기본 연산은 다음과 같은 형태입니다.

D = A × B + C

여기서 A, B, C, D는 모두 행렬입니다. 두 행렬 A와 B를 곱하고, 그 결과에 행렬 C를 더해서 D에 저장하는 연산을 한 번에 수행합니다. 이렇게 곱셈과 덧셈을 묶어서 한 번에 처리하는 것을 FMA(Fused Multiply-Add, 융합 곱셈-덧셈) 연산이라고 합니다.

FMA 연산이 중요한 이유는 두 가지입니다. 첫째, 곱셈과 덧셈을 따로 수행할 때보다 하드웨어 회로가 단순해지고 속도가 빨라집니다. 둘째, 중간 결과를 반올림 없이 더 높은 정밀도로 누적할 수 있어서, 같은 연산을 CUDA 코어로 나눠서 할 때보다 수치적으로 더 정확합니다.

RTX 3060에는 112개의 3세대 텐서 코어가 탑재되어 있습니다.

5. RTX 3060의 실제 성능

같은 RTX 3060 GPU라도 어떤 연산 유닛을 쓰고 어떤 정밀도로 계산하느냐에 따라 성능이 크게 달라집니다. 공식 스펙을 기준으로 정리하면 다음과 같습니다.

정밀도	연산 유닛	성능
FP32 (32비트)	CUDA 코어	약 12.7 TFLOPS
FP16 (16비트)	텐서 코어 (dense)	약 25.5 TFLOPS
FP16 (16비트)	텐서 코어 (sparsity)	약 51 TFLOPS
INT8 (8비트)	텐서 코어 (dense)	약 102 TOPS

TFLOPS: 앞서 설명한 Tera FLOPS. 초당 1조 번의 부동소수점 연산.
TOPS: 초당 1조 번의 정수 연산. INT8처럼 정수 연산인 경우 FLOPS 대신 TOPS로 표기합니다.
dense(밀집): 행렬에 0이 아닌 값들이 빽빽하게 들어 있는 일반적인 경우.
sparsity(희소성 가속): 행렬에 0이 많은 경우, 0인 부분의 연산을 건너뛰어 속도를 두 배로 올리는 NVIDIA의 하드웨어 기능. Ampere 세대(RTX 30시리즈)부터 지원됩니다. 정확히는 "2:4 희소성 패턴"을 만족하도록 모델을 조정해야 적용됩니다.

이 표가 의미하는 바는 이렇습니다. 가장 단순한 FP32 + CUDA 코어 조합과 비교했을 때, FP16 + 텐서 코어는 약 2배, 희소성 가속까지 적용하면 약 4배, INT8까지 내려가면 약 8배 빨라집니다. 같은 그래픽 카드인데도 "숫자를 몇 비트로 표현하는가", "어떤 연산 유닛에 작업을 보내는가"라는 두 가지 선택만으로 체감 성능이 수 배씩 차이 납니다.

6. 텐서 코어는 행렬을 어떻게 한 번에 처리하는가

4×4 행렬 FMA가 기본 단위

텐서 코어가 수행하는 연산을 좀 더 구체적으로 들여다보면 다음과 같습니다. 1세대 텐서 코어를 기준으로 할 때, 텐서 코어 하나는 한 클럭에 다음 연산을 수행합니다.

D = A × B + C

여기서 A와 B는 4×4 크기의 FP16 행렬, C와 D는 4×4 크기의 FP32 행렬입니다. 즉, 곱셈은 낮은 정밀도인 FP16으로 빠르게 수행하고, 누적(덧셈)은 높은 정밀도인 FP32로 수행합니다. 이렇게 서로 다른 정밀도를 섞어서 쓰는 방식을 혼합 정밀도(mixed precision) 라고 합니다. 곱셈은 수치 오차에 상대적으로 덜 민감하기 때문에 FP16으로 빠르게 처리하고, 여러 번의 곱셈 결과를 쌓아 올리는 덧셈 단계는 오차가 누적되기 쉬우므로 FP32로 정확하게 유지하는 것입니다.

4×4 행렬곱은 총 몇 번의 연산일까요? 결과 행렬의 원소 하나를 구하려면 곱셈 4번 + 덧셈 3번 = 7번이 필요하고, 일반적으로 "곱셈 1번 + 덧셈 1번"을 한 번의 연산으로 취급합니다. 4×4 행렬곱은 총 64번의 곱셈과 64번의 덧셈, 합쳐서 128번의 부동소수점 연산 에 해당합니다.

CUDA 코어로 같은 연산을 하면 128 클럭이 필요하지만, 텐서 코어 하나는 이걸 1 클럭에 끝냅니다. 단순 계산으로는 128배의 속도 향상입니다.

세대별 텐서 코어의 발전

텐서 코어는 NVIDIA GPU 세대가 올라갈수록 더 큰 행렬을 한 번에 처리할 수 있게 되었고, 지원하는 정밀도도 다양해졌습니다.

GPU	세대	텐서 코어당 행렬 크기	클럭당 FP16 연산 수	지원 정밀도
V100 (데이터센터)	1세대	4×4×4	128 FLOPS	FP16
RTX 3060 (게이밍)	3세대	8×4×8	512 FLOPS	FP16, BF16, TF32, INT8, INT4
H100 (데이터센터)	4세대	8×4×16	1024 FLOPS	FP16, BF16, TF32, FP8, INT8

표에서 "텐서 코어당 행렬 크기"의 A×B×C 표기는 "A행 × B열" 행렬과 "B행 × C열" 행렬의 곱을 한 번에 처리한다는 뜻입니다. 즉, 입력 행렬의 모양이 커질수록 한 번에 더 많은 연산을 할 수 있고, 그만큼 클럭당 처리하는 연산 수가 늘어납니다.

BF16 (bfloat16, Brain Floating Point 16): 부호 1비트 + 지수 8비트 + 가수 7비트. FP16과 달리 지수 부분이 FP32와 동일하게 8비트입니다. 덕분에 표현 범위가 FP32만큼 넓어서 학습 과정에서 값이 너무 커지거나 작아져 발생하는 문제에 덜 취약합니다. 대신 가수가 7비트뿐이라 정밀도는 낮습니다.
TF32 (TensorFloat-32): 이름은 32인데 실제로는 19비트만 사용하는 형식. 부호 1비트 + 지수 8비트(FP32와 동일) + 가수 10비트(FP16과 동일). FP32처럼 보이지만 내부적으로는 더 빠르게 처리할 수 있는 형식입니다.
FP8: 지수/가수 배분을 다르게 한 두 가지 변형(E4M3, E5M2)이 있는 8비트 부동소수점.
INT4: 4비트 정수. 주로 초경량 추론에 사용.

1세대와 4세대를 비교하면 텐서 코어 하나의 처리량이 약 8배 늘어났습니다. RTX 3060의 3세대 텐서 코어는 1세대 대비 한 클럭에 4배 많은 연산을 수행하는 셈입니다.

7. 트랜스포머 어텐션과 텐서 코어의 연결

어텐션에서 가장 무거운 연산

트랜스포머에서 가장 연산량이 많은 부분은 어텐션(attention) 메커니즘의 Q · K 행렬곱입니다. (이전 게시글에서 상세하게 다루었습니다

트랜스포머는 입력 문장을 토큰으로 만듭니다.
각 토큰을 벡터로 바꾼 뒤, 이 벡터들에서 쿼리, 키, 값 이라는 세 종류의 벡터를 만듭니다. Q, K, V는 각각 선형 변환(하나의 행렬곱)으로 생성됩니다.
어텐션의 핵심 계산은 "각 토큰의 Q가 다른 모든 토큰의 K와 얼마나 닮았는지"를 내적(두 벡터의 유사도 계산)으로 구하고, 이 결과를 바탕으로 V의 가중합을 만드는 것입니다.

이 때 Q와 K는 각각 "토큰 개수 × 차원(토큰 하나를 몇 개의 숫자로 표현할 수 있는가)" 크기의 행렬로 표현할 수 있기 때문에,"행렬 x 행렬"로, 하나의 큰 행렬곱으로 계산됩니다.

차원을 그대로 두고, 토큰의 관점에서, 한 번에 처리하는 토큰의 개수를 n이라고 하면, 이 행렬곱의 결과는 n×n 크기의 행렬이 됩니다. 연산량은 토큰 개수의 제곱에 비례해서 커지므로 O(n²) 의 복잡도를 갖습니다. 문장이 2배 길어지면 연산량은 4배, 4배 길어지면 16배가 된다는 뜻입니다.

문서 수준의 긴 문장을 다루는 최신 모델일수록 이 부분의 연산 비용이 전체 성능을 좌우합니다.

큰 행렬을 작은 타일로 쪼개는 기법

그런데 문제는, 텐서 코어가 한 번에 처리하는 단위는 고작 4×4 또는 8×4×8 같은 작은 행렬이라는 것입니다. 시퀀스 길이가 2048이면 Q × Kᵀ는 2048×2048짜리 결과를 만들어야 하는데, 이걸 어떻게 작은 텐서 코어 단위로 처리할까요?

답은 타일링(tiling) 입니다. 큰 행렬을 작은 블록으로 쪼갠 뒤, 각 타일 단위의 작은 행렬곱을 수많은 텐서 코어에 분배해서 동시에 처리하고, 그 결과를 합쳐서 전체 행렬곱을 완성하는 방식입니다.

예를 들어 2048×2048 행렬곱을 16×16 타일로 쪼개면, 가로로 128개, 세로로 128개, 총 16,384개의 타일이 만들어집니다. 각 타일의 결과는 독립적으로 계산할 수 있으므로, GPU의 수백 개 텐서 코어에 골고루 분배되어 병렬로 처리됩니다. cuBLAS, cuDNN 같은 NVIDIA의 라이브러리가 이런 타일링을 자동으로 최적화해서 수행해 줍니다.

이 타일링이 가능한 이유는 행렬곱의 연산을 블록 단위로 분해 가능하기 때문입니다. 큰 행렬곱은 작은 행렬곱의 합으로 정확하게 표현될 수 있습니다.

멀티헤드 어텐션과 배치 행렬곱

트랜스포머의 멀티 어텐션에서는 여러 개의 헤드를 사용합니다. 헤드가 8개라면, 같은 입력을 8번 서로 다른 관점으로 처리하고, 그 결과를 합치는 방식입니다. 각 헤드는 서로 독립적으로 자기만의 Q, K, V 행렬곱을 수행합니다.

각 헤드의 연산은 서로 영향을 주지 않기 때문에 GPU는 헤드 개수만큼의 독립된 행렬곱을 동시에 수행할 수 있습니다. GPU의 성능은 특정 코어가 놀지 않고 모두 일할 때 최대가 되는데 헤드 사이에 데이터를 주고받을 필요가 없으므로 수백 개의 텐서 코어에 작업을 균등하게 분배하게 되어 효율적입니다.

8. 혼합 정밀도 학습: 낮은 정밀도를 보완하는 법

앞서 텐서 코어가 FP16으로 곱하고 FP32로 누적한다는 이야기를 했습니다. 이 원리를 학습 전체로 확장한 것이 혼합 정밀도(mixed precision) 학습입니다.

혼합 정밀도 학습의 기본 아이디어는 이렇습니다.

순전파(forward pass)와 역전파(backward pass)의 행렬곱: FP16으로 빠르게 계산. 여기가 전체 연산의 대부분을 차지하는 곳이기 때문에 이곳의 속도를 올리는 것이 가장 효과적입니다.
가중치 업데이트와 손실 스케일링: FP32로 정확하게 유지. 가중치가 업데이트될 때 값이 아주 작은 변화량이 누적되는데, 이 부분을 FP16으로 하면 너무 작은 변화량이 반올림돼서 사라지는 문제가 생깁니다. 그래서 "마스터 가중치"라고 부르는 FP32 복사본을 따로 두고, 업데이트는 그 복사본에 대해 수행합니다.

여기서 몇 가지 용어를 정리하면 다음과 같습니다.

순전파(forward pass): 입력 데이터를 신경망에 통과시켜 예측값을 계산하는 과정.
역전파(backward pass): 예측이 정답과 얼마나 다른지를 계산한 뒤, 그 오차를 이용해 각 가중치를 얼마나 조정해야 할지 구하는 과정.
손실 스케일링(loss scaling): FP16은 표현 범위가 좁아서, 역전파 과정에서 아주 작은 값이 0으로 반올림되는 언더플로(underflow) 문제가 자주 발생합니다. 이를 막기 위해 손실(loss) 값에 큰 수(예: 1024)를 곱해서 역전파를 수행한 뒤, 가중치를 업데이트하기 직전에 다시 나눠주는 기법입니다.

이 전략 덕분에 혼합 정밀도 학습은 다음과 같은 효과를 냅니다.

학습 속도가 2~3배 빨라짐 (주로 텐서 코어가 활용되기 때문)
GPU 메모리 사용량이 절반 가까이 줄어듦 (중간 활성화값이 FP16이므로)
최종 모델의 성능은 FP32 학습과 거의 동일하게 유지됨

PyTorch에서는 torch.cuda.amp(Automatic Mixed Precision) 모듈을 사용하면 몇 줄의 코드만으로 혼합 정밀도 학습을 켤 수 있습니다.

9. 데이터센터 GPU vs 게이밍 GPU

같은 NVIDIA GPU라도 데이터센터용과 게이밍용은 규모가 꽤 다릅니다. 텐서 코어의 기본 원리와 아키텍처는 거의 같지만, 탑재된 양과 보조 구성 요소가 다릅니다.

항목	RTX 3060 (게이밍)	A100 (데이터센터)	H100 (데이터센터)
텐서 코어 수	112개	432개	528개
FP16 텐서 성능	~51 TFLOPS	~312 TFLOPS	~990 TFLOPS
GPU 메모리	12GB GDDR6	80GB HBM2e	80GB HBM3
메모리 대역폭	360 GB/s	2,039 GB/s	3,350 GB/s
용도	소규모 추론, 학습 실험	대규모 학습	초대규모 학습

GDDR6, HBM2e, HBM3: GPU에 장착되는 고속 메모리의 종류입니다. GDDR은 게이밍 GPU에 주로 쓰이고, HBM(High Bandwidth Memory)은 데이터센터 GPU에 쓰이는 초고대역폭 메모리입니다. 같은 용량이라도 HBM이 훨씬 빠르고 그만큼 단가도 높습니다.
메모리 대역폭(memory bandwidth): 초당 GPU 메모리에서 연산 유닛으로 얼마나 많은 데이터를 옮길 수 있는지를 나타내는 값. 단위는 GB/s입니다. 딥러닝은 엄청난 양의 데이터를 계속 메모리에서 꺼내 써야 하기 때문에 연산 유닛이 아무리 빨라도 메모리 대역폭이 따라오지 못하면 성능이 안 나옵니다.

GPT 시리즈나 LLaMA 같은 대규모 언어 모델의 사전학습(pre-training)에는 A100이나 H100이 수백에서 수천 장 사용됩니다. 단일 GPU로는 모델이 메모리에 들어가지도 않고 학습 시간도 수십 년 단위가 되기 때문입니다.

반면 RTX 3060만 있어도 다음과 같은 일은 충분히 가능합니다.

소규모 모델(수백만~수천만 파라미터)의 처음부터 학습
공개된 대형 모델의 파인튜닝(fine-tuning, 기존에 학습된 모델을 특정 작업에 맞게 추가 학습), 특히 LoRA처럼 일부 파라미터만 학습하는 기법
대형 모델의 양자화(quantization) 추론. INT8이나 INT4로 변환된 모델이라면 12GB 메모리 안에서도 꽤 큰 모델이 돌아갑니다.

텐서 코어의 원리 자체는 RTX 3060이나 H100이나 같습니다.

정리

정리하자면, GPU가 트랜스포머를 빠르게 처리할 수 있는 이유는 단 하나의 기술 때문이 아닙니다. 구조적으로는 수많은 ALU를 가진 SM들이 있고 그 안에 행렬곱 전용인 텐서 코어가 있으며이 텐서 코어가 FP16 같은 낮은 정밀도로 빠르게 곱하고 FP32로 누적합니다. 소프트웨어 수준에서는 혼합 정밀도 학습과 타일링, 배치 행렬곱 같은 기법이 이 하드웨어를 최대한 활용합니다. 그리고 트랜스포머의 멀티헤드 어텐션 기법의 병렬성이 GPU에서 효율적이기에 GPU를 사용하고 있는 것입니다.

출처

Mixed Precision Training. https://arxiv.org/abs/1710.03740
Accelerating AI Training with TF32 Tensor Cores. https://developer.nvidia.com/blog/accelerating-ai-training-with-tf32-tensor-cores/
Using Tensor Cores for Mixed-Precision Scientific Computing. https://developer.nvidia.com/blog/tensor-cores-mixed-precision-scientific-computing/
Harnessing GPU Tensor Cores for Fast FP16 Arithmetic to Speed up Mixed-Precision Iterative Refinement Solvers. https://www.netlib.org/utk/people/JackDongarra/PAPERS/haidar_fp16_sc18.pdf
RTX 3060 스펙 https://www.nvidia.com/en-us/geforce/graphics-cards/30-series/rtx-3060-3060ti/
CPU와 GPU의 차이, 그리고 딥러닝. https://yozm.wishket.com/magazine/detail/2294/

에어갭 환경에서 Kubespray로 Kubernetes 클러스터 설치하기

반달bear — Wed, 15 Apr 2026 20:10:22 +0900

배경

온프레미스 환경에서 인터넷이 완전히 차단된 상태, 에어갭(air-gap) 환경에서 쿠버네티스를 설치하는 방법에 대한 포스팅입니다.

https://drive.google.com/drive/folders/1WsFwJxH0P3-fV5r5VvyUQ-nW9u-wBsEj?usp=sharing (다운로드)

환경

구분	호스트명	OS	IP
Master	master	Rocky 8.10	192.168.59.11
Worker1	node1	Rocky 8.10	192.168.59.21
Worker2	node2	Rocky 8.10	192.168.59.22

에어갭 환경을 재현하기 위해 VM을 위와 같이 세팅합니다.

VM들은 NAT Network로 묶고
로컬 터미널에서 접근하기 위해 22번 포트로 포트포워딩 설정을 해줍니다.
DNS를 비활성화하여 외부 통신이 차단된 상태로 준비합니다.

# 모든 VM에서 블랙홀 DNS 설정 (외부 resolve 차단)
for host in master node1 node2; do
  ssh $host "echo 'nameserver 192.0.2.1' > /etc/resolv.conf"
done

쿠버네티스는 Kubespray로 설치하고, 오프라인에 필요한 rpm, pip, 바이너리, 컨테이너 이미지는 사전에 빌드해서 /root/kubespray-offline-build/ 아래에 준비해둔 상태입니다.

이 링크를 참고하시면 컨테이너 이미지를 포함한 kubespray-offline-build를 받을 수 있습니다.

1단계: 노드 사전 준비

설치 전에 모든 노드에서 공통으로 해줘야 하는 작업들이 있습니다. SSH 키 교환, 방화벽 해제, 스왑 비활성화, 시간 동기화 설정입니다.

# SSH 키 생성 및 교환 (master에서만 진행주셔도 됩니다)
ssh-keygen -t rsa -f ~/.ssh/id_rsa
ssh-copy-id -i ~/.ssh/id_rsa.pub root@master
ssh-copy-id -i ~/.ssh/id_rsa.pub root@node1
ssh-copy-id -i ~/.ssh/id_rsa.pub root@node2

# 방화벽 해제
for host in master node1 node2; do
  ssh $host "sudo systemctl stop firewalld && sudo systemctl disable firewalld"
  ssh $host "sudo iptables -F"
  ssh $host "sudo nft flush ruleset"
done

# 스왑 비활성화
for host in master node1 node2; do
  ssh $host "sudo swapoff -a && sudo sed -i '/swap/d' /etc/fstab"
done

# 시간 동기화 (master 기준으로 맞춤)
MASTER_TIME=$(date '+%Y-%m-%d %H:%M:%S')
for host in node1 node2; do
  ssh $host "timedatectl set-ntp false; date -s '${MASTER_TIME}'; hwclock --systohc"
done

SSH 키는 Kubespray(Ansible)가 master에서 각 노드에 접속해서 명령을 실행하기 위해 필요합니다. 나중에 나올 파일 서버와는 별개의 목적입니다.

2단계: RPM 패키지 설치 및 온라인 repo 차단

사전에 빌드해둔 RPM 패키지를 모든 노드에 설치합니다. 설치 후에는 yum repo를 비활성화해서 온라인 저장소로 접근하지 못하게 막아야 합니다. 에어갭 환경에서 온라인 repo가 활성화되어 있으면 Kubespray 실행 중에 타임아웃이 걸릴 수 있습니다.

# yum repo 온라인 비활성화
for host in master node1 node2; do
  ssh $host "sudo sed -i 's/enabled=1/enabled=0/g' /etc/yum.repos.d/*.repo"
done

# RPM 파일 복사
cp -r /root/kubespray-offline-build/rpms/ /root/rpms

for host in node1 node2; do
  ssh $host "mkdir -p /root/rpms"
  scp /root/rpms/*.rpm $host:/root/rpms
done

# 모든 노드에 설치
for host in master node1 node2; do
  ssh $host "sudo rpm -Uvh --force /root/rpms/*.rpm"
done

rpm -Uvh에서 -U는 이미 설치되어 있으면 업그레이드, 없으면 새로 설치하는 옵션입니다. -v는 상세 출력, -h는 진행률 표시입니다.

3단계: Kubespray 의존성 설치 (master만)

해당 Kubespray는 Python 3.9 이상을 요구합니다.

Rocky 8.10에는 Python 3.6이 기본으로 설치되어 있는데 이 버전으로는 Kubespray가 동작하지 않기 때문에 Python 3.9을 별도로 설치해줘야 합니다.

# Python 3.9 설치
rpm -Uvh --force /root/kubespray-offline-build/python39_rpms/*.rpm
python3.9 -m ensurepip --default-pip

# SELinux 바인딩 연결 (시스템 Python이 3.6인 경우)
ln -s /usr/lib64/python3.6/site-packages/selinux \
      /usr/lib64/python3.9/site-packages/selinux
ln -s /usr/lib64/python3.6/site-packages/_selinux.cpython-36m-x86_64-linux-gnu.so \
      /usr/lib64/python3.9/site-packages/_selinux.so

# pip 오프라인 설치
python3.9 -m pip install --no-index \
  --find-links /root/kubespray-offline-build/pip \
  -r /root/kubespray-offline-build/kubespray/requirements_main.txt

--no-index는 PyPI 같은 온라인 저장소를 참조하지 않겠다는 의미이고, --find-links는 로컬에 있는 whl 파일들을 참조하라는 의미입니다.

4단계: 파일 서버 구축 (master)

Kubespray가 쿠버네티스를 설치할 때 kubelet, kubeadm, etcd 같은 바이너리를 다운로드해야 합니다. 내부 플레이북이 curl/wget으로 URL에서 받아오는 방식이라, 이 바이너리들을 HTTP로 서빙해주는 파일 서버가 필요합니다. Kubespray가 node1에 "kubelet 바이너리를 다운로드해라"라고 명령을 보내면, node1이 HTTP로 어딘가에서 받아와야 하고 파일 서버에서 바이너리를 받아옵니다.

cd /root/kubespray-offline-build/files
nohup python3.9 -m http.server 8080 &

간단하게 Python HTTP 서버로 올립니다.

5단계: containerd 수동 설치 (master)

containerd는 컨테이너를 실제로 만들고 실행하는 런타임입니다. 다음 단계에서 레지스트리 컨테이너를 띄워야 하기 때문에 master에 먼저 수동으로 설치합니다.

# containerd 바이너리 설치
tar -xzf /root/kubespray-offline-build/files/containerd/containerd/releases/download/v1.6.8/containerd-1.6.8-linux-amd64.tar.gz -C /usr/local/

# runc 설치
cp /root/kubespray-offline-build/files/opencontainers/runc/releases/download/v1.1.4/runc.amd64 /usr/local/bin/runc
chmod +x /usr/local/bin/runc

systemd 서비스 파일을 만들어서 containerd를 데몬으로 등록합니다.

cat <<EOF | sudo tee /etc/systemd/system/containerd.service
[Unit]
Description=containerd container runtime
After=network.target

[Service]
ExecStart=/usr/local/bin/containerd
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target
EOF

sudo mkdir -p /etc/containerd
containerd config default | sudo tee /etc/containerd/config.toml
systemctl daemon-reload
systemctl enable --now containerd
systemctl status containerd

디스크 용량이 부족한 경우 config.toml에서 root 경로와 state 경로를 넉넉한 마운트 지점으로 변경해줘야 합니다. df -h로 확인해보시면 됩니다.

6단계: 프라이빗 레지스트리 실행

nerdctl은 containerd를 위한 Docker 호환 CLI입니다. docker run, docker load 같은 명령을 containerd 환경에서 그대로 쓸 수 있게 해줍니다.

# nerdctl 설치
tar -xzf /root/kubespray-offline-build/files/containerd/nerdctl/releases/download/v0.22.2/nerdctl-0.22.2-linux-amd64.tar.gz -C /usr/local/bin/

# CNI 플러그인 설치 (컨테이너 네트워크 설정에 필요)
mkdir -p /opt/cni/bin/
tar -xzf /root/kubespray-offline-build/files/containernetworking/plugins/releases/download/v1.1.1/cni-plugins-*.tgz -C /opt/cni/bin/

registry:2.8.1 이미지를 로드하고 컨테이너로 실행합니다. kube-apiserver, coredns 같은 이미지를 인터넷 없이 pull 하려면 이 레지스트리에 미리 등록해두고 여기서 가져오게 해야 합니다.

# 레지스트리 데이터 디렉토리 (용량 넉넉한 곳으로)
mkdir -p /home/docker-registry

# 이미지 로드 및 실행
nerdctl load -i /root/kubespray-offline-build/images/docker.io_library_registry-2.8.1.tar
nerdctl run -d --name registry --network host --restart=always \
  -v /home/docker-registry:/var/lib/registry registry:2.8.1

# 확인
nerdctl ps

--network host로 실행하면 별도 포트 매핑 없이 호스트의 5000 포트에서 바로 접근할 수 있습니다

7단계: 이미지 등록 (load → tag → push)

이 단계가 제일 중요합니다. 오프라인으로 준비한 tar 파일들(kube-apiserver, kube-scheduler, kube-controller-manager, coredns, pause, calico/node, metrics-server 같은 것들)을 containerd에 로드하고, 프라이빗 레지스트리에 push 해야 합니다. 흐름은 이렇습니다.

load: tar → containerd에 이미지 등록 (master 로컬에만 존재)
tag: 레지스트리 주소로 이미지 이름 변경 (엔드포인트처럼 작동)
push: 레지스트리 서버에 업로드
이후 각 노드가 레지스트리에서 pull

insecure registry 설정

containerd는 기본적으로 레지스트리에 HTTPS로 통신합니다. 그런데 지금 올린 레지스트리는 HTTP로 돌아가고 있습니다. config.toml에 HTTP 접근을 허용하는 설정을 추가해야 합니다.

/etc/containerd/config.toml의 [plugins] 부분을 아래로 교체합니다.

[plugins]
  [plugins."io.containerd.grpc.v1.cri"]
    sandbox_image = "192.168.59.11:5000/pause:3.6"
    max_container_log_line_size = -1
    [plugins."io.containerd.grpc.v1.cri".containerd]
      default_runtime_name = "runc"
      snapshotter = "overlayfs"
      [plugins."io.containerd.grpc.v1.cri".containerd.runtimes]
        [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
          runtime_type = "io.containerd.runc.v2"
          runtime_engine = ""
          runtime_root = ""
          [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
            systemdCgroup = true
    [plugins."io.containerd.grpc.v1.cri".registry]
      [plugins."io.containerd.grpc.v1.cri".registry.mirrors]
        [plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"]
          endpoint = ["http://192.168.59.11:5000"]
        [plugins."io.containerd.grpc.v1.cri".registry.mirrors."quay.io"]
          endpoint = ["http://192.168.59.11:5000"]
        [plugins."io.containerd.grpc.v1.cri".registry.mirrors."registry.k8s.io"]
          endpoint = ["http://192.168.59.11:5000"]
        [plugins."io.containerd.grpc.v1.cri".registry.mirrors."gcr.io"]
          endpoint = ["http://192.168.59.11:5000"]
        [plugins."io.containerd.grpc.v1.cri".registry.mirrors."ghcr.io"]
          endpoint = ["http://192.168.59.11:5000"]
        [plugins."io.containerd.grpc.v1.cri".registry.mirrors."192.168.59.11:5000"]
          endpoint = ["http://192.168.59.11:5000"]
      [plugins."io.containerd.grpc.v1.cri".registry.configs]
        [plugins."io.containerd.grpc.v1.cri".registry.configs."192.168.59.11:5000".tls]
          insecure_skip_verify = true

mirror 설정의 핵심은 docker.io, quay.io, registry.k8s.io 등 공개 레지스트리로 향하는 pull 요청을 전부 로컬 레지스트리(192.168.59.11:5000)로 리다이렉트하는 것입니다.

certs.d 설정도 생성합니다. containerd 1.6 이하에서는 _default 디렉토리를 지원하지 않기 때문에 레지스트리 주소로 디렉토리를 만들어야 합니다.

mkdir -p "/etc/containerd/certs.d/192.168.59.11:5000"
cat > "/etc/containerd/certs.d/192.168.59.11:5000/hosts.toml" << 'EOF'
server = "http://192.168.59.11:5000"

[host."http://192.168.59.11:5000"]
  capabilities = ["pull", "resolve"]
  skip_verify = true
EOF

systemctl restart containerd

이 설정을 node1, node2에도 전파합니다.

for host in node1 node2; do
  ssh $host "mkdir -p /etc/containerd/"
  scp /etc/containerd/config.toml $host:/etc/containerd/
  ssh $host "mkdir -p '/etc/containerd/certs.d/192.168.59.11:5000'"
  scp "/etc/containerd/certs.d/192.168.59.11:5000/hosts.toml" \
    "$host:/etc/containerd/certs.d/192.168.59.11:5000/hosts.toml"
  ssh $host "systemctl restart containerd"
done

이미지 로드 및 push

# 모든 이미지를 containerd에 로드
for img in /root/kubespray-offline-build/images/*.tar; do
  nerdctl -n k8s.io load -i "$img"
done

# 로드 확인
nerdctl images

tag + push를 자동으로 처리하는 스크립트입니다. 이미지 이름에서 레지스트리 prefix를 떼고, 로컬 레지스트리 주소를 붙여서 push 합니다. (링크에 있는 폴더를 다운받으실 경우 images 아래에 install.sh가 준비되어 있습니다.)

#!/bin/bash
REGISTRY="192.168.59.11:5000"

nerdctl -n k8s.io images --format '{{.Repository}}:{{.Tag}}' \
  | grep -v none | grep -v "${REGISTRY}" | while read image; do
  name="$image"
  name=$(echo "$name" | sed 's@^registry\.k8s\.io/@@')
  name=$(echo "$name" | sed 's@^quay\.io/@@')
  name=$(echo "$name" | sed 's@^ghcr\.io/@@')
  name=$(echo "$name" | sed 's@^docker\.io/@@')

  if [[ "$name" != */* ]]; then
    name="library/${name}"
  fi

  new_name="${REGISTRY}/${name}"
  echo "push: ${image} → ${new_name}"
  nerdctl -n k8s.io tag "$image" "$new_name"
  nerdctl -n k8s.io push --insecure-registry "$new_name"
done
echo "완료!"

# 이미지 pulling 확인
nerdctl -n k8s.io pull 192.168.59.11:5000/calico/node:v3.23.3

8단계: inventory 설정

Kubespray의 inventory를 생성하고 노드 구성을 정의합니다.

cd /root/kubespray-offline-build/kubespray
cp -rfp inventory/offline-prep inventory/offline

/root/kubespray-offline-build/kubespray/`inventory/offline/inventory.ini를 수정합니다. (해당 링크에 있는 파일은 이미 수정되어 있습니다)

[all]
node1  ansible_host=node1  ip=192.168.59.21
node2  ansible_host=node2  ip=192.168.59.22
master ansible_host=master ip=192.168.59.11 etcd_member_name=etcd1

[kube_control_plane]
master

[etcd]
master

[kube_node]
node1
node2

[calico_rr]

[k8s_cluster:children]
kube_control_plane
kube_node
calico_rr

9단계: offline.yml 설정

Kubespray가 바이너리와 이미지를 로컬 파일 서버/레지스트리에서 가져오도록 offline.yml을 설정합니다. 이 설정이 에어갭 설치의 핵심입니다. (이 부분도 링크에 있는 폴더를 다운받으시면 준비되어 있습니다)

/root/kubespray-offline-build/kubespray/inventory/offline/group_vars/all/offline.yml

download_run_once: true        # 파일을 1번만 받아 다른 노드에 전파
download_delegate: master      # 다운로드 작업을 master에 위임

files_repo: "http://192.168.59.11:8080"

kubeadm_download_url: "{{ files_repo }}/kubernetes-release/release/{{ kubeadm_version }}/bin/linux/{{ image_arch }}/kubeadm"
kubectl_download_url: "{{ files_repo }}/kubernetes-release/release/{{ kube_version }}/bin/linux/{{ image_arch }}/kubectl"
kubelet_download_url: "{{ files_repo }}/kubernetes-release/release/{{ kube_version }}/bin/linux/{{ image_arch }}/kubelet"

cni_download_url: "{{ files_repo }}/containernetworking/plugins/releases/download/{{ cni_version }}/cni-plugins-linux-{{ image_arch }}-{{ cni_version }}.tgz"
etcd_download_url: "{{ files_repo }}/etcd-io/etcd/releases/download/{{ etcd_version }}/etcd-{{ etcd_version }}-linux-{{ image_arch }}.tar.gz"
crictl_download_url: "{{ files_repo }}/kubernetes-sigs/cri-tools/releases/download/{{ crictl_version }}/crictl-{{ crictl_version }}-{{ ansible_system | lower }}-{{ image_arch }}.tar.gz"
runc_download_url: "{{ files_repo }}/opencontainers/runc/releases/download/{{ runc_version }}/runc.{{ image_arch }}"
containerd_download_url: "{{ files_repo }}/containerd/containerd/releases/download/v{{ containerd_version }}/containerd-{{ containerd_version }}-linux-{{ image_arch }}.tar.gz"
nerdctl_download_url: "{{ files_repo }}/containerd/nerdctl/releases/download/v{{ nerdctl_version }}/nerdctl-{{ nerdctl_version }}-{{ ansible_system | lower }}-{{ image_arch }}.tar.gz"

calicoctl_download_url: "{{ files_repo }}/projectcalico/calico/releases/download/{{ calico_ctl_version }}/calicoctl-linux-{{ image_arch }}"
calico_crds_download_url: "{{ files_repo }}/projectcalico/calico/archive/{{ calico_version }}.tar.gz"

helm_download_url: "{{ files_repo }}/helm-{{ helm_version }}-linux-{{ image_arch }}.tar.gz"

registry_host: "192.168.59.11:5000"
kube_image_repo: "{{ registry_host }}"
gcr_image_repo: "{{ registry_host }}"
docker_image_repo: "{{ registry_host }}"
quay_image_repo: "{{ registry_host }}"
github_image_repo: "{{ registry_host }}"

files_repo는 4단계에서 올린 파일 서버를, registry_host는 6단계에서 올린 프라이빗 레지스트리를 가리킵니다.

Kubespray가 기본 지원하는 k8s 버전이 아닌 다른 버전을 설치하고 싶다면 group_vars/k8s_cluster/k8s_cluster.yml에서 kube_version을 수정하면 됩니다. (현재 1.23.7로 설정되어 있습니다

10단계: 설치 실행

ping 체크부터 합니다.

ansible -i /root/kubespray-offline-build/kubespray/inventory/offline/inventory.ini all -m ping

전부 SUCCESS가 뜨면 플레이북을 실행합니다.

ansible-playbook \
  -i /root/kubespray-offline-build/kubespray/inventory/offline/inventory.ini \
  --become --become-user=root \
  /root/kubespray-offline-build/kubespray/cluster.yml \
  --skip-tags=packages

--skip-tags=packages는 온라인 패키지 설치 태스크를 건너뛰는 옵션입니다. 에어갭 환경에서는 필수입니다.

11단계: 설치 후 정리

CoreDNS / nodelocaldns forward 수정

에어갭 환경에서는 외부 DNS 포워딩이 의미가 없습니다. CoreDNS와 nodelocaldns configmap에서 forward 부분과 loop 플러그인을 삭제합니다. 그대로 두면 외부 도메인 resolve 시도 → 타임아웃 → DNS 전반 불안정으로 이어질 수 있습니다.

kubectl edit configmap coredns -n kube-system

# Before
.:53 {
    errors
    health
    ready
    kubernetes cluster.local in-addr.arpa ip6.arpa {
      pods insecure
      fallthrough in-addr.arpa ip6.arpa
    }
    forward . /etc/resolv.conf {    # ← 삭제
      prefer_udp                    # ← 삭제
    }                               # ← 삭제
    loop                            # ← 삭제
    cache 30
    reload
    loadbalance
}

# After
.:53 {
    errors
    health
    ready
    kubernetes cluster.local in-addr.arpa ip6.arpa {
      pods insecure
      fallthrough in-addr.arpa ip6.arpa
    }
    cache 30
    reload
    loadbalance
}

nodelocaldns는 블록이 여러 개 있는데, .:53 블록의 forward와 loop을 삭제합니다 . cluster.local:53 블록의 forward는 CoreDNS(10.233.0.3)를 가리키는 거라 그대로 둡니다.

kubectl edit configmap nodelocaldns -n kube-system

# Before
.:53 {
    errors
    cache 30
    reload
    loop                              # ← 삭제
    bind 169.254.25.10
    forward . /etc/resolv.conf        # ← 삭제
}

# After
.:53 {
    errors
    cache 30
    reload
    bind 169.254.25.10
}

containerd config.toml 재설정

Ansible이 플레이북 실행 중에 config.toml을 자기 기본값으로 덮어씁니다. 설치가 끝난 후 7단계에서 설정했던 insecure registry 설정을 다시 적용해야 합니다.

# master에서 config.toml 재설정 후
systemctl restart containerd

# node1, node2에도 전파
for host in node1 node2; do
  scp /etc/containerd/config.toml $host:/etc/containerd/
  ssh $host "mkdir -p '/etc/containerd/certs.d/192.168.59.11:5000'"
  scp "/etc/containerd/certs.d/192.168.59.11:5000/hosts.toml" \
    "$host:/etc/containerd/certs.d/192.168.59.11:5000/hosts.toml"
  ssh $host "systemctl restart containerd && systemctl status containerd"
done

이미지를 못 당겨서 문제가 생긴 pod가 있으면 delete 하면 재생성되면서 정상적으로 뜹니다.

12단계: 설치 확인

kubectl get po -A
kubectl get nodes

모든 노드가 Ready 상태이고, kube-system 네임스페이스의 pod들이 전부 Running이면 설치 완료입니다.

정리

에어갭 환경에서 쿠버네티스를 설치하려면 바이너리를 파일 서버로 서빙하고, 컨테이너 이미지를 프라이빗 레지스트리에 올려두고, Kubespray 설정에서 이쪽을 바라보게 바꿔주면 됩니다.

실수할 수 있는 부분은 아래와 같습니다.

containerd config.toml: Ansible이 설치 중에 덮어쓰기 때문에 설치 후 반드시 다시 설정해야 합니다.
insecure registry: HTTP 레지스트리를 쓰려면 config.toml의 mirror 설정 + certs.d 설정 둘 다 해줘야 합니다.
이미지 tag 규칙: push 할 때 원본 이미지에서 레지스트리 prefix를 떼고 로컬 주소를 붙여야 합니다. 안 그러면 pull 시 이미지를 못 찾습니다.
CoreDNS forward: 에어갭이면 외부 DNS forward를 꺼야 합니다. 안 그러면 DNS 루프로 장애가 전파될 수 있습니다.