LLM 컨텍스트 길이와 동시성 가이드
Jump to navigation
Jump to search
LLM 컨텍스트 길이와 동시성 가이드
상태: Active · 소유: Knowledge Agent · 마지막 업데이트: 2026-11-08 · 검토: Pending
Overview
LLM을 서빙할 때 "컨텍스트를 얼마나 크게"와 "동시에 몇 개 세션을"은 같은 GPU 메모리(KV 캐시)를 나눠 쓰기 때문에 서로를 저해한다. 이 트레이드오프의 원리를 이해하고, 사용 목표(긴 문서 1건 vs 다수 세션)에 따라 둘 중 어느 쪽을 우선할지 정하는 법을 정리한다.
Summary
- 무엇인가? LLM 서빙에서 컨텍스트 길이(context)와 동시성(동시 세션 수)의 관계, 그리고 둘을 조절하는 레버
- 왜 필요한가? 같은 GPU라도 컨텍스트를 크게 하면 동시 처리 세션이 줄고 그 반대도 성립 — 서버 용량 계획의 핵심
- 언제 사용하는가? LLM 서버를 구축/리사이즈할 때 목표에 맞춰 컨텍스트·동시성을 결정할 때
Key Concepts
| 개념 | 설명 | 관련 |
|---|---|---|
| 컨텍스트 길이 (max_model_len) | 요청당 처리할 최대 토큰. 클수록 긴 문서·정확도에 유리하나 KV 캐시를 많이 차지 | Context Window |
| KV 캐시 | attention 중간 결과. 토큰 수·컨텍스트 길이에 비례해 VRAM을 차지 — 용량의 실제 소비처 | KV Cache |
| gpu_memory_utilization | vLLM이 GPU VRAM의 어느 분율을 가중치+KV+overhead에 쓸지. 올리면 KV 풀(→컨텍스트/동시성)이 커짐 | VLLM |
| KV 데이터 형식 (dtype) | float16(2B) / fp8(1B) 등. 소자 크기를 줄이면 같은 VRAM에 2배 컨텍스트·동시성 | Model Quantization |
| 동시성 (concurrency) | 동시에 처리할 수 있는 세션 수 = KV 풀 토큰 / max_model_len | Throughput |
핵심 관계 (공식)
한 장카드에서 컨텍스트와 동시성은 같은 "KV 토큰 풀"을 공유한다.
KV풀_토큰 = (VRAM x gpu_memory_utilization - 가중치 - overhead) / 토큰당_바이트
최대_컨텍스트 = min( 모델의 학습 최대 길이 , KV풀_토큰 )
동시성 = KV풀_토큰 / max_model_len (전부 GPU에 있을 때)
토큰당_바이트 = 2 x KV헤드 x head_dim x attention_층수 x dtype_바이트
256K 요청 1개는 KV 풀을 거의 다 쓴다(동시성 ~1), 32K 요청은 1/8만 쓴다(동시성 ~8배). 아래 레버로 풀을 키거나 1요청당 비용을 줄인다.
최대 컨텍스트를 위한 레버
- gpu_memory_utilization 올리기 (0.90 → ~0.95/0.96) — 가장 직관적인 레버. KV 풀을 키는 직접 수단. 1.0에 가까울수록 여유가 없어져 OOM 위험.
- KV dtype 줄이기 — float16(2B) → fp8(1B,
--kv-cache-dtype fp8_e4m3)로 같은 VRAM에 컨텍스트 2배. 단 fp8 KV는 SM89+(Ada/Hopper)만 지원 — Ampere/Turing은 float16이 한계. - VRAM 늘리기 — 더 큰 카드(48GB → 80GB) 또는 멀티 GPU
--tensor-parallel-size N로 풀을 비례 확장. - CPU로 빌리기 —
--cpu-offload-gb N로 KV 풀을 카드 밖(시스템 RAM)으로 확장. 긴 컨텍스트·저처리량에 적합, 지연은 증가. - KV가 작은 아키텍처 고르기 — KV 헤드 적음 / head_dim 작음 / GQA·MLA / linear-attention 층이 많을수록 토큰당_바이트가 본질적으로 작아져 같은 VRAM에 더 긴 컨텍스트.
- 모델 상한 — 모델이 학습된 최대 길이(max_position_embeddings)를 넘을 수 없음.
더 많은 세션(동시성)을 위한 레버
- max_model_len을 실제 워킹셋으로 낮추기 — 가장 큰 레버. 세션이 대략 32K면
--max-model-len 32768으로 같은 풀에 ~8배(256K → 32K)가 들어온다. 최상 컨텍스트를 처리량으로 교환. - 풀 늘리기 — 더 큰/많은 카드, gpu_memory_utilization 상향, 멀티 GPU, CPU offload.
- dtype 줄이기 — fp8(SM89+)으로 컨텍스트·동시성 둘 다 2배.
- 스케줄러 제어 —
--max-num-seqs N로 동시 시퀀스 상한(기본 256)을 KV로 계산한 동시성 이하로 맞춰, 제한이 풀 쪽이 되도록. - vLLM에 맡기기 — PagedAttention은 풀이 가득 차면 일부 요청을 내보내고 재prefill해(프리엠프트) 응답을 유지. 위의 동시성은 "전부 GPU 레지던트"일 때의 편안치.
- 긴 컨텍스트 + 다수 세션을 동시에? — flag가 아니라 VRAM 문제. 더 큰/많은 GPU, 또는 SM89+ 카드(fp8), 또는 CPU offload로 메모리를 늘리는 것뿐.
실전 선택 가이드
| 사용 목표 | 컨텍스트 | 동시성 | 추천 |
|---|---|---|---|
| 긴 문서/코드 1건, 단일 에이전트 | 최대 (모델 상한) | ~1 | gpu_mem_util 상향(0.95/0.96) + max_model_len = 모델 최대 |
| 에이전트 1 + 가끔 2 | 중간 | ~1-2 | gpu_mem_util 0.90 + 중간 max_model_len |
| 가벼운 세션 다수 | 실사용 수준(예: 32K) | 여러 개 | gpu_mem_util 0.85~0.90 + max_model_len을 실제 워킹셋으로 |
| 긴 컨텍스트 + 다수 세션 | 둘 다 큼 | 둘 다 큼 | 더 큰/많은 GPU, 또는 SM89+ 카드(fp8) |
요약: "최대한 큰 컨텍스트"와 "가능한 많은 세션"은 같은 메모리를 두고 반대 방향이다. 목표가 명확하면(긴 문서 vs 다수 세션) 위 레버로 결정하고, 둘 다 필요하면 하드웨어(VRAM)로 확보한다.