LLM 공부 05. Batch와 Sequence Length가 속도와 비용을 정한다

이 글의 핵심은 batch와 sequence length가 LLM의 처리량, 지연 시간, token 비용을 함께 결정한다는 점입니다.

4편에서는 LLM 추론을 prefill과 decode로 나눴습니다.

이번 글에서는 두 단어를 붙여서 봅니다.

batch
sequence length

이 둘은 LLM을 쓸 때 자주 들리지만, 가장 쉽게 섞이는 말이기도 합니다. 특히 batch는 추론과 학습에서 같은 단어를 쓰지만 목적이 다릅니다.

추론 batch = 여러 요청을 묶어 GPU를 바쁘게 쓰는 serving 단위
학습 batch = loss와 gradient를 계산해 parameter를 업데이트하는 학습 단위

sequence length는 token 줄의 길입니다. 추론에서는 입력 prompt와 지금까지 생성된 output을 합친 현재 context 길이에 가깝습니다. 학습에서는 한 sample 또는 block을 몇 token 길이로 잘라 학습할지와 연결됩니다.

이 둘을 같이 봐야 LLM 비용이 보입니다.

Batch는 GPU를 놀리지 않기 위한 묶음입니다

GPU는 큰 matrix multiplication을 잘합니다. 한 요청만 처리하면 GPU가 충분히 바쁘지 않을 수 있습니다.

그래서 여러 요청을 묶습니다.

요청 A
요청 B
요청 C
-> 한 batch로 묶어 처리

이것이 추론 batch입니다.

목표는 throughput입니다. 일정 시간 동안 더 많은 token을 처리하고, GPU utilization을 높이는 것입니다.

하지만 batch를 키우면 항상 좋은 것은 아닙니다.

batch가 커지면 GPU 효율은 좋아질 수 있지만, 개별 사용자는 기다릴 수 있습니다. 특히 요청마다 prompt 길이와 output 길이가 다르면 문제가 생깁니다.

짧은 질문: 200 input tokens, 50 output tokens
긴 코드 리뷰: 30,000 input tokens, 2,000 output tokens

이 둘을 같은 방식으로 묶으면 누군가는 불필요하게 기다립니다.

그래서 LLM serving에서 batch는 단순한 "N개 묶음"이 아니라 scheduler 문제입니다.

Continuous batching은 실행 중인 batch를 계속 바꿉니다

전통적인 batch 처리에서는 요청을 모아서 한 번에 실행하고 끝냅니다.

LLM serving은 다릅니다. decode는 token을 하나씩 만듭니다. 어떤 요청은 빨리 끝나고, 어떤 요청은 오래 이어집니다.

그래서 continuous batching이 중요해집니다.

실행 중인 batch:
A, B, C

B가 끝남
-> B를 빼고 D를 넣음

A가 긴 답변을 계속 생성
-> A는 남겨두고 다른 요청을 계속 교체

이 방식은 GPU를 쉬지 않게 만듭니다. 하지만 scheduler는 더 어려워집니다. 각 요청의 KV cache 위치, 남은 output 길이, priority, latency 목표를 같이 봐야 합니다.

특히 decode 단계에서는 각 sequence가 한 token씩 앞으로 나아갑니다. 이때 batch 안의 sequence들이 서로 다른 길이를 가지면 memory access와 scheduling이 복잡해집니다.

그래서 현대 LLM serving engine의 성능은 model 자체만이 아니라 scheduler와 memory manager에 크게 좌우됩니다.

Sequence length는 token 줄의 길입니다

sequence length는 모델이 처리하는 token sequence의 길입니다.

추론에서는 이렇게 볼 수 있습니다.

입력 prompt: 4,000 tokens
지금까지 생성한 답변: 1,000 tokens
현재 sequence length: 5,000 tokens

학습에서는 한 sample을 몇 token 길이로 잘라 넣을지와 관련됩니다.

sequence length 2,048
sequence length 8,192
sequence length 32,768

길수록 더 긴 문맥을 다룰 수 있습니다. 하지만 비용이 늘어납니다.

attention은 token들이 서로를 참고하는 구조입니다. causal attention에서는 미래 token을 보지 않지만, 현재 token은 과거 token들을 참고합니다. sequence가 길수록 참고 가능한 과거가 많아집니다.

입문 단계에서는 이렇게 기억하면 됩니다.

sequence length 증가
-> prefill token 증가
-> KV cache 증가
-> decode에서 읽어야 할 과거 K/V 증가
-> memory와 latency 부담 증가

긴 context는 편하지만 공짜가 아닙니다.

