LLM 추론을 움직이는 가중치 스트리밍 구조

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

LLM 서버의 추론 비용은 빠른 연산 코어보다 HBM에서 8.6 GB 가중치를 반복해서 옮기는 데 크게 좌우된다. Prefill은 전체 프롬프트 토큰을 한 번에 처리하지만 Decode는 이전 출력에 의존해 토큰 하나마다 forward pass와 가중치 스트리밍을 반복한다. KV cache는 과거 토큰의 K와 V를 저장해 최신 토큰만 입력하게 하며, Batch는 여러 요청이 한 번의 가중치 스트림을 공유하게 만든다. 시리즈의 핵심 변수인 max_num_seqs, chunked prefill, quantization은 각각 배치 규모와 Prefill 배치 방식, 가중치 이동량을 바꾸며 이 구조의 한계를 압박한다.

섹션별 상세

01

Qwen3.5-4B는 학습 과정에서 고정된 값으로 배운 대규모 weight matrix의 집합이며, 이 글에서 사용하는 모델의 가중치 크기는 8.6 GB이다. 서버를 시작하면 가중치가 GPU의 HBM에 한 번 적재되고 서버가 실행되는 동안 바뀌지 않는다. 연산 코어는 행렬 곱셈을 빠르게 수행하지만 가중치를 저장할 공간이 거의 없으므로, 토큰 하나를 처리할 때마다 HBM의 8.6 GB를 코어로 스트리밍하는 메모리 이동이 산술 연산보다 큰 비용이 된다.

서가에 쌓인 책과 컨베이어벨트가 GPU 메모리와 연산 코어 사이의 가중치 이동을 비유하는 그림이다. — Diagram이미지는 많은 책이 저장된 공간에서 일부 책이 컨베이어벨트를 타고 연산 작업 공간으로 이동하는 장면을 그린다. 이는 8.6 GB 가중치가 HBM에 머물고 각 추론 단계마다 빠른 연산 코어로 스트리밍되는 구조를 시각화한다. 저장 공간은 크지만 느리고 연산 공간은 빠르지만 작다는 글의 핵심 대비와 연결된다.

02

모델 추론은 입력 프롬프트를 읽는 Prefill과 답변을 생성하는 Decode로 나뉘며 두 단계의 처리 방식이 다르다. Prefill에서는 이미 존재하는 여러 프롬프트 토큰을 한 번의 forward pass에 함께 넣지만, Decode에서는 앞서 생성한 토큰이 다음 입력이 되므로 토큰을 동시에 만들 수 없다. 따라서 100개 토큰의 답변은 대략 100번의 단계와 100회의 가중치 스트리밍을 요구하며, 이 비대칭성 때문에 시리즈는 Decode를 주요 병목으로 다룬다.

여러 문서를 한꺼번에 처리하는 Prefill과 한 토큰씩 이어 쓰는 Decode를 대비한 그림이다. — Diagram이미지는 왼쪽에서 긴 문서 묶음을 한 번에 읽는 장면과 오른쪽에서 한 글자씩 이어 쓰는 장면을 나란히 배치한다. 이는 Prefill이 이미 존재하는 전체 프롬프트 토큰을 함께 처리하는 반면 Decode는 앞선 출력에 의존해 토큰을 순차 생성한다는 차이를 나타낸다. 두 단계의 처리 단위가 다르기 때문에 Decode에서 가중치 스트리밍이 토큰마다 반복된다는 설명을 보완한다.

03

KV cache는 Decode가 대화 전체를 매번 다시 계산하지 않도록 이미 처리한 토큰의 key와 value 벡터를 저장한다. 다음 토큰을 생성할 때 모델은 각 요청의 최신 토큰만 새로 입력하고, 과거 토큰에 해당하는 K와 V는 GPU 메모리에 있는 캐시에서 조회한다. 이 모델에서는 캐시된 토큰 하나가 약 130 KB이므로 100개 토큰은 10 MB에 조금 못 미치지만, 활성 요청과 토큰이 늘어날수록 캐시도 커져 부하 상황에서 메모리를 소진시키는 요인이 된다.

04

