배칭 전략이 SLO를 결정한다
LLM serving 아키텍처에서 SLO에 가장 직접적으로 영향을 주는 것은 배칭의 설계 방식입니다. 아무리 고성능의 GPU를 탑재해도, TTFT(Time To First Token), ITL(Inter-Token Latency), aggregate throughput의 세 가지 지표를 동시에 만족시키기 위해서는, 요청 도달 파형·입력 길이의 분포·출력 길이의 분포·KV cache 점유 패턴에 맞게 배칭 전략을 설계해야 합니다. 본고에서는 2026년 시점에서 실전 투입되고 있는 다섯 가지 방법——continuous batching, chunked prefill, PagedAttention, RadixAttention, sorted batching——의 특성과, SLO에 대한 영향, 그리고 prompt cache와의 조합을 정리합니다.
Continuous Batching
Continuous batching(별칭 iteration-level scheduling)은, decode의 각 스텝마다 배치 구성을 재결정하는 방식입니다. 종래의 static batching이 '동일 배치의 모든 request가 완료될 때까지 신규를 받지 않는' 것에 대해, continuous batching은 '완료된 request를 즉시 빼고, 빈 슬롯에 신규 request를 삽입한다'는 방식입니다. 이 결과, GPU 사용률이 request 길이의 편차에 영향받기 어렵고, 특히 출력 길이의 분산이 큰 채팅 워크로드에서 effective throughput이 2~4배 늘어납니다.
다만 continuous batching만으로는 prefill과 decode가 동일한 스텝 내에서 충돌하는 문제가 남습니다. 긴 prompt(8K 토큰 이상)가 들어간 request의 prefill은 수백 ms 이상 걸리며, 그 사이 다른 request의 decode가 멈춥니다. 이 prefill stall이 ITL 분포의 long tail을 만들어냅니다.
Chunked Prefill
Chunked prefill은 긴 prompt를 작은 청크(일반적으로 512~2,048 토큰)로 분할하여, 각 iteration에서 'prefill의 1청크 + 다른 request의 decode'를 동시에 처리하는 구조입니다. 이를 통해 prefill 부하가 복수의 스텝에 분산되어 ITL의 jitter가 격감합니다. SLO p99 ITL을 50ms 이내로 억제해야 하는 시스템에서는 필수 기능으로, vLLM, SGLang, TensorRT-LLM 모두에서 표준 지원됩니다.
청크 크기는 너무 작으면 kernel launch overhead가 지배적이 되고, 너무 크면 decode를 stall시킵니다. KGA의 경험칙으로는, H200이라면 4,096~8,192 토큰, B200에서는 8,192~16,384 토큰이 적절한 시작점이 됩니다. compute bound인 prefill과 memory bound인 decode를 믹스하면, GPU의 compute/memory 양쪽이 동시에 사용되므로 MFU가 단독 처리보다 높아지는 부차적인 효과도 있습니다.
PagedAttention
PagedAttention은 KV cache를 고정 크기의 페이지(일반적으로 16 토큰 분량)로 분할하여 관리하는 방식으로, vLLM의 핵심 기술입니다. 메모리 단편화를 극적으로 줄이고, 물리 메모리 사용량에서 2~4배의 실효 캐파시티를 얻을 수 있습니다. 2026년 현재, vLLM뿐 아니라 TensorRT-LLM, SGLang, DeepSpeed-Inference의 대부분도 유사한 paging 메커니즘을 채택하고 있습니다.
PagedAttention은 'prefix 공유'의 기반으로서도 중요하며, 동일한 system prompt를 사용하는 복수의 요청이 동일한 페이지를 참조함으로써 물리 KV를 하나만 갖게 됩니다. 다만 vLLM 본가의 prefix caching은 '완전 일치 prefix 단위'이며, partial 일치나 테넌트 횡단의 최적화는 RadixAttention 계열이 우세합니다.
RadixAttention
SGLang이 제창한 RadixAttention은, KV cache를 radix tree 구조로 관리함으로써 '임의의 prefix 단편'을 공유 가능하게 합니다. system prompt, few-shot examples, tool 정의, 테넌트 공통 context 등, 중첩된 공유 구조를 자동으로 감지하여 물리 KV를 한 곳에 집약합니다.
실측 벤치마크에서는, 공유 system prompt를 포함하는 멀티턴 채팅(평균 턴 수 8, 동시 세션 256)에서, RadixAttention이 vLLM의 prefix caching 대비 prefill 비용 40~60% 절감, TTFT 중앙값 30~45% 개선을 달성하였습니다. 긴 tool 정의를 포함하는 에이전트 워크로드에서는 2~3배의 차이가 나는 경우도 있습니다.
한편 eviction policy 설계가 어렵고, LRU 단순 적용으로는 핫한 테넌트와 콜드한 테넌트가 교체될 때 TTFT가 급등합니다. KGA에서는 테넌트별로 우선도를 부여한 weighted LRU, 또는 테넌트 파티션을 고정 할당하는 hard partitioning을 상황에 따라 선택합니다.
Sorted Batching
Sorted batching은 '입력 길이 또는 남은 출력 길이가 가까운 request를 동일 배치에 모으는' 전략입니다. naive한 continuous batching은 길고 짧은 것이 혼재하면 패딩과 padding mask의 비효율이 발생하지만, sorted batching은 이를 완화합니다. 2026년 시점에서는 serving 프레임워크에 표준 구현되어 있다기보다, 상위 레이어의 라우터/스케줄러가 구현하는 기능입니다.
단기 응답 전용 엔드포인트(분류, reranking, 짧은 summarization)와 장기 응답 엔드포인트(보고서 생성, long-form 코드 생성)를 분리하고, 각각에서 sorted batching을 적용하는 설계가 가장 단순하며, effective throughput 20~35% 향상을 실측할 수 있습니다.
SLO에 대한 영향 정리
- TTFT: chunked prefill과 prefix caching/RadixAttention이 지배적입니다. 이 두 가지가 들어가 있으면 p50 TTFT는 100ms 전후, p99에서도 500ms 이내에 수렴합니다.
- ITL: continuous batching과 chunked prefill이 효과적입니다. chunked prefill을 넣지 않으면 p99 ITL이 쉽게 200ms를 초과합니다.
- Throughput: PagedAttention으로 메모리 효율을 내고, continuous batching으로 슬롯을 채우고, RadixAttention으로 prefill 낭비를 줄이는 세트로 최대화합니다.
- p99 tail: sorted batching과 admission control로 지킵니다. QPS 스파이크 시에는 낮은 우선도의 request를 queue시키는 admission policy가 필요합니다.
Prompt Cache 전략
본番 스택에서 prompt cache를 설계할 때의 축은 네 가지입니다.
System prompt sharing. 전 테넌트 공통의 system prompt는 시작 시에 프리웜하여 상주시킵니다. RadixAttention에서는 시작 스크립트에서 `warmup` 요청을 보내 KV tree에 올려두는 것이 정석입니다.
Tenant partitioning. SaaS 형태로 멀티테넌트를 혼재시키는 경우, 테넌트 A와 B의 context가 섞이면 security/compliance 관점에서 문제가 될 수 있습니다. RadixAttention은 암호론적 분리가 아니므로, 금융·의료 등 엄격한 도메인에서는 테넌트별로 프로세스(또는 GPU 그룹)를 분리하고, 공유 레이어를 '비기밀인 system prompt만'으로 한정하는 설계가 필요합니다.
TTL과 eviction. 세션이 긴 채팅 에이전트에서는, 멀티턴 대화의 중간 KV를 임시 캐시에 저장하고, 대화 중단 후 N분 후에 evict하는 설계가 효과적입니다. KGA의 고객 사례에서는 TTL을 15~30분으로 설정하여, 메모리 압박과 재 prefill 비용의 균형을 맞추고 있습니다.
Cross-request dedup. 에이전트 계열에서는 동일한 tool 응답을 복수의 LLM call에 전달하는 패턴이 많으며, 이 tool 응답을 핑거프린트로 dedup하여 KV tree에 한 번만 올리는 방법이 TTFT를 30% 이상 줄여줍니다.
설정 예: vLLM + chunked prefill + prefix caching
```python llm = LLM( model="Qwen/Qwen3-72B-Instruct", tensor_parallel_size=8, kv_cache_dtype="fp8", enable_prefix_caching=True, enable_chunked_prefill=True, max_num_batched_tokens=8192, max_num_seqs=256, gpu_memory_utilization=0.92, block_size=16, preemption_mode="recompute", ) ```
`max_num_seqs`를 너무 크게 하면 메모리 압박으로 swap이 빈발하므로, 실운용에서는 QPS 예상과 p99 출력 길이로부터 역산합니다. KGA의 경험값으로는, QPS_peak × p99_output_length / expected_decode_rate가 대략적인 상한이 됩니다.
마무리
배칭 전략은 '다섯 가지 방법 중 하나를 선택하는' 것이 아니라, '전부 도입한 후에 파라미터를 SLO에 맞게 조정하는' 것이 2026년의 정답입니다. TTFT를 지키려면 chunked prefill과 RadixAttention, ITL을 지키려면 chunked prefill과 sorted batching, throughput을 높이려면 continuous batching과 PagedAttention, 테넌트 분리를 지키려면 hard partitioning과 tenant-aware eviction. 이 네 가지 축으로 아키텍처를 설계하면, H200 SXM 8장 구성으로 70B 모델이라도 aggregate 2,500 tok/s, p99 TTFT 400ms 이내의 SLO는 충분히 노릴 수 있습니다.