Context length와 sequence length는 비슷하지만 같은 말은 아닙니다

context length는 모델이나 제품이 허용하는 최대 문맥 길이를 가리킬 때 자주 씁니다.

sequence length는 실제로 지금 처리 중인 token 줄의 길이를 말할 때 더 자주 씁니다.

context length limit = 최대 128k tokens까지 가능
current sequence length = 지금 요청은 23k tokens 사용 중

둘을 구분하면 가격표와 모델 스펙을 더 잘 읽을 수 있습니다.

128k context를 지원한다고 해서 모든 요청이 128k 비용을 내는 것은 아닙니다. 하지만 128k에 가까운 요청을 자주 넣으면 prefill, KV cache, decode 비용이 커집니다.

반대로 짧은 요청이 많으면 context limit은 넉넉해도 실제 sequence length는 작습니다.

그래서 LLM을 운영하거나 API 비용을 예측할 때는 "최대 context"보다 "현재 workload의 실제 sequence length 분포"가 더 중요합니다.

P50 prompt length
P95 prompt length
평균 output length
긴 agent run의 최대 context
cache hit 가능성

이 값들이 실제 비용을 만듭니다.

Batch와 sequence length를 곱하면 총 token 규모가 보입니다

학습에서는 batch size와 sequence length를 같이 봅니다.

예를 들어 batch size가 8이고 sequence length가 4,096이면 한 step에서 처리하는 token 수는 대략 이렇게 볼 수 있습니다.

8 sequences x 4,096 tokens
= 32,768 tokens

LLM 학습에서는 sample 수보다 token 수가 더 중요한 경우가 많습니다.

global batch tokens
= global batch size x sequence length

물론 실제 학습에서는 data parallelism, micro-batch, gradient accumulation, padding, packed sequence 같은 요소가 들어갑니다. 하지만 기본 감각은 이렇습니다.

한 step에서 몇 token을 보고 gradient를 계산하는가

추론에서도 비슷한 감각이 필요합니다.

batch 안에 sequence가 많고 각 sequence가 길면 GPU가 처리해야 할 token과 cache가 커집니다.

batch size 증가
+ sequence length 증가
-> 총 token/activation/cache 규모 증가

그래서 "batch size를 키우면 throughput이 좋아진다"는 말은 조건부입니다. GPU memory, KV cache, latency 목표, request length distribution을 같이 봐야 합니다.

추론 batch와 학습 batch는 목적이 다릅니다

같은 batch라는 단어 때문에 혼동이 생깁니다.

추론 batch는 parameter를 바꾸지 않습니다. 이미 학습된 모델 weight를 사용해 여러 요청의 token을 생성합니다.

추론 batch:
여러 요청을 묶어 output token을 생성
목표 = throughput, latency 균형
parameter update 없음

학습 batch는 parameter를 바꿉니다.

학습 batch:
여러 sample/token으로 loss 계산
gradient 계산
optimizer step으로 parameter update
목표 = 안정적인 학습과 효율적인 GPU 사용

그래서 같은 "batch size"라도 질문이 달라집니다.

추론에서 batch size를 키우면?
-> GPU utilization은 오를 수 있지만 latency가 늘 수 있다

학습에서 batch size를 키우면?
-> gradient가 안정될 수 있지만 memory와 generalization 문제가 생길 수 있다

학습에서는 memory 한계 때문에 micro-batch와 gradient accumulation을 씁니다.

micro-batch 4개를 순서대로 처리
gradient를 누적
4번 누적 후 optimizer step
-> 큰 global batch처럼 동작

추론에서는 그런 식으로 parameter update를 기다리지 않습니다. 대신 실행 중인 요청을 계속 섞습니다.

Token 비용은 가격표와 workload가 같이 만듭니다

사용자는 보통 token 가격표를 봅니다.

input token 가격
output token 가격
cache token 가격

하지만 실제 비용은 가격표만으로 정해지지 않습니다.

같은 작업이 tokenizer에서 몇 token이 되는지, prompt가 얼마나 긴지, output이 얼마나 긴지, cache를 재사용할 수 있는지, reasoning token이 얼마나 나오는지에 따라 비용이 달라집니다.

총 비용
~ input tokens
+ output tokens
+ cache read/write
+ reasoning tokens
+ tool result로 늘어난 context

sequence length는 이 모든 것을 묶는 축입니다.

긴 repository context를 매번 넣으면 input token이 커집니다. 긴 답변을 요구하면 output token이 커집니다. 긴 agent run은 이전 tool result까지 계속 context에 남겨 sequence length를 키웁니다.

