본문으로 건너뛰기

© 2026 Molayo

Zenn헤드라인2026. 06. 23. 21:23

LLM이 1토큰을 생성할 때, GPU와 CPU에서는 어떤 일이 일어나는가

요약

LLM이 1토큰을 생성하는 디코딩 과정에서 GPU와 CPU의 역할 및 하드웨어적 병목 지점을 분석합니다. 디코딩 단계에서는 연산 성능보다 VRAM의 메모리 대역폭이 성능을 결정짓는 핵심 요소임을 설명합니다.

핵심 포인트

  • 디코딩 단계는 연산 제한(Compute-bound)이 아닌 메모리 대역폭 제한(Memory-bound) 상태임
  • 1토큰 생성 시 매 스텝마다 모든 가중치를 VRAM에서 다시 읽어오는 비용이 지배적임
  • GPU는 행렬 연산을 담당하고, CPU는 커널 기동, 토큰화, 샘플링 등 제어 역할을 수행함
  • 프리필(Prefill) 단계는 병렬 처리가 가능하여 연산 성능(Tensor 코어)이 중요함

1. 서론

이 기사에서는 LLM이 1토큰을 생성할 때, 하드웨어 측면(GPU나 CPU)에서 어떤 처리가 이루어지는지 정리합니다. 최종적으로 어떤 하드웨어가 관여하며, 각각이 어떤 흐름으로 1토큰 생성에 기여하는지 이해하는 것을 목표로 합니다.

구성으로는 먼저 결론(무엇이 효과적인가)을 제시하고, 다음으로 관여하는 하드웨어 요소를 개념 $\rightarrow$ 상세 순으로 분해하며, 1토큰이 나오기까지의 처리 흐름을 추적한 뒤, 마지막으로 실례로 마무리합니다.

2. 결론 요약

먼저 결론을 정리합니다. 1토큰 생성(디코딩, Decoding)에서 중요한 것은 GPU의 연산 성능이 아니라 메모리 대역폭 (Memory Bandwidth) 입니다.

이유는 디코딩의 계산 패턴에 있습니다. 프롬프트 전체를 일괄 처리하는 프리필(Prefill)과 달리, 디코딩은 1토큰씩 생성하기 때문에 각 층의 행렬 곱은 「행렬 $\times$ 벡터」로 축소됩니다. 1연산당 읽어들이는 데이터 양(계산 밀도, ops/byte)이 작기 때문에, 매 스텝마다 모든 가중치(Weights)를 VRAM에서 한 번씩 다시 읽어오는 비용이 처리 시간을 지배합니다.

참고로, 프롬프트 처리(프리필)는 반대로 「연산 제한 (Compute-bound)」 상태입니다. 다수의 토큰을 병렬로 처리하기 때문에 계산 밀도가 높으며, Tensor 코어가 병목(Bottleneck)이 됩니다. 본 기사는 디코딩(1토큰 생성)에 집중하므로, 이후에는 별도의 언급이 없는 한 디코딩을 지칭합니다.

3. 하드웨어 요소: 개념 편

1토큰 생성에 관여하는 하드웨어를 먼저 역할 기반으로 파악합니다.

  • GPU (연산의 본체): Transformer의 처리는 대부분 행렬 곱(QKV 투영, Attention, FFN, 출력 투영)입니다. 이러한 곱셈-덧셈 연산을 GPU가 담당합니다. 디코딩에서는 앞서 언급한 대로 행렬 $\times$ 벡터가 중심이 됩니다.
  • GPU 메모리 (VRAM) 및 메모리 대역폭: 가중치(Weights), KV 캐시(KV Cache), 중간 활성화 값(Activations)을 두는 장소입니다. 용량은 「무엇을 올릴 수 있는가」를 결정하고, 대역폭은 「1토큰당 얼마나 빠르게 읽을 수 있는가」를 결정합니다. 디코딩에서는 이 대역폭이 최대의 병목이 됩니다.
  • CPU: 연산 그 자체가 아니라 제어를 담당합니다. 구체적으로는 GPU로 보낼 처리(커널, Kernel)의 기동, 토큰화(Tokenize), 샘플링(Sampling, 다음 토큰의 확률 분포에서 1개를 선택하는 처리), 생성 루프의 관리 등입니다. GPU가 계산하는 동안 CPU는 거의 대기하거나 다음 지시를 준비합니다.
  • 시스템 RAM · PCIe: 모델 로드 시나 VRAM에 다 담기지 않는 부분을 CPU 측으로 넘길(오프로드, Offload) 때 사용합니다. 모델이 GPU 상에 모두 올라가 있는 일반적인 생성 루프 중에는 거의 관여하지 않습니다.
  • GPU 간 인터커넥트 (NVLink 등): 모델을 여러 GPU에 분할할 때의 통신 경로입니다. 단일 GPU에 올라가는 모델(본 기사의 실례에서 다루는 Llama 3 8B 등)에서는 쓰임새가 없습니다.

