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

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가 더 비싸다는 뜻이다.

정리

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를 연결한다.