그래서 비용 절감은 "모델을 싼 것으로 바꾸기"만이 아닙니다.

필요한 파일만 context에 넣기
tool output을 요약하기
반복되는 prefix를 cache-friendly하게 유지하기
긴 답변이 필요 없는 곳에서는 출력 길이 제한하기
reasoning effort를 작업 난이도에 맞추기

이런 운영 판단이 token 비용을 바꿉니다.

Throughput은 token cost의 분모입니다

GPU를 1초 돌리는 비용은 사용자가 보낸 token 수와 무관하게 계속 발생합니다. 구매비, 임대료, 전기, 냉각, 운영 비용은 시간 단위로 쌓입니다.

그래서 provider 관점의 token당 비용은 단순화하면 이렇게 볼 수 있습니다.

cost per token
= cost per second / tokens per second

여기서 tokens per second가 throughput입니다. throughput 자체가 token cost는 아니지만, token cost를 낮추는 핵심 분모입니다. 같은 1초에 1,000 tokens를 처리하는 GPU와 10,000 tokens를 처리하는 GPU의 token당 원가는 다릅니다.

이 때문에 scheduler는 batch를 가능한 한 채우려 합니다. 다만 무조건 크게 채우면 좋은 것도 아닙니다. 한 step이 너무 길어지면 streaming 중인 사용자의 inter-token latency가 튑니다.

batch가 너무 작음
-> GPU가 놀고 cost/token이 높아짐

batch가 너무 큼
-> step time 증가, ITL 악화

현대 serving engine이 continuous batching, chunked prefill, paged KV cache를 조합하는 이유는 이 균형 때문입니다. 매 scheduler iteration마다 decode token과 prefill chunk를 섞어 GPU를 채우되, 사용자 체감 latency를 망치지 않는 지점을 찾습니다.

Token당 비용은 시간당 비용을 throughput으로 나눈 값에 가깝습니다. Batch가 너무 작으면 GPU가 놀고, 너무 크면 inter-token latency가 튑니다.

Long context는 다른 사용자의 자리를 줄입니다

긴 context는 input token 가격만의 문제가 아닙니다.

긴 prompt는 prefill에서 많은 K/V를 만듭니다. 그 뒤 output token을 생성할 때도 매 decode step마다 긴 KV cache를 읽어야 합니다.

input 200k tokens
-> 큰 prefill
-> 큰 KV cache
-> output token마다 긴 cache read

출력이 길어지면 context는 더 커집니다.

처음 context 180k
+ output 20k
= decode 후반 context 200k

이런 요청 하나는 같은 GPU에서 동시에 태울 수 있는 짧은 요청의 수를 줄입니다. provider 입장에서는 긴 context 요청이 memory capacity와 memory bandwidth를 오래 점유하는 셈입니다.

그래서 API 가격표를 보면 token economics의 신호가 보입니다.

input token 가격
output token 가격
cached input 할인
long-context tier
priority / batch / flex tier

output token이 더 비싸다면 decode capacity가 비싼 자원이라는 신호입니다. cached input이 싸다면 prefill 재사용이 provider에게도 이득이라는 뜻입니다. priority tier가 비싸다면 같은 token이라도 피크 시간의 latency 보장 capacity가 더 비싸다는 뜻입니다.

비용은 token 수와 실행 스케줄링이 함께 만듭니다

batch와 sequence length는 LLM 비용과 속도를 읽는 기본 단위입니다.

추론 batch는 여러 요청을 묶어 GPU를 효율적으로 쓰기 위한 serving 단위입니다. continuous batching은 실행 중인 batch에서 끝난 sequence를 빼고 새 sequence를 넣으며 throughput을 높입니다.

학습 batch는 loss와 gradient를 계산하고 parameter를 업데이트하기 위한 데이터 묶음입니다. LLM 학습에서는 sample 수보다 token 수, 즉 batch size와 sequence length를 곱한 규모가 중요해집니다.

sequence length는 token 줄의 길입니다. 추론에서는 현재 context 길이, 학습에서는 sample/block 길이와 연결됩니다. 길어질수록 더 많은 문맥을 다룰 수 있지만 prefill, attention, KV cache, decode memory 부담이 커집니다.

결국 LLM 비용은 다음 식에 가깝습니다.

가격표
x tokenizer가 만든 token 수
x sequence length 분포
x batch scheduling
x cache/reasoning/tool 사용 방식

다음 글에서는 이 비용 구조가 거대 모델 serving에서 어떻게 분산컴퓨팅 문제로 바뀌는지 봅니다. MoE expert, GPU sharding, replication, interconnect, serving replica를 연결합니다.