요점은 일반적인 디코딩에서는 「GPU의 연산」과 「VRAM의 대역폭」이 거의 주역이며, CPU나 다른 메모리는 조연이라는 것입니다. 다음 장에서는 GPU 내부를 한 단계 더 분해합니다.

4. 하드웨어 요소: 상세 편

개념 편의 GPU를 내부 구조까지 분해합니다.

연산 유닛: SM과 Tensor 코어

GPU는 다수의 **SM (Streaming Multiprocessor)**으로 구성되며, 각 SM 내부에는 연산기가 나열되어 있습니다. 연산기는 크게 두 종류가 있습니다.

  • CUDA 코어: 범용 부동 소수점 및 정수 연산을 담당합니다.
  • Tensor 코어: 행렬 곱셈-덧셈(MMA)에 특화된 전용 유닛입니다. Transformer의 거대한 행렬 곱은 여기서 실행되며, CUDA 코어보다 훨씬 높은 처리량(Throughput)을 냅니다. V100 이후의 NVIDIA GPU에 탑재되어 있으며, FP16/BF16이나 INT8과 같은 저정밀도 곱셈-덧셈을 지원합니다.

메모리 계층

GPU의 메모리는 용량과 속도가 트레이드오프(Trade-off) 관계인 계층 구조로 되어 있습니다. 위로 갈수록 크기가 작고 속도가 빠릅니다.

  • 레지스터 (Register): 스레드 고유. 가장 빠름.
  • L1 캐시 / 공유 메모리 (SRAM): SM마다 가지는 온칩(On-chip) 고속 메모리.
  • L2 캐시: 모든 SM이 공유.
  • 글로벌 메모리 (HBM / VRAM): 용량은 가장 크지만, 속도는 가장 느림. 가중치나 KV 캐시의 본체는 여기에 놓입니다.

속도 차이는 매우 크며, 예를 들어 A100의 경우 HBM 대역폭이 약 1.5~2.0TB/s인 것에 반해, 온칩 (on-chip) SRAM은 약 19TB/s에 달합니다 (FlashAttention-2 논문). 즉, **HBM으로부터의 읽기 속도가 느리며, 이 부분이 디코딩 (decoding)의 속도 제한 요소 (bottleneck)**가 됩니다. FlashAttention과 같은 기법이 빠른 이유는 계산을 가능한 한 SRAM 상에서 완결시켜, 느린 HBM으로의 액세스를 줄이고 있기 때문입니다.

여기까지를 통해, "왜 1토큰 생성에서 대역폭이 중요한가"를 하드웨어 구조 측면에서 뒷받침했습니다. 다음 장에서는 1토큰 생성의 각 처리가 이러한 하드웨어의 어디에서 움직이고 어디에 놓이는지 대응시켜 보겠습니다.

5. 처리는 하드웨어의 어디에서 움직이는가

1토큰 생성의 각 처리가 하드웨어의 어떤 구성 요소에서 움직이고 어디에 놓여 있는지 대응시켜 보겠습니다. 4장의 상세 편에서 언급한 연산기 (Tensor 코어 · CUDA 코어)와 메모리 계층 (레지스터 · L1/SRAM · L2 · HBM)을 포함하여, 아래 그림에 배치를 나타냅니다 (처리 순서는 아닙니다). 빨간색 화살표가 후술할 "메모리 제한 (memory-bound)" 경로입니다.

빨간색 화살표는 가장 느린 HBM에서 L2 · SRAM을 거쳐 연산기로, 매 토큰마다 가중치와 KV 캐시를 읽어들이는 경로입니다. 이것이 메모리 제한의 정체입니다. 메모리 계층은 위로 갈수록 빠르고 용량이 작으며, 아래(HBM)로 갈수록 느리고 용량이 큽니다.