실제 서버는 요청 하나씩 처리하지 않고 현재 실행 중인 요청을 running batch로 묶어 하나의 가중치 스트림을 공유한다. 각 요청의 최신 토큰 벡터를 세로로 쌓은 뒤 가중치 행렬을 HBM에서 한 번 읽어 전체 묶음에 곱하면, 열 개 요청도 가중치 이동 비용은 한 요청과 같고 산술량만 늘어난다. 이 방식으로 열 개 요청이 한 번의 가중치 스트리밍 비용으로 다음 토큰을 얻으며, 100토큰 답변은 약 100개의 배치 단계로 진행된다.

하나의 컨베이어벨트에서 나온 책이 여러 사람에게 동시에 전달되는 Batch 추론 구조를 나타낸 그림이다. — Diagram이미지는 하나의 가중치 흐름으로부터 여러 사용자가 동시에 책을 받으며 각자 읽고 있는 모습을 보여준다. 이는 각 요청의 최신 토큰을 하나의 행렬로 쌓고 가중치 행렬을 한 번만 읽어 running batch 전체를 전진시키는 과정을 시각화한다. 산술량은 요청 수와 함께 늘지만 가장 큰 비용인 가중치 스트리밍을 공유할 수 있다는 Batch의 의미가 드러난다.

05

시리즈가 조절하는 핵심 변수는 batch 상한, 긴 프롬프트 처리 방식, 가중치 표현 방식이다. max_num_seqs는 동시에 실행할 수 있는 요청 수의 상한이고, chunked prefill은 긴 프롬프트를 조각내 Decode 작업과 같은 단계에 섞으며, quantization은 가중치를 16비트에서 4비트처럼 더 적은 비트로 저장해 단계당 이동 바이트를 줄인다. 이 세 조절점은 HBM에서 가중치를 옮기고 KV cache로 최신 토큰만 공급하며 batch 전체를 한 단계씩 전진시키는 서버 구조의 서로 다른 부분을 압박한다.

용어 해설

KV 캐시(KV cache): — KV cache는 모델이 이미 처리한 각 토큰의 key와 value 벡터를 저장하는 메모리 영역이다. Decode 단계에서 과거 토큰을 다시 계산하지 않고 캐시를 조회하게 해 최신 토큰만 입력하도록 만든다. 요청과 토큰이 늘어날수록 크기도 함께 증가한다.
Prefill: — Prefill은 사용자가 입력한 전체 프롬프트를 모델에 한꺼번에 통과시키는 초기 처리 단계다. 여러 토큰을 함께 계산하므로 하나의 가중치 스트림을 여러 입력 토큰에 나눠 부담시킬 수 있다. 프롬프트 길이에 따라 연산량이 커진다.
Decode: — Decode는 모델이 이전에 생성한 토큰을 바탕으로 답변을 한 토큰씩 이어 붙이는 단계다. 새 토큰마다 별도의 forward pass가 필요하고 가중치 전체를 다시 읽어야 하므로 토큰당 메모리 이동 비용이 핵심 병목이 된다.
HBM: — HBM은 GPU 안에서 모델 가중치와 KV cache를 보관하는 크고 상대적으로 느린 메모리다. Qwen3.5-4B의 8.6 GB 가중치가 이곳에 상주하며, 매 forward pass마다 가중치가 빠른 연산 코어로 이동한다.
Quantization: — Quantization은 모델 가중치를 더 적은 비트로 저장하는 최적화 기법이다. 글에서는 16비트 대신 4비트를 사용하면 매 단계에서 HBM에서 연산 코어로 이동해야 하는 바이트 수가 줄어든다고 설명한다.

기술

Qwen3.5-4B
HBM
KV cache
Prefill
Decode
max_num_seqs
chunked prefill
quantization

활용 사례

다중 사용자 LLM 서버
동시 요청 처리를 위한 Batch 추론
긴 대화의 KV cache 관리
GPU 메모리 제약을 고려한 모델 서빙

LLM 추론을 움직이는 가중치 스트리밍 구조

TL;DR

섹션별 상세

용어 해설

기술

활용 사례

관련 토론

댓글

관련 기사

원리 기반 LLM 추론 성능 모델링

LLM 추론 벤치마킹에서 중요한 성능 기준

LLM 추론을 나누면 GPU 효율이 달라진다

LLM 추론 엔지니어링과 AI 반도체 최적화 기법 심화 강의