대응 관계는 다음과 같습니다.

  • HBM (VRAM) → 가중치 (전체 파라미터) + KV 캐시: 용량은 최대이지만, 가장 느린 계층입니다. 1토큰 생성 시마다 여기서 읽어옵니다.
  • L2 캐시 / L1 · SRAM (공유 메모리) / 레지스터 → 계산 중인 임시 데이터: HBM에서 읽은 데이터는 이 고속 · 소용량 계층을 거쳐 연산기로 전달됩니다.
  • Tensor 코어 → 행렬 곱 (QKV 투영 · Attention · FFN · 출력 투영 · LM head). 정규화(normalization)나 활성화(activation) 등의 범용 연산은 CUDA 코어가 담당합니다. 둘 다 SM 내에 있습니다.
  • CPU → 토큰화 (tokenization) · 샘플링 (sampling) · 생성 루프의 제어. 시스템 RAM · PCIe는 모델 로드 시나 오프로드 (offload) 시에만 사용되며, 일반적인 디코딩 중에는 거의 움직이지 않습니다.

참고로 처리 순서 자체는 "임베딩 (embedding) → 각 층 (Self-Attention → FFN) × 32 → 최종 RMSNorm → LM head → 샘플링"이며, 이를 반복하여 1토큰씩 생성합니다.

메모리 제한은 어디인가

그림의 빨간색 화살표—가장 느린 HBM에서 L2 · SRAM을 거쳐 연산기로, 매 토큰마다 가중치와 KV 캐시를 읽어들이는 경로—가 메모리 제한의 정체입니다.

디코딩에서는 입력이 1토큰 분량밖에 없기 때문에, Tensor 코어에서의 행렬 곱은 "행렬 × 벡터"가 되어 계산 자체는 순식간에 끝납니다. 하지만 계산에 사용하는 가중치는 HBM에 놓여 있으며, 매 스텝마다 다시 읽어야 합니다. 이 읽기 시간이 처리 시간의 대부분을 차지합니다.

게다가 Self-Attention과 FFN의 가중치 읽기는 32개 층만큼 매 토큰마다 반복됩니다. 결국 1토큰을 생성할 때마다 "HBM에 있는 거의 모든 파라미터를 1회 읽는" 셈이 됩니다.

다음 장에서는 이를 Llama 3 8B의 구체적인 수치에 대입해 보겠습니다.

6. 실례: Llama 3 8B의 생성 속도 개산하기

대역폭 1TB/s의 GPU (RTX 4090 상당)에서 FP16의 Llama 3 8B를 구동한다는 전제로 개산합니다. 식의 분모인 "1토큰당 읽는 바이트 수"는 VRAM 상의 가중치 (고정) + KV 캐시 (문맥 길이에 따라 증가) 입니다.

토대: 모델 가중치 (고정)

FP16 (파라미터당 2바이트)으로 약 16GB입니다. 문맥 길이에 관계없이 일정하며, 매 토큰마다 거의 전량을 읽어옵니다.

추가분: KV 캐시 (문맥 길이에 비례)

Llama 3 8B의 KV 캐시는 문맥 길이에 정비례합니다.

KV 캐시 = 2(K,V) × 층 수 32 × KV 헤드 8 × 헤드 차원 128 × 문맥 길이 × 2byte(FP16)
= 문맥 길이 × 131,072 byte ≒ 문맥 1토큰당 128 KiB

문맥 길이별 개산 (FP16 · 대역폭 1TB/s)

문맥 길이KV 캐시KV 비율1토큰당 읽는 양tok/s (이론적 상한)
1K약 0.13GB약 1%약 16.1GB약 62
...
※ tok/s는 이론적 상한입니다. 실측치는 대체로 이의 5~7할 정도가 됩니다.

여기서 두 가지 점을 읽어낼 수 있습니다.

  • 일반적인 문맥 길이(~8K)에서는 가중치(Weights)가 지배적이며, KV는 몇 %에 불과합니다. tok/s ≈ 대역폭 ÷ 가중치가 좋은 근사치가 됩니다.
  • 긴 문맥(128K)에서는 KV가 가중치에 필적하며(약 절반), 생성 속도는 약 절반까지 떨어집니다. 대화가 길어질수록 느려지는 이유가 바로 이것입니다.

GQA의 효과: 만약 MHA(KV 헤드 32)라면, KV 캐시(KV Cache)는 4배(문맥 1토큰당 512 KiB)가 됩니다. Llama 3는 GQA(KV 헤드 8)를 통해 이를 1/4로 억제하여, 긴 문맥에서의 KV 비대화를 완화하고 있습니다.

양자화(Quantization)의 효과: 가중치를 Q4(4bit 상당)로 양자화하면 약 4.5GB가 되며, 짧은 문맥에서는 1TB/s ÷ 4.5GB ≒ 약 220 tok/s가 되어 FP16보다 약 3.5배 빨라집니다. 디코딩(Decoding)이 대역폭 제한(Memory Bandwidth Bound)이기 때문에, 읽어야 할 바이트 수를 줄이는 양자화가 직접적인 효과를 발휘합니다.

7. 요약

본 기사의 핵심 포인트를 정리합니다.

  • **1토큰 생성(디코딩)은 메모리 대역폭 제한(Memory Bandwidth Bound)**입니다. Tensor 코어의 계산은 순식간에 끝나며, VRAM(HBM)으로부터의 읽기 작업이 처리 시간을 지배합니다.
  • 읽어 들여야 하는 본체는 **VRAM상의 "가중치(고정) + KV 캐시(문맥 길이에 따라 증가)"**이며, 생성 속도는 대략 대역폭 ÷ (가중치 + KV)로 결정됩니다.
  • 어떤 하드웨어가 무엇을 담당하는지 살펴보면, 가중치와 KV 캐시는 HBM, 행렬 곱셈은 SM 내의 Tensor 코어, 샘플링(Sampling) 및 제어는 CPU가 담당합니다.
  • 속도를 좌우하는 레버는 **파라미터 수 · 양자화(가중치의 바이트 수) · GQA(KV 감소) · 문맥 길이(KV 증가)**의 4가지입니다.

"LLM이 빠르다/느리다"를 파고들면 결국 VRAM의 내용을 얼마나 빠르고 적게 읽을 수 있는가로 귀결됩니다. 사용 중인 모델이나 GPU에 위의 식을 적용하면 대략적인 생성 속도를 예측할 수 있습니다.

참고 문헌

Llama 3 모델 사양 (GQA · 어휘 · 계층 구성)

  • Introducing Meta Llama 3 — 공식 문서. GQA 채택 및 어휘 확장 관련 1차 정보.
  • Llama 3 Model Card (GitHub) — 공식 문서. 아키텍처의 요점.

GQA / Attention 방식 (KV 캐시와 대역폭)

  • GQA: Training Generalized Multi-Query Transformer Models from Multi-Head Checkpoints (Ainslie et al., 2023) — GQA 원 논문.
  • LLM 테크닉 습득: 추론 최적화 (NVIDIA 기술 블로그) — MHA / MQA / GQA와 대역폭의 관계를 평이하게 해설.

디코딩이 메모리 대역폭 제한인 이유

  • LLM 추론 퍼포먼스 엔지니어링 (Databricks) — 메모리 제한 및 최적화의 실무적 관점.
  • SARATHI (arXiv:2308.16369) — 프리필(Prefill)과 디코딩의 계산 밀도 차이를 실측으로 보여준 논문.

KV 캐시의 메커니즘

  • KV 캐시의 메커니즘 — LLM 추론을 가속화하는 기본 기술 — 수식으로부터 단계별 해설.
  • LLM Serving을 뒷받침하는 기술 (Zenn) — KV 캐시의 메모리 소비와 배치(Batch) 처리.

GPU 메모리 계층 / Tensor 코어

  • FlashAttention (arXiv:2205.14135) — HBM ↔ SRAM 계층과 IO 제한(IO Bound)에 대한 개념.
  • FlashAttention-2 (arXiv:2307.08691) — A100의 HBM / SRAM 대역폭 구체적 수치 포함.

보충: 다중 GPU · 오프로드(Offload)

  • LLM 분산 추론 서비스 입문 가이드 (NTTPC) — PagedAttention, KV 캐시 오프로드, 노드 간 전송.

Discussion

AI 자동 생성 콘텐츠

본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0